LabVIEW Nubie...tackling large application...Need NI-CAN advice

[JeffGrimes]

Hi readers. First off, I'd like to thank all who read and offer advice...Us new LabVIEW programmers really appreciate the "application specific" advice.

I'm writing test-stand control system for an automotive (Powertrain) test bench. I have to manage the User Interface, 3 CAN networks (1 Read, Act on data, Display. Write and LOG, the other two READ, Display, and Log time-synchronized with the 1 CAN network. Additionally, approximately 60 analog channels will be synchronously logged as well.

All logging will be via TDMs in LV8.20.

All together, I have to read/display/log ~150 CAN signals at 10-100Hz (User Selectable). The CAN channel I'm acting on, which simulates the Vehicle Processor, must have data written at 10ms intervals, or the subnet processors will fault.

To facilitate TDM properties, each CAN signal and analog channel will have ~5 properties associated with it.

I'm struggling with how to structure the data coming off the CAN network. I'm thinking a cluster of clusters, or possibly an array of clusters. But I'm not sure how big that would get...We'll be running RT. I'd likely take this cluster and make it a SHARED VARIABLE for improved coding...and memory management

Any guidance would be GREATLY appreciated. I can "struggle" through the implementation code, as long as I'm comfortable I'm solid with the underlying data structure. :headbang:

For what its worth, I'm planning to have the application Event Driven as much as possible...

Thanks again

[bsvingen]

It depends on how this data is going to be used. Is it only saved, or is some of it going back in a loop. My experience with shared variables are that they are incredible slow, a factor 10000 or more for simple read and write compared to anything else you can think of (queues for instance).

You should have plenty of processing power available, however, *steady* 10 ms timing with all that data could still be a problem if you do a lot of memory reallocations etc, so it is probably a good choice not do alot of type conversions unless you abselutely have to.

[Khalid]

Hi readers. First off, I'd like to thank all who read and offer advice...Us new LabVIEW programmers really appreciate the "application specific" advice.

I'm writing test-stand control system for an automotive (Powertrain) test bench. I have to manage the User Interface, 3 CAN networks (1 Read, Act on data, Display. Write and LOG, the other two READ, Display, and Log time-synchronized with the 1 CAN network. Additionally, approximately 60 analog channels will be synchronously logged as well.

All logging will be via TDMs in LV8.20.

All together, I have to read/display/log ~150 CAN signals at 10-100Hz (User Selectable). The CAN channel I'm acting on, which simulates the Vehicle Processor, must have data written at 10ms intervals, or the subnet processors will fault.

To facilitate TDM properties, each CAN signal and analog channel will have ~5 properties associated with it.

I'm struggling with how to structure the data coming off the CAN network. I'm thinking a cluster of clusters, or possibly an array of clusters. But I'm not sure how big that would get...We'll be running RT. I'd likely take this cluster and make it a SHARED VARIABLE for improved coding...and memory management

Any guidance would be GREATLY appreciated. I can "struggle" through the implementation code, as long as I'm comfortable I'm solid with the underlying data structure. :headbang:

For what its worth, I'm planning to have the application Event Driven as much as possible...

Thanks again

As for the data structure, I have the following suggestions: Not knowing the actual data format and what other processes you will have going, the following may not suit your case. If you have a fixed number of channels, I suggest you use an array of clusters in your processes. The actual cluster will be your data structure, typically with one DBL for value, another for Timestamp, and a U8 for status code, and another one for Channel ID, for example. You can add/delete to this if you see a need.

The reason I suggest having an array of this data-cluster is, in your different processes you can, first, initialize this array to the size of the number of channels, and then as and when you get new channel-values, you just index and replace that element of the array. This way you are not using build-arrays, etc. in a loop.

To pass the values around, I suggest you try the new RT-FIFO functions. In 8.20 they now support clusters. So, whenever you receive a new value for a channel, you would stuff this clusters with all the data, timestamp, status, and the channel ID, and place it on the FIFOs. The different processes can read the FIFOs (you will need one FIFO per process) and take this cluster-data and replace it in the array.

Hope this gives you some ideas.

Regards,

-Khalid

[Mellroth]

Hi,

if you are using the frame-API of NI-CAN in LabVIEW, you might want to enable the reentrancy property (look in VI-properties->Execution) on some of the NI-CAN methods, e.g. ncReadObj and ncWriteObj. Otherwise you will have a dependancy between your CAN networks, e.g. the time it takes to output a frame on one network, delays all other outputs on any network.

If you are using the Channel-API, all methods are already made reentrant.

/J

[JeffGrimes]

Thanks for the feedback...Here is a little more detail.

I have 3 can networks to READ. Two of those will only be logged via TDMs output. The 4th channel, I have to read, do some calculations/comparisons/update a whole slew of flags and variables/write to the same CAN channel.

All three channels have channels I need to bind to indicators on the FP.

My channel count will be fixed, at ~150 channels. For logging, I'll need a lot more information for each channel...but much of that is Meta-data (sensor manufacturer, last calibration date, etc). On the 1 subnet that I'll be doing actual processing and writing, I only care about the channel name (variable name???) and its Channel-API converted value.

Also, for logging TDMs on a RT system...I'll have ~150 channels flying on three subnets that I'll need to log EVERY SINGLE MESSAGE/CHANNEL...Broadcast rates are 10ms or 100ms depending on the message. I'll need all this timestamped and synchronised with 60 analog inputs (pressure, etmperature, humidty, etc).

Should I bundle all this into a cluster...then feed a queue that feeds a write VI...or just send every CAN (Channel API is planned) channel to a queue directly?

Soryy for the rambling...I'm frustrated right now, because I can't seem to develop the application any further without having my 50# 1050 chassis ethernet-plugged into my development PC. Its :headbang:

Thanks.