sbRIO-9651 microcontroller speed

[JMRacing]

Hello there,

I am using the sbRIO-9651 for the complete control/software of a prototype inverter. The main controls for the setup are running on the FPGA. However we need to handle the IO to the system with CAN, which happens on the microcontroller/Real time of the board. Here we have a problem.

We need to send high relatively high speed CAN messages to the board to be able to adjust the torque fast and handle slip control of the vehicle on the inverter, as well with receiving wheel acceleration and desired slip per wheel. The required CAN cycle time for all mesages are 4ms and we have only 6 messages at this speed and a 7th message slower at 20ms cycle time.

For validation of the received CAN and timeout detection we implemented a supervision which checks for the time delay between last received message and current time ( this happens in the CAN block in the middle) . After, for example 10 missed messages, we set the message as "disqualified" and torque request to 0Nm.

Now to the problem: We noticed that our message get disqualified even if the messages are send regularly in CANoe or by the ECU. For investigation we implemented a speed check in the receive timed loop in LabView with a microsecond timer. Here we can achieved a maximum of 800Hz to 1,2kHz for this loop. Which is very slow and to slow to handle the incoming messages fast enough. Every loop cycle works with one CAN ID and writes its data to lokal variables. The time loop is set to a cycle time of 1us.
Could you help with advice how to boost this speed to at least 2.5-3kHz to be able to achieve the required CAN read speeds?

Further info: LabView 2018, Version 18.0.1, total CAN busload with sending 51%,

tryed solutions: disable CAN send, all other non necessary time loops; shift CAN send to different core; send disqualifiuers out to CAN and not RUN/supervise the project from PC

Thanks a lot

[GerdW]

Hi Jan,

---

@JMRacing wrote:

Every loop cycle works with one CAN ID and writes its data to lokal variables. The time loop is set to a cycle time of 1us.
Could you help with advice how to boost this speed to at least 2.5-3kHz to be able to achieve the required CAN read speeds?

---

• What is done in all those subVIs? Do they run fast enough?
• Why do you access "data in" in parallel with those local variables and the terminal? Race condition ahead…
• The median filter of 1000 values will also take some (significant) time to process…
• Can't you stream the CAN message data to the FPGA (using a FIFO) and handle the message content in there? When you know the fixed amount of messages you can easily separate them in the FPGA by their ArbID.)

[dkfire]

How do you run this vi ? From the project explorer on the PC ?? 

If that is the case, then the communication between PC and RIO will slow down your code. 

[ZYOng]

sbRIO-9651 has an ARM processor with 667MHz of processing speed. What is the CPU usage? What if you try to remove all other subVI and benchmark the execution speed of only CAN Read VI?

If it still does not meet your requirement, you might want to consider using sbRIO-9853 to run the CAN read on FPGA.

[JMRacing]

Hi dkfire,

thanks for your reply. Yes at first I was running it from my PC, but I had the same idea that it might slow down the RealTime. Thats why I decided to send this frequency of the timed loop and all my qualifiers out by CAN as well. It did not change the outcome. With a decreased CAN cycle times send by the ECU all signals are valid, increasing the time a little further and the messages with highest ID start to get "disqualified" randomly. Not in fixed pattern, multiple messages and not at a constant frequency/rate

BR

[JMRacing]

Hi Gerd,

I have attached an additional screenshot of the CAN send block. The flat sequence continues to the right with a second window which does the "Qualifier" calculation with some logic for the arrays (just simple comparison of the millisecond time from the left). The VI at the bottom is just for rearranging the data to a neat format for displaying on the front panel. It's not used in normal operation when running in the prototype and the front panel not displaying any values.

I have tried the suggestion with removing the filter. But this as well did not improve the speed. It just gets more noisy.
Moving the CAN to the FPGA won't work as its very stuffed already with the FOCs for multiple motors. Additionally the precalulation for the controls happens in the RealTime as the memory in FPGA is to small for this task.

Can you explain how you would improve the parrallel acces of data_in and why this may slow down the loop?

Thanks a lot

BR

[GerdW]

Hi Jan,

---

@JMRacing wrote:

I have attached an additional screenshot of the CAN send block. The flat sequence continues to the right with a second window which does the "Qualifier" calculation with some logic for the arrays (just simple comparison of the millisecond time from the left).

---

Why are there so many coercion dots in this image? Please learn to use proper datatypes in all places… (This probably doesn't help with speed improvements, but would look so much better!)

I hope (but fear) you don't use all those fp elements to transfer data to different parts of your code (by local variables)?

---

@JMRacing wrote:

I have tried the suggestion with removing the filter. But this as well did not improve the speed. It just gets more noisy.

---

The noise is expected when you remove a filter. The median is somewhat more computational heavy as it needs to sort the internal array buffer with each call…

---

@JMRacing wrote:

Can you explain how you would improve the parrallel acces of data_in and why this may slow down the loop?

---

Just use the wire coming from the subVI and connect it to the middle input of the BundleByName node. The output goes to the data_in indicator. No locals needed, when you use wires!

This also will not speed up the loop, but it will avoid the race condition due to the current parallel access to data_in!

[dkfire]

You have a frame array at the bottom, does that have a limit ? 

What does it do ? 

Reg CAN: 

Can't you read more frames at a time? 

How fast does the messages come ? 1ms between or is it less? 

The CAN read function, is that a NI function for sbRIO ? 

[JMRacing]

Hi dkfire,

the frame array at the bottom is only for dispalying on the Front Panel. It has nothing to do with the handling of the incoming messages.

The CAN function/block (glasses) is a NI function itself. The other CAN block in the center is self developed. Message cycle time is 4ms for ID0x2 to  0x7 and 20ms for ID0x9. Thats all messages coming in. Overall busload is ~50% with the sbRIO9651 also sending a bunch of messages

The current issue I seem to have it that the frames are comming in fast enough just the timed loop cannot process them in time

BR

[GerdW]

Hi JM,

---

@JMRacing wrote:

The CAN function/block (glasses) is a NI function itself. The other CAN block in the center is self developed. Message cycle time is 4ms for ID0x2 to  0x7 and 20ms for ID0x9. Thats all messages coming in.

---

So within a 100ms interval you receive (100ms/4ms)*6 IDs + 100ms/20ms = 155 messages. To handle each message you only have ~650µs available…

What happens when you place ONLY the CAN message reading inside the loop and send the received frames directly into a queue to analyze the frames in a consumer loop? Will the receiver/producer loop run fast enough in this case?