Deactivate outputs when communication lost with I/O-device

s084706

Hi all,

I have a question about a problem that I have with an I/O-module and the door lock connected to this module.
Sometimes I have a 'communication lost with I/O-device', when this occurs I can't unlock the doorlock (the door was already locked when the communication is lost). This gives me the issue that I can't send a 'unlock door'-command to the I/O-device and so to the door. I still have to find what causes this 'communication lost'-problem, but for the future, just to make sure, I want to know if there is a way to deactivate the outputs when the communication is lost again. The door is 'power to lock' so if the communication is lost, I want to deactivate the output of the lock.

Thanks in advance, guys!!

s084706

lemster68

Change the wiring of the lock so that if power is lost it will unlock.  Designs should always be such that they will "fail to safe" condition.

s084706

lemster68 said:

Change the wiring of the lock so that if power is lost it will unlock.  Designs should always be such that they will "fail to safe" condition.

Hi Lemster68,

when we lose power the door unlocks.
The door doesn’t unlock when we lose the communication between controller and I/O-device.
For some reason the device remembers his current state even if the connection is lost. It looks like the output is remanent in a way.
That’s why I want to know if there is a way to set this I/O-device to it’s initial state when the communication is lost. I suppose this can be done in the parameters?
Device:
ABB DSQC 1030 with a Ethernet connection.

s084706

lemster68

OK, I think I got it now.  Look up EIO_SIGNAL_SAFELEVEL in the system parameter manual.  I think you want to use it to define the unlock on and Lock off when communication is restored.  Have you any other IO units available?

s084706

Indeed that’s what I was thinking also, but somebody said this was wrong. This controller, correct me if I’m wrong, looks at the state when the connection is active again (so after the connection was lost), but as long as there is no connection the robot, can’t say to the device to set this signal back to it’s initial value. So from the moment the connection is back ‘on’ the signal is set to it’s initial value again, but this is too late and the doorlock keeps locked during the disconnected phase.
The way I see it: this parameter is seen from the robot perspective, but as long as there is no communication there is no way the robot can ever know the real value of the output present on the I/O-device. So no change of this signal because the robot just can’t reach it.
I hope I explained it clear enough? I don’t know how to say it otherwise.

daynejackson

Hey man, I’m a little late to the party here, but I have a question for you! Unfortunately, I don’t have an answer to your issue, but I have a question of my own that maybe you can help me with! I see that you were getting the issue with the no contact with I/O device. I’m currently having this issue. Did you ever determine what was causing that for you? We have watched network traffic, nothing. Replaced profinet cables, nothing. Just can’t seem to find the problem. It’s only happening on 7th axis robots, and also only on startups after a weekend. Any help would be appreciated!!!!

j_proulxFB

I have the same problem with loss of IO connection. I assumed it has to do with CPU load but since there are others with the same issue it may be a RobotWare issue. I am using Ethernet IP communications.