Has anyone successfully added a BLTouch on a Mini? I have a mini 1.04, but I also have a spare Einsy Retro board to swap into it.
I’d like to see if others have pulled it off, but if no one has I don’t mind spear heading it.
I doubt the Mini has enough travel for a BLTouch. If you manage to get it to work, you will probably end up with very little usable print area.
I was modeling mounts in Solidworks yesterday and realized there is limited room with the tool head. You can squeeze one in but you won’t be able to hit a few points when leveling. My mini’s have been pretty reliable so I think I’ll leave them alone for now. I do have another project in mind that will give me more use out of my Taz 6. I’ll start another thread for that though.
Depending on the toolhead you’re using, perhaps you can integrate a mount directly into that if you’re comfortable with re-designing parts. The bltouch itself is relatively small cylinder in XY and you can probably remove the top part that flares out with the screw holes. The mount could be something akin to a hoseclamp that grabs it where the golden sticker is…
I dug into this a little more while waiting for parts and the next release to make a dual mosquito head extruder for the Taz 6.
While looking for files in my backedup downloads folder, I found some Marlin 2 code written by @marciot back in 2019. It looks like the last one written was 2.0.0.144
I’m trying to use this or past builds becuase I have a mini Rambo board on both my mini’s. They are both Gladiola’s. Looking over the wiring on the mini rambos it looks like it can run a BLTouch. I want to try and compile a firmware and I have a few questions:
In the configuration.h file do I comment out this line:
#define FIX_MOUNTED_PROBE LULZBOT_FIX_MOUNTED_PROBE
and uncomment this line:
//#define BLTOUCH
After that I think the auto leveling needs to needs to be changed as well? With the mini bed being so small I don’t think it needs a mesh, possibly bilinear…
#define AUTO_BED_LEVELING_LINEAR LULZBOT_AUTO_BED_LEVELING_LINEAR
to this
#define AUTO_BED_LEVELING_LINEAR
In the Conditionals_Lulzbot.h file there is lots with the lulzbot_auto_bed_leveling. This is where I’m lost. I don’t know if disabling fix mounted leveling to bltouch if all this is ignored and I still need to use some of it?
Lastly with pin definitions, this is what is defined:
//
// Limit Switches
//
#define X_MIN_PIN 12
#define X_MAX_PIN 30
#define Y_MIN_PIN 11
#define Y_MAX_PIN 24
#define Z_MIN_PIN 10
#define Z_MAX_PIN 23
//
// Z Probe (when not Z_MIN_PIN)
//
#ifndef Z_MIN_PROBE_PIN
#define Z_MIN_PROBE_PIN 23
#endif
It looks good, but the Antlabs docs also recommends doing this:
#define SERVO0_PIN 22
#define SERVO0_PIN 30 //BLTouch orange wire
Do I need to add this to the if statement or leave it out? I can’t find other files that have a mention of servo pins?
Lastly, I mocked up in CAD a mount for the touch, it looks like barely fits, but the fan duct needs to be redesigned. It looks like I can probe all points on the bed.
@iggy: To be perfectly honest with you, I don’t know. I’ve long since downloaded the knowledge of how to configure Marlin for LulzBot printers into the Python script that generates the various the configuration files for Drunken Octopus. That knowledge is no longer in my brain.
The good news is that, unlike the cruddy old version LulzBot continues to use, my modern script generates human readable Marlin configuration files. Those are provided in the archives that I release on GitHub on this page. If you download, for example, marlin-drunken-octopus-v2.0.x-rc41-complete-for-patreon-supporters.zip, it will have every configuration file for every build. You can look there to get your questions answered.
Thanks Marciot! I noticed everything is not as simple as the source from DO. When I make changes to DO for my Taz 6 it’s so much simpler. Do you think I could make use of the DO mini builds on the mini rambo?
Edit: I didn’t realize you had a build for mini rambo’s!! For some reason I thought it was only Einsy’s, or maybe that was just early builds. I’m going to try and build one with BL touch!
@iggy: Yeah, I’ve had builds for rambos since day one 
Sometimes, however, because of limited memory when enabling things like BLTouch, other features need to be removed. That’s the only difference.
I definitely missed them! I’ve been supporting you for a while now and can’t believe I didn’t see them.
Do you think there’s enough memory on a mini with Rambo, LCD and Finch?
I gave this a shot last night. Went through and compared the config files from a Taz6 with rambo and BLT. I got most of it working but get the following error on compiling.
In file included from Marlin/src/HAL/AVR/../../inc/MarlinConfig.h:49:0,
from Marlin/src/HAL/AVR/MarlinSerial.cpp:39:
Marlin/src/HAL/AVR/../../inc/SanityCheck.h:1539:8: error: #error "NUM_SERVOS is required for a Z servo probe (Z_PROBE_SERVO_NR)."
#error "NUM_SERVOS is required for a Z servo probe (Z_PROBE_SERVO_NR)."
Like you said I’m not sure if this is from not having enough memory or if I didn’t change something. Pin 10 I think is the servo pin for the mini rambo
Success!! I got it to compile. It was so simple too I couldn’t find this:
#define NUM_SERVOS 0
but I changed that to
#define NUM_SERVOS 1
and it complied just fine! Now to test. @marciot if you want my files to see if they are ok, let me know.
1 Like
Well guys I’m hoping to get a little help. I managed to compile it, a few time actually with different configs, and they all uploaded just fine, but none of the axis are moving or homing. The BLTouch deploys and works fine, but nothing is moving or homing.
Ok I did some testing and I don’t think it’s a problem with my compile. I loaded the DO firmware for Gladiola_MiniLCD + Finch_Aerostruder with none of my changes and it does the same thing. Here’s what the console says:
< [12:29:23] Attempting to connect to None
< [12:29:23] Detected 3D printer on /dev/cu.usbmodem14401.
< [12:29:23] Attempting to connect to printer with serial /dev/cu.usbmodem14401 on baud rate 250000
< [12:29:32] Correct response for auto-baudrate detection received.
< [12:29:32] Correct response for auto-baudrate detection received.
< [12:29:32] Correct response for auto-baudrate detection received.
< [12:29:32] Expected that MACHINE_TYPE was LulzBot Mini LCD, but got Mini instead
< [12:29:32] Wrong machine detected.
< [12:29:32] Tried to update EEPROM
< [12:29:32] Printer connection listen thread started for /dev/cu.usbmodem14401
< [12:29:32] Established printer connection on port /dev/cu.usbmodem14401
< [12:29:36] Requesting temperature auto-update
> [12:30:04] G28
< [12:30:36] echo:Homing Failed
< [12:30:36] Error:Printer halted. kill() called!
< [12:30:36] //action:poweroff
< [12:30:40] Requesting temperature auto-update
< [12:30:46] Requesting temperature auto-update
@marciot what do you think?
It says “Homing failed”. Make sure the endstops are functioning with M119.
Edit: I just saw you said the axis aren’t moving. That would certainly cause homing to fail. Did you try restoring to factory settings in the menu?
1 Like
@marciot thanks! I’ll try that. The printer was working with the LB firmware. I just finished printing a fan shroud to clear the probe.
I did noticed the end stop logic was set to 1 where the Taz is 0. Could that be it?
Edit: i’ll try that. I’m also using LB cura to load the firmware after complied in VB. I don’t know if that causes issues.
I don’t know. but you can hold down the endstop and see if it moves.
1 Like
Ok thanks! I just left the machine. Will try again tomorrow.
Also the mini homes Z at max. Is there a way to check the order so that it doesn’t use z min/probe?
@marciot Ok, I checked with M119 and all the endstops work by manually triggering them. I also did a factory reset on it and the axis are still not moving. I loaded the LB firmware and it all works just fine. So I’m stumped why the DO isn’t working right now. I’m just loading the ones you complied right now.
Digging in deeper. rc39 and rc40 work just fine. There are no config files in rc40 so I’m assuming that nothing changed from rc39?
@iggy: Okay, this is good information. I can probably use this to track down what changed between rc40 and the current release.