LabVIEW
How to read information from RS-422 protocol
Solved!
Hi worker,
@constructionworker wrote:
The data disappears and reappears on the screen very quickly, as this happens, the data is shuffled
The same problem appears as a rectangular square. It appears in the middle of the array. Of course, it does not happen continuously. It happens when the first vi is run. Then sometimes it happens.
Which underlying data values do you receive when this "rectangular square" is shown in the frontpanel?
Can you provide a VI containing such data?
(Once you know which data cause that display you could filter your received data…)
Btw. data usually don't "collide" nor "vibrate"…
Your main problem is that you have no synchronization whatsoever between what your device sends and when you receive it. So while you read some data, this could or could not be an exact data frame and there is no simple way to guarantee that it is.
With serial communication you do not have additional trigger lines from the device that tell you: "Here this is an entire frame, you can now decode it!" instead this information somehow has to be embedded in your data. Except since your sensor data is ultimately binary, there is no simple data byte that can be used to indicate the end of the message as that data byte can occur anywhere in a message too. And I still wonder about your claim that it is 7bit, Space, 2 stop bits. RS-422/485 is usually always 8-bit but especially for RS-485 networks with a special meaning for the highest significant bit. Here when this bit is set it means that the lower significant 7-bits are the network node address that tells which device should receive the message. In principle 8-bit, no parity and 2 stop bits should return exactly the same data, if it doesn't, something weird is going on.
Now let's get back to synchronization. Your receiver code somehow must be able to clearly and without any doubt reestablish the data frame boundaries in order to be able to interpret the data correctly. Otherwise you end up with this "noise" since the data you interpret doesn't really start at byte 0 of the message but anywhere in the middle and then you interpret the wrong bytes as joystick position and buttons.
And your device makes this synchronization fairly hard. If it would send text messages then you could use the built in VISA mechanisme to let it break receiving a message as soon as it encounters the termination character. Since it is binary there is no easy way to let VISA do all the work for you as that termination character 0x0D can theoretically also appear anywhere in the data and then you are introducing even more problems. Rather than just receiving 10 bytes, or whatever your message length is, and HOPE that everything goes right you have to do some more elaborate processing when receiving data. Somehow you have to try to receive data and then analyse it if it can be a valid data frame:
- is the length ok? (there could be more data in the received message since it could contain fractional left over data from a previous message)
- are the two seeming obvious markers of 0x0D and 0x00 at the correct position?
If any of this is not true you need to loop back and read more data and append it to the already received data until you can securely find a valid data frame. Only then can you interpret that data frame without strange "noise". And don't forget error handling. If VISA Read returns with anything else but a timeout error, there is something seriously wrong and it makes no sense to try to loop and read more data!
While this may all sound complicated and annoying, this is what robust device programming is about. Just calling a VISA Read function and hoping that everything is alright, may work for some hobby projects with well behaved devices, but it often is by far not enough when dealing with real world devices that are used in industrial environments.
I would definitely switch to 8-bit, no parity and 2 stop bits for a next test. If that fails with errors, there is no good way that 7-bit, space parity, 2 stop bits should work instead!
Ok lets try again:
RS-422/485 is usually always at least 8 bits, but for some RS-485 networks, the highest significant bit has a special meaning: When this bit is set, the lower 7-bit are the address of the network node that the controller wants to talk with. With this bit cleared, the byte is part of the data message.
In principle, if 7-bit, space parity and 2 stop bits seems to work, 8-bit, no parity and 2 stop bits should work too and return exactly the same data, if it doesn't, something strange is happening. In fact there is a chance that the 7-bit mode returns data with the highest significant bit randomly set, since it is the serial port drivers task to stuff this bit if the data stream itself only contains 7 bits. Most serial port drivers set this to a 0 but some have a bug there and leave it uninitialized and NI-VISA doesn't go and try to second guess the data it receives from the driver.
>If the device sends text messages, you can use the built-in VISA mechanism to let it stop receiving a
>message as soon as it encounters the terminate character.
This is the configuration for the termination character on the VISA Configure Serial Port function. VISA allows to be configured to terminate on receiving the termination character. BUT, your device uses binary communication and even though it seems to use a specific byte at the end of the message you can't just use VISA to do everything for you. This is because that termination character can almost certainly also occur in your data and VISA can't know which of them is a data byte and which is a termination character.
So your Read operation needs to add the smartness to do so. You can't just execute a VISA Read and pass its data to your parsing routine but first need to write a routine that receives data, checks if there is a full data frame present and if not, loops back and reads more data until it can present a complete and valid data frame to your parsing code. So this comes down to you having to write code that loops (is using a loop) and repeatedly reads bytes from the serial port until you have received a complete frame of data, before returning that data to the rest of your code. And this code needs to be smart enough to exit this loop when any of the following conditions is true:
- there is any error other than a timeout error on the VISA Read function
- You have properly received a full data frame to whatever criteria your device uses for a data frame
- optionally: some timeout, you pass into the routine, has elapsed to prevent this loop to loop infinitely if there is no device connected to the serial port
This is the principle operation you need to follow, whenever your device doesn't send messages with a specifically designated termination character that can not occur anywhere else in your message.
A lot of this discussion, guessing and miscommunication could potentially also have been avoided if we actually knew exactly what sort device it is and had a data sheet to look at.
There are many possible options this device could have. Maybe it is using the 0x0D or 0x00 as termination character and has special provisions such as COBS (Consistent Overhead Byte Stuffing) or escape encoding to avoid the occurrence of this byte in the data? We don't know, we only have a few confusing front panel shots of data that may or may not be representative of the data your device sends.
