Hello Guest it is March 28, 2024, 07:41:58 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.


Messages - extrapilot

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

2
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:
Code: [Select]
 
tool = GetSelectedTool()
SetCurrentTool( tool )

The M6End is:
Code: [Select]
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

3
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

4
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

5
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
%

6
General Mach Discussion / Re: Preparation Positioning, bug?
« on: April 06, 2008, 05:16:48 AM »
Well, I am doing some debugging on a complex toolpath, and sometimes it is useful to run from here vs. cut air for an hour. However, I ran into this inconsistency, and felt it to be significant.

I dont think I follow the logic here as to why this should lose position, unless of course you crashed or lost steps in some way in open loop. But if Mach knows where it is, and it knows where it should be by running through the code, it seems to me that resuming (at least in a 2d or 2.5d path) should not be difficult. There should be no problem at all if the 'run from here' is defined at a tool change operation, since you are already retracted and (presumably) are in the same state at resume as you would be following a tool change regardless.

Having used "run from here" many times in this process, even with the runaways, I have not seen any cut offsets. Im not suggesting this is a great option, but it has worked for me. My inquiry was on the fact that there is a runaway that happens when 'run from here' is used at certain points in a code list, and that is a big problem- could easily cause a crash with a fixture, etc. So if this is not user error (dont see how it can be, since I have no ability to modify the run to positions it calculates (they are greyed)), it seems like it may be a bug- one that seems to me to have potentially serious consequences if you are not prepared to hit Reset.

7
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

8
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

9
OK- scratch all that. Stupid intermittent solder bridge on the breakout board.  >:(

Back to learning-

Regards

10
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