Re: News : ARM Trying to Buy AmperComputing

The Natural Philosopher <tnp@invalid.invalid> wrote:

On 23/01/2025 20:22, Computer Nerd Kev wrote:

Mine does need print software to interpret the Gcode and generate
build files that the printer itself can understand. But it's pretty
ancient as home 3D printers go (an original Makerbot Cupcake).
 

Well mine (creality K1) seems to understand the GCODE directly, but the
slicer 'knows' about the machine, its commands and the plastic
materials, so it pretty much does all of that.

Maybe. You could check the output and see - Gcode is text based,
eg. this tiny snippet from a print I didn't get around to doing today:

G1 X-26.981 Y-1.748 Z3.36 F6240.0
M101
G1 X-20.752 Y-1.748 Z3.36 F3970.1225
G1 X-20.752 Y1.748 Z3.36 F3978.0
G1 X-27.748 Y1.748 Z3.36 F3844.7845
G1 X-27.748 Y-1.748 Z3.36 F3978.0
G1 X-27.286 Y-1.748 Z3.36 F3978.0
G1 X-26.981 Y-1.748 Z3.36 F3978.0
M103

G codes are posisitioning, M codes turn things on/off (the
extruder in this case). You can write it yourself like to use the
build platform as an agitater for etching PCBs in a tub on top,
which I tried but it turns out I enjoy doing the agitation manaully
more anyway (and less risk of splashing etchant on my 3D printer,
though it's mostly wood).

Slicers do need some machine-specific info even just to make the
Gcode. Hence I can't use the new ones with mine. I did look into
adding/hacking a driver (or whatever they call it) in Slic3r for
the Cupcake, but it's fixing something that ain't broke and I don't
like to touch C++ code if I can avoid it.

I think modern printers are very much better than they used to be.Its
now out of 'unstable' and more into 'testing' with their onboard code

Well I've learnt the bugs pretty well by now and they're just like
old friends. Plus it's nice with the Cupcake that everything's open
source so it's been easy for me to modify the electronics a bit
(and someone so inclined could even fiddle at those bugs in the
firmware).

--
__          __
#_ < |\| |< _#