Navigation
Ethernet communication problems with CPU 317-2PNDP
Created by: TEBANCH at: 9/20/2011 10:04 PM (10 Replies)
Rating 
Thanks 7
| 9/20/2011 10:04 PM | |
Joined: 3/25/2008 Last visit: 1/28/2022 Posts: 232 Rating:
|
Hello dear colleagues. I will try to explain my problem as best as i can: I have a CPU 317-2PNDP (6ES7317-2EK14-0AB0), which firmware version is V3.2.3, this CPU is used to control 2 cameras (Cognex cameras); the communication between the CPU and the cameras isdone througth Ethernet TCP-IPprotocol, and for that we use the PN port of the CPU (we do not use any CP). We have an special FB(FB172) that takes care to send and receive information to/from the cameras, FB172/DB172 for camera 1 and FB172/DB173 for camera 2 (one FB172 call for each camera);FB172 calls internally the following Siemens standar Blocks: FB65 TCON, SFB4 TON, FB63 TSEND, FB64TRCV, andFB66 TDISCON. The problem is that we are only able to get communication with one camera at the time, what i mean is if camera 1 is online then is not posible to get camera 2 online at the same time and also if camera 2 is online then is not posible to get camera online. We have to mention that this functionality was achieved in a previous aplication that actually is working at this time, but for that "old" machine, the CPU version used was CPU 317-2PNDP (6ES7317-2EK13-0AB0) with firmware version V2.6, what i mean is that FB172 (with out modifications) is working pretty good with 2 cameras in a older CPU version. I did one test justreplacing the actual CPU 6ES7317-2EK14-0AB0, with an old one6ES7317-2EK13-0AB0; and under those conditions all is working ok 1. Is it posible that the new System Functions included in the newfirmware version of the CPU are the problem. 2. Since the logic/program works ok in the old CPU, what should i look for in order to solve this problem? 3. What are your general suggestions in this matter? I will apreciate any suggestions or tips you can provide me, attached you will find FB172. Thanks all you for your help, and have a very nice day. AttachmentFB172.zip (276 Downloads) |
|
Keep working! |
|
| 9/22/2011 3:33 PM | |
Joined: 10/7/2005 Last visit: 3/20/2025 Posts: 3042 Rating:
|
Hello TEBANCH interesting problem you've come across I must say and I'm afraid to say that all I can offer arequestions and things to try, so here it comes: 1.)Can you confirm that it is exactly the same program that you've tried in both CPU's? 2.) Can you confirm that - as you stated -definetely call each FB172 with its own Instance DB? (FB172 does NOT appear to be Multi instance capable) 3.) Is there any chance that you have used up all connection resources on the CPU? (I doubt it, but can you check and/or disable other programmed communciation jobs for a test). 4.) The connection UDT is embedded as a STAT in FB172 and may perhaps contains its UDT defaults instead of the correct values for each of the two (different) connections (in which case both calls would try to establish a connection to the same camera so it doesn't fully explain what you observe but worthwhile checking anyhow). 5.) Can you provide us with the whole FB172 related project for both connections (the source doesn't compile all that well due to the missing UDT, renumbered FB's and missing symbol declaration etc.) Alternatively,send it outwith a Support request to Siemens and let us know about the outcome. I hope this helps and pelase let us know what you find. |
|
Cheers |
|
This contribution was helpful to
|
|
| 9/26/2011 4:13 PM | |
|
Joined: 3/25/2008 Last visit: 1/28/2022 Posts: 232 Rating:
|
Hello Kaulquappeand fritz. Thanks a lot for your answers in response to your suggestions: Dear Kaulquappe: 1. Do you get any error message of the T-blocks or does TCON just remain BUSY=1 and STATUS=7002? Answer: I will check for this information as soon as i change the PLC, because right now i'm comissioning the station using the older CPU. 2. To analyse the differences I recommend to trace the communiction of both CPU types with wireshark and to compare them. Answer: I will try, however, i do not know 100% what to look for, would you please explain a little bit more? 3. Do you use the latest version 2.4 of TCON? I recommend that. Answer: I'm ussing V2.3, that is the version inside my librarys, by the way my software version is Step 7 V5.4 SP4, do you know where i can obtain the new version V2.4? Dear fritz: 1. Can you confirm that it is exactly the same program that you've tried in both CPU's? Answer: Yes it is the same, there are some diferences but they are related to motion control sequences. 2. Can you confirm that - as you stated -definetely call each FB172 with its own Instance DB? (FB172 does NOT appear to be Multi instance capable). Answer: Yes, in the attached program you will find FB172 called at FC172 with instance DB172 and at FC173 with instance DB173. Please check NW 5 in FB172 it is quite strange, because it makes reference to FB172, instead to a Stat variable or a DIB DIW or DID. But even so, the program works Ok in old CPU version. 3. Is there any chance that you have used up all connection resources on the CPU? (I doubt it, but can you check and/or disable other programmed communciation jobs for a test). Answer: I wil check, but right now i only have comunication services to the 2 cameras, one HMI, a partner PLC, and my computer, all this throught ethernet. 4The connection UDT is embedded as a STAT in FB172 and may perhaps contains its UDT defaults instead of the correct values for each of the two (different) connections (in which case both calls would try to establish a connection to the same camera so it doesn't fully explain what you observe but worthwhile checking anyhow). Answer: I will check. 5Can you provide us with the whole FB172 related project for both connections (the source doesn't compile all that well due to the missing UDT, renumbered FB's and missing symbol declaration etc.). Alternatively,send it outwith a Support request to Siemens and let us know about the outcome. Answer: I will attach it. Once again thanks a lot for your help, attached you will find the program that is running at this moment on the machine, this is the program version for the Old CPU type, if you want to have the program for the new CPU please let me know. Have a great day. Attachment3033_470_Old_CPU.zip (233 Downloads) |
|
Keep working! |
|
This contribution was helpful to
|
|
| 9/27/2011 2:20 PM | |
|
Joined: 10/7/2005 Last visit: 3/20/2025 Posts: 3042 Rating:
|
Hello TEBANCH that FB172 is certainly quite a "beast" and you are correct, there are flaws in NW 5 which should be corrected to make it truly reuseable. Attached is a pic of it which shows the direct IDB access (DB172 in this case) that needs to be replaced with the corresponding STAT variable. Saying that, the initial values of these variables are fortunately correct for your 317 based application,which means that the second FB172 call (with DB173 as the IDB) will work even though the FB writes into the wrong DB (or in other words, this FB172 bug does NOT explain your problem, but should be corrected nonetheless). As for the embedded connection UDT, FC172/173 (ref NW4) seem to do all the required presetting of values in DB172/DB173 (other connection related setup values are also preset inside FB172 as per screendump, so this is a bit of wild mix and does not make theverificationof the open IE connection setup any easier). In light of this I suggest you go with Kaulquappe's advise andgrab the latestversions of the blocks (download SP5) and test them to begin with, following by a Wireshark trace should this NOTfix it. |
|
Cheers |
|
This contribution was helpful to
|
|
| 9/28/2011 3:54 PM | |
|
Joined: 3/25/2008 Last visit: 1/28/2022 Posts: 232 Rating:
|
Hello dear Kaulquappeand fritz. First to all i wish to thank you for your usefull posts, and in second place i have some informationto share with you, what i have found so far based on your suggestions: 1. Ihave updated FB65 TCON to the newst version 2.4; andafter that i re-build FB172, and i transform it to FB100 for camera 1 and FB101 for camera 2.; for this i have created UDT100 for connections parameters of camera 1 and UDT101 for connection parameters of camera 2. 2. I have corrected NW5 address acces, no more DB172 reference there, just STAT variables. 3. I have tested this new logic and the results are the same with the new CPU version, i have done 2 tests, one using FB100-DB100-UDT100-FC172 for camera 1 and FB101-DB101-UDT101-FC173 for camera 2; and other using the multi-instace method FB100-DB100-UDT100-FC172 for camera 1 and FB100-DB101-UDT100-FC173, and the results are the same; the status word of FB65 in both instances is HEX7000 and error bit off. 4. I have done 4 captures in wireshark capture 1 isabout new CPU and when camera 1 is online, second isabout new CPU and camera 2 online, third one is about old CPU version and cameras 1&2 online, fourth isa second capture of Old CPU andcameras 1&2 online. For those captures the IP's are: PLC--->10.32.37.141 My Computer--->10.32.37.233Cam1--->10.32.37.143 Cam2--->10.32.37.144 Beckoff PC--->10.32.37.142. The filter i have used is: host 10.32.37.141. and not host 10.32.37.233 or host 10.32.37.143 or host 10.32.37.144. 5. As you will see in the captures for new CPU,there is not any atempt to conect to camera 2 when camera 1 is online; and in reverse the PLC do not send any telegram to camera 1 if camera 2 is already online, for the Old PLC you will se it is sending telegrams to both cameras. 6. I have confirmed yesterday that the PLC is sendig information to our partner PLC using TCP-IP protocol, FB173 is used for that (FC93). Today i will do some more tests, i will modify the values off UDT100 and UDT101, do you think perhaps that's the problem? If so, why the old PLC is not affected by that? Once again thanks a lot for your help, any other advice you can provide will be very helpfull. Have a great day. AttachmentWireSharkF.zip (248 Downloads) |
|
Keep working! |
|
| 10/5/2011 5:06 PM | |
|
Joined: 3/25/2008 Last visit: 1/28/2022 Posts: 232 Rating:
|
Dear Kaulquappe, thanks a lot for your answer. I have to clarify that the traces for "New CPU" shows the comunication "packets" when both cameras are configured, programmed and connected to the PLC, so in the trace called "NewPLC_Cam1" is shown the PLC behaviur with both cammeras configured, but as you can see, the PLC only recognices one cammera. In the trace called "NewPLC_Cam2" is shown the PLC behaviur with both cammeras configured, but as you can see, the PLC only recognices cammera 2. How thePLC swithchfrom Cam1 to Cam2? Well, i do not know exactly how this happens, what i can tell is if you stop the PLC and re-start it, some times if Cam1was recognicedbefore stopping the PLC, after re-start it will recognize Cam2 and Cam1 will not work; and in reverse way if Cam2was recognicedbefore stopping the PLC, after re-start it will recognize Cam1 and Cam2 will not work. Some times is enough to just download the Instance DB's of the 2 cameras. I will try to take new traces to catch the first packets as soon as the PLC goes to RUN. I have done some other tests, one of them was to just bulid a simple logic using only FB65 TCON, just to check if the New PLC was able to entablish communication to one single cammera, what i found is that the PLC was not able to even get online with the cammera (for this test i deleted 100% PLC and also y restored it to factory defaults). What i found was for FB 65, Status-->802A and error bit-->ON, from theonline helpthis error code means: "Local or remote port is occupied by the system"; i change port number in a wide randomrange from 2000 dec to 4000, and all the time the status was the same!, i have to mention that every time i change port number i also stop PLC and download all the program. Attached you will find this simple program, would you please have a look and let me know if i'mdoing something wrong? Once again thanks a lot for your help, and have a great day! AttachmentTestcoms.zip (236 Downloads) |
|
Keep working! |
|
Follow us on