Pre-convert array of I/O controls fro DAQmx Flatten Channel String

[Gan Uesli Starling]

Am seeing a red dot (indicating conversion) where I feed an array of I/O controls into "DAQmx Flatten Channel String" VI.

Now the I/O controls array is created outside the loop but the VI is doing its conversion inside the loop. For efficiency's sake I'd like that red dot to go away by making the VI's required conversion outside the loop.

How best to do that?

[Francois Normandin]

Am seeing a red dot (indicating conversion) where I feed an array of I/O controls into "DAQmx Flatten Channel String" VI.

Now the I/O controls array is created outside the loop but the VI is doing its conversion inside the loop. For efficiency's sake I'd like that red dot to go away by making the VI's required conversion outside the loop.

How best to do that?

I understand you feel nasty about that red dot, but I don't think you lose any speed over that.

If you want, you can use the "type cast" primitive ans get rid of the dot, but it doesn't accept the array input, so you'll have to use it in the loop anyway.

BTW, thanks for pointing to DAQmx Flatten Channel String.vi. I just realize that's just the thing I needed for solving one of my problems!

[Gan Uesli Starling]

I decided to simply move "DAQmx Flatten Channel String" VI outside the loop, placing it immediately after the Controls IO build array. I no longer have the Error In/Out from that particular VI as easily connectable there, but it'll still do, I think.

The VI I'm building is rather big, quite a few signals to recorde. And there are several fo those Controls IO arrays, not just the one. And finally, as the rig is to be a test chamber eventually containing pressurized fire, I'd like to eek out whatever efficiency I might gain no matter how many hoops I myself must jump through to obtain it. Call it pre-CYA.

[Francois Normandin]

Hi Gan,

As stated earlier, I don't know if you have any performance changes with the coercion dot you're dealing with. Read this post to help decide if it applies to you in this case.

It seems to me that both types are strings, but the coercion dot is inserted to help you recognize a typedef change, similar to numeric vs knob, not a real typecast.