Start with a kuka Robot

Quote from wag_FFU

yes, It was a strange and old teach pendant with the triangular shape buttons key, I worked on that robot only for 2 hours 10..12 years ago. The robot movement where terrible, klunky and with a lot of acceleration/deceleration between the points with no reason.

Not surprising, considering that series of robots ended production... 40 years ago? I'm frankly amazed any of them are still in operation.

Quote from wag_FFU

Or there is a list where I can write my point name and the robot will automatically compare with the current robot position? And yes, Fanuc has it.. but where are speaking about Kuka.

The various Home positions and $IN_HOME signals are the closest equivalent KUKA has to the Fanuc RefPos. The tolerance band for each is adjusted using the $H_AXIS_TOL variables.

You can't change the names of the Home positions, but if you look inside the template PTP HOME inline form, you'll see the line $H_POS=XHOME. XHOME is a teachable point, while $H_POS is the actual system variable that the robot's position is checked against in realtime. So there's nothing stopping you from adding code somewhere (in the INI Fold of your programs, or in your SPS) that would do something like $AXIS_HOME[1]=MyPosVariable. Just arrange the code such that if/when MyPosVariable is touched up, the AXIS_HOME variable is updated before you rely on the $IN_HOME1 status variable.

You can also use the Workspaces in the KRC (Axis or Cartesian), and those can be dynamically adjusted by your program.

Quote from wag_FFU

40 years ago? Are you kidding me? That thing belong to a museum!

The KRC32 was obsoleted by the KRC1 around 1990, so... maybe 34-35 years, instead of 40.

They built them like tanks in those days. Industrial hardware in general tends to get used for very long periods of time, unless it completely falls apart. There's an entire industry devoted to refurbishing and maintaining of older robots. As long as you can scavenge enough parts to keep them going, and find someone who knows how, someone will buy them.

Quote from wag_FFU

I read in the forum than someone has used the $Move_Enable to stop the program execution and restart the movement , and the program, with the $Ext_Start input. Is that a good idea? Or is better to use the interrupts? Thanks

Either way works. Personally, I prefer not to use Interrupts for things that don't require the special capabilities of Interrupts. There's also other ways, like having the SPS monitor a signal and firing the CWRITE $CMD STOP command, which would halt the program without generating the error messages that dropping $MOVE_ENABLE would.

It really depends on exactly what you're trying to accomplish. Safety stops should be handled through E-Stop or Operator Safety inputs. If you expect your program to need to pause often, then using WAITs in the program is better than halting the program. $MOVE_ENABLE is a bit brute force, but I've used it for collision prevention between robots (as a final safety net if the normal zone handshakes somehow fail). If you need the robot to stop quickly without tripping a Safety Stop, then using an Interrupt with BRAKE or BRAKE F may be what you need.

Quote from wag_FFU

`the Move enable cause an immediate stop or a controlled stop?

I believe it's a controlled Category 2 stop, possibly Cat 1. Of course, "controlled" stops aren't always fully, depending on the robot's speed, inertia, and payload at the moment the stop occurred. That's part of what $NEAR_POSRET is about.

that is part not worded clearly in the system variable manual...

the description assumes that robot controlled by PLC is in EXT mode... which is why the start in mentioned situation would also be an external start.

Quote from wag_FFU

With CMD is possibile tos elect, stop a,d deseletc a program, but the robot need §ext start to execute/resume the program?

KUKA has two automatic modes: AUT and EXT. AUT is "local" auto, where you can only control fault reset, motors on/off, start/stop from the SmartPad. No external signals can control these operations.

EXT is exactly the opposite -- the SmartPad controls for fault reset, motors, and start are disabled (stop still works, though). Instead, they are controlled only from $INs, which are usually mapped to PLC I/O or to I/O modules linked to pushbuttons.

Oddly enough, there's no external "stop" signal equivalent to $EXT_START. I guess KUKA expected people to use $MOVE_ENABLE, $DRIVES_OFF, or just programmatic WAITs/HALTs.