[Greolt]

Sage

I am afraid you have totally confused me. Easy to do according to SWMBO.

Starting with incorrect dimensions and then trying to fix them with scaling and swapping base units is a recipe for mistakes IMHO.

I live in the 21st century and so therefore don't use medieval English measurements (that should get a few flames )

Those that do have to contend with files of two different base units, generally have an XML (profile) for each base unit and just start Mach with the appropriate one.

Have one profile called Inch and another called Metric. Easy to do and will only take a few minuets to set up.

Then each will need to have its own Auto Zero macro in the relevant units. Place the macro in the profile's macro folder and call it from the on screen button.

Greg

[neilw20]

Excellent advice.
Use two different XML files if you really must live in the past.
I think it is easier to enter 1.6 than 0.0625, imperial feed rates suck too.
I have imperial lathe and use it as metric. Just a bit hard doing metric threads.

[dsage]

All good advice guys but I guess I'm trying to point out a bug.

Maybe someone could try what I suggested.

In case I lost you:

It's not unreasonable to have a G21 in your code is it? The reason I got around to putting it there is irrelevant.

And I don't think it's un-reasonable to use the scaling DRO's to add some scaling is it? They put them there for a reason.

So. If someone could just try the G-code presented and put scaling of 4 on X and Y and 2.5 or so on Z you might see what I'm talking about.

I think the scaling is taking affect on the Tool Setter. Also I can't explain why the Z axis jerks down a bit before it goes up (dangerous when scaled up). That might be something I screwed up in the button code converting it.

Even if you do none of the above you might also see the tiny (part of a millimeter to you guys) jerk downward. I'd like to know. Watch carefully immediately after the tool setter stops.

Even if I take your suggestion and have two set ups I'd still have to have a different button script for the inch setup of the tool setter because the number in the script in millimeters when interpreted to inches is not reasonable.

BTW> I understand metric. I live in Canada. I use both.

Sage

[tassie]

This is just a quick thank you to Greg for the details of his Aussie Zero Tool and all the other posters who asked the questions I needed help with. I've made this tool for my K2CNC router table and it works SO well. I love that something so simple can make a job so easy!

Thanks again.

Philip
Tasmania

[Greolt]

And I don't think it's un-reasonable to use the scaling DRO's to add some scaling is it? They put them there for a reason.

.

When I first started using Mach I used scaling. I found at that time it was buggy. Now I just don't use it.

So. If someone could just try the G-code presented and put scaling of 4 on X and Y and 2.5 or so on Z you might see what I'm talking about.

I think the scaling is taking affect on the Tool Setter. Also I can't explain why the Z axis jerks down a bit before it goes up (dangerous when scaled up). That might be something I screwed up in the button code converting it.

.

Try taking the following lines out of the code,

ZProbePos = GetVar(2002) 'get the axact point the probe was hit
Code "G0 Z" &ZProbePos 'go back to that point, always a very small amount of overrun
While IsMoving ()
Wend

Even if you do none of the above you might also see the tiny (part of a millimeter to you guys) jerk downward. I'd like to know. Watch carefully immediately after the tool setter stops.

.

No my machine does a very small movement up.

Even if I take your suggestion and have two set ups I'd still have to have a different button script for the inch setup of the tool setter because the number in the script in millimeters when interpreted to inches is not reasonable.

.

That is the idea. You have a macro in each profiles macro folder that is for the relevant units. Much less mistake prone.

It would not surprise me at all if the scaling had a bug that upsets the macro. So if it is that or something else I really don't know.

Greg

[LeeWay]

That issue may be one of the way you have your machine setup. You may need to insure or change that part of the code to a negative or positive value. Opposite of the way you have it set now.
I do have this working on my desktop, but haven't tried it on my machines yet. Will do so when I find some time.

[dsage]

Thanks all.

I'll investigate it some more to see if I can figure out exactly what causes it. I'll be busy making chips for a while.

It continues to work fine without any scaling, although still with a very small jerk down (Maybe 1 or 2 thou) just after touching down. It's not a big deal. I can ignore it.

Thanks Greg.

Sage

[dsage]

Startling development today.
Other than the small qwerks I mentioned previously, the tool setter has been working fine. But today, I used the setter and on what was supposed to be the tool retract phase the machine Z-axis instead drove my 3/16 ball end mill practically right through the circuit board and it was backed by a solid piece of metal too. My Z-axis stepper has a lot of power so I now have a hole in the piece of touch circuit board and it's warped and will need replacement. I turned Mach off and back on to reset (whatever) and it works again. I'm very cautious about using it now and test it by holding the board above the work once to see if it behaves properly before using it properly. I have no idea what messed up the tool setter.
PS> previous to using the tool setter everyting was machining perfectly so there was nothing wrong with Mach itself or any of the settings (that I can figure anyway).

Any ideas what could casue this? Maybe some remnant G-code that didn't clear?


Sage

[bp092]

As a general rule of thumb I always test and contact the touch plate with the cutter to "green light" before doing it. It's a painless fast test that ensures it should work properly.

[jalessi]

Sage,

I did the same thing with the tool setter "ONCE".

I loaded a different screen to check it out and the tool setting macro was not in the screen I was experimenting with.

Needless to say my ignorance caused a $18.00 pyramid cutter to plunge right through the tool setter plate, instantly self destructing or should I say "Operator Inflicted Damage".

Jeff...

[neilw20]

Thumb in 8um. mind in neutral?

[dsage]

I did test the tool setter light first - always do. The light reacted properly.
This was a problem with the code associated with it (I assume) or some other G-code that was laying around which could affect it.
I do a lot of program editing and testing and stop programs mid stream quite a bit after checking code edits to see if they work.
I'm wondering if the code associated with the tool setter can be improved by saving all possible G-codes used by - or that could affect the tool setter - making them safe values appropriate for the tool setter and then restoring the previous setting back after the tool set.
Having said that I have no idea what errant G-code could have caused the tool setter to do a G-zero down 60thou instead of up.

From now on I'm going to have to use it twice. Once in mid air well above the part, and if it reacts properly then I'll put the plate down on the part.

A shame though.

Sage

[Glidergider]

Your problem sounds like a Mach3 problem. Sometimes when rebooting Mach3, it will forget which Macro the button is supposed to run. Lucky me, I've never had a problem that you've had. After a re-boot of Mach3, I always check my custom macros.

In my macro, I changed the Z downward feed rate to a real slow value. Once or twice, I've forgot to plug in my router, which negates the ground. On these occasions that I reminisce, I also forgot to test the continuity. So you know what happens then. Lucky for me, I have a real low feed rate in the macro. I can feel the pressure starting to mount before any damage can be done. I quickly hit the escape key to stop any damage. So, consider slowing down the z feed rate in your macro.

[jalessi]

Sage,

The tool setter led will always light when there is continuity between the plate and the tool, it has nothing to do with the distance between the tool and Z Zero.

How would the LED know the plate thickness if the tool macro was incorrect?

Just because the LED lights does not mean the tool setter is operating correctly!

I am being repetitious and its intentional, if you load a different screen using Mach Loader or choose a screen that does not have the correct tool macro data or the generic tool setter macro data there is a very good chance the tool will crash.

The reason why is because the generic macro is telling the Z axis to travel ... a certain distance.

It would be nice to hear from other Mach3 users to see if they have ever encountered what you are talking about.

Jeff...

[neilw20]

If you have stopped a program part way through Mach3 could be in some unexpected state.

For example,
It could be in incremental mode.
It may have been doing an arc or circle, and G2 or G3 are in effect.
Drill cycles may been interrupted and a G80 is required to cancel G8x mode.
If you Mach3 is likely to be in some unexpected state, you must either run a small program to make sure the state is well defined, or the Macro must check all possible rogue conditions and at least do nothing other than warn you if all is not well.

At the start of a program it is good practice to set all modal states to a known condition.
Initialize all variables used. #123 MAY HAVE BEEN ZERO, but may have some other value now because any previously run program may have changed it. The variable is persistent.
I turned my machine off after running a program successfully all day.
The last program run was aborted because I was cutting air. Variable #123 had a non zero value now.

The next day the program run nicely until after the first pass around a job, dodging the mounting bolts in it's normal spectacular manner.
Next pass around at 400mm/min the $60 carbide cutter unscrewed a mounting bolt in a spectacular manner, and the cutter evaporated.
The cause was #123 had not been initialized to zero at the start of the program. Normally it was set to zero as the program ended.

Expensive lesson, and had to wait for a new cutter to arrive.

A good well behaved program macro will save all states it changes, set all states to it's requirements, and at the end restore the states to the original.

Back to your problem...

Because the macro must cause a Z move by it's nature, there should be sufficient safeguards written into the macro to prevent stupid move.
Also this macro cannot restore everything to what it was because it's purpose is to move to a new position. It is the responsibility of the macro to ensure it can execute correctly, and if you make a habit of leaving things in undefined states, then you must improve the macro.

[Greolt]

I have been using this device for about a year and a half and have never had it fail. Except when using the NCpod but that is another story.

However Neil has a valid argument. It is hard to anticipate every condition it could possibly be called from.

How about placing this line in the macro as a preamble,

Code " G21 G17 G49 G50 G80 G90 "

The G21 would be G20 if using medieval english measurements.

G90 is not necessary in my script but does no harm.

Greg

[dsage]

I would have to agree (and have already stated) that the macro needs to save the current conditions for those Items it intends to use, set them to appropriate values, execute it's function and then put the conditions back where it found them. I do a lot of micro processor programming and this is standard programming procedure for an interrupt procedure (to push and pop the stack), which is essentially what you have here

I agree it might have gotten screwed up by killing a program mid stream. But who's to say the tool setter can't be used after stopping a program. I do a lot of dry runs on programs with the cutter retracted to be sure they work properly for the first (of many passes) then stop the program and reset the axis to start again. I don't think that's unreasonable.

Maybe someone can suggest a way to press a button to reset all of stuff to safe values.

I guess I could put some pre-amble at the beginning of every program to do that initializing, then have an M1 to pause the program for a manual Z-axis calibration before continuing.


Sage

[neilw20]

I knew the RESET (screen) BUTTON had a use. Add all the default settings to the button VB code for that button. Just have to figure how to patch into it.
Might be easier to use some other button.

[Greolt]

The reset already has that option on the General Config page. See pic

Personally I'm happy with the operation and reliability of the macro as is. But that's me.

Greg

[dsage]

Greg:

I must have missed somewhere how you got the tool setter macro to run from a shuttle pro button. Could you explain please. (The shuttle pro is fantastic as is your tool setter)

Thanks

Sage