DO resetting when using multiple software instances with ULx library

[ReinhardV]

Hello,

being new to the forum, I am not sure whether my similar post as an answer will show up as an open question, I give it one more/last try in a new post:

 

I am using the USB-2408-2AO with a LabVIEW (2011) application (built exe) and the ULx library, which is all working fine.

Now we have the need to control several of those modules parallel from one computer and I decided to allow multiple instances of the exe, each connecting to another USB-2408-2AO. In principle this also works, but I have one big problem occuring when a newly opened instance uses the ULx library function (ULx Create Channel (...).vi) for the first time. At this moment the Digital Outputs of all connected USB modules are reset, which leads to unexpected failures in the corresponding measurements. This happens independently from the chosen device of the measurement channel to be created.

Afterwards, I can set all digital outputs of the connected USB devices as desired, but every time I start a new instance, the running measurements crash (as they need the DO turned on). And, to anticipate this, I also would not want a measurement to start if it was stopped before, so inverting the logic (pull-up / pull-down) is not a solution.

Is there a way to prevent the ULx functions from doing this reset to all the DIOs when called by an application the first time?

I might, of course, reprogram everything to be controlled by only one application, which is calling a new window for each USB module / measuring task, but that would be a huge mess, not only because I've made intense use of global variables that should refer to only one measuring task.

Anyway, I think it should be possible to work with two or more USB DAQ systems independently in two or more applications.

 

Thanks and best regards,
Reinhard

[Fausto]

Hello @ReinhardV.

Thank you for the vi examples.  I was able to reproduce the behavior noted for the first daq module, when the second vi executable reached the ULx Create Channel (DO-Digital Output).vi section in the example.  I even saw the LED flicker on both modules just by running the first executable.  Unfortunately, I do not have a workaround or solution for this behavior.

When an update for this behavior is available, it will be noted on this post.

Regards,

Fausto

[Fausto]

Hello @ReinhardV.

With multiple USB-2408-2AO devices connected to one system, is the user required to select a device and digital lines when the custom executable is launched?  I can see this being an issue if you already launched one instance of the executable, selected the first device (Dev0 as default), and then launched the executable a second time which defaults to the first device (Dev0).  Unless you specifically indicate which device and lines to use for each instance prior to launching the executable, ULx will list all detected MCC devices.

I tested the ULx example to generate digital outputs (ULx Write Dig Chan.vi) with two different MCC daq devices.  I named and saved the example twice specific for each device with the device # and digital lines saved in the Channel Parameters field.  I launched one example for the first device and set the digital output 0 line HI.  Afterward I launched the second example specific for the second board and set its digital output 0 line HI.  I did not notice an issue with the first device when I started the second example.

 

Regards,

Fausto

[ReinhardV]

On 9/6/2024 at 6:04 PM, Fausto said:

I tested the ULx example to generate digital outputs (ULx Write Dig Chan.vi) with two different MCC daq devices.  I named and saved the example twice specific for each device with the device # and digital lines saved in the Channel Parameters field.  I launched one example for the first device and set the digital output 0 line HI.  Afterward I launched the second example specific for the second board and set its digital output 0 line HI.  I did not notice an issue with the first device when I started the second example.

Hello Fausto,

Thank you for looking into this matter!

My original plan was, to check DeviceFactoryID and DeviceName of all connected boards by just reading the IOTask properties of arbitrary channels of each device. (e.g. Dev0/1stPortA/Do0, Dev1/1stPortA/Do0, Dev2/1stPortA/Do0, Dev3/1stPortA/Do0)

Additionally, I have the information which device is currently already active in a Shared Variable, so I will not allow the user to connect another program instance with the same DAQ device.

I understood that it might be a problem even to create a channel of a DAQ device which is already in use with another instance, so it would have been acceptable for me, not even to read DeviceFactoryID of a device which is already in use.

The really bad part now is, that I cannot connect to any other DAQ device without disturbing the measurement (obviously by resetting digital output) of another one.

I did the following easy test: Dev0 is used with my measurement application and there is a digital output activated to allow measurement.
Now I have a 2nd simple program (see attachment), which can read DeviceFactoryID from a channel in an ARRAY list. Thus, I can easily try with channels of different devices and data type (digital output and analog input).
No matter which channel I choose with the Index and hit one of the OK buttons to read the channel information, the digital output is always reset for Dev0 at the moment the ULx Create Channel vi is called. To make this clear: It also happens when creating a channel of Dev1 and it may also be an analog input instead of digital output.
Afterwards, I may set the output of Dev0 to TRUE again in my measurement program and it will continue measuring. Also, there is no communication error in any of the programs.
Furthermore, if I hit the OK button of my 2nd program again, there will be no resetting of the DO. On the other hand, if I start the 2nd program again the problem will occur once again when the OK button is hit for the first time.

We also measured the voltage of the digital output. While it is pulled to 0V when the DO is activated and measurement is running, it will immediately jump to 5V when the create channel vi is called from the other program. I would be surprised if you cannot verify this behavior.

I am not sure how to find out the version of the ULx library. Maybe this is of interest. The InstaCal version is 6.72.

One further hint: If you did your tests within the LabVIEW development environment it probably counts as only one application even if you start two VIs and the described behavior will not occur. You will have to check this with two executables or with one VI in the LabVIEW environment and at least one execeutable.

 

Best regards, Reinhard

Edited September 9 by ReinhardV

[ReinhardV]

I've tried another very simple version of the above program. I reduced the arrays to one constant "Dev0/1stPortA/Do0" in program A and "Dev1/1stPortA/Do0" in program B. This way, there is definitely no reference to another device/board in the whole programm.

I then started program A, switched on Dev0/1stPortA/Do0 and measured voltage at DIO0, which went from 5 to 0 V (low-active).

Then I opened the program B and did the reading task for Dev1/1stPortA/Do0 like in the block diagram above, but with the line constant connected to the ULx create VI. After getting the message "before creating channel" and clicking the OK button of this message window the communication LEDs of Dev1 AND Dev0 (!) were blinking two or three times and the Dev0/1stPortA/Do0 voltage went back to 5 V.

I've also tested this with the VIs started from the LabVIEW development environment. There it does not occur. DO0 stays activated at 0 V.

The VIs and EXEs are attached. (As already mentioned, it is LabVIEW 2011 SP1 32-bit)

Test Dev0.exe Test Dev1.exe Test Redlab-IO-Task-Abfrage Dev0.vi Test Redlab-IO-Task-Abfrage Dev1.vi

[ReinhardV]

Dear Fausto,

Thank you for your support and testing. It is at least good to know that I do not have to look further for a programming error on my side.

I'd really appreciate an update on this and I think it should be possible, because you can open InstaCal and get device information while running the programm without influencing the digital outputs. Shouldn't it be similar with the ULx library?

Best regards, Reinhard