Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: tagrace on September 19, 2008, 07:23:31 PM
-
Hi gang. I've been pretty quite here for a long time but I think I have found a bug.
It's not a big deal and it's an easy code fix. I use Sheetcam to generate almost all of my gcode. Sheetcam's Mach post jams an F1 into the init code. Les says it's to keep Mach quite during the init. Don't really know what that means.
Anyway, The F1 comes before the tool change. When run, the mill goes to the tool change location and waits. On continue the next move, which is a G00 to some location, the mill runs at F1 speed like it was a G01 move.
I think it has been like this forever. It still does it in the latest dev version as well. I have just gotten into the habit of changing that F1 to F50 in the editor each time I load a file.
Am I missing something or doing something wrong?
Thanks.
Ted
-
Ted,
I've noticed the same thing going on, seems it gets back up to speed once it reaches the next point if I recall but I usually get impaitent and do a run from here thing.
Kristin
-
Yes, it only affects the first move after the tool change. Runs correct feed rate after that.
I had a problem with Sheetcam TNG and this issue came up. I changed the SC Mach post to jam an F50 in there instead of the F1. Les is the one who brought up the question as to why I was doing this.
It's an easy workaround for me but it did bring up the point that Mach may have a bug.
Ted
-
Must be something like that, as when I start up Mach asks to press Cycle start after tool change, it runs at speed then, next change or possibly the third one, it goes into slow motion.
Kristin
-
May I ask what version you guys are using?
Thanks,
Dave
-
Please attach the code and the xml as I dont have that problem on either mill or lathe.
Hood
-
Dave,
Version does not matter.. It has always done this. I was running 2.63 as of Wednesday when Les (of Sheetcam) brought this up. I loaded the latest Dev version on Thursday and it still does it.
Hood,
I won't be back at the shop till Monday so I can't get to the code. Maybe Kristin has access to her code.
Ted
-
ok will look out for it on Monday
Hood
-
OK, today was a crazy day.Sorry I did not get this done sooner.
Attached is an xml file and the test.tap file that will duplicate this problem for me.
I stripped the job code down to all you need to duplicate it. On both my mill system AND another system system I loaded the latest dev version on to play with, the code runs to the tool change and stops. Upon continue, the Z moves at rapid speed to safe Z, and then moves down at F1 speed prior to turning on the Spindle.
The only thing different here from my original explanation is I rasied the safe height to 5.000 as opposed to 3.000. My actual job code moves the Z to 3.00 at the end of a run thus, I was not seeing the rapid rise to Safe height as it was already there.
To duplicate, just load it up, zero x, y, and z, hit start. Hit start after the tool change stop. The Z will rise to safe height of 5 at rapid speed and then go down at F1.
Also note, I have not changed the M6 macros in any way. They are original as delivered.
Thanks for looking at it.
Ted
-
I dont really follow what your problem is, you have a F1 in your code and Mach is obeying that F1. The only way that Mach will go faster is if the F1 is superceded by another F word. This is not a bug in Mach as its just doing exactly what the code is telling it to do, you need to sort the Post Processor in SheetCAM.
Maybe I am just not understanding what you are meaning or expecting.
Hood
-
I guess I'm the one that does not understand.
Why is the move to safe height move at rapid speed and the move back down at the feed rate of F1. There is no gcode moves in there.
Why does the Z move down at all in fact? If the z moves to safe height after a tool change that's fine. Shouldn't it wait for an move instruction at safe height? The next instruction in my code after the tool change is the spindle on. There are no moves yet the Z moves down on it's own.
If the current operation is by design then that is fine with me and I'll just have to change the Mach Post in Sheetcam to set a higher initial feed rate that I can deal with.
This whole question came about from Les of Sheetcam. Sheetcam jams the F1 in there. When I told Les I had to change the F1 to a higher rate, he said it was not necessary which led to the thinking that Mach was doing something weird.
-
OK what is happening is your toolchange is calling the M6 macro, the M6 tells the axis to move to your toolchange position and wait for the Start button and then move back to the position it was at previously at a G1 feedrate. If you actually look whats happening is your axis starts at Zero, it rapids to the Toolchange position, it then feeds back to zero then the next line is a rapid to 0.6, not a very good idea LOL.
You could edit the macro so that it only goes to the safe Z, you could edit the post processor to do similar or always do a certain Z move before a change or whatever you wanted.
I have not looked at the standard M6 macro for a while but will do so later on and see exactly whats in there and could probably edit it to take out the return to previous position if you want that? Just in the door so it will be in a while.
Hood
-
Hood,
The M6(start) macro has this in it:
tool = GetSelectedTool()
SetCurrentTool( tool )
The M6(end) macro is empty.
I'm assuming that the M6(start) macro does no movement and just updates the screen.
I did some more playing around with this and found that the tool offset has something to do with it. I don't do much with tools settings in mach in fact, the tool table is all zeros. By playing with safe height and tool offset I see now what is happening. Upon hitting the M6, Mach updates the screen as per the macro and waits for a continue. Upon hitting start the z rises to safe height rapid speed and then immediately moves to the tool height as set in the tool table at feed rate. It then continues on as expected.
If this is normal behavior by design then so be it. I can live with it. I just don't understand why. In my situation with no tool changer I have to manually fit tools and zero them. Once fitted and zeroed I am happy to see the move to safe height for protection. The move to the offset height is a wasted move.
Ted
-
OK how do you go about a tool change, ie do you jog up, put the new tool in, jog down to sufrface and zero the DRO?
Hood
-
Yup, that's exactly it.
I'm not always worried about the exact height as long as I'm no lower then the surface height. I'm mainly cutting through a 0.060" surface on most of my jobs. I setup most of the jobs to cut 0.200" deep so I have plenty of leeway. On jobs where z precision is required, I touch off a gauge block connected to the probe input. I have a little macro that does that for me.
I guess if the Mach behavior is normal by design I'll let Les at Sheetcam know about it.
Thanks,
Ted
-
Nothing is really normal, just depends on your code and also whats in your macros.
You said M6 End is empty so really I am not sure why your axis is moving way up then down again. You sure its definitely empty? You are looking in the correct profiles macro folder?
Hood
-
Ha, I lied.
M6 end has the following code:
REM The default script here moves the tool back to m6start if any movement has occured during the tool change..
x = GetToolChangeStart( 0 )
y = GetToolChangeStart( 1 )
z = GetToolChangeStart( 2 )
a = GetToolChangeStart( 3 )
b = GetToolChangeStart( 4 )
c = GetToolChangeStart( 5 )
if(IsSafeZ() = 1) Then
SafeZ = GetSafeZ()
if SafeZ > z then StraightTraverse x, y,SafeZ, a, b, c
StraightFeed x, y, z , a, b, c
else
Code"G00 X" & x & "Y" & y
end if
If I'm reading this correctly, If Safe Z higher then the current Z then will do a rapid move to Safe Z. Then we will do a feed move to the original position.
If Safe Z is not higher (already above or higher then Safe Z) we will do a rapid move to the original x,y.
This explains what I'm seeing.
I must have looked at an old profile's macros when I saw the empty M6 end. Sorry about that.
Thanks for your help. I'll pass this info to Les.
Ted
-
If you REM all that out it should be fine the way your Post Processor is writing the code. Only thing is you will have to watch it doesnt get overwritten by an upgrade. Easiest way to solve that problem is have a custom profile and the macros for that profile wont get overwritted during an upgrade.
Hood
-
Hood,
I can't see REM'ng everything out of M6end but I am sure something could be modified to prevent this.
Kristin
-
I think I'll stick to modifying the post in Sheetcam to set the initial feed rate to something I can live with instead of the F1 Les has provided.
I don't mind the extra moves I just can't wait forever at F1 speed.
This way I don't have to worry about Mach upgrades.
Thanks for your help.
Ted
-
Hood,
I can't see REM'ng everything out of M6end
not sure what you are meaning Kristin?
Hood
Hood
-
Hood,
I was thinking of modifying the part
if(IsSafeZ() = 1) Then
SafeZ = GetSafeZ()
if SafeZ > z then StraightTraverse x, y,SafeZ, a, b, c
TO something like
if(IsSafeZ() < z) Then
SafeZ = GetSafeZ()
if SafeZ > z then StraightTraverse x, y,SafeZ, a, b, c
or something like that (I'm no programmer) may allow those of us doing manual tool changes to jog up/down zero the tool and continue.
Haven't had time to really look at it and decypher what's going on got some outdoor work to finish before the rains come and a machine rental coming this weekend to make the dirt fly!
Kristin
-
I think a better solution (for my situation anyway) would be to see if any moves were made durin the tool change stop.
If no moves were made, then don't do anything. No need to move to safe z.
As I have a lot of production jobs that use a single tool, the first run of the day requires me to verify tool and alignment. After that, I just want to run. The tool change stop just means that I have to hit start twice and walk away after loading the jig. As x,y, and z are not touched between runs, there is no need to move to safe z.
I don't have time now to write the M6end macro changes but basically another IF statement at the top to test if the Start X,Y,Z a,b,c are equal to the current X,Y,Z,a,b,c. If they are not equal then run the rest of the macro. If they are equal then no need to do anything so just exit.
I'll work out the code when I get some time. It's been a crazy week here.
Ted
-
Thanks Ted,
I'll have to give that a shot if I get a free momment, I have a Bobcat loader and auger due here Sat morning and still need to get my fence plans approved, mark up the lot, do a BOM of the parts... not much time to play with the mill this week.
Kristin
-
This modification to the M6 End macro seems to work fine for me. If no moves were made during the tool change stop, the macro does nothing. If a move WAS made, the macro runs as originally intended.
REM The default script here moves the tool back To m6start If Any movement has occured during the tool change..
REM Changes made by Ted G. to stop this from running if no moves were made by user during tool change stop..
x = GetToolChangeStart( 0 )
y = GetToolChangeStart( 1 )
z = GetToolChangeStart( 2 )
a = GetToolChangeStart( 3 )
b = GetToolChangeStart( 4 )
c = GetToolChangeStart( 5 )
CurX = GetDro(0)
CurY = GetDro(1)
CurZ = GetDro(2)
CurA = GetDro(3)
CurB = GetDro(4)
CurC = GetDro(5)
Moved = 0
if CurX <> x then Moved = 1
if CurY <> y then Moved = 1
if CurZ <> z then Moved = 1
if CurA <> a then Moved = 1
if CurB <> b then Moved = 1
if CurC <> c then Moved = 1
if Moved = 1 then
if(IsSafeZ() = 1) Then
SafeZ = GetSafeZ()
if SafeZ > z then StraightTraverse x, y,SafeZ, a, b, c
StraightFeed x, y, z , a, b, c
else
Code"G00 X" & x & "Y" & y
end if
end if