LabVIEW
LabVIEW Serial NAK Response
Solved!
@JÞB wrote:
- If your FW engineering staff insists on using STX immediately follow this with the U16 length.
- Term Character should NEVER be part of a message integrity calculation.
- Term Character should NEVER have any message part postpended to the message.
I consider these mostly rules for good practices, not something like one of the 10 commandments. 😁
Take your second rule, yes it adds absolutely nothing to include a constant value in the integrity check, it even wastes one extra XOR calculation of performance. But it doesn't make the implementation of either the sender or receiver any more complex.
Same about the third rule, yes it makes the handling slightly more involved but not in a very significant way.
The most weird part about this protocol is the fact that it is basically ASCII based in its message structure but uses binary STX and ETX message boundary signaling.
@JÞB wrote:
@rolf
I did edit my reply.
Do you remember Teletype terminals?
Those SPECIAL ASCII Characters actually mean things to 'Ye Olde" terminal. Start TeXt and End TeXt are placeholders bracketing START OF & END OF message characters. Whitespace, such as CR & LF are also useful.
I'm actually old but I never operated on teletype hardware. My father did use a Telex machine on his job. 😁
I can reverse engineer the device's communication routine from the documentation that the OP linked. I cannot justify that routine via code review.
In most cases, instrument communication without the actual manual is anyhow hopeless. And in almost all cases even that manual has at least ambiguities or sometimes simply errors that do not match the reality.
@rolfk wrote:
A few rules I handle myself:
- Try to determine the actual end of message character, as in this protocol seen, it may NOT be the last byte in a message but if what follows is constant in size there is not a big problem.
- Use the VISA termination character handling on Reads to deal with this termination character.
- Do NOT use the VISA termination character appending on VISA Writes but instead handle those characters explicitly when generating the message to write.
- Try at all costs to avoid any form of delay or similar function in your communication code. It is in 99.9% of the cases an indication that you have not yet understood the protocol properly.
- Never ever use Bytes at Serial port for anything else than to determine if there is actual data to process. Using the Bytes at Serial Port value to determine how much data to read is in 99.99% of the cases the completely wrong thing to do. And those 0.01% you will never come across!
These are excellent rules to live by. I'll have to save a link since you put them so well. I'll just add one more that mostly applies to binary protocols: use the protocol. It's not always pretty, but using the protocol in the read process will save so many headaches.
@rolfk wrote:The most weird part about this protocol is the fact that it is basically ASCII based in its message structure but uses binary STX and ETX message boundary signaling.
I don't find those weird at all. I have dealt with enough old devices that use those (Start Text and End Text). Setting the termination character to 0x3 (ETX) is typically all that is required other than the normal default settings.
Now thinking back, my first encounter with serial communication used those characters in a raw/binary/hex communication scheme, which is weird. I was young and dumb then and I did everything wrong with it (I was still in college working as a co-op). I somehow got it to mostly work. Nearly a decade later I figured out what I did wrong as I had to reverse engineer the protocol for a torque meter (the only thing worse than no documentation is wrong documentation). Still, all I can say is that I am not so young anymore.
@JÞB wrote:
Well, now you know that the "RS" in RS-xxx is an abbreviation for Recommend Standard! Including ASCII Character usage as it prints from tty, and not simply the physical layer!
Don't get me started on the "RS-422 only defines the physical layer" rant. To put it short: if you have a serial communication over RS-422, a normal engineer will assume UART. And we all know what assume stands for...
A design engineer told us we were to communicate with a device over RS-422. We specified a standard RS-422 card to put in a test rack. Luckily before we ordered anything, we were involved in a design review and found out it was actually using Manchester Encoding, not UART. There was a lot of shouting about us being lied to. The design engineer would just reply "RS-422 only defines the physical layer". We ended up having to get an R-Series PXI card and I learned LabVIEW FPGA the hard way.
@crossrulz wrote:
@rolfk wrote:The most weird part about this protocol is the fact that it is basically ASCII based in its message structure but uses binary STX and ETX message boundary signaling.
I don't find those weird at all. I have dealt with enough old devices that use those (Start Text and End Text). Setting the termination character to 0x3 (ETX) is typically all that is required other than the normal default settings.
My point was that STX and ETX are often used with binary byte (hex) protocols (and the protocol then needs to provide a mechanism for byte code escaping if one of these bytes happens in the data portion). Here both the actual message as well as the CRC portion are ASCII encoded but wrapped inside STX/ETX. Not a very common thing to do. But while not common it's not a problem here, the ASCII encoding makes sure that the actual STX and ETX byte can not happen in the data portion so no escaping is needed, which makes especially the receiving side a lot easier to implement. Receiving data with byte code escaping, because data bytes can match signaling bytes, is quite a cumbersome thing to do.
