HIYA Ian, Nope no really interested I stop all mach3 testing a good while back. I dabble a little here and there but that is it. If Mach3 is not going to change any no point in working on solutions.

That is why all the test notes went bye bye.

(;-) TP

But I am SURE every one is interested in what you found including me. (;-)  Also it LOOKS as if letting the G28.1 event set the home offset of the switch may work instead of using the G92 to correct the switch offsetting. I will have to try it on the plasma next week.

(;-) TP

Ian, you are such a tease 

But in my defence I would offer two things to the prosecution... (i.e. Terry)

1) I DID say back in reply #45 that THERE IS a way to do this. i.e. Not IS THERE a way to do this? I thought you'd picked up on that.

2) I thought you would enjoy the challenge.

3) I think it's fair to say that you've (in your words) "yanked my chain" plenty and will no doubt continue to do so  so...

Anyway - here's the deal. Simples really (G31 type TOM as an example)

1) get your CAM to output #1000=31 in the init section.
2) say your current TOM probe output is like

G31 Z-1

instead, get your cam to output it like

G#1001 Z-1

Now arrange for #1000 to be copied into #1001 when you're running and when you do a RFH arrange for 1 to be copied into #1001. So a run does what it says on the tin - but a RFH doesn't process G31 it processes G1 instead - which it handles fine.

You can do this in various ways - ONE way is to add code to your cycle start button

setVar(1001, getVar(1000))
doOEMBUTTON(1000)

and your RFH button

setVar(1001, 1)
doOEMButton(1016)

That's the basics of all it is really - which you could play around with if you're interested (oh sorry - you're not  )

DISCLAIMER: I make no claim that this will sort all RFH bugs out. It solved the problem (for me) that you raised in reply #43. YMMV. Do I use it much? not really.

Cheers

Ian

Ahh - I think I understand (perhaps) 

Thanks for the explanation Ian.

Tweakie.

ARE you SURE (;-) ? Something seems off. IF your Cam adds in the #1000 =31 in the preamble of the program Then #1000 gets set to 31 at program load.

When you press RFH and inside of that button you reset #1000 =1 it resets the #1000 to 1

BUT when the RFH preruns the Gcode modes it will SEE the initial call of #1000 =31 and set it BACK to 31.

YES??  NO??

I WILL give it a try next week when I get BACK to the shop.

Using the G28.1 and adding in an offset internally(home offset)  seems to work as well BUT I will have to try it as well.

(;-)TP

ARE you SURE (;-) ? Something seems off. IF your Cam adds in the #1000 =31 in the preamble of the program Then #1000 gets set to 31 at program load.

When you press RFH and inside of that button you reset #1000 =1 it resets the #1000 to 1

BUT when the RFH preruns the Gcode modes it will SEE the initial call of #1000 =31 and set it BACK to 31.

YES??  NO??

that would be YES - I am sure and a NO - the buttons don't write to 1000 anywhere

The 1000 var never changes, what it's set to by your CAM post stays. It just tells the button code which of 31/28.1 to use. I COULD have hard coded (say) 31 into the cycle start button, but that would mean you'd have to change the code in the button if you wanted to use 28.1 instead. By putting 31 or 28.1 into 1000 and copying that in the button instead, it means the same button code will work for either. Simples.

OK some further testing here . Here is a typical TOM routine commonly used

G28.1 Z0.500         (Run the G28 to find the top of material)
G92 Z0.00              (Set the the Z to zero)
G0 Z 0.120             (Move up to account for the switch travel)
G92 Z 0.000            (reset the Z to Zero)


You can take the G28.1 calls out of the program and the problem still exists with the RFH.  The problem seems to be the G92 offseting. You can see it in the diagnostics page by looking at the total G92 offset values. Z gets offset in the RFH by teh value of the G92s and then when it goes to the Zheight it is too high off the table.

Put the G28.1 back in and remove the G92 calls and the problem goes away as there is NO z offsetting taking place because of the G92s. You can see it on the diag page that6 there is Zero G92 offsetting taking place.

Now you need to account for the switch travel and you can do THAT in "HOMING config" Z offsetting apply the switch travel as a NEG number.

NOW when you run the RFH you do NOT see any offsetting and the Torch ends up at the proper height. 

Just a thought, (;-) TP

Another test with

#1000 =31
G#1000  Z-1.000
code
code
code

With this I see what Ian described With RFH it cycles thru the FIRST G#1000 and STALLS out. It will not run any further. So that tells ME that the RFH cannot deal with the G#1000 subsituded for G31. Also with a G31 you still have to OFFSET the Z back to Zero.

I have tried it with G92,G52,G10 and the results are the same. As long as there is a VISABLE Z offset in the code the RFH fails leaving the Z axis HIGH in the sky.

(;-) TP

Interesting test

This will run

#1001 =28.1
G#1001 Z-1.000
code
code
code

This will NOT run. It stalls at the G#1001

#1001 =31
G#1001 Z-1.000
code
code
code

I have the Run From Here issue and the Set Next Line issue and yes, I do have a registered Mach3.

I was cutting 304 Stainless Steal puck. The puck was not faced which was I was working on. I set the line to 251 while it was on 232 so way less than 100 lines. I hit "Set Next Line" and "Cycle Start". Dang Mach3 continues at line 232. So I hit "Feed Hold" and set Line to 252 and hit enter to make sure Mach took it than hit "Run From Here" and "Cycle Start". Mach3 continued at line 232. Very frustrated with software that is not QA'd. Said "I'll change gcode, I know it will work".

Anyone have a solution in Mach3 or could I change to a different package and have better results? I'm getting nothing from Mach3.