Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CNC milling with open source software

opensource.com

Post reply on HN
Print view View original

121–130 of 133 posts

Re: CNC milling with open source software

#121

Post by ElCapitanMarkla »

jcoffland wrote: post #55
tlarkworthy wrote: post #27

G-code is the most hilariously bad language. Keywords are G + a number, e.g. G01, with wildly different effects, varying arg lists and no standard. E.g. G01 move to position, G20 set the machine units to inches. Its often stateful. Obviously its coz its old and works, but i chuckle everytime i have to look up the codes at how comically awful it is compared to anything else i see https://en.m.wikipedia.org/wiki/G-code

Check out https://TPLang.org/ for a JavaScript based Open-Source alternative to GCode. I'm the author.

Hey that’s really cool I’m going to have a play with this. Thanks

Re: CNC milling with open source software

#122

Post by IshKebab »

jcoffland wrote: post #55
tlarkworthy wrote: post #27

G-code is the most hilariously bad language. Keywords are G + a number, e.g. G01, with wildly different effects, varying arg lists and no standard. E.g. G01 move to position, G20 set the machine units to inches. Its often stateful. Obviously its coz its old and works, but i chuckle everytime i have to look up the codes at how comically awful it is compared to anything else i see https://en.m.wikipedia.org/wiki/G-code

Check out https://TPLang.org/ for a JavaScript based Open-Source alternative to GCode. I'm the author.

Looks like more of a programming language than a list of commands like g-code. That's not a good design in my opinion. I mean do you expect CNC machines and CAD programs to embed JavaScript interpreters? Or does it export to g-code? In which case it isn't really an alternative.

Re: CNC milling with open source software

#123

Post by sokoloff »

ElCapitanMarkla wrote: post #120
rmu09 wrote: post #79

Earlier quoted context omitted.

Real CNC machines have limit switches, they monitor the load on the axis and spindle servos etc etc. But that doesn't prevent running your cutter into a fixture at positioning speed and ruining the spindle bearings.

My tin arse Cnc mill I made has stop switches. Probably the cheapest part of the whole thing and saves it grinding itself when you balls the code up :D

Do those stop switches prevent crashing the mill into a fixture? If so, how?

Do you manually monitor the entire job cycle?

Re: CNC milling with open source software

#124

Post by marcosdumay »

51lver wrote: post #76
marcosdumay wrote: post #66

Earlier quoted context omitted.

It would look like something like this: go_home set_units mm set_movements relative activate_tool 0 move X 10 move Y 10 Instead, each of those names is replaced by G + a number.

That's because the above would be highly wasteful on a slow serial link, like the ones gcode was made on and for. That said, I bet vim syntax highlighting could get you most of what you want. Color code movement, configuration, values, maybe display the toolhead status and position at your current line in the status bar...

Well, a gcode file is usually entirely composed of "move" operations. I'm adding one extra character on a 8 characters (at a minimum) line, for an increase of 12.5% at the worst case.

A CNC moves with speeds on the mm/s range. So does a 3D printer (unless you ask for larger movements, but those take less codes/s). They also have a precision on the 100's of µm, but let's push it down to 10's here so we overestimate things by an order of magnitude.

That means they'll need around 1000 codes/s, with a minimum of 64kbps on the 8 character case, or 72kbps with my codes. I don't think there is any serial interface chipset on the market that can't do 512kbps even on a 100's of meters long cable. Not to say that everything nowadays runs over USB anyway.

The gcodes are a leggacy that isn't needed anymore. And since both sides of the CNC link are composed of overpowered computers doing anything on software, the only reason it didn't change already is because nobody bothered to do something better. I'm not much bothered by them either so, I'm not jumping over it, but it is suboptimal.

Re: CNC milling with open source software

#125

Post by onmai-xyz »

tlarkworthy wrote: post #27

G-code is the most hilariously bad language. Keywords are G + a number, e.g. G01, with wildly different effects, varying arg lists and no standard. E.g. G01 move to position, G20 set the machine units to inches. Its often stateful. Obviously its coz its old and works, but i chuckle everytime i have to look up the codes at how comically awful it is compared to anything else i see https://en.m.wikipedia.org/wiki/G-code

>G-code is the most hilariously bad language

Let's do a web site programming analogy(weak but relatable), because JS is now a mature programming language with advanced interpreters. This was not the case back when JS was used to make text dance and a few other useful ad-hoc solutions.

-Early web days with just html is like plain g-code spit out from cam systems.

-Early javascript is like macro options available on industrial cnc[1][2][3].

-Mid years javascript is where cnc macro program is heading, isolated shops doing some awesome things but no industry wide adoption of a coherent system.

-Late years javascript is where cnc macro programming needs to be if we want proper revision control and all the other benefits that normal programmers have afforded themselves.

Which brings us to real digital twins(monozygotic, not the fraternal state of the art), a single source of truth digital file should manifest as both a real world part on the shop floor and a virtual object in the top floor to be used by all the departments.

To close the analogy, like nodejs affords developing on the backend and the frontend with the same language.

[1] http://parts.haascnc.com/haasparts/en/USD/Performance-Upgrad...

[2] https://www.fanucamerica.com/fanuc-america-product-support/f...

[3] https://www.cncci.com/resources/tips/w%20custom%20macro.htm

Re: CNC milling with open source software

#126

Post by onmai-xyz »

grawprog wrote: post #34
tlarkworthy wrote: post #27

G-code is the most hilariously bad language. Keywords are G + a number, e.g. G01, with wildly different effects, varying arg lists and no standard. E.g. G01 move to position, G20 set the machine units to inches. Its often stateful. Obviously its coz its old and works, but i chuckle everytime i have to look up the codes at how comically awful it is compared to anything else i see https://en.m.wikipedia.org/wiki/G-code

The g-code variant my machines use contains most of the control structures of modern programming languages. It has variables, comparisons, loops, subroutines, the codes are all fairly straight forward and honestly a lot of g-code is produced automatically with CAM software rather than being written manually these days. It's a simple language, you don't have to memorize the codes and you end up memorizing the few you…

Have you been able to arrive at any clear repeatable structure in your macro programming, or is it just ad-hoc make it fit for this job and this machine?

Asking, because I am trying to level up cnc programming to "normal" programming.

Re: CNC milling with open source software

#127

Post by yourapostasy »

DannyBee wrote: post #103
rmu09 wrote: post #102

Earlier quoted context omitted.

Low-level control your machine from your CAM workstation in the office building will never make much sense (where the CAM software directly talks to servos). I would prefer my (probably expensive) machine to kind of "know" what it's physical limits are and guarantee that executed commands adhere to them.

It depends on what you are talking about here. CNC is used for a lot . The assumption that there is a cam workstation, and that it's in an office building, is certainly not one i would make. I wouldn't also say "will never make much sense". You seem to have some particular set of users in mind for which you believe it wouldn't make sense. Okay - i'm not sure that changes that there are plenty of sets of users for whi…

> They don't know their own physical orientations...

Wait, so even the really high-end gear in high-end names like DMG Mori don't use something like millimeter radar, ultrasound or machine vision to confirm that real-world orientations at least correspond to within a few orders magnitude accuracy of what is expected? If so, then mad props to you machining guys working with such expensive kit without continuous closed loop monitoring conditions; you re-e-a-a-ally like to live on the wild side.

Re: CNC milling with open source software

#128

Post by yourapostasy »

jandrese wrote: post #68
yourapostasy wrote: post #49

Earlier quoted context omitted.

> ...and material cost (stock and bits) can get very expensive. I've been looking at CNC for a long time, and I've read that if you're starting from scratch, to allocate about the same amount that you spend on the mill itself to the consumables/logistical tail (end mills, cutting fluid, ancillary metalworking tools). Due to the steady degradation of quality design and manufacturing, and rapid support obsolescence, th…

Sometimes those plastic gears are serving a purpose though. They can protect much more expensive parts by failing first when an error occurs. So the operators gripe about replacing a stupid plastic gear so they replace it with a metal one, then gripe when they have to replace the blown out gearbox.

Yep, thanks for pointing that out to the general audience, should definitely be noted. Some KitchenAid mixers have a plastic gear for exactly that purpose. On the other hand, on an outboard motor I use, the plastic gear that wears through for a tilt lock mechanism is attached to a ludicrously expensive metal assembly that has to be completely replaced.

I'm okay with the plastic gear designed as a sacrificial component. I don't like having to toss an entire assembly into the landfill, though. I'd like to be able to print/purchase just the sacrificial component and screw/glue it onto the existing still-working assembly. Event better, I'd like to send the broken sacrificial component back through to a process that breaks it back down into feedstock for recycled resins that go to manufacture products that can take slightly weaker plastic (each pass through recycling, plastic becomes slightly weaker, with virgin plastic starting at the strongest).

Ideally, I'd like to see aluminum parts that are designed to crumple under the specified sacrifice load like the equivalent plastic parts, and be able to just endlessly recycle the aluminum. But I've never seen such a design of a sacrificial gear/cam/bolt, so I don't know if that is simply an impossible mechanical engineering ask by a dumb layperson.

Re: CNC milling with open source software

#129

Post by lvh »

onmai-xyz wrote: post #48
lvh wrote: post #33

Earlier quoted context omitted.

What would a good G-Code variant look like? For all its flaws, it's pretty good at encoding the exact thing you want the CNC machine to do and while there certainly are different post-processors for different machines and in most cases they're not optional, it's also not like they're entirely different. I think of G-code as ASM. For high-performance work you might write code differently for different (related) machin…

A good G-Code variant would roll up the un-rolled loops and separate the geometry data from the tool config data. This is what the view of a CAM IDE presents, G-Code source can be structured the same. If you change the semantics on some of the syntax you get lexically scoped blocks, macro-b subsystem which has existed for decades needs to be fully utilized for this to happen. A fully implemented system would provide…

Eventually, something actuates a servo, and servos don’t understand iteration. Do you agree eventually something with g-codes level of detail must exist (even if it’s just unspecified internal commands)? If so, do you agree you’re just advocating for that layer to be part of the machine?

Re: CNC milling with open source software

#130

Post by lvh »

tlarkworthy wrote: post #101
lvh wrote: post #33

Earlier quoted context omitted.

What would a good G-Code variant look like? For all its flaws, it's pretty good at encoding the exact thing you want the CNC machine to do and while there certainly are different post-processors for different machines and in most cases they're not optional, it's also not like they're entirely different. I think of G-code as ASM. For high-performance work you might write code differently for different (related) machin…

Not really, it cant do helical cuts.

What do you want out of helical cuts that G03s don’t give you?
Post reply on HN