onmai-xyz

If you control the ssh server it can be configured to only allow what you want. Certainly tedious but I would consider it worth while as it stands with agents being well, agentic.

Yellow could be used to start the sequence in reverse order. You are stopped at an intersection with a red light, light turns yellow for a brief time indicating proceed with caution as the cross street has just had its green light go directly to red. The brief yellow turns green allowing cautious transition of cross traffic right of way, instead of the regular use of yellow which seems to induce a lack of clarity on what to do, accelerate or decelerate. Green directly to red makes it very clear what to do, stop or maintain velocity. The grey zone still exists but it is on the new flow to proceed with caution instead of just, green=go. Rightly this would be rejected as it wacky, but wow t-boned accidents are horrendous and people really like to game the yellow light in a reckless way. How can we move towards caution.

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-...

The answer needs to be a single digital file that can render real parts and virtual parts. Why not?

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.

>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

Tooling data in a G-Code data structure bootstrapped with G65 and M98 would support fixture models.

Certainly a chicken and egg problem though, my ideal future would have CAD files generated from single source of truth CNC files:)

>machinist still needs to load everything correctly. It's very easy to make a mistake.

Tool configuration is kinda-sorta solved with ISO 13399, this is being supported in more and more CAM systems and tool vendors, but as you say it is very easy to make a mistake.

Assuming the mistakes are happening when the tool data is reduced from the comprehensive format that ISO 13399 supports to the barebones and simple TxDxHx format that is loaded on CNC machine. Would be nice if machine tools supported a comprehensive format directly.

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

  $ rm file 
  $ echo $?
  $ 0

Silent, unless you go looking. The return value of the last executed command is available as $?.

I picked this up at http://www.rsync.net/resources/howto/remote_commands.html for running commands over ssh and not seeing the console output.

Mechanical engineers are overseeing a software sub-culture with regards to many of their creations being physically manifested. CAD/CAM that spits out g-code to run on mother machines, aka cnc machine tools. I personally would like to see the existing macro primitives available on cnc controls formally structured and abstracted up to enable "normal programming" to occur. Eliminating the fragile, spaghetti code mess that seems to be entrenched. As a g-code programmer I am unable to constructively edit anymore, but this need not be the case.