4 ms·

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 certa

by lvh 8y ago

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) machines, but it's still a pretty OK compilation target.

onmai-xyz 8y ago
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 the CAM GUI engineer and the CNC CLI machinist to work on the same file, skipping post-processing entirely. And, finally implement what was originally envisioned but not possible on even the most powerful mainframes of the late 50's: https://youtu.be/ob9NV8mmm20 https://youtu.be/ob9NV8mmm20
- lvh 8y ago
  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?
  - onmai-xyz 8y ago
    Speaking from user space that has G65 macro-b option, not machine tool builder (sudo) space. >I think of G-code as ASM. >Eventually, something actuates a servo, and servos don’t understand iteration. I think of it more as an intermediate language. Interpreted on the CNC control and JIT compiled to whatever the RT system needs for servo control. >Do you agree eventually something with g-codes level of detail must exist (even if it’s just unspecified internal commands)? It does exist and a strict subset with enough primitives to bootstrap an application VM should continue to exist. >If so, do you agree you’re just advocating for that layer to be part of the machine? I am advocating for a DSL one layer up to be part of the CNC machine with support offline in say the JVM. I want to answer this question, “how do we deploy MBE?” https://www.nist.gov/news-events/events/2019/04/model-based-enterprise-summit-2019 https://www.nist.gov/news-events/events/2019/04/model-based-... The answer needs to be a single digital file that can render real parts and virtual parts. Why not?
marcosdumay 8y ago
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.
- 51lver 8y ago
  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...
  - marcosdumay 8y ago
    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.
tlarkworthy 8y ago
Not really, it cant do helical cuts.
- lvh 8y ago
  What do you want out of helical cuts that G03s don’t give you?

by lvh 8y ago

onmai-xyz 8y ago

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 the CAM GUI engineer and the CNC CLI machinist to work on the same file, skipping post-processing entirely. And, finally implement what was originally envisioned but not possible on even the most powerful mainframes of the late 50's: https://youtu.be/ob9NV8mmm20 https://youtu.be/ob9NV8mmm20

lvh 8y ago
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?
- onmai-xyz 8y ago
  Speaking from user space that has G65 macro-b option, not machine tool builder (sudo) space. >I think of G-code as ASM. >Eventually, something actuates a servo, and servos don’t understand iteration. I think of it more as an intermediate language. Interpreted on the CNC control and JIT compiled to whatever the RT system needs for servo control. >Do you agree eventually something with g-codes level of detail must exist (even if it’s just unspecified internal commands)? It does exist and a strict subset with enough primitives to bootstrap an application VM should continue to exist. >If so, do you agree you’re just advocating for that layer to be part of the machine? I am advocating for a DSL one layer up to be part of the CNC machine with support offline in say the JVM. I want to answer this question, “how do we deploy MBE?” https://www.nist.gov/news-events/events/2019/04/model-based-enterprise-summit-2019 https://www.nist.gov/news-events/events/2019/04/model-based-... The answer needs to be a single digital file that can render real parts and virtual parts. Why not?

marcosdumay 8y ago

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.

51lver 8y ago
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...
- marcosdumay 8y ago
  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.

tlarkworthy 8y ago

Not really, it cant do helical cuts.

lvh 8y ago
What do you want out of helical cuts that G03s don’t give you?