Powerup Chart

I am just getting started on my first PAC control project. I have all my I/O working prooperly and am at the point where I need to start building some charts. Could someone please explain the useage of the Powerup chart ? I searched for some info on the site, but didnt find much.
Specifically, I would like to know what should be included in this chart. Are there certain things that are always done in this chart ect ?..
Thank you

Hi Dan,

Welcome to the forums!

Since your Powerup chart is the only one that’s run automatically when the controller powers up, you’ll want it to:

[INDENT]1) Do sanity checking/initialization logic.
2) Start other charts that do various logical tasks for you, often simultaneously. For example, check out this enabler example to monitor your I/O Units and re-enable them in case your controller loses communication (not as relevant if you’re using a SNAP-PAC-R1 or -R2 where the I/O is on the same rack as your controller): Click here to download enabler example.[/INDENT]

Here are a few other links that might be helpful to you as you get going:

[INDENT]Self-training Guide
SNAP PAC System videos
Also don’t forget our support is free! and we also have [URL=“http://www.opto22.com/site/training.aspx?nid=nr3”]free training here in Temecula, California.


Thank you. Can please expand on " sanity checking " ?
I will include the IO enabler even though I am running an integrated controller / IO rack. ( R1 Controller )
I attended training in October and learned alot, but still just getting my feet wet.
As far as the Powerup Chart, I recall using the Move command to move my IO points to variables. Is this always done in the Powerup ? This is only to initialize the variables correct ? I assume that once this initial Move is done, the variables are not updated automatically and I need to run a continuously looping chart to update these variables every second or so ?
For example, evey time I need to get a temperature value from an RTD I/O Point do I have to use the Move command to move the value from the physical I/O point to the variable to do a compare to limit ?

I see this note in the training guide.

[B]NOTE: You could also move the value of the I/O to a variable in your strategy. This would be advantageous when you want to minimize the frequency with which the control engine scans the I/O. By storing an I/O state in a variable, you can reference the variable, rather than the I/O, each time you need the value. This
minimizes the number of times that the I/O point is polled and cuts down on communication time.[/B]

Hi Dan,

The IO enabler is a form of sanity checking. You’re checking certain assumptions which are important for the rest of your logic, like the assumption you can communicate with all your I/O devices. In the case of a system that just has the one R1, assuming you can talk to the I/O is a good assumption – but later when you go to expand and add more I/O units (we hope!) you’ll be ready for them.

Are there any other assumptions you’ll want to check? Say your application all depends on information coming in from a serial device, or perhaps via the Internet. If you can’t talk to that other device you might want to skip starting all your other charts and turn on a big red warning light or attempt to e-mail IT or something. Do you see what I’m saying? (I’m hoping other OptoFans will jump in here and share some assumptions they check in the Powerup chart too.)

Initialization of tables and such are commonly done in the Powerup chart. For example, if I’m going to display a date somewhere with a month and want it spelled out, I might initialize a table like:
[INDENT]stMonth[0] = “January”;
stMonth[1] = “Febuary”;
[/INDENT]etc. I believe in the class there was a list of part names that got plugged into a table in a particular chart. That’s something you might just put in the Powerup chart.

On that note you asked about, in your case you don’t really have need to “minimize the frequency with which the control engine scans the I/O” since:
[INDENT]1) Your I/O values are right there in the R1 with the control engine – you’re not communicating to a very remote I/O connect via satellite (this is possible). Or connected via an older communication method like a serial 485 connection.

  1. You’re system is relatively very small so the CPU is not being taxed by a huge number of other duties.
    [/INDENT]In your case, keeping it simple and just referring directly to your I/O points would probably be best, based on what I know so far. Just compare the RTD’s value directly (and skip the Move command – because you’re correct, when you do that move, your variable is only going to reflect what the value of the RTD was at the moment you did the move).

I hope that helps!


Dan, I’m kind of late responding to your post, so you may have this all figured out by now. If you haven’t had a chance to check out the PAC Control User’s Guide, form 1700, you might want to skim through Chapter 4, Designing Your Strategy. There’s a section called Chart Guidelines and some other things that might be helpful as you work on your strategy.

  • Jean