Advanced Search

pgf wrote:

 Given that the length of the bit is variable, there is no single actual lower hardware limit. It depends on how far the bit protrudes from the collet. Given that, what's the use of the limit? When would it do me any good?

Adding an upper Z limit switch is usually pretty easy and makes it easy to use Linuxcnc as intended. eg Work in G54 offsets.
Normally, you would jog down so the tool touches the workpiece and set your g54 offset. 
Using work coordinates eg G54 was my biggest learning.

You have to remember you are dealing with cartesian coordinates.
You can home to any corner you wish. Homing to the lower left of the worktable means all x,y coordinates are in the positive quadrant.
Homing to another corner will mean at least one axis will count in the negative direction. Think of the graphs you drew at school

I did have a machine where the home switch was at max Y but I added a home offset to make the home position at min Y
Thinking about it after using it, I realized I could have homed it at the home switch position so the Y axis would count in the negative direction beecause once you zero G54 offsets at lower left on your workpiece, everything would count in a positive direction anyway.

tommylight wrote:

I have plenty, you are welcomed to use them, but i can not guarantee the quality! They do chew on everything in the shop though, seem pretty healthy by the looks and the speed they move through the shop. 

I had one but I bought a better mousetrap and the offending rodent was dispatched in under an hour!
Anybody want a used but battle proven mousetrap I no longer have a use for?

Just to be sure about this...where are the limit switches physically located in relation to the travels?

With the table all the way back and to the right?

[Sorry for the following Wall-O-Text, but I got on a roll ]

OP-
Incremental encoders have a resolution which can be expressed either as 'lines' or 'counts'.

In the case of a wheel with slots, each opening is considered a line.  For optical glass encoders, a line is one of the etched or printed black lines on the encoder disc.

If you have a 1000-line (or 1000-count) encoder, that means the disc has 1000 of these interruptions in the optical sensor/reader.

What causes things to get a little confusing is that the drive doesn't just sense one pulse for each line that passes the optical sensor.

There are two sensors in the read head, and one is slightly advanced from the other.  Both of these sensors send signals to the drive, and we call them the "A" and "B" pulses.  So that's two pulses per physical line on the encoder disc.

But it gets better... the drive can sense the rising edge of each electical pulse, as well as the falling edge.  For example, when a line goes past the A-sensor the drive sees a voltage change from 0 to 5v.  Then when the line gets all the way past the sensor the drive sees a transition from 5 to 0v.  Each transition - 0-5 and 5-0 - counts as a 'pulse' to the drive.

Same thing is happening on the B-sensor, and since the A-sensor is advanced a little bit from the B-sensor, the drive can count 4 pulses for each encoder line.  So we basically get a 4x improvement on encoder resolution for free.

Since your motor has a 1000-line encoder, the drive expects to count 4000 pulses per revolution.  This where the "1000/4000" jargon I dropped on you earlier comes from.

www.motioncontroltips.com/faq-what-do-x1...ncremental-encoders/

You can imagine what happens if the drive is programmed to expect 4000 pulses per rev, but the encoder is a 800-line (or some other non-matching value).  The drive thinks the motor is spinning at a different RPM than reality, and the motor magnetic poles don't line up with what the drive has calculated should be the case.  The drive won't turn on/off the coils at the right time, and the motor might turn but would make noise and not move to the correct position.  A significant mismatch would probably result in the drive erroring out.

That's why I suggested checking what value the drive was programmed.  It was unlikely there was a mismatch as most of (if not all) these cheap closed-loop steppers have 1000-line encoders so the drives are generally programmed for 4000 pulses, but it doesn't hurt to check while you're in the tuning software anyway.

You do NOT adjust the 4000-pulse encoder setting in the drive, regardless of the INPUT steps-per-rev setting in the drive (or in LCNC).  That encoder number is explicitly determined by the encoder on the motor.

Input steps per revolution on a programmable drive can be just about any arbirtary number.  While the motor has 200 physical steps (positions) due to it's construction, you can program the drive to move however far you want per input pulse (not encoder pulses).  If you program 1ppr input, then the motor will turn one full revolution for each pulse.  If you program the drive to 3157ppr, it will move 1/3157 of a rotation per input pulse.

Setting the drive to a higher input ppr than the encoder pulses means the drive is just guessing - the encoder resolution has to be higher than the input pulse setting for everything to work cleanly.  You can set the input higher than the encoder in the software, but there's no way the drive can accurately move the motor exactly where you want it because the drive has to guess where the motor is between the encoder pulses.

Older, non-programmable stepper drives were limited to either 200 input steps/rev for a 1.8 degree motor, or some multiple of that native 200 selectable via dip switches.  So when you see '4x', '8x', etc. that means you got to pick 200ppr, 800ppr, 1600ppr and so forth.

If after you take in to account the mechanical transmission (ball screw, belt ratio, etc.) the math didn't work out cleanly, you wind up with some strange number of input steps per machine unit (inches, mm, degrees).  Thats how you get from a drive set to 8x (1600ppr), through a 3:1 belt, and your units are in degrees (1/360)... so you have to tell LCNC to output 13.3333... steps per degree of spindle rotation.

LCNC can't output one third of a step, so whenever you have a non-whole number of steps per unit of measurement, there's a bit of "ish" involved with where the motor lands. LCNC doesn't lose track of where it is, but it can't move the motor exactly where you want.

However... if you program the drive with an input ppr that results in a whole number for each machine unit - degrees in your case - then LCNC can output a number of steps/pulses that can resolve to exactly one degree.  For your belt drive, that means 1200ppr at the drive input results in 10 steps per degree - a nice whole number which means LCNC can resolve to 0.1 degrees per step.  And 2400ppr gives you 0.05 degree per input step resolution.

Remember a few paragraphs ago when I mentioned keeping the input ppr lower than the encoder resolution?  Both 1200 and 2400ppr input values are lower than the 4000 pulse encoder, which means the drive would still have a chance of positioning the motor fairly accurately.

You machine isn't going to actually be 0.05 degree accurate due to variations in the belt, pulleys, friction, lost step here or there... but your INI file will certainly look neater.

Hope that helps.