Tips for dealing with large channel count on cRio

[Pawel_Kowalski]

Hello, I have a very simple application that takes an analog input using an AI module (9205) from a thermistor and based on the value of the input it sends out a true/false signal using a digital out module (9477). Each cRio chassis will have close to 128 channels, the code being exactly the same for each channel.

I wonder if anyone has any tips for how I can do this so that I don't have to copy and paste each section of code 128 times. Obviously this would be a nightmare if the code ever had to be changed. I'm sure there is a way to make a function or a class but being new to graphical programming I can't think of a good way to do this. I looked for a way to dynamically select a channel but can't seem to find anything, if I could select the channel dynamically I'm guessing I can create a subvi and do it that way. Any tips or help would be greatly appreciated.

[speleato]

Hello Pawel,

Will you be using the modules under FPGA or Scan Interface mode?

Sebastian

[Pawel_Kowalski]

Hi Sebastian,

I want a lot of this processing to be done on the FPGA end so I will be using the FPGA mode instead of the scan mode.

[DFGray]

What version of LabVIEW/FPGA are you using?  It is a lot easier to use subVIs in 8.6 than in 8.0.

If you are using 8.6, consider creating some scripting VIs to make your life easier.  They can be very tedious to create, but can be an enormous aid, especially in maintenance.  You may consider some sort of marker on the block diagram to make each channel easier to find using scripting (e.g. surround each with a uniquely named single frame sequence or name each node something unique).

Finally, have you looked to see if the FPGA Wizard will create code you can use?  If you have never used it, just right click your target and select it to launch.

[Pawel_Kowalski]

Thanks, I will look in to that. And yes, Im using 8.6. I'm guessing I can do what did in the attached screenshot and just add a state for each channel (hopefully the scripting will be able to do this for me) with the sub_vi doing all the processing. 

But coming from a text programming background this still seems a bit inefficient.

Message Edited by Pawel Kowalski on 06-30-2009 09:18 AM

Message Edited by Pawel Kowalski on 06-30-2009 09:20 AM

[BruceAmmons]

You are right.  This method is terribly inefficient, especially on an FPGA.

Try creating an array of references to the channels you want to read and write.  Autoindex these into a for loop that does the processing.  The inside of the for loop will look very similar to the inside of your case structure.

I know FPGA programs don't like large arrays, but it might work okay with channel references.

It will be relatively slow, since it will be reading and writing one channel at a time.

Bruce

[Pawel_Kowalski]

Thanks Bruce, but I'm not sure I fully understand. Do you mean I can select which channel I want dynamically? That would seem ideal to me.

Or do you mean I should take all the readings from the modules and then combine them in to an array then attach that to the for loop. I attached a quick example to make sure I know what you mean,I didnt do the digital channels as I think I get the general idea. I'm curious how well the FPGA will handle an array that large. Thanks.

Message Edited by Pawel Kowalski on 06-30-2009 09:52 AM

[BruceAmmons]

Yes, you should be able to select which channel to read or write dynamically.  You have to create a reference for a channel.  I don't know exactly how to do it or what the limits are, but I know it exists.  I remember the feature was introduced shortly after I did it the hard way on an earlier project.

You could read all the values outside the loop, but I think the resulting array would be too large for FPGA to handle.

A compromise might be putting 4 or 8 copies of your subvi within the loop, then indexing four or eight groups of channel names.  This would operate on several channels at the same time without having to make a huge number of copies of your subvi.

Bruce

[Pawel_Kowalski]

That sounds good. If anyone has any tips on selecting the channel dynamically I would appreciate it, I am not finding a tutorial or much information on it.

[reddog]

There isn't a way to dynamically choose a channel at runtime.  In order for the VI to compile successfully, the compiler must be able to statically determine which channel is being read or written in the I/O Node at compile time.  However, that doesn't mean you can't write a reusable subvi.  If you right click on the FPGA I/O In terminal of the I/O Node and create a constant or control, you should be able to reuse the same logic for all of your channels.  The attached screen shot should illustrate the basics of what this might look like.  If you right click the I/O control/constant and select "Configure I/O Type...", you can configure the interface the I/O Item must support in order for it to be selectable from the control.  While this helps single source some of the logic, you will still eventually need 128 I/O constants somewhere in your FPGA VI hierarchy.

I should also mention that if each channel being read from the 9205 is contained in a separate subVI or I/O Node, you will also incur some execution time overhead due to the scanning nature of the module.  You mentioned you are reading temperature signals so the additional execution time may not be that important to you.  If it is, you may want to look at the IO Sample Method.  You can find more information and examples on how to use this method in the LV help.  Using the IO Sample Method does allow you to dynamically choose a channel at runtime and is generally more efficient for high channel counts.  However, it's also a lot more complicated to use than the I/O Node.

You also mentioned concerns about the size of arrays and the performance implications of using a single for loop to iterate across your data set.  That's the classic design trade off when dealing with FPGAs.  If you want to perform as much in parallel as possible, you'll need to store all 128 data points from the 9205 modules at once, process the data in parallel using 128 instances of the same circuit, and then output a digital value based on the result.  If you're using fixed point data types, that's 182 x 26 bits for just the I/O data from the 9205.  While this will yield the fastest execution times, the resulting VI may be too large to fit on your target.  Conversely, you could use the IO Sample Method to read each channel one at a time, process the data using the same circuit, and then output a digital value.  This strategy will use the least amount of logic on the FPGA but will also take the longest to execute.  Of course, there are all sorts of options you could create in between these two extremes.  Without knowing more about your requirements, it's hard to advise which end of the spectrum you should shoot for.  Anyway, hopefully this will give you some ideas on where to get started.