Difference between Daniel and Enron Modbus

K

Thread Starter

Klaus

We have an Enron Modbus driver. Can this be used on a Daniels Flow Computer?

Thanks in advance.
 
Try it and see.

For one explanation of Enron Modbus, refer to
http://www.simplymodbus.ca//Enron.htm#Modbus

For a second description of what another author describes as Enron/Daniels Modbus, refer here:
http://iatips.wikispaces.com/ModbusForms?token=cbdcefd9f3542f74a8e8bb6b7887b758

For the curious, I reproduce the latter below:

"Enron or Daniels Modbus

In summary: Enron Modbus is just normal Modbus with special handling of 32-bit values as ONE register instead of TWO. Enron or Enron/Daniels Modbus is Standard Modbus with a few vendor extensions.

The exact impact of these extensions is context dependant, but most common Modbus commands work as expected. There are some custom vendor-defined functions available - but few users expect or use them. The largest impact has to do with how 32-bit data values are read/written.

Enron-MB defines two special 4x holding register ranges:

4x5001 to 4x5999 are assumed 32-bit long integers (4-bytes per register)
4x7001 to 4x7999 are assumed 32-bit floating points (4-bytes per register)

Dealing with 32-bit values in Modbus is NOT unique to Enron-Modbus.

However, Enron-MB takes the debatable step of returning 4-bytes per register instead of the 2-bytes implied by the term "holding register" in the Modbus specification.

This means a poll of registers 4x5001 and 4x5002 in Enron-MB returns 8-bytes or two 32-bit integers, whereas Standard Modbus would only return 4-bytes or one 32-bit integer treated as two 16-bit integers.

In addition, polling register 4x5010 in Enron-MB returns the tenth 32-bit long integer, whereas Standard Modbus would consider this 1/2 of the fifth 32-bit long integer in this range.

So the "challenges" posed by Enron-MB slaves are:

Some Masters/Clients insist on receiving 2-bytes per register, thus they can never successfully poll a slave that returns 40 bytes when they ask for 10 registers and expect only 20 bytes.

Worse, the error message the user sees may be simply "comm failure", which leaves the user assuming there was NO response.

Some Masters/Clients that handle 32-bit responses will miscalculate the offset to the next block of registers. Thus after they can poll 50 registers starting at 4x5001, they assume the next block of 50 starts at 4x5101 instead of 4x5051 as Enron-MB expects."

David
 
Wonder what the original author means by "debatable".

> Try it and see.
> For one explanation of Enron Modbus, refer to
> http://www.simplymodbus.ca//Enron.htm#Modbus

> For a second description of what another author describes as
> Enron/Daniels Modbus, refer here:
> http://iatips.wikispaces.com/ModbusForms?token=cbdcefd9f3542f74a8e8bb6b7887b758

> For the curious, I reproduce the latter below:

> "Enron or Daniels Modbus

> In summary: Enron Modbus is just normal Modbus with special handling of 32-bit
> values as ONE register instead of TWO. Enron or Enron/Daniels Modbus is
> Standard Modbus with a few vendor extensions.

> The exact impact of these extensions is context dependant, but most common
> Modbus commands work as expected. There are some custom vendor-defined
> functions available - but few users expect or use them. The largest impact
> has to do with how 32-bit data values are read/written.

> Enron-MB defines two special 4x holding register ranges:

> 4x5001 to 4x5999 are assumed 32-bit long integers (4-bytes per register)
> 4x7001 to 4x7999 are assumed 32-bit floating points (4-bytes per register)

> Dealing with 32-bit values in Modbus is NOT unique to Enron-Modbus.
> However, Enron-MB takes the debatable step of returning 4-bytes per register
> instead of the 2-bytes implied by the term "holding register" in the Modbus specification.

> This means a poll of registers 4x5001 and 4x5002 in Enron-MB returns 8-bytes
> or two 32-bit integers, whereas Standard Modbus > would only return 4-bytes or
> one 2-bit integer treated as two 16-bit integers.

> In addition, polling register 4x5010 in Enron-MB returns the tenth 32-bit long
> integer, whereas Standard Modbus would consider this 1/2 of the fifth 32-bit
> long integer in this range.

> So the "challenges" posed by Enron-MB slaves are:

> Some Masters/Clients insist on receiving 2-bytes per register, thus
> they can never successfully poll a slave that returns 40 bytes when they ask for
> 10 registers and expect only 20 bytes.

> Worse, the error message the user sees may be simply "comm failure", which
> leaves the user assuming there was NO response.

> Some Masters/Clients that handle 32-bit responses will miscalculate the offset
> to the next block of registers. Thus after they can poll 50 registers
> starting at 4x5001, they assume the next block of 50 starts at 4x5101 instead of
> 4x5051 as Enron-MB expects."
 
Hello,

> Wonder what the original author means by "debatable".

Simple; taking a protocol named MODBUS and calling it XYZ MODBUS when a command for MODBUS will not function with XYZ MODBUS.

The XYZ MODBUS creators did not extend MODBUS by adding additional command function codes. They actually broke a MODBUS function code.

Calling it --- MODBUS is debatable.

My2c.

Good luck,
Mark
http://www.peakhmi.com/
 
L

Lynn August Linse

>Calling it --- MODBUS is debatable.
I agree with Mark - Enron/Daniels does break existing codes.

The correct solution would have been to continue the 16-bit words with standard code (so 2 registers per 'value'), then create vendor-defined codes which acted all-most standard, but expected the 32-bit responses as 1 register.

Just some trivia: Daniels was a vendor which started returning 4-bytes per register, while Enron <*WAS*> a utility which decided it could not very well start demanding everyone use a competitor's design, so defined the required 'Enron Design' to sell equipment to them.

Daniels is now part of Emerson, while Enron was bankrupted into shame for fudging the books, hiding loss in off-shore accounts to keep up a super-profitable face in the stock market.
 
Top