Reading the user manual, this isn’t conveyed at all - I'm only finding this out now after reading your post, and this is pretty important to know! (and that’s why I'm bothering telling you so! - Dr Suess reference for those with small humans 
)
Once I figured it out and went back to the documentation it makes sense now but at the time it didn't. What I understood was the gvi addressing reverted back to the legacy driver, so I was hesitant to use that (new is always better, right?) and instead was trying to figure out how to make it work with the newer syntax. Given the legacy driver had options for naming aliased points but was removed it was confusing how I could previously have a aliased pointed name AnalogIn14 be a static read in the old driver but not in the new driver.
As a suggested improvement it would be nice to have a modifier that lets us use the new syntax but set it to do a static read. Like changing the opc path from AnalogIn14 to g40.AnalogIn14 or s.AnalogIn14 or whatever makes sense.
Having 90% of my map be named points but then a few points having to be gvi addressing feels like a bit of a future confusing problem when the project is a few years old and someone has to come back to it.
Ignition tag names are where you get to use a name/identifier that makes sense to you and within the context of your project.
You should get used to the idea that an OPC UA NodeId (OPC Item Path) is effectively an opaque identifier. You will never have control over it - it's entirely up to the server you are connected to, and any rules about syntax/addressing, if there even are any, are implementation specific.
I see what you're saying but the Ignition driver is capable of having all the information from when it does an integrity poll since it knows the group and variant info already so it would make for better usability if it was an option to keep consistency.
I'm suggesting having a config flag of some sort that lets you select between events only, static only, and both static & events when creating the pathing. There are use cases when each of those are useful.
Edit: Thinking UI wise I guess what I'm asking for is on the device connections page can we have a more -> 'static reads' config page that just lets me add points to a list and then when the tag group executes it also does a static read of any points in that list in addition to requesting the class events that poll.
If it’s not enough to get the info across in one or two reads, then I'd say not. I think it needs some examples and a better description of how to use the 3 “modes”. Still reading it now, it’s confusing as nowhere (that I can see) does it actually mention how to address a dnp3 point without using GVI (coming from clearscada back in the day, GVI was the only way address dnp3 points so I figured it was the same in ignition)
Something as simple as: “These modes are accessed by…. “
So running into some time related issues and unsure if we can even proceed at this point.
What started down this path: The FB3000 doesn't provide any localized timezone, so all events and records are based on the current clock setting. Enabling time sync from Ignition forces the FB3000 into UTC time which is typical for the DNP3 protocol. Unfortunately that makes it awkward for the operators when they have to connect to the RTU because all the alarm and events show UTC time rather than local time but also when prompted to time synch, if they click sync to laptop it breaks my DNP3 communications.
If the RTU clock is to local time rather than UTC time I found the following:
- AnalogInput tag updates backfill to 8 hours ago
- The live tag value in designer & perspective does not update
- This is true for both configurations: AnalogInput14 or g30v5i14
- Even issuing a system.dnp.demandPoll does not properly update the tag to the current value. The only thing that will is disabling and re-enabling the device connection and even then it only updates one time.
Why it's an issue: The client wants to switch the FB3000 to use their local time which Emerson said is fine but it causes a lot of issues for Ignition to the point it's no longer usable. I'm not seeing real-time data update which isn't acceptable since the below wireshark captures show the data coming back across. Even doing static polling, which should be what is the value now, are rejected by the DNP3 driver as just 'Bad'.
I understand the DNP3 standard is to use UTC time however even if I do that it means my communications now rely on a procedural safeguard because when the operator connects to the RTU and is prompted with this, if they click sync to PC I lose all data to the site until the RTU is time is re-synced.
So when I need/suggest is the driver should have the following. Which I will need to contact Ignition support for at this point, unless this can get resolved we'll be abandoning using the DNP3 driver.
- Option to enable publishing uncertain values
- Option for a time-zone offset
Sounds like Emerson doesn't want to adhere to the standard. Which is "fine" for them. You should make a bigger stink about this.
Yeah, we are also going back to them to complain as well but ultimately I need to make the site work with the hardware provided so have to press both sides to flag the issue.
We ran into some other issues with the DNP3 driver that is a similar problem but outside this time sync. For example if I'm reading an AnalogIn.live and I go lift physical the wire, the RTU is set to fail to 0 which it does, and I see in wireshark, but Ignition never updates to zero. It flags the quality as bad_Outofservice and then refuses to update the value and instead holds last good value.
Seeing stuff like that is why I think it needs to have an option to publish uncertain values.
There's an option on Tag Providers to allow "backfill" data, might try this and see if it helps with the points updating when the timestamp is well in the past.
If you can't solve the timestamp issue, one thing you might be able to do as a workaround is establish an additional loopback connection to Ignition's OPC UA server that you use only for the DNP3 devices with bad clocks, and then set the Timestamp Source property to Ignition: OPC UA Connections | Ignition User Manual
2 Likes
That seems like it could work, though unfortunately the site is 8.1.48 and that's new for 8.3 Though perhaps this will be the incentive they need to do the update.
Will test in the lab and try to post an update.