towards a P2 PLC
refaQtor
Posts: 95
I've been doing some work with PLCs lately, and I noticed the interesting fit of the P2 Edge Breakout Boards in these ( https://www.digikey.com/en/products/detail/bud-industries/DMB-4773/2499329 ) and useful ecosystem of DIN rail enclosures and connectors and "standard" peripherals in the PLC industrial control space.... and well the P2 has potential for greater I/O options and flexibility than are common. I am still monkeying with the I/O modules that'll connect over two of the 2x6 P2 expansion headers. but that is besides the point right now.
I'm to the point that I want to begin an ANSI/ASCII terminal-friendly IDE on one cog of the P2 to, among other basics, develop Ladder Logic code that aids development and debug visualization in conjunction with execution (interpretation of intermediate ladder logic representation (or autogenerated Spin2/PASM modules) developed on the first cog IDE) of the logic on a second cog.
So... @cgracey , how is your gee-whizzy onboard IDE development going? I know you were going for VGA directly. What is the potential for both options? and can both be done on only two cogs? to leave the rest dedicated to uninterrupted PLC processing, I/O, timing, counting, logging, etc. May I have a gander at the latest efforts on the embedded editor effort? or is it all gone Typescript?
is this madness? probably... but this's where I am headed.
Anyway, for those interested, this is the thread including some architectural points and Spin2 code suggestions where I got some ideas from Perplexity:
https://www.perplexity.ai/search/i-want-to-implement-a-plc-ladd-R2xWPp1DS86ZOQ3m3o7JSw
or, I should say, Perplexity agreeably confirmed my biases . 
Comments
A P2 based PLC might be interesting. A self-hosted code development and debugging would also be interesting.
Do like the idea of DIN rail mounting.
Would like to find some DIN I/O modules that this P2 PLC could talk to...
Currently, I power the current P2 Edge Breakout Boards with 12V from adjacent DIN rail mounted power supplies and connect some digital I/O to drive adjacently mounted DIN rail relays and such. I'll be adding some standard modbus interfaces, and intend to make many of the I/O reconfigurable and an indication, on a small face mounted touch screen, of the configuration and state of each pin/port - I've tried both neo-pixel per pin, and a Nextion display, too.
There is also a Forth in P2 ROM
which is interesting/elegant/magical,
I very much appreciate it in the P2, and I use it for assorted random interactions to check connections and whatnot. Honestly, I want to learn it better, but it seems to me like a write only language, and every one has to hand sculpt their own, because I haven't found a good way to grok each new person's dictionary/words.
all that aside, I'm working on something different now. Forth is an abstraction too far for me at the moment.
I'm sorry I missed the last live chat this month. Lots of topics to weigh in on. Perplexity PRO does much more than was mentioned. I'm glad to see many getting some good use out of it generally for coding P2 related stuff.
A lot of what is driving this effort for me is, as @cgracey pointed out, is the desire to have the full visual display of the state of the system at all times in real time, and to be waaaaay easier to setup than standard PLC stuff - add some autosetup sort of system to recognize new connections and populate a system view with a way to incorporate it in.
No PLC replacement here but I've used a Prop1 as a Modbus slave, driving an array of stepper motors inside a larger rotary head via four slip-rings. It performs the job well. Customer is very happy. The Prop-plug port is independent of the 485 port so that debugging could be done independently and in real-time. In fact I never disabled debug so it's basically like telemetry whenever plugged in.
As for direction in making a PLC from a Prop2, I'd start with targetting of hubRAM for both rung code and rung data space. Get that going first before looking at any expansion RAM.
Sounds like you're planning on modular I/O. I'd include error correction in the bus protocol for such.
Thanks @evanh , once I dug in (data/rung, data/timer, etc), I was surprised at the amount of LadderLogic that could be stored and processed in the hubram alone. which is good, as it leaves more open pins for the flexibility and equally important aspect of a PLC... lots of I/O.
I say that I'm looking at the PLC market, not so much to step in as a 1-for-1 replacement of the "standard" gear in some established industrial control system. There are plenty of arduino/pi things out there that remain difficult to know you're getting it right and rickety from having a deep pile of dependencies that need constant attention.
A useful contender needs to have some aspect in the development, as Chip pointed out, that makes it easy for a user to see/feel/understand - and feel confidence in - the whole operation as it is happening. I'll keep exploring for the sweet spot in that direction.
very cool... what baud rate are you able to get through slip rings? CRC and retries necessary?
@refaQtor, I am thinking about all this, like you are. I am waiting for some breakthrough in user-experience concept. If I knew exactly what to do I would be all over it.
Was happy with 9600. Never tried anything faster but should be fine up to 115k I'd guess. Just uses the generic FullDuplexSerial.spin with small tweak to manage data turnaround on the 485 bus.
There is an odd CRC error occasionally, so yes the check and retries is important, I think this error is purely a turnaround timing issue. The comms only has to achieve setting of levels. Very low performance burden.
The Modbus handler I acquired from the Obex but I vaguely remember doing quite a lot to it to get working to my liking. No documentation though.
One big change was the Modbus 30000 read-only input registers - I decided to make the handler able to fetch the live values directly itself without any interaction from the stepper tasks. This involved filling out a table of pointers at init that the handler would later lookup and dereference as requested by the Modbus master.
@evanh , good stuff, thanks for the tips. there are some elegant aspects of modbus as a concept, but I haven't hit one "that just worked" . that sort of thing needs an update.
@refaQtor Guess you're looking for a P2 version of something like this, right?
https://docs.arduino.cc/resources/datasheets/AFX00001-AFX00002-AFX00003-datasheet.pdf
I do like standards:
He's not looking for it, he's wanting to design it.
I do have one of those, and the IDE for the standard languages and plain old Ardiuno code mixed in, and I can say none of it is really going the direction I'm interested in. It has been very useful to deal with the existing industry tools (a lot of time with AutomationDirect's CLICK PLCs) and discover I'm not alone in thinking the friction is too high to get things working there and feel good about it... well, the ones I can afford, I only watch videos of the AllanBradleys of the industry - and, if you're there, then you have/need a ton of tools and shims to interface with decades of legacy. I haven't the slightest interest in repeating the mistakes of the past. I want to make all new mistakes
. based on my own experience and dissatisfaction with the way things are now.
Wonder if this software is the way to go:
https://en.m.wikipedia.org/wiki/CODESYS
I note the all important Ladder is missing. From memory, Structured Text (ST) is supposedly representable/interchangeable as Ladder though.
It's not performing a PLC's primary job if an electrician can't read the code.
@cgracey , so, I want to take a stab at turning your fancy font rendering (hi-color, gradients, many sized) into, initially, a text mode console on a VGA/HDMI display. Has any of your color/font code been released?
then, incorporate some vector drawing, where a primary task on a cog is interpreting the internal state of affairs and generating a constant stream of svg-like vector drawing commands... which may include text strings in boxes/circles, for example. I looks like I'll want to poke around @Rayman 's thread here: https://forums.parallax.com/discussion/176036/psram-based-anti-aliased-gui-now-16bpp
Yep... spent a lot of time poking around there. If you wanted to make an industry standard PLC replacement with a P2, and have it fit right into the industry, you'd want to build around tools like that.... and decode and process their binary formats. The P2 does have some great features that could make it outperform many PLCs out there right now. If properly funded, a team could build up a drop-in replacement, so to speak, for industry standard PLC that adheres to all of the IEC 61131-3, and other standards... and I don't see the industry clamoring for more of the same, certainly not in a way that I could imagine a great business case for it. The gear that is out there is fast enough and flexible enough at a price point that is tough to beat.
and...
and Ladder, by many sources, still accounts for 80+% of the industry implementations.
and, I'll point out, that I do see a distinction here where this thread maybe gets muddled together.
- a P2 PLC, with computer based external application development environments, would, I expect, perform admirably
- a P2 PLC-like thing, with self hosted development system, which is what I'm going for. And the self hosted system needn't stop at PLC-like operations.
the final bit of confusion is that I've adopted the DIN rail mounted stuff for my projects, as they are convenient and relatively cheap to make a solid device in the end. I don't mean so much to try to supplant any equipment in the normal role of industrial control.
I was very happy, in the '90s, with the snappy performance of BeOS running on a single 200MHz processor and 8MB RAM streaming multiple videos with audio in separate windows to SVGA displays. I think the race to 4K 24bit color for playing cinematic movies on every computer has swamped every other effort on computers now. I have 12/24 core/thread Ryzen and 32GB of RAM right now that doesn't match the responsiveness of that old system for doing the plain things I want to do.
I'm looking to reclaim some of that, somehow.
and, since we've gone far afield, I'm looking at implementing a compressed database system to serve as the primary storage as efficient network cluster computers did I used in the '80s.... import/export from/to FAT on SD card, or through network.
so, expect me to say some crazy sounding stuff.
And Catalina C and PASM.
I spent a few weeks with Catalina last year. Thanks for reminding me. impressive features and fun playing Zork again! Catalina may yet play a tangential role.
How about this ...
https://github.com/manasdas17/OPLC_Compiler
This is an open source PLC ladder logic compiler that takes ladder logic files and generates an ANSI C program from them that therefore can be compiled on the P2 using Catalina.
Also, although this program is not itself written in ANSI C (it is written in C++) it turns out to be almost completely trivial to convert to ANSI C. It took me about an hour to convert it so that it can now be compiled with Catalina (but note that I have not yet tested it at all!).
So, you can compile this program using Catalina on Windows, Linux or Pi OS and run the resulting executable on the P2. It can then take a Ladder Logic program written on the P2 as input (it is just a text file) and generate an ANSI C program as output, which can then be compiled using Catalina on the P2.
Result? A complete self-hosted PLC development system on the P2!
Sure, a graphical Ladder Logic program editor that runs on the P2 would be nice to have, but is not essential.
EDIT: On reading more, it seems you would also need an "Open PLC runtime" written for the Propeller. The Open PLC project claims this is written in "Pure C" so it should be do-able with Catalina. However, I suspect it may require access to some proprietary code. More investigation required.
Ross.
@RossH said:
All interesting bits.
In the PLC realm, I have little interest in a lowest-common denominator solution that doesn't take advantage of P2 ability to do a mix of soft realtime interface and deterministic hard realtime between its cores nor take advantage of unique features of P2 SmartPins. The interesting part, to me and I would suggest, the valuable part is implementing an "Open PLC runtime" that can perform better (faster, tighter tolerances, more elements, stability in toolchain) than the existing hardware/sfotware combos can deliver. Where people may use the desktop tools (in this "Open PLC" realm) they prefer, and execute on a P2 hardware solution that delivers more than putting it on any other PLC hardware.
I am very interested in being compatible with the data format that comes out of a "open" IDE like this: https://autonomylogic.com/ (will have to judge just how "standard" it is when compared with, for example, the (Windows only) tool that comes with Arduino OPTA)
and some data exchange formats that might be found in here: https://www.plcopen.org/downloads
and something here might interest me on the HMI user interface front: https://beremiz.org/2023/10/29/svghmi.html
I guess that would be up to you, since you would probably be the one that would implement the Propeller 2 runtime on behalf of the Open PLC project, which is where the "magic" would happen. The Open PLC program itself simply takes a Ladder Logic program and converts it to ANSI C. Putting additional P2 "smarts" in that conversion process (such as being able to use multiple cogs to implement parallel parts of the ladder logic) would also up to you, since Catalina gives you all the functionality you might need. But that's something you could do over time, since I presume the way it currently works is to simply generate a linear C implementation of the ladder logic program.
>
I presume it would be, since that is the site that the Open PLC program points you to. Perhaps contact them and ask.
Ross.
I can confirm that my conversion of Open PLC to ANSI C compiles with Catalina and runs ok on the P2, and when that is used on a Ladder Logic test program it generates an ANSI C program which Catalina can then compile ok on the P2.
The whole process takes a couple of minutes. Not lightning fast, but probably ok.
But that is about as far as I can go - I cannot actually execute the resulting program without a suitable Open PLC runtime, and I don't know enough about PLCs to write that.
EDIT: Interesting ... I've just delved a little deeper into the output C program generated, and it is (as I suspected) a fairly simple-minded serial implementation of the logic implemented in the ladder logic input program ... but the conversion program adds comments where parallelization should take place. If I modified the conversion program to insert suitable Catalina "parallelizer" pragmas instead of just comments, the resulting program would be a truly parallel implementation of the original ladder logic program, using as many cogs as are available to implement the logic. I wish I knew enough about PLCs to write the runtime. It looks like it would be a useful application for the Propeller.
Ross.
Run ladder logic in parallel? That sounds tricky as the next rung might depend on previous rung, right?
You have already exhausted my knowledge of PLC's simply by using the term "rung" ...
However, reading the simple Ladder Logic test program provided, it TELLS you what parts of the program should be executed in parallel. But the implementation of the conversion to C simply uses a "for" loop to simulate parallelism, whereas if it used Catalina's parallelizer it could have genuine parallelism.
@RossH said:
That's just the thing I don't want to do; use a "parallelizer". As @Rayman points out, there are specific requirements as to execution order, and having those run alone on cogs to ensure deterministic clock-level execution is important; nay... required to outperform the some Arduino PLC as "good enough". Other cogs and smartpins can offload I/O and do ancillary stuff to ensure the main ladder executes as expected every time without getting interrupted.
I have noted the rather simple sequencers made in C on the Arduino OPTA and similar cases. helped clear some things up for my understanding. I'm only interested if I can do something better than that using unique features of P2. and, again... Ladder is interesting because it is some sort of way to reason about the system. I learned from how the runtimes are built for those sorts of things (you might find it in the Perplexity thread I linked at the top of this) and some logical repeatable ways to execute intermediate instructions which may, or may not, end up being ladder structured.
Thanks for your investigations on the compiler side. Local C compiling (and others) of Catalina is really really interesting; just not what I'm doing at the moment.
Ladder logic might look complex but it’s actually very simple.
If think of it as advancement on relay logic, easier to understand..