DMX

[etElMadr]

BRX PLC & Serio module are controlling 240 DMX channels. Well, its supposed to be controlling 240 channels. Somewhere north of channel 62, channels are not updating (I haven't figured out exactly what channel). I still have some troubleshooting to do on site, but hoping you can give me some ideas. I haven't found the exact channel this issue starts (the last channel that responds.)

Rereading the Do-More documentation, I need to check the line termination is enabled on the SerIO though I doubt that is the issue. I hope I'm wrong about that. There is a termination resistor on the last DMX slave. There is only one controller on the network. Of the 62-ish channels that are working, they appear to be working reliably.

• Frame Size is set for 512, and of course DMX EnableMaster is Set.
• Using Data View, I've verified values are as programmed and manually written values to the channels without response from the DMX slave.
• I've changed the addressing on various DMX slaves. The issue follows the address.
• I've tried another manufacturer's DMX controller on my test bench DMX slave, and that works thru all channels tested. I don't have a spare BRX PLC & SerIO module on my test bench at the moment to test (both are on order.) I have NOT yet tried that DMX controller on the site's DMX network, and I'm hoping to avoid doing that. If I do, and the other DMX controller works on the site network, what does that mean?

Does SerIO send every channel in the frame size, every scan EnableMaster is Set, regardless of the previous state of the DMX output value? Or does it only send a packet for outputs that have changed?

Is there a way to adjust the lower end of Frame Size to only send a range of channels or a specific channel (i.e. channel 2 or 2 thru 18)? Or, am I misunderstanding the purpose of Frame Size?

[BobO]

Been a minute since I did DMX, so this is from sketchy memory.

DMX doesn't have any form of address mechanism, so sending select bytes isn't possible, but it is possible to shorten the frame. The FrameSize struct memory does govern the frame length when mastering, and indicates the size received when a slave.

I *think* the module is continually sending frames as long as it is enabled. New data is published to the module every scan, but I think only 64 bytes per scan, so it takes up to 8 scans to update the entire frame. I believe the driver syncs with the module by resetting the publish counter when the frame counter increments. DMX frames are pretty slow compared to a BRX PLC scan (~22ms), but it now occurs to me that if your PLC scan was slow enough the module might not get updated fully every frame. Not sure how that hasn't been an issue for some, we might need to make a provision to push more data per scan at the expense of a scan time bump. Just curious, but what is your scan time?

I can dig more, but it would require me getting down into the details in driver/module code.

[BobO]

It's a bug. Surprised this hasn't been reported until now.

Faster scan will work around it. For full 512 byte frames, total time for 8 scans can't exceed about 22ms. We'll have the fix in 2.9, which should be out this month. Were hoping for last month, but stuff. 

[etElMadr]

Don't hold me to this, but I think the scan time is running a tad under 20ms right now.

As I understand it, I should be able to lower the FrameSize to 240. If I understand what you're saying, a FrameSize of 240 will take just under 4 scans and total scan time of those 4 scans needs to be under 22ms. At 20-ish ms per scan, thats not going to happen. But a smaller FrameSize should also process faster?

For start-up, I can probably reduce the scan time by reducing the data set this PLC needs to churn through. In production, this thing needs to scan through a lot of data so reducing the scan time isn't going to be easy (or maybe I just need to get creative.) Fingers crossed 2.9 comes out soon.

[BobO]

Don't hold me to this, but I think the scan time is running a tad under 20ms right now.

As I understand it, I should be able to lower the FrameSize to 240. If I understand what you're saying, a FrameSize of 240 will take just under 4 scans and total scan time of those 4 scans needs to be under 22ms. At 20-ish ms per scan, thats not going to happen. But a smaller FrameSize should also process faster?

For start-up, I can probably reduce the scan time by reducing the data set this PLC needs to churn through. In production, this thing needs to scan through a lot of data so reducing the scan time isn't going to be easy (or maybe I just need to get creative.) Fingers crossed 2.9 comes out soon.

Reducing frame size will make it worse, since the frame transmission time also reduces.

Move the data processing into a task. If you are using loops, you can adjust the .TimeSlice value to balance total processing time against scan time. If you aren't using loops, insert YIELD instructions to break up the task over multiple scans.

[etElMadr]

OK, so I think you're saying that the module is sending the frame before the PLC can fully update it (64 bytes a scan). Once sent, the driver tells the PLC to start from the beginning. At 64byte per scan with about a 20ms scan and DMX transmit every 22ms that makes sense why I'm seeing only the first 60-ish channels update.

I understand what you're saying about yielding / .TimeSlice, and I'll consider that as an option but I'm concerned that may cause other issues. There may be some other ways I can reduce scan time. So, I need to target a scan time of 2.75ms (22ms/8)?

Could I toggle .EnableMaster in order to allow the PLC to update the entire frame? Something like Off for 8 scans, then On for 22ms?

[BobO]

OK, so I think you're saying that the module is sending the frame before the PLC can fully update it (64 bytes a scan). Once sent, the driver tells the PLC to start from the beginning. At 64byte per scan with about a 20ms scan and DMX transmit every 22ms that makes sense why I'm seeing only the first 60-ish channels update.

I understand what you're saying about yielding / .TimeSlice, and I'll consider that as an option but I'm concerned that may cause other issues. There may be some other ways I can reduce scan time. So, I need to target a scan time of 2.75ms (22ms/8)?

Could I toggle .EnableMaster in order to allow the PLC to update the entire frame? Something like Off for 8 scans, then On for 22ms?

Your understanding is correct, but the enable won't help. The driver doesn't push data when disabled.

[etElMadr]

Was able to get the scan rate down, and that resolved the issue. Thank you for you attentiveness to this matter!

[etElMadr]

Were you able to address this issue in the 2.9 release? I didn't see it in the release notes.

[franji1]

Were you able to address this issue in the 2.9 release? I didn't see it in the release notes.

Yes.  The firmware release notes are online in the firmware update section since firmware gets updated independently of the software:
https://hosteng.com/HW-Products/DM1/BX-DM1_RevHistory.htm

[etElMadr]

 

[BobO]

Actually, it appears that this fix didn't get into the release notes, but yes, it was fixed.

[etElMadr]

With 2.9, are you now updating the entire 512 bytes in one scan?

[BobO]

With 2.9, are you now updating the entire 512 bytes in one scan?

No. Just fixed the issue that was causing the problem.

[etElMadr]

So it still writes 64k per scan, therefore multiple scans to update a frame? Or, is it that the DMX driver is building the frame 64b over ~22ms frame time?

I'm trying to figure-out how to update channels simultaneously. I'm currently writing to one $DMX register, then incrementing to the next. This results in DMX channels turning on/off in a sequence. Next, I was going to try to "build" a 512 byte frame buffer in V-memory, then COPY/MOVER it to $DMX at the end of last scan. I'm hoping that has the effect of turning on/off all DMX channels simultaneously. 

Without yielding, scan times are about 30ms (that's after I shaved off about 18ms thru code optimizations).