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.