I have a transaction group that is setup with several OPC times. One of the items is a record number coming from the instrument. on the trigger tab of the transaction group i have set to execute the group when the record number value changes. when I turn the trigger on all the items say N/A. when i turn the trigger off the value pop into the opc items. the group is set to execute every 1 minutes and i have waited several minutes and no values every show up until i uncheck the trigger and save the project. If i set the group to evaluate on custom tag change for record number all the values come through except the record number. Any ideas on how i can get the values with the trigger enabled?
Your picture with the trigger turned on is displaying the “Execution Disabled” status at the top so I am not surprised to see no values. With the trigger on, any values that are a part of the trigger are read on every execution and it will not read the other values until the trigger is active.
In your third picture, it should be displaying the Record Number item. Are there any warnings or errors for the group? You can see those below the group’s items.
Also, check the options tab for the group. It behaves differently if you are using the Read mode instead of the Subscribe mode.
i just took the picture before the group started executing, but believe me i have waited long periods of time trying to see if data would show up. here is an updated picture.
also i do have the group set to read because the device does not seem to like subscribe mode.
i do not see any errors in the event tab.
Hi,
Just out of curiosity, when you have the “tags to watch” option selected, which tags are selected?
When using read mode, any tags used by the trigger (either the actual trigger, in this case “Record Number”, or the tags selected for the “on change” trigger) should be subscribed. Then, when the trigger is active, everything else is read.
Which OPC server/device are you pulling these from? You said that it doesn’t work in “subscribe” mode, maybe that’s the problem. As mentioned above, subscribe is still used for getting the trigger items while in read mode.
To test that theory, you can try the following:
- Create a new scan class in SQLTags, called “ReadMode” or something.
- Set its data mode to “read”.
- Bring your Record Number item into SQLTags, and set it to that scan class.
- Remove your current record number item from the group, and drag in the record number sqltag. You should notice the different icon for the sqltag in the group vs. a regular opc item.
- Try setting up the trigger as before.
The idea here is that the scan class will update its tags through reading. The group will “subscribe”, but only to the sqltag, not the opc item. This will avoid subscriptions completely on the group. If this works, you might choose to make all of your items sqltags, and use those in the group. Normally we advise people in the opposite direction, using opc items directly, but this could be a special case, if subscribing really can’t be used.
Hope this helps,
this is the device I called in about last week and it was determined that the Greybox OPC Server that the device runs does not work when ignition uses subscription mode. I have a scan class setup for read with the sql tags and i have the transaction group setup as read.
Your work around the subscription issue with the trigger seems to work just fine. do i need to change them all to sql tags or can i just have the one i am using as a trigger be a sql tag?
No, you don’t have to change them all, just any that might be used for the trigger. It’s likely that the problems with subscriptions are caused by dcom security, but if this works for you, then there probably isn’t much need to figure out the subscriptions. These triggered batch-style operations are often best done with “read” mode anyhow.
Regards,
would you be able to tell me from my log why the opc server loses connection and will not reconnect automatically? i had the trace level turned on for ComServerImp over the weekend. this seems to happen almost every night. when i come in i have to disable the OPC server and then enable it to reconnect. the last record to be written to the database was 12/17 3:59 AM and it looks like it lost connection at 4:15 AM
20121217-logs.bin.gz (518 KB)
That’s interesting, it looks like perhaps the server is being disconnected, and the error that is causing subscriptions to not work, which is avoided while running, is preventing reconnection. I’ll try to get that adjusted and send you an update later today or tomorrow.
Regards,
Okay, thank you.
Hi,
Try the attached module (you’re using 7.5, right?), which changes the way the subscription failure is handled. It should now never cause the server connection to fail, which I think is what was happening after the first disconnect. As for why it was getting disconnected once a day, I’m not sure, but we can look into that if necessary.
OpcCom-module7.5.6-beta1.modl (1.6 MB)
Regards,
yes we are running 7.5.4. i will give the module and try and let you know what happens.
thanks,
i tried your module but i received this error in the console.
What! Whoops, the trouble of renaming/uploading things manually. Here’s the correct one:
OpcCom-module-7.5.6-beta1.modl (1.6 MB)
Regards,
I just checked to see how the beta module is doing and the records are being inserted, but the quality code is 0. Also when i look in the designer the values are all N/A except the SQLTag.
That’s very strange… I’m not sure how it could have the correct values going to the table, but not to the display. Do all of the values seem correct in the db? It might just be your screen shot, but some rows seem to be missing at the end of the table.
Do you have anything in the group messages or console?
Regards,
yes, the screen shot does not show the last few rows. yesterday I went to the OPC server connection and disabled it and then enabled the connection and everything worked fine. now today at about 11:57 am the transaction group started inserting the rows, but with data quality 0 again. also instead of all the tags being N/A only a few are. attached is the log and the table of data.
table.xls (354 KB)
20121221-logs.bin.gz (525 KB)
Hi,
I’ve confirmed that “bad qualities” don’t (always?) get displayed correctly, at least when using read mode. So, if even one item was bad, you would get quality code 0 for the row, but wouldn’t see it in the group. I’m not sure how that might relate to never seeing a value, to the first case, where the display stayed “n/a”, since the values seem to update fine, even when the quality is bad.
I’ll keep playing around with it, and try to find the right combo of what might be going on.
Regards,