Modbus Scanner Write Registers with Offset

[RBPLC]

I'm trying to build a profile using the scanner tool. When I attempt to write two consecutive registers with no offset say (2799-2800) and only write to these two registers, the write performs as expected. If I instead start the write addresses at 2783 with a count of 18 in the comm setup then build a field attempting to write to 2799 using an offset of 16, this no longer performs the write as expected. Thoughts?   

[franji1]

I think there's a limit to the count to be 16.

[BobO]

Appears to be working fine.

@Franj - Only with the register defs.

[BobO]

And did it as two different conversion fields from N0 and N1. Worked there too.

[RBPLC]

I tried it with the offset on a different device and it appears to be working correctly there. I'll have to do some more testing with the original device. 

[BobO]

I tried it with the offset on a different device and it appears to be working correctly there. I'll have to do some more testing with the original device.

Your device may be the issue. Many Modbus devices get weird over ranged accesses. You can open the scanner monitor to see if any errors are being reported.

[RBPLC]

It appears to be the original device. With the attempted ranged access it's continuously incrementing the .ErrorCount. It also zeros the first address in the range (possibly all of the other addresses in the range as well). When I switch back to the non-ranged access, it appears to be working without issue with no increase in .ErrorCount. Reading with ranged access doesn't appear to be an issue. That's interesting. I've never seen this before. I guess I'll just have to individually access all of the registers I want to write to.

[franji1]

Some devices don't support the Multiple Write FC (FC16 Write Multiple HRs), only the Single Write (FC6 Write Single HR).  Some are the opposite (force ou to do FC16 with count of 1).  The Master is a Slave to the Slave's implementation 

OR, it could be that specific range is not supported - possibly try writing 2 in one comm and then the rest singles and see if that works.

[ADC Product Engineer]

Also a lot of devices have "holes" in the memory ranges which will cause an error as well.  I don't understand why the vendors choose to do this other than lazy/inefficient/poor programming techniques.

[BobO]

Also a lot of devices have "holes" in the memory ranges which will cause an error as well.  I don't understand why the vendors choose to do this other than lazy/inefficient/poor programming techniques.

It's not always that straightforward. DL scratch pad is an excellent example. Some portions of memory are actual memory, some portions of memory are computed as requested, and some portions are really neither, they are effectively task codes masquerading as memory. The effort to make that appear to be flat memory can be considerable and with very low performance. Sometimes the juice isn't worth the squeeze.