3.5 Million Lines of Code - I Didn't Even Know

[Bob La Londe]

I mention from time to time the first time I cut over a million lines of code on the Taig mill. It was really when I was just starting out CNC machining. I slept on the floor in the shop because the Taig was so unreliable while it ran 1.3 million lines of code for 30 hours.

A few times I've mentioned a 5.6 million line project that was run in two files of 2.3 million lines each. I thought that was the largest code file I had run back in 2017. 2.3 million lines of code in one go.

I have been looking at that all-in-one 4 axis offline control another person mentioned, and I was curious about its memory limitations. I think it uses a 4 GB USB thumb drive for program memory. For some reason my brain wasn't adding things up so I went to my machining folders and did a search for NC files, then sorted by file size. I wanted to see if that was enough storage for my biggest programs.

Imagine my surprise when I found a project I had not thought of was the largest NC file I've ever run. When I opened it up and scrolled to the end it turned out to be well over 3.5 million lines of code. I shipped that completed project to a customer in the Ukraine back in early 2018. 6 years ago. I remember it took all of a very long day to cut, but it was in 4140HT steel with finish passes using very very small cutters. I figured it was just because of the reduce chip size and feed rate. I didn't know until a few minutes ago how big that code file was.

So... I can tell you first hand that Mach 3 will run atleast 3.5 million lines of code if the computer has the memory, video card, and the processing power for it.

[Bob La Londe]

And apparently basic math escapes me. That was 4 years ago. LOL.

[Mark Rand]

When I was programming full time, I managed 40,000 lines of code a year. That was working 70 hour weeks on average. Error rate was about one error per 100 lines of code, as written and it took the same time again to get the error rate down to 1 error per 1,000 lines.

But that was in a high level language, not G-code.

[Bob La Londe]

When I was programming full time, I managed 40,000 lines of code a year. That was working 70 hour weeks on average. Error rate was about one error per 100 lines of code, as written and it took the same time again to get the error rate down to 1 error per 1,000 lines.

But that was in a high level language, not G-code.

High level like Cobol/Fortran/Basic/C/(etc)? I found writing any of those in a modular manner and testing each routine wasn't to hard. Just tedious. I found mid level programming like assembler to be a lot more fun. I like elegant code solutions that trap errors. I identified more than a few bugs in different bios. You might think going with only OS function calls would solve the problem, but no. There are plenty of bugs in OS function calls as well. I also found that some installation of the same OS release could have subtle undocumented changes in function calls. They would make minor updates, but not modify the release number.

The biggest issue I found was in BIOS calls though was that in one BIOS you could perform a function call and then just keep going. In another supposedly comparable and compatible BIOS you would perform the same function call and it would trash all the registers. They both appeared to work, but one trashed your registers. I used to write code at home and test it on 3 different machines before submitting it for review. I even did a sort of display page swapping before Windows for processors that code execute two instructions simultaneously like the V20. (NOT VIC 20). How many lines of code in a year? No clue. A lot. I would get in a groove and write for 2-3 days straight just pausing for coffee and snickers bars. When I would learn a new language I would immerse myself in it for a few days and do nothing but write and test code. I never worked for somebody else as a programmer, but most of my life I have been self employed learning whatever I needed to learn to do the next project. I did tutor programming and economics in college. I love working with students who wanted to learn, and I hated students who came to me expecting me to do their assignment for them. One of my points of pride was writing programs as small as possible to do all of the necessary steps and error checking of a job. I like fast elegant code. Sadly BIOS programmers and OS programmers seemed to conspire to do a bad job and force me to add a lot of error checking.

My biggest problem with writing code was something you might not see as an issue. I could hold the entirety of huge projects in my head while I was working. I would often chase down long chains of logic in my head and find the problems before writing that portion of the code. I had to force myself to go back and document it after it was running error free instead of shutting down for a mental rest. I don't have that much active memory capacity anymore. I have to document as I go.

Now that we are done having a measuring contest over our ... er... bonafides, that really has not a darn thing to do with this post. This post was about the amazing (to me if obviously not to you) fact that I ran a huge code file on Mach 3 (which plenty of folks things is a trash control system) and don't remember having any issue with it at all. It just ran. It just ran and I didn't even remember anything remarkable about the file size. One of the guys on the CamBam forum reminded me that the theoretical limit for Mach 3 is 10 million lines of code. He recounted a job that a friend of his ran that he had to split in two parts because the overall job was 18 million lines of code.

[Bob La Londe]

Another programming aside. I stopped by a geology professors office one day to apologize for walking out of his class. He said anybody with a cumulative score of a certain point had an A for his class no matter how they did on the final. I asked him, "So I have an A even if I walk out right now and don't come back?" When he said yes I threw my saddle bags (used them as book bags) over my shoulder and walked out. He showed me a water saturation model he was running on his (386) using a basic interpreter and mentioned how long it took. (Several days) I helped him translate it all to a basic compiler and it dropped the run time to about 20hrs. He thought that was pretty amazing, until I rewrote the whole thing in C+ and compiled it. Then it ran in a couple hrs. I don't recall how big the program was, but the slow down at that point was in drive speed. Memory was expensive back then. I taught him how to write in C+ and he did all his models in C after that. I guess that got around because my algebra instructor asked me for some help one day with setting up some fractal models for fern graphics. I barely taught him the basics and he was off and running. I hadn't even taught him about all the include libraries. The next time I visited his office he had written his own graphics library. He was clearly smarter than me and with barely any help at all was off and running.

The part about walking out of the class at the beginning was not a brag. It was just setup for the anecdote. There were 7-8 other students in the class who could have done that. It was a pretty easy class. I was kind of offended that the nursing and engineering students at that college had priority for the chemistry and physics classes. I couldn't get into a class and was forced to take a couple semesters of geology for my science credits. It was fun, but not at all challenging. Its does make driving through highways cuts a little more interesting.

[kf2qd]

Looks like you could use a more efficient code generator. I have looked at some of the CAM programs and they seem to have no idea bout G02 and G03. Redid some code on my own and the code shrank to less than 10%, and that was on much smaller programs.

[Bob La Londe]

Looks like you could use a more efficient code generator. I have looked at some of the CAM programs and they seem to have no idea bout G02 and G03. Redid some code on my own and the code shrank to less than 10%, and that was on much smaller programs.

How much organic 3D milling do you do? I make some modestly complex and detailed multiple cavity custom injection and casting molds. I'm not milling a j-box. LOL. If I was doing something that mundane the trochoidal approach I would use for roughing that deep pocket implements lots of G02 and G03 codes.

When a CAM program doesn't output some codes is usually due to choice of post processor. There are lots of controls out there that do not support a full instruction set. Even some that claim to be Fanuuc compatible turn out not to support the full instruction set. Then there is GRBL. LOL. Seriously, if you aren't getting the kind of code you want change the post processor. Most any even half decent CAM program has multiple post processors available, and many have an inbuilt ability to copy, modify, and write custom post processors built write in. The post processors I use every day are modified to suit my needs on a machine by machine basis. I also write my own on machine macros when it's appropriate.

[Dan Dubeau]

What kind of file size are those million line programs Bob?

I've run some very large 3d freform programs, think haas VF6 entire table (32x64+). I think the longest ones were around 20hrs or more just for the finish. Been a while since I've done a full body form that large. Most big jobs we get nowadays are not full body fixtures, but a large collections of smaller blocks. Industry is shifting away from that style of checking fixture in favour of whitelight scanners. The one I'm working on now is an engine cradle assembly about 6' square. Lots of blocks but very little ball cut form.

Anyway, some of those giant programs were around 20-25kb if I remember right. Most of the finish programs on our normal bigger fixtures are around 10k. 8-12 hours with a 1/2" or 5/8" ball. I never really payed attention to how many lines they were though. 15k is about the sweet spot, anything above that almost always seemed to cause problems.

We drip fed into a haas controls. Our vf5 has usb and we run directly off that with ZERO issues, but by nature the jobs just aren't as big as on the vf6. I always had to delete line #'s to bring the file size down (yes, theoretically it shouldn't matter what the file size is when you drip feed, but everything works in theory....), and even then you'd still have the odd crap out overnight between the computer and control. Nothing worse than coming in in the morning thinking you're going to be finishing the holes, scribing, rest finish programs etc, only to realize the program quit only an hour after you left the night before. Snap a pic of the program on the control where it quit, and cut/crop out the rest to restart. Good way to kill a day, and it always happened at the worst possible times too.

When they do run perfect overnight is a glorious thing though. It's like magic. . Nothing like a green blinking light when I walk in in the morning.

No way around it. Ball cutting 3d freeform surfaces generates an ass ton of code.

[Bob La Londe]

The first code file I did over a million lines took 30 hours to machine. Most of that was limitations of the machine. I did a mold that was 2.3 million lines per half and each mold half took a little over 9 hours. I'd have to go back and look at what the 3.5 million code file was. I vaguely recall I did some embossing dies for a company in the Ukraine that took over 11 hours for one single plate die. These were all quite small parts by your standards. The thing is is sometimes I'm doing a finishing pass over an entire cavity for a consistent finish with a very small cutter. Yesterday I did a relatively simple casting mold and every bit of the mold half was cut in about an hour and then it took 2 hours to rest machine some of the key details with a 1/32nd inch ball nose mill.

I posted in another group recently that 12.35 in per minute is screaming fast... When you're pushing a 1/32nd inch ball nose end Mill in aluminum.

One of the things I do when I'm doing a finish pass on something where I want to come fully out of the cut before going back into the cut for uniformity of toolpaths is to use a very very small clearance height. And it's pretty scary when you see that tiny little endmill screaming across the surface of your part at rapid speed to the next operation at only 0.05 clearance. On some of those complex files going with such a low clearance can save hours on a job. I'd go less, but a burr from a previous roughing operation would snap some of the smaller end Mills right off.

[Bob La Londe]

Yep. That biggest file was an embossing die (machined in a medium hard die steel).