I might have found a modbus problem ...??

More
20 Sep 2009 21:52 #849 by Dave911
Dear Mr. Moderator :)

Modbus question/observation.....
I hooked up a Modbus equipped PLC to EMC2 and have it passing 5 words of info back and forth.
I found that when I run Modbus while doing a read holding registers function on 5 words - things work great
When I add a write function to send 5 holding registers - I get periodic time outs. (Using function 16 write multiple holding registers)
If I remove the write function that sends the 5 holding registers and then add 5 individual write holding register functions (should be function 6), I do not get any Modbus errors.
The errors are flagged both on the PC end via the Modbus error box popping up and on the PLC module as it says a timeout has occured.
I have used this same PLC module with different software to write and read these same 10 holding registers without incident.
So there may be a bug in the utilization of Modbus function 16 - write multiple holding registers?
Is this a known bug? Where are the known bugs listed? Is this the proper way to report a bug??
If someone is familar with the code around the Modbus programming - I could run this serial link though some comm analyzer software and find out exactly where things are falling down.

I sent this out on the emc_devel IRC channel and they indicated you might be the best person to contact....

Regards, Dave

Please Log in or Create an account to join the conversation.

More
20 Sep 2009 22:11 #850 by cmorley
Short answer yes modbus has a problem with multiply registers.
I observed checksome errors but could not isolate where the problem
was exactly - whether the modbus routine or the serial routine.
I seem to remember each frame would only send 8 (9?) bytes and
the rest would be dropped- so ethery thing worked fine as long as
you where under this limit. I will have to try what you described...
I had limited testing devices.
there is a known bug list on this page:

wiki.linuxcnc.org/cgi-bin/emcinfo.pl?ClassicLadder_Ver_7.124

I you would like to analyze the problem that would be great.
I am fairly busy right now but there are a couple bugs in CL I need
to address...

Chris M

Please Log in or Create an account to join the conversation.

More
21 Sep 2009 16:46 #855 by alex_joni
cmorley wrote:

Short answer yes modbus has a problem with multiply registers.
I observed checksome errors but could not isolate where the problem
was exactly - whether the modbus routine or the serial routine.


Hi Chris,
a german user reported a similar problem with CL and Modbus:

(following an ad-hoc translation, hopefully you can understand my gibberish):

The ModBus protocol (we speak of the RTU serial mode) recognize a frame just by the fact that a certain period of time nothing has been sent (in ASCII mode CrLf can be sent). This time EndOfFrame depends on the transmission speed.
The standard specifies: Interval of 1.5 chars: Incorrect frame should be discarded, Interval of 3.5 chars: Frame-end.

One can consider 3.5 chars as the end of frame (at 115kBaud: 1000000/115200)*10*3.5= 280 us.). Because this is a bit fast, the standard accepts, as a minimum time using 1.75 ms at baud rates> 19200 Bd (Modbus over serial 'Page 13 / 44).

Thus, in the File socket_modbus_master.c is the first error:
There, after sending, it calls blindly 'DoPauseMilliSec (ModbusTimeAfterTransmit);' and only afterwards 'SerialReceive (...);' gets called.

This is wrong, according to the Transmit SerialReceive can immediately be called.

The SerialReceive (in SerialLinux.c) is also false.
SerialReceive must wait for the TimeOut period (0.5 seconds by default) for a character (not wait for the whole frame!).
After the first letter was received, it must be read on until for T3.5 (ie in the example, the 1.75 ms) no other signal was received. This then is the end of frame (or a transmission error) and it must also be the end of SerialReceive.
And is not already, simply because it reads faster than transfer (the shortest possible response to a valid request takes about 800 microseconds).

SerialReceive now doesn't wait at all (so I could trace a couple times with ModbusTimeAfterTransmit set at 5 ms) it will lack one (or two) bytes.
But those would have come eventually!
Above all, the waiting time before SerialReceive is quite wrong, especially when waiting for longer answers (which can be for more than 200 bytes!).

Please Log in or Create an account to join the conversation.

More
22 Sep 2009 21:50 #857 by cmorley
Oh yes that is good Alex.
When I was trouble shooting I did figure (gut feeling) the problem was in the serial routines.
I will look into to this as soon as i can.
The other option in the long run is to change CL to use the Modbus library included with EMC.

Please Log in or Create an account to join the conversation.

More
15 May 2010 20:23 #2865 by Dave911
Hi Chris,

Was a change ever put into place in the Serial routines to get rid of the errors that Alex Joni found?

I get recurrent time outs and I think it may be due to the time delay before looking for a response or something similar to that.

It works, but it times out once in a while. If the PLC (modbus slave) responds too fast I suspect that EMC might miss the response message and time out.

I'm sending short messages message back and forth.

If the code has not been patched I will attempt to do it, as I need to get rid of this timeout error so Modbus will function more reliably.

Thanks,

Dave

Please Log in or Create an account to join the conversation.

More
15 May 2010 20:31 #2866 by cmorley
Hi Dave

No I unfortunately have not looked into this. I have another project I am working on.
I would gladly look over any patches to fix problems.
I have few devices to test with.

Chris M

Please Log in or Create an account to join the conversation.

More
16 May 2010 00:19 #2869 by Dave911
OK, I'll take a look at it.

I have a project coming up that requires a reliable Modbus connection, so I am motivated! ;-)

Do you think there is a chance that the classic ladder author/s have fixed some of these issues?

Dave

Please Log in or Create an account to join the conversation.

More
20 May 2010 19:13 #2933 by Dave911
Hi Chris,

I was doing some testing of a Modbus serial RTU connection at 38400 baud to a Siemens S7-200 PLC. I was getting number of errors. I figured out that
I could start EMC2 with Modbus, then quit the Classic Ladder and then restart it from a terminal window so I could see any errors that Classic Ladder was printing.
The command from the terminal window - run from the current project folder - was halcmd loadusr classicladder --modmaster custom.clp

I then discovered after some serious twiddling, that I could get rid of all of my Modbus errors (such as crc errors due to missing characters in the receive messages - caused by modbus serial routines??, errors due to multiple register read/writes, and errors due to excessive CPU loading ) by adjusting the timing in the Modbus config window. I could also increase or decrease the CPU loading (I was running HTOP at the same time also) by increasing or decreasing the delay after receive. For some reason Modbus runs better with a delay after transmit, which seems like a work around to a programming bug in the serial routines.

I have just started digging around in this but the result look promising. It looks like some of the serial routines need tweaking as you and Alex discussed.
I'll look into those also to see if I can get rid of some of this timing sensitivity. But I am able to multiple holding register reads and writes without CRC error simply by tweaking the time delays.

Have you seen the later versions of Classic Ladder? It looks like the author put in a number of bug fixes for problems that you pointed out. (he mentions your name a lot in his logs :-) )

The newest version of ClassicLadder editor has a much nicer look to it.

You did a good job of noting things that you changed between his code and your implementation for emc2.

I'm thinking about trying to port the newest Classic Ladder code version over to EMC2 by following your notes.

Do you see any big problems in doing that?

I did some diffs between the modbus related files in the current EMC2 version and the latest classic ladder release and it doesn't look like he made many changes
in the modbus routines from your implementation in EMC2.

Dave

Please Log in or Create an account to join the conversation.

More
20 May 2010 23:24 #2937 by cmorley
Well your work is encouraging!
I'm sure the errors are in the serial code as someone else was using TCP and did not complain of problems.
I will have to try experimenting with time delay more- when i have time .
Yes the newest CL is much nicer. I toyed with adding the gui improvement to EMC2 code base but ran out of steam before finishing.
I also experimented with adding full capability for floats. I probably still have that somewhere...

yes I was very diligent in the beginning on the changes made. There is probably a few not listed.
Porting CL over is a lot of work. In my case I was learning C code and linux so that is why I took it on as a project so some work
was just me learning.
I see no real problems with Marc's newest version. I really like the box that tells you where you are editing.

Please Log in or Create an account to join the conversation.

More
23 May 2010 23:37 #2978 by Dave911
Hi Chris,

I'm in the process of testing and debugging some changes I have made to the serial routines in the ClassicLadder modbus code.

The delay after transmit and delay after receive is not longer needed. As I suspected, the delay after transmit was covering up some software issues. But I think it makes sense to keep the pause after transmit and pause after receive delays in the code since it might be useful for some users. Also, the delays can be used to control the CPU loading that the serial routine creates. Parts of the receive messages were being lost from time to time if a pause after transmit was not in place.

I should be able to send you a patch file in the next couple of days for your review.

I untangled some of the Modbus TCP and Modbus RTU code so I could track the RTU errors, so the TCP code should be tested again also just to make sure I didn't break something. Do you have a Modbus TCP device? I have a slave simulator on a PC that I can use but I'd like someone else to test it also if possible.

Thanks,

Dave

Please Log in or Create an account to join the conversation.

Time to create page: 0.087 seconds
Powered by Kunena Forum