Add mSLA capabilities #6575
Add mSLA capabilities #6575
Conversation
- Add manufacturing process - Send images/buffers via HDMI - Allow print from zip and tar files (By decompress them upfront)
|
Some questions:
See this code: What would be optimal: You think the SET_VELOCITY_LIMIT can be improved in that way? |
- Sync display with UV LED in two-way mode - Add a response test to measure the UV LED shutter time - Allow to define the response delay of the UV LED shutter and take it into account when using M1400 Px - Fix regex for the file path parse from M6054 - Refactorings
- Remove display_width and height from configuration to simplify - Fix bit_depth not set when 32 - Rename type to pixel_format
- Use locks on framebuffer - Add more utility functions - Add `MSLA_DISPLAY_TEST` command
- Add channels information - Add fill_buffer allow a rgb tuple - Add M1401 command to turn off the uvled - Improve image send to allow images smaller than buffer - Improve get_image_buffer to return more data and allow strip alpha - Improve raise to gcode.error - Add utility functions - Rename some commands
Z axis with self homed xy and allow only to move Z
Instead of using filament schemantic, it now use universal material which can be set by user. It is to provide better and more accurate stats, while allowing material types other than filament.
- Add M1450 to clear the screen - Change M6054 to M1451 and force the F param
|
Thank you for your contribution to Klipper. Unfortunately, a reviewer has not assigned themselves to this GitHub Pull Request. All Pull Requests are reviewed before merging, and a reviewer will need to volunteer. Further information is available at: https://www.klipper3d.org/CONTRIBUTING.html There are some steps that you can take now:
Unfortunately, if a reviewer does not assign themselves to this GitHub Pull Request then it will be automatically closed. If this happens, then it is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available. Best regards, PS: I'm just an automated script, not a human being. |
|
Interesting, thanks. I'm curious what your long-term plans are for this work. Are you still working on it? Are there users utilizing this system today? I didn't see your questions earlier because of the many earlier updates to the PR. I'll try to answer them:
Unfortunately that is difficult to do with g-code because there isn't an explicit "start of print" nor "end of print" command in g-code. The closest equivalent would be the events generated from the idle_timeout module (see the
That sounds like you'll want to implement in a module. You could also look at klippy/extras/pwm_tool.py - as that has emergency cutoff code in it. (Should the host disconnect from the mcu while the gpio is enabled, the mcu will know to transition to an error state and turn off the gpio.)
This was discussed on Discourse. It's possible, but I'd guess it would be simpler to break up the moves and change acceleration between move segments (as you've indicated on Discourse). I also have a few high-level questions:
Thanks again, |
I plan to maintain it and work with community to attend and lead mSLA forward. Klipper has everything to drive mSLA, only the display image part is missing. I also made it to support other techs and not be "filament" specific. I think Klipper core should go in this direction, abstract rather than specific.
No, I find this PR very stable and everything is ready to be used. I'm printing with confidence and without any failure so far. But will be optimal to have another set of eyes on the code.
Just me. I converted my printer and throw it a Manta M5P + CM4 to make this proof of concept. Currently printing with it using mainsail.
The Athenna printers (Runs nanoDLP with klipper) also had they sync problem with image and exposure time, they looked my PR and adopted the concept and rewrite my M1400
Yes, topic was open by me. Is true that 4xG1+SET_VELOCITY does optimize (1s less in my tests) however in future would be a nice to have this and benefit other systems. However not critical for PR.
mSLA requires lifts before exposure next layer. Here a normal sequence for print layer 1: You can notice the 4xG1 to perform the lift and retract to detach model from FEP and refresh the resin under it. Regarding that I think I think we should stay with standalone commands for best compatibility and customizable. Here the parameters users can adjust per layer:
Any FDM board and a Pi will do it. I have written step by step guide for who want to convert their printer to this firmware: https://github.com/sn4k3/klipper-msla In my case I have used a Manta M5P + CM4 to make my UNIZ IBEE klipper based.
No slicer so far is able to output this zip format with klipper flavor. The current slicers can output zip but with CWS gcode norm.
Here a sample sliced file, PrusaSlicer (SL1) -> UVtools -> Klipper zip
There are no popular open-source mSLA firmwares. This is the problem :) Working with all these formats over years it's an experience I don't wish for anyone. I wonder why is so hard to write a good firmware? This PR aims to free users from all crappy firmwares monopoly and revindicate the machines under their control. And most important, having the first all-in and good open-source mSLA firmware that allow you to tune and add features to your printer like we do with FDM. |
|
Very interesting PR! It has always seemed strange to me that mSLA, which is a motor, a screen and an LED is less open source than multiple motors working together. Does this support mono lcds that report lower resolution on one axis (eg, 2560x540 instead of 2560x1440 like the DXQ608)? |
The hardest part was always the main LCD which was required custom hardware and know how to address data lines. Not anymore with HDMI interface. That constrained the tech so far. But yeah removing lcd from equation the mSLA is much easier to program compared with FDM.
nanoDLP work similar to that, but that is not optimal, you "lose" sync
It support any HDMI LCD as long you can configure it right (framebuffer) up to a limit of resolution. The auto kms driver won't work well in most case with this mono lcds.
Why overcomplicate? The simpler the best. Having multiple files is best than single array, it also allow faster pre-process of image. IMO handling +/- 2gb TIFF is only desvantagens and more "lock" prompt. |
|
@sn4k3 Is there any further discussion happens anywhere or it's stuck at PoC? it would be nice if you'd add information disclosed here into https://github.com/sn4k3/klipper-msla those readme doesn't really makes sense without everything said here, from perspective of a random person who would love to have klipper on msla printer, explanation around screen is lackluster(it's actually makes think that it's more complex than it is in reality due to folder with bunch of files which the only currently tested screen sends you to) and zero info on how to actually print doesn't encurage as well |
|
No discussion outside this PR as far I know. I guess is dependent on reviewers and people who can implement this to test out. As Klipper is mainly FDM something outside that scope might take extra time and effort to get merged. Most information here (apart from new modules documentation which completes the klipper docs) don't really matter for end user, most stuff is PR related and how code was implemented. But fell free to point out what you find useful to have in klipper-msla and I will complete. About the folder with bunch of files I guess you talking about the macros I built for mSLA? They are completely optional, klipper alone will work out of the box BUT just like FDM klipper without macros are lackluster, for example you still need macros for filament change and other optimal procedures. As so my macros implement that useful extra functions which I recommend but again are optional and not dependent on. About complexity is not near as complex as FDM huge configurations, you only need to configure an output pin for UVLED and add an display. The klipper-msla repo is currently the step by step guide I have build to help people setup things which does not differ from klipper logic and only requires the use of two modules into your klipper printer config file. After that it will print just like any other FDM printer, you can access to webui select file and print. To slice a file you can use PrusaSlicer with my printer profile sample, then you send to UVtools and it will auto convert to klipper file (.zip). That zip is what you upload to your printer and select to print, then it will start and print. For people not into DIY I would say this can be harder, because they may not be used into tinker with custom boards and set up a klipper. But for who comes from FDM costum builds with klipper, this will be just as easy. I have been using klipper into my printer now and I can say that everything was improved, in fact I had no failure prints since then using the same slicing parameters. For example, where because a PAUSE would cause a horizontal line on model 100% of the times, now its history, pauses are perfect and don't create lines any more. The precision of exposure also vastly improved. If you have any questions or require help to implement into your machine fell free to contact me. |
|
@sn4k3 i didn't mean that kind of stranger, yet i really appreciate that you've tried to explain as much as possible. First and foremost: "what i'm going to do after installation" - there's no answer to that question in those guide, but it is here, even in your reply, specifically:
as well as more info which you provided here, like available settings, which you posted earlier Secondly: screen/display - it is not explained how exactly it is used, but have config file with sketchy lines like screen model number(as said here - it's pretty much equals to comment and those field doing nothing, but there's nothing about this on the guide page) which correlates with .bin and .data files in "display database" and it leads to assumption that it might require to contact vendor to get those files(yes, it is my mistake to even peek there, but having questions without answer leads to f-around and find out learning method), with info provided here it is clear that you basically need driver board which can handle display and configure it like any other hdmi screen, but taking into consideration details like horizontal resolution(which you touched in you response as well) I believe that this PR is huge for msla community, but because of unclear level of complexity(which is pretty low, if we talk about printers without fancy stuff like tilting bed, which might require more work like adding "firmware retraction" gcode instead of using plain Z movement) in guide it does not get enough attention |
Background
I'm the creator of UVtools, a software dedicated to help and make resin printing sane (mSLA/DLP) with tons of manipulations and checks.
From the past 4 years I've being deal with many mSLA formats available today, I known them in depth, I'm amazed with the fact that mSLA is far behind FDM in slicing features (In fact I could not believe 4 years ago that mSLA was not gcoded and open like FDM). We are very limited to static file formats that only follow a structure with few or none options. The existing gcode printers in this technology can be counted by hand and the ones that exists suffer from bugs or bad performance.
The bad firmwares are ruining the printers "completely", they never listen to community, never fix bugs that in a normal case takes just 1 day to fix and send the patch firmware online. They really don't care, they just flood the market with models and models of machines that many are very decent on it hardware but the firmware make them a crap machine.
Companies right now are tied to one or two solutions, which are always locking formats and make the best effort to encrypt and make sure no others can be used.
Myself got asked by a board company what could be done to improve the eco-system. I tell them: Well, make the format open-source and run over gcode... A: That's not possible, our hardware is not capable, parse gcode is very hard, run png's is not possible, not economical, can't be made open-source, bla bla bla. All runaround.
The fact is that now they have 4GB boards running linux, is load png still too hard? Is gcode still not possible? 🤦
Then big promises came, open-source boards and format. Guess what? They call themself open-source by just having a repo in github with just a few documentation on the format, which even with the docs we are unsure about the meaning of some fields...
Lies, promises, bad products, and more lies... This is a loop in mSLA with huge lack of vision.
This crappy mindset are ruining the technology and the overall experience. Myself I don't active do nor like resin printing, but I can't just see this and doing nothing when I have to power to change the situation! That lead me to this PR.
What is required run mSLA?
mSLA only need one Z axis, feed image to a screen and lit a UV LED over it. Looping layer by layer and forming a solid piece from cured resin from the lit pixels.
FDM is far more complex to build because it motion system. So now you see another point here, why such simple tech is soo hard to implement? The answer is: Drive the displays! Most displays are held, no datasheets no information how to drive it, require custom FPC = custom board.
However today most LCDs are HDMI! And you guess it, plug HDMI to PC and send image. Easy!
Why Klipper?
I have been told: Why klipper for that? Thats OP for what you want. Why not using something else?
I can't disagree more!
So is Klipper OP for this!? NO! It's just perfect!
Also I think it's time for klipper to embrace other manufacturing processes, it's a win-win and will make klipper richer in capabilities and features.
Hardware
Right now I'm using:
The PR / Implementation
Note that I mark this PR as a draft because I wan't it to be review, it's my first time dealing with klipper sources. In fact I did what most said impossible in just 3 days but had my printer displaying the image using klipper in just one day. This alone means klipper perfect :)
So forgive-me If something is not soo well defined.
GCode sample:
Image display
The displays are now connected via HDMI on the Pi.
Pi itself let us configure the framebuffer (config.txt) to match the display. So all we need is set correct parameters there.
After I created a [framebuffer_display] module into klipper. Which allow us to configure any framebuffer and send buffers/images over there. See framebuffer_display.py
I created to be generic and mux, so some may use it for other displays and send pics to a HDMI display.
All code is python and it direct address the framebuffer without any external dependencies.
From that I created the [msla_display] which is the keypoint
eg:
type,modelare just information, not actually used.All other parameters are used to have sane checks but also provide information about the display which is required.
the
cacheparameter is a smart-feature to cache next layers so buffer is much more fast to send when time comes.The most smart approach to exposure an layer is:
In my implementation before UV LED is turn on, it waits for image buffer send to be completed. A smart feature that most of gcode printers does not have, they never know when buffer is actually completed, in consequence UV LED can be lit before image is present. I really can't understand why, why so hard to make it right?
With cache system and direct buffers I manage fast speeds on transfers, not that we really need them, because they way mSLA works with lifts and waits make time to image to complete (In most cases).
Here the results of an 4K buffer, sampled and avg 10 times:
So in normal conditions if image is load from disk it took about 94ms, but if cached it took 3.5ms to be rendered to the display. Pretty good.
Some gcode commands where created to:
M1400: Because UV wavelength goes from 100nm-400nm
M1451: Command used by other gcode printers to display the image is M6054, but opt for M1451 to be closer from M1400
Commands are debatable, we should set an standard now.
[virtual_sdcard]
The mSLA requires an image per layer. Some users prints can go up to 4000 layers. Upload folders is a bit messy, the format I think is best it's the Zip file (pngs + gcode)
I had to alter the virtual_sdcard.py with some features:
[toolhead.py]
I admit that I had a hard time discovering the [printer] 😅
I have added the property
manufacturing_processthis is required for others interfaces to adapt. Up now all is related to FDM, so interfaces like mainsail would need to know proper process to adapt interface, eg: For mSLA we want to see current layer image that is printing.[printer_stats.py]
Klipper was build around FDM, stats is filament based. Current system is very limited so I rewrote the stats to be universal and more useful. UI's can now render information easier without parse.
filament_used: Was kept for compatibility and give time for other backends to adapt, but marked as deprecated in favor ofmaterial_usedmaterial_type: Based ontoolhead.manufacturing_processthis is auto set by klipper, eg:filamentorresinmaterial_name: This is set by user viaSET_PRINT_STATS_INFO, it represents the current printing material, if a material is changed, eg: M600, we can now update it name and display under UI's.material_unit: The material unit, this is set by klipper but can also be set by user, for filament is set to 'mm', for resin is set to 'ml'. If user is not happy he can change with to 'in' usingSET_PRINT_STATS_INFOmaterial_total: The total material print will use, set once on print startmaterial_used: The used material so far in the print.info.last_material_used: The last used material, is often the material consumed by last layer.Syntax:
FDM sample:
Print start:
SET_PRINT_STATS_INFO TOTAL_LAYER=1000 MATERIAL_NAME="Generic Orange PLA" MATERIAL_TOTAL=100000Before layer:
SET_PRINT_STATS_INFO LAYER=1After layer:
SET_PRINT_STATS_INFO CONSUME_MATERIAL=100echo:
100 / 100000 mm-> This is the used material in mmAdvanced:
Then our
M600macro can be expanded to show the material to insert.Resin sample:
Print start:
SET_PRINT_STATS_INFO TOTAL_LAYER=1000 MATERIAL_NAME="Generic ABS-Like" MATERIAL_TOTAL=1000Before layer:
SET_PRINT_STATS_INFO LAYER=1After layer:
SET_PRINT_STATS_INFO CONSUME_MATERIAL=1echo:
1 / 1000 ml-> This is the used material in mlLaser sample:
Print start:
SET_PRINT_STATS_INFO TOTAL_LAYER=1 MATERIAL_NAME="MDF" MATERIAL_TOTAL=10000On etch/period:
SET_PRINT_STATS_INFO CONSUME_MATERIAL=10echo:
10 / 10000 mm^2--> This is the etched / cut areaCNC sample:
Print start:
SET_PRINT_STATS_INFO TOTAL_LAYER=1 MATERIAL_NAME="MDF" MATERIAL_TOTAL=10000On cut/period:
SET_PRINT_STATS_INFO CONSUME_MATERIAL=10echo:
10 / 10000 mm^3--> This is the removed material volumeThis are just samples, and uses are not limited to them.
UI's can now render better stats without the need of parse nor if's to display stats to other manufacturing processes.
[display]
menu.cfganddisplay.cfgwas adjusted to remove some menus if criteria are not match.UVLEDandUVLED pwrunderControlmenu.What's missing
Stats for mSLA? I'm not sure if klipper does stats for FDM, so this is a question.UI LCD interface (Remove hotend, heatbed and extra menus that are not required for mSLA)Docs: I would complete the docs when PR is done, without further changes to make.Breaking changes:
None.
Video
(Sorry for the bad quality.)
Sample print file
https://we.tl/t-l9a9fMftQN
WIP
This is a WIP,looking for ideias, improvements but the implementation is working stable.