PLC development environment transpile to GO. Is it smart?

Question

go

I'm working on a development environment for GKR/

The main language will be ST (Structured Text) one of the 5 languages ​​of the IEC 61131-3 standard.
The main development environment will be VS Code.

I have already written an extension that highlights the syntax, makes hints, then it will analyze the code and the whole set.

Now that the program is ready, it must be compiled and uploaded to the PLC. Presumably this will only work on Linux based PLCs. No stm32 or the like. There are no ST compilers. Because ST is, as it were, not a language, but a set of recommendations. Everyone implements this language in their own way and writes their own compiler. In any case, everything ends up most likely with / C ++ code. So I have 2 ways from here.

1. Make a compiler and turn the ST code directly into executable machine code. Here I am doing exit because it is not my level of competence and I am not sure if it is correct.

2. Make a transpiler and make a file of another language from the ST file. It turns out that ST will be of the TypeScript type, which then turns into vanilla javascript. Well, here is the choice of languages. At first I was thinking of using Python since it is already commonly used in PLCs. But after playing with it a little, I realized that it would not be easy to make minimalist installations. Python must always be installed in the OS. Yes, and it works through the interpreter.

The next idea was Nodejs. She seemed perfect. I know him at 5, he is asynchronous, which will add special flexibility to the PLC, but after reading the Express author's articles about it, I realized that it is possible to move in this direction, and everything will work, but in the end I will run into some limitations of the node core.

Yesterday I met a friend for a walk, he told me to look at GO. I watched. And he looks perfect. Would it be reasonable to translate the ST syntax into a GO program, and then compile the GO itself into machine code?

To make it clear how ST looks like in order to make at least some kind of assessment, here is an example.

TYPE Shelf :
STRUCT
  TemperatureIN:     POINTER TO WORD;
  Temperature:       INT;
  TemperatureHMI:    POINTER TO WORD;
  TemperatureStatus: POINTER TO BYTE;
  OutByte:           POINTER TO WORD;
  ByteNum:           USINT;
  Correction:        POINTER TO WORD;
END_STRUCT
END_TYPE

FUNCTION_BLOCK TON_M
    VAR_INPUT
    	IN: BOOL;
    	PT: TIME;
    	RS: BOOL;
    END_VAR
    VAR_OUTPUT
    	Q: BOOL;
    	TP: WORD;
    	TW: TIME;
    END_VAR
    VAR
    	TON1: TON;
    	SR1: SR;
    	RT1:R_TRIG;
    	TimeWorked : TIME;
    	xProcess :BOOL;
    END_VAR

    IF pt = T#0S THEN
    	Q := TRUE;
    	RETURN;
    END_IF

    IF RS OR (TimeWorked > PT) THEN
    	TimeWorked := T#0S;
    	TON1(IN := FALSE);
    	RETURN;
    END_IF

    IF NOT TON1.Q AND NOT IN THEN
    	TimeWorked := TimeWorked + TON1.ET;
    END_IF

    TON1(IN := IN, PT := SEL(IN, T#0MS, PT - TimeWorked), Q => Q);

    TW := TimeWorked + TON1.ET;
    TP := REAL_TO_WORD(TIME_TO_REAL(TW) * 100.0 / TIME_TO_REAL(PT));
END_FUNCTION_BLOCK

Here is a list of things that I will need to achieve in the final result. I don't see the difficulty of translating ST into GO since both are similar to C but I will eventually need it.

1. Simulation. This is the ability to run the program and see which variable has what value. It is possible to change the values ​​of variables on the fly.

2. Online debugging. This is the ability to run a program on the PLC itself and see which variables have what values ​​in the running PLC. What does it have to be displayed over the ST code.

Answer 1

1) You can see examples on Matlab. I prefer the graphical language SFC (Codesys), in Matlab it corresponds (not in everything, including in the graphical representation) to Stateflow.
Video
There is a Stateflow -> ST translator. At the same time, it is not so easy to disassemble and debug ST (by the way, in your example on ST there is a logical error: access to the fields TON1.Q and TON1.ET, but not the fact that there was a call to TON1 (the previous IF condition may be false) It's good if the fields contain zeros, but what if it's garbage?).
2) You can immediately translate Stateflow into C / C ++ for Linux (there are tools in Matlab and Simulink)