Getting connection to target lost with sbrio9606

[YogeshShivarudrappa]

Hi All,

I am using NI-sbRIO9606 for one of my project. I have some issues with the RT VI.

I have two SCTL in the RT VI; both configured to 1MHz clock. The dt for both loops anre different; 500 and 100 for each loop.

Now with this kind of configuration; after running the RT VI, the target gets disconnected and I get the folowing message,

The loop with the dt = 100 will be sniffing the CAN bus and send the CAN messages to the loop with dt = 500. Sometimes the RT VI re-establishes the connection to target and sometimes it doesnot connect at all and I have to endup with the Stop waiting option.

I know the RT has got a max of 400MHz clock. Can I run the RT at a max of 100MHz speed so that I can read the CAN messages received at 1us interval.

Any help is appreciated,

Thanks,

Yogesh

[nathand]

This often happens when you overload the RT processor. The task that manages communication with the development environment is lower priority, so if higher priority tasks take all the processor time then the network connection will stop responding.

You won't be able to run an RT loop at 100Mhz, but that's also not what your code does. With a 1Mhz base clock, wiring a value of 100 to dt means the loop runs at 0.01Mhz, or 10kHz.

What's happening inside the timed loops? How fast does it need to run? Can you transfer some of the high-speed work to the FPGA?

[YogeshShivarudrappa]

Hi nathand,

I agree to you that the SCTL with 1MHz and 100us of dt; is 10kHz loop. This is the excat problem. So, if I say 1us as the dt, then the SCTL runs at the max speed of 1MHz.

But the RT processor runs at 400MHz. Is there a way to run loops in RT at speed greater than 1MHz??

I have configure the sbrio with the crash curves of max length of 30k samples. This will be sent over CAN to teh sbrio. So i should handle this on RT adn in order to have less LUT utilisation, I should have max logic on RT; so have these code on FPGA is ruled out for me.

Is there a work around for this?

Any help is appreciated,

THanks,

Yogesh

[nathand]

No, I don't think you'll be able to run a loop faster than 1Mhz reliably on the RT side. One loop cycle on RT is a lot of instructions (how many depends on what you're doing inside the loop), plus there are other operations running at the same time such as network communication, so there's no way to tie the processor speed directly to a maximum loop rate. On the other hand, on the FPGA, you can program exactly what occurs within a single clock cycle (so long as it's within what the FPGA can achieve).

How are you transferring the CAN packets from the FPGA to the RT side? Do you need to process each packet as it arrives? What processing do you need to do, and what other work is the FPGA already doing? Are you close to full utilization of the FPGA?

You haven't provided many details about your application, but normally for high-speed acquisition, the FPGA receives the data and pushes it into a DMA FIFO. The RT code runs at a slower loop rate and processes multiple elements from the FPGA on each loop cycle, instead of handling them one at a time.

[YogeshShivarudrappa]

Hi nathand,

Thanks for making me to understand about the relation between the processor clock and the RT loop clock (new lesson learnt )

1. CAN is availble directly on the RT and not available on the FPGA.

2. I am simulating a sensor which is used in the automotive sector for crash detection. So, worst case, a crash will sustain for 5sec and the no of samples

    will be near to 30k samples.

3. The complete sensor functinality is in my FPGA. I am trying to simulate two sensor per sbrio. So, I need to keep FPGA as light as possible.

4. All 30k samples will sent over CAN from the HOST vi to RT vi. So, i have to process each CAN msg as I receive on RT.

5. I am able to achive downloading a crash curves, but this is taking a lot of time approximately 1min. I need to optimise and try to make it to 1sec.

[nathand]

I didn't realize that on the sbRIO the CAN port is connected to the processor, and not to the FPGA as in the cRIO products. On that topic, there's a note: "... the performance of the CAN port is expected to be lower than National Instruments dedicated CAN devices because the processor is running at only 400MHz, and is also performing other LabVIEW Real-Time operations."

I don't have the sbRIO embedded CAN driver installed and I can't find documentation for those VIs elsewhere, so I'm not sure what your options are. I also don't know how many packets the driver can buffer. What are you doing with the CAN data once it's received? You can't possible respond to each individual packet at the rate you're hoping to achieve, which is why I asked if you need to handle each packet immediately after it arrives, or whether you can read a bunch of packets together (if the driver allows it). If you upload your code I'm happy to take a look and suggest ways to optimize it if possible.

[Spex]

The maximum baud rate for the CAN port is 1Mbps.  I believe the minimum length of a standard CAN data frame is 51-bits without any data payload.  From my understanding, this dictates that the fastest rate frames can arrive at the controller is on the order of 20k frames/sec or slower with full bus load.  Assuming a data payload of 1 byte or 8 bytes pushes the maximum frame rate even lower (16k-frames/sec or 8.5k frames/sec).  This means that it is never necessary to have an RT loop running anywhere near 1us loop rates to process CAN on a frame by frame basis.

I don't have processor load numbers for various benchmarks, but is has been demonstrated that the sbRIO-9606 and other 400MHz Single-Board RIO devices cannot maintain 100% bus-load for 1Mbps CAN when the packet size is small (1 data byte per frame).  Single-Board RIO was capable of handling 100% bus load when packets were larger (8 data bytes per frame) or the bus speed was slower (500kbps), but the CPU load was likely very high (I don't have it documented).  Using more than one CAN interface increases that CPU load and limits the maximum throughput per bus further.

The testing I have observed polled the CAN bus with a 10ms loop time, so roughly 90 frames were read from the bus per loop iteration.

The CAN port built into Single-Board RIO is better suited for using Single-Board RIO as a device in a CAN network that receives a limited amount of bus commands, not as a CAN analyzer/logger that might need to capture all CAN events on a crowded, high-speed CAN bus.

[YogeshShivarudrappa]

CAN bus speed is 500kbps for me. As I explained; I will be trainsmitting all 30k samples over CAN from HOST to RT. This is overloading the RT.

So, what I could find from the discussion is, run the RT at 1MHz and 1000us dt. This should be OK. Also please find the attacehd RT vi (many dead code in that, please ignore all those).