Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Maxwell on March 09, 2013, 05:16:43 PM
-
I'm currently working on my first complicated effort using a Do-more and I want to take advantage of the Program & Task code blocks in order to best organize the plc code so that it is easy to understand / edit by others, or if I come back to it several years later. I was thinking that instead of having a super long $main with lots of comments, I could consolidate certain "functions" into code blocks. Some of this seems obvious to me, such as putting code specific to Maintenance Mode in a program called Maintenance, etc... One thing that I was also thinking about doing is enabling a couple of tasks for continuous run via $tTopOfScan and then using them for organizational purposes. As an example, maybe set one task up called "CMore_stuff" for triggering c-more screen changes, for creating special object visibility triggers for objects on the c-more screens, etc...
A second task I thought about setting up is one for consolidating long streams of conditions into a single bit or memory location. For example if I have activities that take place if all machines are active, or if all machines are down for maintenance, then set up all the condition strings that turn on the "All_Running" or "All_Down" bits here instead or having super long condition strings in my regular code rungs or instead of just doing a consolidation rung the first time I get to one of those points in the code.
Does anyone with more experience have any comments as to if this is appropriate and would be a good practice? (If this is a really bad practice for some reason that I haven't thought of, please tell me that too.) Any suggestions as to other good practices?
-
I'm currently working on my first complicated effort using a Do-more and I want to take advantage of the Program & Task code blocks in order to best organize the plc code so that it is easy to understand / edit by others, or if I come back to it several years later. I was thinking that instead of having a super long $main with lots of comments, I could consolidate certain "functions" into code blocks.
Excellent! This is exactly our intent.
Some of this seems obvious to me, such as putting code specific to Maintenance Mode in a program called Maintenance, etc... One thing that I was also thinking about doing is enabling a couple of tasks for continuous run via $tTopOfScan and then using them for organizational purposes. As an example, maybe set one task up called "CMore_stuff" for triggering c-more screen changes, for creating special object visibility triggers for objects on the c-more screens, etc...
These are both excellent ideas. Some of the built in tasks are actually handled exactly this way...by hidden blocks.
A second task I thought about setting up is one for consolidating long streams of conditions into a single bit or memory location. For example if I have activities that take place if all machines are active, or if all machines are down for maintenance, then set up all the condition strings that turn on the "All_Running" or "All_Down" bits here instead or having super long condition strings in my regular code rungs or instead of just doing a consolidation rung the first time I get to one of those points in the code.
I'm personally not a ladder logic guy, but when developing FPGA code (which is similar to LL in certain ways) I extensively use this technique.
Does anyone with more experience have any comments as to if this is appropriate and would be a good practice? (If this is a really bad practice for some reason that I haven't thought of, please tell me that too.) Any suggestions as to other good practices?
The things you are proposing are excellent ideas. Just use tasks for concurrent bits of logic and programs for self contained logic that controls their own lifespan. Stages in programs are great for controlling sequences. And please let us know how it goes.
-
A second task I thought about setting up is one for consolidating long streams of conditions into a single bit or memory location. For example if I have activities that take place if all machines are active, or if all machines are down for maintenance, then set up all the condition strings that turn on the "All_Running" or "All_Down" bits here instead or having super long condition strings in my regular code rungs or instead of just doing a consolidation rung the first time I get to one of those points in the code.
The MATH instruction is great for this!
MATH,
Result: C0
Expression: IF(C1&&C2&&C3&&C5,1,0)
If C1, C2, C3, and C5 are all on then C0 will be on, else C0 will be off.
Check out the help for MATH and there is a whole list of Binary operands as well as compares for consolidating RLL into MATH. I love it ;D
-
Thanks for the detailed feedback BobO. I'm often nervous about unintended consequences and it's reassuring to know that what I'm trying makes sense.
Quote from: plcnutThe MATH instruction is great for this!
MATH,
Result: C0
Expression: IF(C1&&C2&&C3&&C5,1,0)
If C1, C2, C3, and C5 are all on then C0 will be on, else C0 will be off.
Thanks for the suggestion. I've been doing contacts and never even thought of using the Math function. I'll definately try it.
-
Quote from: plcnutThe MATH instruction is great for this!
MATH,
Result: C0
Expression: IF(C1&&C2&&C3&&C5,1,0)
If C1, C2, C3, and C5 are all on then C0 will be on, else C0 will be off.
Thanks for the suggestion. I've been doing contacts and never even thought of using the Math function. I'll definately try it.
The MATH box is quite extensive and has many things that you might not expect. As plcnut mentioned, they do fully support boolean operators, making it possible to do combinatorial logic in a equation.