We are having an issue with one install where occassionally recipes being sent to a PLC from Ignition ‘hang’, meaning when the customer presses the ‘Send To PLC’ button, nothing reaches the PLC. Usually a Gateway reboot resolves the issue.
There is a lot going on behind the scene when the ‘Send To PLC’ button is pressed. Database queries are invloved ensuring proper inventory in bins, using older incredients first etc… before the actual recipe is sent to the PLC.
The programmer I have working on this project refuses to acknowledge that his code may have something wrong. He insists its is network or windows issues causing problems.
I have taken it upon myself to review the code and get advanced training in order to get this problem resolved.
One thing I have noticed, which I think may be an issue ,is the the use of a PLC Boolean Tag being used as a one shot trigger. In the scripting of the pushbutton, one line of code sets the PLC Tag to 1. This Tag is then used elsewhere in code.
In the final transaction group that sends data to the PLC this one shot Tag is set to 0.
I think it would be better practice to use a DB Tag as a one shot than a realworld PLC tag.
Am I correct in this assumption?
Does the PLC tag used as a trigger get reset anywhere else than the transaction group?
The PLC register looks as if it is being used as a scratchpad for Ignition.
No PLC code references this tag.
You can switch is to a DB tag to get it out of the PLC. That probably won’t fix the issue. My guess is the group errors out. You should add two handshakes on the group: on success and failure. You can write the handshake to another DB tag, 1 if success and 2 if fail. That way if the group fails you will know because the tag will have a value of 2. If everything is working ok you will get a 1. If you don’t get a 1 or 2 the group stopped working. That is case that we need to know about. So make sure the tag starts at 0.
You might be on to something. When you write to an opc tag, the value very well might not have come around by the next time you read it. That is, if you do a read immediately after the write, it's very possible you'll see the old value.
Switching to a db tag, assuming you're using 7.3, would eliminate this possibility. OPC tags are updated according to their subscription rate/scan class, as were all tags prior to 7.3. However, now, static db tags set their values immediately.
The group might still be erroring out as Travis mentioned, but this is one more possible problem.
Regards,