I have tried two different ways to handle reading and writing data records to/from a compactlogix plc. On both the client event tag change script, and the triggered transaction I cannot get reliable increments through my data. Here is what I have tried:
Transaction:
I have a data structure in the PLC that is basically a record that I would like to store in the datatable. I have an array of 100 of these structured records that the PLC moves one by one into a single structured register for Ignition to grab and store. The PLC sets an integer to the value of 2 to trigger the transaction. The first transaction operates successfully after which the trigger settings set the same integer to 0 via the successful handshake setting on the trigger folder. The PLC moves the next record into the data location and sets the trigger integer back to 2; however, the transaction does not trigger. My guess is that the move and change of trigger value is too fast in the PLC for the transaction to recognize a change. How can I get this to work? I can get the data if I manually disable and enable the transaction and uncheck the prevent trigger on start.
Event:
I have tried using an event to dump data to the PLC. I am also using an integer to trigger this event. I have a script that sends the first record to the PLC and sets the trigger integer to 1 after which the PLC internally stores the data to the correct location. The PLC then resets the trigger to 0. An client tag change script is set to look for this integer to go to 0 and perform the dump of the next record. Unfortunately Ignition does not always recognize the change of the tag and the tag change script is only run sporadically. If I edit and save the the trigger tag in Ignition, I can nudge the script into running again after which it usually will hang again a few records later. Any ideas on this?
Thanks in advance,
Russell
In both cases it sounds like your tag change speeds are what’s going wrong. You could speed up the execution times or move to a polling solution to guarantee you don’t hang.
Transaction:
- You could set the group Update Rate to something faster. This way it will check for the tag change more often and not miss the trigger going active again immediately.
- Is your group trigger set to only run once when the trigger is active? If so, you could try removing this since the group is resetting the trigger every time.
Event:
- You can change the scan class of the trigger item to a much faster speed in order to catch the trigger reset.
- You could move the script from a Tag Change event to a Timer event and add a line at the beginning to test the trigger tag’s value. This way it will run as many times in a row as you need.
I made changes to my transaction trigger a couple days ago and it seems to have eliminated the problem. I still need to test more to make sure it is solid. I was resetting my trigger integer using the handshake ability and changed to checking the reset trigger checkbox. I find it odd that my problem could be fixed by this, but I will take it if it works.
I have tested my event trigger with triggers as low as 10ms which I doubt can be achieved as a realistic update. It works better but still eventually hangs. I may go to the polling method you mention, but I would like to understand better why the tag change event is not working. Seems to me there might be a problem there. My understanding is that values are written to the PLC immediately and retrieved according to the scan time. I would think that the tag change event would work no matter what the scan rate is. When the script writes a value to the tag, I would expect the system to recognize this as a tag value change. When the tag is scanned according to the scan time whether it is 10 seconds or 10ms, I would expect the system to recognize this another tag change (if the value is different). Even thought the PLC is immediately changing the value of the trigger tag, the tag database should not see that change until a new scan occurs. It is almost like Ignition is not recognizing the write performed by the script. Can you help me understand better how the tag change event works?
You're exactly right- it doesn't. All writes in the system are made directly to the OPC server- and then the tags get updated when the value is returned from the PLC. This is best for many parts of the system, though can be debated for transaction groups- maybe the group should allow the trigger to run again the next time. Really though, I think when you look at what would happen, the result is basically the same as unchecking the "only execute once while trigger is active" box. In fact, I would probably recommend adding the the array pointer as a tag, and then unchecking that box. Once in a while you might get multiple entries for a particular row, but it won't be a big deal, because you can filter it by the row id.
Another option is instead of triggering on a "on/off" value, use the array pointer instead, and trigger on change. Write to a handshake to indicate success, which moves the pointer foward.
You can't think of the execution of the group as a "scan" of the PLC. There's so much in between, you really have to thing of it in terms of the subscription system. By setting the group rate, you're requesting how often you'd like to get updates about the trigger. The driver might query the PLC multiple times, or maybe not at all if it's behind due to load, network traffic, etc. 10ms really isn't a reasonable rate- 250ms or so might be a better place to aim, depending on how much other work the driver is doing.
Hope this helps,
Colby,
Thanks for the info on how the system updates data to/from the PLC. That explains to me why my event was not working properly. I think you misunderstood part of my response since it was in two parts. The transaction for some reason seems to work with the reset trigger selected instead of the handshake. As a separate but related part of my initial question, I had problems with an tag change event controlling some writes to the PLC. I think you guys need to really review how the tag change event processes events. In my case the PLC is updating the trigger tag so fast that it will rarely show up as a change to Ignition. I can work out a different way to do what I need to do now that I understand how things work; however, this really limits the capability of the tag change event if tag changes on the Ignition side are not recognized. I also agree that this can pose a problem on the transaction side in certain circumstances.