I recently upgraded a gateway from 8.0.4 to 8.0.12 and a custom module I made that extends the AbstractDriverModuleHook class broke. What I mean by that is it no longer polls the items under the device instance in the gateway. All items, probably around 100 of them, have bad tag quality.
Can someone tell me if something has changed in the way this class is implemented?
Thanks,
Brandon
I assume you mean your driver extends AbstractDriver. Nothing has really changed though, so you’ll have to find some errors or add some logging to get more information about what’s going on here.
Thanks for the response. I’m having trouble understanding what is different then. Yes it also extends abstract driver. The only variable that has changed is going from version 8.0.4 to 8.0.12.
Does this statement apply to my module?
No, it hasn’t happened yet and for the most part doesn’t apply to anything using the old Driver/AbstractDriver APIs. They will manifest as compilation errors when it happens, so it won’t be very surprising.
Speaking of compilation errors… have you tried updating the version of the Ignition SDK in your dependencies to 8.0.12 and making sure it still compiles?
No I have not. Are you saying that every time I update the gateway version I have to check the dependencies on my module project? I did not have to do this in version 7.9.x.
Not every time, but the API provided by the OPC UA module is not stable right now.
Understood. I just updated my dependency and will let you know what I find. Thanks for the help!
EDIT:
The build was successful. Do you think I need to update my module with this new build?
If you didn’t make any changes there’s no reason to update it. I was only concerned that maybe some API changed and your module wasn’t working because of some runtime error, but that doesn’t seem to be the case.
You just need to start troubleshooting now.
Alright. I will look into it.
Just for posterity. The problem was fixed by right-clicking on one of the tags and selected restart tag. Then all of the tags came back with good quality.
UPDATE:
This is continuing to be an issue. I can restart a tag and get them to come back but this is not a valid solution. The diagnostics says Unknown_InitialValue.
@Kevin.Herron Does the AbstractDriver still support a Direct Tag Group? I am using that instead of the subscribed model because I could not get that to work reliably when I made the driver back in 7.9
Do you know what exactly Unknown_InitialValue means?
That’s just the starting quality for any Ignition tag. If your driver isn’t ever sending a new value it would stay at that quality.
I think that is the problem. My driver only sends new values if the tag asks for it. So if a tag was set on a direct polling group, will it send a new request after seeing that initial quality tag?
EDIT:
This is what the diagnostics says for a tag that is not working.
When you create an OPC tag the driver sees it as new subscription item being added. If you’re using AbstractDriver the bookkeeping is handled for you and ultimately your implementation of createSubscribeRequest or more likely createReadRequest is called and that Request object you returned is repeatedly executed at the subscription rate.
It’s up to your Request implementation to do something during the execution that gets and updates the values for the ReadItems received in the create call.
All those diagnostics you’re looking at mean is that you created a tag and your driver never sent a value.
Is there an updated example of the AbstractTagDriver so I can compare it to my code?
I feel like I am 99% there just think something is missing to cover this edge case that is happening.
Thanks
The latest example is from the ignition-7.9 branch of the examples repo: ignition-sdk-examples/AbstractTagDriverExample at ignition-7.9 · inductiveautomation/ignition-sdk-examples · GitHub
Here’s a version I just updated real quick for Ignition 8 and it still works. AbstractTagDriverExample.zip (19.7 KB)
At no point in this entire exchange did you mention you were using AbstractTagDriver until now. That probably wasted a lot of both our time.
Thank you for the help Kevin. I apologize for not being precise.
Hey @Kevin.Herron.
Just wanted to circle back on this. My driver is working, but it will not work on when failing over to a backup of a redundant pair. I am concerned that since the old AbstractTagDriver is deprecated that these issues may never be fixed. Can you please give me some advice on how I should move forward?
Should I rewrite this in the new OPC-UA Device model?
Thanks.
What doesn’t work about it on failover?
AbstractTagDriver has never had any redundancy-specific behavior. There’s not really anything to have changed or stopped working in that regard.