Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

Serial read only works in highlight execution mode

Hi,

i am trying to read data from a Extech Rh520 temperature data logger. i can only get it working in highlight execution mode, i get that this is most likely a timing issue but i just cant figure it out.  i have created the most simplest version of the VI (attached) could someone please take a look and point me in the right direction.  i have tried putting delays everywhere and just cant get it to work.

just a bit of background info, this is a data logger and you can only download the data in one go.  To initiate this download you have to take DTR low then just read the data until it stops. it's at the point where DTR is taken low that doesn't work in full speed it doesn't read any data.

 

Thanks in advance for any help i receive.

0 Kudos
Message 1 of 8
(3,910 Views)

If your piece of equipment is still initializing prior to entering the loop, BYTES AT PORT will equal 0.  Prior to entering the loop, could you perform something like an

*OPC?

This command ensures that all previous commands have been completed before it returns a '1' response to imply that the final query was successful.

 

Another option would be adding an initial loop that waits for the first byte at port prior to entering your current loop.  You may also exit the loop prior to reading all bytes coming across.  Why not have the initial loop continue until bytes at port >0 and doesn't change for x consecutive loops?

 

Help the Community (and future reviewers) by marking posts as follows:
If it helped - KUDOS
If it answers the issue - SOLUTION
0 Kudos
Message 2 of 8
(3,893 Views)

According to the manual, you need to set the Flow Control to XON/XOFF.  Also, using the Bytes At Port is typically not a good idea since it causes some weird things to happen.  But without knowing the exact format of the data, I cannot recommend anything there.

 

Are you getting any errors?


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 3 of 8
(3,892 Views)

Thanks for you help you are right XON/XOFF was set in my original Vi i forgot to copy this over the the Vi i posted.  however it did make a difference i guess because i have set this in the device manager/MAX.  Could you elaborate on weird things happening when using 'Bytes at port' i have always used this but i'm not aware of any issues.

 

To get it working i am using Minions suggestion of looping until i see data from the bytes at port property. but i am now wary of this from what you have said.

As for error messages, i am only getting a warning of 1073676294 which i believe is ok.

0 Kudos
Message 4 of 8
(3,856 Views)

The issue with the Bytes At Port is when it is used to tell the VISA Read how many bytes to read.  In most devices, the serial data is in an ASCII format and the message ends with a termination character (typically a Carriage Return and/or a Line Feed).  So to get the entire message, we just tell the VISA Read to read more bytes than is expected in a message and it will stop when the termination character is encountered.  By using the Bytes At Port, you are expecting the instrument to have sent everything, but this is often not the case and so waits are added.  But then it is found that the waits are not always long enough.  And it just turns into a very weird race condition.  In short, use the protocol instead of blindly reading how many bytes happen to be in the port.

 

Now the trick I have made with the Bytes At Port is for when devices intermittently send data (not at a fixed rate, only when something changes, etc).  I just use the Bytes At Port to see if any data has come in (ie a message has at least started).  If there is data, I then tell the VISA Read to read more bytes than I expect in a message.  If no data, then wait.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 5 of 8
(3,853 Views)

Dave,

 

There are many cases in which the Bytes at port excels.  A couple of examples are when you are using it to handle a handshaking protocol, or to check for a particular packet length.  crossrulz is correct that it should not be used in most cases.  We have certain handshaking protocols in which we check to make sure that the correct Byte is read within a certain timeframe and then respond to that accordingly.

Help the Community (and future reviewers) by marking posts as follows:
If it helped - KUDOS
If it answers the issue - SOLUTION
0 Kudos
Message 6 of 8
(3,850 Views)

The data being received is acsii and is like this,

\r\n
2017-04-19,13:34,20.8,C,34,%\s\r\n
2017-04-19,13:34,20.8,C,34,%\s\r\n
2017-04-19,13:34,20.8,C,35,%\s\r\n
2017-04-19,13:34,20.8,C,35,%\s\r\n
2017-04-19,13:34,20.8,C,34,%\s

 

based on this data are you saying i am best to loop reading only 33 bytes at a time and check that the string contains ',% ' rather than use bytes at port? 

 

0 Kudos
Message 7 of 8
(3,844 Views)

No.  You should just tell VISA Read to read something like 50 bytes.  The termination character (default is a Line Feed) will stop the VISA Read.  So each read should give you a single line of data.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 8 of 8
(3,841 Views)