Real-Time Measurement and Control
Achievable loop rates when using RS-232
I did some searching and there are several threads discussing max loop rates, but they are either quite old, involve intense control loops, or don't include RS-232 elements.
I need to do some HIL testing on an embedded device at data rates of 1-2 kHz via RS-232 (at 921.6 kbaud). The built-in port won't do that but the expansion RS-232 card can do it.
My app needs to send a short RS-232 packet ("packet A0"), log a response, immediately send the next packet ("packet B0"), grab a response, then wait to send the next packet (A1) until a the next 1 ms multiple. Or:
t=0: Send packet A0, log reply, send packet B0, log reply
t=0.001: Send packet A1, log reply, send packet B1, log reply
...
t=n: Send packet An, log reply, send packet Bn, log reply
Outgoing packets will be pre-generated. Response packets can be decoded after the fact.
Conventional wisdom says 1 kHz is about the max you can do with the RT side of a cRIO. I know I can go faster with the FPGA side, but I don't have a lot of experience there. My worries are:
1- Can I run a 1 kHz loop with multiple send-receive patterns in it reliably?
2- How does the RS-232 port interact with the RTOS? The manual mentions it talks to the FPGA; can I even access it from the RTOS?
3- If I can get to it from the RTOS, are there OS delays that are going to screw up my timing?
Honestly this whole thing could be done pretty easily with an Arduino or something, so it seems like a dual core RTOS could do it, but the timing has me worried. Certainly the FPGA side can do it.
I would first ask how long exactly your commands and responses are. If under 92 bytes total, you may have a chance. But that would be your 1ms time with just transmission time. Then you also have to worry about response time between when the device receives the message and when it sends the response. Likewise, you have to worry about the cRIO's response time as well.
My understanding is that you use VISA to communicate over the serial ports when in the RTOS. My 2 minutes of messing around isn't showing that. I am probably just missing the right setting hidden somewhere.
I just now learned you can use the FPGA to do the serial communications. It looks fairly simple, but you are down to the byte level, which could introduce some interesting situations (ex. arrays must be fixed size).
Command and responses are small. I don't have the number in front of me but IIRC it could be doable at 3-4 kHz. We've already verified communication works with some prototype hardware so I know the total speeds aren't an issue, nor is the DUT's response time.
I thought you used VISA on RTOS's as well but haven't ever tried it. I know in Windows, at least, that VISA obfuscates the VCP interface and hands it off to the underlying VCP driver, which is anything but deterministic- there's no way to know if it decides to start sending NOW, or once it hits a few bytes, etc. One would think there's more info on that sort of thing from NI but I haven't found it yet. The FPGA route coding doesn't scare me TOO much, but the long compile times and some unfortunate bugs from my previous foray into LV FPGA and Softmotion have left a bad taste in my mouth.
@AndyClegg wrote:
I've used VISA on LV RT for RS-232 comms to an external device where the packet / data structure had to be coded (i.e. not using a pre-built driver). It worked fine, but the update rates were relatively slow compared to what you are doing - 40msec (using built in RS232 on a cRIO). It sounds like you want to do two separate reads and two separate writes over the RS232 within a 1msec cycle time, and I would thnk that could be challenging under LVRT.
I would definitely be considering if a slower rate can be used as an interim test situation to verify the data comms functionaliy first, before pushing the speed to 1msec and adding in the complications from that.
Thanks, that's a good data point, and yes that's what I want to do; two reads and two writes per ms. Did the system you use require timeouts or could you read specified numbers of bytes?
We actually have our comms verified already. Right now, I'm bit-banging the output stream over a standard DAQ's digital IO line and collecting all of the returned data in a buffer that I process asynchronously. I get excellent data rates like this, but I have no relationship between send and receive timing. Theoretically I could gain timing info by doing a receive bit-bang DIO as well, but the reply timing isn't really as important as the send timing.
Our normal test runs around 2.5 kHz total packet rate, and I have some headroom to get faster. The "next level" in fidelity is to add in the correct send/receive timing. Right now, I send packet A0/B0/A1/B1/etc at a ~2.5 kHz rate, and would like to send B0 after the response to A0 has come in.
It sounds like I will need to use the FPGA to get this implemented. Not my first choice but ah well.
I was just wondering if some of your 40ms timing was from a timeout-based protocol. Basically, VISA Read terminates when 1- the timeout is reached, 2- the requested number of bytes is reached, or 3- a termchar is read. If your message was, say, 10 bytes long, and you requested 10 bytes, it should return really quickly. 40ms seems high, but not shockingly so. I would've hoped it was less than that. Terminating on byte count or termchar should result in the fastest Read timing, whereas Timeout based timing can vary due to the, well, timeout.
Ohhh, I understand. I thought you meant that was what was achievable in your system, not your polling rate. Thanks for the clarification.
