Open xC0000005 opened 4 years ago
@ppeterman for the change in sound, if you look into the config diff compared to the default config from marlin, there are these CLASSIC_JERK changes. I took a random delta config and tweaked it for the malyan. I took maybe too much. I have no idea why theses settings are for. Try revert them.
@mojocorp I've had a look at the README, and I would suggest having a "create your own branch" before modifying the Configuration.h - in fact, I seem to remember reading that last night, but I can't see that anymore?
I actually doubt its the CLASSIC_JERK setting (as thats mostly about how corners are done, but for me the printer sounds more 'musical' even on a straight line). I believe @xC0000005 is right with his assumption about timers.
@ppetermann I changed the procedure after creating a second github account to see how it looks like from the other side. I did not find a way to create a new branch directly from the github UI. And actually it's not that bad: everytime someone create/update a pull request, it appears in the list of pull request in my repo. Then everybody can have a look at what tweaks others are doing. What do you think could be the advantage of creating a separate branch ? Did you try to revert the classic jerk settings to original ? I don't remember how my printer sounded when I got it. Just remember it was incredibly loud and I almost immediately swapped the bearings.
Well, tbh, I believe most people won't need their own branch, or even edit the config - for them it probably is best if the build artifacts are available as releases somewhere.
For those oddballs (like you and me) who need a different configuration, because of changed hardware, there is on one hand the thing that they should know how to do a branch anyways (otherwise they shouldn't be touching code IMHO), or they will have rather typical modifications (like I'm having an e3d hotend) which would also best be provided throuh a release.
Having everyone do a pull request to you might seem a good idea at the start, but you will then end up having a load of conflicting open pull requests, and no way if distinguishing those from actual pull requests.
Also in my experience its easier to pull upstream and rebase an own branch on it, than to do (ones own config changes) on the local checkout of upstream.
I might look into the sound thing coming weekend, but as the printer prints quite well, I don't have a high priority on that - I'm more interested in figuring out the issues I'm having with the usb connection on autotune, but i guess that will need a lot more debugging than i can currently do.
Yes this procedure is only for people that need to do some changes. I want to put a binary firmware directly on the front page but the problem is I don't have the printer in it's original state, and the pid values are taken from different sources. I could not verify. Maybe someone with a stock printer will showup and then I could ask for the original pid autotune values.
@xC0000005 What do you mean by " change the F0 period/scale, it’ll fix that mostly." ? Where should I look ? Moreover, I try to find the 'pterodactyl' lcd firmware you mentioned but I could not find anything. Do you a link ?
https://bitbucket.org/megablinken/mp_mini_v1_lcd_experiments/src/master/
Last time i looked at it there was no compatibility for M300 screen
I’m told it works now.
On Apr 1, 2020, at 12:38 PM, mcheah notifications@github.com wrote:
https://bitbucket.org/megablinken/mp_mini_v1_lcd_experiments/src/master/
Last time i looked at it there was no compatibility for M300 screen
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.
@xC0000005 @ppetermann Since today the official Marlin bugfix-2.0.x support the Monoprice Delta Mini / Malyan M300 ! They just merged my pull request. But in order to get all the necessary Marlin options to fit on the 122K of flash, it's still necessary to activate LTO and another trick. So my repo https://github.com/papabricole/Marlin is still necessary if you need a complete firmware or build your own config...
Once Thinkyhead merges the command line build for V2 and delta, we should be able to set the LTO option in the build flags there!
@xC0000005 My M300 PR was merged. For the M200 and M200V2, Marlin it's not using ststm32/stm32duino and that's why it's failing. I have a fix in my repo https://github.com/papabricole/Marlin . I've written a comment about it, but no answer so far. Since my M300 PR was a long way to get merged, I won't propose a new PR for the M200 serie. You are free to propose my fix. The LTO flag cannot be simply activated since stm32duino 1.8.0 is not compatible anymore with this option. Firmwares build with LTO immediately crashes (gcc bug that was someown workedaround in 1.7.0). The only solution I have so far is to patch stm32duino 1.7.0 to add the M300 support.
Once Thinkyhead's "build from PIO" PR is in, we can set the version of STM32DUINO in the environment to 1.7.0. I'm checking out that PR tonight, since I've been figuring out the V3 protocol and adding LCD support for it. Also, I'm going to take a quality of life hack to set the timers right.
For the m200 why not if you need lto, but the m300 variant comes in stm32duino 1.8.0. Thats why i patch 1.7.0 ....
From Hackaday - I've compiled using the M200 V2 variant and it's close to work. Your branch only compile with STM32 cores 1.6. I've rebased your branch onto the current marlin bugfix-2.0.x and compiled it with STM32 cores 1.7.0.
Working:
XYZ motors
min/max end stops
lcd
hotend + temperature
bed temperature
auto bed leveling
NOT working:
hotend fan (blocking)
sdcard => Recv: echo:SD init fail (blocking)
bed heater (major)
endstops status led (cosmetic)
NOT sure:
NOT tested:
extruder (not tested yet, probably just work)
print via usb (no hotend fan...don't want to melt my extruder)
Limitations: