[benjaminellison]

Hi all - so I finally got my cnc put together (kickstarter CreationStation - quite the saga and I was lucky to receive one). Running linuxcnc - and after a few fits and false starts have managed to start making chips (yay!). I've been using Vectric VCarve Pro and one of their tutorials (a vcarved sign). For some reason while cutting with the vbit the router takes an unexpectedly deep z plunge and just start trying to keep cutting from that point (and I have to hit e-stop). I've double checked the collet and it's tight - bit isn't slipping. I quit and re-started linuxcnc but it did it again. Any thoughts, suggestions, or pointers you can share? I believe it was doing the same thing with the test code that the creator linked from his assembly instructions... cutting along fine then a sudden plunge.

If you don't think it's likely a linuxcnc issue, please suggest the appropriate forum & I'll repost this there.

thanks!
--B

[NitroCH3NO2]

Sounds as if you have a Z tool length offset set in the tool table and it is being used in the G-Code. If you are using just a single tool per G-Code file you can set your tool length offsets to 0 in the tool table and just touch off the tool to the part.

[RCaffin]

To misquote James Bond (or rather Goldfinger):
If it happens once, who knows, but if it happens twice at the same place, I would strongly suspect the code.

Cheers
Roger

[benjaminellison]

Thanks for the tips - I'll check out the code & tool table, and maybe try cutting some simple nested circles (or a dust boot, lol!) first.


Sent from my iPhone using Tapatalk

[jthornton]

LinuxCNC does what it is told to do by the G code. Look near the line of code where you hit the estop for a Z move.

JT

[benjaminellison]

A bit more research and mdf - I'm pretty sure it isn't a problem with the gcode for the following reasons:
a) the 'plunge' happens at different points when I rerun the code
b) I've run it through several simulators and they all look fine

I saw your comment on the tool table, Nitro - I haven't zeroed it all out, but due to randomness of the issue I don't suspect it's the table.

A very interesting observation that leads me to believe it isn't as likely to be the actual CNC machine, either: last time it decided to take a nose-dive into the material I was able to pause/soft-stop the cut and back the bit out. When I placed the point of the bit on the top of the material, my DRO read almost exactly 0.25" -- it should have been 0.0", because I had both homed & touched off to the top of the material before starting the job. So perhaps somehow it magically rehomed? Does the software do that on the fly?

An additional point... I haven't been able to prove it yet (reflexes aren't as fast as gcode scrolls, and monitor isn't where I can see it when I'm paying attention to the router), but I *suspect* the issue comes up after a rapid - but not consistently. This might be a red herring, though.

Am I just doing it wrong? I have a couple pieces of MDF screwed to another board that is bolted to the table. The intention is to cut the top-most piece of MDF. I place the tip of my vbit at the very corner of the MDF, right where the point is touching the surface. I home X, Y, and Z, and then Touch Off Z as well. Then I hit run.

[benjaminellison]

update: I just tried it with some gcode output by a different program (halftoner) w/o a post-processor and it looked like it was going so well - but it didn't stay that way... part way through again it plunged. This time I was able to isolate it, though, due to the straight-forward gcode. It *does* happen seemingly randomly right after a rapid. I'd pull bit out, touch off, and restart from current line... it would run for a while then repeat the error. It happened a total of 3 times over the course of the one file (a 11x11" halftone line done at 45 degree angle).

Edit: Oh - and plunge was all approximately (as close as I could measure) off by the same amount - 0.2" in this case - which leads me to think that it might not be missed steps, because wouldn't that be off by random amounts?

[tommylight]

Lower the "max velocity" down to 300-500mm/min (10-20 in/min) and let it run at that speed, if you get the plunge again, your z axis is binding or underpowered motor/drive, if all goes well for sure you have an underpowered motor or drive.
Tom

[RCaffin]

So perhaps somehow it magically rehomed? Does the software do that on the fly?

Bain't no magic there...
And no, I don't think anyone has ever had Mach3 do that consistently. I think we can say it's NOT the SW.

I suspect Tommy has the answer. If it is happening straight after a rapid, then your Z axis motor is in trouble. Whether the Z axis motor is underpowered or whether the power supply is sagging during the rapid move - I cannot say. My first guess would be the power supply if it always happens after a rapid - which places the biggest load on the power supply. I would put an ANALOG voltmeter on the power supply and watch it carefully while doing some dummy runs.

Dropping the maximum rapid speed right down and testing the system would also give a big clue.

Cheers
Roger

[benjaminellison]

Lower the "max velocity" down to 300-500mm/min (10-20 in/min) and let it run at that speed, if you get the plunge again, your z axis is binding or underpowered motor/drive, if all goes well for sure you have an underpowered motor or drive.
Tom

That may have done the trick! I tried a file where I replaced all the G00 z-Rapids with G1's and it worked. I tried one of the earlier files with max velocity set to 16 in/min and it appears to have worked as well. But boy, was it slow! I tuned/calibrated the z-axis on the driver board (cranked up until it stalled & backed off a skosh so it would run) and will fiddle with it some more.

Is there any way to adjust that max velocity (or similar) for just the z-axis so the entire job doesn't take quite so long?


Sent from my iPhone using Tapatalk

[RCaffin]

If you are using Mach3 you can set the max speed for each axis separately. It's under Motor Tuning.
But is the power supply holding up?

Cheers
Roger

[109jb]

You can set the max velocity individually in LinuxCNC too. Either edit the .ini file manually, or use the stepper config program to edit the existing config.