Labview is randomly dropping 4 or 5 bytes from the front of serial reads

[JDorsey]

I posted about this in the VISA forum, but there appears to be no traffic, and this appears to be a software problem anyway. I have a serial device which is supposed to echo any commands you send it and then come up with a firther response. My problem is that LabView is dropping the first 4 or 5 bytes of the echo, and there's no clear pattern about whether it's 4 or 5 bytes. Using a terminal I can get the desired response:

$ echo -en '\xFA\x30\x4\x43' > /dev/ttyr02

$ od -x < /dev/ttyr02
0000000 30fa 4304 30fa 4304 30fa 050a 2e06 010a
0000020 9478

This is doing the right thing at the operating system level, but Labview consistently refuses to read the first 4 / 5 bytes. Has anyone seen anything similar in the past? I'm tearing my hair out. The thing is, I can use LabView to write random bytes to one serial port, read from another through a null modem cable, and whatever I write comes back fine. So there's no consistency. Is 0xFA some sort of special character of which I should be aware?

[RTSLVU]

Post your code so we can see how you are reading the serial port.

[crossrulz]

Even after reading your other thread, there is no advice we can give you until you show us some code.

These are the common reasons for the errors you are describing:

1.  You are initializing your serial port with each write and read (this is a big problem since you should only configure your port once at the beginning of your program and close it out at the end).

2.  You are using the Bytes At Port immediately after your write and you therefore don't get all of the data.  Ideally, you should be using a termination character (usually a Carriage Return) to signify when the message is complete and allow VISA to stop the read on the termination character (ie, do not use the Bytes At Port).  But if you are not using the termination character, you will need to add a delay between the write and the read.

[JDorsey]

Code is attached. It's just the LabView example code from the instrument manufacturer. I should add that exactly the same code works well on LabView in Windows XP and 32-bit Linux (kernel 2.6). The forum software won't let me upload the offending LLB (The contents of the attachment doesn't match its file type.) but as I said, it works. In fact, here it is:

http://data-dump.org/Keller_S30_Control_Linux.llb

1. Serial port is initialised once and closed once - not with each read and write.

2. I am not using bytes at port. The software initially  reads a fixed number of bytes, then decides how many further bytes to read based on the response. In any case, it's the start of the message that's missing, not the end.

Thanks for your help - this is driving me mad...

[JDorsey]

And a simplified VI which does a similar thing. In the screen shot, the response is correct, but is missing the echo of the 4 byte polling command from the front. The response should be "FA30 0443 FA30 0A05", but I'm only seeing the second half of the message.

[JÞB]

Well I saw the llb come through.

OH MY! llbs, stacked sequences, a strange modbus protocol  (Command, Address, Size[as ASCII TEXT!], Data1-N, crc16) and an echo on/off mode with no NAK message!  

Or FA30 is probably translated as "Broadcast 0 byte message" + the crc16 to which we expect all devices to respond with echo and info arbitrating the bus probably with hardware handshaking.  

Frankly its going to be fragile.  And the developer obviously had a heck of a time trying to get it working with all those "Bandaids" in the code.

E.G.  Each message transaction starts with reading bytes at port followed by a 0xC0 buffer flush???  Why not just use 0x90 flush?

The sad part is that if he had done all the VISA I/O Synchronously, the hardware race conditions would have cleared themselves  and then he would only need code to cover the case where message was recieved garbled at the far end.

[JDorsey]

Interesting observations. I couldn't tell whether it was an "interesting" coding style or the product of a disturbed mind. However, the really simple VI I knocked up does exactly the same thing as the manufacturer's code. I'm now doubly confused, because I can reliably write each hex value from 00 to FF and read it back in through the same serial - ethernet converter...

[JÞB · Accepted solution]

Did you try thw VISA writes and reads set to Synchronous?  like a terminal or terminal emulators use?  Right click the functions and select Synchonous (the clock in the icon should dissapear.

And the FA  would be 4 ones to get attention folowed by 1010 for clock recovery on the far end

[JDorsey]

You, sir, are a genius. Have a Kudo...

[JÞB]

It is all in history.  DC loops were the beginning of serial coms.  Several avenues were taken to automate the way it worked.  I guess Morse code was too Dependant on humans to be considered robust.  Manchester walked many of those paths.  This is an example of firmware generated by some student learned from a great teacher who likely died of old age about the time the transistor was invented.

It is not uncommon to see antiquated constructs like this.  Even if they use mixed bags of old means.  FA as a broadcast header is really old.  ASCII Size fields means modem speeds at near human typing speeds.  The crc 16 was likely an enhancement added in the sixtys when the bench full of relays was replaced by an ic.  Ramp that network up to real speed and slap a multicore processor and modern OS on it!  It breaks funny.