Modbus Scanner help

[Brian123]

I'm setting up a device in the Modbus Scanner, and I'm running into a problem I can't figure out.  My device has a register (13 or 40013) that is a 16-bit register of packed bits.  I have a UDT that I'm trying to write the register into, but I can't select the register I'm wanting, it doesn't show up in the popup list.  My memory layout is attached (I know I'm referring to the same register twice, I thought it might be the way to do this...)

Can the modbus scanner handle packed bits like this?

Thanks,
Brian

[BobO]

Sure. Any chance you marked it as read-only in the struct definition?

[Brian123]

Yep, they are!  I was just starting to notice that myself 

And now I'm starting to wonder about the thinking behind read-only.  I was thinking about it as though the ladder wouldn't be able to write to it, but the Modbus scanner could populate it.  Looks like my mental model isn't accurate, oops!

In the first Modbus scanner instruction pair, I was able to write to the root of the struct, and it took that.  It's dumping values into read-only memory in bulk just fine, so somehow I had it in my head that it was possible.  Maybe I'll just make the first element of my next bulk dump read-write and call it good at that

[BobO]

And now I'm starting to wonder about the thinking behind read-only.  I was thinking about it as though the ladder wouldn't be able to write to it, but the Modbus scanner could populate it.  Looks like my mental model isn't accurate, oops!

And ideally it should work that way. The truth is that although DmD can know the difference between a UDT and other structures, it wasn't as straightforward to exclude read-only from one and not the other. There are a number of system structures that *really* need to stay read-only for system stability, so it ended up the way it is. We will take another look at it and see if we can find an easy-ish way to make that work.

[Brian123]

It makes sense that there's more to it than it seems.

Are there similar reasons for limiting the MSREGRD to 16 holding registers and not allowing a Raw Copy into a UDT?  I can do both these things in the scanner.  The 16 register limit isn't as big a problem as the can't raw copy to a UDT.  I have some fault history registers (60 total, some 16 bit, some 32 bit) that I'd like to update periodically (on power up, when a new fault occurs, on return from comm loss, etc).  I can grab individual registers and do single field conversion and put that into a UDT element, but that seems tedious. 

I'll probably just have the scanner keep them updated constantly, but they don't really need to be.  I'm sure there's a slight hit to update time on the more important registers, but there's not a lot that I'm getting out of it total, so I think it will be workable.  If not, I can always do it the tedious way

[BobO]

It makes sense that there's more to it than it seems.

Are there similar reasons for limiting the MSREGRD to 16 holding registers and not allowing a Raw Copy into a UDT?  I can do both these things in the scanner.  The 16 register limit isn't as big a problem as the can't raw copy to a UDT.  I have some fault history registers (60 total, some 16 bit, some 32 bit) that I'd like to update periodically (on power up, when a new fault occurs, on return from comm loss, etc).  I can grab individual registers and do single field conversion and put that into a UDT element, but that seems tedious. 

I'll probably just have the scanner keep them updated constantly, but they don't really need to be.  I'm sure there's a slight hit to update time on the more important registers, but there's not a lot that I'm getting out of it total, so I think it will be workable.  If not, I can always do it the tedious way

I'm actually not sure why we are disallowing that. I'll check, but other than UI/editor/complexity considerations, I can't think of a PLC side limitation.

[Brian123]

I figured it was to try to keep people from doing raw copies into UDT structures and potentially trampling data in non-obvious ways.  Bulk raw data copies require detailed knowledge of the memory layouts of the UDT and the data coming back from the Modbus request.

It just seemed odd to me to allow it in the scanner, but not in the MSREGRD instruction.

[BobO]

I figured it was to try to keep people from doing raw copies into UDT structures and potentially trampling data in non-obvious ways.  Bulk raw data copies require detailed knowledge of the memory layouts of the UDT and the data coming back from the Modbus request.

It just seemed odd to me to allow it in the scanner, but not in the MSREGRD instruction.

And that is definitely a consideration and has traditionally been the justification for preventing some things in the past. We relaxed that a bit in the scanner, because we knew folks would want to copy block data into a UDT. I think for MSREGRD/WR it was more about intent of the instruction (exception update of individual regs) than any specific limitation. The decision to limit to 16 words was logistical: there were 4 bits available for size in the relevant record. The record could be increased, but since the goal was single reg access, that seemed overkill.

We started this with the plan to put out a first cut of the scanner and then see what the feedback was. We definitely don't see it as finished, and always intended to incorporate ideas and requests from actual users.

[Brian123]

IMHO, the 16 words isn't a big deal.  If I need more than that, I can just setup another line item to get more.  It's more the raw copying into UDTs that would be handy.  Same kind of tool as the modbus scanner, just smaller.

I do take your points as far as the intent of the instructions go.  I'm guessing most people will be using pre-defined registers to interact with their devices, which was what you were targeting.  This particular situation that I was trying to use it for is a little odd; bulk copy, but only on demand, not continuously.  As it turns out, it's not a lot of data, and I can have it updated continuously without impact to my application.  It's just an extra comm cycle.  If I was really creative, I could probably request pretty much everything and use a couple fields to dump the data into the proper registers (there's gaps I need to jump).  But, I'm getting good enough performance out of it right now, so it's not worth the effort.


Also, please don't take any of my comments as a lack of appreciation for this new feature!  It's great!  I'm looking forward to connecting to a GS20 directly and being able to use it as easily as I did with a GS2 with a Gateway.  Without this feature, I felt like the GS20s would be a step backwards.  Now, they are just as easy to use, and even better, I can make all my third party devices just as easy to use too!

[franji1]

FYI, in your situation, it is much more efficient (comm-wise) to have 1 COMM doing 16 Registers to V1000-V1015, then on an OnSuccess of the MSREGRD, do a MEMCOPY to your UDT from V1000, instead of having 16 COMMs or 8 or whatever going to your individual UDT fields.

[Brian123]

Yeah, the more registers the better.  Do the MSREGRD instructions get interleaved with the scanner polling?  I'm wondering what would happen if you suddenly had a bunch of MSREGRD instructions that went active.  Would it stall the regular scanner polling until they finish?

Edit: Another question, Does the XferCount refer to successfully completed comms?  Or just comm attempts like the ReadComplete/WriteComplete?  I'm looking at setting up a CommsGood bit, probably by having a timer constantly reset by a change in XferCount.  If the timer completes, Comms are not Good.  Something like this in the scanner struct out of the box would be handy, but I realize that CommsGood might mean different things to different people..

[BobO]

Do the MSREGRD instructions get interleaved with the scanner polling?  I'm wondering what would happen if you suddenly had a bunch of MSREGRD instructions that went active.  Would it stall the regular scanner polling until they finish?

They go to the top of the list. Due to the handshaking between the scanner and the instruction, I think at least one background scan comm will execute between each MSREGXX request. I haven't tried to stall it though, but I don't think it will.

Edit: Another question, Does the XferCount refer to successfully completed comms?  Or just comm attempts like the ReadComplete/WriteComplete?  I'm looking at setting up a CommsGood bit, probably by having a timer constantly reset by a change in XferCount.  If the timer completes, Comms are not Good.  Something like this in the scanner struct out of the box would be handy, but I realize that CommsGood might mean different things to different people..

XferCount is only incremented on a successful comm. ErrorCount is incremented on a comm failure.

[Bolt]

We started this with the plan to put out a first cut of the scanner and then see what the feedback was. We definitely don't see it as finished, and always intended to incorporate ideas and requests from actual users.

Here's some Modbus Scanner feedback from me:

1. I can't use a program structure member (Program.S1) as the Local Address to copy to the remote coil.  I currently do that on several of my "manual" MRX instructions.
2. Pressing Esc from the Edit Modbus Scanner Device window causes it close instantly, not saving the changes.  This behavior is inconsistent with most other Edit windows in the System Config.

[BobO]

Here's some Modbus Scanner feedback from me:

1. I can't use a program structure member (Program.S1) as the Local Address to copy to the remote coil.  I currently do that on several of my "manual" MRX instructions.
2. Pressing Esc from the Edit Modbus Scanner Device window causes it close instantly, not saving the changes.  This behavior is inconsistent with most other Edit windows in the System Config.

1. That's a bug. I think it is checking for read/write for values as inputs when it should be happy with read only.
2. I can see why it would be annoying, and we'll add a prompt, but I'm pretty sure the majority of SysConfig edit dialogs cancel without warning.

[BobO]

And that's puzzling. Looking at the code, there is a provision for read only vs read/write, but clearly it isn't working as expected.