Functional Safety Unit Question

Hi guys

I will would be interested in some comments referencing the below image.

The yellow circled is a range limit set as an outside zone with a 15mmx10mm polygon.

This is to offer some protection around a specific area.

The green arrows show the intended path - similar to a palletizing application where you approach at a diagonal to the target drop position.

The motion is interrupted with an alarm as it is approaching the red circled position, which can be reset and then the robot continues to move to the position and carries on with no further issues.

Can anyone try and explain just why I am receiving this alarm when clearly 'U' axis is no where near the interference zone and in fact 'L' axis is always closer instead?

The point is that the FSU really is proving to be unusable and pointless to integrate in the most basic way.

I would really be interested in any comments or feel free to ask any questions.

Anything would be very much appreciated as I am down to my last strand of hair and I would really like to keep this in view of cloning technologies becoming available before I die....

The only way I can I run this without alarms is at a reduced speed, so it is obviously some sort of estimation.

Any pointers on whether I can 'tap' into this - Parameter Number perhaps?

Many thanks for your reply.

Tool interference is set (long green bubble coming from the flange) at the TCP.

In fact what I have since discovered is the 'U' axis alarm is pointing to 'model operation3' in Motosim which is the bubble that encompasses the 'L' axis, so the alarm reference is correct.

The issue is, I need to protect this joint from colliding with the fixture between the U and L axis.

I have only found 2 ways I can get this 2 work:

a. Slow the robot down (which is a massive reduction from 100% (full tilt) to a crawl of 10%.

b. Lower the area to near the floor (which is a country mile from the physical area).

Due to all this, I am assuming Yaskawa is Stop Category 1 out of the box and not adjustable.

Would you happen to know if my assumption is correct?

ljuba

I see Stop Category 0 in Motosim and it's all greyed out, I don't see any reference to stop category in the manuals or on the teach pendant.

I am assuming my problem is down to speed and distance predictability caused by stop category 1, so if I could just set that area for stop category 0, I could prove my theory.

Please explain more if you can.........

I shall have a look into this a little later, but looks very promising indeed.

Many thanks indeed, appreciate your advice......

Hmmmmm.......very interesting.

All I have done is allocated an FSBOUT no. in the file parameters and without setting anything further, I can nearly achieve my full range of motion.

I cannot believe just leaving out an allocated FSBOUT allocation would make it react in such a way.....but I think it is also proving my theory that this is stop category 1 straight out of the box.

I need to do some further testing, but this is 100% improvement and gives me a clear pathway to further develop this and I've only just tested this in MotoSim, so if this is replicated on the live robot, then the beers are on me my friend.

You are a legend ljuba, I can't thank you enough for your assistance in this and other areas too....

Thank you for your reply.

Quote from WattUp

I always programmed them to be my desired limit only to find out that in AUTO, the robot stopped far short of those limits.

This is a big issue as you cannot sufficiently and accurately protect the environment for manual and auto operations due to the speed differential.

As cells are being designed much smaller there is no tolerance to easily implement FSU with how Yaskawa have integrated the options.

In teach, you can set it quite accurately, although through testing, I have found you can only get to within approx 20mm of that limit.

In auto at full tilt there is a huge amount of 'air' between the monitored arm segments and tool interference which is too over protective and prevents you even visiting your programmed points.

Adding way points and reducing speeds should not need to be implemented.

You should not have to program around the FSU, the FSU is supposed to police your application, not the other way around.

In my case, way points and speed reduction is not an option.

The predictive function, and arm bubbles should be modifiable to allow more precise monitoring.

There should be features to differentiate between manual and auto modes for monitoring too.