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

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

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

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

Hello @Fausto and everyone else, I think I ran into a similar problem and hope you can suggest a solution for it: I am using the USB-2408-2AO with a LabVIEW (2011) application (built exe) and the ULx library, which is all working fine. We had 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