Hello Guest it is March 28, 2024, 05:07:29 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 - thewormz

Pages: 1
1
General Mach Discussion / Re: gcode executions stop matching DRO
« on: January 25, 2014, 08:08:43 PM »
Correct dro and tool position are the same.
Just the machine executing commands incorrectly. It's like a buffer issue. I have used two different computers I have lying around 64/32bits

Now that I have been trying to replicate to take a screen shot of the tool path window , everything is cutting in sync today.

2
General Mach Discussion / Re: gcode executions stop matching DRO
« on: January 25, 2014, 02:20:09 PM »
I don't think it is missing steps because the motors are in the position the DRO's say they are. Or am I wrong?
DRO & Motors are insync and accurate. How is it a skipped step if the DRO's know? The DRO would be off if the motor skipped a step.



The gcode is getting messed up. When you manually enter a jog on a single, it will do weird movements and even move some of the other axis too.

So say your cutting a circle around 0,0 with a 1 radius... it will all of a suden part way throught the circle continue cutting the a 1 radius circle but around 2,4. and on the tool path preview you can see the blue tool path (gcode) and green (actual) and they line up for a while then something happens and it is making the motions of the blue tool path, just not overlayed [offset by 2,4]

3
General Mach Discussion / gcode executions stop matching DRO
« on: January 25, 2014, 11:36:59 AM »
I have a mach3 setup with KL steppers and drivers.

I keep encountering and interesting issue.
When running a G-code program the machine will seem to go wild some times. It seems like an offset changes in the calculating portion of the code, but the DRO still reads exactly correct. Say I am cutting some 2D letters and the first few will cut fine, and then the next few will cut a few inches off in the x&y. I run the same gcode again with a new piece of material and it works fine. When it does go crazy and I cancel the gcode and go to manual input and do something like g0x0, the machine will move sometimes in that direction, sometimes past zero, then back past it. It is like the buffer becomes corrupt.

It does not do it at the same time in the program every time. Sometimes it executes the whole program sometimes ine 50, sometimes line 200.

I would think that DRO in mach3 would check itself with the interpreter program. when it goes okay I am moving to x0y0... I never arrived there, lets not execute the next line or something.

When the machine does go wild and I restart mach3, remembering the offsets and send it to a known position on my work piece to verify, the DRO are ready 100% correct. So I do not think this is a stepper missing steps issue.

Thanks in advance for any insight you may have on this.

Pages: 1