Various message length in serial port communication

[bikekowal]

1. I just set up com port and baudrate and thats it. I dont use any of things you have mentioned but I will try.

2. I dont get any errors.

3. I will try with the indicator and see what will happen.

[johnsold]

1. If you just set the port and the rate, then you have termination characters enabled by default and the default character is Line Feed, hex 0A.  Handshaking is off by default and should remain off unless your protocol uses it.  If the character 0A ever appears in the data, the read would be terminated with fewer characters than specified by Byte Count.  The 0A character will not be returned in the output data.

The termination character enable input is at the top of the Configuration VI but does not apper in the Context Help window.  This makes it easy to overlook.

The default timeout is 10 seconds.  If the Read times out, an error is generated. So that is not likely the problem.

Lynn

[bikekowal]

The protocol does not use a handshaking, thus in my opinion the connection is established properly (it has proper parameters). I don't receive any errors from labview so the problem must be somewhere else...

[johnsold]

Have you disabled "enable termination character?" at the configuration VI?  You must do this expicitly because it is enabled by default and the input terminal to disable it is semi-hidden.

Lynn

[bikekowal]

Yes, I have disabled "enable termination character". The result is still the same. 

[rolfk]

Actually if you are sure that the end of message is always 4352 you could enable the termination character and set it to 0x52 or 82.

Your protocol handler will then somehow have to determine if the received message is really the end or a possible 0x52 character encoded in the data section and in that case do another read until you see the proper termonation. One possibility could be that the protocol inserts a 00 byte or something else than 0x43 in front of every 0x52 byte.

But your description is definitely flawed as none of the strings you show contains 9 bytes between the header and tail and the header is never FC0009 but always FF0009

[bikekowal]

---

rolfk wrote:

But your description is definitely flawed as none of the strings you show contains 9 bytes between the header and tail and the header is never FC0009 but always FF0009

---

Yes, you're right, my mistake. It is obviously FF0009.

I set the 0x52 as a termination character and now I have to situations - good and bad.

Good looks like at the first screenshow (err-kopia) and bad  (err2-kopia) - at second shot. Now both the strings contain proper information, but the second one (bad) has also some prefix. There is a question now how to get rid of the second case?

regards,

Marcin

[johnsold]

There is still something going on which we may not be able to guess from a few data samples.

Please look carefully at the protocol document to see if it defines when the extra 00 characters are transmitted, or if they are transmitted at all.  As Rolf pointed out some protocols insert extra bytes to mark special characters in the data.

Please post your VI, not an image, so we can look for some subtle setting which may be the reason for your results.  If possible, run your VI until you get one of the erroneous messages displayed. Then Make Current Values Default, Save, and post the VI with the saved data.

Lynn

[bikekowal]

The VI with fixed values enclosed.

regards,

Marcin

[johnsold]

There is no received data in the VI you posted.  When you run the VI and get "bad" data showing in the "read buffer" indicator, stop the VI. Pop-up on "read buffer" and select Data Operations >> Make Current Value Default.  Then Save.  This will keep the received data in the indicator.

Lynn