YADRO'S DRO comes with it's own programming language. That language is a (bit) C-like language, that I call YPL (for YADRO-Programming-Language or Yet Another Digital Read-Out Programming Language). The code that drives the display consists of a few code snippets or macros that interact. There is a big variable pool every piece of code can access. There are some special function calls that interact with the display. The display itself is quite stupid and knows nothing about scaling, offset etc.

Here is a sketch:

The cloud named var-pool is the storage that keeps all the variables. Every part of the program or the macros can access and modify them.
The box "digital interface" on the left is the interface that connects to your digital scales.
The box "display" is the core program that puts all parts together and mainly does the display related stuff.
The 3 gray boxes MacX, MacY, MacZ are special macros (in reality, they don't even have a real name and are no macros, but expressions) that process the raw numbers coming from the digital interface.
The dashed boxes on the right with MacA…MacD are the user accessible macros. There is virtually no limit on how many you have. The macros Mac1, Mac2, … are internal macros, that act somehow like subprograms. Macros can interact among them and control the display or the digital interface too.

In the current version, I made an extension not reflected in this sketch. The macros MacX, MacY and MacZ can be further extended at runtime by macros that are arranged in a stack. Macros can add and remove pre and post-display macros that "catch" and modify the variables to be displayed right before and after displaying. These macros go in-between MacX(Y, Z) and the display.

YADRO does the following:

1. It triggers reading all (connected) devices from the digital interface. The values read are put into the variables Dev0…Dev4.
2. It then calls the special macros named MacX…MacZ (again, they have no names, you bind macros to axis) that does the scaling, translation, etc. and displays them on the screen
3. It then puts back the values displayed into the variables Disp1…Disp3. This sounds a bit weird, but for example Dev0 will nearly never have the same value as Disp0, despite belonging to the X-axis.
4. Pre- and Post-display-macros are executed
5. Values of the vars Disp1…Disp4 are displayed
6. Then YADRO checks to see if there is some user-input. If so, it executes the macro (or other stuff you asked for)
7. Then the loops starts all over again at 1.

Raw communication with DRO:int4

The communication part of DRO:ddisp does all the reading and writing to the DRO:int4. It simply reads the values from the interface and converts the hexadecimal representation to numerical data. I does not convert to "real" numbers, but only converts them to some unscaled integer value. As there are two protocols, the communication part has to know (and knows) how the raw values are represented and how the have to be converted. The communication part also does handle time-outs and handshaking with the interface.

Display Engine

The display engine is the "glue logic" that keeps the parts together. It knows where to display values for the axes, it knows how to get values from the interface, it knows how to handle key strokes, it knows how to execute user invoked macros and it knows what macros to call to get the converted and scaled values for the axes. But it knows nothing what a mill or a lathe is and how these values have to be converted. This is all done by the macros.

Interpreter

The interpreter is the part that executes the macros either by user-selection or by request of the display engine. The language is a bit C-like. I tried to keep it simple and only added what is right needed to fulfill the needs of a DRO. Should there be more requirements, I can extend the language. The word "interpreter" might trigger a picture of some slow program running, but that is wrong. The code that is executed at a high rate can be kept very simple and the parts that take a lot of CPU-time are not interpreted.

The DRO:ddisp interpreter executes about 100000 instructions per second on a 3GHz AMD64.