LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

ULx Read.VI issue on USB-DIO96H/50 Digital IO board control

Hi everyone,

 

I experienced an issue since couple of days, and I figure out a odd behavior on the .NET Invoke node used by Ulx library (provided by measurement and computing). 

 

My VI (see NEW_LineV1.vi) use a USB board (USB-DIO96H/50) configured with Instacal.

Note: it is a big VI controlling lot of stuffs, please ignore the error messages to fully visualize the VI architecture.

 

My current issue is located on the vavle control.

I sucessfully write command toward the USB board and change the status of the valve thanks to booleen controls (Fig 1). However, I would like also to read and update in real time the valve status (open or close).
Therefore, I used the ULx read VI, in the same manner than the ULx write VI, but with a digital Input (instead of an output for the ULx write VI)

The VI (see test_read_board.VI) works, but when the signal come into the invoke node (into the ULx read VI, Fig 2), the vavle associate to Di0 input line, close by itself. Same when I used several input lines (Di0:7).

I suspect a weird behavior when the .NET connection between Labview and the USB board is made thought the invoke node. 

It seems that, by default, labview send a command while me, I just want to read the valve status (as the read VI is supposed to do ?). 
If someone have any idea about this behavior and how to fix it, in order to just read the board valve state ?

 

Thank you very much,

Julien AMALBERTI

 

PS: I tryed to used digital Output instead of Input for reading but it seems that reading is assosiated to Input only...

0 Kudos
Message 1 of 7
(3,347 Views)

I am not sure I understand you. Do you want to write to a digital channel (for instance setting it to ON), and later read from the very same channel to "check" if the channel is still on?

Generally DAQ cards with DIO channels do not work that way. You either open the channel for writing or reading, not both.

I think your problem might be that when you change your channel from digital out to digital in, the circuit will switch to digital in mode and voltage keeping the digital out channel up will disappear.

You will have to keep track of the state of the DO lines in your vi instead.

0 Kudos
Message 2 of 7
(3,330 Views)

Hi Perhult,

Thank you for your quick anwser.

For your first question, I will said yes. I want to "check" what are my current valve positions (ON or OFF) whitout sending a command (just a read) but I also want to be able to control them too. So I cannot write and then check if my valve is still ON with Labview and .NET command. Thank you for the information.
I already track the state thought my VI. I recored the status into a file and if anything happens I can recall the last valves configuration (but not in real time) or set up a default mode configuration (or an emergency mode too). 

With my research I found that the valve are controled by the CBW32.dll (or 64 for my version). 

I will try to directly call this library into my VI (thanks to a call library function node) to be able to read via this library instead of using NET.

Thank you,

 

Julien

 

0 Kudos
Message 3 of 7
(3,314 Views)

I am sorry, but calling the dll will not help you. If you read the User Guide for your device you see in the very first section "Each port is software-selectable for either input or output"

You hardware simply does not have the functionality you are requesting. All DAQ hardware I have come across works the same way.

But if you know the state, why do you need to ask the DAQ card what the state is? The state will not change unless you send a command to change it.

0 Kudos
Message 4 of 7
(3,294 Views)

 

Hi Perhult.

Ho, pretty strange then.
I build in the meantime a new VI, with the call library function node. 
I loaded the cbw64.dll, and I just called the function cbDIn located inside. 

 

I was able to read (and only read) in real time the valves status while I was controling the valves with the .NET function. 

I run the both VI in the same time, and no error messages happen. I tested to close a valve on the .NET VI, and the dll VI was well responding by tunrning off one the corresponding booleen indicator.

 

I think I am good right now to be able to control fully my valves. 

About your question, I want to know the valve position in real time in case of electrical problem happens on one of the soleionid valves. Also, when you start labview, the default booleen valve position is OFF on the front panel (even if behind the valves are open). For a new user, the valves should always show their real status to avoid any issue.
I am running a Noble gas lab, and I want that my equipment (mass spectrometer) be the safest possible if an external user come and run some experiments. 

 

Thank you

 

Julien

 

0 Kudos
Message 5 of 7
(3,289 Views)

Refering to your original post, where in your vi are you trying to read? What is Fig 2 refering to? Which channels?

Maybe I misunderstand you.

 

Regarding your last post:

OK, then I am surprised.

But still, what good is it to you? Knowing the internal state of the DO lines is not much help. It is not going to change.

When you want this kind of control you would like a physical feedback from the valve, an end position switch on the valve which would send back a digital signal telling you for real if the valve did not reach its intended position in the real world.

Or, at least connecting the DO line to a DI line to see that it really output the voltage you want.

0 Kudos
Message 6 of 7
(3,231 Views)

Hi Perhult,

 

I have tried to write and read into the board with a flat sequence structure (Fig 1 for example). The fig 2 in my previous post only show the ULxRead VI (it is a default VI provided by measurement computing). 
Initially, I sent a command to close my valves (for example) and then I tried to read if my valves are well closed.
Of course, as you said before: "when you change your channel from digital out to digital in, the circuit will switch to digital in mode and voltage keeping the digital out channel up will disappear." That makes lots of sense now, even if I found this way to work poorly designed. 

Therefore, I created a separated VI, which working with the call library function node (see Fig.2)

From that VI, and I am the first surprised, I can read the valves status (with the function cbDIn from the cbw64.dll library) while my current status is a Digital Output.

 

I agree that the valves status is not going to change while I am running my software. But, imagine, my VI crash during the execution for any raisons. When you restart Labview and launch the VI, the Boolean controller, located on the front panel, are by default ON (or OFF depending of the property of your USB board). In my case they look like all in the ON state, even if for real the valves are OFF.  I want that, even in a case of a Labview crash, the valves keep their information into my VI when you restart Labview (show the real status instead of assuming it). I can only do that with a reading of my valves status in order to check the system configuration. However, I cannot switch my channel to digital Out without resetting the configuration of my valves (Labview will kill the voltage and my valves will close all in the same time). 

I do not need to add a physical feedback; the board should already do that. It has a diode which indicates the valve status. I just want to read that state. 

Thanks to the DLL library, It's appear that I am able to just read the board and also controlling it without losing the voltage when I switch from write to read (which honestly should be a very basic feature to have by default). 


In addition, I noticed that even at the very beginning when you start Labview, even if my valves are in a certain configuration, the VI will shut down all the valves prior even to run my VI. I suspect that at the early initialization of the board, Labview configure the board to be in a certain mode (Out or In, I do not know). That causes this effect of: "voltage keeping the digital out channel up will disappear."

Consequently, I will try to use only the call library function node to use the DLL instead of the ULx library (or the .NET connectivity). I hope by manually configure myself the board via the DLL, it will not doing this weird resetting that the .NET connectivity doing. 

I hope I was clearer. 

Thank you

Julien

 

Download All
0 Kudos
Message 7 of 7
(3,215 Views)