For those interested in my Dolby DSS server plugin. It is attached here. In the zip file is the plugin and both pdf and htm versions of the help file.
-
-
Very slightly updated version to the DSS Server plugin(minor internal change, no functional change).Comment
-
One issue that I'm not sure if Steve has covered in this thread is that of event logging. I didn't pay it too much attention either until a few months ago, when I had to troubleshoot an issue with API commands to external devices not always working.
The core generates an event log, which can be seen in the core's web UI as so:
image.png
However, by default, it doesn't record much. In the above example, only the entries in the "connect" category (which record when an iPad used to run the UCI connects to and disconnects from the core) would be there if I hadn't added logging functions for the others to the design.
Adding those functions can be done in one of two ways.
The first is by adding the "Event Logger" component to your design.
image.png
In this example, house lights are being controlled using a Doug Fleenor RS232 to DMX interface. The buttons on the UCI (bottom left) are driven by a selector (in order to produce a radio button effect whereby only the active setting is illuminated), the output of which goes to a plugin component that sends commands to the actual device via RS232. The inputs to the plugin pass through it to a trigger combiner, which triggers the actual creation of a log entry.
The event logger can include up to two "arguments" - fields that are populated from some place else. In this example, they are taken from the output field of the selector. The one second delay is to enable the field to populate (I found through trial and error that without it, the previous setting change would be recorded). So in this example, if the user pushed the 50% button, a log entry would be created that reads "House light dimmer set to 50%."
The severity category has three options: normal, warning, and error. The effect of these is that the log entry is preceded by either a green check mark (as in the screenshot above), a yellow warning triangle, or a red X, as so:
image.png
The above example shows why taking the time to include log entry creation in your design can be useful. We had an ongoing issue at this site with the core's GPI receiving false alarm fire alarm signals, and had to establish whether it was a fault with our core or the building's alarm panel. We found a ton of log entries in which the alarm activated and then cleared between one and four minutes later, which is consistent with the alarm system going into the silent phase and then being canceled when a security guy got to the location of the sensor and determined that there was no fire. That enabled me to suggest that the GPO line from their panel to our core had been incorrectly configured to trigger for the silent phase, not the actual alarm phase, and for them to fix it.
The other way to create event log entries is in block controller or Lua scripts. Here is an example:
image.png
You'll see that there is a "log error" entry for when the fire alarm signal is actually received, but if the user pushes the "simulate alarm" button (which I added in order for them to do a weekly test of the alarm stop functions without affecting the rest of the building), it just creates a "log message."
It has to be admitted that adding event logging functions adds time and complexity, both to creating designs and maintaining them. The payback is that you'll have an event log that makes troubleshooting a lot easier, both for the end user and you.Comment
-
Thanks Leo! That is awesome. I have not covered adding one's own log entries. It is definitely a good value when one is trying to track down the source of a problem. It also means that one does not have to build their own data storage into a component (and ensure it does not become a memory leak) for keeping track of such things.Comment
-
Is anyone using the Eprad eCNA automation? I sure am. We have two primary automations within the USA (and probably elsewhere in the world, particularly where Regal or AMC may have locations) that have have a degree of pevelance. The Integ JNIOR and the Eprad eCNA. Doremi and GDC servers have made special accommodation for them (as does the DSS line of Dolby servers, somewhat, if you look in their logs). The Integ JNIOR has an official plugin that is in Asset Manager/Library (currently version 2.1). Thus far, there hasn't been a plugin for the Eprad eCNA...until now.
image.png
This is NOT an Asset Manager/Library plugin so it shows up in the "user" section.
The plugin allows quite a bit of interaction between Q-SYS and the automation as the inputs and outputs are supported as well as all of the Macros, RDIs (Remote Devices...aka Ethernet Controlled Devices) and even their "Programs" which harken back to how cinemas have automated shows back in the film days. So, you can set up a show that is looking just for a single "cue" to advance it through the show.
So, why an automation when you have something like Q-SYS? Because it can be the "fingers" that a DSP based system lacks (e.g. relays or Opto-isolated inputs). Because the Eprad eCNA is THE most reliable piece of equipment in any theatre (seriously, their service record is as high as I've ever seen anything). It will outlast any Q-SYS Core, any server, and most any other system. So, when you change your server, no problem, load an RDI that works with the new server and you don't have to rewrite the world. They make your system brand agnostic. We have sites that have, under one roof, NEC and Barco projectors, Dolby and USL sound processors, Dolby DSS, Dolby IMS and GDC servers. They all fire the same cues and the Eprad automation takes it from there because the end result needs to be the same.
A purpose built automation for cinema is also going to handle the "typical" tasks a cinema will need without needing to re-invent everything from scratch. Clearly, there are some layovers from its history (e.g. Slide Projectors) but nothing stops you from repurposing such a dedicated flag to something you use today. Plus, with your UCI, you can put any label on any button or function that you want.
In Properties you can set up how many RDIs or Macros you are using or want to show. You can also set up so poling timers to choose how fast you want it to update its display versus how much you are going to affect the web UI of the eCNA itself (if we're pulling information, it will be processing that rather than drawing a web page of its own web UI). Adjusting the timers allow for a good balance. The default timings seem to strike a good balance.
image.png
The Set up Page is where you put your IP address and which TCP port you are going to use. This is one of the eCNA's weaknesses. It only supports one client per TCP port (at a time). Typically, cinema servers that are eCNA aware will set up Port 13000 as the port it sends commands to and port 13001 to be the one it receives messages from. So, we set up the plugin to default to 13002 but it is configurable.
image.png
The output page is the business end of things. The buttons show the status as well as allow setting the flags/states.
image.png
The inputs page is where you can monitor any of its many inputs.
image.png
Macros may be executed via any of the appropriate macro buttons. I left the legends off of the buttons so you could drag the button off and then apply your own name that makes sense for what it is doing.
image.png
Likewise, for the RDI buttons, you can apply your own names to the buttons based on what that button will do.
image.png
For those using a stepped program, the Program page provides for state/stop/cue and monitoring.
image.png
All of the relevant input/output control pins are available to integrate as you may need.
image.png
Attached (if all of this works) will be a zip file that has the version 1.0.0 of the plugin (and it will evolve over time but I don't have much of that, at the moment), a help file in htm format as well as a pdf of the help file.
Last edited by Steve Guttag; 06-27-2026, 11:12 AM.Comment
-
Minor internal fixes to the Eprad eCNA plugin.Comment
-
Yeah, Strong had a deal with Eprad for decades. They were selling them in the film days, starting with the "CPA-10," which was an Eprad Ultimation 2000 by another name and color scheme. They then evolved that into the CNA100 and CNA200. Then, due to Regal's wantings, they made the CNA150. Then, as the new-fangled networking stuff came into being, they added the "e" to those automations (we're still in the film era). As DCinema happened, they worked on getting the eCNA200 DCinema ready and Eprad continued firmware updates on it through the mid-2010s. For digital cinema, the dedicated unit was the eCNA-10, which was the eCNA-200 without the large LCD screens and with I/O boards consistent with non-film though it WILL work with the Film I/O boards, if you had them and were upgrading a system. There's nothing to stop one from turning the projector, exciter and other film-centric relays into something else or to have a film and digital cinema system all running off of the one unit. The eCNA-10 can support the Film I/O boards and the other ones as well. They then came out with the lower-cost eCNA-5 which go rid of all of the displays and started you with a different I/O board that was more general purpose. Configure the I/O board based on what you want. There are 16 relays...call em what you want.
So, if you have AMC or Regal theatres in your country, it is quite possible you have Eprad eCNA automations. If you don't odds are you don't. Who would have imported them? Who would have known to import them or choose them over another automation? Plus, the eCNA-5 is, roughly, double the cost of an Integ JNIOR. And, if all you are doing is clicking 2-4 relays to switch dimmers or something else that you want relays for, the Integ is lower-cost and smaller and clearly is well backed by Bruce and company. The Integ is also more adaptable as it is an industrial controller that happens to be used in Cinema. Conversely, the eCNA is a cinema automation that happens to be useful for non-cinema. The JNIOR is programmable, the eCNA is configurable.
I stand behind that nothing is as reliable as the eCNA automation and it goes into nearly every one of our screens. It does have shortcomings. It has shortcomings as it is purpose built. If it doesn't do it, it doesn't do it. If it has to talk with devices that want passwords...well...you might be able to fake it (set up a macro to give a timed response...I did that for a Lutron Grafx EYE). If it becomes an issue, I'll put a request into Eprad for an update.
But I use it to control masking (most of our clients still have them), Curtains (some still have them), dimmers, projectors, servers (power control), exhaust, sound systems...you name it. Again, it is the great equalizer...regardless of what server or projector or sound system they have, I can use the eCNA to harmonize all of the cues. It is going to outlive the things it talks to.
If you get a shot to use one, I highly encourage it. As long as they keep making them, I'll keep using them.Comment
-
Of course what you are seeing is the reliability of solid state electronics and especially those running at MHz clock rates. The GHz products generate a lot of heat and, yes, that can be managed. Regardless of that it does impact the expected life of the silicon. I have GigaByte PC cubes that are dropping like flies these days. They just go dark. As near as I can tell it is a form of heat exhaustion. Those should have been better cooled I suppose.
Now the software/firmware plays into your reliability experience. JNIOR and Eprad are purpose-built firmwares developed by experienced individuals. That cleanroom build methodology leads to ultra-high levels of reliability. The GHz systems assemble a generic OS and numerous existing libraries of services each independently proven. Each requiring configuration in creating balance in the overall system. Those end up resetting the hazard function with each release. You then experience bugs and deal with constant updates all of which impact your opinion of reliability.
Then there are the short product life cycles that we all see.
The JNIOR really is a general purpose Edge Controller while Eprad provides a Cinema focused tool. We add the cinema.jar application that makes JNIOR configurable in a way that you folks are all accustomed to. But, yes, you can program it to do just about anything. That limited possibly by input and output capabilities. I have one taking VoIP phone calls from an alarm system. That receives analog Contact ID reports, transmitting the proper handshake and acknowledgement pulses while receiving the DTMF messages. The Java program then finds each DTMF pulse in the communication and using a Goertzel Algorithm decodes the digits. That program then signals the owners by email and notifies through a Signal API. That's about as far as you can get from cinema. A fun application to develop however.
In the current environment I have to feel for Eprad and their manufacturing. They use more steel, more connectors and more manual labor in those. That, today, is costly. There is also the availability of components, especially memory, that is really challenging us. Recent relay prices have doubled in price. No fun.
Strong moves a lot of JNIORs these days. A lot go into AMC theaters. I don't know about Regal. I have had a few conversations with Regal people enthusiastic about low-cost Series 3 JNIORs on the market.
Comment
-
My most recent thermal experience has been with DDR5 ram sticks. I don't think I'll ever buy Crucial memory again (at any price and they are, typically at the top tier of the models they make). I had computers crashing left and right with them. Swapped in some Amazon special "A-Tech" sticks...problem solved. Stress test it for hours...no problem...cool to the touch even. Same speed RAM, same size, same everything.
I don't know how TL/Eprad is doing in their non-cinema industries but I suppose okay. They've always targeted smaller production custom design/build sort of manufacturing. We have not had problems getting products from them (automation or dimmers). They did, semi-recently, rev the CPU board (to version 2), at least partly at my request, for features (which, effectively doubles, if not more, things like Macros, RDIs, and the number of instructions).
I don't want to get too far off topic on this thread. It should be mostly about Q-SYS rather than a particular manufacturer. Eprad has come up here due to the plugin. Not vice-versa. Furthermore, part of the plugin discussion is that the use of AI (Claude) was key in both of the Dolby DSS Server and the Eprad plugins. They were the very first time I ever tried it. The speed at which i've been able to orchestrate the plugin, adding features or making the user experience better (by my perception) has been pretty remarkable, in my opinion.Comment
-
Comment
-
Updated DSS Server plugin (1.0.3). Just some bug fixes. Of note, it was discovered that the Unselected and Stop "LEDs" could be active at the same time. Also, minor cosmetic change to the Manual/Scheduled buttons. The Help File no longer needs an accompanying CSS or extra Fonts. It should look decent in typical browsers (and there is a PDF version too).
DSSServerv1_0_3.zipComment
-
-
I've upped my Eprad eCNA plugin to 1.2. The main new feature is that it now supports/controls an Eprad dimmer (QDC-400 series) with full zone (16), channel (16) and offsets.
image.png
I'm putting my plugins and user components...as they come...up on GitHub. That is probably a better hosting site than here, for such things.
Comment
Comment