Hack Zortrax Driver board? Port Klipper?

[harryz]

Anyone interested in topic?

I have M300+ and it's a pain:
* Trash glitchy firmware with closed control format and no splines
* Trash slow and limited slicer software with issues of support distance on angles
* underpowered X-Y motors that make constant issues with layer shifts.
* Super low speed and lack of input shaping.
* Service nagging
* Bad design of often failing extruder cable
* Shit of a heat-bed
* Use of 12V Fans in 24V PWM system
* No part lists, pulled stickers form motors and fans
* Component stock always lacking, but will never tell you real part numbers
* Generally bad or no communication

Now, most of this would be easily solved with getting Klipper on the MCU board and forgetting about Zortrax.
But of course, as any "smart ass" would do - thye laser etched the chip names for MCU and drivers out.
Of course by packages and pin connection on board as well as reading some registers and scoping for quartz freq - we can clearly deduce the part numbers:

MCU is STM32F103VE and driver is LV8729V.
Android CPU is Allwinner A33

More and detailed info on my github, including debug pinout and some STlink / reg logs: https://github.com/zharijs/zmxxxp-re

1. Anyone interested? Up for collab?
2. Do you think I should try power glitch + ram exec attack on it to dump the firmware before trying to port Klipper to it?
3. Can anyone confirm if M300 dual, M200+ and OG M200 has same board? It seems they have as there's clearly port for the old LCD that is populated with piggyback board with buzzer and there's a "WiFi" module socket populated with piggyback to power Android Display and serial port to it. So I would guess the main board never changed after it was finished?
4. As far as I found, there are single VIAs to each of hte motor drivers - I wonder how well does that work. Should start limiting current above 2A or so I would guess.

Cheers, h-z

[Coordonnée_chromatique]

You seems to be very skilled but it is a gigantic work, i've seen an M300 equipped with a BigTreeTech SKR V1.4 Turbo 32 bits, it should be a lot easyer no ?

[harryz]

The board is rather simple. To get it to run Klipper should not be that hard.

Now - getting the Android part running Linux and some UI on it would be a bit harder.

Anyway -  I have 1/5th pins mapped out already. I'll post the note to git later.

I'll probably also try to get bin form the chip by ram exec / power glitch method just to see if it's works and to have a backup of original bin jsut in case.

About the time - yes, it will take some for me and whoever jumps on, but in the end it'll be a 1h upgrade for everyone else left with the barely usable m200 / m300 series (as I believe boards are likely same except for dual).

So in way of "larger picture" it makes sense to me to use existing hardware as much as possible. Also, the board is close to BTT SKR anyway. Well, tbh, they all are either shitty Arduino or SMT32F103/407/etc. Potato/Toamto.

[harryz]

* MCU board reversed, schematics drafted (at least he parts that matter)
* MCU board "WIFI" piggyback (goes to Android) schematic and connector pinout drafted
* MCU board "DISPLAY" piggyback (goes to optical end stops and hosts buzzer) schematic and connector pinout drafted
* Full (I think) MCU pin map done
* more pics
* more datasheets
* updated stm32cube file for pinout

All posted to https://github.com/zharijs/zmxxxp-re

h-z out.

[DrdPrtRgrs]

G'day Harry.
Already sent you pms through other forums, but I'd like to contribute. I'd made a start on my m200 but you seem way ahead based on the github. At the very least hopefully I can work parallel on the m200 and note any key differences, and step through the listed action items on the GitHub.
The main board looks identical for the m200, based on pictures, except it has an unused esp wifi chip that came pre installed, easily removable to no effect as it uses standard pins and not soldered. 
I'll check revision and everything tonight, but would love to get details on what method and pins you used to communicate and read the board. I think with the details you've given it will probably be much simpler to figure out why I couldn't the first time, but obviously it'll be much quicker to confirm from you so I don't spend a bunch of time being over cautious worried about shorting the wrong pin etc.
Then I can quickly confirm whether key components are the same or not.

[harryz]

I am quite sure you will be able to use the schematics. I'm interested in changes, but I expect:

1. You just don't have anything related to Android (Ethernet, USB hub, Button, front USB, level shifter and android boards)
2. The "WIFI" port on your machine is empty and in "DISPLAY" port you have a small board with graphical LCD on one SPI, SD card on other SPI and knob and buttons and buzzer on GPIO.
3. NOT sure if you have power fail detection
4. MCU pinout might have minor changes on older boards. Not sure - could be anything if it took them 5 major versions to come up with it.

Ah-ha - same board - thought so. Curious on what's the revision on yours will be.

Oh, very interesting - they shipped it with ESP32 WiFi and planned to use it as some WiFi bridge to Serial port or as host G-CODE (Z-CODE) processor? That's a cute idea. Does the module have internal antenna? That'd work well in metal box

As for the MCU debugger connection - I just used STLINKv3mini with a custom adapter I made for the debug port:
https://github.com/zharijs/zmxxxp-re/blob/main/Reverse/STM32F103%20stuff/Debugger%20Connection.png


Then I jsut used STM32CUBEprogrammer utility to connect to MCU and upon connection, of course, I get memory read error when it tries to fetch the binary as flash is locked. But at the same time connection is complete, we get 0x414 device ID and we can read all registers.

At this point we have multiple choices:
1. We jsut erase the chip so we can start coding and porting and writing to it.
2. We try to get the bin with the ramexec/powerglitch (needs modification to board to glitch the power of MCU - taking caps off, disconnecting the buck chip)
3. De-solder the chip. Solder brand new on on. Use the desoldered chips on a breakout board to do do ramexec/powerglitch later while working on the porting on the board with new chip.

I lean to go for option 3 just to have backups.

h-z

 

[Coordonnée_chromatique]

It is a cartesian printer, why use clipper instead of malin ?

[harryz]

My considerations are taht Klipper does:

1. Offloads heavy math to Linux board doing only the motion itself. Makes it faster.
2. Better kinematics and precision
3. Pressure advance instead of linear
4. Expandable to Additional I/Os on andditional klipper boards or Linux GPIO

5 What I actually want - Input shaping. And yes, I know Marlin sorta has it also, but there's no automatic loop calibration as far as I know.

6. I feel Klipper is more progressive solution in general. I don't want to rebuild Zortrax - I want to make it 2024 machine.

But with this work I'd also want the bottom line to be you-do-you-boo kinda thing. If anyone wants Marlin or a custom firmware on it - just fork my repo, use the reverese engineered parts you need and do roll your own as it goes. 
I guess what I'm saying is I kind of know my thing in boards, but I am no way pro in 3D printing. This story is about getting your own stuff on Zortrax boards and in no way about what exact stuff you should be getting on them.

h-z

[Coordonnée_chromatique]

The filament from different manufacturers or the same manufacturer with some viscosity dispersions between diferent batchs require significantly different pressure advance values.
It should be a little messy a to have to set up the values ​​for each spool, no?

[gte326h]

Harry, that github repository is gold. Thank you for sharing your hard work.
We have begun to switch a M200P to Klipper using a BTT M5P mainboard and TMC2209 drivers.

We have a fleet of M200/M200P and M300/M300P, some of the non-P models in use from when Zortrax started selling them.

The print quality is on par, if not sometimes slightly better than, good modern printers (inc. Bambu Labs).
For PLA, it does need more speed and therefore pressure advance (and modification of the toolhead to accept non-proprietary nozzles).
Otherwise, speed is not a huge problem since it creates poor layer adhesion for functional parts in other materials.

Do note that the extruder stepper motor already gets hot on extended prints. It heats up the all-cnc toolhead and eventually softens the filament between the extruder and heat-break enough that it will cause a jam. More speed => more heat. And there aren't many solutions to bring the extruder closer to the nozzle due to the crossed gantry design.

The main problems are...

• The slicer is very limited, missing basic options requested for years. Their gcode to z-code converter requires too much tuning. It's based on the open-source one that was already out there. Their upgraded speed firmware and "new" slicer are a joke band-aid for being stagnant for years.
• Parts were already a pain to get in a timely manner, and it's financial problems at the end of last year made it worse.
• Parts too expensive for their performance.
• The unacknowledged but very much existing M200P/M300P electronics problem when printing higher temp (eg. ABS) materials.

Regarding the last one for the M200P/M300P, the electronics get too hot and there will eventually always be a communication error between the Android board and the mainboard. Increasing air flow (fans) to the electronics bay only delays the problem. Besides, it doesn't cool down the Android board.

That's probably the reason their slicer profiles don't go above 70C or 80C on the bed. With larger ABS prints, it needs that bed closer to 100C for bed adhesion and to keep the chamber hot enough to prevent warping of parts. With heat soaking the printer for 30m before a print, that Android screen is already running too hot to be good for the electronics behind it....and it's been kept that hot for, lets say, a 30hr print.

The most common error is related to the serial communication between the two boards. Zortrax's official recommendation is to remove the level shifter between the Android board and mainboard, connecting them directly. It does work but eventually the heat will degrade the rest of the electronics.

Why is the level shifter suddenly not necessary? Is it because the Android Board is tolerant "enough" to receive the higher voltage signals?

[harryz]

Interesting.
I have m200p and m300p and I have ran some 12 day prints on m300p and I never had that comms issue. I'm in no way implying it's not there - I just have not went printing with that high chamber temp I think.

We have some ideas about the extruder modding. About converting the 300 and 300p to multi-head system. That will also solve many of the hotend issues.

I'm a bit overwhelmed in work atm, but the project is in no way stalled - I will port klipper to the OG board and I will probably extract the firmware before that for backup purposes.

Now about the Android board - It's pure shit. It's based on the cheapest and worst ever Allwinner CPUs. I've designed some Allwinner boards. A64, H3, H6, even older A20 are in general not bad CPUs. Excellent price / performance and the mainline effort for Linux is impressive. But that shit they chose - it's errata is longer than the datasheet and there is literally no Linux support.

I think I will just design a board that accepts the screen and rPi CM4 module to replace the trash they have there. Heat issues can also be managed with custom board.

As for the slicer and part availability - yes. They are so afraid someone will steal their "great" technology they lost the business, the customer base and the plot. Etching chip names off - that alone is such a stupid student thing to do. Anyone above "started yesterday" can find the chips by routing given time and willingness. It's a shame top management went bonkers after sniffing their own farts for too long there.

And don't even make me started on the speed mode. Such a dumb gimmick. It just does not work.

[Coordonnée_chromatique]

Now about the Android board - It's pure shit. It's based on the cheapest and worst ever Allwinner CPUs. I've designed some Allwinner boards. A64, H3, H6, even older A20 are in general not bad CPUs. Excellent price / performance and the mainline effort for Linux is impressive. But that shit they chose - it's errata is longer than the datasheet and there is literally no Linux support.
I think I will just design a board that accepts the screen and rPi CM4 module to replace the trash they have there. Heat issues can also be managed with custom board.
As for the slicer and part availability - yes. They are so afraid someone will steal their "great" technology they lost the business, the customer base and the plot. Etching chip names off - that alone is such a stupid student thing to do. Anyone above "started yesterday" can find the chips by routing given time and willingness. It's a shame top management went bonkers after sniffing their own farts for too long there.
And don't even make me started on the speed mode. Such a dumb gimmick. It just does not work.

Useless

[coppercone2]

lol these parts sound like a parody of companies in 80's c-grade scifi movies.

zortax.. not a name I would have faith in.

[harryz]

Which parts?

Zortrax is a Polish company. They ware first to produce a prosumer 3D printer that worked out of the box.

The mechanics are solid. Motion controller is OK-ish. Unfortunately they stopped innovating and updating the product. Firmware and software is very outdated by todays standards - thus effort to fix that with klipper.