adccommunitymod (AutomationDirect) asked a question.
Created Date: February 18,2016
Created By: svshow
**** This post has been imported from our legacy forum. Information in this post may be outdated and links contained in the post may no longer work.****
Equipment: P3000 (P3-550) P3-SCM (4 port communication module) 1 port 12 modbus devices 2 port 12 modbus devices Firmware up-to-date... Prodctivity Suite - 2.1.2.1 Found that on P3000 (I think P2000 will be the same) If I use, lets say, 3-12 modbus devices on the same communication port and setup 300 msec read interval (6-8 variables) - P3000 can not organize queue. In one time interval it reads modules with 200 msec interval next could be up to 1000-1500 msec. And does not matter if you set 300 msec - it leaves its own life... Tried to play with poll offset - same behavior. With this issue no reason even talk about Custom made protocols on P3000... :( Checked it with do-more PLC. Same wires, same devices, "same " Modbus read command set - 300 msec exactly same intervals... Works perfect. Anybody have an idea how to fix it?
Created Date: February 18,2016
Created by: ADC_CommTeam02
Just to verify when you state Firmware is up to date, since we just release new P3-550 & P3-SCM firmware on Tuesday 2/16, was making sure you are using these latest files:
P3-550: 1.1.15.101
P3-SCM: 1.1.128.81
Can you also create a system report while connected to the cpu and send this zipped file into our tech support team?
Created Date: February 18,2016
Created by: svshow
Productivity Suite Programming Software, Version 2.1.2 (1)
Module: P3-550(1.1.15.101) - group 0 base 1 slot 0
Module: P3-SCM(1.1.128.81) - group 0 base 1 slot 11
Firmware were updated today in the morning.
By the way - The same issue with Modbus/TCP :(
Created Date: February 18,2016
Created by: ADC_CommTeam02
Ok thanks for the info. If you could send in your system report, that way we can use your project files in our testing to see if we can duplicate the issue. Thanks.
Created Date: February 18,2016
Created by: svshow
Sent to techbox.
Created Date: February 18,2016
Created by: ADC_CommTeam02
Quick question, are you using an FA-ISOCON on Port 1 & Port 2 to convert RS-232 to RS-485? Just verifying for our setup here on our end. Thanks.
Created Date: February 19,2016
Created by: ADC_CommTeam02
Can you verify if you are using an FA-ISOCON (or another brand convertor) on Port 1 & Port 2 to convert RS-232 to RS-485 for his multi drop devices? Just verifying for our setup & testing here on our end.
Created Date: February 19,2016
Created by: svshow
It is FA-ISOCON
Speed 9600 Half duplex
Created Date: March 04,2016
Created by: MikeMc
Interesting finding on P2/P3 serial communications
I have been working on the P2 and P3 Modbus communications over the RS-485 port for a long time and have always been unhappy with the way it operated.
I was never able to get reliable communications without timeouts.
Recently for some reason I decided to put the communications routines in the called every second task.
Each Modbus read or write was set to 500 MS automatic polling and zero offset. The request/response delay is set to 10 MS. The baud rate is 57,600, N, 8, 1
I did some testing with the automatic polling interval and found 500 MS is a good number. If I put it out to 1000 MS, then everything got out of sync.
I am writing or reading about 150 registers total every second. The setup works beautiful. I am completing the task in about 1/3 of a second by the light. Timeouts are gone. No sweat, no pain, I have failure counters setup to count any errors or timeouts and after 3 days of running the only ones I am getting are related to my downloading new versions of the PLC program.
I will be the first to admit I have no idea why this is working but I tried it in several other PLC programs using and as long as they are not on radio links it works like a charm.
I have found on the 9-xTend radios I use from DIGI that it takes about 2-3 seconds after a transmission for all the mesh network chatter to settle down so I am going to try this setup over radio by interlocking the next request to the previous Error/Timeout/Success flags so the next Modbus request cannot be sent until the previous one has completed and leave them in the Call Every Second task.
I am hoping that the secret is in the sauce (the Call Every Second sauce) and I have finally found the perfect way to use serial communications on the P2 and P3 PAC units.
BTW as a side benefit, I found that the Ethernet performance improved dramatically after making this change. I can only assume that what I have done is moved communications to its own interrupt driven thread and relieved the main scan task of having to handle the communications.
Good Luck,
Mike :)
Created Date: March 04,2016
Created by: kewakl
Mike, -- Thank you for posting your concept and results!
Recently for some reason I decided to put the communications routines in the called every second task.
This is counter to what AD techsupport has told me for about 6 years regarding PAC comms. I have been told consistently, "NO COMMS IN A CALLED TASK. "
Maybe they meant "NO COMMS IN A USERCODE- CALLED TASK. "
I am writing or reading about 150 registers total every second. The setup works beautiful.
.
.
.
I am hoping that the secret is in the sauce (the Call Every Second sauce) and I have finally found the perfect way to use serial communications on the P2 and P3 PAC units.
I tried using something like this years ago as a backup to ethernet-to-dataworx-store for an AR2S32 array words - in a distributed storage arrangement to several pacs. Sort of a mock QuickPar (without the parity, and without the Reed-Solomon) I was never satisfied with it.
Maybe if you had done this years ago.....
I hope that AD comments on this.
Created Date: March 04,2016
Created by: ADC_CommTeam02
I’m glad that you have found a setup that is working for your application. However, it is difficult for us to comment on what maybe causing your issues as we would need a great more detail on the code and the other devices and serial comm captures of what is happening at the port.