@ersmith said:
But I know nothing about PLCs, so I may be missing some crucial piece.
The ladder diagram PLCs usually run a fast scanning loop, to give them quasi-real-time.
Having the ability to map (small) blocks of code to run/scan compiled in COGs would allow the P2 to shine, I think you already have that in flexspin ?
Yeah, more to it than just the language. And I'm not clear on how the non-ladder components integrate with the I/O scan. What I have seen in the past is that Function Blocks get controlled by the Ladder. Basically, Ladder is then top level with everything else activated from it. But I've not seen a full IEC compliant setup so maybe there is alternate ways.
Perhaps it begins with a straight across translation of ST to Spin2. Regarding the Venn Diagram earlier, it seems Structured Text is the best target across all domains. The language mapping along these lines at first glance seems simple enough.
Here's a table showing a 1:1 mapping of some common Structured Text (ST) language elements to their Spin2 equivalents:
now, I've not implemented these, but have reviewed some of the C generated code from other tools. some questions I bounce of perplexity to get a feel for what might be possible...
I asked this: Ladder, conceptually, has a concept of 1.scan all the inputs, 2.perform all the logic, 3. put all the Outputs, 4.update timer. how does ST perform it operations? are they strictly ordered like Ladder? in PLC projects with mixed languages, how do they operate together on the same runtime?.
Structured Text (ST) in PLCs follows a similar execution model to Ladder Logic, with a sequential scan cycle. The flow of ST programs is as follows:
1. Read all inputs into the input image table.
2. Execute the program statements sequentially, from top to bottom.
3. Write the resulting output image table to the physical outputs.
4. Perform housekeeping tasks, such as updating timers and counters[2].
ST programs are executed in a strictly ordered manner, similar to Ladder Logic. The compiler translates ST code into machine code that the PLC can execute, with each statement being processed sequentially until a semicolon is reached, indicating the end of that statement[1].
In PLC projects with mixed languages, the different programming languages operate together within the same runtime environment. The execution follows these principles:
1. The main routine, regardless of the language used, is always executed first.
2. Subroutines are called and executed as encountered in the program flow.
3. When a subroutine is called, the scan continues in that routine until it's completed, then returns to the point where it was called[2].
For example, in a mixed-language project:
1. The main routine might be in Ladder Logic.
2. It could call a Structured Text subroutine for complex calculations.
3. The ST subroutine might then call another subroutine in a different language.
4. After completing the subroutines, execution returns to the main Ladder Logic routine[2].
This integration allows programmers to leverage the strengths of each language while maintaining a consistent execution model across the entire PLC program.
Citations:
[1] https://www.plcacademy.com/structured-text-tutorial/
[2] https://www.controleng.com/articles/plc-programming-language-fundamentals-for-improved-operations-maintenance/
I seriously wouldn't attempt multi-language conversion/integration initially, or ever. But I ask the question to understand the, still, strictly sequential nature of execution in and out of subroutines. and that it still does the 4 step process of scan inputs/process/output/timing updates
It occurs to me that the processing part (in PLC land, they continually watch that the speed that this loop repeats must not get too long - I'm sure P2 can handle it) all the code that uses, as input, the results of another calculation, it must remain strictly sequential. BUT subroutines that do some calculations based strictly on the read inputs at the first step, can all be done in parallel on another free cog, or queued to get processed on other cogs using the nifty new Task feature of Spin2. The fact that Tasks are co-operative (not pre-emptive) is important for getting repeatable execution order and timing.
all the time spent on those subroutines needn't happen at the time in the sequence, the results would simply be there at the time the subroutine would be normally "called"
Technically, they're not a subroutine if they aren't executing in sequential order.
I do agree with the idea that routines written in procedural/functional languages should be able to run concurrently to the ladder. The ladder just provides the top level control interface as much for documenting of control wiring as anything.
PS: Looking on that linked Control Engineering web page I see Instruction List (IL) is definitely the one that is the textual form of Ladder Logic.
@refaQtor said:
now, I've not implemented these, but have reviewed some of the C generated code from other tools. some questions I bounce of perplexity to get a feel for what might be possible...
.... It occurs to me that the processing part (in PLC land, they continually watch that the speed that this loop repeats must not get too long - I'm sure P2 can handle it) all the code that uses, as input, the results of another calculation, it must remain strictly sequential. BUT subroutines that do some calculations based strictly on the read inputs at the first step, can all be done in parallel on another free cog, or queued to get processed on other cogs using the nifty new Task feature of Spin2. The fact that Tasks are co-operative (not pre-emptive) is important for getting repeatable execution order and timing.
all the time spent on those subroutines needn't happen at the time in the sequence, the results would simply be there at the time the subroutine would be normally "called"
I think a practical system needs to be able to give the user choice of both buffered/scan and real-time-local handling of pin access.
As a compile-time choice, this should be easy to manage.
The buffered / scan model would copy IP pins and some time later, update all output pins in 2~3 opcodes each.
An interrupt could pace that, so very small programs did not scream and change speed as they grew.
Real time local would work directly on the pins, and would allow ST coding of i2c and even WS2812 LED out bit bang routines, that would be user-directed to compile as COG local.
A practical system should also be able to launch COGS with images compiled in (any) other languages ( USB and Displays come to mind here )
Near the bottom of that same page there is a picture of ladder using subroutines. Note: A function block in ladder is different again.
Those "Jump Subr." squares are literal instructions. They tell the execution to gosub to another section of the ladder. And those sections will have a "Return" square, usually shown on an unconditional ladder rung, at their end.
BTW: I've never seen a subroutine used in ladder, and I wouldn't expect anyone to try. Symbolic referencing in ladder is primitive and clumsy. It isn't intended for data processing.
Can't say I think much of Function Block Diagrams (FBD) either. They lack the sequential structure that Ladder Logic naturally provides in its top to bottom flow. FBD is clearly an attempt to make it look like real logic hardware but a CPU can't do that for real. It has to do the logic equations in some order.
I bet FDB use is avoided because of this confusion/difficulty.
Sequential Function Charts (SFC) are a totally different approach to sequencing. They are intended as state machines. But you need to be very rigorous. State machines get buggy real easy.
I could see them getting effective use in conjunction with Ladder Logic.
@ersmith said:
But I know nothing about PLCs, so I may be missing some crucial piece.
The ladder diagram PLCs usually run a fast scanning loop, to give them quasi-real-time.
Having the ability to map (small) blocks of code to run/scan compiled in COGs would allow the P2 to shine, I think you already have that in flexspin ?
Yes, the master loop.. Very important, and all blocks must be open ended and not loop infinitely internally. (Some companies won't allow loops at all)
Procedure of the runtime always goes something like this:
process inputs. (Includes communication-derived inputs)
Run through user code. (I will stick with Codesys as example, the software is free.. and could easily use something like Flexspin as a backend...) Can be ladder, stl, fb or any combination thereof. I still need to verify, but I am quite certain that all of these end up ultimately in STL. (Maybe even C..) for compilation.
process outputs. (includes communication outputs)
Housekeeping
Loop to step 1
Codesys allows scheduling of the loop, where housekeeping includes a delay to keep the 'scan' through the process somewhat deterministic. 'Freewheeling' is also possible where the loop just goes as fast as it can.
I'm not interested in following the sheep because they're all wrong 😁
The industry doesn't want people using Propellers or other simple solutions and so they are gonna keep coming up with "standards" and all kinds of ridiculous justifications for them.
Like Fieldbus....but which standard is standard?
@Mickster said:
I was excited until I got to "runtime license". 🤮
yup. codesys is flashy, and interesting right up to that point.
I have settled on the unknown NMC (network machine control), 4-wire, multidrop RS422 because it is as simple as it can get.
I will have to look up NMC. sounds like right up my alley. I, too, tended to prefer RS422. Having a "standard" of NMC would assist in integrations, if necessary.
On the code side. I've spent some more time looking at the similarities between Spin and another industry standard "Structured Text" that already have a full desktop IDE (OpenPLC) that looks like what the industry expects. OpenPLC uses a text (XML) file format that aids the extraction for translation to Spin2.
Structured Text really (like the Venn showed) digital/analog discrete/continuous realms... so much so that I am not entertaining any thoughts on Ladder or other standard graphical formats. Doing a Propeller onboard ANSI editor for Structured Text (with practically direct translation to Spin2- no need for extracting from xml) is where my head is at right now.
@evanh said:
Without the Ladder it's not really a PLC. It would fail at being readable source code for electricians. It just becomes another embedded controller.
I get it... a huge part of that world is Ladder on a PLC. I'm not really stuck on definitions of PLC or subroutines. There are effective things to extract from the industrial control world (the test/repeatability processing loop with measurable metrics, the modularity of functional blocks) , and unless you make something different that shows some actual benefit/advantage over what is there - it doesn't interest me. Hosted Structured Text is likely only a stepping stone on to a National Instruments LabView sort of interface - with better/different integration between development and HMI.
@Mickster said:
I was reading, recently, about the limitations of separate PLC and Motion Controller. The P2 can handle both with ease.
"limitations" are you talking about the ever increasing need for higher speed dedicated communication buses/protocols to try to get realtime-iness out of motor control and limit of cascading I/O to fan out.... all making it difficult to orchestrate multiple motors/actuators in real time.... sort of stuff?
Can now draw a more complex series/parallel structure on VGA.
There must be a standard way of drawing things like this...
Could have copied from ldmicro, but wanting to avoid GNU license.
So, can make this MIT license, but I'm sure the drawing code is hopelessly full of bugs.
At least, can do this now. Maybe that's enough for now...
Think will move on to ANSI terminal output (think can just dump the screen buffer...).
Also, want to see if can actually run the code on P2.
Thinking this will be easier than trying to draw it.
But, maybe it will turn out to actually be a very similar process...
@evanh said:
Without the Ladder it's not really a PLC. It would fail at being readable source code for electricians. It just becomes another embedded controller.
I get it... a huge part of that world is Ladder on a PLC. I'm not really stuck on definitions of PLC or subroutines. There are effective things to extract from the industrial control world (the test/repeatability processing loop with measurable metrics, the modularity of functional blocks) , and unless you make something different that shows some actual benefit/advantage over what is there - it doesn't interest me. Hosted Structured Text is likely only a stepping stone on to a National Instruments LabView sort of interface - with better/different integration between development and HMI.
PLCs are about building the machine so that the local electricians can easily troubleshoot without any input from the manufacturer. They aren't going to be interested in how a filter works or whether software is buggy or not. They're looking for loose wiring, misadjusted or damaged sensors.
It's surprising how much can be divided off into control logic too. Take a quality inspection camera for example. It might have a cutting edge machine learning algorithm using multiple high resolution cameras to identify the slightest defects, but in the end it still comes down to a pass/fail decision. Ladder manages the result just fine. Better than fine, it tells everyone what the machine is doing with the pass/fail result.
And even the patent holders are kept happy. The code doing the image analysis is still inside a black box.
I've not seen any Structured Text source code for real but my gut tells me it's either an extremely limited language, nothing more than Ladder Logic that looks more formal, or it's intended to be subordinate and operates concurrently with one of the other IEC logic languages.
If you're wanting more than simple control logic at the top level then just use Spin or Basic or C and call it an embedded controller. If you're not managing the top level control with Ladder Logic, or something as equally rigorous, then PLC is the wrong name.
@evanh said:
If you're not managing the top level control with Ladder Logic, or something as equally rigorous, then PLC is the wrong name.
again... don't care what you call it.
but the standards body for PLC languages identify Structured Text as a key language of the IEC-61131-3 standard . ya know.... that standard that the IDEs like CODESYS and OpenPLC strive to satisfy.
pretty sure the guy in the field trying to fix it wouldn't care if you called it a peanutbutter sandwich, as long as it helped him debug the system.. graphically, and easily. and that may have been done in Ladder, but should not be limited to Ladder. there are plenty of enhancements to displaying live the status of the system. and assist in debugging. all well beyond those languages.
and, from the current miserable experience I'm having of trying to decipher and modify Ladder Logic code for these fancy mass-flow controllers that require stepping through strings of characters and doing math digit by digit, which I find on industrial control forums, not uncommon.... I see that there is an official language that covers the full spectrum of digital/analog discrete/continuous. so, that is why I look to making that more useful and easier to see visually live what is going on in the system.
Comments
The ladder diagram PLCs usually run a fast scanning loop, to give them quasi-real-time.
Having the ability to map (small) blocks of code to run/scan compiled in COGs would allow the P2 to shine, I think you already have that in flexspin ?
Yeah, more to it than just the language. And I'm not clear on how the non-ladder components integrate with the I/O scan. What I have seen in the past is that Function Blocks get controlled by the Ladder. Basically, Ladder is then top level with everything else activated from it. But I've not seen a full IEC compliant setup so maybe there is alternate ways.
Perhaps it begins with a straight across translation of ST to Spin2. Regarding the Venn Diagram earlier, it seems Structured Text is the best target across all domains. The language mapping along these lines at first glance seems simple enough.
Here's a table showing a 1:1 mapping of some common Structured Text (ST) language elements to their Spin2 equivalents:
now, I've not implemented these, but have reviewed some of the C generated code from other tools. some questions I bounce of perplexity to get a feel for what might be possible...
I asked this: Ladder, conceptually, has a concept of 1.scan all the inputs, 2.perform all the logic, 3. put all the Outputs, 4.update timer. how does ST perform it operations? are they strictly ordered like Ladder? in PLC projects with mixed languages, how do they operate together on the same runtime?.
I seriously wouldn't attempt multi-language conversion/integration initially, or ever. But I ask the question to understand the, still, strictly sequential nature of execution in and out of subroutines. and that it still does the 4 step process of scan inputs/process/output/timing updates
It occurs to me that the processing part (in PLC land, they continually watch that the speed that this loop repeats must not get too long - I'm sure P2 can handle it) all the code that uses, as input, the results of another calculation, it must remain strictly sequential. BUT subroutines that do some calculations based strictly on the read inputs at the first step, can all be done in parallel on another free cog, or queued to get processed on other cogs using the nifty new Task feature of Spin2. The fact that Tasks are co-operative (not pre-emptive) is important for getting repeatable execution order and timing.
all the time spent on those subroutines needn't happen at the time in the sequence, the results would simply be there at the time the subroutine would be normally "called"
maybe? something like that.
Technically, they're not a subroutine if they aren't executing in sequential order.
I do agree with the idea that routines written in procedural/functional languages should be able to run concurrently to the ladder. The ladder just provides the top level control interface as much for documenting of control wiring as anything.
PS: Looking on that linked Control Engineering web page I see Instruction List (IL) is definitely the one that is the textual form of Ladder Logic.
I think a practical system needs to be able to give the user choice of both buffered/scan and real-time-local handling of pin access.
As a compile-time choice, this should be easy to manage.
The buffered / scan model would copy IP pins and some time later, update all output pins in 2~3 opcodes each.
An interrupt could pace that, so very small programs did not scream and change speed as they grew.
Real time local would work directly on the pins, and would allow ST coding of i2c and even WS2812 LED out bit bang routines, that would be user-directed to compile as COG local.
A practical system should also be able to launch COGS with images compiled in (any) other languages ( USB and Displays come to mind here )
Near the bottom of that same page there is a picture of ladder using subroutines. Note: A function block in ladder is different again.
Those "Jump Subr." squares are literal instructions. They tell the execution to gosub to another section of the ladder. And those sections will have a "Return" square, usually shown on an unconditional ladder rung, at their end.
BTW: I've never seen a subroutine used in ladder, and I wouldn't expect anyone to try. Symbolic referencing in ladder is primitive and clumsy. It isn't intended for data processing.
Can't say I think much of Function Block Diagrams (FBD) either. They lack the sequential structure that Ladder Logic naturally provides in its top to bottom flow. FBD is clearly an attempt to make it look like real logic hardware but a CPU can't do that for real. It has to do the logic equations in some order.
I bet FDB use is avoided because of this confusion/difficulty.
Sequential Function Charts (SFC) are a totally different approach to sequencing. They are intended as state machines. But you need to be very rigorous. State machines get buggy real easy.
I could see them getting effective use in conjunction with Ladder Logic.
Yes, the master loop.. Very important, and all blocks must be open ended and not loop infinitely internally. (Some companies won't allow loops at all)
Procedure of the runtime always goes something like this:
Codesys allows scheduling of the loop, where housekeeping includes a delay to keep the 'scan' through the process somewhat deterministic. 'Freewheeling' is also possible where the loop just goes as fast as it can.
I was excited until I got to "runtime license". 🤮
I'm not interested in following the sheep because they're all wrong 😁
The industry doesn't want people using Propellers or other simple solutions and so they are gonna keep coming up with "standards" and all kinds of ridiculous justifications for them.
Like Fieldbus....but which standard is standard?
Modbus?
Profibus?
Sercos?
Industrial Ethernet?
EtherCAT?
CAN?
I have settled on the unknown NMC (network machine control), 4-wire, multidrop RS422 because it is as simple as it can get.
I feel like the kid in The Emperor's New Clothes shouting "wait, this is a bunch of bollox" 🤣 😂
yup. codesys is flashy, and interesting right up to that point.
I will have to look up NMC. sounds like right up my alley. I, too, tended to prefer RS422. Having a "standard" of NMC would assist in integrations, if necessary.
On the code side. I've spent some more time looking at the similarities between Spin and another industry standard "Structured Text" that already have a full desktop IDE (OpenPLC) that looks like what the industry expects. OpenPLC uses a text (XML) file format that aids the extraction for translation to Spin2.
Structured Text really (like the Venn showed) digital/analog discrete/continuous realms... so much so that I am not entertaining any thoughts on Ladder or other standard graphical formats. Doing a Propeller onboard ANSI editor for Structured Text (with practically direct translation to Spin2- no need for extracting from xml) is where my head is at right now.
Without the Ladder it's not really a PLC. It would fail at being readable source code for electricians. It just becomes another embedded controller.
I get it... a huge part of that world is Ladder on a PLC. I'm not really stuck on definitions of PLC or subroutines. There are effective things to extract from the industrial control world (the test/repeatability processing loop with measurable metrics, the modularity of functional blocks) , and unless you make something different that shows some actual benefit/advantage over what is there - it doesn't interest me. Hosted Structured Text is likely only a stepping stone on to a National Instruments LabView sort of interface - with better/different integration between development and HMI.
"limitations" are you talking about the ever increasing need for higher speed dedicated communication buses/protocols to try to get realtime-iness out of motor control and limit of cascading I/O to fan out.... all making it difficult to orchestrate multiple motors/actuators in real time.... sort of stuff?
elaborate, briefly, if you please.
thanks.
@Mickster do you have a preferred physical connector for NMC between equipment? and pinout?
Hacked the ldmicro source code to add Parallax P2 to the menu.
With this .exe file, one can now pick P2 as MCU and assign pins...
Getting close to being able to read in a .ld file from ldmicro and display the ladder on VGA...
The hard part though is getting serial/parallel combinations right.
This may take me some time...
This is a start though...
veeeeeery cool! really, a great start!
Well, you know about it, so it's not completely unknown.
How can I learn about it? Generic web searches didn't really turn up what I was hoping for.
Can now draw a more complex series/parallel structure on VGA.
There must be a standard way of drawing things like this...
Could have copied from ldmicro, but wanting to avoid GNU license.
So, can make this MIT license, but I'm sure the drawing code is hopelessly full of bugs.
At least, can do this now. Maybe that's enough for now...
Think will move on to ANSI terminal output (think can just dump the screen buffer...).
Also, want to see if can actually run the code on P2.
Thinking this will be easier than trying to draw it.
But, maybe it will turn out to actually be a very similar process...
where are you running this now? this is fantastic.
The code is running on P2, but it is just drawing the ladder…
Next is to make it actually run the code…
Alternatively, could use the c file that ldmicro can make. But, this way allows for eventual on chip editing of the ladder…
PLCs are about building the machine so that the local electricians can easily troubleshoot without any input from the manufacturer. They aren't going to be interested in how a filter works or whether software is buggy or not. They're looking for loose wiring, misadjusted or damaged sensors.
It's surprising how much can be divided off into control logic too. Take a quality inspection camera for example. It might have a cutting edge machine learning algorithm using multiple high resolution cameras to identify the slightest defects, but in the end it still comes down to a pass/fail decision. Ladder manages the result just fine. Better than fine, it tells everyone what the machine is doing with the pass/fail result.
And even the patent holders are kept happy. The code doing the image analysis is still inside a black box.
I've not seen any Structured Text source code for real but my gut tells me it's either an extremely limited language, nothing more than Ladder Logic that looks more formal, or it's intended to be subordinate and operates concurrently with one of the other IEC logic languages.
If you're wanting more than simple control logic at the top level then just use Spin or Basic or C and call it an embedded controller. If you're not managing the top level control with Ladder Logic, or something as equally rigorous, then PLC is the wrong name.
again... don't care what you call it.
but the standards body for PLC languages identify Structured Text as a key language of the IEC-61131-3 standard . ya know.... that standard that the IDEs like CODESYS and OpenPLC strive to satisfy.
pretty sure the guy in the field trying to fix it wouldn't care if you called it a peanutbutter sandwich, as long as it helped him debug the system.. graphically, and easily. and that may have been done in Ladder, but should not be limited to Ladder. there are plenty of enhancements to displaying live the status of the system. and assist in debugging. all well beyond those languages.
I'm trying to help with clarity of understanding. What's effective and why.
I appreciate that.
I don't think so.
there has been useful discussion here. I think many of us learned things about the industrial control world.
guess I'm not going "toward a P2 PLC" I'll startup another thread in Customer Projects as "beyond a P2 PLC"
and, from the current miserable experience I'm having of trying to decipher and modify Ladder Logic code for these fancy mass-flow controllers that require stepping through strings of characters and doing math digit by digit, which I find on industrial control forums, not uncommon.... I see that there is an official language that covers the full spectrum of digital/analog discrete/continuous. so, that is why I look to making that more useful and easier to see visually live what is going on in the system.