[saltybugger]

Hi all, I'm sitting here completely perplexed at this point and wonder if anyone here can help with an idea.

I have a 3 axis machine I custom built to drill. X/Z control a table and the A index controls rotation of the spindle. Using PMDX120 board with mach3, gecko 320 drives on servo motors, us digital e2-500 encoders.

One axis-X after running a machine cycle (typical program consists of x/z position, x move positive, x negative, positive, negative, cancel offset/home, new tool offset, x/z position, x negative, x positive, x negative, cancel offset/return to home)

Machine adds an error in the positive direction every time the cycle is finished. I know this because I setup a pointer this morning on the motor pulley and marked the pully. Each time I cycle it increments this error more and more. Seems linear each time...ie .005, .010, .015 etc.

I've spoken with pmdx about this today and he thinks I may have a noise issue. I'm scratching my head...it's only this one axis, the step/direction lines from the board to the gecko drive are shielded, the encoder lines run through stock shielded us digital cables (one large circular plastic connector controls each motor/encoder so everything can be swapped if necessary), I've swapped encoders/motors, gecko drives, everything I can think of.

The error problem has always been on this machine but it seems like it's gotten worse lately which is what leads me to dig into this. The last run of parts we did I had about 30 bad pieces out of about 700 which is alot.

Anyone got any ideas?

[jalessi]

Saltybugger,

I am curious to hear what is causing the problem.

How big is the error compared to the step?

We have a machine that will add a step to the 4th axis every time it is referenced home.

The movement is repeatable and linear, it only happens when the machine is homed.

Jeff...

[saltybugger]

jeff I haven't measured the error so I can't answer that, I'm basing my observation on the pointer I put in the machine today with a mark on the pulley.

In this case the error disappears when the machine is homed. I haven't figured out when/where in the it starts happening because it runs so quickly it's hard to judge but I'm going to re-write the code and slow it way down to see if it comes into play in a certain run of code.

[neilw20]

By homed do mean just G0 X0 Y0 Z0 or is the machine being referenced.
How many times is the machine reference cycle run?
What sort of homing switches are used?

[jalessi]

Neil,

The machine has Cherry brand micro switches on the X, Y, and Z axis.

The Rotary axis has no limit switch.

After clicking the "REF ALL HOME" button the A axis always moves one step.

[saltybugger]

g92 offset then g92.1 cancel offset and return to original position.

I am seeing the error after the first cycle then it's cumulatively worse, each cycle adds additional error. When it gets bad enough I hit home and start all over again-usually in 4-6 program cycles.

These are small .25" lug two hole mount microswitches with roller and machine has an aluminum ramp on the axis where it contacts the roller of the switch.

Not sure the current manufacturer but it's a standard size microswitch. Switch has been changed in the past also.

By homed do mean just G0 X0 Y0 Z0 or is the machine being referenced.
How many times is the machine reference cycle run?
What sort of homing switches are used?

[neilw20]

On the step and direction setting where the pins are set up I suspect that you need to reverse the logic. Make active low/high the opposite to what it is. Only the positive or negative edge will clock, and it must be correct so it can return to the initial state.
Close investigation of the break out board specs and driver specs will be needed to identify whether a positive or negative edge is correct.
It may be easier for you just to change the it and try it.
Investigate and fix one axis at a time. It is most likely the step phase that is wrong. If you change the direction phase, then the axis will run the other way. Don't touch the direction settings.
Only make one change at a time before testing as multiple changes will just hide and confuse the problem.
It would appear that when you reset, the transition to the initial state is being used a step pulse, so at reset all is out by one step, depending on which state the direction pin was in.
The driver spec should show clearly the transition timing and setup times (how long the direction pin has to be stable before a step transition) required.
Read The Friendly (F=!%&@**) Manual

[saltybugger]

Problem is only on the x axis. not ever the z axis. I'll try changing the step today.

[saltybugger]

did not change the error issue. I have tried flip flopping both the direction and step individually while reversing the motor if needed and no change.

After homing the machine I setup a program this morning to cycle the table x-1 x+1 about 100 times then return to 0 and it returns exactly to the home position without the home error...so it's got something to do with the software telling it to go home or the g92 command

[neilw20]

I assume you are running imperial, and some rounding errors are likely.
Try dry running the machine in metric with a converted program.

If you are referencing the machine multiple times this is a very likely cause.
Because referencing is not accurate, due to contact bounce on switches it is quite possible that the stepper motor(s) start on a different step.

If this id the problem, reference ONCE at power up and no more.
I only ever reference at power up, then run soft limits. Never missed a step yet.

[mactec54]

whats the reason for a G92, You don't want the machine going to home after every operation try G90G0 Z---X---

[saltybugger]

I'm not a g code guru this software was written by one, but it's my understanding that the g92 is used to reference a new start point for the x axis which has a tool on each side of the part. The tools are not in the same position on each side of the part and one side is positive while the other is negative so I think this is where the machine goes back to each time to run it's cycle on each side-there is an offset for the left tool and one for the right then a g92.1/g28 after each cycle command per side.

Does that make sense?

[mactec54]

No It does not sound right at all, You should not have to do a G28 after every move save your Gcode in a txt file like MS word & you can post it here I will take a look & see what can be changed. A G92 is programming of absolute zero point

[saltybugger]

no the g28 is only after it's done doing all the moves on the left side of the table then it changes the offset and goes to the right side tool which after that's done also has a g28/g92.1 command.

It's at the shop but I'll cut and paste it tomorrow here and you can see what it does. There was a specific reason why it was done like this and it has to be done in a particular order. If I remember correctly when the machine was first setup with this program he wrote to make it easier for me to do the coding on the fly there was an issue with having all 3 axes move back to home at once-it ran extremely slow because it was having to turn the a index at the same time as the x and z.

more tomorrow thanks for your input and happy gobbler day!

[neilw20]

When multiple axis move the slowest axis controls the speed.
Because the a axis units are probably degerees the feed rate will make it slow.
If you have the a move on a separate line, with its own feedrate it won't slow the others.
caveat. Other asxis don't move while A is moving, but at least the feedrate is not slowing it. I have a similar issue.
It sounds like better use of G59 Pxxx (xx=1..250) will mean you do not use G92.
Mach3 documentation says G92 may be used internally and should be used with care (if at all).
I never use G28 either.
If you need relative moves with G92, just do it all within a few lines and then switch back to absolute after the relative move. Don't leave relative turned on when not needed. Really, avoid G92. old habits die hard. Use G90 as it was intended. (it probably fiddles G92 internally during a relative move, so don't confuse it.
If you have any inline maths computations, rounding errors can sneak up on you. Multiplication OK, but be careful with divides. Multiply by a fraction is usually better than divide by a number. Use 4 decimal places with computations.

[saltybugger]

Yep that's exactly what we did with it, the a goes to zero first then it g92.1 and g28. I'll post a sample file up tomorrow and you can see what it does.

[neilw20]

Read 10.7.27 of the Mach3 manual. G92 details and 10.7.26 for G90.
in conjunction with G28 / G30 10.7.10, 10.7.11 and G52 10.7.16

The Mach3 pdf does not allow cut and paste, and I am a lazy, typist.
I am sure this is where your problem lies. Something is being executed that is not necessary, or the Mach3 is in the wrong state when executed.
I note that your 100 off test was perfect.

[saltybugger]

I think your right but I think my eyes just glazed over worse than a jelly donut

I'm going to have to read up on this some more.

[saltybugger]

Ok here's a sample file. I can't get any of the disks in the shop to work due to the wood dust....ugh. All typed by hand. Putting what I know it does in parenthesis.

g92x-2.5237 z-2.7247 (set coord for spindle 1)
m8 (spindle 1 on)
g0 x-.630 z-1.086 (rapid to edge of stock)
g1 x-.14 f12.0 (spindle 1 move in)
g0 x-.630 (spindle 1 move out)
a180. (turn stock)
g1 x-.14 f12.0 (spindle 1 move in)
g00 x-2.5237 (rapid back to home/original position)
m9 (shut spindle off)
g92.1 (offset coord)
a0.0 (return a index to 0)
g28 (cancel offset)
g92 x1.2609 z-2.7796 (new spindle 2 coord)
a90.0 (a index turn)
m7 (spindle 2 on)
g0 x.632 z-3.19 (rapid spindle 2 to edge of stock)
g1 x-.15 f15.0 (spindle 2 move in)
g0 x.7 (spindle 2 out)
g0 z-2.609 (reposition spindle 2)
g1 x-.28 f15.0 (spindle 2 move in)
g0 x1.2609 (spindle 2 return to start position)
m9 (spindle off)
g92.1 (offset coord)
g00 a0.0 (return a to 0)
g28 (cancel offset)
m30 (rewind)

[neilw20]

I use multiple offset tables like G59 P15 for table 15, G59 P20 for table 20.
you could use P1 for spindle 1, P2 for spindle 2 etc.
Each table can have any or all offsets different, so changing form one to another that has all the same offsets, except say for a Z difference for a different tool achieves the desired continuity of numbers for the human.
Once the offsets have been set, they can be persistent if setup that way in the config screen.
These offset are effectively offsets from machine zero, but you don't even need to worry about that. Just reset as suggested below.
No G92s or G28, G30. Just G59 Pxxx to change offsets, and this does not cause any machine movement. Just the coordinate system reflects the new offsets.
To cancel back to machine coords I think is G53, but I never use that.
I just move the machine to my desired reference point, with Pxxx selected, and zero all the axis.
Some machines have had whacky tool change cycles that can screw up or reset the coordinate system.

There are definite advantages doing it this way.
It is bad programming practice to hard code tool offsets in a program.
Apart from being able to select a tool a program should not need to know anything other than the tool number.
The tool offset is machine dependent, and should be a part of the machine documentation. Not in some long lost program.
All the program needs to document is the tool description, to ensure that the human makes the tool available - in say 2 years time, and with a new operator.