[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

[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)

[rdsi]

For the X & Y axis the homing routine backs away from the limit switch trip point 255 counts or 0.0255".

[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.

[rdsi]

Don't know why I didn't mention the Z axis but it also moves off the limit switch 255 counts or 0.0255". Tormach calls this a soft limit and the value is set in the "tormach_mill_base.ini" file as 0.025" but it really moves 0.0255". You can change this value for each axis as you like.

Since you mention the 4th axis there are some things I've discovered about it's operation.

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.

Also, the A axis PP DRO reads in degrees to 4 decimal places. Although you can step at this resolution PP only outputs a pulse to the driver every 20 steps for the 6" or 8" option, and every 35 steps for the 4" option. So depending on the selected option you really only get movement every 20 or 35 steps on the PP DRO. Just something to be aware of...

[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?

[rdsi]

I'm not sure that you need a control box. If you're using an active probe (NO) I think you can just mount multiple DIN connectors on the front panel wired in parallel. One each for your probe, ETS and A limit. Since they are all NO function it's like a wired OR function. The only caveat would be if the A axis is parked on the home switch such that the accessory LED is on. Then the probe and ETS would not do anything because the accessory line is already tripped. However, the A axis homing routine actually finds the trip point & then moves in a positive direction until it goes off and calls that homed. Now probing and the ETS will work. So you would just have dead zone where the A axis actually has the accessory line tripped. Probably most of the time it would not be a problem ...

[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.