Navigation
PROFINET on Unmanged Switch & 50 Mbps Regular Antenna
Created by: G_R_E_Y_31 at: 12/19/2014 4:02 PM (5 Replies)
Rating 
Thanks 1
6 Entries
| 12/19/2014 4:02 PM | |
Joined: 5/26/2011 Last visit: 11/14/2024 Posts: 456 Rating:
|
Good day experts! I'm working on a Profinet system which passes through unmanaged switches and a 50 Mbps antennas (please see attached file for the system architecture). Now I'm having a communication error to both gateways (diagnosed through online HWConfig) even though I can ping and find on Simatic Managers' "search ethernet node" all the devices from all different switches and even upload and download to the CPU315. This might mean that the ethernet network per se is fine, but maybe not good enough for Profinet protocol. I've tested my configuration on bench (direct CPU-gateway-power meters connection) so my suspicion lies outside, on the netwrok, namely either or both the switch and antenna (and someone told me that the switch recommended on Profinet systems are the "managed" ones and that Profinet system has a minimum requirement of 100 Mbps, but the antenna only has 50 Mbps capacity). So I made some isolation. First I pull the gateway and connect it directly to the CPU once more, thereby bypassing both antenna and switch, and there's no problem. Second, I connect the gateway to the switch, thereby bypassing only the antenna, and there's also no problem. 1) Does establishing communication between CPU and gateway on a single switch (Isolation 2) really vindicates the use of the said unmanaged switch on Profinet system? Because someone told me that maybe that can be fine with only two devices talking on an unmanaged switch, but not when you have four switches and 9 devices (CPU, gateways and antenna, my whole system). 2) If the answer to 1 is "yes", then the problem must be on the antenna, right? Is it due to it being only 50 Mbps? Does replacing it with one of 100 Mbps or more would do the job? 3) We are thinking to bypass only the switch by directly connecting the CPU to it's antenna (it's a POE line, is it ok) and the gateway to it's own antenna on the other side. If this worked, then it must be the switches right? Or is it even worth a try with a 50 Mbps one? Thanks for any response!
AttachmentPROFINET_VIA_SWITCH_ANTENNA_SYSTEM.zip (185 Downloads) |
Last edited by: G_R_E_Y at: 12/20/2014 1:18 PMLast edited by: G_R_E_Y at: 12/20/2014 2:59 AMLast edited by: G_R_E_Y at: 12/19/2014 4:05 PM |
|
| 12/20/2014 12:08 PM | |
|
Joined: 5/26/2011 Last visit: 11/14/2024 Posts: 456 Rating:
|
Can anybody help me please? |
| 12/22/2014 3:37 AM | |
Joined: 10/7/2005 Last visit: 11/14/2024 Posts: 3027 Rating:
|
Hello G_R_E_Y ok, can't really tell you if the CISCO switch is (part of) the problem or not and perhaps the info in the thread Cisco switch and simatic profinet is of help. My main question to you is though: Have you adjusted the PN I/O update for every device behind the wireless link? (any WLAN with PN I/O will never give you the update time that a "hardwired" solution does) If not this would be my first point of action, have a look IWLAN: Setup of a Wireless LAN in the Industrial Environment and Basics on Setting up an Industrial Wireless LAN for more on this. I hope this helps |
|
Cheers |
|
| 12/23/2014 2:24 AM | |
|
Joined: 5/26/2011 Last visit: 11/14/2024 Posts: 456 Rating:
|
Hi sir fritz! I haven't adjust any PN update time on my configuration. Would it be on the HWconfig (since it seems there's no such configuration on the ANYBUS gateway software)? Though I think I've seen some update time config on the CPU properties, I'm not sure about the gateway GSD properties. Maybe it's on the surely informative documents you linked, I'll study it later. Anyway, It seems we have actually pinpoint the problem already. It appears that the use of unmanaged switch and 50 Mbps antenna can be ok, but the problem is on the signal quality/strength on our installation. I complained on my last post that the CPU-gateway PN comm. is fine with switch only and with antenna only but not with both. That's our findings on the higher capacity antenna we testedwithout disk(since in this antenna the disk is separated and not available at that time). But when we test the existing installed antenna (the 50 Mbps model) on bench (short range/face-to-face) it's actually ok with or without the unmanaged switch. When we tried to slightly distract the line of sight, there comes the PN comm. error, but with the "normal" ethernet functions ok. This bench test of the switch and antenna is virtually the same setup and model on the actually installed ones, only with the difference of the distance and line of sight, which both affects the signal quality/strenght, and so we concluded that it's the problem, namely the positioning relative to the antenna model, not the devices used. We actually confirmed this conclusion. If you checked my system architecture, you'll see that there is 4 different areas linked by pair of antennas. The 3 areas aside from the CPU area have shorter antenna distances compared to the original CPU area. We took the CPU to that area to see what pairs are having problems, and voila, I can see both the gateway without PN comm. error on any of the 3 area/antenna pairs (and I've even cross checked the actual MODBUS power meters reading to the CPU). So our only problem now is the original CPU area wireless communication to the first gateway area. Probably the antenna pair will either be replaced by higher capacity or maybe install a bridging pair in between, if some adjustment, on software and physical, on the existing pair wouldn't do. Thanks for your response and link anyway sir fritz! |
| 12/23/2014 5:44 AM | |
|
Joined: 10/7/2005 Last visit: 11/14/2024 Posts: 3027 Rating:
|
Hello G_R_E_Y It is indeed in the HWconfig and to note is that each PN I/O devicecan have its own update time (unlike Profibus DP). Step 7 will calculate the update time for each PN I/O device for you and defaults to 2ms for smaller networks. Apart from being hard pressed to get a reliable 2ms update time via a wireless link, what also comes back to bite you is the Watchdog time which by default is 3 times the update time (or a mere 6ms in this case). Anyhow, attached is a pic to show you two ways how tofind and change the update time and everything else is in the previously listed links (I hope, if not revert back here). |
|
Cheers |
|
This contribution was helpful to
|
|
Follow us on