Consecutive VISA writes and read

[Hikoya]

Hello all, I am a new LabView user doing a project to create a monitoring dashboard for my sensors. All these different sensors communicate using serial AT commands, and only in a single serial port. I have 4-5 different sensors with their own device IDs and I am required to read all of them consecutively using VISA write to write the AT command, then reading from the result and splitting the string to get the values needed (Voltage, Current etc) to display on the indicator.

The problem I am facing now is that some devices are shutdown and produce an ERROR message when I write an AT command to it, this in turns jams up the rest of the chain and the subsequent sensor does not write the message to it and get their own sensor.

To have a better understanding of what I mean, I have attached the VI file and here is the expected result

Write: at+uc=000195000000B3DA,?

READ: ERROR 

Write: at+uc=0001950000007FA0,? 

Read: OK

Read: +0001950000007FA0 I0.04 T25.42 E23.3 

However, when I write the first command, it will just jam the second one, resulting in no reading for BOTH serial nodes. And since the values are in real-time, I have to switch between them quickly in a loop so I can get the latest value for the second write.

I am stuck for the past few days and I have no idea what went wrong. Please help me!

Some other details:

Serial Port: COM4, Baud Rate 38400, Termination Char is \n

[RavensFan]

DON'T USE BYTES AT PORT!

You have a termination character, take advantage of it.  Just read a number of bytes that is larger than the longest message you ever expect to get.  The VISA Read will terminate when it sees the termination character.  It will allow you to get rid of the wait which will make your communication more efficient, and more accurate (suppose the device takes longer than the 50 milliseconds you allocated to respond?)

If the "bad" sensor returns "READ ERROR", I don't see why that would affect your later communications.  But what you can do is set up a case structure that determines if that string has occurred, and handle it accordingly.

If you have an actual communication error, an actual error on the error wire.  Then you need to do something to handle it.  Having the shift register on the error wire will kill all future read/write activity on the later loop iterations.  And that error wire going into later VISA reads and writes will also keep those from executing since most LabVIEW functions will not execute if they have an incoming error.

[Hikoya]

Thank you for the help.I have since changed the code to include a 50 byte count limit as my messages are around 40+ bytes long, and removed the error wire in case it is a hardware error (only in charge of software). However, the issue I am facing now is that, while the second AT command ("at+uc=0001950000007FA0,? ") returns the values almost instantaneously (expected as I am trying to do a real-time system), the first AT command ("at+uc=000195000000B3DA,?") takes approximately 9 seconds just to return the "ERROR" message, which in turn jams up the entire system. Is there a way to run both write commands simultaneously or implement a timeout that skips to the next command after eg 2 seconds?

I have to implement 3 other sensors (total of 5) where I will be switching from and I hope not to see cumulative delays 😞

Thank you so much for your help

EDIT: I am actually trying to edit one of the existing VIs that the previous team left behind, the problem with that VI is that the values are not updated fast enough. (multiple spmu )

[Blokk]

Do you have a user/spec manual for these serial devices? Such manual should give all the details to decide the proper communication technique.

Besides, what is the used serial protocol? How did you connect the single serial port to your multiple devices? Is this RS485??

[RavensFan]

The problem is with your device.  If it takes 9 seconds for it to return the error message for a bad command, the only solution is to not to send a bad command.

You could shorten the timeout for the VISA Read with the Serial Configure.  But the problem is that eventually, the device will return the error message, and it might be right after you moved on to your next command and while waiting for its response.  In that case, you'll have to read the error, then ignore it and go back to waiting for the correct response.

Or worse, the device will send the error message while the later devices are replying and the message just gets garbled.

The real solution is to not send a bad command.  That, or don't use devices that are so poorly designed that they take 9 seconds to return an error message.

[Hikoya]

Hello all, thank you so much for the prompt responses. I really appreciate it!

I am actually using a USB to Serial dongle that communicate using a Zigbee USB Adapter ProBee ZU10 so I can write different AT commands to get different data 🙂

I have stopped using the defunct devices that return the error and used other devices instead

Here is the AT command I am sending and the responses. The responses are multi-line:

WRITE: at+uc=0001950000007FA0,? 

Read: at+uc=0001950000007FA0,? 

Read: OK

Read: +0001950000007FA0 I0.04 T25.42 E23.3 

WRITE: at+uc=000195000000807A,?

Read: at+uc=000195000000807A,?

Read: OK

Read: +000195000000807A I10.04 I20.31 I30.23 etc ...

As adviced by RavensFan, I have used a fixed 60 byte constant for my VISA reads and get the values working. 

Now, when I run the VI, the values will change for SPMU2, then change for DC Load for a short while (the for-loop), then pauses for an awkward amount of time which I find it weird as all other buttons were off, meaning the VI is only switching between these two. 

Is there a way to do parallel serial writes and reads on the same port? Or is there any example for "real-time" monitoring of values? I have been stuck in this for about a week before mustering the courage to post this question, I apologise for my ignorance.

Attached below are some of the methods I have tried:

Method 1: Using a single while loop for the entire VI and then check if button is turned on, if on, then write and read from serial port, the same serial port is opened before the loop and shared throughout 

Method 2: Using VISA open to duplicate the serial port and try to run them concurrently with their own set of AT commands to write and read from

Method 3: Using method 1 example, but I have a for loop in each case structure in case the read doesnt produce the result that I want

Method 4 (Original): Using a flat sequence, repeatedly open serial port, write and read in a for loop, then close serial port, and move to next sequence. This is the one that was originally in th project given and was shot down for being too slow and "not-real-time", and this is the problem I am trying to solve!!!

Which of the methods is the most feasible, or is there another way in which I can tackle this problem? Thank you so much!

[RavensFan]

What happens if you write out multiple commands to different devices?  Do the devices, at least occasionally, try to respond at the same time thus turning what would otherwise be two valid responses if they were separate into garbage?

You can certainly read and write to a give serial port in multiple locations.  I wouldn't use multiple VISA Opens or Configures, just split the purple VISA wire.  But that starts going against the idea of what a serial port essential is, a "series" of commands and responses.  (Technically, serial means the bits are transmitted in series, but common implementation of serial communications means the messages are basically sent in series.)

Do the responses have enough data in them that if you received them out of context of what command you just sent, would you know what the data meant?

So if you said "give me the value of sensor1", does the device respond back with "9.99"?  Or come back with "sensor1=9.99"?  If the former, you can't do much because you won't know what the response is related to without know that immediately before that you asked for sensor 1. For the second, you could have a separate VISA Read loop that reads all messages and decodes what to do with the responses.

But like I said before, if you write out "Give me sensor1" followed by "Give me sensor2", and the messages come back at the same time, you could get one message that says "SenSe1nsoror2=9.9=899.88".  How would you decode that?  Or worse "$%^^%$;lasdj&*(" because both devices sending data on top of each other will scramble things at the bit level, possible giving you framing and parity errors along the way.

[Hikoya]

Thank you for your prompt reply, RavensFan. To answer the first question about devices occasionally responding at the same time, I am not sure because I had not seen the actual hardware since it was done by a separate team, whatever they gave me was what I had. 

As for the second question, they do! Each response have its own unique ID tagged on to them, like "+0001950000007FA0 I0.04 T25.42 E23.3" has a device ID 0001950000007FA0 , which is then fed through the string match function and then split to its own variables

As for the messages coming back at the same time and colliding with each other, I would like to just ignore them as I will be hoping to send multiple write commands at high speeds (since baud rate is at 38400)

[RavensFan · Accepted solution]

Then I think you can make what you want happen.

Split your VISA reference wire after configure or open the VISA port and send it to multiple locations.  Most of those will be where you write out to the various instruments.  Ideally, you might just have a single loop that sends the commands for all.  Pace the commands at a reasonable rate.

Have a separate loop that performs the VISA Reads.  Try to use the termination character so that you know you are getting complete packets of data.  If you get OK or Error in the message, or you get framing errors, then discard the message and do nothing.  When you get a valid response, decode what the response is so you know where it came from and for what parameters, and then handle the message accordingly,  (i.e.  update sensor 1 indicator,  update sensor 2 indicator, ...)

I'm not guaranteeing this will work flawlessly, but it could be a starting point for what you are trying to do.

[RavensFan]

Actually I'm not as confident as I was that this will work.

I don't recall you saying what type of serial interface you have.  Is it RS-485 4-wire?  2-wire?  RS-232?

RS-232 is a one to one communication, though there are devices out there can can piggy back signals.  RS-485 is multi-drop.  But if it is 2-wire, that means transmits and receives are happening over the same pair of wires.  So you could even get a conflict of having the LabVIEW program trying to transmit a message while a device is sending a response back.  I had only touched on having two devices sending responses at the same time and conflicting.   Having your PC possible conflict with responses just increase the chances of problems if you happen to have RS-485 2-wire.