delay in VISA Read

[Orbieu]

Hi everyone,

I made a VI which writes a text according to the button i pressed and then reads the COM port.

I got a port COM with TX and RX welded together, to receive the emitted data.

However, when i run the VI, i read what i wrote only on the second button press.

For instance, when i start the VI, chose the COM port and press test1, nothing is in my read buffer. But if i then press any button, i will read test1 in my buffer.

What i don't get is the fact that when i switch to highlighted mode, the VI runs as i expect it to run.

Can somebody see why it acts like this, and what to do to prevent this ?

See attached two attempts to realise this VI.

Thank you,

Clement Z.

PS : Sorry if i don't think dataflow but i don't get what it means!

[GerdW · Accepted solution]

Hi Clement,

using BytesAtPort is wrong most of the time. Use a TermChar if possible!

2nd problem: you read BytesAtPort directly after writing your output string to VISAWrite. At the time you read BytesAtPort the output string isn't even sent to the COM port - it is still in the COM port (internal) buffer! When using BytesAtPort you NEED to work with delays!

What i don't get is the fact that when i switch to highlighted mode, the VI runs as i expect it to run.

The big difference in highlight execution are the delays in code execution!

So when something works with highlighting, but not in regular execution, it is most likely a race condition…

[Orbieu]

Hi,

Indeed, putting a little delay after VISA Write worked wonders !

Concerning BytesAtPort, i've been using this all along and, to the best of my knowledge, i never had a problem because of it.

However i tried using the termchar, but without any succes. Here's the process i followed :

 _ enable termchar in VISA configure

 _ chose a term char in VISA configure

 _ put a huge number in byte count in VISA read

 _ end my frames by the termchat i chose

But i couldn't get it to work. Maybe you could give me a small example ?

Thank you again,

Clement Z.

[GerdW]

Hi Clement,

you need to append the TermChar to your string as LabVIEW does not add it (by default).

(The other "non-default" option is to use a VISA property node to enable automatic appending of TermChar at VISAWrite…)

[Orbieu]

Hi,

I did not succeed in appending the termchar but the property node worked wonders !

Just for the record, is there a particular reason why BytesAtPort is not advised ?

Thank you,

Clement Z.

[GerdW]

Hi Clement,

is there a particular reason why BytesAtPort is not advised ?

Because of the problems you encountered?

And because:

- when you have messages of fixed length you should read that fixed number of bytes: no need fo BytesAtPort!

- when you have messages of variable length you should always work with a TermChar: no need for BytesAtPort!

[crossrulz]

I just fixed up your VI to make it a little simpler and to be able to use the termination character.

As GerdW stated, using the Bytes At Port for a serial read is very dangerous because you can run into weird race conditions like you just ran into.  If you know your message length, you should just read that many bytes.  If you have a termination character, let that stop your VISA read.  In a good communication scheme, the Bytes At Port should not be needed.  But it all depends on the instrument you are trying to communicate with.