Issues connecting with an Energy meter through MODBUS

[keristos]

Here is a screen shot from the Modbus Over Serial Line V1.02 Specification;

If it isn't least significant bit first, it isn't Modbus.

So what they are saying on the datasheet is correct, right?

 

[danw]

The RS-232 spec says LSB goes first. I interpret the Modbus spec as low order LSB bit 1 is first, high order MSB bit 8 is last.

I'm not sure which datasheet you are referring to, the power meter?

One would think that a commercial product would get the serial bit sequence correct. But given the bad nature of the data, who knows?

 

[keristos]

First of all Thank you for this reply, and sorry but I only saw it now (I must have missed it by mistake).

Now, my Answer:

The manufacturer is confused and has poor documentation.

This is getting clearer with every reply I get from you guys...

The Correct Master message
The master's request message should be
slave 8: 08h
Function code 03: 03h
start register: 1000h
length of data: two words/registers: 00 02
CRC: CRC CRC

08 03 10 00 00 02 CRC CRC

This is not what is in the data stream:

The Function code, circled in green has to be 03.
The requested register count, circled in red, must be 02

This is what I posted in my latest trial:

Sending: (Function 4, Addr 4097, length 2)
[08][03][10][00][00][02][C0][52]

Recieving:
[2F][DF][FF][FF][FB][7F][00]

Error:
Wrong Slave address in response

Master software tool

What is called Data Type (circled in red) is NOT the function code, it is the leading numeral used by humans to identify the data type or memory area.The leading numeral for input registers is (3)xxxx

This is confirmed by the Address (circled in blue): 34097, [which I would write (3)4097 because (3)is not part of the modbus message.]

Since Function Code 03 is the correct Function Code, and FC 03 addresses the Holding Registers in the (4)xxxx memory, the Data Type needs to be switched to whatever comes up on the list for 4: (probably 4: Holding Reg)

Then Address will appear as: 44096

I suspect that you've done this at one point or another in the combinations of trials, but stay away from single (one) register reads (device might well generate exception code) and stick with Function Code 03, in spite of the misnamed Input Registers on the mfg's document.

Serial Comm
But none of this will produce a valid read transaction until the serial data makes sense.

That makes more sense now, I guess it is a free software, but it gets the job done usually.

The USB/485 converter must be on the right COM port or you'd get nothing.

I am 100% sure that I am configuring the master software to point to the right COM port of USB/485 Converter. I deduced this from 'Device Manager' on Windows Machine.

A and B must be OK or you'd get nothing (time out).

Correct, confirmed by flipping A and B and proceeded to get a time out error.

Terminating resistors aren't critical at 4800/9600/19.2K with short table top distances (cable lengths).

I tried it nonetheless to make sure it is not something I was doing that was causing the failure.

Have you run a 3rd wire for signal ground-to-signal ground?

Yes I am connecting 3 wires, not just A and B.


Side note in case no else noticed on the Manual of the device, first page, where the device's terminal block for RS485 is, there is also a mistake.

+ : (35)
- : (36)
SG : (35)

This error is also repeated on the sticker on the side of the device. Don't know what to think of this anymore

 

[keristos]

Some devices do not recognize COM setting changes until power is cycled.

Try cycling power after confirming your comm settings.

Sh*t...I will try this one, remember it happening with another device also.....

 

[danw]

Sending: (Function Code 3, Addr 1000h, length 2)
[08][03][10][00][00][02][C0][52]

Receiving:
[2F][DF][FF][FF][FB][7F][00]

The hex representation of the master poll msg in the master tool is correct for slave #8 power meter.

Slave #8 recognizes its unit/node ID address, evaluates the master poll msg as valid with no comm error (the CRC is correct), and generates a reply msg.

The slave's reply msg will be either a normal response or an exception response.

If the slave evaluated the poll msg as having a comm error (CRC is wrong), then the slave would remain silent and would not reply (there is no exception response for comm error; a Modbus slave's comm error response is silence).

But the slave's reply message is garbage, typical of a comm setting mismatch, like a wrong baud rate.

Either
- the slave is sending bad bits or
- good bits are being corrupted in transmission, or
- the receive end is misinterpreting good bits

Are you testing the power meter all by itself on the 485 network? Point-to-point, by itself?

There are no other (multidrop) devices whose drivers can fail to go to tristate mode which can create a network problem?

There is no possibilty of a second slave device, also with a slave ID address 8, who is replying along with the other slave 8, so the result is garbage because of message collisions on the network?

If the power meter is not stand-alone on the network, isolate the power meter from everything other than the master tool/USB/485 converter, to rule out a 'network' problem.

Is it probable that electrical noise is corrupting the reply msg but not the poll msg? Are you testing this setup with the comm cable lying across on an open, exposed, unshielded working VFD?

Could your USB/485 converter have a good transmit driver but a bad receive driver? Or the slave a good receiver but a bad transmitter?

Can you test your USB/485 converter on some other Modbus RTU device to prove it works?

If your USB/485 converter works on some other 2 wire 485 Modbus RTU device, point-to-point, with your master tool and cabling, but that same setup produces a garbage reply from the power meter, then the power meter is faulty: bad transmit circuit - hardware (bias, Uart chip) or firmware.

 

[danw]

RS232/485 converters that were 'port-powered' frequently failed to perform properly on laptops, because laptops limited the power to the pins of the physical RS-232 COM port. Usually, when a DC power supply was connected to the converter, they'd work fine.

A USB/485 converter will rely on the USB port's power source. There probably is no provision for connecting DC power to it.

But if, for some reason, the receive buffers are starved for DC power, then who knows how it fails.

That's why I think that it's important to test the USB/485 converter with that laptop, on another Modbus RTU/485 device to prove that it works.

 

[keristos]

Hey guys just a quick update...

After all the problems these energy meters caused I found out that somehow the 3 different meters I tried out of a panel of 8 were faulty. The 4th one finally worked.

Thank you all for the help and suggestions

 

[m_turk]

Wow That is some serious quality problem...

But nice you got it working

 

[keristos]

Wow That is some serious quality problem...

But nice you got it working

Tell me about it!

 

[danw]

Thanks for the update. Dan