I set up a pocket operation and proceeded to run it on my LinuxCNC. What happened was that the pocket operation took place at the same speed as the plunge speed, NOT what I set up as the feed rate.
I am uploading the MillMage file as well as the NGC code it produced.
BaseTable3.mage (25.9 KB)
BaseTable3.nc (5.6 KB)
I also think this is related to my previous post about having to add the user code of F120 to make this run on LinuxCNC. I’m convinced that the post for LinuxCNC has a flaw here…
I looked at your .mage file and the playback showed a slow 120mm/min feed rate. The generated gcode also shows F120 as the feed rate on the pocket operation (and the only feed speed).
When I picked a different 1/4in tool from my library the feed speed went up to 1000 mm/min. I also use LinuxCNC as the machine type since the Buildbotics controller is reportedly a LinuxCNC fork.
Try creating a new 1/4in tool and selecting that for the pocketing operation to see if that works.
I’ll try again on the morning, been a long day. Thanks. Though I have had this same problem with drilling holes with a different .25 drill bit
Ok, Added a 2nd pocket operation, selected the pockets, add the tool, still got the same result… no feed output for xy axis.
BaseTable3A.nc (9.4 KB)
BaseTable3A.mage (27.3 KB)
I just noticed that you are running an older beta based on your screen shot…
The current beta is RC4…
I’d suggest downloading and applying the latest beta in case this issue has already been corrected.
The current beta, available on the web site, is what I get when I go to HELP _> Check for Updates
I guess it is a MANUAL search for new betas .. or I am still running pre-release candidates
Here’s a link to RC4: Home - MillMage Documentation
Loaded… still not happy
Note on new RC4
Weird error messages pop up now.. and program has an issue that needs to be reported..
But . still no speedup on the Operations
BaseTable3D.nc (5.6 KB)
BaseTable3D.mage (27.3 KB)
Are you the developer? If so.. I have more to report as bugs
I reopened your mage file and had the same slow feed rate in preview. So I deleted the pocket operation, and added it back and it’s much faster.
I seem to remember during one of the recent updates that it was recommended to delete/readd the tool library due to some breaking changes.
I’m sure one of the LB support team will jump in with some comments…
I shall retry tomorrow. Thanks.
I also deleted everything in that project… Added the pocketed operation. No dice. Created a new device…redid…no dice, there has to be something fundementally wrong with my set up weird window pops up when trying to export the code, and when I press cancel on that window…it goes ahead and exports anyway…
Hi Paul - it looks like you’re on Beta 15, would you please try the latest Release Candidate (Currently RC4) and let us know if it happens still?
Ah, I see. My bad, I didn’t read thoroughly enough.
It appears that the pocket is using the Ramp feed, upon further inspection, I’ve passed this along to our devs to confirm and (if confirmed) fix.
Well… I got rid of that pocket, I got rid of the USES TOOL, and I don’t get that weird error ( I still think that is an issue… )
This is a Clean pocket, using PLUNGE, not ramp. Using a clean tool… No feed.
I wonder if my post for LinuxCNC is messed up? I don’t know where it is stored, I thought I could User Edit the post, but I don’t know where that option is on RC4
I had also made a brand new spanking device for the run.. which should have generated a fresh post.. should have
I will upload the clean tests ..
Test3c.nc (674 Bytes)
Test3.mage (7.0 KB)
And I confirmed that I have it set to PLUNGE not ramp
Oops too much screen dump .. but you get it
This is actually as designed, but I’m willing to debate it.
When running a pocket, the first outline after the ramp or plunge move is full engagement, not having the benefit of reduced chipload from stepping only partially over the preceding pass, so I set it up to run that initial outline using the ramp rate.
Your pocket is more of a profile, since it never actually “steps over”. If you make your example “pocket” taller, so it actually has stepovers, you’ll see this:
First outline:
Subsequent outline:
I can possibly see that.. well.. no.. not really. If I have a nice super rougher bit, like what I am using, “The Beast”, it can more than handle the load on the system… it should run at the speed I indicate it in this case. So, unless I am doing Metal, I generally with a rougher, opt for a plunge operation.
And I think someone missed the other part of this issue… On LinuxCNC, if you don’t put in that Feed rate on either first X or Y axis move… LinuxCNC will NOT proceed. It thinks the gcode is in error. So i get bit ( Oh that was a pun! ) twice.
Had that issue on Pure Drill functions as well.
Playing devil’s advocate, why bother to have a ramp rate then? If you made it ramp at 600, and set the ramp angle relatively shallow, that would solve it too.
We could add another “full engagement” feed rate, which is probably the correct way to handle this.
Regarding the GCode, the first G1 move in the file has a feedrate specified. G0 moves shouldn’t require it - are you saying on LinuxCNC they do? (I’m looking at the .nc file on your last post)
Actually, if your machine needs a G0 feedrate specified, you could just edit the GCode header to include G0 Fxxxx and set that to whatever you want your rapid rate to be.
That would be in Edit > Device Settings on the GCode page.
Also, I was thinking, I have done a lot more CNCing on metal long before I started lasering ,… I gave up metal CNC back in 2017 and been targeting mainly wood since that time.
Most of the time, I use this particular operation to do slots. A slot is a very narrow pocket, generally slightly bigger than bit width mostly. In my example, So those 8 slots are normal for a lot of the work I do, and if I am in a production mode, that would slow me down a lot. I generally use a slow plunge and fast moves for slot gouging.
I have never really ran into a CNC program that overrides the machinist input. Perhaps warnings.. but never override. Now if this was solely meant for beginners… I might agree with that. I don’t remember any option based on roughing bit or not in the tool. I have to verify that.
So I would beg to honor the settings for the tool selected. Possibly in “Beginner” mode, those would trigger some warnings.. Just saying. For now, I can run the Gcode through my converter and add the feeds in programmatically. So now that we identified my issue, I can get around that.
Plus I still had the legitimate issue with having a tool changer.
Thanks for helping here.
