search

xC0000005 / Marlin

Optimized firmware for RepRap 3D printers based on the Arduino platform.
http://www.marlinfw.org/
GNU General Public License v3.0
22 stars 5 forks source link

M300 Issues thread #5

Open xC0000005 opened 4 years ago

xC0000005 commented 4 years ago

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:

NOT working:

NOT sure:

NOT tested:

Limitations:

xC0000005 commented 4 years ago

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 commented 4 years ago

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

mojocorp commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

mojocorp commented 4 years ago

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:

mojocorp commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

for heater and fans I use soft PWM

mojocorp commented 4 years ago

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: git@github.com: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 commented 4 years ago

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

mojocorp commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

mojocorp commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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:

ppetermann commented 4 years ago

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 commented 4 years ago

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 notifications@github.com 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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 notifications@github.com 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 commented 4 years ago

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 commented 4 years ago

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 notifications@github.com 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 commented 4 years ago

My Malyan M300 marlin configuration: git@github.com:papabricole/Marlin.git , checkout the branch 'malyan-m300' The 'malyan-m300' branch contains 2 commits:

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

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

Good luck!

mojocorp commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 notifications@github.com 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 commented 4 years ago

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 commented 4 years ago

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

Flash:

mojocorp commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

xC0000005 commented 4 years ago

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 notifications@github.com 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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 . (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 notifications@github.com 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 commented 4 years ago

@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 commented 4 years ago

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 notifications@github.com 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 .