Industrial Relay Controller Board 32-Channel DPDT

Hello there,

I am reaching out for help regarding programming your relay controller (with USB interface) using Labview.

So far, given our technical need, we have been able to operate our relay i.e. sequential 32 channel turn On and Off, with a simple change (adding for loop with N=32 iterations) in the original file. Please see attached picture (1)
This VI results in about 30 msec switching time (On and Off per relay) which is pretty good. please see attached picture (2)
Now, to promote our technical level, we need to reduce this timing to be less than 10 msec. To that end, I’ve tried to minimize serial communications in its sub-VI by removing the Visa Read block but this causes major disruption to the main switching process. I intuit the source of the cause could be uni-directional communication as a result of removing the Rx (Reciever) command from the cycle.
So, I was wondering if you could help me with a modified programming approach for achieving a faster switching speed. Thank you very much.

Relay on off Relay Addressable status_Mehran_back up2 - (19.6 KB)


We have an article here which goes in depth in optimizing the operational speed of ProXR series relay controllers, I would recommend starting there:

Thank you Travis for the quick reply and for sharing a useful article. I went over the optimizing procedure and changed the settings using the Base station software. However, I measured a toggling rate in the same order as before (~30-32 msec). Do you think I am already at the operating limit or you think of a way to push it further to its limit? thank you very much.

What baud rate are you operating at? Now that you have improved many of the latency issues, you might check into a faster baud rate than the default 115.2K. Also, please make SURE you are using API commands, they should begin with 0xAA and NOT 0xFE. Hope this helps. Also keep in mind there are limits to the switching speed of mechanical relays, so constant rapid switching is not advised with a mechanical solution.

Thanks, Ryan for the reply.
Yes, I use a 115.2 k baud rate. So also I checked two higher baud rates, 230400 and 400k but non of them made difference, i.e. still 30 msec toggling time. 500k had some communication issues.
P.s. yes I run the LabVIEW in API mode.

I am pretty sure our controller has been able process closer to the 10 or 15ms range when working with an embedded microcontroller but I am not 100% certain. It’s been a while since high-speed has been a factor for our customers (nonetheless, I find it a topic of interest!). I’m starting to think we are hitting a wall with either the underlying operating system or the LabVIEW overhead. While I am not certain of this, it might be helpful to remove the relay controller from the equation altogether (keeping the USB interface connected) and just see how fast you are able to send API frames by monitoring the TX line of the communications module. An ideal test would be to connect the TX line to the RX line of the USB module, this way everything is looped back (echoed back). You could monitor the lowest possible latency between the beginning of the transmission and the end of the reception. This would give you a better idea if the relay controller is holding you back or if there really is an overhead in the OS/LabVIEW. It’s been a while since I have done this, so it would be really great to have a record of your results on our community forum! Anyway, I really like this particular topic, so please keep me updated!