Host Engineering Forum

General Category => Do-more CPUs and Do-more Designer Software => Topic started by: clarkjohnken on March 12, 2020, 10:38:24 PM

Title: Do-More Structured Programming Practices
Post by: clarkjohnken on March 12, 2020, 10:38:24 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?
Title: Re: Do-More Structured Programming Practices
Post by: ATU on March 17, 2020, 08:24:55 PM
Use "Main" as your central call location to enable the other code blocks.  People going behind you will probably start there if they are trying to figure out your program.  I tend to save the TopOfScan routine for updating data that affects the entire program like remote I/O and remote data. BottomOfScan is good for outputing the same. Take advantage of ability to order your blocks by execution order. You can create a task that evaluates the machine state and  order that first in line after Main. Good practice to separate machine functions in different code blocks.  Use stages for sequential logic where it fits. Your code will execute much faster. Yes, the more you can separate machine functions and isolate the variables used within, the easier it is debug and  the more likely it will be portable and re-usable for other projects.