We are having issues right now, and I just stumbled on that post. It seems to me you are saying your Linux ARM control is RPi 5-compatible, but the one you sell specifically for RPi is not. The fix you are proposing requires customers to re-purchase a CODESYS licence. Is there a time frame for that to be fixed?
https://us.store.codesys.com/codesys-control-for-raspberry-pi-sl.html Quoted from the "additional requirements" section : The operating system Raspberry Pi OS (32-bit)
4.11 appears to solve the problem. Thanks for your help. I had first installed the 64-bit version of RPiOS, but looking at various posts and the product's page on the store which only lists 32-bit compatibility, I downgraded to the 32-bit version. I did this before trying 4.11, and it did not solve the problem. Thus my working system is 32-bit, and I am wondering if I can go back to 64-bit or not. An 64-bit OS is not listed as compatible on the store's web page, but when installing there actually...
I have a Raspberry Pi 4 we have been using for years to run CODESYS for development purposes. I recently have had to re-install the OS (Raspberry OS lite). The only change to the default configuration is not creating the "pi" user during install. I (apparently successfully) installed the 4.10.0.0 control on the Raspberry Pi. We have licences on a dongle. I am able to start the control. systemctl status shows it as running for a little while (exactly, precisely 30 seconds as per my tests, every time),...
In the past, we have routinely used the "add all instance paths" function to automatically add variables to VAR_CONFIG lists. My recollection is that compiling a project did not require VAR_CONFIG to be fully populated, and, once successfully compiled, instance paths could be added. Errors related to missing declarations, if I recall correctly, were thrown when downloading to the PLC, they did not prevent a successful compile. At some point, it stopped working. Missing declarations in a VAR_CONFIG...
If the relationship between level and volume is amenable to it, one thing you can do is to use software that can perform a regression to get a a formula that approximates volume as a function of the level (Excel graphs can do that). Then, instead of a lookup table, you just perform a direct calculation. It makes for more concise code. Obviously, you need a different formula for each tank geometry, but the same is true with lookup tables (or at least their content).
I am the guy from the Stackoverflow answer. Let me attempt to give you a few more breadcrumbs. You are likely to want to achieve any combination of these goals. Make your control logic independent from your hardware Avoid hard-coded hardware addressing. Allow several instances of whichever device you control (e.g. motor) Make your code portable (for me, this means CODESYS and TwinCAT). I have found only one sane way to check all these boxes. This way involves not trying to achieve all these goals...
I am the guy from the Stackoverflow answer. Let me attempt to give you a few more breadcrumbs. You are likely to want to achieve any combination of these goals. Make your control logic independent from your hardware Avoid hard-coded hardware addressing. Allow several instances of whichever device you control (e.g. motor) Make your code portable (for me, this means CODESYS and TwinCAT). I have found only one sane way to check all these boxes. This way involves not trying to achieve all these goals...