I have been experimenting with a way to make a heartbeat bit exchange from a PLC to FSQL and back out to the PLC to verify communications. I have a two second timer in the PLC which flashes a bit on and off at two second intervals that I can’t seem to loop through FSQL back to the PLC to read and set an alarm. I am afraid that I’m not seeing this clearly but I can’t get the signal back out to write to the PLC. I have tried making action items in various ways with no luck. Is there someone who can point me in the right direction through this seemingly simple task? I want to use this bit to prove that I have communications with FSQL and the SQL database for validation. Is there another way to do this without having FPMI running?
I can think of two, but not as a heartbeat, per se, since timing becomes interesting once it leaves the PLC.
use the bit as a trigger, use fsql to reset the trigger.
use bit as a trigger, use fsql to set a handshake bit back to PLC, rinse, repeat.
(I know I said two, but this just came to me… ) increment an integer, use the integer as a trigger, use an action item to write it to another tag back to the PLC. In the PLC, when both integers are equal, you can increment the first one to trigger again. Actually, this is the one I’d recommend. If you need to alarm at the PLC end, you only need to watch for how long the integers are not equal, and it gives a good visual on whether things are working or not.
I usually have a timer on the plc which is always running, and just have FSQL keep setting the timer’s reset bit. The group I am using runs every minute and uses the success handshake to set the timer reset bit. Then if the timer ever gets done you know that something is amiss.
I usually set up FSQL to update a row in a table created specifically for the heartbeat - one row, two columns (index + time stamp) - to make sure the whole chain from PLC to database is working properly. The handshake back from FSQL resets the trigger, which tells the PLC to trigger again after a short delay. If I see the trigger bit on for more than 2-3 seconds the PLC knows something stopped working.
Thanks to everyone for the input, all were great ideas. I finally got what I wanted by making a counter in the PLC that counts up and resets. The counter accumulated value is written into the SQL database and copied from one column into another column called feedback which is written back to the PLC. I take the difference between the two numbers and if it gets too high I signal a communications alarm. I feel good that I can confirm communications from the PLC—>FSQL—>SQL server—>FSQL and back to the PLC now.
I am setting up an EXSi Bare-Metal Hypervisor in my office to substantially increase my ability to test different server/client configurations. I think I will test the other methods mentioned here when I have some time to play.
) increment an integer, use the integer as a trigger, use an action item to write it to another tag back to the PLC. In the PLC, when both integers are equal, you can increment the first one to trigger again. Actually, this is the one I’d recommend. If you need to alarm at the PLC end, you only need to watch for how long the integers are not equal, and it gives a good visual on whether things are working or not.