[cncvirgin]

OK Let's recap:
1) You have a problem with the Z retract in one place in a specific program.
2) You tried a few things with the software, including loading an older copy that used to work to check for accidental code errors, but the problem persists.
3) You try some suggested fixes for common problems and that didn't help.
4) It's now time to pin down whether it is a hardware or software issue so you don't keep poking around blindly.
a) A good place to do that it at the driver outputs. If the drive signals are good the problem is somewhere in the wiring or the mechanics. If the drive signals are corrupt then the problem is somewhere from the driver output toward the actual code.
b) The appropriate piece of test equipment is an oscilloscope but if you don't have an oscilloscope you can use headphones to perform the task.

This was intended as a quick way to perform the test using things you have at hand but has morphed into hijacking the tread and I apologize for that.

So, let's confirm the symptoms and get back to actually finding the problem.

Are these true statements?
The machine runs other programs just fine.
It is only this program and only this one retract that exhibits missed steps.

1) yes correct except that the problem is with the z-retract of 'one type of toolpath', the parallel finishing of several objects, it's on the retract before the spindle is moving to the next object that the missing steps happen
2) yes correct - tried everything in software, including different velocity/acceleration settings, different kernel speeds, sherline mode, and whatever else i could find or that has been suggested

The machine runs 2.5D programms just fine, no missed steps there. The problematic toolpaths are the ones where there is a lot of continuous Z-Axis motion (ie Parallel finishing), but the lost steps occur only on the retract move at the end of one object.

I would run this as a separate cable bypassing the one on the machine and see if it fixes the problem. I wouldn't rewire the machine until you find out if the is a wiring problem.

yes this is what i'm doing, it's a separate cable, the original ones are still in place. It's just about the ground i'm confused, a friend told me i could just clamp the shield to any part of the machines fram as long as the machine is grounded. The ground on the bottom is connected to the metal tray holder .. so can i just clamp the braided metal shieeld of my new cable to the PCB tray to ground it .. or should i run a wire from th ground connector on the bottom of the machine and connect it to the braided metal shield ?

[probinson]

Your machine misses steps on the retract when it finishes a really big block of code just before moving to a new part.

What this implies is that the computer is accessing either disk or memory in preparation for the next part and that is tying up CPU time. The CPU is not getting control back in time to service the motor control thread and steps are being lost.

If this assumption is correct, then inserting a dwell after the retract should make the program wait for the machine to stop before loading the code for the next part.

Here is what I think is happening:

You run a really big routine that eats up lots of memory.
The routine completes and sends a retract command.
The entire program didn't fit in memory so the interpreter starts loading more code for the next part.
The access to disk or swapping of memory pages doesn't give back control often enough for the motor control thread to keep track.


If you put a dwell before the retract, the program stops for a little while, starts a retract, and then begins loading while the retract is running.

If you put a dwell after the retract, the program performs the retract, stops for a little while, and then begins loading while the machine is stopped so no steps get lost.

Try that and see if it works.

Pete

[cncvirgin]

Your machine misses steps on the retract when it finishes a really big block of code just before moving to a new part. What this implies is that the computer is accessing either disk or memory in preparation for the next part and that is tying up CPU time. The CPU is not getting control back in time to service the motor control thread and steps are being lost.

the CPU in question is a Pentium 4 with 3GHz and i have 4GB of RAM, everything is running of a pretty fast SSD. The Gcode for each object in between retracts is around 3 thousand lines and i have a lookahead of 100 lines setup in the Mach3 prefs. There is nothing else running on this machine and all unnecessary or disruptive Windows services or features have been turned of.

Could it really be taxing this system so much ? I have no idea what 'a really big routine' is ... is 3k lines a huge routine ?

Y
If you put a dwell before the retract, the program stops for a little while, starts a retract, and then begins loading while the retract is running.

Tried up to 30sec of Dwell before the retract (see also the video posted in the first post of this thread) and its still loosing steps

Y
If you put a dwell after the retract

I've already lost steps at that point, it's happening during the retract.

Almost done with the wiring of the dheadphone probe, but will try this tomorrow morning

[probinson]

It wouldn't matter if you had a super duper 5 terahertz Pentium 17. Latency is the issue, not raw processing speed.

Lookahead of 100 lines means it will have 100 lines buffered IF they happen to be sequential. When program jumps to a block of code it has to dump the buffer and load 100 lines from the new location to fill that buffer.

I've already lost steps at that point, it's happening during the retract.

No. You have not lost steps at that point.
The G-code interpreter parses a line and sends it to the motion planner.
The motion planner calculates the move and begins executing the move.
The G-code interpreter parses the next line well before the motion planner has a chance to finish the one it's working on.

If the freshly parsed command says "We have a new program location" then part of the G-code interpreter's job is to throw away everything in the buffer and fill it with code from the new location.

Putting a dwell after the retract should make the parser load the new location while the dwell is being executed instead of while the retract being executed.

Pete

[cncvirgin]

No. You have not lost steps at that point.

but i do ! i can hear the lost steps happening during the retract move (see video) .. it sounds like stuttering or binding, that's why i thought it was mechanical at first but we've ruled that out (steps are already lost at the stepper).

when i stop the machine just after having retracted and make a 'go to 0' the zero point has moved down several millimetres ... if i stop just before the retract the zero point is where it should be ... so i'm loosing the steps during the retract, no ?

it's completely cool to walk me through the headphone probe and grounding issues i have with my limited electronics knowledge

for the moment here's where i'm at:

check speed/acceleration - done - problem happens whatever the settings
check computer - done - reinstalled windows on SSD, all optimised, clean driver test
check software - done - upgraded to newest mach3 version as well
check if older gcodes still work - done - no they don't, Gcode that used to work without hitches exhibits the problem now
check power - bought a power stabilizer/conditioner to rule out dodgy power lines in the building
check if it's mechanical - nope, it's already happening at the stepper
check if it's the stepper - nope, bought a new one and still losing steps

what's next:

check if shielding the motor cable solves it - almost done
listen to the signal in audio - need to finish the probe