ABB AC700 PLC as Modbus RTU Master & 4-5 RTU slaves Communication Problems
Hi everyone!
I have 3 systems with ABB AC700F PLCs as Modbus RTU Masters & 4 or 5 RTU Slaves.
Each system works separately (PLC are physically disconnected from each other)
My problem is a communication failure between Master and slaves after 2 or 3 or 4 weeks of perfect working. The only one decision which solving the porblem after the communication failure is a cold restart of the master PLC. Physilally RS-485 link is perfect, but those failures occur in any case of program examples that I used before for three years of experiments.
Has anyone such Modbus RTU communication problems?
Technical characteristics of my communication task:
- Modbus RTU Master - ABB PM783 Controller - 1 unit;
- Modbus RTU Slaves - ABB P820 Panel - 2 units; Danfoss FC-102 - 3 units;
- Baudrate - 38400 bits/sec;
- Physical interface - RS485;
- Cable - shielded twisted pair for RS485 networks;
- Network structure - "chain with PLC inside" according to any RS485 network sructure and described in ABB manuals;
- Application - Water Heating Plant;
- Communication Timeouts (configured in Modbus function blocks): ABB P820 Panels = 100msec; Danfoss FC-102 = 50msec;
- Actual Response Time (this value appear on the "RSP" pin of the Modbus R/W FB): for ABB P820 Panels = 60-70 msec; for Danfoss FC-102 = 25-30 msec;
- Number of retries: ABB P820 Panels = 1/1 (for read/write); Danfoss FC-102 = 0/1 (for read/write);
- Duration of PLC Program cycle >= 300 msec;
- Maximum quantity of Modbus send/receive operations during 1 program cycle - not more than 2 ("AUTOREQUEST" mode in not used because of its misoperability discovered at the start of this job, i.e. each PLC cycle only 1 or two of Modbus R/W function blocks receive "TRUE" on its "REQ" input.);
- Average Timeouts Quality (TO = (Timeouts / Transmit Count)*100 = 1.5 %). Best is TO = 0,01 %!!!
- Process Image Size (Configurable in Task Header) - 4 or 32 kB - No matter!
As usual system runs properly, but sometimes (once in 2 or 3 or 4 weeks or longer) Receive count stops to increment, but Transmit count and Timeouts continue to increase (PLC sends communication requests, but all slaves cannot receive any request, so all Master requests become unreceived by the slaves). As I said - the only working decision to solve this problem is a cold restart of the master PLC (by means of power supply reset or remotely by means of reload of the whole station in Control Builder). Screenshots that decribe the problem and after restart - see in attached files (pls take a deep look at the communication statistics before and after!).
So, please, help me to solve this problem!!!
Our local ABB representative (ABB - Ukraine) cannot help!!!
Answers
Hello Andrikmail,
Lots of information :), Mean time go through your project, provide some more information On MBread/write FB are you getting error (bit 1 @ ERR pin) ? if yes what STA code you are getting ? is it possible to get controller diagnosis data via web server will help to get solution from other community users, too. From engineering pc once controller is reachable (pinging) type controller IP in web browser and click on diagnosis tab and perform write to file or save data from there and you can attach that file.
There could be several possibilities of communication loss and solutions, too. Have you tried performing warm start if at all that works ? Will get back to you after more analysis...
Hello, Sumit!
MBread/write blocks are reporting about next types of errors (error codes): 5 or 6 or 13 or 256!
About error code 256 I have no idea what does it mean :).
About warm start - helpless: Transmit Count contunues to increase, but Receive Count stays constant. Only complete restart helps to communication come back!
About web diagnosis report - I`ll try to catch this error next time and then to make this report. But I think it will be helpless, because last time when I was making it I didn`t see any interesting information inside.
I`ll try to find my last webreport and will attach it to my next post.
I`m very glad to see that my answer became interesting to the community and I hope that we`ll find the solution together!
Here is the link to video files with the catch of the problem on 2013/01/14 (but it was very cold in the machine room, so it could be a part of the problem):
_http://www.ex.ua/view_storage/479123914410
Hi Andrikmail.
This is very interesting. The error codes You gave mean:
5 - Time-out error
6 - Miscellaneous errors
13 - Warm boot leads to loss of connection
256 - Illegal function
The last one is shown when the requested Modbus function is not supported by bus subscriber, which by the way doesn't make sense in this case.
At the moment I'm trying to find anything relevant to this problems in Your program. As Sumit wrote - controller diagnosis data could be helpfull.
Source: 3BDD012515R0501_Communication Fieldbusses
Few observations
Observation -1
In video in commissioning mode master object communication statistics in lower pane shows big count for parity and crc errors, also for timeout and retires. For healthy communication except transmit and receive count everything should be zero.
Check : configuration of MODM_DEV object in master (Framing,mode,baudrate,steopbit,parity) should be same across all the slave(across modbus network). So that parity error count will go to zero count
Observation -2
In program you are using some logic to process ‘Request’ pin in read and write block, seems it’s leading to collision in read – write values and causing timeout and retires error. For sure errors should be zero and if you are not missing any read/write request the tot, retires should also be zero.
Check: If you can optimize or remove your logic to process request pin, just give pulses on request pin of write block and put read block with auto request. Check image below to read and write logic from one of the project as example
Use Modbus master view block and loop back block to trace your communication. The timeout, retires, crc and parity should be zero.
Observation – 3 from govindaraj thanks he noticed this
Termination of master within the busline
Check : If the master is located within the bus line, it does not need a terminating resistor.However the pull-up and pull-down resistors must be activated (see the following diagram).The Bus cable sheath should be grounded.
check more info in manual "2PAA103858R0201_M&I_AC700F"
Why you are using taks cycle time 300ms, is that process value changing that fast ? Else try to give task cycle time 1s or 500ms remove logic for ‘request’ pin process give some pulses for write block ( you can create pulses using AND block) and read value with auto request.
This can be guideline at L2 support level and for further help I recommend you to contact L3 support line. good luck!
Hi Sumit!
Thanks for your answers and proposals!
Let me answer on yours to clear the situation:
Observation -1:
All of the devices on the network are tuned with the same framework parameters. So, as You told "(Framing,mode,baudrate,steopbit,parity) are the same across all the slaves (across modbus network)."
"For healthy communication except transmit and receive count everything should be zero" - I agree, but the practical results are different. :)
Zero Timeout and Error statistics I can have only if I`m trying to communicate with one or two slaves. But my task consists of 1 Master and 4-5 Slaves :). But I have no statistics about the time of the proper work of such configuration (maybe in few weeks communication freezing problem can occur even with zero statistics of Timeouts and errors).
During the last three years I tried a lot of program configurations to make the communication statictics better
Observation - 2:
Yes, I`m using some logic to process request pulses for maximum of 2 Modbus Read or Write function blocks (Every PLC Cycle only maximum 2 Reading or Writing Blocks are active). There are no cycles where Read and Write Blocks working together. There are no cycles where PLC is trying to Read or Write Different Slaves. So, communication formula is: 1 PLC Cycle with duration of 300 ms = 1-2 Reads or 1-2 Writes of the SINGLE Slave. For my process cycle time is very critical, because I have air pressure regulator inside the PLC program and PLC has to send speed setpoints into 2 frequency converters at least once in two seconds, thats why I can`t increase PLC`s cycle time. Current cycle time of 300 ms is a practically measured maximum time discrete, that can observe my process regulation stability. Higher cycle times of the PLC leading to delays in reaction which can cause boiler damages.
When I used Autorequest principle for reading and writing, my communication statistics was absolutely insane (in comparison with todays results - see attached files). Sometimes I had 30% of Timeouts with Autorequest Program Configurations!!!
Practically the use of autorequest was causing a freezing of the communication every week or twice a week. That`s why I decided not to use Autorequest communication principle.
Normally, I Think, Autorequest principle is a good idea of ABB software developers, but on the practic this idea does not work correctly. That`s why I proposed to my local ABB represantatives to take a deep look on the Modbus Master Driver Hardware and Software, but my request had no result.
The same principle, for example, is used in communication parameterisation of Schneider and Siemens PLCs, but there are no problems with Schneider and Siemens in comparison with ABB.
Observation – 3:
Termination of master within the busline is absolutely the same as in Your example.
P.S.:
In my observation I can describe my problem like: "Master PLC in some moment is feeling dizzy and starting to send unsynchronised requests that cannot be read by any slave. Then Master PLC does not make any decisions about this situation and absolutely loosing control of the communication process. But PLC says - NO Problems, NO Warnings, No Alarms! Everything is OK! Let`s Work! :)".
During the last three years I tried a lot of program configurations to make a communication statictics better, but "communication freezing" problem stays with me :). The main negative factor in this issue - that's what it appears irregularly, and you never know when the problem will appear again.
Now I have another problem: winter season is finished and Water Heating Plant is stopped. Now I have to wait for the next Heating season to continue my experiments.
I wish I feel myself like beta-tester of ABB AC700F PLCs :(
Anyway! Thanks for attention and for providing some fresh ideas!
How can I contact L3 support line? Please Help!
Hello andrik,
You can check with local ABB representative to contact to L3 support, would be proper channel I think. or check @ http://www.abb.com/service/seitp335/8b233e49d6fa8ce3c125751d004f04cf.aspx?produ
ctLanguage=us&country=UA
Few comments on your clarification,
Practically I worked with 1 master 5-6 slave’s such combination of many serial lines in one of the PDCS project, communicating with umc’s and breaker works fine. But there we were communicating bit slower than 300ms task cycle time and 3.84K baud rate:), I could not get your statement “in few weeks communication freezing problem can occur even with zero statistics of Timeouts and errors” is that climate is so cold! Even communication data freezing too! :)
In summary basics of communication what I understood, that if receiver receives data @ faster frequency than senders send data frequency, there is no data loss, tot or retries. Except there are any noise, cable, configuration or programming issues or anyother limitations.
One more thing you can try, if haven’t tried yet, you can read and write with different task cycle time, if possible! Good luck.
Hi Sumit!
Thank You very much.
Now my Automation equipment is disconnected from the power supply because of the end of the heating season.
I`ll continue my experiments when the Plant technicians wiil provide power supply again.
Now I just have to wait.
When I start my work again, I`ll send You a message that describes my new results.
Good Luck!
Hello Andrikmail
Did you solve this problem?
Add new comment