Puma 560 simulation using pumakins

I don't think there is an index... and if there were... it would pulse once per revolution. The trick is getting one, and only one logic state change across the entire range of travel. If it had an index... then the output from the circuit above and the index pulse could be routed through an AND gate... the unit would detect a high at any point where the index pule AND the circuit pulse were both high. This would occur at specific intervals all across the upper band. You would need to drive the PUMA to a point where the first signal was NOT high, then start moving forward until both outputs went high the first time.

Getting LinuxCNC set up to do that would be problematic... at least I think so. An alternative would be to set the circuit level at the very high end... near the end of travel. It would detect the AND signal... then the INI file would direct it to back off by a specified amount.

Not sure if that level of complexity would be required... although now I may have to find out. The folks who have been using my PUMA the last 6 months are returning it today... apparently the controller has now failed. If so... the cost to get it repaired would be several times the cost of building a new controller. Part of me is looking forward to that challenge... part of me wishes that the original controller and the VAL command structure were still intact. On the bright side... I may be able to replace a 70 pound noisy controller with a 15 pound quiet one. (When I can afford the 6 drivers to do so.)

Hi Jerry and Andy,

very good thoughts about the homing.
First, yes the encoders do have index signals.
Best would be to do the homing similar to the original controller combining the potentiometers with the index signals at each join.
The advantage is that it can home with a very small travel at any position. But this could get a bit tricky. Most probably I have to add some coding / modification to the Linuxcnc because it would be a non-standard homing procedure. This is still an option because in the meanwhile I have set up my development envirnoment and could modify the standard code.
Maybe I will start with a standard homing using a similar schema you line out above and then later switch to a more advanced without the need to do a longer distance travel to the home position. You know these travel can often cause collisions in the working space of a 6 axis machine.
Concerning the hardware I'm currently in favor of using an Arduino instead of a discrete comparator / OP Amp with a 10 turn precision poti and and AND gate.
An Arduino Nano is much cheaper (>3 EUR) and much easier to use. It comes with >6 A/D input (for the poti signal) and >6 digital inputs for the index signal. I can easily program the arduino at any position so it creates an output for the parport to simulate a home switch.
The original Puma controller works with a translation table that assigns to various joint positions an index position and a poti value so it can home at each index signal. This is generated during the potcal procedure. I could do the same and store it into the Arduino if I implement the final solution. The arduino could transfer the joint position to the linuxcnc. But this would require more input wires than I do not have with the current 6 axis setup at one parport. Most probably I would use the Arduino USB connection to transfer the position.
For now I could start with the easy solution having a fixed home position what I can easily change in the arduino software.

Now you are onto something... but you are making it much more difficult than needed... you don't need to modify the LinuxCNC routines or anything like that... for some reason, I didn't even think about an external microprocessor... ugg.

What you want to do is set the Arduino up as a "switch server"... have it look at the A/D position and the Index Signal. It will then evaluate the pulses and the A/D, and only send out a logic LOW when the correct conditions are met.

In normal LinuxCNC homing, if it gets a LOW, it considers that the limit/home switch is tripped and moves in one direction initially... if on the other hand the signal is HIGH... it moves in the opposite direction until the signal goes low... then begins the sequence of backing off, etc.

So the Arduino looks at the AD signal and if above a certain set point, sends a HIGH constantly, if below a certain set point, it sends a LOW continuously. Within a very specific range, it will toggle between the high and low ONLY when the INDEX is also present. This way, LinuxCNC will ONLY see the toggle point at a very limited point on the travel. An Arduino (or other micro) can do this across 6 axis several hundred times per second... so there would be no issue with the LinuxCNC reading the "home switch" output from the Arduino. At other times (normal use) this signal is simply ignored... the Arduino would continue to do what it does... but no action would be taken by the PC.

Upon a HOME command, LinuxCNC would evaluate the current state and act accordingly. And... as a bonus... you can programmatically set the exact trip points to fine-tune the home position to within any single INDEX point desired.

Hi Jerry,

thanks for detailing this out.
The complication with the code modification in LinuxCNC would only be needed in case I want to have it similar to the original controller that can home at any position of the arm with only a very little travel and not going a full travel to a single home position.
The way you describe it is the "easy" way with a single home position per joint (only disadvantage is a possible collison in the work space).
But as said I will start with the easy way first that do not require a code modification and can work with the standard home procedure.
One thing I'm not 100% clear about is the limited number of feedback lines I have with one parport. Since I'm using a 6 axis control 12 wires/lines are already in use. There are only a few ones left (max. 5) for feedback to LinuxCNC. I need to think about how I can use them efficiently for homing 6 axis.

Thomas

I made a chart to better show the timing...



To answer your question, likely you will need to add a second parallel port to get the proper number of input ports. Or you would need to migrate to a MESA card. Adding a second printer port is really cheap... I get them here in Austin for $10 to $15 typically, PCI style... 5 minutes to install.

Suggested Pin Assignments: askjerry.info/CNC/PUMA_PARPORT_Pin_Assignments.xls

The Spreadsheet above assumes that you would use a StainSmart Breakout Board... they are very easy to implement.
Jerry

thanks Jerry for the timing diagram.
For me personally there is the issue that I want to use a Thinkpad with my Puma and no desktop PC. Unfortunately there is only one parport to and no easy option to extend with a second port. Portability is one of my major requirements and this is not easy to achieve with a desktop PC. Maybe I will check for a PCMCIA2Parport card.
I guess 6 feedback wires is the minimum you would need for the homing you have in mind.
Another option for me is to go to the more sophisticated homing where I use the USB port in addition. Via parport I would only transfer the realtime signal of "index is hit". Via USB I could tranfer control data (e.g. what axis is currently homed) and back the poti A/D converted signal. In this case I would store the potcal table (which poti values correspond to which approx. position and what is the corresponding index position). I would then home each axis after another with a small travel to the next index signal for this axis. Then reading out the poti digital value and translate with the potcal table to the exact position. But this is a non-standard homing procedure would require add. code.
Does anybody know where to intervene in the LinuxCNC code to get this implemented?
Not sure if this really makes much sense or if it would be easier to get a second partport card via PCMCIA running on the Thinkpad? Currently I'm not in favor of switching to a desktop because I have quite some Thinkpads and I love especially the 10year+ R50P which the 1600x1200 flexview.