The challenge about a self hosted system is, that it has not only to be possible but also has to be attractive to use. If you don't have a sufficient level of convenience, than you and others will simply not use it.
I had made a block file editor, which was probably as good as the old ones, when systems had 32k of Ram. But forget it, if you have the choice to use something like notepad++.
I have also tried to use mpark's sphinx for P1 which is very impressive, but I found myself to use the file download feature mostly.
With P2's 512k the story is different. For my last projects I have always used my Forth editor. (A second SD card should be the next step for automatic backups....)
@"Christof Eb." said:
The challenge about a self hosted system is, that it has not only to be possible but also has to be attractive to use.
True. C is the language that everyone wants and expects to be able to use in embedded systems, but the only complete and viable self-hosted C option (Catalina) is currently a bit slow.
@"Christof Eb." said:
The challenge about a self hosted system is, that it has not only to be possible but also has to be attractive to use.
True. C is the language that everyone wants and expects to be able to use in embedded systems, but the only complete and viable self-hosted C option (Catalina) is currently a bit slow.
Tricky.
From one who actually spends most of his life in the trenches (plant floor):
PLCs are the bane of my life. For the sake of a 2-minute modification, someone has to go find the laptop with a current license to connect to the PLC. Oh and where's that RS485 cable with the proprietary connector. Oh wait, I have the password somewhere, let me find it. Now, if I could only remember how to use this app.
Prop cogs and pins are precious. Why tie them up with mundane stuff. I prefer to create a library of tasks on the prop and call/trigger them from a Basic interpreter on the RPi Pico. A keyboard, mouse, VGA/HDMI connect directly to the RPi Pico and everything is self contained. Edit the code and run. "Structured text" was described as similar to Pascal/C. I disagree. It's more like a modern, structured Basic with a smattering of Pascal.
Shop floor techs have no problem using Basic.
True. C is the language that everyone wants and expects to be able to use in embedded systems
Never have I heard this
Basic: Brilliantly Advanced Structured Instruction Code (line numbers and GOTO haven't been required since the early 80's)
Scenario: Production line down. Hourly employees stood around waiting until someone who understands C or Forth comes along? Not realistic.
Back in the 80's, I was their (Galil) first machine-tool customer. I was a sales engineer based in Cleveland. My boss got us into big trouble by selling a machine to GM that couldn't possibly work due to the huge stepper-motors losing pulses like crazy. This was the first fully-automated seat-frame line, involving robot welding, massive investment. I got pulled into it because my field was closed-loop servo control which is what should have been used. GM was about to wipe us out but I'd read about this Galil product and after a few cocktails in the bar with the GM guys, I blurted out that I could come up with a working solution
I'd never programmed anything prior to this but I grabbed a copy of QuickBasic for the PC host and a couple of ISA-slot Galil boards. Had that 5-axis machine making accurate parts in less than two weeks using a combination of the Galil language and QuickBasic. I had to babysit the eventual installation, 24/7 for a few weeks while my boss was on the golf course. Repeat orders came in and I said screw this, I'm now self-employed. A beginner programmer, building controls for big auto.
Today, the Siemens flagship S7 PLC cannot do this, costs a fortune and don't get me going on the programming.
There is no need for industrial controls to be complicated but the industry giants (and engineers) want to keep it that way.
Scenario: Production line down. Hourly employees stood around waiting until someone who understands C or Forth comes along? Not realistic.
I'm curious about these situations; the frequencies, causes and solutions.
I can imagine a few scenarios, like...
hardware failure - controller needs replacing and the same firmware installing (I suppose usually when "the guy" is on holiday, and when he's not given his assistant the tools to properly take over)
parameter variation - one example would be that the item on the line changed somehow, and so the controller firmware needs adjusting appropriately (in your experience, is that stuff usually scheduled to when "the guy" is on-site?)
No doubt you have many more examples?? My two don't seem like they should be issues at all, not withstanding the high-value sales income to be had from a service contract when things fail)
Pneumatic flag-stop with the sensor inside the cylinder. The device wasn't being used because the workpiece was very short and so the stop-plate had been removed. However the cylinder still had to actuate to switch the input on/off for the logic to work. The cylinder failed and therefore couldn't trigger the sensor. The fix was to remove the toggle condition in the program logic.
Another was a "clamp-is-closed" sensor failure. While waiting for a replacement, we used a time delay so that we could at least make parts. The cycle time was a consistent, ~1 sec and so we used a 3 sec delay to be sure. Painful to watch but production continued.
Pneumatic flag-stop with the sensor inside the cylinder. The device wasn't being used because the workpiece was very short and so the stop-plate had been removed. However the cylinder still had to actuate to switch the input on/off for the logic to work. The cylinder failed and therefore couldn't trigger the sensor. The fix was to remove the toggle condition in the program logic.
Another was a "clamp-is-closed" sensor failure. While waiting for a replacement, we used a time delay so that we could at least make parts. The cycle time was a consistent, ~1 sec and so we used a 3 sec delay to be sure. Painful to watch but production continued.
Production downtime is the killer
Ah, ok, so sounds like no.2 situations mainly, but of the unscheduled kind
Would the production line operator want that sort of program-logic editing control being exposed to regular on-site staff ("Hourly employees") ?
I mean, something really bad could happen if someone trying to be helpful made an adjustment error ? And might lead to health/safety/insurance repercussions ?
-- is that why firms like to have service contracts; to protect themselves from all that ?
I'm trying to visualise how a system could be more open for simple adjustment in a way that serves a purpose, without inviting risks.
Perhaps certain parameters could be marked as overridable, and allow someone with a known pin-code to adjust them. So the fundamental code elements are locked to the machine (and only "the guy" can edit them), but things like "ignore sensor" or "wait X seconds" could be toggled and adjusted via a simple interface to technicians with a certain level of approval?
How would the interface work on the factory floor?
I suppose each device doesn't need a touchscreen--- maybe a portable admin device (plugin or wifi) ?
Or a permanently / centrally connected controller that has screen/keyboard? Allows program flow updates, and also provides live data and logging ?
People are generally reluctant to go near this stuff and the programs can be password protected. Anything that involves motion, I worry more about the setup guy inserting a decimal in the wrong place for a tooling parameter or part program and crashing the machine.
What's supposed to happen and what really happens can come as a shock. Some of these ISO9001 certified companies where they have dedicated safety personnel who don't know what the heck they're doing. Where head protection isn't required they have hard-hats, where ear protection is required, they are the ones wearing the full ear-protectors.......but they are oblivious to the fact that a light-curtain has been bypassed The LEDs are still flashing so it must be OK
Service contracts: Great until the product is obsoleted. The original manufacturer all-too-often refuses to support the equipment because they want you to buy new. Even simple machines are fitted with PLCs but you don't get the source code so even if you managed to find a used CPU module (eBay), you can't use it because you don't have the programming kit nor the firmware/source.
I am sitting next to a machine as I type; the OMRON motion controller is dead but the machine is good for another 30+ years. A replacement machine is >$150K. I am ripping out the Omron controllers, the obsolete PLC and the obsolete panel PC. It will be running on MCUs and an industrial Android tablet and I supply full source, BOM and spare PCBs.
All programmable logic resides on the RPi Picos, loaded-up with the PicoMite Basic interpreter. No toolchain required. A USB KB, mouse and VGA/HDMI monitor connect directly to the RPi Pico and code is edited via the PicoMite editor....on the device. The PID loops on this particular machine only require 1KHz loop-rate and so I don't need the Prop but the higher performance machines will absolutely need the P2.
Ignore sensor: Absolutely. In many cases, a time delay can be substituted for a failed sensor. I also have this for a failed homing sensor; limit the motor torque and allow it to hit a hard stop.
We don't have the luxury of running out to Radio Shack and cobbling something together like the good ol' days so anything to keep that machine making parts (safely)
Appears a Slovenian company, Smarteh, has made a fork of beremiz for their PLC controllers.
Is mentioned here: https://github.com/beremiz/beremiz
Think this should mean they have to make source code available as beremiz is GNU, but not seeing it...
But, one thing not liking is the GNU stamp on the generated c file.
Don't think that just because matiec is GNU that the generated c file has to be GNU.
Might have to change that...
think have matiec compiled after the usual Ubuntu command line pain...
Matiec has build instructions:
To compile/build these compilers, just
$./configure; make
But, of course this doesn't work without extra steps...
Had to install/run "autoreconf"
Then had to do "automake --add-missing"
Then "autoreconf" again...
then, "sudo apt get install flex" after the make one liner failed.
Then, finally seemed to actually compile...
Ok, see the real challenge now...
matiec creates a few output files from the input .st file, but mainly a resource and a config file.
Seems there's a way to make these files have the names "STD_CONF.c STD_RESSOURCE.c", but mine are "res0.c" and "config0.c"
The real challenge appears to be to create a main.c file and a plc.c file that will run on P2.
Seeing a Linux, Windows, and STM32f4 example.
Presumably, OpenPLC can create an Arduino version.
@refaQtor is probably getting annoyed by all this? Maybe would start another thread if can actually figure it out...
@Rayman said:
Ok, see the real challenge now...
The real challenge appears to be to create a main.c file and a plc.c file that will run on P2.
I imagine there is a lot of mostly mapping mcu ports to/from "standard" industrial addresses and modbus register spaces in these config files. then it synthesizes the C code to read write and make it addressible from the PLC.c code. that is sort of the gist of many these gui code builder schemes. ...
Think BlocklyProp, for example.
that is how I started C coding on Propeller.... I built a few new things with Blockly, then looked at the generated C code. I kinda find Blockly useful on occassion, it does make it pretty easy to follow what is going on, especially when things are happening in parallel, but once you get the pattern of C code it generates, it is way faster to edit the text. Frankly, the real underlying issue of all this, is that no self-respecting "professional" would admit to using the childish interface of BlocklyProp in an "industrial" situation.
You can swing tooo far the other direction and get mired and bogged down by dragging along a ton of arcane baggage from a half-century of industrial control... that keeps an army of annoyed PLC programmers employed.
I think this is less a technical issue than a human one - each of us have our own faovrite hammer with which to hit this problem. Machines are easy to reprogram, people are near impossible.
@refaQtor is probably getting annoyed by all this? Maybe would start another thread if can actually figure it out...
I don't mind, as long as people are sorting things out. it takes some back and forth... the hard part of reprogramming people
This thread has helped to clarify for me where PLC hardware and a self hosted system are two separate efforts. My head is churning on the hardware at the moment. I will probably open a "customer project" thread when the time comes to show something - instead of just waving my hands around here.
The real challenge appears to be to create a main.c file and a plc.c file that will run on P2.
That's been done. I did a quick and dirty port of OpenPLC to ANSI C so that it can be compiled using Catalina, and also generates ANSI C code that can be compiled using Catalina. And it can do this on the Propeller 2. So generating and compiling the C code is the easy bit. But if you want a full self-hosted solution, then building a suitable GUI for the Propeller 2 is going to be where most of the work is. And for this, it is better to start with LDmicro than OpenPLC, since it already has a text-based ladder logic editor (which is then wrapped in a Windows GUI).
However, after doing a little more digging, I am a little confused by how many versions of OpenPLC there actually are, and which one is the most current. The github source for OpenPLC seems to be older than the github source for LDmicro, which was (I think) the original. Then there seems to be several commercial derivatives of both OpenPLC and the OpenPLC editor, so I am now not sure which one would be the best source to start with.
Probably needs a bit more digging from someone who knows more about PLCs than I do.
@refaQtor is probably getting annoyed by all this? Maybe would start another thread if can actually figure it out...
Yes, if @refaQtor let's us know, happy to continue this particular discussion in another thread. But I will say again that I have no real interest in PLCs themselves - it just seems like it would make an interesting application for Catalina, because it seems to me that Catalina C can handle the C side, and Catalina Lua would be an ideal language to use to implement the GUI.
@Mickster said:
Prop cogs and pins are precious. Why tie them up with mundane stuff. I prefer to create a library of tasks on the prop and call/trigger them from a Basic interpreter on the RPi Pico. A keyboard, mouse, VGA/HDMI connect directly to the RPi Pico and everything is self contained. Edit the code and run. "Structured text" was described as similar to Pascal/C. I disagree. It's more like a modern, structured Basic with a smattering of Pascal.
Shop floor techs have no problem using Basic.
The IEC61131 is quite close to Modula-2/Oberon, (also from Europe) and there is a new Oberon now for the PiPICO
Oberon is very interesting. Might have a play with it.
However, I don't see support for the PIO. I use the PIO for high-speed quadrature decode (4 encoders/Pico)
The problem, though is that it's always the perspective of an engineer, working on a program at his desk.....no consideration for the schmuck who is responsible for keeping that equipment churning-out product.
These guys don't get to program every day. Mention "uint" or "bool" or "float" and they will throw their hands up in the air and just give up until the outside support guy gets there, maybe in a couple of weeks.
I am talking about grabbing a USB keyboard and a VGA monitor, editing and instantly testing/running code, right on the Pico. No PC, no compiling, etc.
They need to be concentrating on what they need to do, not how to do it.
In my perfect PLC world, @Rayman, there would be a P1 on the backplane with VGA/USB-keyboard/mouse driving an IDE (that could be the LDMicro Ladder) on your 10080p TextDriver (as a platform to develop other IDEs) which would load the Ladder (or similar intermediate process definition data) onto a P2 that had the runtime to and the massively flexible I/O. The importance of having a TEXT MODE IDE is that it would also be available over and ANSI terminal to the service guy on the floor that had a laptop, but not VGA/keyboard. and that the laptop need not install ANY custom software at all. The P1 would communicate back/forth with the P2 to be able to interogate the P2 for the current actual status and configuration that had been loaded or the active state of pins (coils/contacts). The P1 is to be given entirely over to the management and display features of the PLC, and can use all the pins/cogs for that without worrying about impacting the P2 PLC perrformance of the actual duties.
The active LIVE HMI (not the development interface) of the PLC machine (if it had one) would drive either a TFT interface, or share the system state over modbus as many commercial HMI solutions expect already.
And... ok. good understanding now for laying out circuit boards for development with this strategy. The external interfaces are coming together with discovery of a new all-in-one TI part combining RS-232/422/482 into one for externally protected standard interfaces.
for the 2 processor (backplane chassis management console) and the (P2 PLC runtime executor) I will put down one each of the 80 pin Edge socket. The PLC one is obvious to external machine connections. the backplane socket can use just 32 pins - all of the P1 available pins - for a P1 on an Edge form factor - for the essential chassis monitoring and ANSI only IDE interface.
Or most of the ones also available to the P2 32MB Edge module that would be the top end of IDE management interface.
Wondering if a reasonable sized ladder logic program really needs to be compiled at all...
Maybe P2 is fast enough to just process the text directly...
@Rayman said:
Ansi terminal interface is interesting idea...
Wondering if a reasonable sized ladder logic program really needs to be compiled at all...
Maybe P2 is fast enough to just process the text directly...
pretty certain the intermediate text file format could be stored/loaded from Flash into structures and registers in the Hub RAM that the cogs all operate on directly.
ports potentially: (along the lines of what I've been cooking already)
1. maestro (with nifty new task management)
2. filesystem I/O (avoid contention on disk interface)
3. PLC Ladder
4. PLC Timers
5. all the things I am forgetting at the moment
6. modbus or other protocol data shuffling through cog 8
7. ADC smartpin input (DAC?)
8. 8 port smartpin serial driver (playing with 16, too)
Thinking that @ersmith ANSI VGA text driver will meet goals better (and use only one cog, vs 3 cogs with my 1080p driver).
The columns are less but ANSI serial output does sound attractive too.
Doing this with Micropython too...
Here's a quick test at highest resolution (1280x960 signaled as 1280x1024).
Not 100% sure sold on this driver yet, but seems like it could work...
Not sure if there's a terminal that can work with this resolution or not.
Maybe?
Comments
The challenge about a self hosted system is, that it has not only to be possible but also has to be attractive to use. If you don't have a sufficient level of convenience, than you and others will simply not use it.
I had made a block file editor, which was probably as good as the old ones, when systems had 32k of Ram. But forget it, if you have the choice to use something like notepad++.
I have also tried to use mpark's sphinx for P1 which is very impressive, but I found myself to use the file download feature mostly.
With P2's 512k the story is different. For my last projects I have always used my Forth editor. (A second SD card should be the next step for automatic backups....)
True. C is the language that everyone wants and expects to be able to use in embedded systems, but the only complete and viable self-hosted C option (Catalina) is currently a bit slow.
Tricky.
From one who actually spends most of his life in the trenches (plant floor):
PLCs are the bane of my life. For the sake of a 2-minute modification, someone has to go find the laptop with a current license to connect to the PLC. Oh and where's that RS485 cable with the proprietary connector. Oh wait, I have the password somewhere, let me find it. Now, if I could only remember how to use this app.
Prop cogs and pins are precious. Why tie them up with mundane stuff. I prefer to create a library of tasks on the prop and call/trigger them from a Basic interpreter on the RPi Pico. A keyboard, mouse, VGA/HDMI connect directly to the RPi Pico and everything is self contained. Edit the code and run. "Structured text" was described as similar to Pascal/C. I disagree. It's more like a modern, structured Basic with a smattering of Pascal.
Shop floor techs have no problem using Basic.
Never have I heard this
Basic: Brilliantly Advanced Structured Instruction Code (line numbers and GOTO haven't been required since the early 80's)
Scenario: Production line down. Hourly employees stood around waiting until someone who understands C or Forth comes along? Not realistic.
Craig
Never have I heard this
TrioBASIC
A relatively crude dialect of interpreted Basic
This is what DARPA use for their self-driving vehicle.
Sotty, but this stuff makes assembly language look advanced.
Back in the 80's, I was their (Galil) first machine-tool customer. I was a sales engineer based in Cleveland. My boss got us into big trouble by selling a machine to GM that couldn't possibly work due to the huge stepper-motors losing pulses like crazy. This was the first fully-automated seat-frame line, involving robot welding, massive investment. I got pulled into it because my field was closed-loop servo control which is what should have been used. GM was about to wipe us out but I'd read about this Galil product and after a few cocktails in the bar with the GM guys, I blurted out that I could come up with a working solution
I'd never programmed anything prior to this but I grabbed a copy of QuickBasic for the PC host and a couple of ISA-slot Galil boards. Had that 5-axis machine making accurate parts in less than two weeks using a combination of the Galil language and QuickBasic. I had to babysit the eventual installation, 24/7 for a few weeks while my boss was on the golf course. Repeat orders came in and I said screw this, I'm now self-employed. A beginner programmer, building controls for big auto.
Today, the Siemens flagship S7 PLC cannot do this, costs a fortune and don't get me going on the programming.
There is no need for industrial controls to be complicated but the industry giants (and engineers) want to keep it that way.
I'm curious about these situations; the frequencies, causes and solutions.
I can imagine a few scenarios, like...
No doubt you have many more examples?? My two don't seem like they should be issues at all, not withstanding the high-value sales income to be had from a service contract when things fail)
@VonSzarvas
Pneumatic flag-stop with the sensor inside the cylinder. The device wasn't being used because the workpiece was very short and so the stop-plate had been removed. However the cylinder still had to actuate to switch the input on/off for the logic to work. The cylinder failed and therefore couldn't trigger the sensor. The fix was to remove the toggle condition in the program logic.
Another was a "clamp-is-closed" sensor failure. While waiting for a replacement, we used a time delay so that we could at least make parts. The cycle time was a consistent, ~1 sec and so we used a 3 sec delay to be sure. Painful to watch but production continued.
Production downtime is the killer
Ah, ok, so sounds like no.2 situations mainly, but of the unscheduled kind
Would the production line operator want that sort of program-logic editing control being exposed to regular on-site staff ("Hourly employees") ?
I mean, something really bad could happen if someone trying to be helpful made an adjustment error ? And might lead to health/safety/insurance repercussions ?
-- is that why firms like to have service contracts; to protect themselves from all that ?
I'm trying to visualise how a system could be more open for simple adjustment in a way that serves a purpose, without inviting risks.
Perhaps certain parameters could be marked as overridable, and allow someone with a known pin-code to adjust them. So the fundamental code elements are locked to the machine (and only "the guy" can edit them), but things like "ignore sensor" or "wait X seconds" could be toggled and adjusted via a simple interface to technicians with a certain level of approval?
How would the interface work on the factory floor?
I suppose each device doesn't need a touchscreen--- maybe a portable admin device (plugin or wifi) ?
Or a permanently / centrally connected controller that has screen/keyboard? Allows program flow updates, and also provides live data and logging ?
People are generally reluctant to go near this stuff and the programs can be password protected. Anything that involves motion, I worry more about the setup guy inserting a decimal in the wrong place for a tooling parameter or part program and crashing the machine.
What's supposed to happen and what really happens can come as a shock. Some of these ISO9001 certified companies where they have dedicated safety personnel who don't know what the heck they're doing. Where head protection isn't required they have hard-hats, where ear protection is required, they are the ones wearing the full ear-protectors.......but they are oblivious to the fact that a light-curtain has been bypassed
The LEDs are still flashing so it must be OK 
Service contracts: Great until the product is obsoleted. The original manufacturer all-too-often refuses to support the equipment because they want you to buy new. Even simple machines are fitted with PLCs but you don't get the source code so even if you managed to find a used CPU module (eBay), you can't use it because you don't have the programming kit nor the firmware/source.
I am sitting next to a machine as I type; the OMRON motion controller is dead but the machine is good for another 30+ years. A replacement machine is >$150K. I am ripping out the Omron controllers, the obsolete PLC and the obsolete panel PC. It will be running on MCUs and an industrial Android tablet and I supply full source, BOM and spare PCBs.
All programmable logic resides on the RPi Picos, loaded-up with the PicoMite Basic interpreter. No toolchain required. A USB KB, mouse and VGA/HDMI monitor connect directly to the RPi Pico and code is edited via the PicoMite editor....on the device. The PID loops on this particular machine only require 1KHz loop-rate and so I don't need the Prop but the higher performance machines will absolutely need the P2.
Ignore sensor: Absolutely. In many cases, a time delay can be substituted for a failed sensor. I also have this for a failed homing sensor; limit the motor torque and allow it to hit a hard stop.
We don't have the luxury of running out to Radio Shack and cobbling something together like the good ol' days so anything to keep that machine making parts (safely)
Liking the ideas here...
The Autonomylogic openplc code looks good: https://autonomylogic.com/docs/openplc-overview/
Found a forum thread where somebody took the "structured text" .st file that OpenPLC generates and created C code from it:
https://openplc.discussion.community/post/proof-of-concept-port-of-openplc-core-to-mcu-platformioarduinoesp32-10245850
Also in github: https://github.com/mprymek/mcu-plc
This looks to be based on the "MATIEC - IEC 61131-3 compiler":
https://github.com/mprymek/mcu-plc
Might take a look to see what other .st "compilers" might be out there...
beremiz looks to have everything... HMI, editor, and compiler...
Seems to be related to matiec in some way...
Found a getting started like page here:
https://github.com/Felipeasg/matiec_examples
Appears a Slovenian company, Smarteh, has made a fork of beremiz for their PLC controllers.
Is mentioned here: https://github.com/beremiz/beremiz
Think this should mean they have to make source code available as beremiz is GNU, but not seeing it...
See now that OpenPLC uses MatIEC for the C code that it generates.
https://openplc.discussion.community/post/matiec-manual-compile-9471555
Guess will try using OpenPLC as GUI to generate .st file.
Then, MatIEC to generate C code.
Then, figure out how to make that C code work on P2.
Just did the OpenPLC example here:
https://autonomylogic.com/docs/3-2-creating-your-first-project-on-openplc-editor/
Kind of liking it...
Seeing that it internally uses matiec to create a c file.
But, it's a very ugly c file.
Going to try using matiec stand alone and see if any better.
Think it might be from the examples here:
https://github.com/Felipeasg/matiec_examples/blob/master/and_logic/plc.c
But, one thing not liking is the GNU stamp on the generated c file.
Don't think that just because matiec is GNU that the generated c file has to be GNU.
Might have to change that...
First thing I came across....15 days and no response
Contrast this to setting-up a smartpin(s) on the Prop.
Regular "Joe" needs to be able to make things work
think have matiec compiled after the usual Ubuntu command line pain...
Matiec has build instructions:
But, of course this doesn't work without extra steps...
Had to install/run "autoreconf"
Then had to do "automake --add-missing"
Then "autoreconf" again...
then, "sudo apt get install flex" after the make one liner failed.
Then, finally seemed to actually compile...
Ok, see the real challenge now...
matiec creates a few output files from the input .st file, but mainly a resource and a config file.
Seems there's a way to make these files have the names "STD_CONF.c STD_RESSOURCE.c", but mine are "res0.c" and "config0.c"
The real challenge appears to be to create a main.c file and a plc.c file that will run on P2.
Seeing a Linux, Windows, and STM32f4 example.
Presumably, OpenPLC can create an Arduino version.
@refaQtor is probably getting annoyed by all this? Maybe would start another thread if can actually figure it out...
I imagine there is a lot of mostly mapping mcu ports to/from "standard" industrial addresses and modbus register spaces in these config files. then it synthesizes the C code to read write and make it addressible from the PLC.c code. that is sort of the gist of many these gui code builder schemes. ...
Think BlocklyProp, for example.
that is how I started C coding on Propeller.... I built a few new things with Blockly, then looked at the generated C code. I kinda find Blockly useful on occassion, it does make it pretty easy to follow what is going on, especially when things are happening in parallel, but once you get the pattern of C code it generates, it is way faster to edit the text. Frankly, the real underlying issue of all this, is that no self-respecting "professional" would admit to using the childish interface of BlocklyProp in an "industrial" situation.
You can swing tooo far the other direction and get mired and bogged down by dragging along a ton of arcane baggage from a half-century of industrial control... that keeps an army of annoyed PLC programmers employed.
I think this is less a technical issue than a human one - each of us have our own faovrite hammer with which to hit this problem. Machines are easy to reprogram, people are near impossible.
I don't mind, as long as people are sorting things out. it takes some back and forth... the hard part of reprogramming people
This thread has helped to clarify for me where PLC hardware and a self hosted system are two separate efforts. My head is churning on the hardware at the moment. I will probably open a "customer project" thread when the time comes to show something - instead of just waving my hands around here.
That's been done. I did a quick and dirty port of OpenPLC to ANSI C so that it can be compiled using Catalina, and also generates ANSI C code that can be compiled using Catalina. And it can do this on the Propeller 2. So generating and compiling the C code is the easy bit. But if you want a full self-hosted solution, then building a suitable GUI for the Propeller 2 is going to be where most of the work is. And for this, it is better to start with LDmicro than OpenPLC, since it already has a text-based ladder logic editor (which is then wrapped in a Windows GUI).
However, after doing a little more digging, I am a little confused by how many versions of OpenPLC there actually are, and which one is the most current. The github source for OpenPLC seems to be older than the github source for LDmicro, which was (I think) the original. Then there seems to be several commercial derivatives of both OpenPLC and the OpenPLC editor, so I am now not sure which one would be the best source to start with.
Probably needs a bit more digging from someone who knows more about PLCs than I do.
Yes, if @refaQtor let's us know, happy to continue this particular discussion in another thread. But I will say again that I have no real interest in PLCs themselves - it just seems like it would make an interesting application for Catalina, because it seems to me that Catalina C can handle the C side, and Catalina Lua would be an ideal language to use to implement the GUI.
Ross.
The IEC61131 is quite close to Modula-2/Oberon, (also from Europe) and there is a new Oberon now for the PiPICO
https://www.astrobe.com/astrobe.htm
and some examples of IEC61131 Structured Text for comparison :
https://www.realpars.com/blog/structured-text
@jmg
Oberon is very interesting. Might have a play with it.
However, I don't see support for the PIO. I use the PIO for high-speed quadrature decode (4 encoders/Pico)
The problem, though is that it's always the perspective of an engineer, working on a program at his desk.....no consideration for the schmuck who is responsible for keeping that equipment churning-out product.
These guys don't get to program every day. Mention "uint" or "bool" or "float" and they will throw their hands up in the air and just give up until the outside support guy gets there, maybe in a couple of weeks.
I am talking about grabbing a USB keyboard and a VGA monitor, editing and instantly testing/running code, right on the Pico. No PC, no compiling, etc.
They need to be concentrating on what they need to do, not how to do it.
Craig
Just tried LDMicro. Like that it's simple enough for me to understand
Would people really be interested in such a simple GUI?
Already have a 1080p text driver that could be used for this:
https://forums.parallax.com/discussion/171223/1080p-tiled-gui-with-mixed-signal-scope-demo/p1
In my perfect PLC world, @Rayman, there would be a P1 on the backplane with VGA/USB-keyboard/mouse driving an IDE (that could be the LDMicro Ladder) on your 10080p TextDriver (as a platform to develop other IDEs) which would load the Ladder (or similar intermediate process definition data) onto a P2 that had the runtime to and the massively flexible I/O. The importance of having a TEXT MODE IDE is that it would also be available over and ANSI terminal to the service guy on the floor that had a laptop, but not VGA/keyboard. and that the laptop need not install ANY custom software at all. The P1 would communicate back/forth with the P2 to be able to interogate the P2 for the current actual status and configuration that had been loaded or the active state of pins (coils/contacts). The P1 is to be given entirely over to the management and display features of the PLC, and can use all the pins/cogs for that without worrying about impacting the P2 PLC perrformance of the actual duties.
The active LIVE HMI (not the development interface) of the PLC machine (if it had one) would drive either a TFT interface, or share the system state over modbus as many commercial HMI solutions expect already.
And... ok. good understanding now for laying out circuit boards for development with this strategy. The external interfaces are coming together with discovery of a new all-in-one TI part combining RS-232/422/482 into one for externally protected standard interfaces.
for the 2 processor (backplane chassis management console) and the (P2 PLC runtime executor) I will put down one each of the 80 pin Edge socket. The PLC one is obvious to external machine connections. the backplane socket can use just 32 pins - all of the P1 available pins - for a P1 on an Edge form factor - for the essential chassis monitoring and ANSI only IDE interface.
Or most of the ones also available to the P2 32MB Edge module that would be the top end of IDE management interface.
just a thought.
Ansi terminal interface is interesting idea...
Wondering if a reasonable sized ladder logic program really needs to be compiled at all...
Maybe P2 is fast enough to just process the text directly...
Maybe can "compile" into a set of arrays, one for each line in code...
perhaps arrays of longs for:
Instruction, arg1, arg2, arg3, arg4
1024 line program would need 20 kB of arrays.
So, maybe something like bytecode, but simpler.
pretty certain the intermediate text file format could be stored/loaded from Flash into structures and registers in the Hub RAM that the cogs all operate on directly.
ports potentially: (along the lines of what I've been cooking already)
1. maestro (with nifty new task management)
2. filesystem I/O (avoid contention on disk interface)
3. PLC Ladder
4. PLC Timers
5. all the things I am forgetting at the moment
6. modbus or other protocol data shuffling through cog 8
7. ADC smartpin input (DAC?)
8. 8 port smartpin serial driver (playing with 16, too)
The source
Thinking that @ersmith ANSI VGA text driver will meet goals better (and use only one cog, vs 3 cogs with my 1080p driver).
The columns are less but ANSI serial output does sound attractive too.
Doing this with Micropython too...
Here's a quick test at highest resolution (1280x960 signaled as 1280x1024).
Not 100% sure sold on this driver yet, but seems like it could work...
Not sure if there's a terminal that can work with this resolution or not.
Maybe?