Practicalities of using Rusty

[r2k-in-the-vortex]

My idea is to deploy Rusty as alternative to Matiec in OpenPLC

While it doesn't seem to be a very mature alternative right this moment, down the line I can see Rusty developing and becoming better and more capable while Matiec is what it is, nobody is seriously developing it.

There are some practical challenges with that and not many samples to work off of. To begin with, OpenPLC is written in C/C++ as would likely most other PLCs that might want to use rusty compiled code.

How do I get PLC object file to link to begin with?

I have PLC.st, easy enough

FUNCTION PLC : ULINT
  PLC := 7;
END_FUNCTION

I compile it to object like so, that works
$ rustyc -c PLC.st -o PLC.o

I have minimal main.cpp file like so

extern unsigned long int PLC();

int main(int argc, char * argv[]){
    PLC();
    return 0;
}

and I compile it to main.o $ g++ -c main.cpp so far so good

but when it comes time to link, it doesn't

vscode ➜ /workspaces/rusty/examples/minimumplc $ g++ PLC.o main.o -o main
/usr/bin/ld: main.o: in function `main':
main.cpp:(.text+0x10): undefined reference to `PLC()'
collect2: error: ld returned 1 exit status

Where am I going wrong?

Well, I can see where I'm going wrong, in object file PLC is not a function, but how do I fix it?
Do I need some sort of #[no_mangle] pragma in st?

(alt.o is a cpp compile equivalent to what PLC.o should be)

vscode ➜ /workspaces/rusty/examples/minimumplc $ nm -C alt.o 
0000000000000000 T PLC()
vscode ➜ /workspaces/rusty/examples/minimumplc $ nm -C PLC.o 
0000000000000000 T PLC

That's just an entry point though, a practical PLC needs to access hardware, handle retain variables, call system functions... well that's beyond absolute minimal viable example.

[ghaith]

I'll try to answer the question below as far as I understand them

My idea is to deploy Rusty as alternative to Matiec in OpenPLC

We have not done any testing with Matiec, but we already link RuSTy code against a C++ based runtime, so this is possible, I'll try to expand on how below

While it doesn't seem to be a very mature alternative right this moment, down the line I can see Rusty developing and becoming better and more capable while Matiec is what it is, nobody is seriously developing it.

RuSTy is under very active development, anything not yet working is definitely a bug, and contributions/bug reports are always welcome :)

There are some practical challenges with that and not many samples to work off of. To begin with, OpenPLC is written in C/C++ as would likely most other PLCs that might want to use rusty compiled code.

How do I get PLC object file to link to begin with?

I have PLC.st, easy enough

FUNCTION PLC : ULINT
  PLC := 7;
END_FUNCTION

I compile it to object like so, that works $ rustyc -c PLC.st -o PLC.o

You can also directly generate a C object or a statically linked object like this:
rustyc --shared PLC.st -o PLC.so, this will produce a normal shared object
rustyc --pic PLC.st -o PLC.so, this is best suited for dynamic loading
rustyc --static PLC.st -o PLC.o , this can be later archived with gnu-ar

I have minimal main.cpp file like so

extern unsigned long int PLC();

int main(int argc, char * argv[]){
    PLC();
    return 0;
}

and I compile it to main.o $ g++ -c main.cpp so far so good

but when it comes time to link, it doesn't

vscode ➜ /workspaces/rusty/examples/minimumplc $ g++ PLC.o main.o -o main
/usr/bin/ld: main.o: in function `main':
main.cpp:(.text+0x10): undefined reference to `PLC()'
collect2: error: ld returned 1 exit status

Where am I going wrong?

Well, I can see where I'm going wrong, in object file PLC is not a function, but how do I fix it? Do I need some sort of #[no_mangle] pragma in st?

(alt.o is a cpp compile equivalent to what PLC.o should be)

vscode ➜ /workspaces/rusty/examples/minimumplc $ nm -C alt.o 
0000000000000000 T PLC()
vscode ➜ /workspaces/rusty/examples/minimumplc $ nm -C PLC.o 
0000000000000000 T PLC

You need extern "C" instead of extern in your main.cpp to link using C++, we don't mangle names and are compatible with C calling conventions.

That's just an entry point though, a practical PLC needs to access hardware, handle retain variables, call system functions... well that's beyond absolute minimal viable example.

We can call system functions already, any C function can be linked and used in ST see External Functions, this applies to any function, you just need to declare the appropriate header and link the library correctly (-L<lib path> and `-l)

Hardware and Retain are planned, and we have rudimentary support for hardware.
Both of these features are more of runtime features than language-specific, here's how we can work with hardware in the current state, but this might be changed soon (#648):
A global variables file defining address locations, or any place for that matter can be treated as a VAR_CONFIG file, we can then export the generated data into a toml or json, these would be mappings from the global variable into the address it should be.
During initialisation, the runtime will then fetch the list of variables in that toml/json and based on it assign the value of each global variable during its cycle.

The change we are planning would be that the address itself would become a variable that could be assigned, and the global variable would then possibly become a pointer to that address. This might make hardware access more efficient.
Furthermore, if the hardware addresses are known at compilation time (like on arduino or small devices) they could be defined during compilation into global variables or enums, and accessed directly from the code, the %IX.. addressing defined in the norm would be redundant here for that case.

Hope this helps, and please don't hesitate to ask further questions.

[r2k-in-the-vortex]

Alright, that definitely helps, with that basic IO and cyclic call should be viable.
I will attempt to build that into OpenPLC over next few weeks.

Of course its a runtime thing rather than language thing, but the language exists to be used in runtime, so it's probably a useful point of feedback to actually integrate it into a fully fledged plc.

Anyway, here's the fixed calls from cpp for anyone attempting similar thing in the future.

PLC.st file

VAR_GLOBAL
    iVarGlob1 AT %IL1.0 : ULINT;
    iVarGlob2 AT %QL1.0 : ULINT;
END_VAR

FUNCTION PLC : ULINT
 VAR_INPUT
  tick: ULINT; (* Comment *)
 END_VAR
  PLC := iVarGlob1 + 1;
  iVarGlob2 := tick;
END_FUNCTION

main.cpp file

#include <iostream>
#include <string> 

extern "C" unsigned long int iVarGlob1;
extern "C" unsigned long int iVarGlob2;
extern "C" unsigned long int PLC(unsigned long int tick);

int main(int argc, char * argv[]){
    iVarGlob1 = 41;
    std::cout << "Number is " << std::to_string(PLC(7)) << " tick was " << std::to_string(iVarGlob2) << std::endl;
    return 0;
}

compile and run like this, it also spits out the json for IO

$ rustyc -c -o PLC.o --hardware-conf json PLC.st && g++ -c main.cpp && g++ PLC.o main.o -o main && ./main
Number is 42 tick was 7

[ghaith]

Alright, that definitely helps, with that basic IO and cyclic call should be viable. I will attempt to build that into OpenPLC over next few weeks.

Glad to hear, it would be nice to have more compatibility with OpenPLC, we tried to stay as close to the norm as we can as well.

Of course its a runtime thing rather than language thing, but the language exists to be used in runtime, so it's probably a useful point of feedback to actually integrate it into a fully fledged plc.

Yes, I also think Retain and further hardware support is important, I just meant we haven't gotten to them yet.
The way I think we will do retain is very similar to the current hardware support, all variables marked as retain will be marked, and probably exportable as json/toml. The runtime can then save/load these variables as required

[r2k-in-the-vortex]

It might be easier to expose the entire structure of everything in PLC, that's what TwinCAT does with it's tmc file.

There is also the hmi question for future considerations - that will want to poke all sorts of variables available in PLC and it's pretty popular to add non-realtime services and interfaces to PLC similarly too - be it over OPC for most PLCs or in case of TwinCAT direct ads access is popular. It's all the same thing, external things having access to pretty much all variables in PLC when they want it. For that the memory structure has to be described somewhere.