Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: extrapilot on February 11, 2018, 03:42:10 AM
-
Hey guys
Sorry if this has been covered- I have searched here and elsewhere and have not found anything.
On Mach3 Mill, I experience a random positional motion at the start of each operation in a file. Example- at start of program, on hitting Start, the table may be commanded to move to X7 Y2, but it may initially travel to something like X8.4 Y1, and then (if it has not hit soft limits) will move to the commanded position correctly.
I am doing nothing strange in my gcode, no Macros have been called etc, and this effect is seen on both .62 and .66 versions of Mach3.
Because the motion can be random for the same code (i.e. if I export only a single operation, and run that- I can see different directions of motion prior to the motion towards the correct start location), I don’t expect this is a gcode problem. In fact, the ‘random’ direction seems to be influenced by where the spindle is in relation to the operation’s starting point. It seems almost to generate some exponential vector, where if it is 1” from the target, it may travel 2”, but if 2” from the target, it may travel 4”…
It also seems to switch signs/direction if the starting position is on the opposite side of the starting position (i.e. if -X relative to the target, it tends to move in the +X direction, and vice versa). I don’t know if this is a hard rule- but it seems to be a pattern.
There is never a problem once the system begins the cut- I only see weirdness in Mach on the op start.
Below is some sample code which is doing this. It does it for all code I export, from all posts I have used. So, Im wondering if there is some bizarre config option in play, or if some registry corruption could cause the system to pull in random offset data as with motion in one coordinate system and then switching to G54 for the actual operation…
It is frustrating as hell, because this can and does cause tool crashes, and requires frequent re-zeros mid-program since a softlimit trip can yield a few thousandths bias…
Any thoughts are appreciated-
Rob
%
O0000 (Trunnion Test Part)
(PROGRAM - Trunnion Test Part.NC)
(DATE - FEB-11-2018)
(TIME - 1:36 AM)
(T120 - 3/8 FLAT ENDMILL - H120 - D120 - D0.3750")
N110 (COMPENSATION TYPE - COMPUTER)
N120 T120 M06 ( 3/8 FLAT ENDMILL)
N130 G00 G17 G90 G54 A95. X7.5302 Y.6396 S3600 M03
N140 G43 H120 Z2.3295
N150 Z1.4295
N160 G94 G01 Z1.3295 F2.
N170 X7.4802 F3.17
N180 X3.5302
N190 G00 Z1.4295
N200 Z2.3295
N210 M05
N220 G28 A0.
N230 G90
N240 M30
%
-
how do you handle tool Change ?
because the first line in your GCode is a tool Change:
N120 T120 M06 ( 3/8 FLAT ENDMILL)
-
Yep- I noticed that and started digging. There isn't anything in the m6 macro file, and the tool offset table for T120 is blank, but removing that T120 call does prevent the random motion. No idea how or why. But, at least it is a good starting point. Worst case, Ill revise the post to not export the M06 and/or Tool ID and just leave the comments, since this is a manual tool change setup...
Thanks very much for the insight. It didn't initially occur to me because there is an additional setup line which was omitted here (it is largely the same as N130- just setting up the motion plane etc generically), and the system ran wild on that line even with no tool change in place. It must look forward enough, or perhaps it runs a line ahead of what is shown in the display. But removing that as a simplification for the post lead me to the same place as you did- and I'm grateful for your time and support in this; it has been a pain, and it didn't affect my machines running the Kmotion/Kflop interface on the same code...
Best
Rob
-
what is your Setup in:
Config -> General Config -> Tool Change ?
did you look in M6Start and in M6End macro file for any code ?
-
Hi TPS/all
Sorry for the delay in response- been working on a 4th axis trunnion, and fighting with some control weirdness there.
Following up on this thread- I did look in M6Start and M6Send and see nothing there of interest (I believe it is only spindle start/stop).
But, I do see one legacy problem- first op on first run of the day can still runaway a bit. None of the others do. So, I wonder if there is some macro called, or a state in place, that would explain that.
Something else which is strange- noticed only with the change to a trunnion on the table now- is that Im seeing the coordinate system move on occasion, for no reason I can think of.
Example, I have my 000 at left center of the trunnion axis of rotation. And, that works. So, I may cut a part on the table- and all goes well. Then, I change ops to run say some finishing/drill op, and magically, X is now biased 0.1”. It is still G54, and when I see the cutter is clearly going to be in the wrong place on reposition- Ill stop the op, throw in an edge finder, and check the zero against the trunnion as was done initially. And for no obvious reason, X at 0 (where it might read 0.1 with the indicator being 0.2 dia) is now reading 0.2… And that is strange, because I don’t ever need to reset the WCS/G54 values in this setup; the part is on jig which was zeroed and proved previously.
Last night, I had a random change in Y by 0.3”. Yea, it sounds like a stall, but it isn’t; I don’t run unattended, and the op in question was supervised carefully. And, in years of using the system, I haven’t seen anything like this ‘until’ I started with 4 axis. Since this is random, it seems more a software thing than a post error or some inherent WCS problem.
Any ideas? I only operate in G54, so hard to know if this is a bug, or some weird implementation of a gcode call, or some macro I don’t know about.
Any help is very much appreciated.
Best regards
Rob
-
can you please post your M6Start and M6End macro,
because there should be nothing in for spindle control.
spindle is controlled by M3/M4/M5.
-
Sorry, you are correct. I was thinking of an M03 that was part of the overall attempt to remove control variables here.
The M6Start for this profile is:
tool = GetSelectedTool()
SetCurrentTool( tool )
The M6End is:
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
So far as I know, these are both as-delivered/stock.
Just wondering if there are other macros called natively that are not obvious, or if there is some process where perhaps a coordinate system is copied in (where somehow that source value is an offset etc). I have much more experience with Kmotion/Kflop, and I dont see weird stuff going on there; you define which calls are made at startup (in fact, you define the startup process), so Im not familiar-enough with Mach's baseline config as it may be affected by the Config screen, the Motor control screen, etc.
Thanks so much for the help in this-
Rob
-
so you M6 macros look "normal".
if i understand everything right (my english is not the best), this random
Position shift either X or Y is allways Happening after a tool Change (M6).
so you can try this by entering a couple of M6 into MDI, to improve the
toolchange does this shift.
-
It is doing other strange things. Example, often if I pause an operation via the Space bar, normally it should resume when I hit Start/Resume. But more recently, it will often offset itself in Y by some amount (typically 0.3" or more), and/or attempt to rotate A where there is no A code in effect. I assume both have something to do with the machine zero being called instead of G54 (where right now, A defaults to 45deg, and this behavior is seen with the rotary table at 0 or 90deg etc). But there is no G28 called, so perhaps it is native to the system, or maybe it is buried in the config screen as a call on program start. But, seems to me 'resume' should not trigger program start calls regardless of where they are.
Ill see if there is a G28 in the startup command in the Config screen, but as to how these offsets are being introduced to the machine (vs just a move to machine zero before a WCS positioning call) I have no idea.
Regards
Rob
-
I would suggest that you read the Mach3 manual, watch the videos, etc and enhance your understanding of Mach / CNC job creation, machine referencing / homing, work offsets, and some commands,etc. That will cure you problems.
RICH
-
Brand new to this site, so please be kind. I too am having this same problem. It has occured for years now. In looking at the M6end macro I am questioning the second to last line:
Code"G00 X" & x & "Y" & y
Are the parenthesis in the correct position? Thanks
john f
-
Brand new to this site, so please be kind. I too am having this same problem. It has occured for years now. In looking at the M6end macro I am questioning the second to last line:
Code"G00 X" & x & "Y" & y
Are the parenthesis in the correct position? Thanks
john f
Nothing wrong
-
Hey guys
Sorry if this has been covered- I have searched here and elsewhere and have not found anything.
On Mach3 Mill, I experience a random positional motion at the start of each operation in a file. Example- at start of program, on hitting Start, the table may be commanded to move to X7 Y2, but it may initially travel to something like X8.4 Y1, and then (if it has not hit soft limits) will move to the commanded position correctly.
I am doing nothing strange in my gcode, no Macros have been called etc, and this effect is seen on both .62 and .66 versions of Mach3.
Because the motion can be random for the same code (i.e. if I export only a single operation, and run that- I can see different directions of motion prior to the motion towards the correct start location), I don’t expect this is a gcode problem. In fact, the ‘random’ direction seems to be influenced by where the spindle is in relation to the operation’s starting point. It seems almost to generate some exponential vector, where if it is 1” from the target, it may travel 2”, but if 2” from the target, it may travel 4”…
It also seems to switch signs/direction if the starting position is on the opposite side of the starting position (i.e. if -X relative to the target, it tends to move in the +X direction, and vice versa). I don’t know if this is a hard rule- but it seems to be a pattern.
There is never a problem once the system begins the cut- I only see weirdness in Mach on the op start.
Below is some sample code which is doing this. It does it for all code I export, from all posts I have used. So, Im wondering if there is some bizarre config option in play, or if some registry corruption could cause the system to pull in random offset data as with motion in one coordinate system and then switching to G54 for the actual operation…
It is frustrating as hell, because this can and does cause tool crashes, and requires frequent re-zeros mid-program since a softlimit trip can yield a few thousandths bias…
Any thoughts are appreciated-
Rob
%
O0000 (Trunnion Test Part)
(PROGRAM - Trunnion Test Part.NC)
(DATE - FEB-11-2018)
(TIME - 1:36 AM)
(T120 - 3/8 FLAT ENDMILL - H120 - D120 - D0.3750")
N110 (COMPENSATION TYPE - COMPUTER)
N120 T120 M06 ( 3/8 FLAT ENDMILL)
N130 G00 G17 G90 G54 A95. X7.5302 Y.6396 S3600 M03
N140 G43 H120 Z2.3295
N150 Z1.4295
N160 G94 G01 Z1.3295 F2.
N170 X7.4802 F3.17
N180 X3.5302
N190 G00 Z1.4295
N200 Z2.3295
N210 M05
N220 G28 A0.
N230 G90
N240 M30
%
1. The Gcode file says in comment
N110 (COMPENSATION TYPE - COMPUTER)
Does that mean the radius of tool#120 which has a diameter of 0.3750" (3/8") has not been compensated?
G41 that turns on radius compensation and G42 that turns off radius compensation are NOT found in the program so cut dimensions may be incorrect because of tool radius.
2. Operation.
Normally, you need to jog the machine to your work piece origin x and Y and Z (tool tip on top of the material surface), the in work coordinates (no red square around Machine Coordinates button) click [zero X] [zero Y] and [Zero Z].
Then click on [reg. toolpath]
BEFORE
you click on
[CYCLE START]
-
@extrapilot @kabover
I recommend you read concise STUDENT CNC GUIDE first
https://www.kth.se/polopoly_fs/1.686422.1550155780!/Student%20CNC%20Guide%20v0.4.pdf
Then
as RICH suggested
Mach3Mill_1.84.pdf that is available in this forum under USER DOCs.
-
The reason that I asked the question is for some time when I do a tool change, after pushing start, the machine will take off in a random direction for a given distance and then go to the position it is suppose to. In reading M6end is suppose to send the tool to the next starting position after tool change. I moved the " mark from in front of the G00 to In front of the X and now the machine works as it should. The random motions have stopped. At least 6 dry runs and not one problem. It looks like it is fixed, but I am not sure and you say nothing is the matter with the statement. Is it fixed or not???
john f
PS I am quite familiar with G-code but the macros are foreign territory.
-
I moved the " mark from in front of the G00 to In front of the X and now the machine works as it should.
imho by doing this, you should see a scripter Compiler error in the Status line, and the M6End macro
will not be executed at all. -> so no move