I am moving my transaction groups from FactorySQL to Ignition manually. It appears the alerting works a little different. In FactorySQL we have alerts setup on the opc item inside the transaction group. In Ignition this does not seem possible. My question is should I setup an alert on the tag in the SQLtags section or should i create a triggered expression item with the same name as the opc tag and setup an alert on the expression tag?
I am trying to preserve the old alert table as much as possible because we use it for various things.
Also did the alert status table disappear with ignition?
Thank you,
Yes, the alert status table is not longer used. We now have a component called the alert status table that shows that information. If you read the upgrade guide:
files.inductiveautomation.com/gu … _Guide.pdf
it talks about the alerting differences. I would create the alerts on the SQLTags rather than on individual items in groups. It is easier to find and make changes to.
No, it definitely still is possible... when you edit an item, it has alert properties just like the tags do. Items that have alerts on them get a special little icon in the "properties" column of the display. What are you seeing that makes you think it's not possible? Did they not import correctly?
Regards,
I want to setup an alert on this item, but i do not see the alerting section on the edit group tag window.
when i try to upgrade my FactorySQL project in the ignition gateway i receive this error
also i am ok with just manually adding our transaction groups one by one. Since we are not going to be using kepware any more i do not think the backed up project will be much use because all the opc item addressing will be incorrect.
I believe that error indicates a problem with the .Net framework (which must be installed for the upgrade process). We recently saw a problem like that even with the framework installed, on a 64-bit machine. In that case, it was possible to run the “db-to-xml” upgrade portion manually, and then import the xml.
- Download the FSQL Upgrader Tool, and extract it.
- Run “ProjectConverter.exe fsqlproj.fdb output.xml” (with the correct file name, of course)
- Take the resulting “output.xml” and use that in the legacy upgrade screen instead of the “fdb” (I know the screen says it will only take “fsp” and “fdb”, but it will also take XML).
I’m mostly outlining this for other people who have this problem, since your right that in your case you’ll probably have just as much work to convert the addresses after your upgrade.
NOW, as for alerting: You are adding SQLTag references to groups, which is why you can’t define additional alerting on them. It is also possible to add direct references to OPC into groups, in which case you can then define scaling, alerting, etc.
The difference between SQLTags in groups and OPC items is described a little in the user manual Here, but in short the key thing to know is that with SQLTags, the tags are subscribed and evaluated according to their scan class, whereas opc items in groups are subscribed and evaluated according to the group. If you’re going to use the tags in status displays and the like (in other words, you’re going to make sqltags anyhow), you could do your alerting there. Otherwise, you could add the opc items to the group and alert on them in that way.
Hope this helps,
I have to use SQLTags because the PLC is a siemens and that is the only way to add the tag addresses into Ignition. Right?
I will just stick to using SQLTags and setting up the alerts on the SQLTags. This way everything is consistent throughout. Also it looks like the alerting table does not use the group_folder and group_name in the log table which would be the purpose for me keeping the alerting in the group.
No, you can create OPC items manually or through browsing the PLC. You would go through the same process as creating SQLTags. You want to use OPC items in groups since they can be subscribed to at the rate of the group not the scan class rate for SQLTags. You can then either configure the alerts on the OPC items in the groups or SQLTags. I think you should create the alarms on the SQLTags.
I am trying to add my item as on OPC item instead of a SQLTag item, but cannot seem to get a value to come across. the database table shows nulls being written into the database columns. The SQLTag with the same exact address is showing the current value just fine. What am I missing?
Did you ever get this figured out? I somehow missed with this message was first posted… was it just the problem of subscriptions taking a while to get the first value (that is, related to your other question about prevent null values in the db)?
Regards,
yes it seems to be related to this post http://www.inductiveautomation.com/forum/viewtopic.php?f=70&t=6801
the values take a few transaction group cycles before they show up.
Right, ok. We still haven’t been able to successfully replicate the problem reliably, but there’s something there- I saw it once or twice, but couldn’t track it down. I’m doing a lot of redundancy testing right now, so I’ll keep looking.
Regards,
hmm you cannot reliably reproduce the issue. I have tried creating groups with opc items (not sql tags) from both a siemens plc and a Allen Bradley PLC with the issue happening every time.
all i have to do is create a transaction group with an update rate of 5 minutes. add some opc items and then start the group. the tags will just say waiting in the value column for 5 to 15 minutes.
If i allow the group to stay logging for a duration of time and then come back and disable and re-enable the group the values will take another 5-15 minutes to populate.
I’ve been working with Kevin on this, and it seems like it might just be an unfortunate timing issue. It goes like this: you subscribe to the items, OPC should send a value immediately, and it does- with bad quality, because they haven’t come in from the driver yet. Then, you don’t get your next update for your subscription rate. However, unfortunately, the subscription is offset slightly behind the group, so the group executes after 5 min, using the old values, and the new values come in shortly after. Thus, you don’t see it for 2 cycles.
On the “Options” tab of the group you can override the OPC subscription rate. Try setting this to a lower number, like 1 minute. Does that seem to improve things? (On a side note, it’s worth noting that FactorySQL, by default, subscribed to OPC at 1/3 the group rate, mainly for this reason).
Regards,
yes, over riding the subscription rate seems to make things better so I do not have to wait more than one transaction group cycle.
In my situation I still could potentially have a gap of missing data for ~10 minutes if the service goes down right before the transaction group executes. Then when the backup comes on line the subscription has not populated with a value by the time the transaction group first executes causing the backup transaction group to wait another 5 minutes.
Making a transaction group not start it’s execution rate cycle until there were values in the OPC item may be a solution. If accommodating this feature conflicts with how other people are using the transaction group I can live with setting the override rate on our groups that have long update rates.
