Sensor Rack Woes - DMX Input Error

Spent an hour on the phone with ETC today (thanks, Justin!). Unfortunately, our troubleshooting still came up short. We were able to determine that the DMX processor is functioning and seeing the crazy data come into it (and sending it out the other side), but something upstream is causing problems. I did patch my controller directly into the rack at the card edge connector, effectively eliminating everything between the controller and the CEM minus the connector itself, so the plan now is to try replacing that connector and scope out all aspects of the system to try and find what is causing it fits.

Spoke with a veteran in the county who told me that at one point they did replace some of the building cabling (DMX) since it was determined that there was a fault in one of the input runs, presumably from water-intrusion. My thought is maybe this issue has come up again and is causing failures in the DAS and rack 1 CEM whenever we do get a lightning hit. The DMX conduit does go under the slab, so water intrusion and lightning damage are possibilities here. Why this damage would not show on the bench in Wisconsin is beyond me, but it might explain why a functioning CEM would turn into a non-functioning one given enough time in this rack (and would transfer to rack 2 when swapped)

It is still very unusual to me that the errors are so predictable. Without fail the same dimmers seem to initiate the same flickering in the same dimmers consistently. To me that says data transfer issue, as maybe the timing is being disrupted somewhere. I don't immediately see how a dirty connector would cause such a consistent problem.

But, I was looking through other threads and came upon this one that @derekleffew pulled from the storied archives of CB to answer someone else's DMX ailments.

I'm wondering if I'm running on one leg or maybe one and a half legs. Speaking with tech support I confirmed that the dip switch PCB is the terminator and that the switches set it on or off (on for the last rack and off for the 1st rack). I'm wondering if I turn off the terminator in rack 2 if it would make the problem go away, and according to the other thread indicating that I'm losing a leg somewhere- possibly at that connector.

Either way, I've learned more about Sensor racks in the past few months than I ever thought I'd want to know. And I really want to plug Justin and ETC in general for their willingness to support a piece of hardware that's over 20 years old. I know a few of the ETC crew post on here and I've never felt anything less than the utmost respect for the level of customer service they offer. You da real MVP's.
 
Lightning and water damaged twisted pair cable could certainly cause some weirdness. There is always an answer and you will find it.

Big props to ETC Support. That's a significant part of what has made the company a leader. Unfortunately, I've run into a few companies that would have given up with "the shrug" a long time ago.
 
So here's an update! We have error-free control! Had a tech onsite this morning and we went direct into the rack again and still saw the same errors as before. He thought to swap the data + and - and it corrected the errors. Working backwards we went to each of the three input stations, looking for a swapped connector. Keep in mind this is swapping right at the rack, eliminating all cable runs.

The input wiring is strange. It's a daisy-chain, but the first one loops back to the dimmer closet on the second pair of the DMX cable. So one cable both sending and transmitting. The next leg goes to the remaining two stations. We'd had issues in the past getting control from the middle input. In these stations, pins 4 and 5 were wired correctly, but at the rack they are cut off. When he initially tried to send data nothing happened. We realized that 4 and 5 weren't terminated and just open so we disconnected those from the input and were able to send data.

No clue why swapping the input pair works like that, unless something in the documentation is wrong, but it's working well. Wondering if the CEM has a polarity switch jumper on it.
 
Very perplexing! Especially with the swapped CEM traveling with the problem. Also, when did this start? I assume that at some point everything worked, so it would have had to start up after some work was done and the conductors got swapped. Lastly, the times I have had a 2/3 swap, pretty much NOTHING worked. Maybe ETC has some programing that looks for data inversion and "handles" it to some extent, and the software version (as well as the extent of the "handling") was different between the CEM units. Glad everything works now.
 
Especially with the swapped CEM traveling with the problem.

That's where I'm wondering if the CEM has a secret menu or hardware switch to swap polarity. Why it ran fine for as long as it did and would only slowly start developing errors? I have no idea. It defies troubleshooting, but obviously there is a reason somewhere. Maybe in three months it will decide it wants to switch back? :confused:
 

Users who are viewing this thread

Back