Hello Snappy community! I am creating a safety printing firmware on the u1 for the innovation competition. I’m inquiring how to go about reaching my goals:
learn how I can quickly iterate versions hopefully without flashing every time.
learn how to access the acceleration data from the print head, and either display that on the printer screen or preferably on my computer. (like in my IDE console)
how to move the print head from either the firmware or the gcode. Either way there must be some awareness of the model being printed. the result I’m searching for is to have my nozzle bump the edge of the first layer and measure the resistance the nozzle feels to judge the adhesion quality. my
knowledge: I’m very familiar with Python, and other languages. I have never worked with creating custom gcode outside of slicers. I do not know how to go about changing firmware nor do I know where to learn this.
Snapmaker themselves publish a custom firmware. I don’t have a U1 to test it, but you might start there. There is discussion in the forums about it as well.
The fundamentals of firmware on an FDM printer are that it reads G-Code from somewhere (an SD card for example) and performs the actions specified by the G-Code more or less blindly. This draws on general principles of CNC machining which were established a long time before anybody thought of 3D printing. The really clever stuff is in the slicer software which “compiles” the G-Code. So the printer itself is just a dumb robot.
If somebody were to build their own FDM printer from scratch, they could buy in a controller board for the job, or build their own controller, but either way they would probably run it on Marlin or Klipper (there are others), which are implementations of a G-Code interpreter. Customisation is required to tell the interpreter how the various motors and sensors are wired up, using configuration files.
If you want to write your own, I would say the best way to start is to examine the specifications for Marlin and Klipper, and then you’ll know what your firmware has to do.
To be honest, I don’t see the point. Marlin is less sophisticated than Klipper, but they both have been around for a very long time and are as developed as they need to be. It will be a huge task to write a new one, and unless it is to address some inadequacy in the existing offering it would be wasted effort.
Well, the firmware is the operating system for the printer and is stored in Flash which can only be written to during a dedicated Flash update, so you would have to find a way to set up a writeable file system in RAM or something and divert execution there.
You might be under the misapprehension that there is a general purpose operating system running in the background – there isn’t (or a very stripped-down one). This is bare-metal coding. This is NOT like programming up a game on a PC – which always surprised new recruits in electronic engineering who thought they were good at software but then had to have bits, bytes, hardware control, and bit-bashing explained to them (some never got it). I suppose you could try installing an OS, but typically all the processing power the controller has is dedicated to running the printer.
There is no acceleration data. If you want to know how the head is accelerating, you have to infer it from the way it is being driven. You might have heard of acceleration and vibration shaping, but these are pre-programmed open-loop tunings of the control to the motors – no feedback.
The G-Code commands get interpreted and converted into the control signals for the XYZE stepper motors, and tracked to ensure travel limits are not exceeded. Ditto for head movements under manual control from the control panel, or built-in scripts for homing, head changing, etc etc etc.
No, none. All the printer knows about the model is the line-by-line G-Code commands that the slicer provides. Yes, OK, the modern fancy control panel stuff can display previews of the model to be printed, but that preview image is provided by the slicer and is not (so far as I know) generated internally.
An interesting idea, but you would need lateral force sensors to do that and there aren’t any. All you might do is reduce the drive current to the motor to the point where it fails to move the head, but I don’t think you can even detect that the head has skipped.
Python is an interpreted language, requiring an operating system behind it. Coding for a controller means programming in something like C, and compiling to machine code.
The G-Code is the G-Code. The firmware on the U1 is what takes the G-Code and converts it into the motor movements etc that run the printer. If you think custom firmware means generating G-Code, you’re wrong.
I think you are out of your depth. The Paxx12 and DnG Crafts forks of the Snapmaker U1 firmware add additional routines to the Snapmaker customisation of Klipper. Look up Paxx on GitHub, and you will find plenty of documentation about the modifications and the process of preparing a firmware update.
No doubt people will use vibe coding but I advise extreme caution. The code is what drives the mechanics of the printer and is entirely responsible for not driving the mechanics in an unsafe way. Any code generated by AI assistance must at least be reviewed in detail, just throwing it at the printer without understanding it risks damage to the printer and potentially injury to an operator.
It is not my intention to discourage you from exploring and learning, but IMO your proposal is a few steps too far to meet any innovation competition deadlines! Your energy might be more productively used elsewhere.