Created Date: October 22,2009

Created by: jackson

Why don't you use interlocking with the Status bits?

Don't send a message to a device until after the current message is Successful or ends in an Error.

If you do this in that manner, you should not run into a buffering issue.

I think you would only need to do this interlocking per device as Ethernet will allow you to send messages to multiple devices concurrently. The Modbus TCP spec. tells you not to send multiple messages to the same device concurrently so I think that is why you are buffering up.

I don't think your speed will suffer any since you are buffering anyway.

Created Date: October 23,2009

Created by: pravp

Yes as you already notived I am using interlocking bits. I have also raised this issue with tech support and yet to hear from them.

Yesterday I had a look at some of the CPU status bits and there is a status bit that goes true when the ethernet buffer goes 95% and this comes on as soon as I take a Modbus TCP slave offline. It seems as though if a slave goes offline the PLC is unable to detect this offline state and does not seem to give any feedback and keeps filling its buffer until it overflows.

Lets see what tech support come back with.

Created Date: October 23,2009

Created by: jackson

Ok, I got it working like I 'think ' you want.

I found 3 issues/problems.

1.) There is 1 Counter interlocking all 4 instructions. This is Ok but when one of the devices go down, you are having to wait on the Timeouts for the down device before you send messages to the Up device. I changed the code to 2 Counters: 1 per device (interlocking 2 instructions). That is the important part, I think. I don't think you need to interlock between devices.

2.) The "In Progress " bit comes on after the timeout set in the CPU hardware configuration which may conflict with your Counter permissives on the Timeout timer in your code. I substituted the same Counter permissive used to trigger the MRX/MWX instruction for the "In Progress " bit you were using. This prevented the occasional stall in the code when 1 device goes away.

3.) The Counter permissive in the lower sub rung of your rung you use to increment the Counter for the next MRX/MWX instruction needs to be an Edge contact. Using a Normally Open contact there causes a race condition between the Counters.

After I made these changes in my setup, everything worked great.

Hope this helps!

Created Date: October 24,2009

Created by: pravp

Jackson :cool: thanks for your help!

You code works good and I can see how you have only interlocked the Modbus slaves and not individual transactions like I did.

I have hit a snag though. Have a look at my program.

MB01 - Terminator I/O

MB02 - Terminator I/O

MB03 - MB06 - DL06 PLCs

I have set up a "called task " for each of the Modbus TCP slaves so that I can enable/disable each slave if required. If I enable MB01, MB02 & MB03 then comms works OK and I do not get any failures, however as soon as I bring online MB04 or more, slaves MB01 & MB02 start failing.

I have set up some counters that are passed on to the DL06 PLCs so that I can see how fast the Modbus transactions are happening and they are around 10ms which is fantastic.

The problem seems to be with MB01 & MB02 the Terminators and how they handle their TCP connections as they are intermittently timing out when comms to all of the Modbus TCP Slaves are going at the same time. If I only have MB03 - MB06 working then I do not get any comms fails.

I have even tried delaying the read and write polling in MB01 & MB02 but this still has issues and causes timeouts.

I have a feeling that this is because the comms buffer is getting full as the only thing that will cause a comms failure alarm in the code is if the "Complete " bit from the MRW/MRX Transaction sticks on for longer than 1 second.

Created Date: October 27,2009

Created by: pravp

Problem Solved!

Hi All, Thanks to support from techbox they managed to find the problem

One of our comm specialists here setup a test with your project. I had set up test with the same hardware, and had no issues.

His initial test used H2-Ecom100's in place of the T1H, and he saw no problems with your project.

However, I wanted apples to apples, and we rounded up the 2 T1H's, and he started seeing an issue. The Term I/O's respond much faster than any of our PLC-based units ( they aren't hindered by scan time) and this causes a problem in your code.

He worked on it, and said the issue is that the Complete bit of any instruction ( technically, just for the T1H's)needs to be reset immediately after detection. You can SET a bit ( as you did) so you can keep working with the Complete status, but he said to add a RST (in parallel) of the Complete bit. The Complete bit actually stays on until the next instruction uses it, and the T1H can actually respond so fast that the "one-shot " instruction never senses the change of state, and never comes back on.

So, for example, in your MB01_Comms task, he recommended paralleling the output to add a RST of the complete bit, changing rung 6 to:

One shot "MB01_R01_COMPLETE " -------------(SET)MB01_R01_COMPLETE_SET

'--(RST)MB01_R01_COMPLETE

He did this to your program for the T1H tasks and it worked just fine, he no longer saw the problems you did. They are going to recommend this for all instructions in the P3, and they are going to create some example communication programs.

He said you would have to go thru your program and make those changes (adding the RST instructions), but that should take care of your problem.

I have made the changes and tested the program and it is now working SWEET :D I must admit this is much more reliable and faster than automatic polling as when I used automatic polling comms used to lock up. I will keep this code running for a few days to ensure all is good.

At this stage I dont expect any problems as it has been running fine in its previous form for more than 3 days.

I have attached my sample program for anyone who wants a reliable high speed solution to modbus comms :cool:

Created Date: October 22,2009

Created by: pravp

I am trying to set up high speed communications between the P3-550 and some modubus TCP slaves (2 x terminator I/O racks and 4 x Koyo DL06 PLCs). I have tried both manual and automatic modes of communications but I am unable to configure the P3-550 to not completely loose communications with the modbus TCP slaves that are online when one or more of the slaves go offline.

The system works very well when all slaves are online but if one or more slaves go offline it seems as though the communications buffer fills up and communications grinds to a halt.

Would appreciate if you can advice on how I can set the system up to manually trigger modbus TCP read and write insrcutions that is intelligent enough to disable communications to a Modbus slave when it detects a failure and keep communications going to healthy slaves. The system also needs to recover communications with the modbus slave that went offline when it comes online.

I have a test program here that I wrote but the problem seems to be that when one slave goes offline the buffer fills up and everything stops working. If you put the PLC into STOP and then RUN it keeps going fine. In the test program I have set up one read and one write instruction each to both the terminator I/O Modules.

P.S. We are only going this way because we need counter modules and since P3000 does not have this yet we are bringing in the counts via Modbus TCP and the Terminator I/O

Click here to download P3000 Project