I have several groups set up to trigger on a “PC upload bit”. Only one of these groups handshakes with the PLC. I am having trouble with some of the groups not always triggering. They are set up to execute once at 1 sec update interval. My question is, do the groups only trigger for the 1 second update interval if they are set to only execute once? How does “execute once” determine how all the data is retrieved?
A little more on this. PLC values have been verified. I am actually moving the values to the upload register a second before the upload. The action_item “sometimes” only moves in the previous triggered value. I have just now set-up quality codes to track the data from kep. All other data in this group makes it ok. Any Ideas? Sometimes it is all good.
Hi, sorry for the late reply!
So, if you have multiple groups triggering off of that bit, and the bit is reset by any of the groups, there will be a race condition as to whether all groups have seen the value.
Fundamentally, the “execute once” option means only execute when the trigger is active, then not again until it first goes to an inactive state again. There is no interplay between the groups when it comes to this, so it’s relative to each one.
The best thing to do would probably be to set up separate triggers for each group. Short of that, it would probably be better to run your groups at a higher rate (like 250 ms), and then have your trigger reset based on a timer (several seconds, if possible) instead of as a response to the first group executing.
Let me know if I’ve misinterpreted your setup, though…
Regards,
The group in question is the one that resets the trigger. Ergo the dilema. I have got some quality codes back. They are all 192 even the ones that load the same last triggered value. Groups are 1 sec update, but set to execute once. How long does the trigger in the plc need to be active? Is there a rule for this?
Hi,
The way you have it set, the each group will run every 1 second. When it runs, the first thing it will do is evaluate where the trigger is active. If so, it will continue executing and do the rest of its work, otherwise it will break out.
Therefore, since the group only checks once a second, it’s important that the trigger stay on in the PLC for more than that. If the system is particularly bogged down, the group my not get to execute at exactly that second (though this case is pretty rare). However, if there are other groups that also depend on that trigger, they might run at different times, up to a second later (well, 999ms).
How long is your trigger staying on right now? For what it’s worth, since you are using the “execute once when active”, you can pretty safely set the groups watching the trigger to run at a faster rate, like 500ms or more. They do very little work when not trigger (although, that will increase the subscription rate on the items, so if you have a lot of items it could increase PLC comm a bit). If the groups are racing to see the value before the main group resets it, though, speeding it up won’t do anything except make this happen faster.
Regards,
One other question. I use the “handshake on success” feature to reset the upload logic. When FSQL sends this bit isn’t it saying that I got everything and I am done? Or is it different than that?
That is what it’s saying, for that group. If that is the only place it’s written to from FactorySQL, then yes, it should mean that the group has executed.
So are you saying the groups are looking for “trigger” based on the update rate? For example, lets say I have a group set for 5sec update rate. Lets say I have a trigger bit that comes on for 1sec somewhere in the middle of the five seconds. The group never triggers? Is that what you are saying?
In my case I have a group set for 1sec update rate. Lets say the trigger comes on during the check and the group executes. (Group set to only execute once.) If it takes longer to get the data than the remaining update rate, then the group stops (whether it has gotten all the data or not) and sets the done bit?
Yes, groups check the trigger at their update rate.
Here’s how the data flow works:
-The group takes all of it’s items and subscribes to the OPC server at a rate based on the update rate
-The OPC server sends updates asynchronously when values change. This means they come in at any time, but are supposed to be at the update rate.
-The group, independently, runs at its update rate. When evaluation starts, the group snapshots the current values, an operates on those.
Therefore the values will be whatever they are at the snapshot, including the trigger. So yes, running a group at 5 seconds for a trigger that’s only on for 1 second would really not work. This also means that it’s possible to have the trigger come in before any other values, meaning that the group will capture the old values if it runs at that time. In practice, though, this is uncommon, for two reasons: 1) OPC servers tend to send data together, and 2) By default, FactorySQL actually subscribes to the items at a faster rate than the group runs (actually 1/3 of the group rate), so that it is more likely the data will be present when the group executes.
Of course, even with that there’s room for error. That system is fine for historical snapshotting, but for important transactions that must have all values present, it’s not 100% safe. Instead, in those cases, it’s necessary to use polled reads. With polled reads, the trigger is subscribed and works in the same way. However, when the trigger is active, the other items are manually read from the OPC server (and in turn the device). It’s slower, but safer. To use polled reads you need to turn on “advanced options” from the Frontend Settings menu, and then enable it on the new “advanced” tab that shows up for groups.
Hope this helps,
Ok turned on “polled” and get the following error(s)
OPC Write did not return the expected results and,
Error writing handshake:Results from OPC:OPC_Failure
You can turn off the polling option and the handshake works great. What am I missing?
Eh, you may not be missing anything. What version of FactorySQL are you using? A bug was fixed in 4.2.11 that involved async writes (the default) with polled reads.
If you’re using 4.2.11, then it’s something different. If you’re previous to that version, you can either upgrade, or turn off asynchronous writing through Settings > Service Settings, “OPC Options”. Using synchronous writes isn’t a big deal- async is recommended by most OPC server vendors, but FactorySQL used synchronous for years before switching the default.
Regards,
Yea using 4.2.8. Corrected the issue and groups are handshaking. I will follow-up in a couple of days to report if the data problem is resolved.
As of today, no issues recorded. So polled reads are a success.
Thanks for your help.
Great. Yeah, it probably shouldn’t be relegated to an invisible tab, but our fear was that everybody would just click it for everything, since it seems to make sense. The subscription based model is more efficient and fine for most situations - however, these batch/transactions often need the explicit reads.