This is topic Additional uses for the JNIOR in forum Digital Cinema Forum at Film-Tech Forum ARCHIVE.
To visit this topic, use this URL:
https://ft-forum.com/ft/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic;f=16;t=003539
Posted by Bruce Cloutier (Member # 9615) on 01-03-2019, 11:03 AM:
You know that the JNIOR can do a lot of things and it wasn't designed solely for the cinema market. We want to bring more value to this market (make the JNIOR do more for you) but need your input. I do not have the direct experience in operating a theater that all of you have but I can create products. For new applications I need to rely on all of you.
quote: Carsten Kurz
There are certainly more ways to use a JNIOR in cinemas in addition to the classic applications as light and curtain control. Not only the actual application is of interest, but also the means to apply user interaction. E.g. all servers enable automatic actions in playlists, but playlists are only active during an actual movie showing. So, one has to look closely at what happens when and what is useful for the operator. I am sure that cinema will have a good time with you sneaking in.
Bruce - ever thought of adding IR remote control as an expansion module?
Carsten, the IR control is an interesting idea and obviously something that we could easily do. I couldn't tell if you were thinking of an IR transmitter (so we can control other devices by simulating their remote control inputs) or a receiver (so we could respond to commands from some standard remote). Did you have a target application in mind?
Posted by Carsten Kurz (Member # 5396) on 01-03-2019, 03:13 PM:
I guess sending IR makes more sense, as control can nowadays be achieved more easily through networked smartphones/tablets.
Now that Oppos Blurayplayers are gone, being able to control such consumer devices could be handy.
- Carsten
Posted by Bruce Cloutier (Member # 9615) on 01-04-2019, 06:51 AM:
The Oppo Bluerays are gone? Figures. That's what I have in my home system.
We would like to service more of the home and small theater market. Options for the JNIOR to interface somehow with these players and surround systems would help. We could do something along the lines of a "universal remote" as well. Just ideas.
We're making changes to allow us to be more responsive to custom requirements and low volume product implementations. By the end of February INTEG will have its own production line up and running where previously we relied upon contract manufacturing. This will allow us to go from design to delivery in around 4-6 weeks. With reliance on contract manufacturers the best we could do is 3-4 months and the smallest runs would have to be like 250. We're excited about this.
Posted by Harold Hallikainen (Member # 5405) on 01-04-2019, 09:47 AM:
IR control is interesting, but can't this equipment already be controlled by the SMS over HDMI?
Harold
Posted by Tony Bandiera Jr (Member # 2365) on 01-04-2019, 10:17 AM:
quote: Bruce Cloutier
We would like to service more of the home and small theater market. Options for the JNIOR to interface somehow with these players and surround systems would help. We could do something along the lines of a "universal remote" as well. Just ideas.
For this idea to fly, rather than having your company try to get the IR command files from all of the manufacturers, you need to take the route that AMX (and I presume Crestron) has done....AMX has a box called the "IRIS" which is a learning device.
You use the equipments' remote to program in each function (assigning it to a unique "channel" as you do so) that is saved as code that the AMX controller can translate and send to standard IR emmitters (simply an IR LED in a stick-on package) to place on the controlled equipment.
I have used it extensively and with very little practice can program a rather large full-function remote in a short period of time.
One great feature of this setup (which simplifies code writing and learning new remotes) is that the common functions' channel assignments can be saved to a template to save a lot of time in learning new remotes.
So far, I have never found a "universal" remote sold that can cover every function of all the gear I have encountered...the AMX IRIS and touchscreen/controller system makes that an easy task.
I would be happy to provide the services to help develop this concept with the JNIOR if you provide the equipment.
Posted by Carsten Kurz (Member # 5396) on 01-05-2019, 07:15 AM:
Oh wow, on a side note, I just opened an ancient issue of Cinema Technology Magazine, and found an image and description of a JNIOR in it - this issue is from september 2008, so, more than 10 years...


- Carsten
Posted by Bruce Cloutier (Member # 9615) on 01-05-2019, 08:18 AM:
INTEG was formed in 1999 as a programming services company. The company had contracts to develop control systems software in the newspaper industry and to develop computer models and simulations for the steel industry. We also provided programming support to the transportation industry.
The control systems we developed relied heavily on Programmable Logic Controllers (PLCs) and some of you may be familiar with them. They are expensive and the companies that make them have learned to efficiently collect your money. INTEG needed an inexpensive controller and developed the JNIOR concept. This was sometime around 2001 or 2002.
The first units had combinations of I/O including built-in analog (10V) capabilities. The first prototypes became known as the JNIOR1 or JNIOR Series 1. Only a few were made. The product was redesigned for production as the JNIOR2 and only a couple of thousand were produced.
Kodak obtained the JNIOR2 for use as a low-cost controller with their pre-show systems. They eventually came to INTEG asking that we create a model with more relays and inputs dropping the analog I/O as this would best fit their needs. As a result the JNIOR3 or Series 3 Models 310, 312 and 314 were developed. This was around 2004 and it is when I became involved with INTEG. First INTEG contracted for my services but eventually as the product gained speed I took on ownership.
The Series 3, recognizable by the white background label (and green power LED), was in production from 2004 thru 2014 (10 years). The processor it employed was an 8051 variant with built-in Java Virtual Machine (JVM). The component manufacturer eventually notified us that they were no longer going to make the part.
As we have a commitment to this market and we were in the midst of the big conversion to digital cinema, we needed to replace the product with something. I decided to redesign the JNIOR from the bottom up around a new processor. The only design spec was that it be a drop-in replacement for the Series 3 (and perform much better). The Series 4 was born and these are current products for us. The only visible difference is the black background label and the blue power LED.
So when I created the first Model 410 prototype I installed the board in a 310 housing. So we could tell which was the new 410 I temporarily used the blue LED for the power light. Well Rick liked the blue and we stuck with it. The color blue was a hard thing to create in an LED. So it initially became somewhat of a novelty for everyone. We were no different. So we kept it.
Yeah, more than 10 years for the JNIOR. More like 15. But it is not old stuff. It is becoming a work-horse in a lot of industries.
In 2018 I became the sole owner of INTEG and we have been refocusing the company. INTEG is now a product company and I spun off what remained of the programming services activities. I still have the Hot Strip Mill Model (HSMM) which is used by every company producing steel around the globe. I need to find a home for that software asset.
In entering 2019 INTEG will begin producing the JNIOR with our own production line. We were reliant on contract manufacturing previously and that limited us in a number of ways. One issue had been our ability to bring new product to market. It both took months and the costs required that we had customers interested in quantity. Soon we will be able to create product and bring it to market in just a few weeks and produce as few of them initially as makes sense without undue cost. We are excited about this.
So now where do we go with it?
Posted by Steve Guttag (Member # 268) on 01-05-2019, 01:58 PM:
How is the rackmount package coming? (or at least some form of finished installation package?
Posted by Bruce Cloutier (Member # 9615) on 01-05-2019, 04:06 PM:
I know that we discussed the rack mounting. In working to make that happen I ran into the issues that I referred to in the prior post. So the first step to get that done, well, was to buy the company believe it or not. So I'm working on it. That and about 12 other configurations. Our production line should be up and running by the end of February. First we'll need to get all of our current products to run through there. And... then we'll see about rackmount or anything else different.
We'll be able to quickly run small quantities of custom boards for versions of the JNIOR (or anything else). It is PCB assembly equipment that we are bringing online. After that is in place I need to address the cost for enclosures and metal work. The sheet metal case for our LED dimmer is crazy expensive for some reason and it shouldn't be. Just the flat 2U plate that we use for the Control Panel is far too costly. Now we have tariffs. We don't like what we would have to charge for that rack-mounted JNIOR. I am pretty sure that you won't. Gotta work on it.
We are not passing these tariff costs through to you, our customers. We needed to take command of purchasing and production in order to get control over our costs and get it so we can absorb these tariffs.
We have never increased our pricing. That Model 310 in the photo that Carsten posted carried the exact same list price as does the 410 today. Even our approach to discounting has not changed in decades. So to keep it up, we have had to make changes.
Okay... enough blowing my horn. I doubt that any other company in this market will be as transparent and accessible as we are.
So I started this thread to prompt you all for ideas. To see what you want for the future of JNIOR or how INTEG might be able to play a better role. Steve previously suggested rackmounting to address the installation of the JNIOR. Got that on the list.
New product development aside, you probably don't fully realize what you can do with what you already have. Just as, I don't really know what it is you need.
Posted by Bruce Cloutier (Member # 9615) on 01-09-2019, 10:32 AM:
And there is silence and one can imagine the proverbial tumbleweed rolling past...
For those of you who read but not post, you can look into jnior.com. There in the knowledge base there are a number of topics covering the JNIOR, what you can do and in some cases how to do it. If you want a peek into JNIOR applications perhaps beyond cinema, that site may be of interest.
Posted by Harold Hallikainen (Member # 5405) on 01-09-2019, 10:56 AM:
Just curious... You said the device started as an 8051 variant with a Java virtual machine. I wonder what processor is now used? I THINK I MIGHT remember a processor that executed Java byte code directly, but that may be a faulty memory. Is the current device a CPU with a Java interpreter library or something like that?
Harold
Posted by Bruce Cloutier (Member # 9615) on 01-09-2019, 11:37 AM:
The JNIOR Series 3 used/uses the Dallas/Maxim-IC DS80C400 processor. Basically this was an 8051 variant that booted up a built-in Java Virtual Machine. From the manufacturer this would run a single Java process. We hacked the thing to make it multi-tasking and created some inter-process communications. This allowed us the develop an application like CINEMA and still run other programs. Outside of the fixed firmware in the processor everything was done through Java.
The Series 4 currently is based upon the Renesas RX63N processor. Here we developed the JANOS operating system to mimic the environment that eventually existed on the JNIOR Series 3. Only, much better.
The Series 3 employed the DS80C400 processor which is an 8-bit processor that ran at 36 MHz and everything had to be in Java (including operating system tasks, network, etc).
The Series 4 employs the Renesas RX63N which is 32-bit running at 100 MHz where all of JANOS is implemented through an optimized C compiler.
The difference is more than a 200X improvement in performance. JANOS can execute one or more instances of our JVM (each running program is its own instance). So applications are still in Java but perform at a whole different level and can take on much more sophisticated tasks.
At the same time JANOS can manage the network, make secure connections, support a full-featured web server with PHP-like server-side scripting, support a websockets API, handle FTP, and Telnet command line tasks. All done at the lowest level not burdened by any JVM requirement.
So back in the 90's Sun Microsystems was pushing Java as a means to network enable everything. They made the JVM public and encouraged device manufacturers to create processors that can be used to embed the JVM in almost everything. The DS80C400 was part of a series of processors that Dallas Semiconductor introduces along those lines. Other component manufacturers had their own.
Obviously I like to boast about it and we need to sell more of them but... I am really here to help anyone with their JNIORs that they already have. I have to admit we do cringe when a Series 3 issue comes along. We are spoiled now with the Series 4.
Aside from offering support, many of you have JNIORs sitting there that can be easily used to do something additional.
For instance, you might have one doing not much more than flipping house lights. You can add an environmental sensor to it and track booth temperature and humidity. Perhaps issuing a warning email if things get out of hand and, well, you're shortening your bulb life or something. You could wire A/C power (not from the UPS) to an input to know when power to the building has gone down. I know, now I have the integrators cringing.
I am always fishing for ideas. A lot of people have done a lot of different things with a JNIOR. Some of that is just interesting.
Posted by Sean McKinnon (Member # 612) on 01-09-2019, 06:13 PM:
A Q-Sys custom component for the JNIOR would be good imo. While the q-says devices all have relay and GPIO I sometimes have a need to control something that is in a different location than everything else and just send macro commands to the JNIOR over IP. I can program it by hand but who wants to do that!
Posted by Bruce Cloutier (Member # 9615) on 01-10-2019, 08:12 AM:
I see that we just got the Q-Sys CORE 110f in here on loan. I believe its so we can assist in creating that component. I'll inquire as to the plan.
The remote aspect of the JNIOR w.r.t. any server GPIO is a good point.
Posted by Sean McKinnon (Member # 612) on 01-10-2019, 09:36 AM:
That's GREAT! I definitely have use cases for this such as placing a JNIOR back stage and connecting it to masking motors or placing it near an electrical panel to control exhaust fan relay's and other things like that.
I am working on the design phase of a project right now where we are planning to use the JNIOR as a masking controller.
Posted by Steve Guttag (Member # 268) on 01-10-2019, 10:57 AM:
Sean, what do you do about housing/affixing the JNIOR in your installations? And, for controlling exhaust fans, how are you addressing the HV wires such that inspectors are good with it?
Posted by Bruce Cloutier (Member # 9615) on 01-10-2019, 11:01 AM:
I also suspect that you all might appreciate a JNIOR with built-in power (10A) relays so you need not putz always with the Power 4ROUT module. Am I right?
I would need to put that in the larger 412DMX-style enclosure (thicker) to accommodate the relay height. We would have to sacrifice some of the other I/O capabilities to get the room on the PCB and wouldn't likely be able to do more than 4 relays. Both NC and NO contacts would still be provided and we would keep the snubbers. Probably keep the ride-thru power supply to cover power glitches. You might not have UPS power in remote locations.
I doubt that many of you know about the ride-thru power tech in the 412DMX. Basically it prevents the JNIOR from rebooting if there is a brief (<15 second) power glitch. It also then can log power loss and if it is restored before the reboot is forced. This does make pulling power to reboot a bit challenging. Challenging for your patience that is.
There is a YouTube Video showing it in action. Basically the blue power LED flashes indicating loss of power but the JNIOR continues without missing a heartbeat. Note Relay Output 1 remains powered. After the roughly 15 seconds the unit powers down. If I had plugged that back in life would have gone on as if nothing happened. There would be two entries in the log. One for loss of power and one for it returning.
All of you have UPS based power I bet. We have customers outside of cinema who would really appreciate this in the standard 410, 412, or 414. So we are considering its implementation there.
Posted by Carsten Kurz (Member # 5396) on 01-10-2019, 04:02 PM:
I guess I'd prefer to have 'real' power relays external. I'd love the internal relays being able to handle 230VAC, but not necessary heavy duty. Some control circuits use 110V/230V, but not necessarily high currents/loads. Someone being able to wire a JNIOR should also be able to hook up their own external relays, e.g. on DIN rails.
- Carsten
Posted by Sean McKinnon (Member # 612) on 01-11-2019, 12:25 PM:
If the JNior is going to be in a rack or pedestal we will take a 2 or 3 ru blank and drill mounting holes in it and attach it to either rear rack rails or in the case of a pedestal we would mount the JNior on the back of the blank and attach it to the front or side rack rails.
I usually leave it up to the local electrician as far as how to safely contain the HV. In the past I have used stand alone Relay in box type relays which the EC has mounted in another J box either at the rack or near the fan. I would only use the JNior if I had multiple blowers running to the same panel and I would probably have the EC mount a few of those relays in boxes in a box and connect the JNior relay output to the secondary relay which actually switches the fan so the JNior wouldn't be carrying any HV.
Those are my thoughts at least.
Posted by Bruce Cloutier (Member # 9615) on 01-11-2019, 12:49 PM:
Just as an aside, external relay coils represent inductive loads. If you touch a wire to the relay coil to energize it and then break the connection that little spark that you can see can reduce the life of the contacts in the JNIOR relays (maybe significantly).
The small signal relays in the JNIOR do not employ a TVS or Snubber circuit to protect them. You can add it externally. The relays in the Power 4ROUT external module do protect both the NO and NC contact sets with a hefty TVS component. So those are good to go.
JNIORs run the doors of the people movers in the Atlanta airport. We found out that maintenance there had been replacing the surface mounted relays on their own when they burned them out. We suggested that they add diodes externally (its a DC circuit) to protect the contacts. That resolved their issue, well, as far as I know.
Just something to keep in mind. You can find lots of articles on the topic.
Posted by Marcel Birgelen (Member # 6801) on 01-26-2019, 07:16 PM:
I'm still looking for that magical device that lets me get remote GPIOs over Ethernet like they're locally connected to the device and not using some archaic bus like Modbus. Yes, I can do Modbus over TCP/IP, but even that feels archaic and clumsy. I'm looking for a modern, more "plug and play" approach.
Also, I've done a lot of PLC programming, using FBD, ladder diagrams or Structured Text and to be honest, it is all totally archaic and inefficient. PLCs might still have their place for stuff where proven technology is key, where lives depend on predictable outcomes, but for general, everyday automation tasks, they should be considered a thing of the past... So I'd love to get rid of them.
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.
Personally, I'm a sucker for Alcorn McBride's WinScript. It's a no-brainer scripting language that doesn't get into your way and mostly does exactly what you expect it will do. They also allow you to easily design simple UI controls for the systems you automate with them. Something that even looks good, and is very responsive, unlike the bloated crap you pull out of CODESYS. I've been looking for a poor-mans implementation of a comparable system for a while now.
Posted by Gordon McLeod (Member # 33) on 01-27-2019, 08:16 AM:
If you put a internal powersupply or allowfor internal switching of HV then the device would require for sale inainstallation in Canada a CSA or ULc label on it
Posted by Tony Bandiera Jr (Member # 2365) on 01-27-2019, 10:15 AM:
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.
Posted by Bruce Cloutier (Member # 9615) on 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.
Out of the box you can remotely toggle/pulse relays, check input status, and control analog modules via the built-in web interface. There is no programming required. The pages also render on your smart phone.
We supply a CINEMA.JAR application that would allow you to create and execute macros. There is also a Task manager available as well as other freebie programs.
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.
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.
On a Series 4 the Modbus interface is simply just another application program. We don't build it in because it ain't worthy.
Also, if you go to monitor an input with Modbus you have to poll for the current state. You then waste a ton of resources repeatedly checking the input state. You never feel that you are checking often enough and generally are never going to be happy with the response to an input change.
The JNIOR Protocol (binary) or the built-in Websockets interface (JSON) both provide a means to subscribe to an input. The JNIOR then sends a message when and if the input state changes. This eliminates polling and you are alerted to an input change very promptly. Of course, one needs to program the client side for those protocols. We would support you in that endeavor.
We can easily accommodate new protocols in the JNIOR. An example is the latest MQTT work that Kevin has been doing. Since the JNIOR can make the necessary secure outgoing connections we have been successful in working with Amazon AWS. You can ask Alexa to command your JNIORs. We can demo that at CinemaCon if anyone is interested. I am personally not a fan of the voice interface. It lacks privacy and, really, most of what we all have to do is best handled quietly by pressing a button.
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]
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 by Tony Bandiera Jr (Member # 2365) on 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.
Thank you. I would like to discuss this with you when you get the chance. You can find my email in the equipment for sale forum, I have a few active listings there.
Posted by Sean McKinnon (Member # 612) on 01-28-2019, 06:22 AM:
Thanks for the advice Bruce. What would you recommend for using external relays? Add a diode on the coil? Filter the control voltage lines with caps?
Posted by Bruce Cloutier (Member # 9615) on 01-28-2019, 10:55 AM:
I'm trying to not run off on more technical detail as there are a couple of issues that one should address in protecting the small signal relay contacts. An inductive load like an external relay is but one.
If you are running an external relay you can check the specs for the relay (or relay board) that you are using. Some of those include a snubber, TVS or other circuit already. They tend to include those more and more these days not only to protect the driving circuit (our relay contacts) but to eliminate the radio noise (EMI) a spark would cause. Automotive relays have them since vehicle owners demanded clear AM radio reception in order to hear Wolfman Jack back in the day.
Basically when current flows through a wire energy is stored in a magnetic field around the wire. Wrap a length of wire into a coil and you create a significant magnetic field which in the case of a relay you need so it can actuate it. When you break the driving connection the energy stored in the magnetic field has to go somewhere. It goes out of its way to force the current to continue enough so that it ionizes the air and generates the spark (which eventually fries the contacts in our relay).
You can add a diode across the relay coil that would allow current to continue to flow in the same direction it does when the relay is activated. Now when the JNIOR's relay opens the magnetic energy can slowly dissipate without arcing. Any general leaded 1A diode should do the trick.

Generally, we can't add the protection in the JNIOR without making some assumptions as to what you are doing with it. The diode for instance only works with DC relays.
Posted by Marcel Birgelen (Member # 6801) on 01-29-2019, 04:46 PM:
I've been using MODBUS driven Digital Outputs that allow you to enable a diode via DIP switch per output, to avoid arcing. With the right power supply, their output is also sufficient to drive almost all DC power relays I've encountered. Maybe dip-switchable diodes is a possible solution for the JNIOR too.
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 by Tony Bandiera Jr (Member # 2365) on 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 by Bruce Cloutier (Member # 9615) on 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.
Maybe if we sold it without an enclosure the Arduino/BeagleBoard/RasPI people would take it more seriously. The JNIOR with its JANOS core sits in that spectrum closer to the Arduino than the Raspberry Pi. We do so little marketing that the JNIOR is more or less a secret. We also look a bit pricey for them at $400 but when you consider all of the built-in functionality and the finished product with enclosure it isn't that expensive. I guess you can figure in the value in free support (and sometimes free application programming).
The JNIOR came about to be a low-cost alternative to PLCs offered by companies like Allen-Bradley. We play a similar role in the cinema market being an alternative to AMX/Crestron/QSC an others. More and more we are being employed as a remote peripheral to these larger systems. Not everything is located so it can be easily wired to the rack in the projection booth.
It is interesting how many people think that they'll just grab an Arduino and do it themselves. It is a great educational experience and perhaps fun to do. But it amazes me how "Arduino" has become such a household word. I am not sure that I would know how to target that market.
I didn't start this thread though to try to sell more JNIORs. It is more about working to insure that technically the product is appreciated and fully meets your needs. To that I am sure you would say "Yeah right". I get it. I am a cynic too.
Posted by Carsten Kurz (Member # 5396) on 01-30-2019, 06:15 PM:
Bruce - how do you structure your buyer profiles? And what do you believe, who is making the actual decision pro/contra JNIOR? How much do you know about the target areas? I know you mentioned some examples earlier, and you probably know what type of specific functionality is used/needed in these different areas.
I recently visited a new installation by CinemaNext, and they used the Proyecson PAA-20+ Automation Adapter. I was wondering why e.g. they decide to use a JNIOR and when the Proyecson. The Proyecson has some obvious benefits (19" mountable, front soft buttons), but is a lot weaker on the software side. It's ethernet based, but it basically is a dump relay switch box. Don't know how it competes with the JNIOR price wise.
I am a tech savvy exhibitor, but many cinema operators are not interested too much into what device is installed, they think more in immediate functionality for them. Press a button, place a cue, expect the result. The question is, who defines functionality in the exhibition area. The integrator, the cinema owner, the projectionist (if exists). I think it is quite important to know who you talk to and what level of expectation that person has. I also think that many JNIORs installed in cinemas are underutilized. I guess most are used in a standard Doremi style installation, activate lights and curtain, and that's it. Many cinema operators probably do not even know what a JNIOR is, even if one is installed in the back of their racks. So, they don't know what else it can do.
- Carsten
Posted by Dave Macaulay (Member # 813) on 01-31-2019, 02:10 AM:
Almost all the Jniors we install are just used for relay control for lighting and masking plus an input for the fire alarm trigger. We have used some of the more advanced functions but that brings complications if one fails - a replacement has to be loaded with the configuration used. To avoid the headaches of archiving that data and the issues arising when one is replaced and doesn't work because the tech didn't know it was "special", we like to leave them at default requiring only the addressing setup for a replacement.
Posted by Bruce Cloutier (Member # 9615) on 01-31-2019, 07:51 AM:
Rick splits his time between Sales, Marketing and Support. Like I said we don't do much Marketing and to Cartsen's question we probably don't know who makes the purchase decision. That is something to ask Rick. I believe he would say that the integrators make the decisions. The theater owners that stop by our booth often either don't know they have JNIORs or perhaps have noticed them but still wonder what they do. Once a theater chain defines their standard system configuration they just replicate it over and over. Pretty much our approach has been to make a really smart, flexible and cost-effective controller as a reliable and capable tool and let it take on a life of its own.
Basically someone (in any market) who needs a controller finds the JNIOR in a web search and tries one. We throw in some freebie application development just because Kevin gets bored and loves new challenges. It almost always leads to additional sales in that market/application. Over time that entry festers and we move more and more units to an increasing number of customers in whatever segment. There is a surprising list of completely unrelated applications using the product almost religiously. The feedback is all good. We're just the complete other end of the spectrum from the Crestrons.
The JNIOR was not meant to be just a cinema product. We added the CINEMA application to it and continue to refine that to give the controller that cinema feel with macros and all of that. We weren't targeting rack-mounted automation with switches like eCNA, Christie's ACT, and others. Eventually we prototyped the control panel to expand the JNIOR and give it some kind of user interface. But as Steve apply noted it starts to become somewhat of a "kludge". That is not our intention of course. We will be rectifying that (hopefully) over the upcoming year or two.
I'm just looking to you all for ideas and priorities. It is your satisfaction with the thing that drives us, the sales are just a necessity to keep us alive and kicking. We don't have any cranky investors to keep happy (just me).
Later this year I would like to bring someone additional in to support Marketing and Sales. It would make sense to tap someone from this market with the market specific knowledge and experience that we don't really have ourselves. We might open a position for a tech to assist in development and perhaps create a training program. I'm open to all of that too.
Posted by Carsten Kurz (Member # 5396) on 01-31-2019, 08:28 AM:
Well, that's where it becomes interesting - the JNIOR offers sophisticated software functionality, but is very often used below it's potential (at least in the cinema environment). So, one option is to educate buyers to use that functionality (which means, integrators have to spend on manpower for training and programming), or, offer a simpler solution that competes price-wise. Or, improve other design aspects (19", buttons, etc.).
You said you have a client cinema close by. Did you go there already and got some insights in how they operate?
I recently visited two colleagues, and, among other things, was, err... slightly irritated how 'retro' their auditorium heating control was organized. Some usher had to judge on the number of patrons/seats sold and then was to go to a machine room and flip a switch between off or on...
We do have a thermostat with a week-range-timer (and pretty constant exhibition schedule) which helped us save a lot of money, but it certainly can be improved by some limited local and remote control intelligence.
The trouble is, no exhibitor is taking something like this up themselves, no integrator deals with heating, and no heating/HVAC tech wants to fiddle or is allowed to fiddle with the presentation gear.
Some of our german trade organisations picked up 'green cinema' a while ago, and issued papers on options and typical solutions. Some larger operations where able to get cinema techs, energy, HVAC, techs and consultants on a table, but the smaller operations have trouble to do that. But that's exactly where a JNIOR could shine.
- Carsten
Posted by Bruce Cloutier (Member # 9615) on 01-31-2019, 12:57 PM:
We observed the tech at a nearby cinema replace a couple of old Christie ACTs with our Control Panel and a JNIOR. To get "some insights as to how they operate" we would need to get in tight with the ownership and spend time to observe operations. There's not the incentive for them to play along with us until they need a solution for something.
I actually have HVAC background. I was VP of Engineering for American Auto-Matrix (AAM) who in an earlier life were responsible for the conversion of HVAC systems from vacuum signalling to microprocessor control (c1972). We haven't placed JNIORs in the HVAC industry. I wasn't in a position to pursue it and the previous INTEG ownership were not familiar with it. We would need to implement BACnet really to get into that. Not impossible.
We did have conversations with a cinema customer who wanted to use the JNIOR to throttle his air conditioning. While we could program the logic we couldn't help him interface with his HVAC system. He could not provide much information and we couldn't risk him damaging anything (including himself and/or the whole theater). He didn't have the HVAC contractor involved. It is a good concept though. A good HVAC system would detect the added cooling load and adjust. Generally you undersize the system it isn't able to quickly respond to the theater filling up in just 15 minutes. So you need some predictive mode which the JNIOR can do. We would just have to work hand-in-hand with the HVAC system contractor (their form of integrator).
I have a JNIOR on my furnace handling two-stage humidification. Basically the normal evaporative humidifier is insufficient for the size of the house. So the JNIOR kicks in a steam humidifier when humidity needs to catch up. Makes the place really comfortable even like today when it was below zero over night. But I have a Carrier system and had purchased the communications option so the JNIOR can query humidity status.

This isn't running CINEMA by the way. I think the program and details are on jnior.com. I can go verify that if anyone is interested.
Posted by Tony Bandiera Jr (Member # 2365) on 02-03-2019, 12:58 PM:
Bruce, I just sent you an email discussing a few things.
Funny you brought up HVAC, I just finished a BACnet install for one of the major HVAC companies.
I think one of my contacts there could assist in bringing JNIOR into that area.
Powered by Infopop Corporation
UBB.classicTM
6.3.1.2