Skip to Content

SiePortal

The integrated platform for your product selection, buying and support workflow - bringing together Industry Mall and Online Support.

SiePortalDeutsch

Search

Home
Support Support
{{(apiData.Support | filter:{'rank':1}:true)[0].title}} Support
- Menu temporary not available
- Menu temporary not available
- Menue temporary not available
- {{item.title}}

Products & Services
- Menu temporary not available
- Menue temporary not available
- {{item.title}}
Support Support
{{(apiData.Support | filter:{'rank':1}:true)[0].title}} Support
- Menu temporary not available
- Menue temporary not available
- {{item.title}}
MySiePortal MySiePortal
{{(apiData.MySiePortal | filter:{'rank':1}:true)[0].title}} MySiePortal
- Menu temporary not available
- Menue temporary not available
- {{item.title}}
Cart ({{apiData.CartCount}})

Navigation

BUSF LED Flashing

Created by: Vinny at: 6/4/2010 3:36 PM (9 Replies)

Rating (0)

Thanks 1

10 Entries

6/4/2010 3:36 PM	Rate (0)
Vinny Posts: 35 Rating: (0)	Hello Siemens Friends, I am trying to communicate between two CPU 315-2 DP controllers via CP 342-5 on both ends. 1) I've established connection between the two CPs but I've got the "BUSF" LED flashing on both CPs. 2) Also, "SF" and "SF DP" LEDs are lit on both the controllers. I believe the communication between the controllers is not happening because of these two reasons. Can someone please point me in the right direction? Thanks.
Vinny Posts: 35 Rating: (0)
Suggestion To thank Quote Answer

6/4/2010 4:23 PM	Rate (0)
Fatso Bronze Member Joined: 9/11/2006 Last visit: 3/17/2022 Posts: 168 Rating: (6)	Hi have a look at the diagnostic buffer to see exactly what the problem is ,maybe you can post your diagnostic buffer on the forum

Suggestion To thank Quote Answer

6/4/2010 4:48 PM	Rate (0)
Vinny Posts: 35 Rating: (0)	Hi Fatso, I tried to post my diagnostics, but the forum says there is an error. So I will write down what the error message says. In master CP: "The slave is not polled by its own master" In slave CP: "Slave waiting for parameter assignment/configuration of the DP master" Any help is much appreciated. My thinking is, when I download the HW to master saying there is a slave, it (Master) starts polling but doesn't see the slave because I haven't yet downloaded the HW to the slave. When I go back to the slave and download the HW, I think the master doesn't poll since it is in fault mode. I might be wrong but if this is the case how would I get around it. All suggestions are welcome. if this is not the case what might be the problem. Thanks in advance.
Vinny Posts: 35 Rating: (0)
Suggestion To thank Quote Answer

6/4/2010 6:00 PM	Rate (0)
dchartier Grandmaster-Expert Joined: 9/27/2006 Last visit: 3/26/2025 Posts: 12344 Rating: (2707)	Hello Vinny; As you will see in the following FAQ, the trick is configuring the slave first (both CPUs belonging to the same Step 7 project); this creates a specific CP 342-5 slave in the Profibus catalog of the HWConfig editor of Step 7, as a Configured Station. When you configure the master, you connect this specific CP 342-5 slave to the master's Profibus line.Communications are then easily started up. http://support.automation.siemens.com/WW/view/en/6518937 Look at the sequence of configuration presented here, it should clear things up for you. Hope this helps, Daniel Chartier

Suggestion To thank Quote Answer
This contribution was helpful to 1 thankful Users how come

6/7/2010 12:07 PM	Rate (0)
Vinny Posts: 35 Rating: (0)	Hello Siemens friends, Thanks Daniel. I did configure the slave first and then the master as done in the example. But it still complains and the BUSF LED is flashing. Current status is as follows: 1) BUSF flashing on both CPs. 2) SF DP lit on both CPUs 315-2 DP I've checked my Profibus cable and it works fine. The interesting thing is I've got error message "8184" in the DP_STATUS of the DP_SEND and DP_RECV of the software in both the master and slave CP. I know "8184" says "system error" or "illegal parameter type". Anybody has come across this before or knows what it means, please let me know. Cheers....
Vinny Posts: 35 Rating: (0)
Suggestion To thank Quote Answer

6/7/2010 3:31 PM	Rate (0)
Vinny Posts: 35 Rating: (0)	All sorted now. I didn't understand technically what was wrong but persistence helped. A pointer reference wasn't used in FC1 (DP_SEND) and FC2 (DP_RECV) where the data source and destination area is mentioned. Direct memory area was used (like MD10 instead of P#M10.0 byte 4). How that stopped the BUSF LED flashing, I don't know. Only Siemens PLC knows about it. SF DP still lit, not sure what it means. Doesn't affect so doesn't matter. Cheers for all help.
Vinny Posts: 35 Rating: (0)
Suggestion To thank Quote Answer

6/7/2010 4:27 PM	Rate (0)
dchartier Grandmaster-Expert Joined: 9/27/2006 Last visit: 3/26/2025 Posts: 12344 Rating: (2707)	Vinny All sorted now. I didn't understand technically what was wrong but persistence helped. A pointer reference wasn't used in FC1 (DP_SEND) and FC2 (DP_RECV) where the data source and destination area is mentioned. Direct memory area was used (like MD10 instead of P#M10.0 byte 4). How that stopped the BUSF LED flashing, I don't know. Only Siemens PLC knows about it. SF DP still lit, not sure what it means. Doesn't affect so doesn't matter. Cheers for all help. Hello Vinny; Do you mean you removed the ANY pointer, replacing it with an absolute address, and it worked? That would hold true on;ly if the data area you were using held exactly 4 bytes (MDxx contains 4 bytes), as I understand things.It would not work with any other size of data exchange. Strange, in any case. have a look at the following FAQ, with an extract that covers your last statement: http://support.automation.siemens.com/WW/view/en/18208090 Parameterizing the "SEND" and "RECV" inputs For the "SEND" parameter you specify the data area which contains the data to be transferred to the slaves. Here you specify just the data source. The reverse holds for the "RECV" parameter. Here you specify only the area where the data from the slaves is to be stored. How the data then gets to the I/O or is read from there is explained in section 5. The "SEND" and "RECV" parameters require a pointer to be specified in the "ANY" format (e.g. "P#DB1.DBX3.0 BYTE 37"). In this example the pointer points to bit 0 in byte 3 of data block DB1. BYTE 37" specifies the length in bytes of the data field to be transferred. The "ANY" format permits in principle other length specifications. However, for the "DP_SEND" and DP_RECV" functions you must specify in bytes. Aha! Examine section 5 of the suggested FAQ, and see how the data from the slaves needs to be addressed from the CP 342-5 functions. And you really should open the CPU diagnostics buffer and look at the reasons that you still have diagnostic LEDs. A SF means something in your code or addressing is not correct. which might lead your program to take decisions on erroneous data. We can help you evaluate the contents of the buffer (save it aa a .txt file, and zip it, if it is too large to copy/paste). Hope this helps, Daniel Chartier

Suggestion To thank Quote Answer

6/7/2010 11:03 PM	Rate (0)
Hulzhex Gold Member Joined: 8/25/2005 Last visit: 3/21/2025 Posts: 1162 Rating: (111)	Hello Vinny, if your problem still exist, please make some screenshots of the FC's, Hardwareconfiguration and the digostic information of the CP's. Have you seen this examples? Quick Start CP342-5 Hope this will be helpfull. Good luck Sabine

Suggestion To thank Quote Answer

6/8/2010 1:37 PM	Rate (0)
Vinny Posts: 35 Rating: (0)	Hi Daniel and Hulzhex, I think I created some confusion. What sorted my problem is when I used pointer format instead of absolute address. When I used absolute address (MD4) it complained. When I changed it to pointer format (P#M4.0 byte 4) it worked. It basically fixed the BUSF LED flashing. How it relates to the BUSF, I still don't know. Even stranger is the fact that when I changed it back to absolute addressing (MD 4), it didn't work as expected but BUSF was not flashing anymore. A bit inconsistent results. My diagnostic LED SF DP is lit (it doesn't affect me and I can turn it OFF if I want). Thats because it is not seeing profibus network in its DP port since I am using CP communication. The light dissappears if I change the HW config to say there is a DP profibus network (even if there isn't one) and download it to the controller. If the controller once had a DP profibus network HW downloaded to it then it always expect to see it or it will turn SF DP LED on. I hope I didn't create more confusion. Cheers.
Vinny Posts: 35 Rating: (0)
Suggestion To thank Quote Answer

6/8/2010 4:14 PM	Rate (0)
Hulzhex Gold Member Joined: 8/25/2005 Last visit: 3/21/2025 Posts: 1162 Rating: (111)	Hello Vinny, Vinny Even stranger is the fact that when I changed it back to absolute addressing (MD 4), it didn't work as expected but BUSF was not flashing anymore. A bit inconsistent results. The DP master at the CP starts when he got the first data from the CPU. So the first successfull DP_RECV is importand. After that this FC only is needed to transfer new data from the CPU to the CP. The CP didn't get the information that the FC isn't called correctly. So the communication is still running. So now I think everything is going well If there are any further questions please post again. Best regard Sabine

Suggestion To thank Quote Answer

|

Share this page:

Share this page on...

Follow us on