Puma 560 simulation using pumakins

My take on this is that AXIS can be configured to allow it to run G-Code without being homed.

[TRAJ]
NO_FORCE_HOMING = 1

This means that (in theory) the same pins that are used as HOME switches could be read as an input... and that G-Code could interact with them. This G-Code could do some pre-work to get the system near the home points ready for actual homing... then terminate.

The user would then click the "HOME ALL" button in AXIS which would run each joint to the nearest position where the INDEX is read as HOME.

I have somewhat of an idea how to accomplish this... but frankly to pull it all off is still above my level of expertise.

HOME INFO: linuxcnc.org/docs/html/config/ini_homing.html#_home

For anyone else interested in getting a PUMA back online... I scanned the wire lists from my PUMA manual into a PDF.

Here is a link to the file: PUMA MOTOR WIRE LIST

Hopefully someone will find it useful.
Jerry

I was thinking about the homing on the PUMA... today it dawned on me that there is a variable resistor (potentiometer) attached to each motor. If this resistor was given a reference voltage and ground... the output would vary from the reference (VCC) to 0 (GND). The trick is to detect only a single point.

Using a 741 OP AMP IC, you can accomplish this fairly quickly.


So if you use this circuit... then attach the output to an OPTO-ISOLATOR with the appropriate resistor... for example a 4N35 IC... then you get a HIGH for anything above the set point, and a LOW for anything below that point... just like you would get from a HOME switch.





You then could replace one of the fixed resistors in the voltage divider with a 10-turn potentiometer... and really fine-tune the HOME position. Or... you could see where it stops... and just set the offset in the INI file.

In any event... it should work very well.
Thoughts?
Jerry

Askjerry wrote: Thoughts?

If you derived the V-ref from a PWM signal then you can measure the actual position, possibly to within one encoder revolution.

(This is just a roundabout way to do analogue input with a digital output)

You would only need one V-ref and a comparator for each joint.

The motors have a quadrature encoder which is very accurate. You only need to find a home reference for LinuxCNC to be able to use it's homing routines. Unlike a typical milling machine which has limit switches or a home switch, the PUMA does not have that feature.

In the original controller, it had an analog to digital card that read the position, calibrated it, and moved to home... then it used the quadrature encoders. The issue wasn't getting accurate positioning data... it was finding that one location for home... without needing to modify the PUMA.

I think this would accomplish that goal... the machine would move to that location and LinuxCNC would see it as a switch tripping... which would allow normal homing activity.

if the motors have quadrature , then does it have index also ? or only a,b
then use index for homing , ( sometimes it may mean rotating the body of the encoder to match the home position )
then count the index rotation