Power off the drive motors.

[droter]

Is there a way to power off the drive motors when the arm is not in motion?

Similar to this issue to power off the drives on connection loss.
#18 (comment)

[gavanderhoorn]

No, that's not supported by fanuc_driver, nor fanuc_driver_exp.

To be honest I'm not sure this would be possible. Or at least, not without either stopping the (main) program, or generating some kind of fault.

On Fanuc controllers, drive power is turned on as part of the system enabling procedure (ie: resetting errors and depressing the deadman switch when in manual mode). There isn't really a way to start programs without the controller doing that for you (well, there is, but it's not something used by regular users of the driver).

AFAIK, any program which locks (a) motion group(s) would result in drive power being enabled as part of the startup procedure. And it would probably only be turned off when entering power save mode (after sufficient nr of idle seconds), an (motion system) error being posted or a deliberate action by the operator (like turning on the TP in AUTO, although that would also lead to an error, so perhaps is the same as the previous condition).

[gavanderhoorn]

Perhaps if you could describe what you're trying to achieve -- or why you'd like to remove power to the drives -- we could determine whether there'd be a way to do what you ask.

[droter]

Okay. That make sense. Thanks for thinking this through.

The use case would be to prevent unintended motion. The arm would not be used for periods of time but would still need to be under programmatic control. The idea would be to get it into a safe state while it is not in active use.

[gavanderhoorn]

The use case would be to prevent unintended motion. The arm would not be used for periods of time but would still need to be under programmatic control

could you clarify what "under programmatic control" would be?

Both fanuc_driver as well as fanuc_driver_exp only really 'control' motion. If there is no motion for (extended) periods of time, I would suggest to just stop the TP programs running on the controller.

I would expect a system configured for more than just a quick test to have some kind of remote coordination interface set up (ie: a fieldbus to remotely control cycle-start, etc). If that's the case, you're likely already starting and stopping the TP program(s) using that interface. It would then make sense to me to use that same interface to simply pause the main ROS TP program, which would immediately cause RobotStatus::motion_possible to become FALSE, and would cause any trajectories submitted to not be executed (note: not rejected, things will likely just hang. At least without ros-industrial/industrial_core#271).

Whenever you need to continue motion control, (re)start the ROS TP program and things should just work again.

Stopping the program would likely result in (eventual) drive powerdown as well. Or you could force it by making one of the involved signals low.

Note: you'd not be stopping the Karel programs. Or at least, I'd recommend not doing that. Without ROS_STATE running, no RobotStatus messages would be published any more, nor any JointStates. Seeing as ROS_STATE is not involved in motion execution at all, you'd typically want to keep that running continuously, and only moderate access to motion services by coordinating ROS_RELAY (or ROS_TRAJ with fanuc_driver_exp).

The idea would be to get it into a safe state while it is not in active use.

So I have to add here: doing any of the above would not get you "into a safe state". Or at least not anything safety rated.

If that is really your concern, I'd suggest looking into setting up DCS, perhaps with a Cartesian or Joint velocity check and some suitably defined volumes. Trigger/(dis|en)able those using some safety input and connect that to another suitable safety system (a mat, a scanner, fence, anything).

You could still do what I wrote above, but that would just be something to be "nice" to the ROS application, such that it can be aware of what's going on.

Pedantic -- of course -- but: do not use fanuc_driver or fanuc_driver_exp, or ROS in any way for anything which should be safety rated.