Hello people,

I am having a really raer trouble that is driving me crazy and I have to solve really quickly. I have a little Modbus network running over a RS-485 link; the slaves are Nuflo and Emerson Process Flow Computers, the master is the Modbus I/O Server from Wonderware. I am communicating using an USB to RS485 converter and so far I have not added terminal resistance to the communication loop which is really short, the speed is 9600.

If I communicate to each slave individually I have no problem, but if I communicate with all the slaves, I start getting the answers from slaved that were not directed on the request!!!

I am using the software HDD Free Port Monitor (which I think is good) to see the port activity and below you can see what happen. This behavior occurs all the time, few times the communication goes ok. If anybody has any idea please let me know; if somebody know anyone good in serial communications and Modbus communications, let me know as well. I have to solve this really fast! My email is [email protected]


Thanks a lot and see the monster:


Request: 10/8/2007 9:01:16 PM.92464 (+0.0000 seconds)
05 03 1B 5A 00 01 A3 79 04 03 1B 5A 00 01 A2 A8 ...Z..£y...Z..¢¨
Answer: 10/8/2007 9:01:20
PM.98664 (+0.0625 seconds)
04 03 04 E8 E0 96 42 74 F4 ...èà–Btô

Request: 10/8/2007 9:01:20
PM.98664 (+0.0000 seconds)
01 03 1B 5E 00 01 E3 3C 06 03 2F 04 00 01 CC A8 ...^..ã<../...̨
Answer: 10/8/2007 9:01:24
PM.04964 (+0.0625 seconds)
06 03 02 47 1F 7F BC

 

Increase the transaction timeout value on the OPC Server. You're likely seeing a late reply due to a busy or overburdend embedded slave device.

You'll need to make empirical changes until you find something that works. Try a significant increase first (5x current value), then tune from there.

Contact Automated Solutions Technical Support for serial/modbus comms expertise.

http://www.automatedsolutions.com/support/

 

It appears that the hardware is working (without calculating checksums, etc). The message formats seem to make sense, with the caveat that there appear to be garbage characters following legitimately formatted PDU's.

I've never used HDD free port monitor, and I assume that's what has been posted. And I'm ignorant of Wonderware, but I can tell you what the posted messages seem to indicate.

The first request query is time stamped 9:01:16, addressed to slave 05
It isn't clear what "92464" is.

The first request query 05 03 1B 5A 00 01 A3 79 interprets as:
slave 05
read (03) one (0001) holding register(s) at 1B5A
CRC = A3 79

The first request appears to be followed immediatesly by a 2nd query
04 03 1B 5A 00 01 A2 A8
slave 04
read (03) one (0001) holding register(s) at 1B5A
CRC A2 A8

What is posted as the response
04 03 04 E8 E0 96 42 74 F4 ...
seems to be time stamped 4 seconds later: 9:01:20
4 seconds is a medium long time for a reponse. And although it comes from slave 04, the most recent query was issued to slave 04, see above.

And note that the "unknown 98664" is followed by (+0.0625 seconds).
0.0625 seconds seems like a very reasonable serial reponse time, but 62mS is a far cry from the 4 second date stamp. It isn't clear how the times correlate.

The response 04 03 04 E8 E0 96 42 74 F4 ...
interprets as:

slave 04 responds with holding register data (03) totaling 4 bytes (04) (probably a floating point from the flow computer); consisting of E8 E0 96 42, then the CRC 74 F4.

Looks l;ike a reasonable response to the last full request (lots of garbage characters follow the request sequence. It isn't clear what those are).

The same pattern repeats for the 2nd set of query responses, where the response is from the 2nd query, not the first.

Slave 01 is queried, followed immediately by slave 06.
The response is from slave 06.

Somehow the master is not waiting for a response from the initial request (in the first case slave 05, second case 01) and the responses are from the slaves addressed by the 2nd queries, 04 and 06 respectively.

Tell the master to breathe deeply, enjoy life, wait the first slave's response . . .

Carl

 

Dear fellows; the problem is solved!!
As Mark said the problem was a timing issue, if you see close to the message, the request contains another request after the 16th byte; this second request is the one which is getting the answer from the slaves. I just realized about it this morning; the master was sending two question one after the other; I solved the problem changing the times between the questions (even though the master should wait for the timeout).

I would like to thank you guys, I also would like to thank Mr. Gerry Corriani who sent me an answer to my email.

This is a very good forum, I will be checking it in case I could help somebody else, thanks again.