Using the Release 10 of the PAC Control IDE , what are considered best practices for sharing charts across multiple strategies?
We have 5 nearly identical pieces of equipment to control. The differences are minor enough that nearly all of the charts work on any equipment. There are some differences:
Analog I/O scaling, and
a few of option settings may be different. The option settings include things like time-out settings, flow and temperature setpoints, and flags indicating the presence of a specific equipment option.
Currently, we are doing this
each equipment has its own strategy in its own directory.
the charts are identical in each folder
each equipment has its one option file that is specified in the control engine download options
where a specific equipment item requires different code paths within a chart, an option setting (usually specified in the download options) is used in a decision block to specify the specific code path to be used for that option.
during development, when we change a chart, we manually import the modified chart(s) into the corresponding charts in the other strategies.
If they are as similar as you say - then why do you have them in separate strategies at all?
Analog IO scaling can be setup by using a chart if needed using memory map commands, so you can configure them through an initialization file too. Sounds like you already have everything else setup that way.
The equipment I refer to is part of an overall interconnected system, and in real life, all of them are running at the same time as part of a cluster of equipment. There are some interactions (material can be passed between them), so we need to be monitoring I/O and charts on multiple pieces of equipment at the same time. We currently to this from a PC by opening multiple sessions of PAC Control at the same time.
Note that each equipment has a different IP address, and the include files we download to each equipment have differences among them. The ability to define separate control engines handles these differences, as the IP Address and path to the include files are specified per control engine. However, when you compile a strategy to get a download file, you can only do it for the currently active control engine.
The bigger problem is that once you have opened a strategy, you cannot open that same strategy in another session of PAC Control. If you want to see what is happening on two different pieces of equipment at the same time, you need to use difference strategies, one for each controller.
I saw the forum thread about scaling analog I/O. Personally, I do not like the idea of mucking with the memory map to change individual I/O configuration settings. You now have chart logic in the control layer directly coupled with low level details of the I/O layer. It would be better to have high level commands to get and set I/O point attributes.
Sounds like you have it pretty sorted.
Why not use pac display or groov to monitor the different I/O and charts? It seems to me that using pac control to do this would be very difficult and prone to human error due to the cluttered GUI.
DEBUG mode is used for verifying I/O connectivity after the tool is built, and after servicing. I suppose that we could implement a PAC display that displays all the digital and analog input values and lets a tech turn on and off all the digital output values and analog output values. Instead we train the techs on how to use the PAC Control I/O dialogs that already exist.
These dialogs are also as close to the hardware as we can get. The I/O dialog from PAC Control displays the actual IVALs and XVALs that the controller thinks the I/O module is sending. If a physical switch is on, but the I/O dialog tells us it is off, then we look at wiring, connectors and the I/O module. If the I/O dialog agrees with the switch setting, that tells us to look at the logic.
