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 = “January”;
stMonth = “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.
2) 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!