Using the PXIe-8431/16 on LabVIEW RT : how to ensure that the frames are sent within my RT loop timing ?

[CyGa]

Hi,

I'd like to use the PXIe-8431/16 with a controller running a RT OS (not sure yet between PharLap and LinuxRT).

The goal of the RT application is to sent burst of data on RS-485 ports with a specific timing between frames.

Is it possible to do so with that board ?

Am I ensured that, as soon as I write into a VISA function, the burst will be pushed on the physical bus ? (or at least within my loop timing )

What would be the typical latency between the SW write and the actual burst being sent on the phycial bus?

Cyril

[TheEngineeringBear]

This ended up being a fun dive.  I think you're going to have to test it.  Most likely the best answer is after testing you are going to notice a floor for the lowest latency and then an average latency which will be more dependable on an RTOS communicating with RTOS if passing data back and forth.  I know the answer to this question for a network port, but not for serial.  I'm sure it's faster than network due to the reserving of the hardware resource.

Reference: https://lavag.org/topic/15772-troubleshooting-latency-on-the-serial-bus/

Good overview of testing latency.  Linux RT going to have more control and can dive into setting the latency.

[CyGa]

Hi Ben,

Thanks for the explanations!

I'll dive into the Lava thread !

But in regards to the 8431/16 cost, and the customer I'm working with on this, I would have expected NI to do the rest and benchmark!

I'll go through the support, and see what we can do from there!

Thank you!

[rolfk]

Benchmarks are usually fairly useless and what you are trying to do is likely doomed. Even realtime is not instantaneous. Instead it just guarantees  that no important tasks are ever left behind unserved because of other tasks trying to monopolize the system. If a system guarantees that any request will be handled within one second it is absolutely realtime. Windows can’t guarantee that ever although it is likely that it will respond within that time, but not guaranteed. If you perform the action in a kernel space driver, it’s more deterministic but that is a tad complicated as writing kernel drivers is a very thorny business.

You haven’t specified what “as fast as possible” is in your case. Rule of thumb here is: >10ms will almost certainly work, <1ms definitely not. For that you need direct hardware control, aka FPGA!

[CyGa]

Hi Rolf,

Thank you for your input !

I understand the concept of RT OSes, so I completely agree with you.

To give more insight I'm working on a bus requiring scheduling. The system will run on LinuxRT.

If I set a loop to run as fast (or twice as fast) as the smallest schedule time, I want to understand :

1. What the max payload I can send within my loop time (nb bauds of course set to be able to send that payload with a loop time)

2. What the typical latency between the moment I VISA Write and the moment the first bit is actually going on the physical bus.

And we've a got a 6683H to keep time alignment.

According to this I should be able to see if the board + RT loop is enough to enter within the transmission specs.

Otherwise yes we'll go with FPGA. The protocol here is divided in bursts of 8 bits + start / stop bits. So it fits well with a UART based communication.

So we need to understand if doing VUSA R/W + RT loops is ok or if we need to indeed go with FPGA.

The cost might be divided drastically with the RS board solution.