M300 Issues thread

[xC0000005]

trafficstars

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:

• eeprom (M500 is ok, but M503 does not reflect the changes after restart)

NOT tested:

• extruder (not tested yet, probably just work)

• print via usb (no hotend fan...don't want to melt my extruder)

Limitations:

• cannot enable LCD and EEPROM, not enough Flash (I reduced a lot the size required by the eeprom but with more work, it may eventually fit)

[xC0000005]

Things I've found fixes for (I pulled a fresh copy of the 2.0.x branch, copied in the example fixes, and started working on it: In Configuration_adv.h, #define E0_AUTO_FAN_PIN PB8 - this enables the EXTRUDER. I suspect the intention was to have it set to MALYAN_FAN1_PIN, but since I knew it was PB8, I just put that in. In Configuration.h, enable #define FAN_SOFT_PWM

SD wouldn't init In configuration.h, I enabled: #define SPI_SPEED SPI_QUARTER_SPEED

What version of the printer are you using?

[mojocorp]

What version of the printer are you using? Monoprice Delta Mini v43

[mojocorp]

#define E0_AUTO_FAN_PIN PB8 does NOT work, but the status led turn to solid green when the fan must be off and off when the fan must be on. If I change to PA8 (like mcheah/Marlin4MPMD), then the fan work exactly as expected BUT the homing fails! it seems like there is a side effect on maybe the endstops or something else.

#define SPI_SPEED SPI_QUARTER_SPEED or #define SPI_SPEED SPI_HALF_SPEED It does not change anything, still "SD init fail".

The extruder does not work. If I change E0_ENABLE_PIN to PB0 (like mcheah/Marlin4MPMD), I can enable/disable the extruder motor. Step and Dir don't seem to work.

I played a bit with M42 and I've found some pins: M42 P0 S0 -> blue led on M42 P1 S0 -> green led on M42 P13 S0 -> red led on M42 P30 S0 -> enable XYZ motors M42 P28 S0 -> enable E motor M42 P12 S255 -> turn on hotend fan (after few secs, the 3d printer crash)

[mojocorp]

I checked with a multimeter and the bed heater is connected to PA5 as expected ( https://eu.mouser.com/Datasheets/_/?Keyword=STM32F070CBT6&FS=True ) But still not heating. I event tried "#define HEATER_BED_INVERTING true" and nope, did not work. I reflashed mcheah/Marlin4MPMD to be sure the mosfet was still alive and yes it is. Is it possible that the STM32 cores variant is wrong ?

[xC0000005]

It just hit me that you're using a Delta. Ok, yeah, it's entirely possible I got some of the pins wrong (sorry). Let me see if my delta has the same problems.

[xC0000005]

variant

It's certainly possible. If you swap extruder and bed pins, does one of them come on and other not? (I'm checking to see if it's a pin definition). Checking the variant pins, PA5 is index 25, and it appears to be correctly defined as PA_25 in the CPP file. It may be that Marlin is attempting PWM on PA5, which isn't wired to a timer at all. I'll look and see if there's a soft pwm for heaters.

[xC0000005]

Confirmed that PA5 does not have hard PWM capabilities. I'll see what options there are.

[mojocorp]

If you swap extruder and bed pins, does one of them come on and other not?

I swapped the pin definitions for hotend+temp <=> bed+temp:

• hotend work as expected using the bed gcode commands
• bed does NOT heat and marlin goes to failure after ~20s

[mojocorp]

• Now I have xyz and e motor enable pin working (PB10 and PB0)
• If I change STEP_TIMER to 6 and TEMP_TIMER to 7, then the hotend fan work perfectly on PA8. No crash or side effect on homing/motors.
• The bed still does not work
• The sdcard still cannot init
• The extruder still does not work

My understanding is there was a kind of timer conflict. I had to guess what STEP_TIMER and TEMP_TIMER are. Any idea what are the correct numbers?

[xC0000005]

To answer one question - the "right numbers" on any STM32 board are timers that don't conflict with other PWM pins. If 6 and 7 work, we can define them in the pins.h and that'll be fine. Bed's going to be an issue - I'll ask Mickey what he does for M4MPMD and see. My guess it's a soft PWM.

[mcheah]

for heater and fans I use soft PWM

[mojocorp]

I always had FAN_SOFT_PWM defined, and my understanding is that it should use software pwm for the heaters as well. Any idea how to proceed ?

UPDATE: if I deactivate the SD card support, the bed heater and extruder are working ! I highly suspect the sd card pinout to creates all the troubles. eeprom stil does not work.

UPDATE2: while looking at the stm32 datasheet, it look like there are alternative pins for SPI (PB3 PB4 PB5). The current SPI pins (PA4 PA5 PA6 PA7) are already in use by the motors. I'm completely guessing since I'm not an hardware guy but do you think it could be the problem ? Any idea on how to activate the alternate mode ?

UPDATE3: I traced the connection for the SDCARD and the pins are PB3 PB4 PB5 PB6. #define SCK_PIN PB3 #define MISO_PIN PB4 #define MOSI_PIN PB5 #define SS_PIN PB6 Note that PB6 is not the hardware SPI SS pin. Even with theses changes, activating SD card support still does not work and break the bed heater. I suspect the SPI pins are not taken into account.

UPDATE4: Finally ! It's working ! The new SPI pins are good, "just" spiInit from HAL_STM32 does not take them into account. I had to add: SPI.setMISO(MISO_PIN); SPI.setMOSI(MOSI_PIN); SPI.setSCLK(SCK_PIN); SPI.begin(SS_PIN);

Now I can start my first print ! Still saving to eeprom would be a nice addition. There is a bug report about a similar issue on STM32duino. Could be just that.

My full config is available here: [email protected]:papabricole/Marlin.git (M300-2.x branch) but you need to adjust the arm lengths and extruder settings since my M300 is not stock.

[xC0000005]

The variant needs to have the SPI pins enabled and I can do that.

[mojocorp]

The variant needs to have the SPI pins enabled and I can do that.

Does it mean my changes to 'spiInit' won't be necessary anymore ? That would be great !

Another question: does the eeprom save/load still work with your M200 and STM32 core 1.7.0 ?

[xC0000005]

Ok, I was wrong. This is very closely related to the "Marlin can't cope with multiple SPI instances" issue - the STM32 HAL doesn't set the pins (and Marlin assumes a single SPI, period). Regardless, I'll add support for setting pins to the STM32 HAL.

[Evg33]

Multiple, simultaneous, SPI buses handling and Smart SD mounting https://github.com/LinoBarreca/Marlin/pull/7

[mojocorp]

Ok, I was wrong. This is very closely related to the "Marlin can't cope with multiple SPI instances" issue - the STM32 HAL doesn't set the pins (and Marlin assumes a single SPI, period). Regardless, I'll add support for setting pins to the STM32 HAL.

I'm using the M200 V2 variant right now for my M300, and it use the first SPI pins definition. Maybe if you create a M300 variant with just the alternate SPI pins by default? The M300 just need one SPI bus, not 2, or did I miss something?

I did my first print! I'll do more tests before declaring victory. UPDATE: 3rd print, no problem so far. I had my best first layer ever on this printer! Autobed leveling using 3 points is just perfect (I have a glass bed mod). I don't think other bed leveling methods make sense on this printer due to the mecanical way the probe work.

[LinoBarreca]

@xC0000005 let's not work twice on the same things or we will waste time. I can make a PR to marlin which will add multiple SPI (so others will be able to adapt the other HALS and make pr to my branch, so we will merge them all at once) although I'm still working on Hardware CRC from SPI

This is how I thought to handle it: https://github.com/LinoBarreca/Marlin/blob/MultiSPI/Marlin/src/pins/stm32/pins_BTT_SKR_PRO_V1_1.h

bus definitions with some default parameters (overridable by device) Device definitions with type, bus number, cs pin, and device custom attributes.

[xC0000005]

@LinoBarreca , this makes sense. It does appear that the "Marlin" way of doing things is usually not to put arrays in the pins files. A "marlin" style approach would have a bunch of defines like #define SPI1_MOSI PB5, etc #define SPI1_BIT MSB

and then in the code, a #ifdeff layered thing that assembles it. pins.h files tend to be a stack of #defines and nothing else. Other than that, it's looking good, and I agree, I don't want to duplicate.

[LinoBarreca]

@xC0000005 that array, actually, is populated at compile time through #ifdef and the idea of arrays isn't completely excluded #define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 400, 93 } the reason why they prefer avoiding arrays is because they are hard to manage at build time (boost preprocessor could come into help for that) ...but for the purpose of what I did they are necessary because to find a device (SD card) you actually loop the array instead (over a variable range of boards) instead of defining it as "SD1, SD2, SD3".....same for extruders or axis... more elegant solution to a variable-scale problem.

[mojocorp]

I've tested overwriting the SPI pins in a new M300 variant and it's working.

see https://github.com/papabricole/Arduino_Core_STM32/tree/malyan-m300

Should I propose a pull request to STM32 core or you handle it ?

[xC0000005]

I've tested overwriting the SPI pins in a new M300 variant and it's working.

see https://github.com/papabricole/Arduino_Core_STM32/tree/malyan-m300

Should I propose a pull request to STM32 core or you handle it ?

Go ahead and request it - I'm working on DMA handers in the core, mostly.

[mojocorp]

Ok, pull request merged. The M300 support will probably be available for STM32 core 1.8.0. Next step, find eeprom bug and propose a Marlin branch.

[mojocorp]

@xC0000005 Please confirm saving to "eeprom" work for you on M200 V2. Thx.

STM32 cores 1.8.0 add support for the M300 but Marlin crash with this version. Only 1.7.0 work for now. For the eeprom, I kind of workaround the problem by adding: bool PersistentStore::access_start() { +SERIAL_ECHOPAIR("access_start ", capacity()); While it's obviously not a solution, it does not crash anymore and work as expected. This problem may be fixed in STM32 cores 1.8.0...don't know yet. Wait and see.

[ppetermann]

Apologies for using this issue to ask, but this is from all places on the net that I could find the place with the most recent activity (and even that seems a few month ago).

I'm interested in Marlin 2.0 for the M300, and I stumbled over the project on hackaday, and I've spend some time looking around the repos and branches linked.

Honestly? I can't figure out how far the m300 support is atm, if anyone is still actively pursuing it, or if anyone actually has some repo somewhere where the efforts of all of you are brought together. So is there any chance someone could post an update/overview of the efforts and their state?

[mojocorp]

Apologies for using this issue to ask, but this is from all places on the net that I could find the place with the most recent activity (and even that seems a few month ago).

I'm interested in Marlin 2.0 for the M300, and I stumbled over the project on hackaday, and I've spend some time looking around the repos and branches linked.

Honestly? I can't figure out how far the m300 support is atm, if anyone is still actively pursuing it, or if anyone actually has some repo somewhere where the efforts of all of you are brought together. So is there any chance someone could post an update/overview of the efforts and their state?

I have a working version for the m300 but:

• you need a new 10A power supply otherwise the printer will crash as soon as the bed start to heat (the genuine firmware alternate the nozzle and bed to lower the power consuptiin but it result in poor bed temperature control)
• it currently does not compile/work out of the box due to a problem with marlin and stm32duino 1.8.0. (Could be solved but I could not find any info about it) So: I can compile (but not test) a firmware for you, or try to write some kind of convoluted build instructions.... In both cases, you need to invest some time for testing and reporting.

[ppetermann]

I've got a new power supply already on the way to me. that said, marlin4mpmd seems to deal with the power issue by ensuring that its never powering the bed and the hot end at the same time.

I believe build instructions are the better choice, as my machine isn't fully stock and might help others to hop on and help out as well.

Investing Time, well I don't expect it to be perfect out of the box, so I'm expecting to invest a bit of time when I have some

[xC0000005]

Create a PR and I'll see why it doesn't compile (unless you mean "doesn't compile with PIO). I'm currently trying to figure out why the #ifdefs i timers.h don't work - we should be using board-specific timers but it isn't.

On Sat, Mar 7, 2020 at 7:44 AM Peter Petermann [email protected] wrote:

I've got a new power supply already on the way to me. that said, marlin4mpmd seems to deal with the power issue by ensuring that its never powering the bed and the hot end at the same time.

I believe build instructions are the better choice, as my machine isn't fully stock and might help others to hop on and help out as well.

Investing Time, well I don't expect it to be perfect out of the box, so I'm expecting to invest a bit of time when I have some

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/xC0000005/Marlin/issues/5?email_source=notifications&email_token=AHVGS4NJ4IMHZ5SFNPV5L23RGJTXDA5CNFSM4JW2LZC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOD4RJA#issuecomment-596101284, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHVGS4P5DBQQJ5OUGKRA5I3RGJTXDANCNFSM4JW2LZCQ .

[mojocorp]

It's not that it does not compile, its more that it does not work ... I've created the m300 variant based on stm32duino 1.7.0 and it worked with marlin 2.0 with a small bug in save eeprom that I workaround but can definitevely not be merged to marlin (using a printf fixed the issue...). The second problem is my variant was officially release in stm32duino 1.8.0 and when I tried, the printer crashed immediately. The guys from stm32duino told me marlin need to be adapted and some workaround removed. Since I had a working version, I stopped there. The third 'issue' is my m300 is not stock (glass bed, bondtek extruner clone, longer arms) so my marlin 2.0 config is custom. I can try to findout the stock parameters but cannot test. Moreover I'm constantly traveling the next 4 months and don't have access to my m300 to do some smoke tests. I'll try next week to better resume all this and give you my branches.

[mojocorp]

I've got a new power supply already on the way to me. that said, marlin4mpmd seems to deal with the power issue by ensuring that its never powering the bed and the hot end at the same time.

I believe build instructions are the better choice, as my machine isn't fully stock and might help others to hop on and help out as well.

Investing Time, well I don't expect it to be perfect out of the box, so I'm expecting to invest a bit of time when I have some

Alternating the nozzle and bed heater result in a poor heating control. It take ages to heat up the bed and when I tried, it could not really go over 50 degree. With a 10a power supply and without the trick, It work perfectly. At least I tried until 70 degrees, fast and stable. Moreover, this alternating trick will never be accepted by marlin since buying the correct power supply is the real solution ( you may have some fire hazard as well, but I'm not an electrician) To resume: I will personally never implement and try to propose such thing to marlin.

[xC0000005]

The reason "it does not work" is that board-specific timer overrides don't work currently (and I have zero idea why). That's why setting the timers in the headers works, as well. There's another approach to the whole heating thing that requires zero "marlin" changes. Reduce your P value for both PIDs and increase the heating windows. Since acts as "attack" or how hard the heater is spiked to move in a direction, reducing P reduces pull, but results in longer heating time.

On Sun, Mar 8, 2020 at 4:21 AM mojocorp [email protected] wrote:

I've got a new power supply already on the way to me. that said, marlin4mpmd seems to deal with the power issue by ensuring that its never powering the bed and the hot end at the same time.

I believe build instructions are the better choice, as my machine isn't fully stock and might help others to hop on and help out as well.

Investing Time, well I don't expect it to be perfect out of the box, so I'm expecting to invest a bit of time when I have some

Alternating the nozzle and bed heater result in a poor heating control. It take ages to heat up the bed and when I tried, it could not really go over 50 degree. With a 10a power supply and without the trick, It work perfectly. At least I tried until 70 degrees, fast and stable. Moreover, this alternating trick will never be accepted by marlin since buying the correct power supply is the real solution ( you may have some fire hazard as well, but I'm not an electrician) To resume: I will personally never implement and try to propose such thing to marlin.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/xC0000005/Marlin/issues/5?email_source=notifications&email_token=AHVGS4L7XEJ6XRJZE3GDWE3RGN5UZA5CNFSM4JW2LZC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOETI3Q#issuecomment-596194414, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHVGS4OKVC2QGJRPKBIEFITRGN5UZANCNFSM4JW2LZCQ .

[ppetermann]

Reduce your P value for both PIDs and increase the heating windows. Since acts as "attack" or how hard the heater is spiked to move in a direction, reducing P reduces pull, but results in longer heating time.

longer heating time would mean i-gain accumulates longer, bringing up total, so chances are you'd just end up drawing too much a bit later, as P isn't really limiting..

[xC0000005]

I'll do some tests and see how high the default one can go if it's by itself for the bed, then with the hotend (with the understanding that I have no intention of setting the hotend temp higher than 245). For bed temps, what are most folks aiming for? 100C for ABS?

On Mon, Mar 9, 2020 at 10:29 AM Peter Petermann [email protected] wrote:

Reduce your P value for both PIDs and increase the heating windows. Since acts as "attack" or how hard the heater is spiked to move in a direction, reducing P reduces pull, but results in longer heating time. longer heating time would mean i-gain accumulates longer, bringing up total, so chances are you'd just end up drawing too much a bit later, as P isn't really limiting..

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/xC0000005/Marlin/issues/5?email_source=notifications&email_token=AHVGS4IM5CY5Z3JLTKYLRFDRGURO5A5CNFSM4JW2LZC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOIHLYA#issuecomment-596669920, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHVGS4K5L22N42UXCBQB4ULRGURO5ANCNFSM4JW2LZCQ .

[mojocorp]

My Malyan M300 marlin configuration: [email protected]:papabricole/Marlin.git , checkout the branch 'malyan-m300' The 'malyan-m300' branch contains 2 commits:

• a workaround due to a crash while saving to eeprom
• a config for my customized M300 (obviously, you have to update it)
• optionally you can rebase my branch onto the latest Marlin 2.0 branch (untested)

Adapt the config. Follow the build M200 instruction from xC0000005 but:

• select 'M300' variant in the arduino ide
• select "optimze: Smallest (-Os) with LTO (otherwise it will never fit in 120k of flash) If the firmware just work then someone fixed the stm32duino 1.8.0 problem.

If the firmware crash, you have to use stm32duino 1.7.0 + the M300 variant:

• checkout the 'malyan-m300' branch from [email protected]:papabricole/Arduino_Core_STM32.git
• Findout on your computer where the Arduino ide installed stm32duino and replace the content with the content from my repo. It should just work now. If you experience a crash while saving to eeprom, cherry-pick the other commit in my Marlin repo.

Good luck!

[mojocorp]

The reason "it does not work" is that board-specific timer overrides don't work currently (and I have zero idea why). That's why setting the timers in the headers works, as well.

Do you have a commit with this workaround ?

[xC0000005]

https://github.com/xC0000005/Marlin/commit/a36eda3cdc3687038b164d0920ad3de8f4fc28d8

Only the changes to the timers.h file matter. Have you considered making a PR to marlin to add the M300 if it's not there already?

[mojocorp]

a36eda3

Only the changes to the timers.h file matter. Have you considered making a PR to marlin to add the M300 if it's not there already?

No since:

1. I had a crash with the official stm32duino 1.8.0 (the only version supporting the M300)
2. my config is custom, it's not the stock one.

I can solve 2) but cannot test it. For 1) I'll look at your fix.

[xC0000005]

I'm almost certain there's an include order issue. I looked at your fix for the crash and it makes no sense. As long as the binary is less than 112k, EEPROM emulation should be fine (8k stock bootloader, 8k total space taken by flash emulation).

On Tue, Mar 10, 2020 at 7:34 AM mojocorp [email protected] wrote:

a36eda3 https://github.com/xC0000005/Marlin/commit/a36eda3cdc3687038b164d0920ad3de8f4fc28d8

Only the changes to the timers.h file matter. Have you considered making a PR to marlin to add the M300 if it's not there already?

No since:

1. I had a crash with the official stm32duino 1.8.0 (the only version supported the M300)
2. my config is custom, it's not the stock one.

I can solve 2) but cannot test it. For 1) I'll look at your fix.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/xC0000005/Marlin/issues/5?email_source=notifications&email_token=AHVGS4L2263B6OSXIYU5WK3RGZFWTA5CNFSM4JW2LZC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOLVBOQ#issuecomment-597119162, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHVGS4IAUMDADXDMBO7AGK3RGZFWTANCNFSM4JW2LZCQ .

[mojocorp]

I just tried with Marlin 2.0.5.2 + Stm32duino 1.8.0 and no luck, the printer does not respond at all, no usb nothing. @xC0000005 does the M200 work fine for you ?

[mojocorp]

@ppetermann I've a new way to generate a working firmware using only github:

• fork https://github.com/papabricole/Marlin
• switch to the 'malyan-m300' branch in the github gui
• edit the config files directly from github and commit your changes
• click on the github 'Actions' tab (create a workflow if necessary)
• a build action should be automatically triggered after each commit
• when the build succeed, download the 'firmware.zip' artefact

Flash:

• copy the content of the zip on an scard, insert in your printer, power-on
• the white led should blink

[mojocorp]

@xC0000005 good news about the eeprom hack; it's not necessary anymore with the latest marlin bugfix-2.0.x. No idea why but cool.

[ppetermann]

alright, this is working, however the version number reported on ~bootup is strange: [insert here once print is done]~ the version number that was show after flashing, however i can't see the one at bootup, as splashscreen doesn't stay long enough, and the one in M115 is correct.

a few notes: to make the actions work I had to creat my own action - i just copied yours @mojocorp , had to give it another name though.

I had to adjust the M665 H; in my backups this one doesn't even show up, and mcheas marlin4mpmd didn't need any such adjustment, but with this firmware, I needed to set a bit more height, otherwise the level probing (G29 P0) would fail (never reaching the build plate) I assume that this is because my E3D Lite6 hotend is sitting a bit higher than the stock hotend, but my adjustment was more than it should be if this was the only factor.

I've started a print, which as far as I can see will come out just fine.

I'm noticing two things though, that don't seem to be a problem, but I figure are worth mentining:

1. the sound of the printer is distinctively different - its a bit more noisy, and the pitch of the sound is varying a lot.
2. there is a progres bar on the display field that keeps going from zero to full, and then reset and start again so rather than indicating progress it seems to indicate "working on something"

[mojocorp]

Strange that the progressbar does not work. Maybe the current marlin bugfix branch is buggy. Try to rebase on an officisl releasr maybe. To me its working perfectly fine. The only thing that does not work is printing using the wifi. I spent some time to debug the 1.8.0 crash and its due to the lto link option. Without the firmware is too big to fit in the 128k flash. If you k ow well the marlin config maybe you could reduce it and get rid of the lto option.

[ppetermann]

~why would you want to get rid of lto?~ never mind, just read the part about 1.8.0 again

[xC0000005]

I would suspect not having printf float support in the build so it goes to 100 when some rounding misbehaves. That code should really just send ints anyway.

On Mar 29, 2020, at 2:06 PM, mojocorp [email protected] wrote:

 Strange that the progressbar does not work. Maybe the current marlin bugfix branch is buggy. Try to rebase on an officisl releasr maybe. To me its working perfectly fine. The only thing that does not work is printing using the wifi. I spent some time to debug the 1.8.0 crash and its due to the lto link option. Without the firmware is too big to fit in the 128k flash. If you k ow well the marlin config maybe you could reduce it and get rid of the lto option.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[ppetermann]

So a bit more:

the Version string shown when flashing is: V99.160.3, shouldn't that be something thats aligned with the actual version?

The PID currently set as default are very low - now I don't have a stock hotend running, so they might work for stock hotend, but when having an already warm hotend (from a previous print), those won't accumumlate high enough to get over 222 degee (with the goal set to 230). Obviously that can be autotuned out... kinda.. because autotune doesn't work. When I start autotune from pronterface after a while it will complain about not being able to write to the usb connection anymore. the Autotune itself will run to the end, but even with the flag set it wont write the PID values in the end (however writing them down and manually setting after restarting the printer works).

I have G29 in my startcode, so it will run autolevel after heating up - however, for some reason during autolevel Cura shows a bed temperature thats through the roof (5 figures), while the display shows the actuall correct temperature. one autolevel is done, Cura will fall back to correct temperature quite quickly. I assume that this is not a Cura problem, but something weird sent, as Cura in the same version did not have that issue with previous firmware

[mojocorp]

There is an entire closed source firmware running just for the display and it communicates with Marlin to send/receive infos. I think the version displayed is the display firmware version, not the marlin one. Again, I have absolutely no problem at all, everything work: autotune, usb , all. I based the m300 branch onto a Marlin bugfix-2.x and it's maybe the problem you have. Try to rebase your branch onto an official Marlin release. I'm based onto Marlin 2.0.1. NOTE: usb is not working well with my mac (old mac with hacky dosdude Mojave) but working perfectly with windows or a raspberry pi + octopi. I do everything from octopi. NOTE2: I assume you use a 10A power supply, and a real 10A one.

[xC0000005]

That’s right and not why it’s happening. Attached to the LCD is an ESP8266 running Malyan’s firmware. There’s an opensource UI firmware for all malyan LCDs called pterodactyl, but what’s causing the version is in the malyan lcd .cpp file.

A little background - I don’t think Malyan (or Monoprice, of Malyan’s biggest resellers) cared at all about my little Marlin hacking project until I added LCD support. At that point, I had two different individuals reach out and say “We don’t want to be responsible for supporting people running Marlin.

That seemed reasonable to me.

The version numbers printed at startup are .<UI version> (I might have that reversed) but the point is, I chose 99 to signal “This is Marlin on the backend.” It gave an easy way to know what printers are running Marlin and which aren’t.

I just tested, and SD percentage works fine on my V2 which I JUST compiled on, and it’s the same code, so I think it works, but like I said, there are issues with integer/rounding if you don’t build with float support for printf/scanf.

The change in sound is absolutely Marlin’s “fault” - the timers are probably not running at the same interval as M4MPMD. If someone wants to look at that code and change the F0 period/scale, it’ll fix that mostly.

On Mar 31, 2020, at 10:10 AM, mojocorp [email protected] wrote:

There is an entire firmware running just for the display and it communicates with the main board to send/receive infos. I think the version displayed is the display firmware version, not the marlin one. Again, I have absolutely no problem at all, everything work: autotune, usb , all. I based the m300 branch onto a Marlin bugfix-2.x and it's maybe the problem you have. Try to rebase your branch onto an official Marlin release. I'll try to find out wich version I'm based. NOTE: usb is not working well with my mac (old mac with hacky dosdude Mojave) but working perfectly with windows or a raspberry pi + octopi. I do everything from octopi.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/xC0000005/Marlin/issues/5#issuecomment-606756867, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHVGS4KQWZOJ4CBRB4ZGA33RKIPXLANCNFSM4JW2LZCQ.

[mojocorp]

@ppetermann I've updated the README for my fork https://github.com/papabricole/Marlin. Could you review the build instructions ? I don't have a second github account just to test the build procedure using github actions... If you have more infos, just create a pull request. It's time to share the infos correctly. I have to write in the README why I cannot propose this config it to Marlin upstream.

@xC0000005 thanks for the version explanation. For the float printf, I use the nanofp option. You can look at the options we use in: https://github.com/papabricole/Marlin/blob/malyan-m300/.github/workflows/ccpp.yml The idea using the github actions is not only to simplify the build but also to share them. I would like to see ppetermann tweaks for example.

[xC0000005]

I think it's a fantastic idea (and something I should have thought of, but I'm actually better at reverse engineering than I am this kind of stuff). I'll look at it and figure out how to make a V1, V2, and M300 build trigger. If we had axis reverse GCODE commands, we'd be basically set (I have a branch with the ones for Wifi).

On Tue, Mar 31, 2020 at 1:30 PM mojocorp [email protected] wrote:

@ppetermann https://github.com/ppetermann I've updated the README for my fork https://github.com/papabricole/Marlin. Could you review the build instructions ? I don't have a second github account just to test the build procedure using github actions... If you have more infos, just create a pull request. It's time to share the infos correctly. I have to write in the README why I cannot propose this config it to Marlin upstream.

@xC0000005 https://github.com/xC0000005 thanks for the version explanation. For the float printf, I use the nanofp option. You can look at the options we use in: https://github.com/papabricole/Marlin/blob/malyan-m300/.github/workflows/ccpp.yml The idea using the github actions is not only to simplify the build but also to share them. I would like to see ppetermann tweaks for example.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/xC0000005/Marlin/issues/5#issuecomment-606857575, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHVGS4OTVCYHV6V7R5EI32DRKJHHFANCNFSM4JW2LZCQ .

[mojocorp]

@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.

[ppetermann]

@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.

[mojocorp]

@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.

[ppetermann]

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.

[mojocorp]

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.

[mojocorp]

@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 ?

[mcheah]

https://bitbucket.org/megablinken/mp_mini_v1_lcd_experiments/src/master/

Last time i looked at it there was no compatibility for M300 screen

[xC0000005]

I’m told it works now.

On Apr 1, 2020, at 12:38 PM, mcheah [email protected] 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.

[mojocorp]

@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...

[xC0000005]

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!

[mojocorp]

@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.

[xC0000005]

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.

[mojocorp]

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 ....