I am busy editing some old LabVIEW code I had written back when I was just getting started that I now know to be sloppy and/or dangerous. The application I am working on uses a USB-6501 to control up to 16 different output pins used by our automated test setup. My old way of doing it was to create a new, unnamed task every single time we wanted to change a single output value, run the task to change the value, then clean up the task. The change I am making will make a single task for the device with all 16 channels registered in a pre-set order to match an enum that the higher SubVIs will use to switch multiple lines at a time.
The problem I am having is in testing this out. I don't have a USB-6501 to test on currently, so I simulated on in NI-MAX and then wrote a small VI to test whether or not it was working. First, here is the initialization SubVI to test up the task:
Next is my test SubVI:
Basically, since I want to be able to write to multiple channels at the same time without disrupting the states of the other channels, I want to make sure I can read the current output states from the device, alter only the lines the caller asks to, and then write the whole thing back out. So if I want to alter the states of the two pins which control the two physical relays, I don't want to also alter the channels that control the LEDs, and vice versa.
The problem that I am having is that what I read is never what I write. Worse, what I read is always the same no matter what I write AND changes every time I call DAQmx Read. Every time I do a read, each individual port starts incrementing like it's a binary counter: the least significant line on each port changes from OFF to ON; the next time, the least significant lines change to OFF and the next line changes to ON; then both change to ON; then they both change to OFF and the next line changes to ON. The series of snapshots below are having done NO write commands and a series of read commands:
Every time I start the application, the first read always shows all OFF, then goes through this same sequence. I don't know if it is because I am using a simulated device or what, but this is really concerning. Help getting to the root of the problem (preferably not things like keeping around the previous results of the last "write" command so I know what the last thing I wrote was) would be infinitely helpful. Thank you.