[18:28] 6 hours ago, I was looking at the Tetent Timespy [gd0136] concept I had modelled the day before and desired to print it. I thought about the printers I had available. The CR600S is completely out of commision and the Tevo Flash needs a fan shroud tweak and a new fan, but I couldn't think of anything hardware related that stopped me from using the Linear Plus. 

Fixing auto bed calibration

Powered it on and it homed fine, so I started an Auto Bed Calibration and that's when I found out that the issue was firmware related. The printer wasn't moving to the correct next probe position. So, 5 hours ago, I got started.

Pulling from common

So my Marlin Github is set up to have "common" as the main branch that has all the common changes I make to all Marlin printers, and then printer specific branches. Since I didn't want any suprises, I pulled changes from common as-is instead of first pulling from marlin/bugfix-2.0.x. About an hour later after accepting changes, I was ready for the first compile.

Yeah I thought I could get away with this and marlin would automatically apply the value to the other 2 axes.

Yeah that make sense.

Oh yeah... that's right. There was some sanitycheck bug I found when compiling for the DP2. Instead of going into that file, adding a "!" and recompiling, let's take our chances and spin a win on a git pull bugfix2.0.x -> common.

Pulling from bugfix-2.0.x

So there's a bunch of new things I have to accept in the config files, and so I finish one and then see this:

Why is there so many things that failed to merge??? I haven't touched any of these files!

Thus, I "Accept all incomming" for maybe 20 files at a time, since, for some reason, I couldn't do all at once successfully.

Yeah... this is probably one of those "caught inside a merge" kind of errors. I don't know what they're actually called, but I imagine that a non-compiling codebase was pushed to the branch. I copy out the 4 files I've modified, hard reset the repository, paste the 4 files back in and... same result. 

Pulling from bugfix-2.1.x

Wait. There's a 2.1.x!?

So after like an hour figuring out how to pull from 2.1.x and not 2.0.x, I go through the config and find out what a TPARA is:

I accept changes in the config files, then do the same copy-out strategy mentioned above. 

Success?

FINALLY WE HAVE GREEN

Man it's so nice to see that logo, signalling a successful firmware flash.

The changes from the initial LP firmware is 

• changing the probe margin from 30mm to 45mm to increase the likeliness of the piezo sensors detecting a signal. The closer the probe point is to the edges, the closer it is to the rigid bed mounts and the less the bed vibrates enough to trigger the piezos.
• Reducing Z_CLEARANCE_BETWEEN_PROBES from 18mm to 10mm to see if a bug has been fixed since the last time I flashed firmware.

Solving the delta calibration issue

First time trying the auto calibration and the Z was moving down at a snail pace.

This is probably why. Changed that to 120mm/s.

Then the probing looked pretty gittery so I was thinking it was to do with a low DELAY_BEFORE_PROBING of 70ms. It barely succedded with a standard deviation of 0.49 after 3 iterations. Increased it to 200 and then 500ms and the calibration failed and made it more obvious that the bug I mentioned earlier was still around. For some reason, the printer won't move to the correct location if this value is too low.

I changed DELAY_BEFORE_PROBING to 100ms and increased Z_CLEARANCE_BETWEEN_PROBES back to 18mm/s. I got a successful calibration and after 4 iterations, the screen spat out a s.d. of 0.35. Now it's been entire years since I've last done a delta calibration, but I feel like the typical standard dev is 0.020, but maybe I'm misremembering 0.200.

My hypothesis was that 18mm was high enough for a full auto calibration, but not high enough for the linear plus to move to the correct points. I observed that the 3 middle points didn't really move that much from each other.

Thus, I increased the value to 24mm, and after 10 iterations...

Wow. It really was 0.020 deviation. It's likely because it's only working with rough defaults, but this is the first time I've seen Marlin go up to 10 iterations. Usually it's 6 with the one-off of 7. Anyway, that's everything up to this moment in time (now 19:44) and I've got to set up Cura 5.0. I also wonder if I shoud linstall a volcano nozzle and hex aluminium spacer as CNC kitchen has done more tests of what I was planning to do for the #SecSavr Sublime [gd0036]. I'm totally putting the 32mm nozzle in the Flash.

Getting a print

[21:55] So I copied over the cura config files into a new printer profile and set everything up for printing some £5/kg PLA. Repaired the SD card drive and put it in the printer.

Not really sure what could've happened. Perhaps I had finally broken something on the screen when I moved it earlier today?

The comments from this reddit post fixed the issue. I enabled SDCARD_CONNECTION LCD and I was able to get the SD card in a halfway position when it was detected. I theorised that the printer thought that the SD card was in when it was actually out, and vice versa, so I changed SD_DETECT_STATE HIGH to SD_DETECT_STATE LOW. While I was here, I found out about and turned on BROWSE_MEDIA_ON_INSERT and MEDIA_MENU_AT_TOP which are very nice Quality Of LIfe features to have. I uploaded the firmware, put in the SD card and was transported to this screen.

Success, and truly convinient.

Now it was time to get some printing done.

First attempt didn't look that great. Steps on the printer were 418 even though they were set to 209 in the slicer, so I changed that and the second one extruded better but the PLA still wasn't sticking to the bed. Next, I reduced the first layer speed from 60->45mm/s and increased the bed temp from 60->65C, as well as babystepping from 0.300->0.275 and I had a great first layer. I didn't even have to go though mesh bed levelling.

It seems that I need to reduce the speeds on bridges because it looked pretty wrip-n-torn-up and I reduced the speed to 57% for the next layer so that the error could be mitigated.

Now it seems to be printing well and quiet. As I found out from the DP2, spreadcycle isn't that loud. I still have stealthchop on the 5160 extruder, but I've reduced the current (800->600mA) and microstepping (16->8) from the old firmware. It's a standard motor with a 3:1 reduction, so I don't need the extra torque (not like it matters anyway, after seeing CNC kitchen's various flow rate tests) and it's much quieter than the last time I remember printing on it.

Oh and I have just noticed the crack in the top left. That's unfortunate.