Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: clachan on August 23, 2007, 10:41:50 AM
-
after hiting run from here button and then start, program runs from the begining instead of from the defind place, any sugestions please
-
Is this a registered copy of Mach3?
thanks
Brian
-
No, it is not
-
The problem is this function is not available without registering the software.
Sorry
Brian
-
Brian
I have a registered copy and updated, purchased program fron Syill, and Mach 3 starts from the begining too.
Bob
RMD
-
Oppps must be the server the first message wasn't displayed....works here for me
-
You need to set the line number that you would like to start at.. after that Press the run from here button.
Mach3 will then be ready to start so press the cycle start button and you will be good to go :)
thanks
Briain
-
Hi
I have one problem with RUN FRO HERE command
its working but there some limith how many line I can set
I working with g code with 800 000 lines and he can run only from 140 000
any suggestion
Thanks
-
I have a fully registered copy and myine will not work right. I type in the line I want to start at and hit run from here and it goes back to the start. What else can I check?
-
I always highlight the code window and scroll to the line I want then press RFH, works every time.
Hood
-
Thanks for the quick reply. If I try to scroll in the window with the reset button pressed "not blinking" it will not let me scroll down. It will only scroll if the reset and its blinking.
-
Something wrong there, if you attach your xml I will see how it works here and maybe can find the issue.
Hood
-
Forgive my ignorance but how do I do that?
-
Ok open Mach and look lower right for the profile name. Look in the mach3 folder on your drive for a file with that name and a xml extension. Copy it to your desktop and rename to jeremyrockjock.xml and then use the additional options on the reply page to browse and attach.
Hood
-
Okay Thanks alot.
-
Seems to be fine here, are you just using the parallel port?
Might be worth trying the standard plasma screenset or maybe even a different keyboard.
Hood
-
I have parallel ports 1 and 2 for the THC300.
I unplugged the keyboard and tried to scroll but no go. I also switched the screens to plasma.
-
I just tried with the scorpion code in Mach and it worked fine, maybe something in your code although I dont know what it could be. If you attach some code I can test with it.
Hood
-
Here is the file I was running today.
-
Ok its not working with that code, I need to get some sleep but will have a look at the code tomorrow. Having said that I am crap with code ;D
I can scroll with the slider and click a line but when I press RFH it starts at line 4.
Hood
-
It might be an Mcode in the file, try:
Go to Config/ General Config/ Check off "Ignore M Calls While Loading"
-
yep line 12 for me. I am way more clueless than you I am sure. I used sheetcam to create the code if that helps.
Hey Zealous, I tried that and still no go. Should I restart mach?
-
No I am getting the error as well:
"Process: Outside Offset. 0. T1: Plasma: 0.06 in Kerf
Are you using Sheetcam ?
-
Yes Sheetcam TNG
-
Did you import your drawing from soildworks (DXF) into Sheetcam?
-
Using RFH in plasma with either the G31 TOM routine or the G28.1 routine will ALWAYS cause problems. The G31 and 28.1 are action gcodes that have to be run in order for mach to know where it is and continue AND in RFH it cannot run so mach tends to get stuck and does not know what to do.
In plasma the set next line works with these routines you just HAVE to restart at a new function or a G1 line. You cannot use set next line on a arc. mach will not know where the arc startpoint should be and error out.
(;-) TP
-
That would indeed seem to be the issue as line 12 is the G31 Doing a set next line like Terry suggests seems to work, at least in simulation anyway.
Hood
-
1. put number of line you need, click enter.
2. click SET NEXT LINE
3. click RUN FROM HERE
4. CYCLE START
-
I'm having the same problem except I'm using FeatureCAM and it is both starting from the beginning regardless of where I "set next line" and "run from here". It then slowly cycles line by line to the line where I had specified the "Run From Here" to be. Additionally, my toolpath is extremely slow to generate. This particular program is a 3D machining toolpath with approx. 22k lines of code. The post processor is configured to define 1 digit code numbering increments. When initially loading the problem I'm hanging on just the 19th line in a G54 command.
I suspect the "Set Next Line" and my initial loading issues are related. Has anybody made any headway on this?
-
I can't seem to get my rfh to work as I hoped. Maybe the answer is the 'set next line' as I hadn't pressed that.
It works currently but the preparation move is always a Z- and 90% of the time this move will crash into the job while the spindle Is off.
So it moves, z- first then in xy till it gets to the desired location then z+ to get ready for cycle start to run from here
Any ideas as I am sick of starting jobs over if I have to do a rfh
-
Make sure you have Mach configured for Safe Z, its from Config menu.
I prefer to use SafeZ as Machine coords, that means I always know exactly where it will go. Z0 in machine coords should be fully up and all Z moves from there are down and negative. So if you set Safe Z as machine coords 0 or -.5 or similar then Z will always raise to that point when doing RFH or Go To Zeros.
You can also set safe Z as an incremental move or work coords move but as said I think machine coords is preferable.
Anyway, RFH, it will only work if licenced, I believe you are so thats fine.
To do RFH you select the line of code you wish to start at, you can do it by scrolling through the code window or selecting a line, doesnt matter.
Once you have chosen where you want to restart you press RFH and Mach will run through the code and then tell you to press Start when it has finished running through it. You press Start and then a prep move box will open, check the coords look fine and you can then press OK, Mach will move to the position detailed in that box but will observe Safe Z, ie it will raise first, move X and Y then lower Z. Once that has happened you can then again press Start and it will continue.
Few things, best to select a start that has Z above the material if possible.
If you have an ATC or use height offsets it is best to start at a tool change or make sure you have the correct tool and height offset loded by MDIing it prior to the RFH.
The prep move box has an option to Start Spindle, you need that chosen. Also you need to have a value in the spindle speed DRO as the spindle will only get a M3 command and no Speed command.
Hood
-
Righto I think you just fixed my problems.
I have not done anything with the safez setup. I have seen it in the config but didn’t know what it did so left it alone.
I will check out what is going on there.
A the moment the prep move is to z- then to xy. Once at the xy position z will raise up and then it will ask to press cycle start and the spindle will start and machine will run.
Will report back once I get a chance to get into the shed.
Sorry to hijack the thread but just thought it was sort of on topic so chucked it in this thread.
-
Ok I just set my safe z to -0.5 Mach co-ord.
Didn't have a lot of time to stuff around with it but did a rfh and it moved to z -0.5 first then xy. Then prompted for cycle start. So far looks to work a treat. Thanks a bunch hood
-
RFH has always worked well for me, once you understand how it works then its a great tool :)
Hood
-
Hey Guys, I am back two years later and still cannot get the RFH function to work. Its still reverting back to line 12 on all my gcode when I hit the RFH button. I have tried the settings last mentioned and nothing changes. Any more ideas?
-
attach your xml and some code and I will see if I can replicate your problem.
Hood
-
Here is the file
-
He asked for g-code and your Mach3 .xml
the .job file from your CAM program is useless.
-
okay sorry. I went back a tried to attach the xml but it won't let me since I posted the same name xml further back in the thread.
-
just rename it, or zip it with a unique zip file name.
-
I copied it
-
I have just tried with your xml and it works exactly as I expected and how it should work.
I click the code window and then scroll through the code to the line I want to start from.
I then press Run from Here and the code scrolls through the code and then a message says press Start.
I do that and get the prep move box.
I check the details in that are correct and press OK
The machine moves to safe Z first then X and Y move to position then z lowers.
I then press start and off it goes.
Hood
-
Weird. Maybe it is a setting that I have wrong in my sheetcam setup. Do you have a gcode file I can try? I would like to try one that I did not create. Thank you for helping me with this.
-
Hood what you may not be aware of IN plasma when you are doing TOM routines that may contain certain calls such as G28.1 the Run from here does not work correctly. Never has never will . You can get it to work IF the TOM routine is in MACRO form BUT that also may cause problems with macros that contain Gcode.
Seeing as the XML is from a plasma unit it may have problems with the TOM routine will trying to do a Run From Here . It is best to use Set Next Line and restart the torch on the fly as you approach the restart position.
Just a thought, (;-) TP
-
Terry I am no expert with plasma as you know, however that was why I also asked for some code along with the xml so that I could see what was going on. I never got the code so could only run with generic code such as the roadrunner.
You know plasma well so what you say is almost certainly the issue and jeremyrockjock should be able to confirm if his code does have g28.1 etc
Hood
-
IN plasma when you are doing TOM routines that may contain certain calls such as G28.1 the Run from here does not work correctly. Never has never will . You can get it to work IF the TOM routine is in MACRO form BUT that also may cause problems with macros that contain Gcode.
Just for Terry because you said you were bored the other day. Here's your challenge should you decide to accept it. There IS a way to get RFH to work across G28.1/G31 GCODE TOM routines, i.e. WITHOUT putting your TOM in M codes. >:D
Ian
-
(;-) I worked on that one for well over a year. Without success, well it could be done with a LOT of block deletes statements but that was a PAIN in itself.
But I will review it ONE more time
(;-) TP
-
Sounds like I am SOL on long runs.
-
No you are not (;-) It is easy enough using Set next line to a few lines before you stopped then get ready to refire the torch when it approaches the spot you stopped at. It works well here, have used it many times to restart mid program without a hitch.
(;-) TP
-
(;-) I worked on that one for well over a year. Without success, well it could be done with a LOT of block deletes statements but that was a PAIN in itself.
But I will review it ONE more time
(;-) TP
No block deletes needed. ;)
-
(;-) I worked on that one for well over a year. Without success, well it could be done with a LOT of block deletes statements but that was a PAIN in itself.
But I will review it ONE more time
(;-) TP
No block deletes needed. ;)
The suspense is killing me ;D
Tweakie.
-
The suspense is killing me ;D
;D
hopefully you're not the only one >:D
Ian
-
OK thinking out loud the problem with the G28.1 and RFH is it cycles the G28.1 EVERY time it sees it. This causes the Torch to RAISE up a bit. The more times it is run the higher that torch gets off the material. So when it is ready to cycle start the torch fires WELL off the material. OR it cycles UP far enough to trip the Z limit.
Now running the G28.1 from a macro then Mach3 does NOT see it when cycling thru the RFH thus does NOT raise the torch each time.
Running with Block delete you use the block delete to delete those lines of code in the G28.1 routine so it also does not raise the torch during the RFH.
You might could Recreate a RFH button that added the TOM code in after it cycles so it refinds the the material top(needs testing again)but I think I did that once and it did not cycle correctly with the RFH.
I do not have the old test notes anymore so off hand I do not know of a way from Gcode to do it.
Here is you chance to be famous and a MASTER Mach3 WIZARD :o ;D
-
OK thinking out loud the problem with the G28.1 and RFH is it cycles the G28.1 EVERY time it sees it. This causes the Torch to RAISE up a bit. The more times it is run the higher that torch gets off the material. So when it is ready to cycle start the torch fires WELL off the material. OR it cycles UP far enough to trip the Z limit.
OK - not what I see here so we need to make sure we're looking at the same problem. Here when I do a RFH, it runs the code from the start to set up modals etc. until it gets to the RFH selected line. However in plasma it never actually get's to the RFH line because when it hits a TOM (G31 or G28.1) it just stops (actually on the line following the G31/G28.1 in the code window) - i.e. never gets to the chosen RFH line. All you can then do is hit stop or reset. Here I'm on 3.043.022
-
HUM I have never seen that here(;-) or even heard of that one.
Here I am on .067 That is the release that Brian and Tom from Candcnc worked on to get some glitches fixed for plasma.
(;-) TP
-
The CURE would be for Brian to exclude the G28.1 and G31 routines from the RFH routine but that is not going to happen, already asked. Answer was NOTTA.
They are to busy with Mach4.
It can be made to work with a macro with limited Gcode/CB code as Mach3 will not run the macro in the RFH. BUT then you have to mod your Cam post to make that work AND your code will NOT run on someone else's machine.
(;-) TP
-
OK - it seems different symptoms but same cause - i.e. we need to stop 28.1 or 31 being active during a RFH approach and then become active again once we're ready to resume. Yes?
Unfortunately I need to mod the CAM post but you seem to not want to do that for some reason.
Don't know why you're disallowing that though - that's exactly what CAM posts are for surely.
Ian
-
OK some more thought on this . I don't think it is the G28.1 that is causing the real problem but the G92 calls after it. It keeps resetting the Z height after the G28.1. THAT causes the Z height to be way high at the end of the RFH sequence.
NOW how do we account for the G92 sequence > MAYBE all we need to do is set the Z home offset in the Homing section and NOT run the G92 after the G28.1. The change in Zheight will be accounted for from inside the G28.1 sequence itself as it will reset the Z internally and not from Gcode.
You cannot account for the change in the G28.1 sequence in CAM. The CAM does NOT know when you are going to call for a RFH in Mach3.
Just a thought, More Testing,(;-) TP
-
Terry - you appear to missing one minute teeny weeny itsy bitsy detail here....
I've already solved this - I did it years ago - I was seeing if YOU wanted to have a go - that's all.
Cheers
Ian
-
I've already solved this - I did it years ago - I was seeing if YOU wanted to have a go - that's all.
Ian, you are such a tease ;D ;D ;D
Tweakie.
-
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 ;D ;D ;D
;D ;D ;D
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 ;D 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 ;D)
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) ;D ;D
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. :(
-
Hi CES,
Which version of Mach3 are you using ?
Tweakie.