Industry Online Support
Technical Forum
Navigation
Rating 
Thanks 0
| 6/5/2009 1:45 PM | |
Joined: 1/4/2008 Last visit: 1/4/2025 Posts: 703 Rating:
|
Hello, imho the grounding would be the reason. You wrote about grounding of boxes, haven't you forget to ground the Profibus cable? I had the same problem with the Danfoss FC for big ventilator, there is such big electromagnetic field, especially while starting. There is a grip near the Profibus connector on the Danfoss mounting. You should remove the top insulation from a Profibus cable and connect the cable shielding with the grounding of the FC. Regards Sydney see the manual for Profibus module, page 11 http://mcliterature.danfoss.com/WebPublish/doc_MG90G102.pdf |
Last edited by: Sydney at: 6/5/2009 1:54 PMliterature link addition... |
|
| 6/5/2009 3:18 PM | |
|
Posts: 1064 Rating:
|
Open your hardware manager and go online it should show you what node is failing with a red x in the niode |
| 6/5/2009 3:24 PM | |
|
Posts: 139 Rating:
|
You may have taken these measures already but just in case you havent, you will find that by increasing the number of retries on the bus will help improve stability straight away. I have attached some pictures. One profibus trace with 11Mhz noise on the bus. (this network was still working by the way). And one picture outline how to change the bus setting from default to increase the number of retries on the bus. The default setting is typically 1 retry before the node drops off and has to go through theprocess of master and slave getting to know one another again."set parameters" Get diagnostics" etc. Increasing this value will give the slave more chances toread a dropped message. I reccomend you first try setting to 3 and then increase from there if no success. Just be wary to check the max Ttr times which is the bus calculated max cycle time. the more you increase the number of retries the longer your bus cylcle may be on occasion. Anyway this should at least buy you some time to apease your customer while trying to iron out the wrinkles. AttachmentSet Retries will help.zip (487 Downloads) |
| 6/6/2009 2:44 AM | |
Joined: 10/7/2005 Last visit: 1/23/2025 Posts: 3032 Rating:
|
Hello jacekpro From what you've described, your bus instability problem can have anumber of causes Let's start with one specificcomment relating to you stating that: "This profibus network supplied with this OLM is about 350 m long. Profibus rate is 1,5Mb/s, but when I lower rate to almost lowest 19,2 Kb/s the same things happens but not as often as with higher rate. And disappearing lasts few seconds, not 200 ms. I don't see relations which slaves disappear. For me it is random .." The maximum (purple copper cable) Segment length is 200 m for1.5Mb/s.You will need toadd repeaters for your length, alternatively lower the speed to 500 Kb/s and you can have segment lengths ofup to 400 m(a network topology drawing would greatly help,please post one if you have it). What worries me most is that you have the same bus instability problems even at 19.2 Kb/s. At this baudrate your Profibusshould run stableeven if you'd useapair of wet twisted shoelaces instead of Profibus cable(Ok, I'm exaggeratinghere, but I trustyou getmy drift). The "random" disappearing of your Slaves is a hint of general bus instabilities rather than related to a specific Slave(Slaves get polled one afterthe other by the DP Master, depending on when the short lived interference occurs it will "corrupt" the request or response telegram relating to a"random"Slave that is currently being polled by the Master). If segment monitoring is enabled on your OLM (see the OLM manual for DIP switch setup), the OLM can block the interference from propagating onto thefiber (i.e. the interference is contained to "only" affect all Slaves that are part of theRS485 copper segment of the OLM). Without the aid ofbus analyser (e.g. Procentec's Profitrace), it is hard to say how good or bad the signal quality of your bus is in general(with and without a frequency converterrunning). As such, what I suggest is to go back tosome basics and start a "process of elimination" as followed: 1.) Go to www.profibus.com,navigate to the download section,grabthe "PROFIBUS Installation Guideline for Cabling and Assembly" as well as the "PROFIBUS Installation Guideline for Commissioning" andimplement the recommendationscontained in them (it doesn't cost the earth to implement these but it will give many many years of problem free operation). Do especially the test for Shield continuity (gut feeling tells me that your cable shield is interrupted somewhere along the segment which is a prime candidate for the problems that you described). 2.) Check the installation chapterof theOLM manual (http://support.automation.siemens.com/WW/view/en/24164176) and pay heed to what it says (e.g. keep the OLM away fromluminescent lamps and contactors and/orimplement the interference suppression measures that are outlined in it). 3.) OLM's also allow you to measure the optical signal quality witha multimeter via measuring sockets, which would not hurt to do too. 4.) Check the DIP switches on your OLM's and make sure they "line up" with your chosen topology (again, a network topology drawing that includes cable length would greatly help,please post one if you have it together with the DIP switch settings that you have). 5.) Anchobi is also correct with his advise, I usually change following bus parameters to further "bulletproof" thebus (see also the FAQ section of www.procentec.com): Retry limit: Change from 1 to 5 Min. Tsdr:Change from 11 to 22 TQuiet: Change from 0 to 9 These however act as the last line of defense and do NOTeliminate the cause of the problem (they merely allow the bus to "ride trough" short lived interference). That's all I can think of for now and I reallyhope this heps you in eliminating the problem. Cheers Fritz |
|
Cheers |
|
| 6/6/2009 9:24 AM | |
|
Posts: 33 Rating:
|
I have attached my network topology. All connections marked with F.O. are fiber optic connections, all others are standard profibus cable connections. Fiber optic ends like this because the rest of network has not yet been finished. The problem touches slaves 51 and 52. In slave 16 I have two much bigger FC's, and they do not interact with profibus network. Noises do not cross OLM, they are only visible in a part with slaves 51 and 52. If i turn on FC in 51 all other 19 slaves in this part starts to blink once in a while. I haven't modified DIP switches on OLM's because when I tested at the beginning my network all was working with their default positions (as I remember - all zeros). The problem starts when I turn on FC's, and when there are off, blinks are seldom (once in a 2-3h). Do I have to modify these switches? If yes I might need some help choosing how.
Regards, Jacekpro Attachmenttopology.pdf (467 Downloads) |
Follow us on