LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Using NI VISA to control serial relay card


@eichlerjw wrote:

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.

 


Is it only reporting the relays are off at the same read that it reports a timeout error?  I don't have your subVI's to know how you are decoding your serial responses.  But if you are decoding the response such as looking for a 1 to mean true, and a 0 to mean false for a relay input, and you get a timeout error and thus nothing returned from the VISA read, the decoding of your string data may also be failing and returning the default datatype for a boolean which would be a false.

 

If that's the case, you need to make sure you only write boolean values to your indicators whenever no error is returned from your VISA reads and your decoding VI's.

0 Kudos
Message 11 of 23
(1,382 Views)

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

May be related to the internal program running the relays-  I don't see a lot of certifications on the device page you sent and the "Best" claim made is that "you may reprogram the device." 

 

If there are "mission critical" functions and potential safety concerns........ I'd be looking for some different gear before the OSHA injury investigation points out this mistake.



"Should be" isn't "Is" -Jay
0 Kudos
Message 12 of 23
(1,377 Views)

Ravens fan. No the error doesn't always coincide with incorrect relay status. The VISA read function returns an 8 bit integer. (anywhere between 0 and 255) - Relay 1 is assigned number 1 and relay 8 is assigned 128. I convert this to a boolean array, then convert this to a binary array. The array is then multiplied by an array of (1,2....7,8) which results in an array containing zeros and the numbers of the relays which are switched on. I remove the zeros to result with an array of relays which are enabled.

 

I think that this bit of the code is not the problem as (using an indicator before this vi) I have shown that incorrect data is passed to it when the problem occurs. I think that the visa read function is causing the problems.

 

0 Kudos
Message 13 of 23
(1,364 Views)

Jeff

 

There are no real safety concerns. This is a research machine in my own lab so not too many worries on health and safety issues(!). The machine is in an interlocked cabinet with an E-stop button. My problem is that if the VISA function reports that a relay is off, whilst it is actusally on the rest of my code runs into problems.

 

I'm going to try to shift all the daqmx functions into a parallel while loop (or remove them for now) and see if this helps matters.

 

Unfortunately, no funds are available for additional hardware so I have to make what I have work

 

thanks

 

J

 

p.s. one solution I did think of was to connect the normally closed terminal of the relay to the digital in ports on my daq card. By monitoring the ports I would then know the state of the relays. Unfortunately, one of the relays controls some 240VAC fans so this is not easy (the rest are controlling 24V).

 

0 Kudos
Message 14 of 23
(1,361 Views)

WHOA! 


@eichlerjw wrote:

Ravens fan. No the error doesn't always coincide with incorrect relay status. The VISA read function returns an 8 bit integer. (anywhere between 0 and 255) - Relay 1 is assigned number 1 and relay 8 is assigned 128. I convert this to a boolean array, then convert this to a binary array. The array is then multiplied by an array of (1,2....7,8) which results in an array containing zeros and the numbers of the relays which are switched on. I remove the zeros to result with an array of relays which are enabled.

 


You've got some serious WEC in that!

 

 

This is the same- and you don't need a DBL to represent a whole number.  Try this

 

22415iBDFB4CD4B5EC9EDB


"Should be" isn't "Is" -Jay
Message 15 of 23
(1,354 Views)

Forgive me - I'm only a beginner! Thanks for the suggestion. I'll sort it later.Smiley Happy

0 Kudos
Message 16 of 23
(1,349 Views)

What you need to do is log some of the raw data coming in from the serial port.  If the data is wrong, then it seems to be an issue with your relays.  I doubt the VISA reads are doing anything to change the results coming in from the serial port.

 


@eichlerjw wrote:

 

p.s. one solution I did think of was to connect the normally closed terminal of the relay to the digital in ports on my daq card. By monitoring the ports I would then know the state of the relays. Unfortunately, one of the relays controls some 240VAC fans so this is not easy (the rest are controlling 24V).

 


A lot of relays that are intended to drive those higher currents and higher voltages (motor contactors) usually have a provision to add on some auxiliary contacts that you'd be able to wire your digital inputs through.

0 Kudos
Message 17 of 23
(1,341 Views)

Help me please!

 

I have made some progress (i think) in getting to the bottom of this. Placing the VISA read function after the VISA write function causes an error (1073807346). It complains that the com port specified is invalid and will not read any data. To test this i placed an indicator on the task wire between the two vi's. Sure enough, the value was blank. To remedy this i put the read function in a second while loop. See snippet.

 

22475i4A47F6B0EB254A82

 

This is the only way I have found to make the visa read function accurately report the relay states. Unfortunately, it slows down both the while loops. The VISA read vi reaches the timeout if there are not 4 bytes at the serial port to be ready (4 bytes = all relays on, well the ones I am using anyway). When all the relays are on the program functions fine. When less than 4 relays are on the VISA read vi runs until the timeout is reached, before allowing the next iteration of code to be executed. This results in an relay status array that blinks off and then on again when data is availble (I assume because the loop is running so slowly).

 

How can I recode this so that I get a fast loop and correct function of the VISA read vi? I'm pulling my hair out here, so any help would be greatly appreciated.

 

Many thanks

 

John

0 Kudos
Message 18 of 23
(1,329 Views)

I have just tried reducing the timeout to 100ms on the configure serial vi. This speeds up the vi but gives me error 1073807339 "timeout expired before operation completed" from the VISA read vi.It still reads enough data to accurately report on the relay status.

 

Is there a way of dynamically controlling the "bytes to read" value on the VISA read vi? I have tried using VISA property node "bytes at serial port" but this didn't seem to work. If I can read only the bytes that are at the port then the loop will not be delayed until the timeout expires.

 

Thanks

 

John

0 Kudos
Message 19 of 23
(1,321 Views)

there are a few ways to dynamically read an undetermined number of bytes. in order of preferance.

 

  • Use hardware handshaking.   RS-232 needs TX, RX and GND to work but ither signals are often used to control the communication flow.  most often they are not used
  • If the device supports termination characters use them.  Often a rs-232 talker that does not use hardware handshaking will send a special charater at the end of every send.  often this is a 0x0A or Newline.  set up this way the read will return as soon as it reads a newline character (sees end of message) or at timeout if nothing is there.  you will get warnings if termination char is read- we don't know how many more bytes could be there
  • use a property node on the VISA session to view the value in "Bytes at port"  (but you will need a bit of logic around this like- not increasing nor 0 and that can get sticky.) then read that many bytes.  certqainly you'll get the VISA warning- bytes read... may be more...

"Should be" isn't "Is" -Jay
Message 20 of 23
(1,305 Views)