Homing Changes

[ally-g]

Does anyone know if the homing routines have changed between PP ver 1.9 and 2.0.

After updating to 2.0 the homing is consistent but seems to be in a different place as my work piece offsets in all my programs are out by between 0.3 and 0.4mm from what they used to be in X Y and Z axis.I could try reinstalling ver 1.9 and see if they revert back to where they were but thought maybe someone else had encountered this.

Thanks - Ian

Similar Threads:

• Homing with X and A
• Homing
• Need Help!- Homing.. need help please
• Need Help!- Fanuc O-MD Homing problems Y Axis-Power up/ False Home/Slow homing
• Re-Homing

[rowbare]

Did you verify the probe setup after you switched to 2.0? Effective diameter, calibration etc... Depending on how you did the upgrade, those values could have been lost.

bob

[jwatte]

I think they're talking about the homing switches, not the probe?

[ally-g]

Yes I am talking about the way it homes.I put a dial gauge on the Z axis to check consistency (and it is remarkably good) and it jumps quite a way off the switch to its homed position and thought maybe something was different in the way it goes about this.
If I put the new figure in my programs everything works as it should and the new home position has not changed at all but I was curious as to why this has happened.

[old-cnc-geek]

From the PathPilot 2.0.0 release notes PDF. The values below are in inches. I think this explains the behavior you're observing.

* Reference offset increased from 0.010 to 0.025 to reduce chances of 'on limit error' when machine powers on (PP-1661)

[ally-g]

Thank you old-cnc-geek I think that looks to be exactly what has happened.
If you home the machine and then establish a reference point each time then it does not really matter but as I have the 4th axis at a fixed position on the table and write offsets in the programs it has caused some head scratching.
rdsi I have only monitored the Z axis and it looks to jump more than that,I will have to check.

[ally-g]

Because I do not use the 4th axis in the vertical position I have a homing setup permanently mounted on the end face using an inductive proximity switch and the accuracy is acceptable for what I do.
When setting things up with a dti I had noticed you have to move the jog wheel quite a way between actual steps.
I still have PP 1.9 setup on an old desktop,I will have to compare files now I know where to look - thanks

[ally-g]

If I was to make changes to the ini file would they be permanent or would they get overwritten in an update.

[old-cnc-geek]

New PathPilot versions use new ini files that don't include your change.

[kstrauss]

First, it does not have a limit switch because it's considered limitless due to it's rotary motion. When referencing or homing the A axis (the "REF A" button in PP) all that occurs is the G53 parameter for the A axis is zeroed. However, there is an optional homing switch P/N 31921 that can be used to home the A axis using the accessory input. This option can be enabled by ticking the PP settings menu option: "4th Axis Homing" box. PP does not use soft limits on the A axis so the homing routine settles on the homing switch trip point.

I am making a control box so that I can leave both the probe and ETS permanently connected. It seems a nice idea to also accommodate the 4th axis homing switch (P/N 31921). Does the homing switch work as a normally closed or as a normally open contact?

[ally-g]

The problem with leaving the homing connected is it trips every time it goes past it.

[kstrauss]

I omitted details of my in progress control box:
I hate having a cable to the probe so the box will be half of a wireless link using a pair of tiny 2.4GHz nodes (nRF24L01A). Both my probe and ETS use NC contacts so wire-OR is not applicable. One side of the probe and the ETS connects to ground so I can't simply put them in series.

The problem with leaving the homing connected is it trips every time it goes past it.

I'm obviously missing something. Does the tripped probe affect anything other than G38.x moves?

[jwatte]

the box will be half of a wireless link using a pair of tiny 2.4GHz nodes

Beware of latency! I've used those before. Not only is it big enough to be measurable, but it is also somewhat jittery. An analog carrier on a narrow 900 MHz or 2.4 GHz frequency might actually be better (but harder to get parts for.)

Does the tripped probe affect anything other than G38.x moves?

Whenever you jog, if the accessory input gets triggered, it will abort the jog, assuming that you're about to crash a probe tip.

[kstrauss]

Latency has been a concern for me. Checking things with the scope the latency on my toy is about 650 µsec with jitter of about 100 µsec. I have a watchdog timer to report a probe trip if the wireless signal is lost for longer than 5 msec. Unless I've made an error (quite likely) at 20 ipm the probe moves about 0.0003 inches per msec. If I fast probe at 20 ipm and then slow probe at 2 ipm the latency should not be measurable. At least that is my assumption.

I haven't tested and it is too cold to go to the shop tonight but will try things tomorrow. My probe is NC. Does PP abort a jog when the probe goes from closed to open? Otherwise how does it distinguish no probe from a probe trip?

[mountaindew]

The problem with leaving the homing connected is it trips every time it goes past it.

I have experimented with homing and my cam software code. Found no real way to make it useful. I ended up just using basic math to unwind axis code and return to a0. I concluded it was maybe more useful for 4 axis work that is manually coded and indexed to a given feature or radial limit.

[kstrauss]

I haven't tested and it is too cold to go to the shop tonight but will try things tomorrow. My probe is NC. Does PP abort a jog when the probe goes from closed to open? Otherwise how does it distinguish no probe from a probe trip?

As promised I did some testing this morning and things work differently from my memory of past behaviour.

With PP 2.1.6 it appears that a change of state of the probe during an operator controlled move causes the move to abort. That is, when a passive probe changes from closed to open or when an active probe changes from open to closed the move is aborted. This behaviour is the same whether the move is requested with the pendant or with a G0 entered from the MDI. However, probe trips during g0/g1 moves when running a program *DO NOT* abort the move!

[jwatte]

Otherwise how does it distinguish no probe from a probe trip?

You configure the software with whether you have a probe, and if so if it's NO or NC, so it knows what to do.

[ally-g]

I have one of keen's excellent probes so just swap between that and the 4th homing and try to remember to pull the plug out when I have finished.

I too love to tinker but am very handicapped by a lack of linux knowledge.I did compare 1.9 and 2.0 ini files and sure enough that 0.015 difference explains a lot.