Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: Chet on November 14, 2010, 04:08:28 PM
-
I'm using Mach3 with a computer running Windows XP and a HobbyCNC driver board.
I've noticed that the Z-axis motor will rotate slightly during runs on the X-axis only.
It is stable on Y-axis runs.
I'd love to get rid of the drift...
And, yes, I've already added the extra capacitors to the cables going into the HobbyCNC board to ground out cross-talk.
So I'm open to new suggestions...
Chet
-
Either electrical noise, possibly even on the output side of the drives or you have duplicated pins in Mach.
If you attach your xml I can check your config.
Hood
-
Okay, which of the reply icons would I use to attach that file???
On regular e-mail I'd be confident, but I'm not seeing what I'm looking for in the icon list.
Of course it could be there, I just don't recognize it...
Chet
-
On the reply page you will see the additional options button, you can use that to attach your xml. You may need to rename it first though if it has a standard name as the forum only accepts a file name once.
Hood
-
Okay, let's see if I'm uploading the file correctly...
Hope you find something useful...
Chet
-
Dont see any problems of pin duplication in your config so it is likely that it is noise getting into the wiring.
Hood
-
Just performed an interesting test...
There is NO drifting of the Z-axis when I manually move the carriage along the X-axis with the keyboard commands.
It only occurs when the X-axis is moving during a program execution.
What does that imply????????
-
Seems strange unless your code is calling a Z axis move. What if you MDI a X axis move?
Hood
-
MDI????
If this refers to moving the X-axis from the keyboard, I can do that without Z-axis drift.
-
MDI is manual Data Input
When you said you were moving via keyboard I presumed you were meaning jogging but you are meaning via entering G Code commands in MDI line?
If you are then I cant see how that would be any different than from Mach running code from a file.
When you start Mach and hit the Reset button for the first time do you get any messages?
Hood
-
No, no error messages.
But I did make another observation... The Z-axis is stable during the duration of a cut, it only drifts when it is on it's way to the next cut. It's almost like it's easing in....
-
try a 0.1uf cap from each input to ground, has worked for me in the past.
-
Angel Tech, thank you!
BUT they're already in place!
Remember I'm only getting the drift when the Z-axis is on it's way to the next location.
No drift with shuttle, or at specified depth...
Seems to me I remember something, way back when, about the settings of the limit switches in Mach3 that could affect Z-axis drift...
Chet
-
Does the Z DRO show this movement?
Hood
-
Yes! I was surprised to see it, but the Z-axis numbers change on the readout... even thought they are not supposed to...
But, I am embarrassed to admit, I forgot to notice whether the program is actually calling for that change... Rats!
I'm using Acme Profiler to generate the code, but it theoretically shouldn't be generated the shift...
-
Okay, I got lucky...
I have a program running and it allowed me to see the drift in action...
The Z-axis readouts show the drift with changing numbers, but the programming code does NOT call for any change.
I look forward to your analysis...
-
Can you post your code and I will see if I can get the same in simulation. Also if you could attach your xml if it has changed from the last time you posted it.
Hood
-
It's a kind offer, Hood, but it's 56,000 lines of code.
I'll hold off on sending the file for now.
Let's see if someone else is having the same problem...
I'm sure I read about this a year or so ago when I was just getting familiar with Mach3...
-
One more observation...
The Z-axis is stable during the duration of a Depth of Cut...
It is only drifting during the duration of a Height of Clearance...
Both are arbitrary commands set by the programming code.
Why would one be stable and the other unstable?
-
Afraid with out being able to replicate it here I am out of ideas.
I have tried with your xml and it seems fine but without trying with code that you definitely get the problem with its not possible to say whether its a hardware, software or config issue.
I understand you may not want to share the code for many reasons but if you find some simple code that also causes problems for you please post and I will see if I can replicate it.
Hood
-
Hood, thanks for the offer...
If you can work with a string with the problem action, I'll try to isolate a couple of hundred lines...
Give me a day or two...
I really appreciate your effort to help me find a resolution...
Chet
-
Just a few lines of code that makes it happen is all I would need, so if you can get that it would be good as it would hopefully narrow down the problem.
Hood
-
Okay, Hood, I've attached a test code when Z-axis drift occurs...
If you start counting with the top line as 0 in the attachment,
the problem occurs on line 29.
Here's a snippet of the code:
26 X0.1657 Y0.626 Z-0.25
27 X0.0823 Y0.626 Z 0.0
28 G00 Z0.1
29 X9.9157 Y1.376 Z0.0 (THIS IS THE LINE THE Z-AXIS DRIFTS ON)
30 X9.9157 Y1.376 Z-0.25
The drift also occurs if you use Set Next Line to an earlier execution like line 26...
The Z-axis will drift while moving to the line 26 start point...
I look forward to your analysis...
Chet
-
The previous Z height to that line is Z0.1 and that line then commands it to go to Z0 because the X and Y have a longer distance to go the Z will move slowly so that all axis reach their destination together. Is that what you are meaning? because that is a commanded move and should be happening.
Hood
-
Okay, Hood, if I understand you correctly, the software is causing the move...
So do I simply eliminate all such lines to stop the drift????
(would I eliminate just the z0.1 line or both the G00 and Z0.1???)
I'm on a steep learning curve here...
I'm not the author of the code, it was generated by Acme Profiler...
It appears I'll have to tweak the code after Profiler generates it...
Yes???????????
Thanks, Hood, for all your effort on my behalf....
-
I have been following your problem and there seems to be no real solution in sight, at least for the moment.
I have an off the wall idea i would like you to try. Press together, the CTRL ALT & DEL keys. This will bring up the windows task manager screen. It will stay on top of everything else on your screen. Now run your program. Watch the CPU Usage number at the bottom of the window. If at any time to goes to 100% your CPU is over extended and program steps in progress can be gained or lost in the process.
If you seen it go to 100%, then click on the Processes tab at the top and look down the list to see what process is causing the CPU to go to 100%.
Like I said, kind of an off the wall idea, but sometimes can be very revealing with running a complex program.
George
-
Chet your code is fine as long as the axis is doing what the code is telling it to do. On line 28 the code is telling the Z to move to 0 and line 29 it tells it to go to 0.1 along with the X and Y moving. If the Z does what its being told to do then all is fine. Line 30 tells the Z to move down again to -0.25, it also has X and Y moves but as X and Y are already there they will not move.
Is the axis doing as described above?
Hood
-
Two observations:
First, I am not a computer programmer, BUT George it would appear that activating the ALT-CTRL-DEL sequence WILL be putting more stress on the CPU, thus affecting the outcome...
(this nearly verges on the esoteric topic of quantum states... if you watch it, you change it...)
Second, it's also really obvious I'm not skilled at understanding g-codes...
Hood, I appreciate your line by line analysis...
I believe your conclusion is that the router is simply obeying its commands.
So, I think I may simply take individual lines and bracket them with parenthesis to turn them off and study the results.
I think Wikipedia's g-code explanation may become my leisure reading....
-
Is there actually a problem? Is the Z not going back to where you think it should be after line 29? The code tells it to go to -0.25 on line 30, is it going there?
Hood
-
Yes, the problem is that the Z-axis drifts below Z=0.0 while moving to a new location on the X-axis only...
This causes a taper across the top of work...
It's removing material where it should not...
-
Ok so is it t towards the end of the line 29 move that it starts digging in?
In the code you attached if you change the Z in line 29 to 0.1 is it OK?
Hood
-
The slow Z-axis rotation starts immediately...
I won't be able to do the line modify until later today...
Thanks for enduring...
-
Yes the code is telling the Z to rotate slowly and that is why it is doing it.
Here is what the code is saying
27 X0.0823 Y0.626 Z 0.0 ( X, Y and Z to move to these positions at the commanded feedrate set earlier)
28 G00 Z0.1 (This is telling Z to Rapid to 0.1)
29 X9.9157 Y1.376 Z0.0 (this is telling X,Y and Z to go to the positions and all will move but as X has the furthest to go it will move faster, Y will be next fastest but Z has hardly any distance to move so it will go slow. The reason is all axis need to start and finish at the same time)
30 X9.9157 Y1.376 Z-0.25(This line is essentially telling the Z to move to -0.25, there are X and Y commands but as they are already there they dont move and are actually not needed in the code, replacing that line with z-0.25 would do exactly the same)
So as you can see the machine is doing as its told by the code. If the Z0 on line 29 was deleted or replaced with Z0.1 the Z Axis would not move until that line had completed and then the next line would take it down to -0.25
Hood
-
Outstanding explanation!!!!
Thanks, Hood!!!!!
-
Glad it helped.
Hood