No values from modbus when using the UDT system

Hello my friends. I'm encountering a problem when I setup modbus devices with a UDT.. It worked fine at first but now when I create a new instance of a device it just shows 'Bad' in the value fields.

I can force it to work by making a single OPC tag of a single register value in the tag browser and that somehow activates the corresponding value in the UTD.

When I look at the logs I just see a bunch of entries of illigal data request from that UDT tag.


The start address there do not match the ones in the UDT. they are all of by one. The configured address are 410, 14 and 200 and so on not 409, 13 and 199. But I think that might just be a quirk of the modbus module or the protocol itself. Because as I said I have created multiple of these UDTs before and had no problem.

I'm just wondering if anyone has encountered something simular and knows what is going on.

I'm kind of leaning towards the server hardware just being too slow at this point. We are scaling pretty quickly here and are in the thousands of values logged territory and growing.

This is what the performance page looks like.

Any pointers would be appreciated.

Off by 1 tells me 'zero based addressing should be set to 1 based addressing'

I have this working on other devices so should not be that. But I tried it anyway just to make sure and it did nothing for the frozen values on the UDT. I just notice that they are still just showing 'Bad'. Me forcing them with a single OPC tag creation just put a placeholder there instead of the error message but when you hover over the value it says 'Bad'. I'm kind of at a loss here, I have tried deleting the UDT and creating a new one. But so far no luck. So far I have 16 of this UDT running and this is the first one to brake so I have no clue what could be the cause. Might be time to get the Ignition guys on the phone and see if they can figure it out. :smiley:

Try turning the "Span Gaps" setting off.

1 Like

Dude hahahah. I can't believe I missed that. Thank you so much. You just saved me a lot of headache. Have a good day sir :smiley:

That's one of the default behaviors I'd probably change if I were starting over with the Modbus driver.

Another would be that addresses without a unit/slave ID are simply not valid.

Another might be forcing zero-based addressing, but there's soooo many one-based devices/manuals out there it probably doesn't make sense.

Yeah, but they pretty much always show the full legacy address. You have to tell people to cut off the prefix already--adjusting to the offsets on the wire isn't much of a step from there. I get no grief for enforcing zero-based addressing. (Though I do show the legacy address format in my OPC browse to highlight the difference.)

I like this, or since many times on Modbus, there's just a single slave device, what if there's an advanced parameter to change the default slave ID when not specified from 0 to anything else. Although this may lead to more confusion when sharing an address without a slave ID, it's one more question to have to ask vs just knowing it's 0.

Hmmm. This sounds like a good idea. And if you set it to -1, then the OPC Item Path will require a valid unit ID.

(My driver defaults to unit #1, not zero.)

1 Like

Yeah, the advanced setting is a pretty good idea.

For a fresh start, though, I'd prefer no settings that mean you can't look at an address and know exactly what it means without the additional context. So that means always zero-based, and always requiring the id.

How would this affect upgrades though? I typically try to always specify the slave ID, but not necessarily everyone has that uses the Modbus driver. I guess I think support would get a flood of calls/tickets due to "Modbus stopped working after upgrading to v8.x". But if you do it only for v8.3, it could be part of the upgrade notes stating that all modbus item paths now require a slave ID to be specified.

Edit: I guess this could be accomplished with a migration to using advanced settings where upgrades set it to 0, but new installations set to -1 like Phil mentioned to force an ID to be specified in the item path.

I'm musing about a theoretical fresh start here.

Just split it like the Rockwell drivers, ModbusLegacy, ModbusCorrect :stuck_out_tongue:
On upgrades you leave them on the ModbusLegacy, for new devices it uses ModbusCorrect

Or name it like ModbusThe80'sCalledAndWantTheirProtocolBack

1 Like

Modbus....The standard that isn't very standard.

2 Likes