[jeffserv]

Pete,

I like your thinking regarding the programming. I too have found, that putting pauses in, alone the way, lets your computer have time to think, and your controls time to react... I have found this especially at the end of programs. Like M2 can cancel something before it is done.

I have seen the coolant pump keep running, when no pause ahead of the M2 command. M2 happens immediately, everything else gets canceled, done or not. So the pause, to allow some time for the computer and motion controls to catch up... is a really good idea!

Could be something to this!

Diagnostics... oh the joy!!

[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

[probinson]

OK, you are missing the point. Let's me see if I can explain this better.

The software running the machine is made up of several smaller programs that run separately. I don't know how many independent programs make up Mach3 but there will be at least 2 major groups, a G-code interpreter that handles getting commands from the text file and figuring out what they mean, and a motion planner that actually calculates all the motion and controls the motors.

Now, as I said, these are basically independent programs. Once the G-code interpreter sends a decoded line off to the motion planner, it is finished with it and working on the next line. The interpreter is always a line ahead of what the machine is actually doing.

You say the machine loses steps in the retract and I say it loses steps when both {the motion planner is trying to perform the retract} and {the interpreter is figuring out whatever comes after the retract} at the same time.

Stopping the machine will not change anything. You're not telling one person on an assembly line to hold up so everyone else can catch up. Stopping the machine freezes everything and it will all pick back up where it left off. If the interpreter was hogging CPU time when you stopped the machine, it will go right back to doing so when you restart.

It may not be quite that simple to fix but I am hoping that adding a dwell after the retract will give the the motion planner something unimportant to do while the interpreter hogs the CPU. An axis losing steps is very bad but nobody cares if a dwell is off by a couple milliseconds.

Pete

[mactec54]

cncvirgin

Some more things for you to try in the control, your look ahead change that to 200 this is the norm for this Mach setting

What do you have these settings set at
Step Pulse=
Dir Pulse=
Velocity=
Acceleration=

In the General Configuration look for Lock Rapid FRO ( Check this box if it is not ) this will allow you to change the Rapid feed rate move, on the main screen, you slide it up & down & the Rapid rate can then be matched to the Feed rate

In some programs the Z Rapid moves are so small, the Rapid move of the Z axes is moving to fast for such small moves, & problems like this can cause lost steps, doing the above slowing the Rapid moves down to match the feed moves will help to stop lost steps

[cncvirgin]

What do you have these settings set at
Step Pulse=
Dir Pulse=
Velocity=
Acceleration=

In the General Configuration look for Lock Rapid FRO ( Check this box if it is not ) this will allow you to change the Rapid feed rate move, on the main screen, you slide it up & down & the Rapid rate can then be matched to the Feed rate
In some programs the Z Rapid moves are so small, the Rapid move of the Z axes is moving to fast for such small moves, & problems like this can cause lost steps, doing the above slowing the Rapid moves down to match the feed moves will help to stop lost steps

Step Pulse=15
Dir Pulse=15
Velocity/Acceleration= tried every possible and imaginable setting, from optimal, reasonable, crazy slow, crazy fast and everything inbetween

I normally set my rapid travels speed through my cam softwares feeds&speeds settings and don't use rapids at all, usually i set the rapid speed to the same as the cutting feed

[cncvirgin]

OK, you are missing the point. Let's me see if I can explain this better.
Pete

indeed i didn't understand what you meant .. will try out a dwell after retract as well


but i think there is light at the end of the tunnel .. it seems to be the cable ... i tried with the shielded cable and lost no steps, then put on the old cables and was loosing steps, put on the shielded again and no steps lost

i'm still not 100% sure that no steps are lost, at one point i thought there was a small loss .. so i will calibrate the machine tomorrow and do another double test tomorrow and then also hook up the audio probe so we can compare the signals ... i tried this with 6 different Gcode files and all worked on the shielded cable and all didn't work on the old connectors ... so if i'm lucky that's it

on a sidenote, i measured the outputs of the machines parallelport with the multimeter and am getting 10V there (2 pins have 8V and one 7.6V) ... shouldn't they be 5V ? The machines parallel cable is going into this optocoupler which then goes into the PC: Optocoupler board for PC LPT 'HS-Opto' - mechapro

will report back tomorrow after a good nights sleep and some more testing

[mactec54]

Step Pulse=15
Dir Pulse=15
Velocity/Acceleration= tried every possible and imaginable setting, from optimal, reasonable, crazy slow, crazy fast and everything inbetween

I normally set my rapid travels speed through my cam softwares feeds&speeds settings and don't use rapids at all, usually i set the rapid speed to the same as the cutting feed

So you have no G0 anywere in your program

Not sure what you mean with you set your rapid speed in your cam, most cam programs only have cutting Speed/Feed settings your machine rapid is controlled by the Velocity setting in Mach if you have a G0 in the program it will run with what is set in the control, that is why I asked for those numbers you may have them set to high for the motors you are using

Your Step pulse can only be a max of 5 as 5 is the max for that setting same for the Dir Pulse

There is something wrong at the computer if you are getting more than 5.5v

[probinson]

The parallel port voltages should indeed be no more than 5.5V. You may have stumbled across a grounding issue. All grounds on your CNC machine should be the same as the PC ground. Connecting a cable with an exposed shield may be connecting the floating grounds and fixing the problem.

[cncvirgin]

so i did some more tests with the shielded cable .. and to my surprise the issue has changed, i am now loosing steps going down as well .. when i do a 'Ref all' and then a 'go to 0' i get a different Z position every time, sometimes higher other times lower. Nothing has been changed since yesterday evening when i didn't loose steps. i can now also see in almosst every Z move i do via the keyboard jog that the move happens in 2 parts ... when i hit the jog key the motor will move, then stop for a brief moment (less than a second) and then carry on again .. this is now a mechanical problem since i can see that the motor shaft is turning without stops .... so it's the coupling to the belt that sticks ... this is new but should be easy to fix

So you have no G0 anywere in your program- Not sure what you mean with you set your rapid speed in your cam, most cam programs only have cutting Speed/Feed settings your machine rapid is controlled by the Velocity setting in Mach if you have a G0 in the program it will run with what is set in the control, that is why I asked for those numbers you may have them set to high for the motors you are using

when i create my toolpaths in RhinoCAM i have the option of choosing 'Use rapid' or choosing a speed to execute rapid moves.

Your Step pulse can only be a max of 5 as 5 is the max for that setting same for the Dir Pulse

i set them to 15 since in this video the guy says to set it so high and that setting it higher than required is no problem, just setting it too low creates problems. It starts at 14:50:

Where did I put those steps - YouTube

There is something wrong at the computer if you are getting more than 5.5v

i measured the Parallel Port of the CNC machine. When i measure the PC parallel port i get 6,6V .. when it comes out on the other side of the optocoupler it's at 10V

The parallel port voltages should indeed be no more than 5.5V. You may have stumbled across a grounding issue. All grounds on your CNC machine should be the same as the PC ground. Connecting a cable with an exposed shield may be connecting the floating grounds and fixing the problem.

Do you mean that the grounding issue is responsible for the 10V instead of 5V ?

[cncvirgin]

euhm ... in other related news: i broke the new stepper (chair)

the transmission wheel for the belt that goes on the stepper shaft was not holding properly (hence the NEW lost steps) but it would not come off anymore ... so i had to force it and that mechanically broke the stepper which now won't turn properly anymore.
luckily the old one still works

here's the culprit:

Attachment 247426

it's really my own fault since i bought a stepper with a round shaft wehreas the original had an indent:

Attachment 247428

what is the technical term for such a non-round shaft so i can google it to find a suitable motor

[mactec54]

cncvirgin

Double post

[mactec54]

cncvirgin

That makes sense, the Breakout Board could quite easily have a different voltage, that is quite normal, 6.6v from the Parallel port is a little high, if it works without any problems, with the computer side, then I would not worry about it

[probinson]

Your stepper is probably still good. You can probably use the vice to push the shaft back in until the rotor stops binding against the case. Push the shaft in a tiny amount at a time, checking to see if it turns normally. You don't want to go too far and have it bind in the other direction.

The opto-couplers provide complete electrical isolation and the output put side can be any voltage levels that the board maker wants. The parallel port is powered by the computer's 5V supply and should not be more than 0.3V higher the supply voltage. Now, you can't put your negative lead just anywhere and expect your voltage reading to be correct. You need to use the ground pins of the parallel port as your reference (pins 18 - 25).

[probinson]

Actually, I misspoke. Just pushing the shaft in won't put the bearing back in place. You need to take the cover off the output shaft side and pry the bearing up.

When you get the cover off you should be able to see if you actually broke the rotor or just moved the bearing.

[probinson]

Oh, and a shaft with a flat on it is known as a D shaft. A slot is a Keyed shaft.

[cncvirgin]

hello again

sorry i was offline for such a long time, I had to make a couple of changes to my workshop and actually get some work done so i put aside the troubleshooting for a while.

So in the end i think it was really just the shielding .. the original cable was unshielded and ran in channel together with the spindle cable .. there were also a lot of cables crossing each other so first i cleaned up the cabling making sure that no cables cross and there is sufficient space between each of them .. then i recabled the Z-axis stepper with a shielded cable ... and the missing steps are gone ...

just to be sure i tripple checked this switching back and forth between the original cable and the new shielded one .. and every time the same result: missing steps with the old cable .. no missed steps with the new shielded one ...so i think it's fair to say that was it

thank you so much everyone for helping me find this ... i know i'm a bit 'thick' from time to time since i don't have an engineering or mechanical background so cheers for hangin in there with me :cheers: