"Standardized" (Fixed) Output Format... - Printable Version

+- Forum (
+-- Forum: General Discussion (
+--- Forum: Feature Requests (
+--- Thread: "Standardized" (Fixed) Output Format... (/showthread.php?tid=549)

"Standardized" (Fixed) Output Format... - David_Schofield - 02-12-2020

Love my board, and it's helping (forcing) me to learn Python for my application!
One of the current features of the board is that "If no known protocol is detected, the input will be turned off and data for that axis will not be sent to the application."

If you're rolling your own application, this feature means additional parsing and conditional logic needs to be present in the application.
That's no big deal for anyone but beginners, but most industrial and scientific equipment interface protocols I've worked with over the years features a "fixed" or standardized output. That is, instead of not sending the data at all, they'll send an empty/off/NC/NAN indicator for that channel.
I would love to see this implemented, so that if there's no W/X/Y/Z axis you at least get a placeholder in the data stream, if not a minimal diagnostic. 
Also, most ASCII output instruments I've worked with uses a cr/lf pair to indicate end of record.
So rolling that all together, here's an example:

I have scales connected only to the X, Y, and Z inputs (not W, so it's No Connection), but Z seems faulty and can't be read. So I'd get...

Variations on the theme might minimally be
W:;X:1275;Y:6593;Z:;cr/lf  (empty data variant)
W:;X:1275;Y:6593;Z:FAULT;cr/lf  (empty data+fault indicator variant)


Thanks for your consideration!

RE: "Standardized" (Fixed) Output Format... - Yuriy - 02-15-2020

The reason most [older] industrial protocols use the fixed message size was performance. The devices simply didn't have enough computing power to parse a protocol that uses "regular" grammar, let alone "context-free".
Modern android device (or frankly, even an Arduino) won't have any problems dealing with regular grammar so there is no point in sending all the extra unneeded stuff down the wire.

Parsing TouchDRO protocol is beyond trivial: you need to code a basic finite state machine with a small handful of states: "Reset", "Expecting Axis Label", "Expecting Sign or Digit", "Expecting Digit", "Expecting Digit or Terminator", "Terminator". When you reach the "Terminator" state, send the position to the UI thread.