Aug 142021
 

For real, I’m still shaking my head about this one. The details are weird but it’s a fun story.

The original email we received was similar to so many which have come in before. “We’re trying to control a handful of Grafik Eye 3500 wall panels via DMX. Can you help?”

We’ve done this before and it’s pretty standard stuff. By adding a QSE-CI-NWK-E interface to an existing Lutron system, it becomes easy to talk and listen to their control bus via RS-232. We’ve used this method for many years to easily control Lutron equipment via DMX.

The control syntax is nicely documented, human readable, and not difficult to implement. For example, the command #OUTPUT,1,3,75,0<CR><LF> sets dimmer #3 on device #1 to 75% with a zero second fade time. For ease of use, as per their documentation, <CR><LF> means each command is terminated with the carriage return and line feed characters. So that’s two bytes at the end of each command. No big deal.

In our normal firmware, we generate these commands easily on-the-fly as monitored DMX channels change their various states. Lutron does suggest that commands be sent with a 100mS delay between packets, and we definitely respect that that advice. Years ago we learned that some of their controllers would crash, hard, if we pointed a firehose of serial data at them.

Anyway, we emailed a firmware update file to the customer, in a different country several time zones away. And sadly, after the update, nothing worked. In these situations it’s not unusual to troubleshoot: Is the serial cable correct? Was a null cable installed by accident? Does a null cable need to be added? Are the baud rates equal? Did we get the Lutron device ID numbers correct? And so on and so forth. Usually after half an hour on the phone, or a couple emails back and forth, everything just works.

I suggested that if I were sitting on-site, I’d connect a laptop and serial cable to the QSE bridge and send some control strings manually, just to confirm the syntax was correct, etc. At that time, they didn’t have those tools nearby, but the Lutron system does accept the same commands over the network via Telnet. After an hour, the client replied replied that he could correctly control the lights using this syntax:

#DEVICE,5<CR><LF>,6,14,88 <— That is, dimmer/channel 6 on device #5 set to 88%. 14 is the command for ‘assign level’ in Lutron syntax.

Ok, no big deal. We sent new firmware which generated output like this:

Setting dimmers 1 & 2 on device #1 to different levels.

That is, #Device,device ID, carriage return, line feed, then channel number, set value, value, time, carriage return, line feed. The terminal program, RealTerm, uses those micro-characters to represent non-printable characters. It’s a neat tool and makes it easy to tell if there’s non-ASCII garbage mixed in with a data stream.

No luck! The Lutron system only responded with random errors, which I forgot to screenshot as part of a TeamViewer session.

Finally, we went back to the notes the client took about their known-good control strings. Could it be that <CR><LF> is meant to be eight separate ASCII characters instead of the regular two bytes we’ve been using for years? This was such a strange idea, running counter to every set of Lutron firmware we’ve ever shipped, as well as all of their documentation. Ever. In the last ten years we’ve helped an awful lot of customers with this type of integration.

And thus, a new set of firmware was compiled and emailed. Check this out:

It works. No idea why, because it shouldn’t. We need to open a ticket with Lutron themselves to learn more. But until then, if you need help controlling their equipment with a DMX lighting console, please reach out. We’re always happy to help.

 Posted by at 9:51 pm  Tagged with:
Aug 142021
 
The nIO X Interface

Well, this was new!

Originally, the customer ordered one of our Field-Programmable DMX to RS-232 Bridges. It was shipped and delivered with no issue. Then the support email came:

“For example if I wanted DMX channel 245 to send the hex string A5 08 7A 01 01 00 21 F6 when the channel is at 1 should that string in the txt file look as follows?”

245 1 1|$A5$08$7A$0101$00$21$F6

This, happily, was the correct syntax. But upon further discussion with the customer, we learned that they wanted to control 8 channels of Acuity nLight dimmers via the nIO X bridge. The proposed setup would require several thousand unique control strings. That’s… a terrific pain to program and calculate by hand. And further, our existing firmware doesn’t support more than a few hundred field-programmable commands.

So we offered to automate the entire process and provide a custom firmware personality that they could load in the field via USB. In this case, DecaBox is generating transmitting the proper serial messages live, in real time, based on 8 sequential DMX channels. The start address, of course, is user-selectable using our LCD and pushbuttons. This is much, much more efficient than reading data from an SD card, checking to see if it’s valid, transmitting if yes and dumping if not.

Success!

As a side note, the Acuity control syntax is a bit more involved than some we’ve worked with, but definitely not terrible. The messages are all around 8 bytes long, (in straight hex, so not human readable) and there’s a fancy two-byte checksum at the end of each message

Here’s a screenshot of live output. The messages start with $A5, top left corner. The fourth byte, $01 in this case, means dimmer channel one. $0E is the level, then $25 $F8 are the checksum. At first, DMX channel #1 was run up and down, then later dimmer 2 ($A5 $08 $7A $02…) changes level as well.

Anyway, all is well. Need something similar? Let us know.

DMX Multi-Zone Universe – A White Paper

 Case Study, DMX, RS232  Comments Off on DMX Multi-Zone Universe – A White Paper
Mar 092017
 



Mike Slattery, CTO over at TEKVOX in Dallas, wrote a short white paper about how our DMX Engine can easily control fixtures in multiple physical zones, and shows how the Engine’s ‘mask’ command makes it simple to adjust the look in each zone without affecting surrounding areas.

He writes from a Crestron background, but the principles apply to every major control platform.

Take a look! DMX Multi-Zone Universe [PDF]

 

 

 

 Posted by at 5:47 pm

DMX Control of a Daktronics Venus 7000 Video Controller

 Case Study, DMX, RS232  Comments Off on DMX Control of a Daktronics Venus 7000 Video Controller
Feb 142017
 

Canucks Arena & Video Ribbon. Photo from GLOBETREKIMAGES / 604 NOW FLICKR POOL

This was a fun one.  Turns out, the Daktronics Venus 7000 video controller can be trained to play content based on incoming RS-232 messages.  And, the trusty DecaBox can receive DMX and output all manner of RS-232 content.  When the dust settled, we ended up shipping a somewhat-modified version of our DMX to ASCII firmware.

Here’s the story, straight from the customer:

Recently, I was given this task of creating a lighting board to Daktronics Venus7000 lighting trigger and started out by looking at my relevant device ‘gozintas and gozoutas’ (ins and outs). 

I do not dabble too much in lighting control technology although I knew we are using a Grand MA on PC. I do provide in-house second tier support on our Daktronics LED systems and servers so I also knew that I needed to create some simple ASCII data strings on an RS-232 serial port. 

After asking the Google, I was able to find some articles about converting DMX to serial. This is the link that came up: http://response-box.com/gear/decabox-protocol-bridge-overview/ and this Decabox looked like the exact piece of ‘glue’ needed to convert lighting transitions to a Daktronics triggers. 

I took a bit of a chance and purchased the Decabox, (John Chapman at Engineering Solutions Inc. was also very helpful in that he returned my call and assisted me in determining a data scheme). I went back a to Daktronics Engineering and they were good with John’s proposed data string.  

Shortly after submitting my order, I received the Decabox which John had  pre-programmed and we were ready to test. We were very quickly able to see the appropriate serial data in our Dak server room and soon after got Dak to remotely configure the serial listen port. 

Success! 

This has solved an ongoing issue with playback synchronization of Daktronics content playback, and our house lighting.  We now have consistent and repeatable triggers during our game start opening sequences, whereas before we relied on an intercom countdown to mouse click (which was not very tight!). 

I would not only recommend this device, but also have kudos for John Chapman’s support and timely follow ups to our questions. 

GS | Broadcast Technician
Canucks Sports & Entertainment | February 2017

Need something similar? Contact us and let’s get started.

 

 Posted by at 11:07 pm

Announcing the RS-232 Driven Double DMX Engine

 DMX, RS232  Comments Off on Announcing the RS-232 Driven Double DMX Engine
Oct 102016
 

RS-232 Driven Double DMX Engine

RS-232 Driven Double DMX Engine

This has been shipping for a few months now, as free upgrade to any purchase of an XLR-5 or XLR-3 Engine. It features

  • XLR-3 and XLR-5 outputs in the same chassis.  Each output is controlled by its own drive chip, which means the system has a ‘built in’ 2-output optosplitter.  Currently the outputs are parallel copies of each other.  However, each drive chip is connected to a separate pin in the internal processor, which means that future firmware updates could allow two universes of DMX to be driven independently.  We use only genuine Neutrik connectors.
  • Mounting ears for easy panel mounting.

Today, we’re delighted to also announce a completely updated firmware build (v5.044), featuring the following improvements:

  • The internal dimming engine calculates fade levels 100x per second, rather than the previous 20.  This allows silky-smooth crossfades on LED fixtures.  “This LED strip now acts like a halogen bulb,” said one customer.
  • Built-in RGB color wheel engine performs rainbow color cycles without any controller overhead.
  • Startup scene and timeout delay can be set, so that lighting levels are instantly restored after a power cycle.
  • ‘Group Fade’ command lets multiple channels be set to the same level in a simple way.  ‘Group skip’ option makes it easy to control multiple fixtures at the same time.

The complete protocol description is available in this file: Double-dmx-engine-504.

Note that this protocol simply expands on the features available in our original DMX engine.  Code written for our earlier hardware will still work very nicely.  Check this page for older information.

Want free gear?  If you’re a Crestron, AMX, Lutron, Savant or Control4 guru, we need to talk.

We’re what the IRS would classify as a ‘very small business’, and don’t have resources to tackle this alone.  We don’t have the time or staffing to buy / borrow / rent hardware, then learn the software, to test against each and every major system out there.

Here’s what you get:

  • One RS232 Driven Double DMX engine
  • One 9v DC adapter
  • As much email and telephone tech support as it takes to make you happy
  • Full credit for your work if desired, including links to your website and a quick company bio if you’d like some extra exposure.

And in return, we want

  • A complete ‘plugin’ or ‘module’ or whatever it’s called on your particular platform, which we can publish here on this site and share with other customers.  The module needs to support all of the commands described in the PDF instruction manual linked to above.
  • A sample file / installation / setup which a new user could use for initial testing, before they integrate our gear into a larger system.
  • Basically, your work should include everything a brand-new customer – someone reasonably skilled in their trade, but new to using our gear – would need to get up-and-running, as quickly and painlessly as possible.  Source code, screenshots with annotations, even short video clips would be much appreciated.

Interested? Send email to drivers AT response-box.com.   Please mention your platform of choice and describe your experience in this world.

This is a first-come, first served-per-system sort of project.  We can sneak five or maybe ten boxes out the door before accounting notices and begins to gnash their teeth.

Thanks for visiting our little corner of the Internet.

-John Chapman, President, Engineering Solutions Inc

* New feature requests are always welcome, and existing gear may be easily and quickly updated in the field.  We thrive on that sort of feedback.  If there’s a function we’ve not considered which would make your life even easier, please let us know.

 

 

 Posted by at 3:24 pm