Fusion 360 - Lathe Post ??

Muzzer:

That actually makes sense. I never thought the feed might change in lathe work. But historically for a lathe the change gears sets feed in units/rev. It would make sense this would carry through to CNC. But, if this were true, then the G95 in the above example should be in the program start. Up there with G7 and G18, not in the "THREAD" operation.

The only other lathe CAM I've used is in CAMBAM. It is rudimentary only doing external profiles (no boring or threading). It doesn't specify G94 or G95. I've used it with G94, set before starting the G-code program, and it worked fine. But the feed is an input and I input as in/min.

SOLVED: I just ran a few examples in Fusion. This time I started with a 1/2" bar, faced the end, turned down to 1/4", and threaded. And out popped the solution. The facing and turning asked me to define the feed, in/min or in/rev along with a value. Each operation had the G94 or G95 I requested with corresponding feed. For threading it didn't ask, but threw in a G95 just 'cuz. It does fall off the end of the program with G94/G95 as set in the last operation.

I'm convinced G76 and G33 don't depend on G95. G76/G33 grab the encoder singnal and sync to it independent of feed mode.

I ran this program with and without "use cycles" checked. With it checked it gave a G76 cycle, without it gave a series of G33 commands. I can't verify if it generated the intermediate code (*.cnc ?) but I suspect it had to to make the NC code. This was using the LinuxCNC-Lathe post. I could send you the Fusion model but not sure how to go about this. If this might help let me know and we can work through the details.

So thank you. You've solved the G94/G95 question for me. I may add a G94 (or maybe G95) in the closing so the machine is in a known state. But I at least know what Fusion is doing.

Thank you.

Hugh

As you say, it makes sense when you look into it. I've now got my lathe threading, having connected the encoder the right way round(!) but I'm completely unable to make it generate a G71.

To edit the post processor to include a G94, I think you'll want to add it to the "onClose" section which is executed at the end. You'll be able to see the M30 in there. Javscript isn't very hard to understand.

You can save a Fusion file by cicking the file menu (folder icon at top LHS of screen) and selecting "export". This saves it in .f3d format which you can share as an attachment. You could also create a sharable link but that's less portable perhaps.

Another issue I've found with Fusion is that when I change the thread pitch in the model, it doesn't want to change the pitch in the CAM dialogue or the G33 output itself, even if I remove and reselect the geometry. I don't believe this was deliberate but it resulted in my first test piece having a non-std pitch!

Muzzer wrote:

I don't know when the LinuxCNC g code set was defined and by whom but they appear to conform to the "Fanuc Group Type B" 

Possibly the other way round. LinuxCNC is a development of EMC which was written by the US NIST, and they defined RS264NGC.

  www.nist.gov/publications/nist-rs274ngc-interpreter-version-3
 

That's an interesting paper. I see no mention of lathe or G95 in there, so presumably the lathe content came later. As I mentioned, it seems to me that most of the lathe stuff resembles Fanuc Group Type B which itself predates this year 2000 paper. I'm guessing somebody in the EMC / LinuxCNC developer community must have needed to figure out which way to go. I wonder if they are still active here or is that part of the history lost in the mist of time?

Muzzer:

Did you mean G76 rather than G71? I believe I deleted my thread model but would only take a minute to rebuild it. If you'd like I'll try to send you a copy of the model. Send me an email address and I'll give it a try.

When I rebuild the threading model I'll see if I can duplicate your results regarding thread pitch.

Yep, a closing G94 (or G95) should go in the onClose. It would assure the machine is in a consistent state after program end.


I think I remember someone here saying EMC was based on an long ago G-code and still is closest to that company's control language. I swear I remember this, but know for a fact my memory is poor. Seems to have all started around 2000 for hobby use. I remember spending 3-4 12 hour days getting EMC running from floppies around this time. I'm pretty sure it had no pre-coded lathe functionality then.

Wikipedia says about G-code "The main standardized version used in the United States was settled by the Electronic Industries Alliance in the early 1960s". But that group wasn't called that till 1997, they may mean its predecessor "Electronic Industries Association". It seems the EIA put out a "final revision" in 1980 as RS-274-D. They go on to say the market between 1970 and 1990 was dominated by Fanuc (in the USA), and many manufacturers based their controllers on this. Fanuc G-codes, circa 1996, sure look familiar. It includes G33 and G76 for turning. I think this was in place when NIST came on the scene. Whatever sources they started with they began development of EMC (LinuxCNC) for us. Cool.


That was an interesting diversion. Now back to something productive.

Thanks.

Hugh