Does anyone can give an example of how variable “release output” should work?
From the document, I can see this sentence:
The restart interlock, which interferes in many cases because it is already applied in SafeDESIGNER, is no longer available. Starting with mapp Safety, a restart interlock after a safety request must always be configured in SafeDESIGNER in an application. The available functions of the PLCopen library can be used to do this, for example.
According to the state diagram it should be sufficiant to set ReleaseOutput any time after startup (to be precise: any time after SafeModuleOk of the specific output module became SAFETRUE).
Because with the rising edge of ReleaseOutput it will leave the LOCK state.
And in case that SafeModuleOk gets lost for some reason (e.g. part of the machine temporarily powered off) it will need another rising edge of ReleaseOutput.
I’m not sure just doing an rising edge of “SafeModuleOK” is good enough for a safety program. If every scenario can just handle by “SafeModuleOK”, I think B&R can do it in firmware instead of provide extra variable to let user program the rising edge. What is the real reason behind this?
I was referring to the state LOCK(0x3) where it will wait after SafeModuleOK got true.
Then it needs a rising edge of ReleaseOutput to get to the state OUTPUT_DISABLE(0x4).
There are cases like e.g. a temporary network problem which will be caught by the LOCK step. Because after recovering from such a temporary network problem (= SafeModuleOK changes from false to true again) it would enter state LOCK_ERROR(0x5) to prevent unexpected switching on (in the case that DigitalOutput, SafeDigitalOutput and ReleaseOutput are still all true).
In case you get to the state HW_ERROR(0xA) it doesn’t seem to be related to ReleaseOutput. But there should be a logger message with further information.
PS.: maybe I should point out that the state will always be resetted to DISABLED(0x0) whenever SafeModuleOK is not true.
If HW_ERROR(0xA) never happened, why it is exists? By the way, I think document does not state exactly what kind of scenarios can make it jumps into the state.
If some how this HW_ERROR happened, I think it is not good for me to tell my customer to reboot the machine to make it work again.
I agree with you that the document doesn’t exactly state what “HwError” means.
Usually it can be wiring problems like short circuits - see this table for a channel type specific list of detected error cases.
There will be logger messages in those cases
…I also agree to that and I think this leads to the general topic of error handling which can be very application specific. It may depend on the machine’s HMI and even on the expected skills of the operator or on-site service personnel.
Unfortunately I don’t know what would be something like “best practice” for that but there may be other people in the community who do.
And this general topic is actually not specific to Safety because there may also be errors in other components of the machine. So maybe it could be a good idea to post a new question about general best practice of error handling.
