Problem with Modbus/TCP not working

[Scot]

I've been trying to get a Modbus/TCP connection to a SKADA unit working. The Do-More has no problem Pinging the SKADA, but for some reason I've been unable to discover, it doesn't want to read data from it.

In this screenshot, I connected a PC to the SKADA and am able to successfully read Modbus registers from it:
http://www.mainewoodspelletco.com/Modbus2.png

But the Do-More doesn't seem to want to connect using the same settings:
http://www.mainewoodspelletco.com/Modbus1.png

Is there something I'm missing here?

[Scot]

Nevermind. That was dumb.
I wanted to read the registers in the 30000 range and I chose "3 - Read Holding Registers"
I needed to choose "4 - Read Input Registers".
It works fine now. I was going to delete the question but maybe someone else makes dumb mistakes once in a while and is looking for the same answer.

[franji1]

As you figured out, Modbus Address Type Number (0xxxx, 1xxxx, 3xxxx, 4xxxx) does not equal the Function Code.

3 vs. 4 are actually swapped in the tables below - doh!  Not sure why the folks at Modicon did that.  This is a common misunderstanding, you are definitely not the first or the last.

Address Types

• 0xxxx - Coil
• 1xxxx - Discrete Input
• 3xxxx - Input Register
• 4xxxx - Holding Register

Function Codes

• 1 - Read Multiple Coils
• 2 - Read Multiple Discrete Inputs
• 3 - Read Multiple Holding Registers
• 4 - Read Multiple Input Registers
• 5 - Write Single Coil
• 6 - Write Single Holding Register
• 15 - Write Multiple Coils
• 16 - Write Multiple Holding Registers

[Controls Guy]

And THEN, as if that weren't bad enough, there actually can be a [4]30001 register, which then adds all sorts of fun in addition to the address confusion, because some masters see "30001" and insist on interpreting it as [3]0001.

[BobO]

De-facto standards are the bomb-diggity, no? They are so awesome, everyone has their own!

[Scot]

So, speaking of standards...
I have another device that I'm communicating with using Modbus MRX commands. This device is sending real numbers using 2 words but I can't just give an R address to the MRX command because the words are swapped.
If I read it into V addresses, starting at V100 for example, I can then MOVE V101 to v200, MOVE V100 to V201, then MOVE V200:R to R100 to get the correct value.
Is there a more simple way to use a cast to move a large block of these reversed words into R addresses?

[Scot]

To answer my own question again:
I found a command I've never used before called PUBLISH.
I could just read the Modbus values into V locations using MRX (to V2100 for example) and then use PUBLISH from V2100:R to R2100 with the number of elements filled in and Word Swap checked.

[Controls Guy]

Yup.  Thank heavens for Do-More!

[franji1]

PUBLISH and SUBSCRIBE are SPECIFICALLY for dealing with RAW data that is in a format not "natively" supported by Do-more (including swapped Modbus Register words, BCD format, et. al.).

PUBLISH is when you need to WRITE (Publish) Do-more data OUT to another PLC/Device.

SUBSCIRBE is when you need to READ (Subscribe) data from another PLC/Device to Do-more.

Neither of these actually do the transaction, but just format the data to its desired format so that it can be written/read to the remote device in ITS format.  If you are familiar with the 7 Layer OSI Communications Model, this would fall under "Layer 6 - Presentation Layer".

Most of the time, these are not needed, because most protocols handle these consistently.  However, (for example) Modbus does NOT specify an Endian-ness when dealing with DWORDs or REALs (i.e. WORD order).  This is a some-what common issue with some Modbus devices.

[Scot]

Good point. I'm changing it to SUBSCRIB because what I'm really doing is translating TO DoMore. There was also the added benefit of not needing to cast the V data when using SUBSCRIB. It works great.