As far as I know, there will be an option, on the Touchscreen, for you to select whether the machine has the quick swap kit installed. The default settings and data will be adjusted accordingly.
@Riskey any word on when the source code will be made available? When it gets integrated into the mainline?
I looked at the beginning of the sample GCODE.
Iām not familiar with GCODE, so I would appreciate it if you could teach me.
;Memory the parameter
(1)M593 P1 F40
(2)M203 X130 Y130 Z40 E60
(3)M201 X3500 Y3500 Z500 E5000
(4)M205 V10
(5)M900 T0 K0.04
(6)M900 T1 K0.04
(7)M500
M500
(1)Should it be added in the case of a vibration farm?
(2)What is the intention behind this? It seems unnecessary to me.
(4)I donāt understand the meaning of the V10 parameter.
(5)It seems like it would be better to set it specifically for the vibration farm.
(7)Since the above parameter is set in the start code every time, is it unnecessary to save it?
Is there something in this g-code not documented at https://snapmaker.github.io/Documentation/gcode/G000-G001
?
Hi @Riskey Iām having few troubles with the installation of the firmware: it seems my machine doesnāt recognize it like a genuine update. I have a SM 2 A 350 with updated linear rails.
Any suggestion? Or am I wrong with something?
Thanks for your support.
Hi jlropes, please submit a support ticket here and my support colleagues will contact you.
The J1 firmware, which has already been open-sourced, includes code for vibration compensation. You can take a look on Github.
Thanks for your feedback @Riskey !
M205 V10
āV10ā is the setting for the corner speed.
I tried the vibration compensation firmware and got two errors.
- printing goes into a freeze state in the middle of printing. (Happened twice)
- the printout tilts in the X-axis direction.
At 250, the linear module is a newer version.
I reverted the firmware.
Known issues:
When printing certain large models, the X axis might appear tilted.
Occasional layer shifting.
Slight abnormal noise during bed heating.
I expect that the reason they are writing this way is because the error is only occurring occasionally, and they are not sure if they have identified the cause of the error or if their coping strategies are working well, so they are taking a wait-and-see approach.If there is no clear confirmation that the error has been resolved, then I think that we should not integrate it into the official version and release beta 3.
Could you please send me the log files to lisiqi@snapmaker.com? We havenāt identified anything similar to issue 1, so we need your logs for further investigation.
I sent the log file to info@snapmaker.com.
No.147789
I think it would be pointless to have any further testing period for firmware version 2.1.0.
Do you have any plans to release the next beta version?
I had this issue, too. But I cannot provide logs, sorry.
For those who are concerned about the development and testing process of the vibration compensation firmware, weāre sorry to inform you that the next release, whether it be a beta, stable, or integrated version, will be postponed until at least the end of this year. Since the initial release of this firmware, our R&D team has been closely attentive to your feedback and has thus indeed identified some critical issues that weāre still working hard to resolve.
We have decided to delay the release for two primary reasons. Firstly, we donāt want to rush the release of a new version that might introduce new issues and disappoint you; we want it fully tested and ensure it is either bug-free or contains only minor ones. Secondly, the resources required to achieve such a release just mentioned have proven to be more than estimated and cannot be allocated at the moment.
However, it is important to note that the release is only being postponed and not canceled. We will still work on this firmware and bring you all a better creative experience.
Thanks for your understanding and patience. Have a nice day!
Is there a way we can assist?
Weāre currently evaluating when to open-source the 2.0 vibration compensation firmware. After itās open-sourced, interested and enthusiastic users will have the opportunity to participate in improving this firmware at their will.
Regardless, any contributions will be sincerely appreciated and remembered by Snapmaker.
I meant if there is an established program of beta testing (internal) that can be expanded to enthusiasts from community. That would require to test a scenario and report back in a format that allowed for devs to understand and improve upon. Attach some incentive to it and you could recruit some people (myself included) for the benefit of all. This is done in other companies.
Frankly sounds like at this point releasing it to open source would be equal to it being abandoned by snapmaker dev team in hopes of community sorting it out on its own.
Please rest assured thatās not our intention. Weāre still discussing plans for the best interest of our users, but one thing is certain: we will not abandon this firmware and just leave it solely to the community.
Thanks for your continuous development and for not āforgettingā us Snapmaker 2.0 users!
Not to be rude, but there isnāt really a choice in open-sourcing the firmware. Under the GPLv3 license of Marlin, Snapmaker is required to release their Marlin-based firmware sources.