Using NI VISA to control serial relay card

[eichlerjw]

Hi

I am using a relay card to control the operation of a pneumatic machine. The relay card has an FDTI chip and uses an integrated USB to serial convertor. It came from eBay (see link). The card works fine but I am struggling with the VISA code in my vi (see attached library).

The card switches a relay when a command from 1 to 8 is sent to it. I.e. if you write 1 to the serial port, the card will switch on relay 1. If you then write 1 again, the relay will switch off.

so my vi generates a character pulse from 1 to 8 to control the relays. The first element of the resulting array is checked. If it is non zero, the character is written to the serial port.

Ideally, the case structure then switches to "read mode" where is checks which relays are on using the VISA read vi. The relay states are written to the shift register and then the case structure switches to the default case of 0 where it clears the buffers.

The e-stop button reads which relays are on and switches all of them off when enabled.

The problem is that the read function does not work.Everytime a relay is enabled, an error is thrown up when the read mode is enabled. (I do not know the error code but can find out this next week when I am back at work). I know that the read function does work as I can read the card in another vi.

Can anyone suggest a better way of coding the VISA read and write functions to avoid getting an error everytime the program tries to read from the card? I am new to VISA (I normally just use daqmx devices),

I suspect that the vi is not allowing enough time for the read function to grab all the bytes from the card and is therefore giving an error. I had to slow the loop down with the time delay to avoid getting errors from the VISA write vi.

Is there a way to run the VISA rear vi until it reads all bytes from the card?

Any help would be greaty appreciated.

Thanks. John

[Dennis_Knutson]

Knowing the error code is pretty important so aybe you should have waited before posting.

A termination character of '8' is pretty strange. The card responds by terminating each message with that? And you do not have to terminate your command? Post the manual and the VI that works.

[Tom9390]

Post the error code asap and I'll see what I can do

[eichlerjw]

Hi. Many thanks for the replies. I changed the termination character (whoops!) this seemed to help. I then started running the program as an exe on the windows xp box which will eventually control the machine (not my windows 7 laptop). I updated both the visa and LV runtime engines and it all seems to work a lot better.

However, the visa read function is still slightly unreliable. I believe this may be due to the card. I'll try and find out the error codes. Thanks once again. John

[JÞB]

See this thread where I discovered some of the more interesting "features" of the FTDI driver.  You may need to adjust the driver settings from the hardware manager to decrease the latency of the communucations.  Essentially the FTDI drive waits untill it gets a "full packet" OR the latency timer expires before sending the data in the buffer.  This causes some of the "last" bytes to be sent delayed rather than transmit at a consistant rate on the USB side of the link.  Also, definately use Synchronous VISA calls instead of the default Asynch VISA reads/writes (right click the VISA calls to change the mode)

[eichlerjw]

Nice one!

I had just this minute discovered the async vs sync modes. I'll read your other thread now. Thanks. J

[eichlerjw]

OK, so I have rejigged my code slightly (see screenshot). I have changed the modes of all VISA read and write vi's to sync mode. This has had little effect.

The main problem is the VISA read function.

I keep getting the errors -1073807339 (timeout expired before operation completed) and the warning 1073676294 (The number of bytes transferred is equal to the requested input count. More data might be available). I think these are due to the card not reading all the data in time.

Can anyone suggest a solution? I need to make the VISA read function actually keep reading until it has read all the data.

Do you think that modifying the driver .inf to increase the timeout would work? I see that the default is 16ms. I could change this to 32ms.

thanks again.

John

forgot to say. LabVIEW 2009 SP1 on winXP SP3.

[RavensFan]

You can safely ignore the warning.  It just means you got exactly the number of bytes you asked for.  My personal opinion is that LabVIEW shouldn't be warning you about this at all.

It looks like your timeout is only 1 second.  That may not be quite long enough to guarantee the device responds.  You should increase the timeout at the VISA configure function.  Perhaps to 2000 or 3000 milliseconds.

[JÞB]

the warning is typical.  I often supress (clear) this warning when reading "number of bytes" instead of until "termination character" and I'll supress the expected warning "Termination char recieved - more data may be available" if  I've enabled termination characters.   All it means is that you asked for 8 bytes and got 8 bytes but you don't know how many bytes were there (it was at least 8.)

The Timeout error means that less than 8 bytes were available in the 1second you waited.  There could be several reasons for this and each affects your code differently.

• The equipment hasn't sent data lately:  in this case you just need to read less often or peek into the buffer (property> bytes at port) to avoid buffer underflow/overflow.  Or set the device to produce data more often.  With your current code your outer while loop timing is dependant whether or not the VISA call timedout or read 8 bytes.  You may need to change to a different arcetechure if it is important to have tight control of the DAQmx task timings.
• The latency of the FTDI driver is delaying sending the bytes.  Unlikely that the 16 mSec is causing a 1 sec TMO error but if it is DECREASE the latencey timer to solve this.  Increasing it would only make it worse.  2mSec would be better than 16.

Without knowing how the equipment is supposed to work its pretty hard to say one way or the other that the TMO error is "bad" ar the normal consequence of an expected (or predictable) scarcity of data availablity

[eichlerjw]

Thanks for the replies. I increased the timeout on the serial port seconds to 3000ms and this reduced the errors.

However, the read function is still unreliable. It sometimes reports that relays are off, when in reality they are on.

I will try reducing the latency of the card to 2 ms tomorrow.

Yes, agreed about the daqmx stuff. I have to acquire data from a load cell (I have not put the code in for this yet) so adding a parallel while loop might be the way to go.

FYI. The code controls a pneumatic machine.

The relays control:

• Cooling fans for penumatic piston
• Extraction fans
• Pressure controller for air reservoir
• Start/stop operation

The function of the 4 relays above is not mission critical in terms of time of response but the software needs to know with 100% accuracy if each relay is on or off (this is something I cannot achieve as yet!)

The daqmx write function sets the pressure in the reservoir (which supplies piston) the and the digital in monitors an emergency stop button. Code for a loadcell will be added soon so that the force exerted by the pneumatic piston can be controlled by a feedback loop (hopefully).

Thanks again.

John