I’m just getting started with my first project. I want to diagram it in some standard way to share the logic with other users as I begin to put the parts and pieces of the OPTO22 system together. Are there any good tutorials for guiding this process control diagramming?
Kirko, well I like my approach and of course one problem in Opto is that they don’t want to put you in a box from the start, however, I would argue that beginners need a box. I arrived at this approach after making many mistakes and some of them repeatedly.
Start by labeling all Block0 as Start, and typically don’t put anything in them. Next, if this chart is a typically looped chart, then the next block should be labeled “Return” block. If you want to run the chart at 1 sec, then put it in here. Any initiallizing you may need to add can simpply be added between these block later. If you need to make a chart that runs once and ends, be sure to label the last block END. This is because later when you use the [B](very important) [/B]FIND (spyglasses) missing connections command and you see these block names show up, you will be able to dismiss those items becuase you know from the block name that they are intentionally missing.
I use a simple top to bottom “tree” style which is sooo much easier to read later when you have forgotten what this program does. All the logic can be branched out to the left or right but I do not use both directions, one or the other, it is much easier to read.
Each branch of logic does one thing or typically a “system” or a piece of a system and originates off the TREE in a conditional block. The condition can be any number of things or just a timer, it depends on what the branch is doing.
The next aspect of my style is that I generally run various conditions on this branch and each one of these conditions use a purple loop block to route either back to the tree BELOW the originating branch (above or even below the next banch) or is routed back to RETURN. Most people assume that routing back to RETURN is a waste of CPU time and that it will slow the logic way down. NOT true, these controllers are very fast at processing “internal” logic and the advantage here is that you get to keep all the conditions in the TREE updated.
Whether the branch routes to return or “continues” to the TREE is dependent on the requirements of the process. Also the branch can extend out as far as neccessary to complete the logic branch. From a readable standpoint, I try to keep it inside a block label readable view window. If necessary I can wrap it back towards the TREE.
Remember, logic loops inside of a branch are just plain bad…I rarely use them and if I do, I make sure that there is no way the loop can loop more than a few times or a few milliseconds maybe as much as 100ms. Remember, if your logic is spinning around in a loop, it’s not doing anything else, and eveything else is not being updated…
[B]NEXT RULE, do not separate logic of a system into multiple charts.[/B] This is the single biggest mistake most people make in Opto, they think that because there are no rules that can do anything they want. Unfortunately, there are rules, they just don’t know them. The problem is when creating multiple charts for the same logic, operating on the same varibales, there is no determination of when one chart will write or read to a specific variable and when a another chart will write or read to that same variable. I just got done with two service calls for an OEM that created this same problem exactly and did multiple times. You do not need to make a million charts, it actually will take more CPU time to run multiple charts than running one chart. Let’s take an example of logic. You have a machine that heat treats metal. In addition, that machine has a conveyor system that runs through it. Now, you can put all the temperature control and oven startup, and safety circuits in one chart and that can run either independent or can be controlled by a flag. Next, you can put the entire conveyor system in another chart and it can either run independent or be controlled by a flag or say by the temperaure of the oven. You should not break the oven temperature control and the associated safety and startup and shut down logic…this will lead to a [B]disaster[/B].
Lastly, to begin a project, the best method is to lay out your thoughts in the form of a chart as decribed above and do it with no logic. Just plop down your blocks and LABEL them as to what you want to do at each step. Once you have a basic outline like this, you can go back and begin installing logic as needed and you will find that you have to move thnigs around and so on until you begin to get a feel for how the actual logic will have to work.
Kirko,
Welcome to the forums.
For the most part, I totally agree with Barrett.
One of the things I liked about Opto when I was starting out was the fact that it pretty much is self documenting and that the flow chart way of programming is both clear and logical.
Barrett explores this concept in the first part of his reply.
You can use color within Pac Control itself to show the logic to others and have them grasp it just by looking at the flow chart. They don’t need to look into each block to understand the process.
Note, this only works with the standard action and condition blocks. If you wrap it all up into an Optoscript block then the whole graphical nature of the flow chart goes out the window and you will need to come up with a way to describe your code.
Where I differ from Barrett is his thoughts on separating logic into different charts. I find it helps a great deal and have never had a problem doing it that way.
I think you should take on board his clear thoughts about how you break it up, but in the end, you know your process, you know your programming skills… Take your time and run through it methodically.
Bottom line, I don’t know of any tutorials on process control diagrams… I’m 100% self taught on Opto 22 from eleventy eight years ago and so have not had to look around for that sort of thing.
Try Google and ‘flow chart’ as a keyword?
Lets know what you come up with. It might be something the training department will look into.
Ben.
Hi Kirko,
I agree w/the guys about using PAC Control to draw a flowchart (which is a standard way to diagram, and perhaps easier to use than Visio or some other tool to draw flowcharts). Add actual commands in later.
However, I wanted to clarify/disagree with this line: “Remember, if your logic is spinning around in a loop, it’s not doing anything else, and eveything else is not being updated…” Not true. Our multi-threaded system divides time between charts and everything else happening in the controller. It is wise to add a delay if you’re looping on a condition (like waiting for an On Latch) which doesn’t need to be checked more than perhaps once every 100 milliseconds. That way the chart running the loop will give up it’s turn and give the other pieces running a bigger slice of the overall pie.
Once you really start having your controller do a lot of things at once, you might want to check out this Tech Note on Performance, especially Page 4 (of form 1776) gets into this concept.
-OptoMary
Kirko,
Also be sure to check out Chapter 4: Designing Your Strategy in form 1700 the PAC Control Users Guide, if you haven’t already. Our award-winning technical writers have put together some simple steps for designing a system and developing a strategy from that design.
Here are some other resources that might be helpful to you as you get going:
SNAP PAC System Self-Training Guide.
-OptoMary
Ok, I agree with Mary and Ben and they and others who have substanial experience know what can and SHOULDN’T be done and certianly those who are newbies can’t possibly know all this which is where the problem is.
One more point before I go is that when trouble shooting where a variable is getting written to at the wrong time and from where it is getting written to is very very hard if not impossible when you have 13 charts most of which are writing to that variable, so which chart do you run autostep to catch the problem? If you have all of the logic for that one process in one chart, it is extremely simple to troubleshoot, if not, good luck. You actually complicate, not simplify the process of troubleshooting when you split a single process up into multiple charts. For instance, there is no good reason I can think of to split up a burner control logic into seperate charts, however, if you also have a furnace door control, then yah ok, put it in a different chart if you see the need.
“Remember, if your logic is spinning around in a loop, it’s not doing anything else, and eveything else is not being updated…” Not true. Our multi-threaded system divides time between charts and everything else happening in the controller. It is wise to add a delay if you’re looping on a condition (like waiting for an On Latch) which doesn’t need to be checked more than perhaps once every 100 milliseconds.
Mary, you’re right about this depending on what else is in the chart that is looping…that is where I argue that if you use my approach where instead of going round in circles you just have it return and comeback through all the other logic in the chart that should be watched then you don’t have to worry about whether other things in the chart are being processed while it waits for that condition to become true. Also, by using this method, you inhernetly simplify the strategy becuase you have more sequential control over execution of the logic. In other words, making sure that logic 1 gets processed before logic 2, etc.
I often find that since I use a modular approach to logic (branches), it often turns out that even though I assume something about the order that logic needs to be processed, I come to relaize in testing that I got the order wrong, and whala, all I have to do is move an entire branch in the tree up or down to fix the problem. Becuase I use routing blcoks for every connection from the branch to anything else, I don’t have 20 graphic lines to fix either since many of these connections will either be to return and the others will typically be to the next block down the tree.
Although loops have their place, I would also point out that most newbies are not aware of all the pitfalls that await them using loops. If a loop only happens once in a blue moon and the programmer is not aware that they produced an infinite loop…
BTW I a not specifically speaking about logic loops like repeat, or while, etc. These can of course produce the same problems. I am speaking about waiting for a specific IO or variable to change versus processing a number of variables in a loop.