Prusa-firmware: Unifing MK2 and MK3 firmware

[GurliGebis]

Is there a plan to combine the two firmwares into one, or can we expect 3.1.0 to be the end of the line for the MK2? If so, do you need/want any help?

[thess]

Good question! I can't wait for the Prusa response.

At the moment I don't think you can even compile the MK2 variants. And... it looks like the MK3 code was forked from the master/MK2 branch long before any warnings cleanup, or any other contributions, were done - plus they've added a bunch more questionable code. Good luck.

[GurliGebis]

That is what I am fearing indeed. There is a lot of people with MK2's that would be sad if we already are at the end of the line for that one.

[JohnOCFII]

And... it looks like the MK3 code was forked from the master/MK2 branch long before any warnings cleanup, or any other contributions, were done

It looks like they did the fork at 3.0.6 -- that is quite a while back. It looks like they cherry picked a few things from 3.0.12, but it's hard to tell as the comments are not very verbose throughout the MK3 firmware.

[PavelSindler]

Yes there is plan to combine MK2 and MK3 fw together.

[GurliGebis]

Okay, please let us know if you need any help, I know the community will be more than happy to help

[PavelSindler]

Thank you.

[FischOderAal]

Thank you very much for the reply. The implementation will be interesting. I'd like to cheap out and use TMC2130 on the MK2 instead of buying a MK3. From my assertion the easiest way to do this is using SCK, SDI, SDO from the ISP header and CS from the MAX end stops. This would allow to at least swap X,Y and Z and keep compatability with MMU and 2.5 upgrade (filament sensor uses I2C?).

[3d-gussner]

@PavelSindler How can we help to merge the MK3, MK2 branches in one, as there also will be a need for the MK2.5?
I created a 'Unified_Prusa_Firmware' branch where i will try to merge the different branches.

The differences between MK2(s),MK2.5 and MK3 as far i can see are:

1. Controller board: Prusa already updated the boards.h and pins.h files (pins_Einsy_0_3.h, ..., pins_Rambo_1_3.h).
2. 12V vs 24V: Differnet PID settings Hotend and Bed, current settings for the stepper drivers
3. 12V vs 5V FANs: As the hotend and part cooling fans are 12V onMK2(s)/MK2.5 and 5V on the MK3 i am not sure if there is a need to have different PWM settings to get same airflow rates for cooling?
   3.a. Fans with RPM: MK2(s) doesn't has RPM sensing fans. The MK2.5 (curious where these will be connected to on the miniRAMbo) and MK3 will have RPM sensing fans.
4. Build volume: MK2(s) with 250x210x200 / MK2.5 with 250x210x200 / MK3 with 250x210x210
5. Endstops: MK2(s) and MK2.5 need mechanical endstops, the MK3 doesn't, so homing is different
6. Filament Runout Sensor: MK2(s) need a mechanical or optical sensor (as I implemented in my fork) and MK2.5 and MK3 use the new laser PAT9125 I2C sensor
7. Bed calibration is bit different between MK2(s) and MK2.5/MK3, as the MK2.5/MK3 need the spring sheet removed
8. Mesh bed leveling is bit different on MK2(s) and MK2.5/MK3, as the MK2(s) needs the 9 calibration points and the MK3 can scan the removable sprint sheet anywhere
9. PINDA vs PINDAv2: The MK2.5 and MK3 use the PINDAv2 (curious how Prusa will connect the PINDAv2 thermistor to the miniRAMbo with the MK2.5 upgrade)
10. Ambient thermistor: Is only on the MK3 EINSY board
11. Power Panic: Is only on the MK3 EINSY board possible
12. 2Mb Flash: Only on the MK3 EINSY. Would be nice to make the daughter board available for the miniRAMbo too. As far i can see from the schematics it should be able to do that. As the ATMega2560 is limited in EEPROM, Memory, ...(I already hit the limits by adding languages or diagnostics to MMU firmware) and Prusa adds more and more features they decided to add additional flash memory and it would be great if MK2(s)/MK2.5 owners could use these new features, wizzards as well as the MK3 owners.

Most of the things are already in the Configuration_prusa.h (variants/...) files, some MK2 are 'old'.

Did i miss something?

[thess]

@3d-gussner - Re: Item 12 above. What gives you the impression that there is additional memory on the Einsy? It's still a stock ATmega2560 with 256KBytes of flash (I guess that you could call that 2Mbits :smile:)

The only schematic I have seen is here: https://github.com/ultimachine/Einsy-Rambo/blob/1.0a/board/Project%20Outputs/Schematic%20Prints_Einsy%20Rambo_1.0a.PDF

[Panayiotis-git]

@3d-gussner - Item 4: I think that the build volume of the MK2.5 will be the same as the MK2(s).

[3d-gussner]

@Panayiotis-git you are right as you don't get the frame as in the MK3 upgrade kit. Changed it :-)

[3d-gussner]

@thess The newest schematics are https://github.com/ultimachine/Einsy-Rambo/blob/1.1a/board/Project%20Outputs/Schematic%20Prints_Einsy%20Rambo_1.1a.PDF (sheet 5 section D1-D3) and in the assembly manual 8. Electronics Step 8 you see two Einsy boards (pity both showing v0.5c as one should be v1.1a) one with a daugtherboard which has a flash on it.
The Bom shows that U13 is:
"2Mb" "IC FLASH 2MBIT 104MHZ 8USON" "U13" "USON8 2X3" "W25X20CLUXIG TR" "W25X20CL"
So you get additional 2Mbit of flash.
Somewhere it was mentioned that due to the limits of the ATMega 2560 Prusa/Ultimachine added this flash to get all features and languages in the firmware.

I had until 3.0.12 no issues adding an additional language to the firmware, with 3.1.0 it changed and i hit a limit so the printer behaved strange.
That's why i have 6 hex files of the firmware in the releases:

1. Stock languages
2. English, German, Dutch, French and Italian
3. English, Spanish, French, Portuguese and Dutch
4. MMU English, Czech and Polish AND SUPPORT_VERBOSITY enabled
5. MMU English, German, Dutch, French and Italian AND SUPPORT_VERBOSITY enabled
6. MMU English, Spanish, French, Portuguese and Dutch AND SUPPORT_VERBOSITY enabled

[GurliGebis]

Might it be time to split the firmware into one language per hex file?

[JohnOCFII]

How much space did adding the V2calibration to the binary file take?

[thess]

@3d-gussner - Nice to see the external SPI flash chip. It's not much more usable than a built-in SD card without the burden of SdFat. I also see zero support for a second SPI device at the moment connected to that port (maybe I missed something).

[thess]

@JohnOCFII - About 5200 bytes for MMU and 4200 bytes for MK2S (different procedures for each)

[tvi675]

Are there any updates on this yet? 3.1.0 is still having ongoing problems with Octoprint causing many users issues. There's been multiple new releases for the MK3, but to be honest it feels like us MK2 users are just being left behind now. There's been no updates to the MK2 branch for 3 months now despite comments above that the firmware would be unified, so if it's going to be the case that there will be no future updates for the MK2 then fair enough, but it would be nice for users to be told!

[GurliGebis]

@tvi675 There has been some commits to the MK3 branch indicating that the MK2 and MK25 is going to be using that branch going forward (which makes perfect sense).

I don't think they have forgotten about the MK2(s) users, but it seems like the problems with the MK3 has caught them by surprise, causing them to focus on fixing that first, and then getting the MK3 firmware changed to work on all three versions.

[3d-gussner]

It is a pity seeing the MK25 branch also drifting away from the MK3 branch as it has done with the MK2.

Hope the Prusa development team get's some rest and time to consolidate the branches.
But as the MMU v2 seams to have an additional ATMega2560 controller board with 3 stepper drivers it will take a while i guess.
I tried to merge lot of fixes from the MK2 branch to MK3 but stopped doing it as the development was/is so fast and couldn't keep up with all these changes and pull requests.
Compiling the MK25 and MK3 branches gives so many warnings, some fixed in MK2 branch some are new, it makes it difficult to keep up.

@tvi675 Did you try to compile the MK2 branch yourself as it got in dec 2017 a fix by @thess but Prusa didn't release a new hex file since Nov 2017?