Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Brian123 on March 10, 2022, 05:48:09 PM
-
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
-
Sure. Any chance you marked it as read-only in the struct definition?
-
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 :)
-
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.
-
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 :)
-
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.
-
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.
-
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.
-
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!
-
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.
-
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..
-
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.
-
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.
-
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.
-
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.
-
DOH! :o
It has already been fixed by someone else. I tested with bugged code, then checked out to fix, which updated with fixed code, making me wonder why it wasn't working...but it was.
So...Prompt has been added, and support for read-only locations for write operations was already there.
-
Well that was a speedy remedy. Meanwhile, I'm still waiting for a process shutdown to upload my new Modbus Scanner config to the PLC.
-
I'm getting an error message here, can you help me figure out what I'm doing wrong?
I've added a whole bunch of Convert modbus address to local UDT address, many of the Bit type. Now that I've gotten down to TankChiller.Pump, it will not accept it, saying Local Address + Field Count exceeds local data. As you can see, I can write to .Call just fine, not limited to the modbus offset. However, once I try to write to .Pump, it's a no go. I've tried to do it in a new Scanner device to eliminate the Field count and things like that and it's the same result.
-
Well I simply re-assigned the Bits' UDT memory to dw13:0 and greater, and then it accepted the conversions. Still strange to me, but it works.
-
I'm getting an error message here, can you help me figure out what I'm doing wrong?
I've added a whole bunch of Convert modbus address to local UDT address, many of the Bit type. Now that I've gotten down to TankChiller.Pump, it will not accept it, saying Local Address + Field Count exceeds local data. As you can see, I can write to .Call just fine, not limited to the modbus offset. However, once I try to write to .Pump, it's a no go. I've tried to do it in a new Scanner device to eliminate the Field count and things like that and it's the same result.
I think the error might be the editor getting confused, but do you mean to assign a 16 bit value to a 1 bit value?
-
Yes, that's correct. I'm reading all the data from the device as registers. However, some of the registers are actually boolean, so I'm converting them to a 1 bit UDT item to be more usable in ladder logic, etc. I used to do this on the fly via a cast (such as V598:0), but I can't cast a structure member, so I'm converting them to bits here in the scanner config, which is cleaner in the end, but quite tedious to setup initially on dozens of bits.
I have it uploaded to the PLC now, so your scanner does successfully convert it all to bits and whatnot. It also works well in reverse, converting a bit/coil to a write to a register.
I think I'll like this scanner. It is a lot of work to set up initially, but so is writing it all in ladder code initially. It's also a pain that any changes have to go through a PLC run mode transition, but that's kinda inherent to the beast here. Thanks for another cool tool.
-
I've got
a little bit more UI feedback for you:
1. It would be nice to be able to do more than 32 Fields per Comm (they go quick when conversions are used for each register), but that may be technical limitation on your end, and it's not hard for me to work around, just cumbersome initially
2. When I click 'Add Field' in a Scanner that has a long list of Comms and Fields, it adds it as it should (after the cursor/selection) but it scrolls the list to the top, causing me to be working "blindly" while editing the Field parameters. The same kinda applies when 'Remove Field' is used
3. Possibly auto increment the offset/decrement the word count (by total of previous count) when adding Fields after each other?
4. Allow Fields to be moved up and down within the list
5. I'm not a fan of it defaulting to C0/N0 every time I add a Field, I would prefer it to be blank (TANGENT ALERT -> the same applies when using a ladder instruction like MEMCLEAR, it defaults to D0 for count, I'd prefer it to be 1, less chance for overlooking that way, as when I don't put a value in there, I probably mean once only. Conversely, MEMCOPY defaults to count (of 10), not D0 value like MEMCLEAR does)
6. If I edit an existing Scanner, and it prompts for me to update the device profile, somewhere along the way it seems to have lost track of the old profile. This I have not tried too hard to re-create, and isn't a huge deal to me. I also don't follow the auto incrementing revision numbering logic it tries to do for me
-
I've got a little bit more UI feedback for you:
1. It would be nice to be able to do more than 32 Fields per Comm (they go quick when conversions are used for each register), but that may be technical limitation on your end, and it's not hard for me to work around, just cumbersome initially
2. When I click 'Add Field' in a Scanner that has a long list of Comms and Fields, it adds it as it should (after the cursor/selection) but it scrolls the list to the top, causing me to be working "blindly" while editing the Field parameters. The same kinda applies when 'Remove Field' is used
3. Possibly auto increment the offset/decrement the word count (by total of previous count) when adding Fields after each other?
4. Allow Fields to be moved up and down within the list
5. I'm not a fan of it defaulting to C0/N0 every time I add a Field, I would prefer it to be blank (TANGENT ALERT -> the same applies when using a ladder instruction like MEMCLEAR, it defaults to D0 for count, I'd prefer it to be 1, less chance for overlooking that way, as when I don't put a value in there, I probably mean once only. Conversely, MEMCOPY defaults to count (of 10), not D0 value like MEMCLEAR does)
6. If I edit an existing Scanner, and it prompts for me to update the device profile, somewhere along the way it seems to have lost track of the old profile. This I have not tried too hard to re-create, and isn't a huge deal to me. I also don't follow the auto incrementing revision numbering logic it tries to do for me
Fixed the field being off screen. It really should have worked the way coded, but Windows UI coding frequently has it's own opinions.
Added Move Up and Move Down buttons. They work on both Comms and Fields.
Not all you wanted, but some improvements.
-
Awesome, thanks!