Instrument Control (GPIB, Serial, VISA, IVI)
Serial communication output not working
Solved!
Can someone please explain me the correct way to read from a serial port? In the above mentioned picture, sometimes I read all 0 or sometimes same output two times.
Please free to correct me. I am new to communications in LabVIEW.
Thanks for your help.
Hi
It depends completely on the sending side what you read.
You always send the same command, waits 5 ms and expects a complete answer.
If in those 5 ms no answer comes you get nothing.
If the instruments sends the same measurement again you also can get two messages after each other where you maybe don't see the first zero bytes.
Give us more info. What you do is not wrong but you better use an end character instead of using bytes at port.
Generally speaking, you should not be using the Bytes At Port to tell the VISA Read how many bytes to read. In this case, you could just set the number of bytes to read to be a full message and let the timeout happen if no data comes in time. But to be more robust, you need to use the protocol of the data being sent. To give full details, you need to share that protocol. For more general ideas, go watch this: VIWeek 2020/Proper way to communicate over serial
I removed bytes at port and waiting for the read command to throw error. Its working now most of the time but sometimes it gives me nothing even though I am reading bytes at port greater than 0.
Hi
As I wrote earlier, we know too little to really help you.
What are you expecting?
A stream of data? In badges of how many bytes? Maybe 50 as indicated?
What should be done with this data?
checked? or displayed or saved?
115k is quite fast so make sure you handle everything.
I am sending line 1 and I should receive line 2.
I know how to decode line 2.
I just want this process to be in a loop. I want to change line 1 with different commands and should receive an answer from the device.
The following table is protocol for line 1
The following table is protocol for line 2
You do not have a termination character here to state the end of the message. So if the reply is 12 bytes long, ask for 12 bytes.
Hi
For accepting this protocol, just ask for 8 bytes.
The problem can be that the device has been sending already a few bytes and you have to synchronise to get at the correct boundary for the message. That is why an end character would be nice.
If you are able to add an end character to the protocol it becomes much easier.
Or do you know what you ask then the number of bytes to receive may also be used.
In that case just keep a table of commands with expected answer length, and use number that for the request.
Just what you are able to do.
@Albert.Geven wrote:
If you are able to add an end character to the protocol it becomes much easier.
It is a raw/binary/hex protocol. So a termination character is not reasonable here (the termination character could possibly be in the data).
