200429 error when using simulated DAQ and local variables for task/channel inputs

[J Bowen]

I've created a vi setting up several channels in the beginning of the VI; passes the task names to a hidden indicator, then attempts to use local variables (referencing the indicators) to measure data on the channels I've created.  I'm using a simulated device just to debug but I've experienced this error with my DAQpad 6015 and SCC 2345.  It only happens once, when I initially run the VI and then after one error message it seems to work fine. 

I've included screenshots of the error as well as how I'm setting up my channels.  Obviously after the VI runs once and spits out an error something is in the memory location so the local variable isn't referencing an empty string anymore but I was curious as to why it doesn't work during the intial run?  Any help or recommendations would be helpful.

[Dennis_Knutson]

I suspect that you are seeing problems because of the reason why it is unwise to use local variables. Local variables are subject to race conditions because there is no data flow. The first time you try to read them, they probably haven't been written to yet. Without seeing the entire program, I couldn't tell you where this is happening or exactly how to fix it but eliminating the local variables would probably solve it. Is there a special reason you are using them?

[J Bowen]

Your right.  When I put the channel configurations in a sequence structure before calling the local variables it worked.  I'm using them because the vi i'm making is cluttered and i'm trying to basically configure some channels and then latter on (to the right) call on those channels to take data after some user input.  i don't want to have to have wires all over the place providing connections for to the task id.  is there a better way to do this?  Is  there a way to store the task id after the channel is configured so I can easily reference it in the vi?  I know I could do global channels but I change my SCC modules frequently so I'd rather stay away from them...i think...

Thanks for your help!!

J

[Dennis_Knutson]

Always, always use wires when you can. It is the most efficient and least problematic. Local variables, besides causing race problems, create duplicates in memory. Read the style guide that ships with LabVIEW. Wires do not have to be messy and can be arranged neatly. Multiple wires can be bundled together and unbundled as needed. Sequence structures are also usually not required. LabVIEW is a dataflow language and if you make use of things such as the error in/error out connections, you can control execution flow that way. You can also make use of state machines, event structures, and shift registers. There are shipping examples of all of these and many more in examples posted here and in the Developer Zone.