Retrofit of Precix 5x10 CNC

Yes, you can check your sensors with this method. Using an M66 in your tool change g-code to check the status of the pin from the sensor.
linuxcnc.org/docs/html/gcode/m-code.html#mcode:m66

But I would not only rely on that. I would recommend programming some logic that always checks the status of the sensors when the spindle is commanded to run, and sets an alarm and stops everything if the sensor status isn't correct. This is how all the machines I've worked with were setup from the factory.

Quick question regarding spindle speed. My VFD is set to RAMP up pretty slow, which was how it was set. Also, when it stops it coasts to a stop, both of which can take quite a while.

I found this:
www.linuxcnc.org/docs/2.4/html/examples_spindle.html#r1_5
Is that the best practice to bring the spindle up to speed before cutting?

I almost put a 30 second pause in the G code, just figured there was a more elegant way to do it and wanted to make sure the "soft start" was still the proper way to do it, or maybe I just didn't have my info set properly.

thanks as always!

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.

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?

Thanks PCW, always appreciate your help!

1) Here are my hal/ini files, let me know if you'd like to see anything else.

2) Yes, LinuxCNC enables the drives. AFAIK

It isnt' going to fix your problem, but your FERROR and MIN_FERROR are both much too large for your X axis servo. Probably should both be some fraction of an inch. (maybe 0.1 and 0.01)

An encoder fault won't necessarily cause a following error alarm during a run-away. For example on your X axis with the 5" ferror, if you command a 4" move and Linuxcnc does not detect any movement from the encoder, you now will have a run-away at the fastest speed your drive and motor can do, until it crashes.