Created Date: July 29,2010

Created by: Bob S BN

I wonder if certain devices are just 1 off??

I wonder if certain devices are just 1 off??

I just did reads and writes with Ecom to CT servo drive, and the spreadsheet was right on.

I used MRX/MWX for rs485 to an AC tech VFD, and while I didn't need the spreadsheet for those commands, the registers are 1 off and they tell you that in the documantation.

I can't wait for everyone to do this stuff the same way, and everything (including the PLC) uses the same number type for everything.

Just my $.02,

Created Date: July 29,2010

Created by: keycoldstorage

Unfortunately, I hold little hope for any "open " standardization that is clear and concise. There are to many economic incentives for the old guard to keep this stuff arcane.

//rant on

Case in point, how many pay by the element licenses are there to serve proprietary communications protocols into a distorted Microsoft COM object so that you can pay for another license to build an interface?!

I just messed around with a few of them and found them just as arcane as stepping back down to utilizing open source modbus libraries inside scripting languages like Ruby and Python.

//rant off

Oh well. In twenty years, our kids look back and ask us why we made it so difficult for ourselves. :rolleyes:

BTW, has anybody noticed that the ECOM devices are especially heat sensitive?

edgar

Created Date: July 29,2010

Created by: franji1

I wonder if certain devices are just 1 off??

The issue is, at the APPLICATION (user) level, the Addresses are expressed as 40001 and up. However, at the PACKET level, there is no "40000 " type offset, and you subtract 1 (to get the full range at the packet leve). So at the PACKET level, 40001 is sent as a 16 bit address of 0 (or hexadecimal 0000). 40016 at the PACKET level is 000F hexadecimal.

Since many bitweenies (who implement the PACKET level) do not understand that the APPLICATION LEVEL address rules are DIFFERENT than the PACKET level rules, you end up with the off-by one address values.

Technically, at the PC UI level, you should be entering 40001, or "Holding Register " Offset 1. The 40000 part is not really part of the "address ", but more of a "data type " designator. Here are the "standard " Modbus application level "data type " offsets:

10000 - Modbus Input Bits

00000 - Modbus Coil Bits

30000 - Modbus Input Registers 16-bit

40000 - Modbus Holding Registers 16-bit

Created Date: July 29,2010

Created by: keycoldstorage

Thank you, I suspected as much given my experience addressing even DuraPulse drives over Modbus using the DirectSoft application level stuff is all one off.

The excellent Ruby based modbus library, rmodbus, requires me to strip (or never add it as the case may be) the Modicon notation (40000 for holding registers). This seems to be relatively common as well, that there is an explicit call to the action "read holding registers " or implement 4x un-masked from the address location.

Thanks again, I'm slowly getting used to coming here first when I am having trouble with a concept rather than banging my head against a wall.

edgar

Created Date: July 28,2010

Created by: keycoldstorage

Just an FYI for those who might try and utilize the modbus_conversion.xls http://support.automationdirect.com/docs/modbus_conversion.xls file from Automation Direct. I was admittedly lazy and just trusted its output, but was finding that everything I queried over modbus was off by one address. Looking back at the spreadsheet, it appears to add or subtract an extra address to each "conversion " depending on which way you 're going. Perhaps that was necessary for a different interface.

On my DL-260 over an H2-ECOM ethernet module speaking modbus, the formula to convert V memory to a holding register address should simply be Octal to Decimal plus 40000 (not plus 40001 as the spreadsheet would have it).

Hope that helps someone.

edgar