Messages

1281

General Mach Discussion / Re: Opinion and advice - explain relationship of encoder to kernel speed

« on: April 10, 2009, 05:17:46 PM »

Timing belt drive with idler, so no backlash, but i can see the idea needs more thinking through.

A 200 line sensor puts out 800 pulses . .  interesting . . quadrature?  The formula seems pretty straightforward, thanks!

Putting a sensor on the axis is not practical, but I could either use an encoder with less steps . . say 50, and put the encoder on the motor, or run off a larger idler and gear down to the encoder. I have seen huge machine tools that wof that way with the encoder driven off the lead screws with tiny timing belts.

From the speculative responses so far, I take it that a servo driven 4th axis/pseudo lathe is not common?

1282

General Mach Discussion / Opinion and advice - explain relationship of encoder to kernel speed

« on: April 09, 2009, 10:05:18 AM »

I have a stepper powered 4th axis (shown in the show and tell section) that I am considering converting to servo power so that it can be used on the mill as a pseudo lathe.

Currently I have a 10:1 reduction and a 10,000 RPM DC motor to use which would net a max 1,000 RPM which is adequate for my purpose. I can install the encoder wither on the motor or on the belt drive idler.

First, I wonder if anyone is doing something similar and if it is considered viable.

Second, if I put a 200 step encoder on the motor, there would be a max of 2,000,000 pulses per minute. What kernel speed would be needed for that and in general what is the relationship between the encoder steps and kernel speed?

1283

General Mach Discussion / Re: Subroutines broken in 42.023

« on: March 30, 2009, 03:34:11 PM »

If I remeber correctly, .43 broke the 4th axis.

I posted that some time ago, but now I cannot find the thread.

Since there is no version change and it is still  .43.00, I assume it is still bropken?

It seemed the thrust behind 43.023 and .24 was to fix threading. Does threading work in 43.00?

1284

General Mach Discussion / Re: laptop use

« on: March 27, 2009, 04:23:31 PM »

FWIW, I used a laptop for quite a while.

The power saving feature is the problem . . . even if it is running off the wall current. On my laptop, all power saving features could be disabled in the bios. Once done, no more problems, but the 1.2ghz VIA processor would occationally peg and then the motors could stall.  I figure that the VIA CPU is not good with with math functions.

I'm running now of a really old dual P3 server. I set the Mach 3 process to 'real time' priority for one of the CPUs. Works great and never gets close to pegging the 850Mhz Intel processor.

1285

General Mach Discussion / Re: Swarf in Keyboard and Mouse!! Ahhhh!

« on: March 27, 2009, 04:11:17 PM »

I bought one of those silly silicon roll up keyboards and it works great for the purpose.

As HimyKabibble states, It's not something you want to do a lot of typing on    , but like Hood, I do 99% of my work on a separte (and powerful) desktop machine and just shoot the finished G-code to the machine tool, so I don't care how weird the keyboard feels, so long as it survives tha chips and oil.

So far so good.

1286

General Mach Discussion / Re: Subroutines broken in 42.023

« on: March 27, 2009, 03:57:22 PM »

Attached is one of the programs that is effected.

At return from sub, next move commandis ignored.

Works fine in .021

1287

General Mach Discussion / Subroutines broken in 42.023

« on: March 23, 2009, 09:09:04 AM »

Ignores G0 move on next executed line after M99

1288

General Mach Discussion / Re: Motors stalling, losing steps

« on: February 09, 2009, 05:52:59 PM »

Comments on the 'tick' from motors:

Something I noticed about Mach3 is that manual jogging behaves differently than running Gcode. This was explained by others on this forum as a Mach 'rounding' process.

I can only speculate on this issue as the programmers did not weigh in on that thread, so anybody's guess is as good as the next.

The behavior though is not speculative as it is observable. If I set the jog distance to 1", the jog will be a few thou short and then make it up on the next jog, then be short again, then make it up again later. Yet if I enter Gcode to go to sequential coord's 1" apart, the error is not present and the movement is dead accurate.

So it would seem that Mach uses different methods with jogging and with Gcode moves.

This is only speculation on my part, but if Mach jogs my stringing short moves together, it would have to make up the shortfalls as it goes along . . which at certain speeds might manifest as a 'tick'.

1289

General Mach Discussion / Re: Motors stalling, losing steps

« on: February 09, 2009, 05:40:24 AM »

The correct settings for the 203v (which are opposite of all other Gecko drives) are found on www.geckodrive.com along with a bunch of other useful info about CNC mechanics in general. Definitely worth a read.

Two thoughts:

I wonder if one possible cause of a regularly spaced 'tick' might be the system adding or subtracting an extra step to correct for rounding if the drive ratio is something odd that slowly gets off-step.

Is there anyone who has used a third party add-in parallel port that is known to work with Mach3? That would be great info to post.

I have experienced the motors skipping/stalling/grinding in two instances:

A wireless network adapter very definitely caused the issue. Unplugging it from the USB port instantly stopped the problem.

The computer reaching 100% CPU utilization also caused the symptom. It is likely that any process that interrupts the CPU with polling or 'wait' type operations could also cause this. In my research on steppers, it seems to me that they cannot recover from  receiving a step command that is out of sequence with the previous command, so in addition to the obvious timing sensitivity, any lost or out-of-order-step commands are going to stall the motor.

I suggest as a general rule to go into the task manager (right click on task bar) and set the mach3 process to 'real time' which is the highest level of priority. (right click on the process) This *should* prevent other processes from suspending Mach3 long enough to cause a problem.

Make sure the PP is set in the bios to the correct communication type as required by your BOB . . presumably the highest setting.

1290

General Mach Discussion / Re: Motors stalling, losing steps

« on: February 08, 2009, 06:20:44 AM »

Unless you are mis-typing, or I am missing something, you still are off by a factor of 1,000 on your set resistor.

For the 540, your set resistor should match your motor's draw amps times 1,000.  So if I remember right your motors in series draw something like 2 amps, which would call for a 2K (two thousand) ohm resistor.

I'm no expert in electronics, but it seems to me that a 3.3ohm resistor in this application is equivalent to not having a resistor on there at all. I can tell you from my experience with my Gecko 203v drivers that they are very sensitive to having the correct resistor. Bumping and stalling is the symptom of the wrong resistor.

As to your computers, you might check that there is no software polling the parallel port as that could cause the rhythmic bumping that you are getting.

Look for things like printer drivers, antivirus, spoolers, etc. that talk to the parallel port. Make sure your parallel port is set to the highest communication level in the computer's BIOS. If it is set for a printer, it will likely cause trouble.

Other things to watch out for: wireless anything, network, keyboard, Xbox360 controller, phones nearby.

Again, not being a electronics whiz, I would still have to second Hood's comment that the caps may be more effective on the drivers rather than the power supply. I have them in both places, calculated, again as Hood suggested, based on the motor draw.