I wonder about the customer claimed restart-szenario of the PN communication under a S7. Trying to reconstruct the system running a ctrlX-PLC-codesys PN-Controller "emulation" does not lead to the same behaviour.... But I saw the following reaction at least once but can not reproduce anymore. - S7 - PN - ctrlX-PNDevice(by codesys lib) exchanging prozessdata. - ctrlx PLC switched to STOP : S7 Controller detects Fehler: IO-Datenausfall in HW-Komponente/ Failure,Error: IO Data miss. in HW comp. - trying to restart the ctrlX-PLC does not reactivate/reestablish the data-exchange with the S7. Reactivating the communication is possible by reset-cold/reset-origin. Emulation the S7 with another ctrlX-PLC running the Codesys PN-Scanner Stack reacts different. Start and Stop of the PN Device is possible. The PN Controller detects the "inactive/unavailable/passive" PN-Device and labels the Communication-state with Bad-by-Device instead of Good. I wonder about the communication states taking place in background since the S7 PN Controller seems to operate different than the codesys-PLC based emulation. Activating the prozessdata comm to the Codesys-provide PN Device with former reset-cold/origin and reset of vars is something to consider about. Does anybody know how to identify/run diagnosis provided by CAA_Device_Diagnose libs. even on the PNController side for test-purposes? Other libs providing diagnosis support? Thanks! My expectation for the szenario would be: Device-PLC is running process-data exchange. Stop of Device-PLC ... data transfer stop ... since the PLC is not running, clear. Trigger RUN of the Device-PLC again.... should lead to: a) data transfer start immediatley (like in my testcase happening mostly) b) diagnosis on PN-device-side able to identify the comm-state and triggers the restart again without making a resetcold/origin necessary. Any experience / hints / workarounds / examples. Thanks!
... View more
