Advanced Modbus driver sending Modbus/TCP messages with Transaction Identifier '0' causes connection problem

[acj47]

It appears the advanced modbus driver for ClearSCADA / GeoSCADA Expert uses a Modbus TCP ‘transaction identifier’ value ‘0’ until it gets a valid response from the outstation, at which point it starts incrementing the transaction identifier value. However, my outstation will not respond to transaction identifier ‘0’ and must have a non-zero identifier. 

Both Modbus Poll and Modscan software have no issues communicating to the outstation as soon as the transaction identifier is greater than zero. 

Please advise how I can adjust ClearSCADA / GeoSCADA Expert settings to always have a non-zero transaction identifier. 

[AndrewScott]

This appears to be a fault with the "Sungrow LC" outstation - it should be replying to requests with a transaction identifier of zero. There is nothing special about transaction identifier zero in the Modbus/TCP standard, so there is no reason for it not to reply.

There are no settings to control the transaction identifiers in Geo SCADA. It starts at zero and increments after receiving a valid reply (with correct identifier) or following a failed request (after all retries have failed). Eventually it will rollover from 65535 back to zero.

How many Comms Retires have you specified on the channel? See Defining Scan Parameter Settings for a Channel  in the help.

What does the driver log files show when trying to establish comms with this outstation?

[acj47]

Hi Andrew, I have set the ‘comms retries’ to a large value (15) and clearscada simply resends transaction identifier ‘0’ and the outstation does not respond.

I understand there are no settings and the root issue lies with the outstation, however, this is a very critical system so I have to ask, is there any way a developer could make an adjustment to the modbus driver to send Transaction identifier value ’1’ instead of ‘0’?

Or, alternatively, start with value ‘0’, but increment the transaction identifier by ‘1’ each attempt while it is trying to establish comms to the device, instead of holding at ‘0’ until it stops attempting to communicate? (This is how the Modbus Poll software tools works)

I understand this would not be a tested and validated driver for ClearScada but I would be willing to give it a chance to see if I can get communication to this device while I am on site.

Please let me know what is possible, thank you.

[acj47]

Hi Andrew, I looked at your response again. Are you saying that it will increment to value ‘1’ after a failed request?

[AndrewScott]

Yes, once the 15 retires have all failed and therefore the whole request has failed, the next request should use a transaction identifier of one.

[acj47]

Hi Andrew,

I have attached a log file as you requested in the original response. 

I just let it run for 5+ minutes (Comms Retries set to '3' now), I never saw it use a transaction identifier other than zero, even in the retries after the Reestablishment Interval (set to 10 sec).  Can you please advise if it's working correctly, because if it were to use '1' after the first failed attempt, I would be able to get comms to the outstation. WireShark log file and image with transaction identifier messages from ClearSCADA attached. 

Thank you! 

[AndrewScott]

From the driver log I can see what is happening. The first request is a 'Start MDRP Comms' request which is a special case. This type of request doesn't normally fail (and therefore doesn't increment the transaction identifier on failure), as it is always retried forever (using the Reestablishment Interval after the initial Comms Retries have all failed).

I therefore can't see any workaround for this issue.

I would suggest contacting Sungrow to see if they can fix their outstation's firmware so it replies to requests with transaction identifier zero.

Alternatively, contact Schneider customer support and request a change to the Advanced Modbus driver in a future monthly release of Geo SCADA Expert.

[acj47]

Hi Andrew,

Thank you. A few questions: 

1) Why does the driver decide to use MDRP instead of 'normal' comms? 

2) How can I configure the driver to not use MDRP? 

Thanks! 

[AndrewScott]

MDRP is a contraction of "multi-drop" which is an old term which refers to connecting several devices to a single communications channel.

In Geo SCADA drivers it just refers to direct serial or IP comms. This is the only type of comms supported by standard Modbus. The only other type of comms is PSTN (dial-up using modems).

[acj47]

Hi Andrew,

OK so if I'm understanding correctly: 

- the Advanced Modbus driver in ClearSCADA can only use MDRP? 

- so that would mean that the Advanced Modbus driver will never increment the transaction identifier to '1' after the first attempt failed, because MDRP makes it stay at zero? 

[AndrewScott]

The 'Start MDRP Comms' request is always the very first request for an outstation in this driver (and most others). If it fails it won't increment the transaction identifier and therefore all retries will also have a transaction identifier of zero.

The name of this request dates back to the 1990's hence the use of old terminology.

[geoffpatton]

@acj47 You mentioned that this is critical. A resolution might take a while to be implemented if one is done at all by either Sungrow or Schneider.

You could try setting up NodeRed on the server or another computer and see if one of the Modbus nodes can retrieve the data. If it successfully retrieves the data you can also setup NodeRed to be a Modbus slave which Geo SCADA can poll.

[acj47]

Hi Andrew,

Thanks for the explanation. I guess my final question is this: is the Advanced Modbus driver supposed to increment the transaction identifier to '1' after a failed response, or will it always stay at '0' ? 

If the answer is stay at '0' , what would the timeline be to get an update in an upcoming release to allow it either to start at '1' , or increment to '1' after a failed response? 

Thank you. 

[AndrewScott]

I'm unsure whether the driver not incrementing the transaction identifier after a failed 'Start MDRP Comms' request should be considered a fault. As its just going to keep retrying the request forever it doesn't really need to change the transaction identifier, as retries all have the same identifier. For other types of request the identifier is incremented after the final attempt has failed.

[acj47]

Hi Andrew, 

As much as I would like to get Sungrow to fix their issue, I don't think it is very likely. And due to the fact that other tools (Modbus Poll and Modscan software) increment the transaction identifier (instead of resending '0'), Sungrow seems convinced that the issue lies with Schneider (even though I agree with you that they should respond to '0'). 

Can you please please see if its possible to add an update to the Advanced Modbus Driver to allow the transaction identifier to increment when attempting to establish comms with the outstation? 

Thank you. 

[Felchap1205]

Hi everybody, 

I work with Acj47 on this project and wanted to know if you could help us with some questions we had.

From Sungrow's documentation they say their modbus solution is built to be compatible with the GB/T 19582-2008 standard. Does Schneider's clear scada officially support this standard? If so, is 0 a valid transaction identifier within that standard or is that topic not covered?

Thanks for your support!

[AndrewScott]

Geo SCADA conforms to the official Modbus/TCP standard:

https://www.modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf 

All transaction identifiers are valid, including zero, in this standard. Transaction identifiers are described in sections "3.1.3 MBAP Header description" (page 5), "4.4.1.2 Build a MODBUS Request" (page 23) and "4.4.1.3 Process MODBUS Confirmation" (page 24).

GB/T 19582-2008 is a Chinese national standard. There is limited information online about it (just an overview) and its unclear if this deviates from the official Modbus/TCP standard:

https://www.chinesestandard.net/PDF/English.aspx/GBT19582.3-2008