System Variable for Servos Ready

    Is there a system variable I can read to see if my robot is ready for motion? I've noticed that even after the robot "clicks in", there is often a short interval (a couple hundred milliseconds) between when the servos seem to engage and the robot can actually start moving. Our system streams positions for the robot to move to, and works really well except during that interval. What it looks like is happening is the servos engage, the motion program begins running and commanding positions, the robot receives those positions and "moves", but then doesn't actually, physically move for ~300ms. This wouldn't be a problem, but then it jumps to try to catch up to where it was expected to be after those 300ms before smoothly following the rest of the planned motion.


    This isn't an acceleration problem -- there are no issues starting the motion planner if the servos are already engaged, and we can mask this issue by adding an artificial "if the servos were off and just came on, wait half a second before streaming the path" to our planner's logic, but ideally we just want the robot to be able to signal that it is actually ready to receive motion commands.

    I would assume this is due to the brake release and servo power up. I recommend disabling the break off timer. That will keep the servos ready during wait conditions but will still require a time delay at the start of the program.

    I don't have the variable name you are seeking, however, I can add that the delay from servo off to ready to move includes the pre-charge of the DC bus on the servo amplifier. The 1st noise you hear is a contactor engaging the pre-charge current then flows, once pre-charge is complete the second contactor engages.

    Quote from Sergei Troizky

    Why do you need a system variable?

    The UO[2] "System ready" indicates exactly what you need.

    I was using UO[2]; unfortunately, UO[2] goes high a decent bit before the robot will respond to streamed positions, so I was hoping there was another value that I could read that signaled exactly when the robot would begin to respond to commanded motions. I reached out to Fanuc and got this from them:

    Quote from Fanuc Technical Support

    Normally for a newer robot controller of R-30iB or B Plus the servos will take about two seconds to fully recover from a "servo off event" before motion will occur. If the robot is just sitting still and after about 20 seconds with no command of motion then it will go into a "power save mode". Upon recovery from a power save mode will normally take a little over a second, about 1.5 seconds then motion will occur. You may use these times for your [application] to start the streaming process after stopped motion[.]

    It seems the official response is that no such value exists... the closest we can get is watching for SYSRDY and then waiting a second and a half :thinking_face:

    The thing is, it is ready to accept a motion command, it just takes time to respond. There is no way to get the servo fully energized besides commanding it to move. I would command it to move to the current position, Jpos, then wait, then start streaming. You can disable the idle brake timer so it won't go idle after 20 seconds. Then you only have to do the 1 second delay routine after a stop event. You could keep track of that in BG logic. I think the best way would to have the stream motion read then command jpos for the 1 second delay.

    How about tricking the robot into never stop moving in the first place ? Doing very small motion back and forth would prevent the robot from moving into a "servo off event" while looking like the robot is not actually moving ?

    Tricking it is not necessary. Just disable the brake timer and it will never go idle. That wouldn't help with an actual servo off event.


    A servo off event happens when there is an estop, fence stop, collision, or program end, etc. There is no way to keep it energized during a real servo off event thus the time delay method is needed.

    If the time delay method is fine for the application then go for it as it surely requires less work.

    However i'm only trying to find an alternative solution, purely for the sake of it.


    So to keep on building on top of HawkME remarks :

    Quote

    Tricking it is not necessary. Just disable the brake timer and it will never go idle. That wouldn't help with an actual servo off event.


    I was starting with the assumption that the brakes were disabled.



    Quote from HawkME

    A servo off event happens when there is an estop, fence stop, collision, or program end, etc

    Of course this will not prevent the servo from powering off in the event of an estop, errors and such, that is much certain since these mechanism exist precisely for that purpose. However my understanding of the application is only to prevent them from being off between motions.

    Thus that is where having something to keep the robot busy comes in, no need to stop the program then. Just go back and forth between following the streamed path and the "do not let the robot stop" routine.

    Just thought I'd throw in my 2 cents here.

    What HawkME and Sevastopol1 has mentioned is key here I think.

    This process that takes place between motion command request and actual motion and therefore this delay period will always exist.


    However, if you think about it, the brakes are in fact the last in the chain of events.

    Servo's must be running and error free in order for the brakes to be released - otherwise there is possibility of arm drop.

    Therefore, I would certainly be looking into the 'brakes' variables that are available to sniff at.


    In Kawasaki, they have a dedicated output called RGSO which is an indication that servo's are energised and brakes are released.

    Because even at zero motion request, the joints are being held in there current position.


    Could you use $MOR.$brk_status then.

    I am not 100% sure, but I think this turns to 1 when brakes are released, then with a servo off event, such as toggling of the teach switch then the brakes are re-applied and this status is then returned to 0.


    Certainly worth looking into......

    Aha! I wouldn't have thought of that, but it works perfectly! Thanks kwakisaki!

    So it works then.


    From Kawasaki perspective, when brakes are released, the robot itself is considered 'moving', even if no motion commanded value is received from a program, a motion command is received to retain it's current position - so it is moving, but stationary.


    So it was a little bit of a punt from my perspective as I myself am relatively new to Fanuc, but in my mind the order of events will be very similar if not identical.


    Glad it's worked for you though...………..Nice and good to know for the future.....:top:

Advertising from our partners