Getting my old Logitech Quickcam Pro 4000 to work on Octoprint

 The library that Octoprint uses to connect to a webcam and stream images to the octoprint window is called mjpg-streamer. It works for many webcams, but of course not my trusty Logitech Quickcam Pro 4000. Upon further investigation it turns out my camera only supports the Y12 format but that library can support just the YUV version of that format (there's even a pull request to add support for it). Luckily someone has made their own service called PICS which can read that format and it works pretty well. I forked the project and added some helpful code to allow you to automatically run PICS at boot. Clone the repo, follow the steps to build and run in the Readme, then scroll to the end and follow the steps to "Creating a service to start PICS on boot". This creates a stream that can be viewed at http://octopi.local:8080/dev/video0 which is the URL you can use in the Octoprint WebCam config.

Connecting the Raspberry Pi to the Robin Nano via GPIO pins

Since the Robin Nano board is mounted such that the USB port is only accessible outside the printer, I had to snake the USB cable out through one of the holes and around the printer to reach the port. For a clean installation, I need a way to let the Raspberry Pi connect to the nano using the GPIO pins.

USB port can only be reached from the outside

Currently, however, most of the easily accessible pins are already taken on my board as part of enabling SPI communication on the TMC2209 drivers.

Most easy to access pins are used

So I went hunting for pins that I could use and it turns out most of the pins on the TF connector can at least be used for SPI freeing up the pins on the WIFI connector that are most commonly used for RPI communication. So the plan now is to rewire the 5 SPI wires into a single 9-pin JST-XH connector and then use the WIFI pins for RPI.

Establishing Common Grounds

Before we can hookup I/O pins between separate devices, we need to ensure that they all have a common I/O ground. This is different from grounding the printer (which you should do as well). What I mean is that the negative terminal on the DC side of all the power supplies should be connected together. This ensures that the 24v line from the 24v PSU is actually 24 volts above any of the DC grounds and the 5v line from the 5v PSU is actually 5 volts above the same ground lines. When I had the USB cable connected, there was a ground wire that joined the PSU's together. Although, I could have added a ground wire as part of the wires connecting the RPI with the Robin Nano, its usually better practice to join the PSUs directly to minimize any current going over the ground GPIO pins.

In the end, I connected the GPIO pin14/15 (which are pins for a serial port) on the RPi4 to pins PA10/PA9 on the Robin Nano, respectively. Note that you must cross the wires so that the TX from one boards goes to the RX pin on the other board and vice versa. 

Klipper/RPi Configuration

Next, I had to build a new klipper firmware so that it would know to listen on the correct pins.

I ran through make menuconfig as per the klipper installation instructions being sure to use the same settings described in the top of my printer.cfg regarding booloader size, startup pins, etc. The difference this time, is I picked the serial connection to match the new pins we're using.

After this I: 

1. saved the config
2. ran "make" to build the image
3. used the mks script to convert the image to one compatible with robin nano
4. used Filezilla to get the file onto my computer
5. copied image to sd card
6. booted robin nano with sd card (the image file will get renamed with a *.CUR extension)

Next I had to configure printer.cfg to use the correct serial port. Klipper docs don't document this correctly. They assume you are using USB. Instead of using their command, use "ls /dev/serial*" but at this point the serial ports are not configured correctly. This doc proved helpful: https://docs.google.com/document/d/1kFasg5H_YDpIwc0PZpKph6RTX4BPROkNgTojQ0RWks8/edit

Basically, I first need to configure RPi to disable bluetooth, enable serial ports, disable shell on serial ports. This was done with a combination of editing /boot/config.txt and running raspi-config.

After all was set and done, I had 2 serial interfaces /dev/serial0 and /dev/serial1 with serial1 mapped to /dev/ttyS0 which is the one that corresponds to the GPIO pin 14/15.

Finally, in printer.cfg under the [mcu] section, I set the "serial" to "/dev/ttyS0". Restarted everything and then it all worked.

 

Crashplan Scripts on QNAP

 Looks like QNAP will delete/recreate many directories like /root when it reboots so you can't keep your crashplan scripts there. You can get around this by creating a shared directory. I made one called scripts which can be access by /share/scripts.

I put the update scripts there too so now I can ssh into the QNAP, cd to /share/scripts and run update_crashplan.sh.

Refuting the Chinese Room Argument

This post assumes you already know about the Chinese Room Argument developed by John Searle.

Before I refute it, let's begin with a simple explanation of what the experiment entails:

• A person who understands Chinese writes down a message using Chinese characters and places it into the mail slot of a room. The person cannot observe anything about the room's contents including what is going on inside of it.
• Inside the room is John Searle, he has buckets of Chinese symbols and a book that describes for each combination of Chinese symbols, English instructions on how to arrange the Chinese symbols in the buckets onto a piece of paper which he send back out through the same mail slot. Searle, himself has no understanding of Chinese, he blindly follows the instruction in the book.
• The person outside the room, reads the message from Searle and because it's content and the fact that it is written in Chinese is then convinced that there must be a person who understands Chinese in the room.
• Because Searle never understands Chinese, he is only performing syntactic symbol manipulation. There is no semantics going on. Without semantics there can be no strong AI.

Let me now write the steps of the thought experiment down so it's clear before I make changes to them:

1. Chinese speaker writes down message, places it in mail slot
2. Searle looks at message, thumbs through book to find matching page
3. Searle follows the instructions on the page to form a response
4. Searle places the response back through the mail slot
5. Chinese speaker reads Searle's message and concludes Searle understands Chinese

Now suppose we make a small alteration to the experiment, but in a way that you shall see is immaterial to the experiment itself.

• Suppose that the room has a 2nd mail slot on the back wall that leads to a 2nd room. Just as the Chinese speaker cannot see into Searle's room, Searle cannot see into the 2nd room. Additionally, to the Chinese speaker, the original room and this room are identical (conceptually the original room is divided into 2 rooms internally).
• The book that Searle uses is also different. It still contains all the same Chinese symbols except now, the place where there were English instructions is blank.
• Searle however can now tear out that page from his book and place it into the 2nd mail slot and within a negligible amount of time, the page will be returned through the same slot with the previously missing English instructions. Assume these instructions match the instructions in the original experiment.

So now let's write these new steps down:

1. Chinese speaker writes down message, places it in mail slot
2. Searle looks at message, thumbs through book to find matching page
1. Searle tears out the page and places it into 2nd mail slot
2. The page is returned with the instructions on it
3. Searle puts the page back into his book
3. Searle follows the instructions on the page to form a response
4. Searle places the response back through the mail slot
5. Chinese speaker reads Searle's message and concludes Searle understands Chinese

As you can see, the additional steps we added are inconsequential to the experiment. Whether the page already had the instructions on it or whether Searle performs an extra step using purely syntactical operations to get that instruction, the result is the same. Searle still doesn't understand Chinese, so we must conclude there is no Chinese understanding going on and thus strong AI is false.

But wait! I haven't told you what was in the 2nd room

Inside the 2nd room was a person who understands both Chinese & English. He/she used their understanding of Chinese to formulate a response in Chinese, then used their understanding of English to create the necessary instructions for Searle to construct that response.

So what's the problem?

The Chinese room is an analog for a Turing Machine (aka digital computer). By having Searle in essence "be the computer", the idea is that if Searle never understands Chinese, then all computers for which he is an analog for would never understand Chinese either. The test requires that if Chinese understanding were to exist in the Chinese room, then it must be within Searle. Is that true though? Because, didn't we just show that understanding could definitively be in the Chinese room and entirely separate from Searle?

A test that fails to detect what it's meant to detect, shouldn't be used to infer anything.

Systems Reply?

Some may point to Searle's systems reply as a rebuttal. Namely that Searle could internalize the content of the book (with the instructions). However doing so results in the same conclusion that he made --> Searle doesn't understand Chinese and that's precisely the point. In this case, where we know Chinese understanding exists, we'd want Searle to then understand Chinese (not only that the same understanding of Chinese as the person in the 2nd room).

I don't believe the 2 experiments are truly identical, surely their difference is consequential

Okay, lets have the same person from the 2nd room go through the entire book filling out the instructions, then and only after doing all of them, he places the book in Searle's original room and leaves. The Chinese room starts off indistinguishably from the original. The room, book, people are all the same. The only difference being the author of the book. In the original it's a programmer, in the 2nd it's the person who understands Chinese and English. 

[3D Printer Series] AC powered heated bed and safety

 A normal 24v DC heated bed usually takes a while to come up to temp, especially if you want to print with higher temperature filament. Not only does it take a long time, but it also consumes a lot of the PSU power. That's why if you want to heat up your bed faster, you'll want an AC powered unit.

I purchased this:

Which perfectly fit my new cast aluminum plate and it's mounting holes. Since we can no longer use the Robin Nano controller board to feed this 120V AC and 750 watts is much more than my PSU can handle, I also got a 40amp solid state relay (SSR). You'll want an SSR so that the Robin Nano can still control the heater with a PWM signal. The SSR needs to support a control input of 24V DC and be able to switch 120V AC. For our needs a good quality 10A SSR would suffice but since I don't trust these off brand models I went with a 40A model for extra insurance.

DC to AC 40A SSR

Thermal Runaway

Even good SSRs can fail and the worst way for it to fail is if they fail with the circuit closed (i.e. permanently on) which would mean there's nothing stopping the AC power from flowing to the heater until it catches on fire. 

First line of defence: Thermal Fuse

To prevent this, I added a thermal fuse in series with the wire for the heater power. If the temperature exceeds a certain level, the fuse should blow and the heater should get disconnected. To attach the thermal fuse, I used RTV silicone sealant, which seems to be the adhesive of choice for this task among the Voron crowd. Then to insulate the bottom, I added a self stick foil faced insulated pad used on automobiles. The adds another layer of insurance to keep the thermal fuse in contact with the heater pad.

 

Thermal Fuse

Insulated Pad

RTV Silicone Sealant

2nd Line of defense: Pi controlled relay

Relying just on the thermal fuse might be okay if you plan to continuously monitor your printer but I don't want to monitor my prints so closely. So for an added measure of safety, we want to make sure our heater bed remains disconnected at all times except when the bed is heating. A regular relay can do this for us if we connect the wires leading to the SSR through our relay using the relay's NO (normally open connection). This is nice because we have to actively supply power to the relay to keep the power flowing to the heated bed. The relay I used is the Elegoo 4 relay module. It's nice because the inputs can be isolated from the power used to energize the relay coils.

Elegoo 4 relay module

Why do we need to electrically isolate?

The logic/GPIO pins on the RPi operate at 3.3V but the coils on the relay work on 5V. To make this work we need to separate the relay's logic voltage from the relay's coil voltage. According to the documentation this can be done by removing one of the jumpers:

Remove the jumper to allow mixed voltages

Then you can wire up the module like so. (Note only the top pin under the jumper should be supplied with 5V)

Luckily, the RPi has some 3.3V pins close to some GPIO pins so I chose the first 3 pins since I knew I wanted to control 2 relays, but you can choose the ones that work for you. 

I chose these pins (green), but you do you

For the 5V and ground connections, you can either use the same 5V PSU connections as the RPi or daisy chain it from the header pins (pins 4 & 6).

Configuration

In OctoPrint, I first used the GPIO Control plugin which is good if you want to manually control the relay. The thing to remember is that you need to configure the "Active" dropdown to "LOW" to indicate that activating the relay requires the GPIO pin to be connected to ground (0V). That's usually how these relays work. If you see the relay light come on when you command the pin to be "ON" then it's configured correctly. If the light doesn't come on then you might have a relay that's configured for active "HIGH". If the light works correctly, but the relay itself is opposite, then you've likely wired the output of the relay to the "NC" (normally closed) pin instead of the "NO" (normally open) pin which we want for passive safety. The "GPIO" number should match the label in the pic above.

Active should be set to "LOW" for most relay modules

 Advanced Configuration

Using GPIO Control is relatively straight forward, but you'll have to remember to turn on your heatbed before every print and then turn it off after. I'd rather have Klipper do that for me automatically. Additionally, since Klipper has temperature safety checks, that will shutdown the printer when it detects a temperature abnormality, I want that to also shutdown the relay controlling the heat bed. But how can you get it to trigger a GPIO pin on the RPi? Answer: RPi microcontroller 

You can add the RPi to Klipper as a secondary microcontroller (mcu) and use it's GPIO pins as if it was just another driver board. To do so, follow the instructions in the link above and in the end you should have added something similar to the following lines to the klipper printer.cfg:

[mcu pi]
serial: /tmp/klipper_host_mcu

In my case, I named the RPi mcu as "pi" but you can name it whatever you like, just remember it.

At this point your config doesn't do anything, it just establishes the RPi as something klipper can control. To have it turn on the heated bed when the bed is active we can use the [controller fan] configuration which essentially enables the configured pin when the specified heater is active. Just make sure we keep the speed at 1.0 (ie 100%) since we don't want to pulse the pin on/off. Luckily the default config is just that.

[controller_fan heater_relay]
pin: !pi:gpiochip0/gpio3
heater: heater_bed

Notice that we include a "!" in the pin configuration. That inverts the logic of the pin just like how we set active to "LOW" using GPIO Control. The rest of the pin configuration is explained in the klipper docs.

Now I just start my prints as normal and the heater bed relay turns on automatically, sweet!

[3D Printer Series] Understanding how to set z_offset on Klipper

 Z-Offset is a general name for telling the printer how far the nozzle is from some reference point. The reference point can be either a z end stop or the probe position of a bed probe like a BLTouch. The confusing bit is what happens when you have both an end stop and a probe. In that case you'll want to use the end stop to move the z-axis to a fixed position and then rely on the bed probe only for bed leveling/compensation.

Klipper doesn't explain how the different options interact with each other making this process very confusing. Additionally, following their calibration guide will lead you down the wrong path if you are using a similar configuration as me. Here's how I do it and why:

Offset for z end stop/probe for bed mesh

We will essentially be using the z end stop as our absolute reference, but when we add bed mesh leveling there's an important config that makes our bed mesh work relative to the z end stop, and that is the key. You don't need to do PROBE_CALIBRATE as we never try to use the probed position for absolute positioning.

1. Use the [bed_screws] and [screws_tilt_adjust] configuration to define where the bed level screws are on the xy plane. While you're at it, create an OctoPrint macro/button to move the nozzle above the first screw, this will come handy later.
2. Next, tighten all the bed screws so the nozzle doesn't crash into the bed.
3. Use your macro to move the head above the first screw and home the z-axis.
4. Adjust the first bed screw so that the nozzle is about 1-2 mm above the bed.
5. Use the SCREWS_TILT_CALCULATE command to level the other 3 screws, repeat till you get it pretty close
6. ACCEPT when you are done
7. SAVE_CONFIG
8. Preheat the bed to your normal print temp
9. Run Z_ENDSTOP_CALIBRATE but use a feeler gauge to get a precise gap between the nozzle and bed, then subtract out the thickness of the gauge. We do this instead of the paper test because the bed is now heated and the gauge is an accurate thickness. This is your effective z offset. If you get an out of bounds error, you will need to configure the min z position with a small negative number.
10. ACCEPT when you are done
11. SAVE_CONFIG
12.  Add a [bed_mesh] config, but be sure to include a relative_reference_index that corresponds to the first screw position.
13. Run BED_MESH_CALIBRATE
14. SAVE_CONFIG, if you look at your printer.cfg, see if you can find the bed mesh values at the end. The value for the relative_reference_index should be 0 if you've configured it correctly.
15. Do a single layer test print. I use calipers measure the thickness of the layer. I'll then manually change the [stepper_z] position_endstop to tweak the first layer until I get a thickness that matches the thickness specified in the gcode.

[3D Printer Series] Updating Octoprint/Klipper for Python 3

 After upgrading/resurrecting my Sapphire Plus with a new cast aluminum build plate, 750 AC silicone bed heater, SSR, relay board, magnetic textured PEI build surface, I was prompted to update OctoPrint since it was going to stop supporting Python 3. Unfortunately, if you use OctoPrint w/ Klipper the update steps are a lot more involved than explained.

After you update your Raspberry Pi, you basically have to reinstall Klipper as well and installing Klipper on the Sapphire has a lot of special steps that are unique to the Robin Nano 1.2 board that we use. 

You need to follow the klipper install guide: https://www.klipper3d.org/Installation.html , but during the make menuconfig section you need to match this:

Then the make command failed for me. Previously, when running one of the earlier scripts I got a message that looked more like a warning than a true error: 

 InRelease' changed its 'Suite' value from 'stable' to 'oldstable' N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.

This turned out to be important and you need to run: sudo apt update --allow-releaseinfo-change

Which then allows you to update all the packages. The subsequent errors to make can be resolved by installing the missing packages using apt-get install <package>. 

Once make can run successfully, you still need to run (do not attempt to flash the mcu):

./scripts/update_mks_robin.py ./out/klipper.bin ./out/Robin_nano35.bin

Then you can use something like Filezilla to SFTP the Robin_nano35.bin file to your computer and then onto a microSD card to put in the Robin nano. If the LCD screen never goes blank, you will likely have to repeat the process starting from make, but before you do run:

make clean

If the screen does go blank, it means the update succeeded so you should remove the SD card and restart the MCU

Fixing my Blogger Theme

I figured out why I didn't have the same configuration options in my theme as others. Turns out blogger has a completely customizable theme configuration engine (mind blown). You can define variables and metadata about them in your HTML code and then blogger will scan the code and build a dynamic UI for you to tweak it.

Details are here: https://www.freshtechtips.com/2021/09/blogger-blogspot-template-custom-variables.html

My issue was that there was no way to style the fonts for the different heading types in blog posts:

The lesser headings turned out to be bigger than the major ones. This turned out to be a bad CSS rule, but still its good to be able to change it.

So now my headings look like this:

Major Heading

Heading

Subheading

Minorheading

Paragraph

Normal 

Source code syntax highlighting on Blogger

Making code look nice on blogger is pretty hard. Most of the time we use a fancy IDE with syntax highlighting to write the code, but once we want to talk about it here on blogger, all we can show is mono-space text... yuck! The best thing I've found so far is to add hightlight.js as part of the theme HTML. Then whenever you add HTML in the form of:

<pre><code>YOUR CODE GOES HERE</code></pre>

it will highlight it. However if you have HTML in the code, you will still need to escape it first using something like https://www.freeformatter.com/html-escape.html. Also highlight.js will try to figure out the language that you're code is in, but if you want to force it, you can by adding a class="language-<ALIAS>" attribute to the <code> element. For instance, to do Typescript:

<pre><code class="language-typescript">class MyClass extends SubClass {
  private field;
  constructor() {}
}</code></pre>

And you'd get something like this:

class MyClass extends SubClass {
  private field;
  constructor() {}
}

Configuration

Blogger doesn't allow <link> elements in the post template so we have to edit the whole theme HTML to add the CSS styles. Goto the dashboard and click on "Theme" then click on the down arrow next to "Customize"

Then click on "Edit HTML"

And paste in the following code somewhere in the <head> section of the HTML

<link href='https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@latest/build/styles/stackoverflow-dark.min.css' rel='stylesheet'/>
<script src='https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@latest/build/highlight.min.js'/>
<script>hljs.highlightAll();</script>

Like this:

You can find other themes on the highlight.js site, but make sure you use the CDN path like I did so you will always get the latest version.