How do we want to handle ladder logic?

[Michael-F-Bryan]

I think it'd be cool if rustmatic could handle ladder logic programs as well as structured text.

One way we could do this is by getting people to write ladder logic programs using 3rd party software, then parse whatever format that software uses to export ladder logic so we can compile it to wasm (using the rustmatic-iec crate).

Another option is to make our own application for creating ladder logic programs. I'm fairly confident I've got the experience and knowledge to do this (it's quite similar to the CAD/CAM program I wrote at work, just smaller), but it would require a non-trivial amount of effort.

In the long term having an editor people could use in their browser (by compiling to WASM and using an existing framwork like yew) would be really cool, and a great demonstration of the project... But it also opens us up to scope creep and designing interactive programs can get really fiddly because users tend to do random things you wouldn't expect.

@NOP0, thoughts?

[NOP0]

Another option is to make our own application for creating ladder logic programs. I'm fairly confident I've got the experience and knowledge to do this (it's quite similar to the CAD/CAM program I wrote at work, just smaller), but it would require a non-trivial amount of effort.

Yeah, it's a lot of work, I've got no easy answer for this. Other than we could maybe target the standard xsd format first, and maybe functionality for just displaying the ladder, and then we could of course do the gui later....I don't know...

In the long term having an editor people could use in their browser (by compiling to WASM and using an existing framwork like yew) would be really cool, and a great demonstration of the project..

Killer feature!

I don't know if it's relevant, but the standard also describes an ascii format for ladder. whipped together a quick example. Would it be easy to parse? We could sidestep the gui "problem" in short term, but maybe it's more job than it's worth.

|                                                               |
|       my_bool      my_other_bool                   my_output  |
+---------| |---------|/|-----------------+------------( )------+
|                                         |  
|                                         |  
|                    my_timer             |  
|                    +-----+              |  
|         %IX0.0     | TON |              |  
+---------| |--------|IN  Q|--------------+
|                T#5s|PT   |
|                    |     |
|                    +-----+                         

[Michael-F-Bryan]

I guess the ascii form would be easier to work with because it's not interactive and we don't actually need to write a UI. I'm guessing under the hood the UI and ascii forms would use the same code and object representations under the hood, so it seems like a good place to start 👍

I'm not sure how we'd actually parse it though, it's kinda like a poor man's image recognition and feels like it'd be quite brittle and/or annoying to code... That said, I'm sure there are already loads of programs out there which do exactly this, so hopefully we'll be able to find something that can be used as inspiration.

[NOP0]

Yeah its not ideal. Are there some good Ascii Art editors?

Some brainstorming;

• The file should maybe be read into a grid. I suspect we will need to traverse in all directions when parsing.
• Maybe we should flatten the representation and then one could use the ordinary structured text PEG grammar as the next step. Example box like my_timer above, we define the insertion point to always be top left pin. Then we can traverse clockwise getting |+-----+||||+-----+|||, which gives the "footprint" of the box. By convention the type (here TON) is right under the top bar, and the variable name is always above the top bar.
• Or we can maybe store the graphical representation of TON like a raw string and match on this. Do some "reverse" text template stuff to read out argument values etc?
• Another aspect is that we could give each rung a "result logic operation". This is like a running total of all previous logic operations for the rung. So when a rung is traversed/interpreted you can look at this bit and do your and/or whatever with the current instruction. Like an Accumulator machine

[Michael-F-Bryan]

Sooo.... remember how we both agreed that writing a full-blown GUI editor for Ladder Logic programs would be a bit over the top?

http://adventures.michaelfbryan.com/posts/ecs-outside-of-games/#conclusion

🤣

[NOP0]

I'm all in 😆 I have a prior interest in (simple) ECS outside games also (since OOP is generally not available on PLC's, ECS is sometimes a good fit, as you can build a performant poor man's ECS system using only arrays. +all the benefits you describe in the blog post)

Where do you want contributions?

[Michael-F-Bryan]

I don't know yet. I was thinking of publishing the arcs crate as its own self-contained project, then once it's on crates.io we can add a rustmatic-ladder-editor crate to this workspace and start implementing the actual editor here.