Pathway PWREP RDM Turn off RDM

NJLX

Active Member
Anybody have any idea how to get RDM to turn off on a Pathway PWREP DIN P4 RDM? I have some fixtures that really don't like RDM, and just turning it off on the gateway isn't cutting it. (Fixtures work fine plugged straight into the gateway, but get all flashy on the opto splitter)

I get this error when I try to change the "DMX Personality" on the PWREP over RDM from pathscape:
[Nov 2, 2023] [10:57:42] QString::arg: Argument missing: "RDM GET: NACK: 0x00e0x: %d" , 4
 
Sorry for the problem Nate. The old units had a switch to turn off RDM, but the truth is, it never did. The property you're trying to set is read-only. And again - the actually is no way to TURN OFF the RDM. This was historically bad documentation. The unit is not that clever, it actually works with little to no latency. If a 0xCC RDM start code comes in, it just turns around the UARTs and waits the prescribed amount of time, then normalizes the flow of bit-wise data.

Quite a long time ago, we found that some badly behaved fixtures don't MUTE when asked after discovery and cause chatter on the line. This could be your issue.

In Pathscape, after you discover on the port with the Repeater, please report the version number. Do you see v1.7.7?
1698940423090.png


Another test you may want to try is to take one of the flashing fixture and address it above 64. No RDM packets are longer than that, so this might be an interim solution.
 
Sorry for the problem Nate. The old units had a switch to turn off RDM, but the truth is, it never did. The property you're trying to set is read-only. And again - the actually is no way to TURN OFF the RDM. This was historically bad documentation. The unit is not that clever, it actually works with little to no latency. If a 0xCC RDM start code comes in, it just turns around the UARTs and waits the prescribed amount of time, then normalizes the flow of bit-wise data.

Quite a long time ago, we found that some badly behaved fixtures don't MUTE when asked after discovery and cause chatter on the line. This could be your issue.

In Pathscape, after you discover on the port with the Repeater, please report the version number. Do you see v1.7.7?
View attachment 24958

Another test you may want to try is to take one of the flashing fixture and address it above 64. No RDM packets are longer than that, so this might be an interim solution.
Thanks for the response Rob.

I am seeing 1.7.7 on the Repeater.

Most of the flashing fixtures are addressed above 64, so sadly that won't help. It does seem that if they're plugged into a port with RDM disabled, no flashing; plugged into a port with RDM enabled and then later disabled, flashing continues until DMX is unplugged/replugged. I'd believe the not muting after discovery theory.
 
What are the errant fixtures?
Aputure Nova P600c. I tried updating firmware on some of them, with the errant chatter theory I'll now go through and update firmware on all of them.
 
Aputure Nova P600c. I tried updating firmware on some of them, with the errant chatter theory I'll now go through and update firmware on all of them.
For those following along at home, this did not fix the problem.

1 of my DMX chains is fine off an opto splitter out(3 aputure, 8 other lights), 1 is fine off an opto thru but not an opto out(3 aputure, 8 other lights), and 1 is only fine directly off the colorsource console(6 aputure, 9 other lights).

All non-aputure lights are either fiilex q5 or chroma q space force onebytwo.
 
This is very odd that you have better results on the THRU than one of the OUTs. Check to see if you have AC leakage from Data Common to Earth? Something's screwy with your downstream wiring. Sadly the next move will be climbing a ladder and removing fixtures until you find the nasty one.
 
This is very odd that you have better results on the THRU than one of the OUTs. Check to see if you have AC leakage from Data Common to Earth? Something's screwy with your downstream wiring. Sadly the next move will be climbing a ladder and removing fixtures until you find the nasty one.
That's what led me to RDM as a culprit. Could certainly be something else though.

There's a voltage differential of 3-6v AC between Data Common and Earth(Induced voltage or leakage from a fixture, not hard power). It seemed strange to me, but the Gateway and optos aren't grounded - they just get + and - from a din rail mounted Low-Voltage Power Supply. The installed gear was out of scope for me though - it was installed by one of the other companies in our area.

For the long string of fixtures that works fine off the console, the first half worked off an opto thru, but the second half flashed on any port except directly out of the console. The string of fixtures running off an opto out ended up getting split into 2x opto outs - once the 8th fixture was connected, all the aputure lights at the beginning of the chain started flashing.

If it were just one DMX chain causing issues, I'd say it's *a* bad fixture, but with it being all of them I can only blame either Aputure as a manufacturer or the install wiring(which seemed fine from my troubleshooting).


All this just makes me continue to say, don't buy Aputure products if you're planning to use them with DMX. They work great in standalone though.

(Note - all opinions mine, they do not represent my employer, though they do affect the recommendations I make to my employer.)
 
Sux for you. Sorry.
Page 6 of this document has some good trouble shooting tips you can do with a multimeter.
That's a nice list - I have a DMX tester that I typically use for all the continuity testing. Didn't have it today, and didn't think about testing all the combos with a multimeter, since it was just 1 manufacturer of light that was flashing, at multiple positions in the chain. I'll check those on my next visit though, at least to satisfy my own curiosity and verify that I've done all I can.
 
  • Like
Reactions: Rob

Similar threads

Users who are viewing this thread

Back