G-code?

[Garyhlucas]

I think I have a little experience at this level of discussion. I am currently active on the Practical Machinist, Mach 3, Home Shop Machinist, CamBam, and Reprap forums, worked as CNC programmer, bought the CNC in our shop.

I built my own 4 axis CNC in my garage running on Mach 3 with a motion card. A DL06 handles all the button functions, switches between the R8 spindle, router spindle, lathe spindle and 3D printer extruder. It also controls printer bed temperature and extruder head temperature.

A couple of weeks back I bought a Chinese 3020 router and built a test tube rack for it. I modeled the rack in SolidWorks, programmed the shop CNC using CamBam to cut out the 144 holes and then imported the same geometry into a cheap TopCNC TC55H CNC controller. 3 axis of control to move from a drain port to each tube and a 4th axis running a peristaltic pump to pull the sample and accurately dispense into the test tubes.  Works quite well except all programming is G-code only.

That's it??   

No.  But real work interferes at times.

[BobO]

Someone mentioned 3D printers. The g-code for that far exceeds the memory of almost any PLC. I've cut some simple 3D shapes that took 80,000 lines of G-code, but a 3D printer program can easily run to millions of lines.

One option will be streaming from files on the SDCard. Quite sure that you'll be able to fit what is needed. That certainly isn't our market target though.

[Garyhlucas]

A couple other thoughts. G0 and G1 are modal, once called all motion occurs at rapid for G0 or feed rate for G1 until you call the other. G90 and G91 are important, G90 is absolute motion from a defined origin, while G91 is incremental from the last location. This also concerns G2 and G3 and how the arc center point is defined. Typically using I,J,and K respective to X,Y, and Z. Then various systems use either incremental or absolute referencing for I,J, and K. You don't need both but you have define one or the other.

Just had a great thought. Download the full version of CamBam and use it to create some G-code using any of the post processors supplied. Then you can see exactly how a drawing gets processed into G-code. It costs $150 but you can install it and run it free for 40 sessions that last all day before it reverts to a limited demo mode. I think you'll learn what is needed and what is not much quicker that way. It'll also generate test code if you decide to move forward.

[BobO]

Another Hostie is a full blown machine tool guy, and he has one or more packages. Not sure which, but I'm sure I can get what I need. Will definitely look into CamBam as well.

It's probably an irrelevant implementation detail, but we won't be running G-code at the PLC. My current plan is to have a conversion utility that will read G-code and convert to what amounts to a time-based multi-axis position cam; the master axis 'position' will be microseconds, which will drive up to three slave position cams which are utility-generated to give you coordinated motion at the specified feed rates. As far as you are aware, you are running G-code, but this approach allows me to use the existing cam solver to do very complex stuff with almost no computational hit.

That also gives me the luxury of continuing to enhance the conversion utility over time, with no changes to the firmware. We'll be able to add as many codes as makes sense. PLC won't know or care in the slightest.

[BobO]

Modality is interesting. The files I've been playing with use a G1 or G0 on every line, but I have seen others that did G0 or G1 with axes on one line, then just axes on subsequent lines. That isn't hard to parse, but it implies that each line is a single command and must be well-formed within the line. That's a different parsing approach to languages like C where line breaks really don't matter, but of course there is no modality concept in C.

And all of this is made ever more fun given how 'standardized' G-code is. I'll probably pattern after a well known and well supported open source target like grbl. If I can see the parser code I stand a better chance of not messing my implementation up. In the end, I don't guess it matters as long as most CAM packages have post processors for whatever we choose.

[Garyhlucas]

Lots of G-code stuff comes from the old paper tape days, and then really underpowered CNC controllers. Modality saves memory, lots of CNCs work fine without line numbers too.  I used to program a Bandit controller.  4 digital numeric displays, X,Y,Z and G-code or M-Code number and some red lights indicating G, M, F etc. Really user friendly.

The other space and programmer saving things were canned cycles, like G80,G81,G82, which were drilling cycles that did depth,peck, chip break and such. Then there were G70-G79 range cycles for things like circular pockets, rectangular pockets, mirroring, rotation about an axis and such.  When writing code by hand these things kept you from going completely mad as the code that would replace them would be thousands of lines. The G40, G41, G42 codes do tool radius offsetting.  That was nice because you could program a 2" square pocket and cut it to size by calling up a tool number and radius, and the toolpath would move over to compensate. Subroutine calls were useful too. No standardization on that at all!  One machine I worked on, a Fadal actually used MBasic for macros!