StopMove overloads motor

AlwaysBeBootin

Hi all,

I'm working on implementing a trap routine to stop movement of a MU300 mechanical unit controlling an indexing door if the safety area scanner is tripped. I was successfully able to set up the interrupt and trap routine as such:

            ! Enable interrupt from safety scanner

            IDelete irIndexBlocked;

            CONNECT irIndexBlocked WITH tIndexFault;

            ISignalDI SAFE_TO_ROTATE,0,irIndexBlocked;

            ! Proceed with rotating indexing door

            SetGO goLoadedStation,0;

            IndAMove Indexer,1\ToAbsNum:=180,nIndexerSpeed\Ramp:=nIndexerRamp;

            WaitUntil IndInpos(Indexer,1)=TRUE;

            ! Disable interrupt from safety scanner

            IDelete irIndexBlocked;

    TRAP tIndexFault

        Reset doIndexerReady;

        StopMove;

        WaitUntil SAFE_TO_ROTATE=1 AND doIndexerReady=1 \MaxTime:=60

                                                        \Visualize

                                                        \Header:="Indexing Door Working Area Not Clear"

                                                        \MsgArray:=["Waiting for Area Clear Signal","And Indexer Ready checked on HMI"]

                                                        \Icon:=iconWarning;

        StartMove;

    ERROR

        IF ERRNO=ERR_WAIT_MAXTIME THEN

            UIMsgBox

            \Header:="Please clear indexer area",

            "Exceeded 60s while waiting for indexer area to be all clear."

            \MsgLine2:="Clear the indexer area and click OK when ready."

            \Buttons:=btnOK

            \Icon:=iconError;

            RETRY;

        ENDIF

    ENDTRAP

However when the trap executes and the StopMove command runs, it tries to stop the door as fast as possible, which is overloading the motor (there is a lot of mass on this door). This also happens even when I program the IndAMove to go as slow as 1 deg/s, which is a snail's pace.

Is there any way that I can control how quickly StopMove will ramp the speed down to a stop? I ran the Signal Analyzer, and it appears the motor is spiking to over 4000W when it's trying to stop. The stress duty cycle for this motor is currently set to 471.2 speed absolute max and 17.5 torque absolute max, which I think is the default for an MU300. I see there is also a "Max Overload Time" of 0.5 under Supervision Type.

Thanks,
Jeff

lemster68

I hate to tell you this, but having to rely on the robot program is not acceptable.  You need some safety rated relays, at a minimum, tied from the scanner to the robot runchain.  Is there a safety PLC in this cel?

AlwaysBeBootin

Good afternoon Lee,

I definitely agree with you, and I'm actually pursuing that solution with the cell manufacturer as well at the same time. There is a PLC that handles all of the cell signals; however, I do not have access to it to understand its logic. Right now, the cell manufacturer just has it set up as a digital input to the robot and nothing else. The trap routine is mostly just to keep it "as safe as I can" until the proper solution is implemented and we're actually ready for production.

Now that you mention that, though, this could still be a good learning opportunity for me on proper practices. Would there be a way to tie the safety scanner to the robot runchain only during certain moments, as if when I'm about to rotate the door? Under normal circumstances, the door is sealed, and the robot is able to move, regardless of whether the safety scanner is tripped or not. Only when the door is about to index is when the safety scanner should break the robot runchain. (Think like a pallet changer on a horizontal mill)

What are your thoughts? I appreciate any help. Thanks!

lemster68

Do you activate and deactivate that mechanical unit to move it?  There would be an activation relay which you might put into series somehow with scanner and runchain.  Still, maybe kind of sketchy, though.

matti

Hallo, there is a hardware-option 1313-1 axis selector, which does this. In contains an additional contactor to separate the drive from the controller in case of manual loading of an manipulator, turning table or similar. If you follow the circuit diagram 3HAC039887-001 it can be done by yourself.

AlwaysBeBootin

We do activate and deactivate that mechanical unit, and we also have the axis selector option. Would it be feasible enough to have a cross connection to the activation relay, or should this be solved purely electrically?

For the cross connection, I'd need some logic to only shut off the activation relay when desired - i.e. the door is about to rotate. We do have a door position sensor, so I could do something like:

Resultant: doACT_K1
Actor: diDoorInPos AND diSafeToRotate

I'd have to think more on which signals need to be inverted, but I think something like that would work.

What do you guys think?

lemster68

It seemed strange to me that it overloads despite the fact that you are not using the optional argument /Quick.  That made me wonder if you have run the LoadID for the manipulator, ManLoadID.

matti

Stop and QuickStop keeps the manipulator on path( which is not necessary when in safety violation), therefore the axis will deaccelerate coordinated. Both stops can be activated using a system input, parameter action. The manual says explicitly that one should not use that for personal safety. 

Is there a way to include the safety scanner into the run-chain or emergency off?

The manipulated device will stop with a servo and mechanical sequence but might loose path position, so a restart (PP to main, Start) is required.

Best solution is quite likely SafeMove option.

AlwaysBeBootin

Thank you for pointing out the ManLoadID routine, I tried using that today, however I kept getting a "LoadID Error: Load Identification is not available for this robot type". This is a custom solution using MU300 motors (but very closely resembles an IRBP B250), so I tried using the IRBP_C_INDEX. I will probably need to look closely at the MOC file for a IRBP C indexer and maybe try to trick it into thinking it has one so I can run the load identification.

I have not had a chance yet to try the cross connection to the activation relay, but that will be my next step. One flaw I noticed with the door in position sensor is it falsely triggers while rotating, so I need to either relocate it or get one with a shorter sensing distance.

I did some research into the SafeMove option, and that would likely be the cleanest solution. If I'm un-succcessful with the activation relay, then I will get a quote for that and go down that route. It's not necessary to regain path position, so I'm not worried about having to PP to main either.

Thank you all for your help!

lemster68

You are welcome.  I had encountered that same error before too.  If that in position sensor goes to the robot, look into filter active setting for that input.