Serial Framing Error with no termination char set

[Furbs]

There are lots of posts about framing errors but most are a decade old. I've confirmed all the settings with the manufacturer for baud rate, bit count, and frequency. He's writing in Python which looks like it uses default stop bit and parity. I've also tried other settings just to see.

I'm getting data but not the right amount and nothing I can make sense of. There's no termination char at all.

I can't think of anything to try next. I've tried polling faster and slower but I never get multiples of 86 bytes, which is what they are sending.

---

Does LabView do any extra work on a read that could be messing me up, like when it translates to ASCII instead of giving me the binary directly? Is a frame error ALWAYS related to the wrong serial settings or is there another setting? Should it be ignored sometimes?

[RTSLVU]

Most serial communication issues can be solved by watching this video: VIWeek 2020/Proper way to communicate over serial

[Furbs]

Thank you for the link. I watched the sections on Binary Reads. I created a fresh VI to mirror the one in the video at the end. I am no longer getting a framing error, though I'm still not sure what was causing it. Why would labview think I have a framing error when it has no idea what the frame should be? I am being sent a mix of data, uint8_t, uint16_t, uint32_t. Maybe that is causing issues if it assumed all the bytes are the same type and doesn't like when something comes in smaller or larger?

However, I still rarely see the start byte for the protocol. When I run their python application to read the data, everything is great, but I don't receive  0x7B in Labview but once in a blue moon. Assuming they are sending it and there's nothing weird on the python side, are there any setups that need to be changed when reading ASCII vs Binary/Hex data? It's not a timing issue, because even if I buffer for 10s, then scan the bytes, I dont see the start byte when I should see 10 of them. Something is wrong on a very basic level if they are sending a 0x7B and I don't receive one. 

[K C]

Hi,

Used LabVIEW many time to read serial data.

Can you tell me more about the protocol you are trying to read ?

But before you can try to read the protocol first the framing error must be solved.

The framing error occurs if the transmitted data frame is not Ok. Baud rate or number of bits is wrong. 

Can you share more information ?

Kees

[Furbs]

I am talking to an arduino with custom python code on it. They have told me it communicates over the RS422 bus at 115200 baud with 8 data bits, no parity, and network (big-endian) byte ordering. The start byte is 0x7B. 

They have not confirmed the stop bit but I assume it's 1. Looking through their code, it doesn't seem to specify and python's serial library has a default of 1. I've tried others, and it doesn't seem to make a difference. 

I am currently just reading streams of data, but I rarely see 0x7B. They are sending data at 1 hz but but I get a 0x7B anywhere from 1s to 90s later. At this point I think Labview is twisting my binary data somehow innately when it tries to convert it to a string or maybe the card is bad in a subtle way. Unfortunately, I do not have any other 4-wire RS-422/485 devices to test with to confirm that the card itself is valid. 

Again, my proof that they are sending exactly 86 bytes and a 0x7B for a start byte is that when I run their GUI python code on a PC to talk to their own code on the Arduino, I can see that stream. But I never get 86 bytes in RT labview. 

The difficulty is that I'm getting mostly expected frames. Its 1 Hz, its between 78-82 bytes. So its not complete gibberish in that respect. But it should be exactly 86 bytes every time. 

[K C]

Ok, I think I understand what you are doing.

I can assure you that LabVIEW does not change the received data. If that was the case I would have many application with a lot of problems.

Is there any change that I can get this code for the Arduino. I have a UNO and en Mega Arduino.

I would like to see the data on my oscilloscope.

Kees

[crossrulz · Accepted solution]

A few things to clear out here:

1. If a VISA Read is returning a Framing Error, that is at the byte transmission layer.  Generally speaking, that points to a mismatch in settings, usually the baud rate.

2. I suspect you have your RS-422 lines flipped (RX+ and RX- as well as TX+ and TX-).  This would cause an inversion of every bit in your data that happens to get read.  It could very easily also cause the UART to through framing errors.

3. You can simplify your code quite a bit by just trying to read all of the data and then use Unflatten From String with a cluster as the data type.  The cluster will need to contain all of the data you want to parse out and in the correct order.

[Furbs]

Unfortunately, since it is not my code, I cannot. I also don't understand all the parts well enough to send a striped down version. I can say that is uses the following commands to send out the serial data. 

import serial
socketio.start_background_task()
serial.Serial(device, baud, timeout=1)
bytearray.fromhex("7B")
serialInstance.write(frame)

We do not have the 100 ohm resistor mentioned so we are starting to look into noise, but its a short run and doesn't even go in a wire tray, so I'd be surprise if there was noise. 

We were originally using a PXIe-8431 and now have a PXI-8431 to confirm the card is good. 

It is RS422. We assumed the pinout would be the standard, but now its looking like online there can be different pin-outs for RS422 possible. The data we are getting is so consistent, I wouldn't think we could have something as basic as the wrong DB9 pinout. 

[Furbs]

@crossrulz, 

1. Maybe if their baud rate is variable, as in 115202, then labview would complain? But they have confirmed that is the right setting. 

2. I actually did try to run some code to flip the bits to see if it would help or see if 0x42 is the opposite of 0x7B and its not, its 0x84. I wasn't sure thats how it would work but tried anyway. I definitely need to confirm the pin out as it is not in their documentation at all. 

3. Unflatten from cluster is a great idea. So far, I've just been trying to cherry pick data to confirm it's right but might as well make a cluster for all of it now, then I can play around with an offset/timing issues or something. 

All of the internet seems to just talk about baud rate when getting a framing error. The code I posted doesn't usually get a framing error, just a warning about not all bytes being read due to the way I'm reading the buffer. I have no idea why it would go away but the data read is still the same. 

[pincpanter]

Keep in mind that:

- VISA just reads from the UART whatever was received (with the current settings), so for any anomaly or framing error, the culprit is either the hardware or wrong settings

- there is no such thing as a standard pin function for RS422 and RS485 (sometimes even adapters of the same manufacturer may differ)

- if high and low states are inverted as suggested by crossrulz, you cannot make a correction by code, since the character START bit (not byte) would be sensed at a wrong position; if this is the case, I would certainly expect framing errors

In general, there is another case (other than with wrong baud rate) where you typically receive framing errors: if you open the serial port while some data are already arriving. In this case, it's possible that the UART receives half a character at first; once the corresponding framing error is ignored, however, the rest of the data should be well received.