LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Sub-ms timing in FOR loop

Hi!

 

I'm developping an application that communicate with multiple devices (1 to 4) via a CAN bus by sending commands (set speed/acceleration etc) and requesting telemetry (get speed/acceleration etc.) in a timely manner.

Given the amount of TM to receive and other factors, I'd need to go sub-milliseconds to send requests.

For now the only suitable solution I could find would be to use a FOR loop with a High Resolution Polling Wait.vi inside, and I get an array with all my commands that I send one after the other to the bus.

 

VinnyLaTaupe_1-1637843663195.png

(In reality I am not sending it directly to the Visa but to a specific queue)

I would share my code if I could, but that would be complex to pack it up in a moderate solution.

 

I also thought of a Timed structure but if I'm not wrong I need a RT target for that with a suitable processor.

 

Is that really a suitable solution? From what I read it does look like so, but maybe I missed something? (This thread and this one which are both rather old)

Apart from CPU usage, what should I consider when we go in that order of magnitude?

How can I plan the CPU load? My application is meant to run on other targets as well.

 

Thanks in advance.

Best,

Vinny.


PS:
1. The devices are supposed to (development requirement) generate an answer under 50µs

2. The CAN bus is handled by a USB adapter: Baudrate=3Mbps // 8databits // 50ms timeout (considering to change it to 1ms)

0 Kudos
Message 1 of 7
(176 Views)

Hi Vinny,

 


@VinnyLaTaupe wrote:

For now the only suitable solution I could find would be to use a FOR loop with a High Resolution Polling Wait.vi inside,

 

Is that really a suitable solution?


As long as you stay with your Windows computer and that simple approach that solution will be your best bet! If this is suitable for you you need to decide on your own…

 

Usually the CAN message timing is offloaded to hardware (or kernel device drivers): it seems your CAN interface doesn't allow that option. The last time I needed to send CAN messages with a strict timing regime I was working with a cRIO+FPGA+NI9853, which was rather easy to implement…

 


@VinnyLaTaupe wrote:

2. The CAN bus is handled by a USB adapter: Baudrate=3Mbps // 8databits // 50ms timeout (considering to change it to 1ms)


AFAIK the USB bus is not recommended for rather strict timings in the sub-millisecond range…

Best regards,
GerdW


using LV2016/2019/2020 on Win8.1/10+cRIO
0 Kudos
Message 2 of 7
(147 Views)

Hi Gerd,

 

Thanks for your reply.

 

This application will definitely stay on a windows environment, no problem there, the windows version might be an issue though (my company still uses some computers running under XP ... But that shouldn't be the case with this application, I'll put a condition on this.)

 


@GerdW  a écrit :

Usually the CAN message timing is offloaded to hardware (or kernel device drivers): it seems your CAN interface doesn't allow that option. 

 



Could you explain a bit more what you mean here?

To provide more details from my side as well:

I'm using a 4NGalaxy USB TO CAN 2.0, their website and docu is pretty terrible but it does the job somehow. The USB port is configured to 3Mbps, the CAN bus to 1Mbps.

We have decided to not use the .dll provided but to create our own Library using VISA (still not sure this is a good idea though).

 

 


@GerdW  a écrit :

 

AFAIK the USB bus is not recommended for rather strict timings in the sub-millisecond range…


So I have an error margin (which I will have to test) but as long as I don't have messages overlapping from one device to another I should be fine. The monitoring isn't that time critical as in "I need data to be sent and received at precise time" but more as in "I have a lot of data that I need to pass trhough, so better be fast". I don't want to overload neither the coms bus, nor the computer though, so this will be a bit of a try and error situation I guess.

 

I'm still unsure about how the final solution will look like. This one looks working fine for one device, let's see when I'll have more to put on the spot 🙂

0 Kudos
Message 3 of 7
(128 Views)

Hi Vinny,

 


@VinnyLaTaupe wrote:

 


@GerdW  a écrit :

Usually the CAN message timing is offloaded to hardware (or kernel device drivers): it seems your CAN interface doesn't allow that option. 

 



Could you explain a bit more what you mean here?


"Better" CAN ports can handle certain type of CAN messages on their own, to minimize CPU load. It seems (from a quick glance at the manual) your device doesn't allow that - read on your own or ask the support…

 


@VinnyLaTaupe wrote:

To provide more details from my side as well:

I'm using a 4NGalaxy USB TO CAN 2.0, their website and docu is pretty terrible but it does the job somehow. The USB port is configured to 3Mbps, the CAN bus to 1Mbps.

We have decided to not use the .dll provided but to create our own Library using VISA (still not sure this is a good idea though).

 

 


@GerdW  a écrit :

 

AFAIK the USB bus is not recommended for rather strict timings in the sub-millisecond range…


So I have an error margin (which I will have to test) but as long as I don't have messages overlapping from one device to another I should be fine. The monitoring isn't that time critical as in "I need data to be sent and received at precise time" but more as in "I have a lot of data that I need to pass trhough, so better be fast". I don't want to overload neither the coms bus, nor the computer though, so this will be a bit of a try and error situation I guess.


It would have been nice to have that information in the first place…

Talking about "3MBaud over USB" is quite nonsense - it is of no interest and matter to you! All that is handled internally by the driver for that converter, all you do is to open a "virtual" serial port… (See chapter 2 of the "USB commands" manual.)

 

When you want to send "as fast as possible" you don't need any timing at all. It also doesn't matter when you wait for some 10s of µs (with a horrible jitter on WindowsOS) when the communication from your computer to the converter is handled via a virtual COM port over an (kind of older) USB2.0 connection. A quick calculation on CAN message transfer speed gives:

 

 

 

 

64 bits payload + 32 bit ArbID + ~16 bit other stuff = 108 bits per message
-> 108 bits / 1MBaud = 108 µs per message

 

 

 

 

Why do you even want to implement some "sub millisecond wait on non-realtime Windows OS" when you can simply stuff 10 messages per millisecond into the device message buffer???

 

Recommendation:

Please put ALL relevant requirements onto a sheet of paper. Then discuss the actual implementation (or even discuss which hardware to use)…

 

Edit:

Please read also chapter 5.2.1 of the same manual: your device seem to be also limited in the number of messages it can receive from your computer and handle internally. (I would go this way: send some messages, wait for 1-5ms, send the next mesaages, wait, and so on…)

 

Edit 2:

The manual lists Windows7 as most modern OS for the driver (while the website mentions Windows8). It seems the manufacturer doesn't care about using that converter on modern computers/OS, so why do you care?

Best regards,
GerdW


using LV2016/2019/2020 on Win8.1/10+cRIO
0 Kudos
Message 4 of 7
(114 Views)

Hi Gerd,

 

Thanks for the details. I should point out that I'm still in a big learning curve here, not only for CAN communications (even though I worked a bit with CANOpen in the past) but with communications in general 🙂

 


@GerdW wrote:

"Better" CAN ports can handle certain type of CAN messages on their own, to minimize CPU load. It seems (from a quick glance at the manual) your device doesn't allow that - read on your own or ask the support…


Didn't know that. What kind of messages are you refferring to? Pre-loaded messages that are sent whenever nothing is communicating?

 


@GerdW wrote:

It would have been nice to have that information in the first place…

Talking about "3MBaud over USB" is quite nonsense - it is of no interest and matter to you! All that is handled internally by the driver for that converter, all you do is to open a "virtual" serial port… (See chapter 2 of the "USB commands" manual.)

 


In this chapter 2, they do say to "Set COM port to 1200 Baud 8N1 (this corresponds to an external baud rate of 3.000.000 bps
Why is it non-sense? The converter can be programmed to communicate with different parameters on the CAN bus (Baudrate, ID (11 or 29bits format), Acceptance Code and Mask); 

But when I open the VISA session I have to enter the COM port parameters, no?

VinnyLaTaupe_0-1637917432366.pngVinnyLaTaupe_1-1637917444768.png

 


@GerdW wrote:

A quick calculation on CAN message transfer speed gives:

64 bits payload + 32 bit ArbID + ~16 bit other stuff = 108 bits per message
-> 108 bits / 1MBaud = 108 µs per message

 


Sounds about right yep, that's what I took for my calculations.

 


@GerdW wrote:

Why do you even want to implement some "sub millisecond wait on non-realtime Windows OS" when you can simply stuff 10 messages per millisecond into the device message buffer???

 


hmmmm because I didn't think of it. I also don't know (yet) how the device would react to this, I will have to investigate this option!

 


@GerdW wrote:

Recommendation:

Please put ALL relevant requirements onto a sheet of paper. Then discuss the actual implementation (or even discuss which hardware to use)…

 

Edit:

Please read also chapter 5.2.1 of the same manual: your device seem to be also limited in the number of messages it can receive from your computer and handle internally. (I would go this way: send some messages, wait for 1-5ms, send the next mesaages, wait, and so on…)

 

Edit 2:

The manual lists Windows7 as most modern OS for the driver (while the website mentions Windows8). It seems the manufacturer doesn't care about using that converter on modern computers/OS, so why do you care?


So that's actually my difficutly here: everything is being developped all together and tested asap. So requirements are evolving.

For the HW part, I would love to go with something more sophisticated, but budgets seem to not allow it ...

 

I will try to implement your suggestion of sending 10 messages at a time on the buffer, wait for the answers and send again etc.

I'm just not sure yet howthis will work on the bus (devices answering at the same time etc.)

But for now we have only one device so messages conflicts shouldn't appear.

 

Vinny.

0 Kudos
Message 5 of 7
(81 Views)

Hi Vinny,

 


@VinnyLaTaupe wrote:

Didn't know that. What kind of messages are you refferring to? Pre-loaded messages that are sent whenever nothing is communicating?


I was thinking about CANopen heartbeat or PDO messages, which are transferred repeatedly…

 


@VinnyLaTaupe wrote:

In this chapter 2, they do say to "Set COM port to 1200 Baud 8N1 (this corresponds to an external baud rate of 3.000.000 bps
Why is it non-sense? The converter can be programmed to communicate with different parameters on the CAN bus (Baudrate, ID (11 or 29bits format), Acceptance Code and Mask); 

But when I open the VISA session I have to enter the COM port parameters, no?


You open a virtual COM port to your device: usually the parameters (1200 8N1) are ignored by the COM port driver, as it uses USB under the hood. You "just" need to communicate faster than is possible with the CAN port, that's why they choose 3MBaud (virtual COM port) vs. <=1MBaud on CAN…

Changing CAN port parameters has nothing to do with the "serial" communication over USB. And most often you cannot set those CAN parameters on your own, but have to follow what the devices on your CAN port need/expect…

 


@VinnyLaTaupe wrote:

I will try to implement your suggestion of sending 10 messages at a time on the buffer, wait for the answers and send again etc.

I'm just not sure yet howthis will work on the bus (devices answering at the same time etc.)

But for now we have only one device so messages conflicts shouldn't appear.


On a CAN bus there is only one device "talking", all other devices will be quiet "at the same time".

A "message conflict" can only occur, when several devices will try to send/answer messages with the same ArbID: this should be avoided by design! Typically there is a CAN database (dbc file), where all devices/messages/nodes/signals/etc. of that specific CAN bus are defined!

Best regards,
GerdW


using LV2016/2019/2020 on Win8.1/10+cRIO
0 Kudos
Message 6 of 7
(67 Views)

@GerdW wrote:

Hi Vinny,

was thinking about CANopen heartbeat or PDO messages, which are transferred repeatedly…


Ah ok! No unfortunately I don't have access to those.

 


@GerdW wrote:

On a CAN bus there is only one device "talking", all other devices will be quiet "at the same time".

A "message conflict" can only occur, when several devices will try to send/answer messages with the same ArbID: this should be avoided by design! Typically there is a CAN database (dbc file), where all devices/messages/nodes/signals/etc. of that specific CAN bus are defined!


Yes, it is avoided by design (every devices will have a different node ID).

I will check out this dbc file.

 

Vinny.

0 Kudos
Message 7 of 7
(58 Views)