Ignoring MODNET exceptions

Have you tried prefixing the modbus addresses with a capital 'G' (like G40005)? If you do that, the I/O server will send individual requests for each register instead of grouping them into blocks. No need for using MaxBits in that scenario.

If the exceptions still occur you might want to try setting [Modnet]FailOnBadData=0

It seems that the default values of [Modnet]NonCriticalExceptionMask and [Modnet]OnlineTestExceptionMaskare already set to block the exceptions for your case, however I have not found any documentation on these exception numbers other than the examples in the driver help.

Have you tried prefixing the modbus addresses with a capital 'G' (like G40005)? If you do that, the I/O server will send individual requests for each register instead of grouping them into blocks. No need for using MaxBits in that scenario.

If the exceptions still occur you might want to try setting [Modnet]FailOnBadData=0

It seems that the default values of [Modnet]NonCriticalExceptionMask and [Modnet]OnlineTestExceptionMaskare already set to block the exceptions for your case, however I have not found any documentation on these exception numbers other than the examples in the driver help.

The G prefix is new to me (despite using Citect since v3/4!). Does it do anything different from MaxBits=16? (The latter is useful as it applies to the whole device and can be associated with a device type in a standard .ini file.)

I've G-prefixed my addresses for testing (MaxBits=16 still set)

I've just tried FailOnBadData=0 and it makes no difference. (The exception mask parameters are removed.)

Looking at syslog I see:

Unit '10 BMS' Port TCP_110 is Online
Error: Unit offline READ 000c TCP_110 DEV_BMS 4G0031

Every time it tries to read 40031 it takes the device offline and I lose the data from all the other working tags.

For reference the relevant sections of the .ini are:

[MODNET.BMS]
InitType=3
InitUnitAddress=0
LongDataType=0
MaxBits=16

[MODNET]
FailOnBadData=0

Hi Mark,

The G-prefix is available since I the first time I used Citect (v5.40, not v3/4 though).
Not sure if there is a difference to using MaxBits, although being able to use it for individual registers as opposed to the whole device could be a benefit. Grouping multiple registers in a single request will speed up communication, so I would suggest prefixing only the troublesome addresses.

One thing that strikes me is your error line which is displaying '4G0031' as the register address.
I was expecting it to read 'G40031'. How did you configure this address in your Variable Tags?

For reasons best known to Citect, a tag configured as G40031 shows the address as 4G0031 in syslog. (Yes, I thought the same thing!)

Agreed that the G-prefix is useful where it only needs applying to certain tags. The problem I have is that any of the BMS tags might be removed by the site without me being told, and I have to ensure only that tag goes into error. So the need to read single register at a time applies to all the tags.

Still have no idea why the device is being taken offline though.

I just found a list of Modbus exceptions (they are part of the MODBUS standard) and after reading your initial message again I realized you want to prevent exception 11 from taking the IODevice offline.
Exception 11 stands for 'Gateway target device failed to respond' by the way.

My guess is that you need to adjust [Modnet]OnlineTestExceptionMask for this.

Default value for this parameter is 0xFFFFFFF9 which means all exceptions except #2 (mask 0x2) and #3 (mask 0x4). If you want to exclude exception #11 (mask 0x400) as well, the new value becomes 0xFFFFFBF9.

Hope this helps

Well the good news is that you and I both interpret the OnlineTestExceptionMask parameter, and calculate it, the same. And it's definitely the same value I had before because it was still commented out in the .ini file.

So you can guess where this is going: I just tested again and the same exception is resulting in the device going offline.

Oddly, I have also put a test tag in for an invalid address (40099), and that does not take the device offline. Instead, syslog tells me Citect is reporting "Address is out of range" rather than exception 11 - syslog doesn't report this as an exception but monitoring with WireShark confirms this is exception 2, which Citect is handling correctly. (It appears the BMS gives exception 2 for non-configured addresses, and 11 for configured addresses where the attached device is missing.)

For test purposes I even tried a mask of 0 but that was no different.

Support picked up on this thread and offered some suggestions. After some experimentation what worked was:

[MODNET]
TransactionExceptionMask = 0x80000000
OnlineTestExceptionMask = 0xFFFFFBF9

I understand the OnlineTest parameter, I'm not clear what the Transaction parameter is doing (other than make it work!).

I can also confirm that device group parameters works, so in my case

[MODNET.BMS]
TransactionExceptionMask = 0x80000000
OnlineTestExceptionMask = 0xFFFFFBF9

.. is fine.