In another thread that started on the topic of choosing tag/variable names, we ventured into several other topics, including using init files, FlagLock/Unlock commands, and pointers:
http://www.opto22.com/community/showthread.php?126-What-s-in-a-name-Chose-tag-names-wisely...&p=350#post350
The question was asked: How are others using pointers?
I hope many of you are using the Example strategy called IO_Enabler for Enet & PAC Brains (installed with PAC Control), which will automatically re-enable I/O Units that have become disabled.
In IO_Enabler_Chart’s pink block (Block 1, called User Initialization) you can see where a Pointer Table is used to create a list of all the I/O Units in your strategy you want this IO_Enabler_Chart to re-enable for you. The code can then loop through the list and act on each of many (or even just one) of the I/O Unit’s you’d like it to re-enable for you.
That’s my favorite use of pointers.
Anyone else?
-OptoMary
I use pointers on almost every project. The best example of pointer use is to control a large group of similar pieces of equipment such as a rock crusher operation. In this case I had multiple conveyors and crushers and shakers, etc., etc. I was able to incorporate all 70 pieces of logic into a chart which consisted of the logic for only one piece.
Additional differences or additions can also be added into this logic simply by using a condition looking for a specific set of indexes in the main logic tree to branch for these special cases.
I use mostly tag variables instead of tables for the variables because it is easier to troubleshoot and the controller is so fast it can easily move all the values to and from the registers and brains without using tables.
Anyway the strategy only consisted of one chart to control all 70 pieces. The real beauty of this design is that during the troubleshooting necessary for most of less than perfect programmers, fixing all 70 logic loops is done in one place only once!
I inherited a set of strategies for some legacy equipment. For some reason, they had a pointer for each IO point. The first chart started at Power Up assigned the pointers to the corresponding I/O point. Any reference to the IO point in the remaining strategies used the pointer instead of the actual IO point. I am not sure why they did that.
I did end up with a good use case for pointers and communication handles. We have some auxiliary I/O that we communicate to using serial channels. We also have device simulators for these auxiliary devices that we can communicate with over TCP/IP. We use a pointer to switch the communication channel from the serial to the TCP/IP channel when we run in simulation mode.
Communication handles:
Ch_device_Ser (defined as @deviceSerialPort:baud=2400,data=7,parity=e,stop=1,rts-cts=0)
Ch_device_TCP (defined as tcp:127.0.0.1:8092)
Pointer variable:
Ch_device (Initial value is Ch_device_Ser)
Code during Powerup:
if (SimulationModeUseTcpForDevice == 1) then
Ch_device = &Ch_device_TCP;
endif
