problems with Get IO Module List.vi

[Dhomfray]

 I am using the NI Scan Advanced I.O Access 1.1 and have a simple program shown in the screen capture. What it shows is the GET I/O Module List.vi gets the first module OK but then gives all the rest the default module and channel number. Is this a bug or am I doing something dumb. What I am trying to do is get all the channel names to create an array of channel names

[alpha1]

Hi,

If you were to rename the modules Cal1 and Cal2 to something different like Cal01 and Cal02, does it then report Cal01 CSS_LED6_5 and Mod2 TC15? Do you have the NI Scan Engine Advanced I/O Access pushed down to the cRIO? Which version do you have on the host, and which version do you have on the cRIO? They must be the same, and the same goes for NI-RIO, which version do you have on your host and which version is installed on the cRIO? Which version of LabVIEW are you using?

[Dhomfray]

If you were to rename the modules Cal1 and Cal2 to something different like Cal01 and Cal02, does it then report Cal01 CSS_LED6_5 and Mod2 TC15?

It now shows the correct names but does it in alphebetical order not module order? which can't be correct as the header says I/O module info and the array index should really be module number

Do you have the NI Scan Engine Advanced I/O Access pushed down to the cRIO?

If i didn't I would not be able to run cRIO with that VI I have shown

Which version do you have on the host, and which version do you have on the cRIO?

My System - Don't have the scan engine let alone the advanced on the host??

RIO - NI Scan Advanced I/O Access 1.1

same goes for NI-RIO, which version do you have on your host and which version is installed on the cRIO?

My System - NI RIO 3.2

RIO - NI RIO 3.2

Which version of LabVIEW are you using?

2009

[alpha1]

Hi,

I sent an email to one of my colleagues in the US about this issue, and he responded with the following:

That VI will not work until you deploy the project. This is why it problably didn't work the first time, but it did the second time when he changed the names; he must have deployed. You can test this even by deploying the modules once in a project, then close it, create a new project and you will see that the VI works. Basically you need to deploy once, to configure/enable the scan engine, then that VI will work every time. Obviously, this isn't a bug and it is expected behavior.

As far as the alphabetical showing of the results, rather than by the order in which the modules are in the chassis, although not ideal I think this is also expected behavior. Is this problem for the customer? Can he not name the modules such that they will be in order in relation to the chassis? If not, there are other ways to get the location of the module using RSI property nodes. This requires additional programming, but it is doable.

"That VI will not work until you deploy the project. This is why it problably didn't work the first time, but it did the second time when he changed the names; he must have deployed. You can test this even by deploying the modules once in a project, then close it, create a new project and you will see that the VI works. Basically you need to deploy once, to configure/enable the scan engine, then that VI will work every time. Obviously, this isn't a bug and it is expected behaviour.

As far as the alphabetical showing of the results, rather than by the order in which the modules are in the chassis, although not ideal I think this is also expected behavior. Is this problem for the customer? Can he not name the modules such that they will be in order in relation to the chassis? If not, there are other ways to get the location of the module using RSI property nodes. This requires additional programming, but it is doable."