LabVIEW Serial NAK Response

[JÞB]

---

@rolfk wrote:

---

@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.

---

And my point being that the ETX is both part of the data integrity calculation AND that is the only means to determine that the sent data ends after ETX+2bytes.  Requiring two reads with different end modes to receive all bytes without timeout.

If you saw this when walking in a pasture,  you would avoid stepping in it!!!  Yup, I see and call BS.

[crossrulz]

---

@JÞB wrote:
And my point being that the ETX is both part of the data integrity calculation AND that is the only means to determine that the sent data ends after ETX+2bytes.  Requiring two reads with different end modes to receive all bytes without timeout.

---

Yes, we all agree it is a weird protocol.  Let's move on instead of arguing over tiny details.  Yes, I am yelling at myself as well.

[rolfk]

The point is you can leave the end mode as is for reading the two CRC characters since the CRC byte is encoded in two ASCII bytes so it is impossible for these two bytes to contain ETX.

Weird yes, but still fairly sane. I’m out of here 😀

[BovineJoni]

Thanks so much for your help!  I'm still learning LabVIEW so I always appreciate knowing how people usually organize their code.  For context, this is part of a larger control system I am making.  I want data from a variety of sensors to be visible on a panel with some user interface options (toggling valves and whatnot).  I'm using a cRIO-9057 and have followed NI's tutorial for a realtime system, so I have a decent idea of how to break up all the different parts.

One question I still have: do you typically open all the serial ports you want to use as you start the control panel, and close them when you stop running the panel, or do you open and close the port in the VI you use to pull data from a sensor?  So far, I've been opening and closing the ports every time I query a device.  I also using maybe 10 different serial ports for the various devices, but I doubt that matters.

[crossrulz]

---

@BovineJoni wrote:

One question I still have: do you typically open all the serial ports you want to use as you start the control panel, and close them when you stop running the panel, or do you open and close the port in the VI you use to pull data from a sensor?

---

Open the port at the beginning of the application and close it at the end.  Opening and closing the port is a lot of overhead that you are better off avoiding.

To see an idea of how I structure my code for serial communications, you should check this out: VIWeek 2020/Proper way to communicate over serial