Hello for all!
In a last time has very bad problem…
Our company has some projects, in this projects we using Danfoss MCX PLC’s. In one project this is ~35 PLC’s, in another ~50 and one more ~100.
Each PLC has more than 100 tags.
Also, we have devices, which converting Modbus RTU to Modbus TCP. This device is ADFWeb HD67507M.
Proportion… 1 ADFWeb for 5-10 PLC’s.
Next, this ADFWeb’s i am adding to Ignition OPC-UA Server Devices using Modbus TCP driver. Than i am added my tags to Ignition in different projects but has same problem:
Tags goes bad quality for some time than goes to good quality for some time. This process repeating again and again and again…
Devices, which added in the Ignition OPC-UA Server Devices, goes connected/disconnected.
Early we using KEPWare server and all was perfect. But using KEPWare - bad variant…
P.S. I am trying to change all of the options in the “Edit” menu of Modbus TCP device. No result.
P.P.S. Also trying to change Scan classes but still have same result.
Anybody, help!
When wrote to support - they or do not understending me, or don’t know how to fix it…
On the console page, levels tab, search for a logger called DriverVariableNode and turn that to DEBUG level too.
It sounds like you’re probably requesting data too fast, and the devices are either responding slowly (causing the tags quality to go bad occasionally) or requests are timing out, which would cause disconnect/reconnect cycles.
On the console page, levels tab, search for a logger called DriverVariableNode and turn that to DEBUG level too.
It sounds like you’re probably requesting data too fast, and the devices are either responding slowly (causing the tags quality to go bad occasionally) or requests are timing out, which would cause disconnect/reconnect cycles.[/quote]
Here is the logs from 1 ADFWeb in debug. [attachment=1]logs.bin.gz[/attachment]
Here is the log called DriverVariableNode. [attachment=0]logs (1).bin.gz[/attachment]
Yeah, you’re pretty much just dealing with an unreliable/unresponsive device. There’s nothing wrong with the Ignition driver itself.
The gateway you’re communicating with frequently responds with ExceptionCode: 0x0B (GatewayTargetDeviceFailToRespond) or simply fails to respond at all. Three timed out responses in a row causes the driver to reconnect, which explains the disconnect/connect you see. When it’s not being disconnected/connected, your tags will generally go stale/bad quality since they’re not being updated consistently.
There’s an option to disable the reconnect on consecutive timeouts behavior, but you’ll still probably see intermittent bad quality if the gateway doesn’t respond with good data frequently enough.
[quote=“Kevin.Herron”]Yeah, you’re pretty much just dealing with an unreliable/unresponsive device. There’s nothing wrong with the Ignition driver itself.
The gateway you’re communicating with frequently responds with ExceptionCode: 0x0B (GatewayTargetDeviceFailToRespond) or simply fails to respond at all. Three timed out responses in a row causes the driver to reconnect, which explains the disconnect/connect you see. When it’s not being disconnected/connected, your tags will generally go stale/bad quality since they’re not being updated consistently.
There’s an option to disable the reconnect on consecutive timeouts behavior, but you’ll still probably see intermittent bad quality if the gateway doesn’t respond with good data frequently enough.[/quote]
On this logs i am disable the “Reconnect After Consecutive Timeouts” and some interesting fact that the Kepware getting all of the tags perfectly. How it can be?
[quote=“Serhii”][quote=“Kevin.Herron”]Yeah, you’re pretty much just dealing with an unreliable/unresponsive device. There’s nothing wrong with the Ignition driver itself.
The gateway you’re communicating with frequently responds with ExceptionCode: 0x0B (GatewayTargetDeviceFailToRespond) or simply fails to respond at all. Three timed out responses in a row causes the driver to reconnect, which explains the disconnect/connect you see. When it’s not being disconnected/connected, your tags will generally go stale/bad quality since they’re not being updated consistently.
There’s an option to disable the reconnect on consecutive timeouts behavior, but you’ll still probably see intermittent bad quality if the gateway doesn’t respond with good data frequently enough.[/quote]
On this logs i am disable the “Reconnect After Consecutive Timeouts” and some interesting fact that the Kepware getting all of the tags perfectly. How it can be?[/quote]
Kepware behaves very differently in the presence of an inconsistent TCP connection and/or tags that aren’t updating at the rate you’ve requested they be updated at.
Ignition’s OPC-UA server is much more strict and sets bad quality on tags when any of these situations is encountered.
We’re having the same issue here over Modbus TCP. Continuous connect/disconnection issues. Log file is attached for reference (we’re just getting started attempting to get a feel for the product prior to purchase).
[quote=“GeoffStoltz”]We’re having the same issue here over Modbus TCP. Continuous connect/disconnection issues. Log file is attached for reference (we’re just getting started attempting to get a feel for the product prior to purchase).
Thanks,
Geoff[/quote]
Geoff, you probably just need to get one or more tags set up. Most Modbus devices will close the socket connection after 10-15 seconds of inactivity. If you’re not subscribed to anything there will be no activity and the driver will cycle (connect, 10-15 seconds, disconnect).
That’s what we’re attempting but we’re missing the link apparently between the Modbus register and the OPC tag/name, or at least where to establish that connection. We thought it was a result of the disconnect/reconnect, but perhaps not. We go into designer and point the OPC server at the device, but there’s nothing listed beyond Diagnostics. Apologies for the rather basic question, again, we’re trying to set up an internal demo as we’ve looked at Wonderware, but would prefer Inductive for scalability/cost reasons as it’s a new installation.
That’s what we’re attempting but we’re missing the link apparently between the Modbus register and the OPC tag/name, or at least where to establish that connection. We thought it was a result of the disconnect/reconnect, but perhaps not. We go into designer and point the OPC server at the device, but there’s nothing listed beyond Diagnostics. Apologies for the rather basic question, again, we’re trying to set up an internal demo as we’ve looked at Wonderware, but would prefer Inductive for scalability/cost reasons as it’s a new installation.
Thanks,
Geoff[/quote]
There’s no such thing as browsing in the Modbus protocol. You have to manually create SQLTags for every register you want to address. There’s a section in the user manual that describes the syntax to use when specifying the OPC Item Path of the SQLTag.
I am having a similar problem as described here. Using 7.6.6 and the Modbus tcp driver.
I am connecting to modbus rtu devices via a delta ethernet communication converter.
The tag updates seems intermittent, i.e. the quality alternates between “unknown” and good. In my trends i see a lot of gaps. The device connection seems to remain “connected” so far.
I have also tried playing with my scan class settings and the device timeout settings and have had no success.
If this cant be solved, Is there at least a way to prevent the data from appearing with so many gaps? I.e. somehow make the opc-ua server more tolerant to long response times?
I think i know why this issue occure.
Some devices has programs with non-existent holding registers. Like HR1, HR2, HR3, HR5 etc.
When Ignition trying to ask package with 5 holding registers it trying also to ask HR4, which non-existent. And because of this modbus devices goes to timeout. And in this timeout all tags goes to bad quality. Thats too bad when i using frequency converters with default and non-changed addresses of registers. Then i must to create in Gateway modbus device for every converter and uncheck Span Gaps.
This method goes to slow asking of registers.
IA, fix this, please. Imposible to work with some types of devices.
Yes, Serhii is correct about the “Span Gaps” option.
Here is an explanation from the developer:
"
Ignition’s Modbus driver attempts to optimize requests for data in such a way that the overall number of requests that need to be sent to the device is minimized.
This means that, for example, if tags for HR1 and HR20 are created in Ignition, the driver will send a single Read Multiple Registers request requesting all of the data for HR1 through HR20, even though the data in between will simply be discarded.
With most devices this causes no problems. However, some devices are very finicky about which data you read, and if you attempt to read data from registers that don’t exist or don’t have data in that device they will respond with an error.
Turning this option off will prevent the driver from attempting to minimize the number of requests at the expense of possibly requesting data it does not need.
"
Since this is something that depends on the device’s behavior, I am not sure anything can be done on the driver’s end, but you are welcome to put in a request here: ideas.inductiveautomation.com/fo … -and-ideas