PLC faults out for communication with profinet connected devices

Please add both pictures to a .zip archive and upload.  The posted images are blocked (at least for me).

What is in the PLC diagnostics buffer about the fault?  By fault, do you mean it generates a diag buffer entry, or the PLC goes to STOP?

If the PLC goes to STOP, have you considered adding a diagnostic error interrupt OB to your PLC project?

I too have some non-Siemens ethernet connected controls devices in portal projects with similar issues.  If we connect to these special controllers using their native software, the controllers stop talking to anything else.

Luckily, in our case, the system designers thought about this better than your situation because whatever communicates with these controllers first after power up retains the right to communicate with them until the controller power cycles.

In your case, it sounds like the Camera software takes over and shuts down external communications like Profinet.

Check with the manufacturer's support site to see what configuration options are available so they can share or at least have similar behave as described above to prevent unintended loss of PN comms.

Pandher36

Hi All, 

I am working on 1 project where we are using  Siemens S7-1200  PLC and it is connected with 3 Siemens Servos, 1 HMI , 1 IO Module and 4 Keyence Cameras through profinet. PLC faults out when I try to connect with any of Keyence cameras through Keyence IV Navigator software to check camera images or result values. Fault is related to losing communication with 4Keyence Cameras and Siemens IO Module. PLC cycle time is set to 200ms. Any idea, What should I check for or make changes to fix this issue ? Please check attached pictures. 

That would depend on the physical topology (wiring).

In a star topology (everything home-runs to a central network switch), there should not a problem with one device knocking other devices offline.

In a daisy-chain device to device wiring scheme, let's say 10 devices all linked together with the PLC as the 1st device in the chain. 

Now let's say device #5 in the chain suddenly stops being a Profinet device and stops forwarding PN packets for downstream devices.  Now devices 6-10 will show as offline.

I'd say stop connecting with the navigator software during any mission critical times, or at least in a daisy-chain type topology, make all devices impacted by the navigator software the last ones in the daisy-chain - and of course check for devices being online before attempting to read/write to their I/O - to prevent IO Access errors.

I have a block call in my code for every remote I/O device that determines if the device is accessible and sets a global DB tag.  If it is offline, it resets it.  I have a couple of user constants in the PLC tag table, ONLINE : BOOL = TRUE, and OFFLINE : BOOL = FALSE.  That allows for comparisons like "IF DeviceName.IO_Device_xxx = ONLINE THEN ... and access I/O related to that device.  Or, I put all the I/O accessing in a block in LAD and the first network simply does a RET (return) if the hardware IO device is OFFLINE.

That prevents a lot of diag buffer error entries for IO access errors.

It also allows handling of PN faults within the PLC logic rather than potentially requiring a plc stop / start to recover when there is no error-handling and recovery logic built in.

Pandher36

Please check attached picture in .zip.

It does not stops PLC, but gives a alarms that IO devices watch dog timer expired. It faults out for 5 devices (4 Keyence Cameras and 1 Siemens ET200SP). I was assuming same thing that Keyence software is taking over the cameras and causing comm error, what how could it will faults out with other devices which I am not trying not connect.