Serial communication - multiple read/write in series

[bensulli]

Hi,

I've got a piece of equipment that I'm communicating with using as RS-232 connection - it outputs multiple variables (3 or 4 of interest), and I'd like to record these.  Currently, I have mutiple read/write trains, writing the request to the instrument, and then reading the response.  However, I'm finding that sometimes the wrong VISA Read will read the return, and display the information in the wrong "spot".  Sometimes it works great, with the correct information displaying where it should.  Other times it jumps around quite a bit.  I'm farily new at LabView, so most of my knowledge comes from cannibalizing the "Find Examples" example VIs.

Per the user manual, the transmission should be the following format:

<STX>4AREG<space>K0<space>PRC code (a 3 digit code to specify the metric of interest)<ETX>

With the response following this format:

<STX>4AREG<space>0<space>PRC code<space>Metric of interest readout

I've seen some examples of people adding a delay between read/write events, but with other people commenting that that's not the best way to do it.

I've attached a picture of the layout I currently have (I can also post the VI iteself, it's just got a lot of other stuff associated with it that's not related).

Any help at all would be greatly appreciated!

[JÞB]

OK you Have a send end enable of True and all your string constants end with ETX.  Essentially you are double terminating your writes.  Most Equipment would ignore the double term but, considering the is a STX-ETX protocol I would guess its been around for a long long time and not nearly as forgiving of packageing errors

And show display format on string constants.  use \code display when the strings are not human readable.  Seeing those single "\02" at the leading end of the strings will help you avoid a bad typo

[nathand]

Just to clarify - are you saying that sometimes the values for "FlowRate," "Mass Concentration," and "Total Mass" are in the wrong places? Seems like you might want to use the PRC Code in the response to determine which value you read, rather than relying on the order in which you send the requests. Is there anything else that can cause the instrument to send a piece of data over the serial connection (for example a "Print" button on its front panel)? Or, do you ever send a request but then not wait for the response (for example, aborting your code in the middle)? That could leave characters waiting at the port to be read, which would throw off the order of everything else.