Delays and Distractions

A project log for Lerdge 3d Printer Mainboard Hacking

Breaking the encryption on the Lerdge series mainboards so I can try porting Marlin 2.0 to it.

J.C. NelsonJ.C. Nelson 01/22/2019 at 18:324 Comments

I was fairly close to being ready to declare this printer running at an alpha state and add it to the Marlin 2.0 compatibility table. All I had to do was get a few test prints done and I'd be happy.

Easy, right?

First, I found an issue with my variant in Arduino. In ST's core, every pin has to be mapped to an ADC if it's going to be used for analogRead(). And guess who didn't have an ADC for the hotend pin.

Easy fix.

I wire everything up...and still don't get a reading. This sent me down a rabbit hole checking and rechecking, but finally I hit an easier answer. We're at the part of the project where theory meets reality, and the bits and wires intersect.

I had a broken thermistor. I don't know where it's broken, but it is. So I wired in a new one...and discovered my hotend was destroyed. How did this happen?

One of the last fixes I did fixed the E0_AUTO_FAN, so the hotend is automatically cooled. But right before that, I'd done a temperature test, and (sigh) cooked the PFTE liner in my hotend. 

Good news? Thermal runaway detection at both min-temp and max temp works 100%.

Bad news? I'm wiring a new hotend into the printer.

At that point, I'll print the lucky cat...and have a beer.]


warlockd wrote 01/23/2019 at 19:22 point

Humm.  Its funny thinking of a proper chip vs the Atmega.  I was going to say it might be hard to drive updates on a LCD and keep the rather fast step isr without skipping steps, but then I realized that you can DMA the screen...  Hell.  When I think of it, I bet you can dma the stepper pins humm.

Glad your working on this, I bought one of these half a year ago to do what you were doing, but it took 2 months to get the USB/hot bed adaptor and promptly forgot about it:P

  Are you sure? yes | no

J.C. Nelson wrote 01/23/2019 at 23:06 point

DMA from a memory buffer to the screen is absolutely possible. There's currently a few problems. First, Marlin currently draws to a bit buffer and then blits the buffer in during the next page command (thanks, U8G). That buffer is way too large to fit in memory as a fully expanded byte array. Secondly, we don't currently have assets in SPI RAM for use (if we did, we could DMA from SPI ram to LCD). In theory, looking forward, we could begin simply: Have a background "image" - aka, the fan box, the bed symbol, FR, etc that is in SPI flash. We DMA that in. Then we draw the text in on top using more "normal" commands.

  Are you sure? yes | no

J.C. Nelson wrote 01/23/2019 at 06:55 point

LCD updates - I think having custom LCD code (with less functionality than the table driven menus) is not only possible, it's a natural evolution. First I want to see everything print solidly.

  Are you sure? yes | no

Kenn wrote 01/23/2019 at 06:02 point

Nothing like  everything that worked yesterday is not working today when you have other unknown problems you are trying to track down. I think we all have run in a circle with our foot nailed to the floor... 

I know this is way cart before the horse. but is there a way we can use icons and a  full color display? I know some makes (flyingbear) actually offer some sort of customization for their display and they are running marlin but I don't know where the code is actually implemented. Anyway really I appreciate you skating on the bleeding edge for SCIENCE!!  

  Are you sure? yes | no