I notice your trust in the LCCF CIP Client block somehow figuring out the server IP by itself.

Without a tag of IPv4 datatype at the block's input for ServerIP, how will the block ever know where to send your request(s)?

Your issue is completely different than the original poster's.  I suggested splitting your issue as a separate topic.

Try reading the block documentation for parameters again and provide the correct IP for your CIP server. 

That said, perform every step in section 5 of the LCCF CIP Client .pdf document found on the same URL you downloaded the library / sample application:
https://support.industry.siemens.com/cs/document/109782317

Piteu125

Hi all,

I am facing the same issue. I am using the blocks provided by Siemens (CIP Client – exchanging process data with third party control systems - ID: 109782317 - Industry Support Siemens) in TIA V17 and a 1517F CPU.

This is my sequence of events:

1. Running: With status = 7002. Valid = 1, Busy = 1, Error = 0.
2. Comms failure. Ex: Rockwell plc went into stop or disconnection of the Ethernet cable between them. After a timeout, status = 7003, LCCF_CipClient still does not return an error.
3. After another timeout, Status = 8401 and LCCF_CipClient returns an error
   

Rockwell PLC running again back (or communication back)

To try to reset the error:

1. Drop the enable to the block. The status = 7004 and 8602, error = TRUE.
2. Set the enable TRUE again. Status = 7004 and 8602 error = TRUE
3. Stop the Siemens CPU and start it again (status 7000) = error = FALSE, valid = FALSE, busy = FALSE
4. Positive edge of the enable then comms established again. That sets de status to 7002 with no ERROR and with tag quality BAD, and after a timeout status 7003 with no ERROR and with tag quality BAD and after another timeout status 7002 again with no ERROR and finally with tag quality GOOD.

The main issue is to have to restart the Siemens PLC in all the scenarios that I could create. I have attached a picture of what the LCCF_CipClient looks like in a normal good operation

According to the S7-1200/1500 Programming and Style Guide (by Siemens), you should not directly access instance DB tags.  Use the block instance parameters (unless specifically recommended by the library / block author(s)).

Why are you not monitoring the block outputs with tags for valid, done, error, busy, diagnostic?

Add tags for those (not temp tags either).  Then you can actually see what the block is able to tell you and make adjustments.

Piteu125

Hi 0_Einstein.

Thanks for your reply

I feel both scenarios are the same as we both have the same problem the Siemens CPU needs to be restarted once there is an issue with the Rockwell PLC or its comms

The IP in the program example is being set in the rung before the call please see image attached. It could be done differently but this is the way is set in the example and I have not change it

Thanks

Most TIA Portal library blocks built using FBs (and have static memory) tend to require the ENABLE input be ON 100% of the time the block is needed (typically).

Instead, look for what the block does when the remote device goes away and then comes back.  Then create detection handling logic to track the status of the connected device - capturing the status values and their meaning in the current context.

Then your PLC logic can infer the state of the connection and wait for the remote device to come back online, or attempt reconnection every so often if the block requires that.

EiH1

I have the same problem. Using TIA V16 and the communication with Rockwell PLC works fine. When the Rockwell PLC is switched off or the ethernet cable is disconnected then the LCFF_CIPClient function block goes to error. When connection is ok and the Rockwell PLC is running, the LFFC_CIPClient function block the Status change from 7004 to 8602 and back again. When the enable from the function block is changed from TRUE to FALSE and back to TRUE nothing happens. The only way to get the LFFC_CIPClient function block to run again is to set the PLC to STOP and then switch it back to RUN. After that the communication works again.

It cannot be that a PLC in a productive system has to be stopped and restarted so that the data exchange with another system works again. Please find a practicable solution as soon as possible.