Guest
Show Posts
1
General Mach Discussion / Random positioning motion on each operation start.
« 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
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
Code: [Select]
%
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
%