Retrofit of Precix 5x10 CNC

The most elegant way to accomplish this is, if your VFD can send an "at speed" signal. That signal can be connected to the hal pin "motion.spindle-at-speed", then Linuxcnc will automatically wait after a commanded spindle speed change for that signal to go true before performing any cutting moves. (It will still make G0 positioning moves.) So if you have this set up, and start a g-code file that begins with a spindle start command then makes a positioning move to the start of the first cut and starts cutting. The spindle will start and the machine will move to the start of the cut and then stop and wait for the spindle to finish spinning up to speed, then once the VFD sets that spindle at speed pin true, Linuxcnc will start the cut.

PS: If it is taking a whole 30 seconds for your spindle to get up to speed, something probably isn't configured correctly on your VFD. (same goes for stopping) About 3-10 seconds sounds more normal.

Thanks Todd! Great info.

Not sure if my VFD has that output, it does have an analog output, not sure if would correspond to the ramping issue. Do you think I could use the attached VFD output to make sure the spindle is up to speed?

Also, I will review ramping of the VFD. It's lumbering up to 12000RPM now, and the coasting to a stop even takes a bit longer as i recall.

Was thinking I will check voltage on that pin #6 to see if it climbs as the spindle ramps to speed or if it mirrors the analog input voltage.

Not sure how I can set that up in LinuxCNC instead of "at speed" pin it would have to be "at a level about to the output speed" I know the 7i77 has an analog inputs.

It should work.
I have it set for 3 axis on a mill with yaskawa drives, they output only 3V max for the 150% load so i had it scaled in hal and pyvcp, it can also change colors so it is easy to see from far.
Mesa 7i92 with 7i77 set to mode 2.

So in the few projects I have done with my CNC I have had a few problems where I couldn't figure out what failed.

I have had user errors as well, my bit slowly coming down out of the bit holder for example. That's entirely on me...

Once I turned my machine on hit home and it went super speed Y - until slammed against the limit switch. I checked everything the best I could and couldn't figure it out, so I fired it up, and worked perfect. I couldn't figure out why it did it.

Once I was cutting and taking several passes to get the shape I wanted, first 3 passes were perfect, 4th was way off. It's like the 4th pass was the same shape just moved over 6in. Code looked fine and I ended up running same code on a new piece of wood and it worked perfect..

Today I was surfacing some butcherblock for a project and It went through about 80" of the 90" material before suddenly X minus servo went super fast and flew past the limit switch into the stops. Broke a belt as well.

In Today's example the g code was fine, same surfacing code I have used several times. In fact the screen was still showing it's position where it should have been (around80" over) before it ran away. What I am thinking is the encoder is saying it's going X+ so the power for the servo is going X- to get to it's position which results in it running away until it hits limit switch. Computer was still running normally, only linuxcnc running...

Anyone seen anything like this?

Think it's a encoder connection problem of some sort? computer to 7i92/7i77?
Software setup problem?

I'll have to purchase some replacement belts before I give it another shot.
As always thanks for any input.

That does sound like an encoder or drive issue of some kind _but_ in most cases of drive or encoder errors, LinuxCNC should have caused a following error fault and disabled the drives.

1. Can you post your current HAL and INI files and I can give you some some suggested changes for safety

2. Did you get a following error and are your drives enabled/disabled by LinuxCNC?