How to read information from RS-422 protocol

[constructionworker]

Thank you for your detailed explanation, Mr. Rolf Kalbermatter.

I think it will be more understandable if we do the situation as follows. I just try what you say and give you the result. Please tell me what this means, at least I want to understand that I am on the right track, I don't want to take any more of your time.

In principle, if 7-bit, space parity, and 2 stop bits seem to be working, 8-bit, no parity, and 2 stop bits should work and return exactly the same data, if not, something strange happens.

-As you said, I did a test like this: I set the data bits: 8, parity: None, Stop bits: 2.
The result is the same as in the attached photo.

So your Reading process needs to add cleverness to do this. You cannot perform a VISA Read and export its data to your parsing routine, but you must first write a routine that takes the data, checks if there is a full data frame and if not, loop back and read more data until possible. Provide a complete and valid data framework to your parsing code. So this means you have to write some code that loops (uses a loop) and reads the bytes from the serial port over and over until it gets a full frame of data, before going back to the rest of your code. And this code needs to be smart enough to exit this loop if any of the following conditions are true:

-I really want to investigate exactly how such code should look, but I don't know how to create such code.

Much of this debate, prediction and miscommunication could also be potentially avoidable if we knew exactly what kind of device it was and had a datasheet to look at.

-I don't know too, just know hardware '' ISL4489E, ISL4491E ± 15kV ESD Protected, 1/8 Unit Load, 5V, Low Power, High Speed ​​and Dial Speed
Limited, Full Duplex, RS-485 / RS-422 Transceivers were used. As I know this, the help of someone who knows how to comment on the results is needed.

[constructionworker]

I made a combination change after Mr. Rolf Kalbermatter suggestion.

that weird rectangular square does not appear at the beginning and afterwards. Of course now I get a printout like the picture.

I actually get the same values after the change but I guess it just changed somewhat.

Sometimes the starting value and the trailing place change value because the ending character cannot be determined exactly.I don't know if I'm on the right track.

[rolfk · Accepted solution]

It's always hard from a single picture but from what I see it seems you read 20 bytes each time and that results in 2 frames containing

0x88 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x08 0x0D

So the 0x88 seems to be the first byte, with the highest significant bit set. And that would have violated the space parity you had configured before.

My approach would probably be to enable the termination character and set it to 0x0D, then write a Receive VI that reads in a loop data from the serial port with number of bytes set to 10. This VI needs to search for the 0x88 byte in the data which apparently marks the start of message (possible it could contain other data too, but with the highest significant bit always set so any byte value equal or bigger than 0x80 would indicate the first byte). Then see if you have 10 bytes left in the message and the 10th byte is 0x0D. If not, loop back and read once more and append that data to the previous bytes and check again. To avoid this loop to block on unexpected situations you should break it whenever there is an error other than timeout from the VISA Read or your own timeout has elapsed.

This is a quick and dirty attempt to write such a function based on the several assumptions I explained above. It may need modifications to really work reliable with your device and it assumes that you do enable the Termination Character on the VISA Serial Port Config function and set it to 0x0D. It requires a lot more testing and debugging, also with trying out any possible joystick position and button press to see if it works reliable.

On a second thought it probably also works without enabled termination character. But if you do not call this in a loop that is fast enough to receive every single frame that your device sends, it will fill up the receive queue eventually as it only retrieves one frame each time.

[RavensFan]

Just to regroup here, I've heard a number of different byte counts thrown around, 10, 11, 12, ...

Looking back to message 7 and this attached image.  It appears that there are 9 bytes in the message and the message always ends in x0D

You really need to determine how many bytes make up a full message.

[rolfk]

Those 9 bytes was with 7bit, space parity and 2 stop bits. The 0x88 character that now appears as first byte was invalid with that parity setting and therefore likely never made it through the serial port driver. With 8 bit, no parity and 2 stop bits the frame now seems to be 10 bytes with that 0x88 character at first. Most likely the character might not always be exactly 0x88 but the highest significant bit will be set, so hence checking for the byte to be >= 0x80 in my code.

[constructionworker]

I set the "VI" you sent as follows and tested it.output results are also the photos named "Front panel".

After pressing the run button the outputs come and the "VI" stops. Is this normal ?

After pressing each button, after the "VI" is stopped, sometimes the same values appear, sometimes different values.I saved each changing data value as a photo.

After the VI is stopped, I run it again, mostly it shows values like the Front panel-1.png photo, sometimes it shows values like in the other photos.

What is the reason the data changes this way?

Thanks for your help

[rolfk]

---

@constructionworker wrote:

I set the "VI" you sent as follows and tested it.output results are also the photos named "Front panel".

After pressing the run button the outputs come and the "VI" stops. Is this normal ?

Yes of course. That VI is written to receive exactly one full frame of data. Nothing more and nothing less. It is meant to be used as subVI much like you did use the VISA Read before! You really should do some LabVIEW course material to learn about LabVIEW programming.

After pressing each button, after the "VI" is stopped, sometimes the same values appear, sometimes different values.I saved each changing data value as a photo.

After the VI is stopped, I run it again, mostly it shows values like the Front panel-1.png photo, sometimes it shows values like in the other photos.

What is the reason the data changes this way?

That's because as I said, it is a quickly hacked together VI and there is very likely still some bad logic in there. Without the device in question it is pretty much impossible to test and debug it here. So that job is left to you. But that's one reason why I hesitated to post that VI. Your LabVIEW experience is clearly very limited and without being able to understand what the VI does, it is pretty much impossible to debug it.

One obvious problem you did is to clear the error at the end instead of showing it on the front panel. Those invalid data are most likely caused by an error in one of the previous VIs, most likely the VISA Read, which will cause the loop to abort and without showing that error you will never know and just wonder why there is not the full 10 bytes returned.

[constructionworker]

You are right, I'm still trying to learn labview. However, I can comment a little on the way this code works.
I understand this code is for determining the start and end bytes, but I don't understand why it sometimes shows different values. This sometimes gives the following error code: Error code -1073807298 and 1073807253.1073807253 Error -1073807253 is a framing error but I don't understand what caused the other error code.
What is the reason for the data that changes with each reading? I didn't understand him
So do you think I'm on the right track? or rowing in vain 🙂

[rolfk]

Framing error means that something with the parity, start and stop bit is not matching what arrives on the wire. And no, changing back to 7-bit and space parity is certainly not going to make it better. If 8-bit and no parity doesn't work, 7-bit and space parity can only work even less.

[constructionworker]

I think this combination works better. I am getting no errors right now after doing a fix and the values don't change. It always stays the same.my change is in VI below.If there is no error in this way, does this mean that in the next step, the termination bit is 0x0D.