With the new mount in, I needed to upload new firmware - even though slic3r can take a Z offset, it seems the heating position doesn't take that into account and just goes to Z min, which is now about 7 mm below the plate.
Unfortunately, new security software on my laptop blocked some of the sub-programs used by Arduino, so I figured it was time to switch to the Raspberry Pi I got for the same purpose. Hook up a monitor, a (German) kezboard, and a mouse (I am still amazed that you can plug in random things in USB and they just work and know what they're supposed to do), and up and running.
Except not quite. The Arduino in rpi is rather old, so I decided to try a new one with proper board management and all, compiled from scratch. Took a while to install all the dependencies and everything, but I got it. Except... the Marlin firmware isn't compatible with Arduino 1.5+ :( So back to the old one (with an interregnum of a Chromium update making it fail and requiring a kernel update, and various crashes when I asked too much of my little Pi).
I did update to a newer version of Marlin, though getting that to compile right was tricky. I don't have the Melzi definition installed and remember installing it as a frustrating task, but some sites say Sanguino works as well - and it does! (Specifically ATMega1284p 16MHz). I set the Z_MAX_POS to 200 but allow it to go to -1, in case the frame expands. The Z axis is exceedingly slow, though, until I changed the steps to 200.0*16/1.25 - that's what I had before, I'm honestly not sure where the calculation comes from. I might be able to speed it up... nope, that caused a crash! I'll keep it low.
The bed height when manually calibrated turned out to be 1.1mm above 0, a bit higher than I hoped for, so let's reduce the height to 199mm.
The newer firmware version seems in particular to have better autolevelling support, which I want to include soon. Also, it connects immediately rather than after about 5 seconds, which is nice.
I also need to recompile Slic3r, of course. And somehow it seems every app involved uses a separate set of languages and libraries, so each time I install something 20+ other things get installed. Sigh. But the strangest thing will have to be this requirement for Slic3r:
$ sudo apt-get install libopengl-perl
The following packages will be REMOVED:
cura gstreamer1.0-plugins-bad libalien-wxwidgets-perl libgl1-mesa-dev
libgl1-mesa-glx libglew1.10 libgltf-0.0-0 libglu1-mesa-dev libgtkglext1
libopencv-calib3d2.4 libopencv-contrib2.4 libopencv-core2.4
libopencv-features2d2.4 libopencv-flann2.4 libopencv-highgui2.4
libopencv-imgproc2.4 libopencv-legacy2.4 libopencv-ml2.4
libopencv-objdetect2.4 libopencv-video2.4 libreoffice
libreoffice-avmedia-backend-gstreamer libreoffice-base libreoffice-base-core
libreoffice-base-drivers libreoffice-calc libreoffice-core libreoffice-draw
libreoffice-gtk libreoffice-impress libreoffice-math
libreoffice-report-builder-bin libreoffice-sdbc-hsqldb libreoffice-writer
libvisual-0.4-plugins libwx-perl libwxgtk-media3.0-0 libwxgtk-media3.0-dev
libwxgtk2.8-0 libwxgtk2.8-dev libwxgtk3.0-0 libwxgtk3.0-dev openjdk-8-jdk
openjdk-8-jre python-opengl python-pyglet python-wxgtk3.0 python3-uno
raspberrypi-ui-mods vdpau-va-driver xserver-xorg xserver-xorg-core
xserver-xorg-input-all xserver-xorg-input-evdev xserver-xorg-input-synaptics
I was not done with those! In fact, I just specifically installed libwx-perl to make Slic3r happy. I'm sure stuff is going to break stuff. And it doesn't make Slic3r run, it wants both wx and opengl, but those two cannot live together. What's with that?
Huh. Despite setting the height to 199mm, it still hits the bed at 1mm Z height. Maybe that's because I didn't actually change it.
It seems sometimes the Z movement is a lot slower than normal. It would be nice if Pronterface had a display of what it thinks the state of the world is - where the axes are and how fast they're moving.
Truly, language-specific package managers are a pain, a pestilence, and a pox upon the Linux world. To get slic3r to run, I've been led a merry chase between installing Debian packages, installing CPAN packages, installing Debian packages because installing the CPAN package failed without it, running slic3r again to find another package is needed, etc etc. Only to get to where slic3r runs for two seconds and then segfaults.
This is probably caused by https://github.com/alexrj/Slic3r/issues/3540, and can be cured in the same way by not having the plater. I only occasionally use the plater, so that's ok.
Since I don't feel like digging up the standard (if any standard exists) way to install a Perl program, I'm just pointing at the build dir for now, so my slicer command is /home/pi/src/Slic3r-1.2.9/slic3r.pl --gui --no-plater $s --output $o --load "/home/pi/3DPrint/Slic3r/filament/Simple Mode.ini" --load "/home/pi/3DPrint/Slic3r/printer/Simple Mode.ini" --load "/home/pi/3DPrint/Slic3r/print/Simple Mode.ini". Slic3r is a rather quirky program, all told.
An unfortunate side-effect of switching to a Linux system is that I can't use Google Drive as my shared filesystem any more. But I can mount my home directory from my main machine, which in turn contains a Google Drive mount. Using afpfs, that was pretty simple, except Slic3r without a plater doesn't automatically slice like it used to, so I have to "Quick Slice and Save As" until I find the right commands. Update: No, I just needed to remove the -gui argument.
Trying to print - and no heat. I probably missed a thermistor setting. Or not - the hotend thermistor is definitely the right setting, and setting the bed to something that looks sensible (some numbers have changed) gave wonky results. Trying again, they both heated.
Now I got it to print (with a cold bed), but oddly the print was done a full centimeter above the bed! The new firmware is nice, though, that it heats the bed and extruder while homing. Much time saved. The print is absolutely 9.95mm above the bed, desipte the settings saying Z offset of 0. Odd.
by Lars Clausen (email@example.com) at January 15, 2017 09:36 PM