posted 01-27-2019 10:18 AM                       

quote: Marcel

---

I've never really written a program for a JNIOR, so I don't know how that feels, but what I really want is a simple, yet powerful scripting language.

---

quote: Tony

---

I'd still like to hear from Bruce on my thoughts about adding IR capability....I guess he didn't see my post on 1/4/19. [Confused]

---

posted 01-27-2019 11:00 AM                    

quote: Bruce Cloutier

---

I did see the post. You mentioned the "universal remote" issue which really opens Pandora's Box. I can see a JANOS based (JNIOR's core) product offering something along these lines. Our user programming capabilities would allow an integrator to accommodate almost any unique theater control requirement in whatever setting. We need to discuss this off-line so we could come to some agreement on the scope of such a thing. Perhaps there is another product out there that comes close but could use our touch that can serve as a reference point. I know that I personally could use it in my home. I can see 6 controllers from where I am sitting right now.

---

posted 01-29-2019 04:46 PM                    

quote: Bruce Cloutier

---

If none of that floats your boat you can create simple Java programs in any available IDE. Build your project against the JanosClasses.jar runtime and it will run on the JNIOR. You can run several applications simultaneously.

---

Maybe you should try to target the JNIOR more at the homebrew domotics and automation market? The same market that currently is stuck with Arduinos and RasPIs? Only now, you get a platform that can run actual Java code and useful interfaces with the rest of the world.

For me, personally, the primary problem is time. Often being occupied with lots of concurrent stuff, I don't have the time to start another development project.

What I try to get across, why I like the Alcorn McBride WinScript stuff is, because they provide me with a set of tools that get me up-and-running in no-time. There really is no need for me to learn yet another API, to get an IDE running, to compile stuff, etc. If someone could replicate a similar experience on a budget, I'm pretty sure the market would be up for grabs.

The amount of automation around us is only increasing every day, but the amount of competent developers isn't steadily increasing. Therefore we need the tools to let half-competent script-warriors to do the job too.

quote: Bruce Cloutier

---

I would avoid MODBUS if for no other reason than the lack of security. The JNIOR provides for a means to implement a login on a Modbus connection but that requires customization on the client side where most use off-the-shelf software that cannot support the login.

---

Well, yes, I would love to avoid MODBUS, even though my own house is still strung together with MODBUS.

But, let me try to get my message across, for what it's worth. I'm really looking forward to a system that lets me (securely) string together a whole "universe" of input and output modules, all simply connected by Ethernet or even better, simply by IP, where I can thread my input and outputs in my "program" or "script" like they were locally connected.

If such thing could even work "event driven", so I don't need to constantly poll for a certain value, that would be even greater.

But I really don't want to write code that deals with sockets, queues and all the nitty-gritty low level communication protocols out there, it should just work seamlessly: I connect my slave modules over IP to the master and once they're registered on the "master", the inputs and outputs are available, like they're local GPIO. The communication between the "master" and the "slaves" should be transparent for me.

posted 01-30-2019 11:24 AM                    

quote: Marcel Birgelen

---

But, let me try to get my message across, for what it's worth. I'm really looking forward to a system that lets me (securely) string together a whole "universe" of input and output modules, all simply connected by Ethernet or even better, simply by IP, where I can thread my input and outputs in my "program" or "script" like they were locally connected.

If such thing could even work "event driven", so I don't need to constantly poll for a certain value, that would be even greater.

But I really don't want to write code that deals with sockets, queues and all the nitty-gritty low level communication protocols out there, it should just work seamlessly: I connect my slave modules over IP to the master and once they're registered on the "master", the inputs and outputs are available, like they're local GPIO. The communication between the "master" and the "slaves" should be transparent for me.

---

AMX and Crestron already do that.

The issue with those two companies (and it's not necessarily a bad thing) is that the hardware is proprietary to them and not universal like some ethernet based hardware.

Legacy AMX hardware used Axlink (2 data, 2 power in a "special" cable.) Crestron uses Cresnet (same type of cable, different comm protocol). AMX has moved on to Netlinx which uses CAT 5e for power and comm. (Fun note, Crestron has a special CresNet block to terminate multiple cables with a very naughty part name. Let's just say that the abbreviation for CresNet is CNT ..you figure out the rest.)

Both systems have the ability to "talk" to the outside world via relays, IR emitters, serial data and ethernet. They have a host of other modules to also do 0-10v control (you can set up a fader for a CP-55/65/200 with it), 4-20ma process control and more. AMX's Axcess Card cage masters also had input cards for temperature, and DMX output cards to control theatrical lighting.

The programming platforms are different between the two as well.

AMX Legacy was a strictly "line-based" code (vaguely similar to C++) that is extremely versatile. I literally can create my own programs easily and never had to take AMX's courses. (I started by editing existing programs and moved on from there.) Both University screening rooms I did used legacy systems and code I wrote from scratch.

AMX Netlinx is similar, but offers a few pre-programmed "modules" of code to make programming faster. To build a program it is a hybrid of line-oriented and object based coding. I haven't had the time to do any Netlinx programming yet..I do have a controller that will be replacing my Axcess controller here in my house, when I get around to writing the code.

Crestron uses a very object oriented programming protocol, which I never really got good at. It is done on blocks of code, and you link the blocks together to get your finished program. I worked with a programmer who was a true wizard with it, he could write and debug at an impressive speed.

Both systems have compilers that take care of getting the code formatted to work with the master. Both work very well, but are not foolproof. You CAN successfully compile codes with errors that have adverse effects on the desired outputs.

The worst experience I encountered with that little "gotca" was a screening room setup with two screening rooms and four projectors running on one master. An error in my code caused the "Changeover OPEN Rm1 P1" caused the other three changeovers to get open AND close commands at the same time. Oops. Luckily I was able to clear the error before frying the changeovers. And each relay set did have the mutually exclusive code to keep that from happening. (still trying to figure out how my mistake made the system ignore that exclusive part of the code.)

One trick that is cool is you can talk from Amx to Crestron and vice-versa via RS 232 if both systems have the appropriate code. I did that at the Academy (Oscars) theatre to control the four way masking. (I have not used any of the latest from both manufacturers, but it should also be possible to do this via ethernet.)

Both systems can be event driven (AMX refers to it as a "System Call") to simplify the code and make the operation more robust.

As for physical security, both systems have that pretty well locked down. You not only need bus/network compatible devices physically connected (though both offer wireless connectivity) but you would need to have the master code programmed to communicate with the rogue device..otherwise it is simply ignored. To get into the master code, you would need the system's complier/editor software, AND (in the case of AMX) the "source code" to be present in the master. (AMX legacy has the option to "load with Source Code") and if you don't do that, the only way you can edit anything is if you have the source code saved on your computer. Otherwise you're screwed. A certain programmer had the habit of uploading without including source code and it bit him and me more than once.

posted 01-30-2019 03:48 PM                       

quote: Marcel

---

Maybe you should try to target the JNIOR more at the homebrew domotics and automation market? The same market that currently is stuck with Arduinos and RasPIs? Only now, you get a platform that can run actual Java code and useful interfaces with the rest of the world.

---