Hello Guest it is January 26, 2021, 07:11:09 AM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - extrapilot

Pages: 1
1
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

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
%

2
General Mach Discussion / Preparation Positioning, bug?
« on: April 06, 2008, 04:12:32 AM »
Hi

I have noticed that in using the 'Run From Here' command, if that selected line is some type of M command, and perhaps others, though the Prep Positioning dialog box indicates what seem to be correct target coordinates for a prep move, the system runs away- generally hitting a soft limit, but sometimes just randomly stopping at some weird place. I have called this 'run from here' command several times against a given line, and the runaway position seems to vary, and is not related in any obvious way to machine coordinates or offsets, etc; it seems random. However, if I 'run from here' on any G or coordinate line, the positioning function actually goes where it says it will go.

Here is a (subsection) sample drill operation, with a change to a facing operation. I can 'run from here' on any drill coordinate line, and all is fine. If I 'run from here' on M09, M05, M01, or M08, I get the runaway. Perhaps there is some problem with my code, but if the Preparation Positioning dialog box says, for example, x=2, y = 2, z = 1, and that is within reason for the part, but the table goes to x=18, y=0, z = 2.2, Im not sure how I can be causing that; the dialog box suggests Mach knows where it should go, it just doesnt go there.

Any insight? Using the current lockdown version of Mach3 under Win XP.

Regards,
Rob

M08
G00G17G90G54X1.459Y.4899S3200M03
G43H47Z.2
G94
G99G83Z-.4R.2Q.1F3.
X.139Y2.5893
X.413Y2.5949
X.7377Y3.0899
X.139Y.1514
X.413Y.0949
X1.459Y.9649
X2.109Y.4899
X2.959
X3.559
X4.5478
X4.434Y.9399
X2.959Y1.7399
X4.434Y2.0399
X4.309Y2.5899
X4.459Y3.0899
X3.659
X3.309Y2.5899
X2.659Y3.0899
X2.259Y2.4399
X1.834Y2.8899
X1.809Y3.0899
G80
M09
M05
G91G28Z0.
M01
(TOS = .12)
T0M06(9/16 FLAT END MILL)
(MAX - Z.25)
(MIN - Z-.22)
M08

3
General Mach Discussion / G81 weirdness, newbie
« on: August 28, 2007, 06:52:40 PM »
Hi-

I was attempting to run a very simple drill process. The program was to drill 3 holes full depth, and then drill a 4th hole partial depth, followed by a tool change (smaller drill) and a full depth pass at that final hole.

When Mach3 runs this code, it properly completes the first 3 drilling operations, but then it executes the 4th (partial depth drill) on the 3rd hole. Then it requests a tool change, and executes a full depth drill on the 4th hole. As best I can tell, the process should run as: move to -1.25,0 and execute a drill operation to -.6, then retract to .1, then move to x=1.25 and repeat drill operation (sticky), and then move to .315,-1.5945 for the 3rd drill op. Then it calls a G80, which as I understand it should cancel the G81 sticky process, and then move to -.5762,-1.5873, where a G81 call is made for a hole to -.3. The G80 does not appear to be handled here- and it seems to just skip line 118.

Anyone have any clue as to if this is a bug in the interpreter, or in my code generation (it is from Mastercam X).

Regards,
Rob

N100 G20
N102 G0 G17 G40 G49 G80 G90
N104 T104 M6
N106 G0 G90 G54 X-1.25 Y0. S1069 M3
N108 G43 H104 Z2.
N110 G98 G81 Z-.6 R.1 F4.28
N112 X1.25
N114 X.315 Y-1.5945
N116 G80
N118 X-.5762 Y-1.5873
N120 G98 G81 Z-.3 R.1 F4.28
N122 G80
N124 M5
N126 G91 G28 Z0.
N128 M01
N130 T4 M6
N132 G0 G90 G54 X-.5762 Y-1.5873 S1800 M3
N134 G43 H4 Z2.
N136 G98 G81 Z-.6 R.1 F1.03
N138 G80
N140 M5

4
Hi

First day with Mach- in fact, first day with the new controllers. Im very sure this is not a controller problem, but the system is just 3 Gecko 203V drives direct coupled to a PC with a dumb breakout.

I defined pins for each axis (seperate pins of course), and connected my X axis stepper. I noticed that when I use the left and right arrow keys, the motor always turns CCW. As soon as I hit the down arrow, then the left and right arrows cause the X stepper to turn CW or CCW as expected. If I hit up arrow, the X stepper reverts back to always CCW. I ran the sample GCode (Roadrunner), and just by watching the X axis stepper when running the code, it is having the same issue- X is stuck in CCW until there is a Y-, and then sticks in CCW again as soon as there is a Y+ move.

Since the drive works correctly after a Y- jog, it cannot be the drive or anything outside the PC; the direction control for X is physically separate from the Y direction, and I have verified the signaling with a DSO.

Just wondering if anyone has a clue as to what is going on here. Maybe driver corruption? It is a super clean new install though- XP Pro, no unnecessary background processes, etc etc.

Thanks all- looking forward to working with the group.

Regards,
Rob

Pages: 1