safetyfactorman
I recently read a paper by Alves, Morris, et. al., discussing plc security and openplc.

I am interested to explore the possibility of integration of micropython with IEC 61131-3.

The micropython project is located at http://www.micropython.org.  It is a slowly developing project, but has lots of potential.  There are interesting similarities between the two projects, and I believe that they are very much complementary to each other, and mutually beneficial to each other.

I am interested to run micropython and openplc on a raspberry pi initially, but then expand to a more capable hardware platform with a higher frequency update time for i/o.

I understand from reading the paper that openplc runs on a dedicated core in the arm cpu.  I would like to compile the micropython code to run dedicated on another core of the cpu, and then communicate with openplc via some mechanism.  Does anyone here have ideas as to skill level and resources required to do this?

I came across this thread on the raspberry pi forum:

https://www.raspberrypi.org/forums/viewtopic.php?t=191744

The raspberry pi thread is based on resources on the micropython website, which I believe refer to the unix port.  There was an attempt to run micropython on a raspberry pi zero, but it is not successful, so far as I am able to determine.

I would like some idea as to the manhours required, and whether anyone would be interested to undertake this effort, with the final output released under the mit license.

thanks,

Mark
Quote 0 0
thiagoralves
Why use micropython if the real python runs on the Pi already? If you want performance, you can even compile your python code into an executable and then it will run with native instructions without the python interpreter. If you want to integrate it with OpenPLC, that's done already. Half of the OpenPLC project is written in python. The communication mechanism is Modbus/TCP, a well established industrial network protocol.
Quote 0 0
safetyfactorman
Cpython runs on an operating system only, does it not?  Does openplc run with python on embedded controllers?  Perhaps I misunderstood the architecture of openplc.  Are you saying that for embedded controllers, you are compiling the python -> C code in order to be able to run it on an esp8266, for example?  How is garbage collection handled?  How can you be sure that it is deterministic?
Quote 0 0
thiagoralves
OpenPLC cannot run without an OS. It runs on top of Linux on the Pi and on all supported platforms. The runtime does not run on embedded controllers, they are treated only as expansion devices to a host system, and cannot run any logic by themselves.

About determinism, I’ll limit myself to say that, if properly configured, it is deterministic enough. Of course that since it runs on top of Linux, it can’t ever be called a hard real-time system, but it got better responses than most popular PLCs on the market (see Table 4 on my attached paper), which means that this level of determinism is not required for PLCs.
Quote 0 0
safetyfactorman
I think that I read this paper first, and lost track of it.  And I was really impressed by openplc.  I have some more questions:

1.  I think I recall you mentioning somewhere about slow performance in openplc of the modbus driver?  Are you using a lookup table for the crc checksum calculation?  Are you aware of Joe Campbell's book on rs232 programming?  He has code there for crc calculation.  It is very fast.  I used his code to write a modbus slave connecting a vax scada system to realflex running on qnx  an i386.  I also used it on dos (modbus master) to do data acquisiiton via a mux to a network of rtus.

2.  I am sure that you have heard of microkernal unixes, such as windriver and qnx?  Have you considered running openplc on a deterministic rtos?  maybe even on the freertos's?  Would running openplc on an rtos make it better?  

https://en.wikipedia.org/wiki/Comparison_of_real-time_operating_systems

I used to work for an engineering consulting firm in Calgary (Kenonic Controls Ltd.) that was the dominant engineering consulting firm in Canada at the time I worked there.  There was a need to find customizable plc software for some projects.  But one cavaet is that the closer that you get to a deterministic requirement, then risk goes up for failure.  They used qnx with success.  A lot of the controls equipment is obsolete, because it takes a long time to get a track record for reliability.  Another critical thing about commercial controls is accountability and support.  I found programming on qnx to be very painful.

3.  Have you ever considered micropython, or python, as an IEC 611131-3 language?  My understanding is the the European Space Agency is funding micropython.  Have you considered approaching them to obtain funding for openplc? If micropython ran on a dedicated arm core, with openplc running on another core, might it be worth the bother?
Quote 0 0
thiagoralves

1.  I think I recall you mentioning somewhere about slow performance in openplc of the modbus driver?  Are you using a lookup table for the crc checksum calculation?  Are you aware of Joe Campbell's book on rs232 programming?  He has code there for crc calculation.  It is very fast.  I used his code to write a modbus slave connecting a vax scada system to realflex running on qnx  an i386.  I also used it on dos (modbus master) to do data acquisiiton via a mux to a network of rtus.

This has nothing to do with CRC. Remember, you're running on GHz machines. No matter how you do it, calculating CRC would take a couple nanoseconds only. The slow performance I mentioned is due to the nature of the protocol itself. You see, if I use Modbus I need 4 full requests (8 transactions counting request + response) to read/write the entire image buffer of a single device (read inputs, write coils, read input registers, write holding registers). This is a stupid waste of time! What I wanted to improve is to have the entire image in a single request. This would be 4x faster. The host requests the entire input image (both digital and analog), and sends the entire output writing on the same request. The client responds back with the entire input image as requested and an acknowledgement about the writing changes. That's it. It might be possible to do this by creating a custom Modbus function code and implementing this call on it. I just don't have the time and resources now to implement it.


2.  I am sure that you have heard of microkernal unixes, such as windriver and qnx?  Have you considered running openplc on a deterministic rtos?  maybe even on the freertos's?  Would running openplc on an rtos make it better?  

https://en.wikipedia.org/wiki/Comparison_of_real-time_operating_systems

I used to work for an engineering consulting firm in Calgary (Kenonic Controls Ltd.) that was the dominant engineering consulting firm in Canada at the time I worked there.  There was a need to find customizable plc software for some projects.  But one cavaet is that the closer that you get to a deterministic requirement, then risk goes up for failure.  They used qnx with success.  A lot of the controls equipment is obsolete, because it takes a long time to get a track record for reliability.  Another critical thing about commercial controls is accountability and support.  I found programming on qnx to be very painful.

The current OpenPLC architecture won't run on anything smaller than Linux. It depends on the python interpreter for the webserver and on gcc to recompile the main core every time a new program is uploaded through the webserver. These things are not present on microkernel RTOSes.


3.  Have you ever considered micropython, or python, as an IEC 611131-3 language?  My understanding is the the European Space Agency is funding micropython.  Have you considered approaching them to obtain funding for openplc? If micropython ran on a dedicated arm core, with openplc running on another core, might it be worth the bother?

The IEC standard is very specific about the languages that should be supported. I don't think they are planning to add Python to that list any time soon. In any case, I don't see any issue in adding python to the mix. In fact, I believe that Beremiz has an extension that allows you to write python code alongside your program with the other IEC languages. In OpenPLC Editor (and also on Beremiz) you can write C code directly by using pragmas. In fact, any language that can be compiled to C should work. In the end of the day, you don't have to have openplc running on one core and micropython (or python or whatever) running on another core. When you create your PLC program, all languages are compiled to C, and then the C is compiled to binary and run together as a single application on a single core.
Quote 0 0