In the glass: StationHaus, a slightly smoky red lager to benefit local firemen.
The “next time around” board has an unclaimed donation for Red Rock Search & Rescue, to which I might need to add a bit. They got organized initially to find a hasher who’d disappeared out in that part of town…turned out he’d fallen off of Turtlehead Peak. :( On-Ron!
In the glass: Veteran Pale Ale. Behind the bar: Russ Gardner, a homebrewer who I hadn’t run across in years. He said he’s holding down the fort here for a bit while he gets his own beer bar spun up in another month or so.
If I hadn’t stopped at Taco Y Taco earlier, I might also have grabbed a Cuban sandwich from the food truck outside.
First time in over a year, I think…starting at Bad Beat. In the glass: A Healthy Distrust, which in addition to a useful outlook on life in general, is also a blonde coffee ale with vanilla. Like Bad Beat’s previous coffee beers, this one’s not the usual dark hue you might expect. Stops at Astronomy Aleworks and CraftHaus to follow shortly.
…that the Pervert-in-Chief could rock out in German?
I’ve been playing around a bit with ESPHome and Home Assistant lately…started with a couple of Sonoff smart outlets, one to replace a Kill-A-Watt monitoring my mining rig and another to switch a light on at sunset.
What’s up above is part of this weather station kit. The metal can on the small board in the center is a BME280 environmental sensor that picks up temperature, humidity, and barometric pressure and makes that information available over I2C. The NodeMCU on the right reads the sensor, publishes its readings over WiFi to a Home Assistant server, and displays the readings (and current time) on the I2C-connected OLED on the left. You could probably use an ESP-01S with a 4-MB flash upgrade since I2C only needs two pins to work, but the kit came with a NodeMCU, so that’s how I brought it up initially.
Wiring is simple: connect ground together on all three boards, connect the power inputs on the OLED and sensor to a 3.3V pin on the NodeMCU, connect the data pins (SDA) to pin D2, and connect the clock pins (SCK) to pin D1.
The ESPHome config file (not really a program as such) looks something like this:
esphome:
name: bme280
platform: ESP8266
board: nodemcuv2
wifi:
ssid: "your_wifi_ssid"
password: "your_wifi_password"
# Enable logging
logger:
# Enable Home Assistant API
api:
ota:
i2c:
sensor:
- platform: bme280
address: 0x76
temperature:
name: "BME280 Temperature"
id: temp
oversampling: 16x
pressure:
name: "BME280 Pressure"
id: baro
humidity:
name: "BME280 Humidity"
id: humid
update_interval: 60s
display:
- platform: ssd1306_i2c
model: "SH1106 128x64"
lambda: |-
it.strftime(127, 60, id(arial14), TextAlign::BASELINE_RIGHT, "%H:%M", id(esptime).now());
it.printf(0, 0, id(arial14), TextAlign::TOP_LEFT, "%.1f°", id(temp).state*1.8+32.0);
it.printf(0, 20, id(arial14), TextAlign::TOP_LEFT, "%.1f%%", id(humid).state);
it.printf(0, 40, id(arial14), TextAlign::TOP_LEFT, "%.2f\" Hg", id(baro).state*0.0295);
time:
- platform: homeassistant
id: esptime
font:
- file: "/usr/share/fonts/corefonts/arial.ttf"
id: arial14
size: 14
The sensor returns temperature in °C and barometric pressure in hPa; the code above converts those to more sensible units for display. Also, you’ll probably need to update the font file location to whatever is correct for your system. (I have ESPHome installed on Gentoo Linux and have the corefonts package installed.)
Something like this would be useful to have indoors. For an outdoors weather sensor, leave off the screen and the related sections (display, time, and font) from the config file. Next task is to fab up an enclosure of some sort.
This should’ve been easier, but in hindsight it isn’t too bad. The point-and-drool tools provided for managing Bluetooth (at least under KDE) fall flat on their face, but if you enable some supposedly deprecated options and rebuild BlueZ, you’ll get what you need.
I decided to try getting an HC-05 Bluetooth interface working with one of my 3D printers yesterday. bluedevil (the KDE package that manages Bluetooth) apparently knows nothing about RFCOMM devices (which emulate RS-232 connections over Bluetooth). I had gotten both Android and Windows 10 to talk to my printer over Bluetooth without much fuss: pair the device, fire up a suitable application, and connect.
The needed documentation to get RFCOMM devices working on recent Gentoo builds is a bit sparse, so this post aims to correct that.
First, BlueZ needs to be rebuilt with some more USE flags enabled:
echo net-wireless/bluez deprecated extra-tools readline | sudo tee /etc/portage/package.use/bluez && sudo emerge -1v bluez && sudo /etc/init.d/bluetooth restartWith your HC-05 at least powered up, you can retrieve its MAC address, which is needed for the following step:
hcitool scanwhich returns something like this:
Scanning ...
98:D3:32:10:F7:9C HC-05Next, RFCOMM needs to be configured and BlueZ restarted (wherever you see it below, substitute your device’s MAC address for the one used here):
cat <<EOF | sudo tee /etc/bluetooth/rfcomm.conf && sudo /etc/init.d/bluetooth restart
rfcomm {
bind no;
device 98:D3:32:10:F7:9C;
channel 1;
}
EOFNow we can pair the device to the computer:
sudo rfcomm connect hci0 98:D3:32:10:F7:9C 1You should be prompted for the HC-05’s PIN; the default is 1234. (Note: while I’ve gotten this working under KDE, I never get prompted for the PIN when in a pure-CLI environment and the connection is refused.) Key it in, and you should get a notice that you’re now connected:
Connected /dev/rfcomm0 to 98:D3:32:10:F7:9C on channel 1
Press CTRL-C for hangupPress Ctrl-C, then store the PIN for future reference:
for i in /var/lib/bluetooth/[0-9A-F]*; do echo 98:D3:32:10:F7:9C 1234 | sudo tee -a $i/pincodes; doneCreate a boot script to bind /dev/rfcomm0:
cat <<EOF | sudo tee /etc/local.d/01-rfcomm-bind.start && sudo chmod +x /etc/local.d/01-rfcomm-bind.start
#!/usr/bin/env bash
rfcomm bind hci0 98:D3:32:10:F7:9C 1
EOFRun rc-update and verify that both bluetooth and local are both being launched; in my case, both are in the default runlevel. If you reboot now, /dev/rfcomm0 should show up. Use something like minicom to connect, and if your HC-05 is plugged into a printer and the UART interface it’s using is active, you should at least see garbage coming across the line. The HC-05 defaults to 9600 bps, while your printer is probably at 115.2 kbps or faster. The only method I know of to set a different bitrate is to plug it in through an Arduino to bring up the AT-command interface, as described here. It doesn’t seem to support nonstandard speeds like 250 kbps and multiples thereof, and I even had trouble getting 230.4 kbps to work. 115.2 kbps has usually been fast enough to stream gcode without stalling; preprocessing your gcode with something like ArcWelder may help if your printer is running reasonably modern firmware.
In PT100 + MAX31865 + SKR 1.4 Turbo + Marlin: how to get it all working, I got an RTD sensor working on my printer by sharing its SPI bus connection with the Trinamic motor drivers I’m using. What if you’re using “dumb” drivers like the DRV8825 or A4988, or you’re using some of Trinamic’s other drivers (like the TMC2209) that are configured over a UART connection? This post describes how to use the MicroSD-card SPI connection instead.
One disadvantage is that you can’t use a display that runs on the EXP1/EXP2 headers (such as the ReprapDiscount full-graphic display). (You could, but then you’d need to tap into the SPI bus going to the display’s SD-card slot, which is beyond the scope of this post.) I have one of Bigtreetech’s full-color touchscreens on the way; those plug into a designated connector that uses a UART connection. Until then (and probably after), I have an ESP-01S (running ESP3D) plugged into the 8-pin “WiFi” connector and can control the printer through that. The TFT35 went tango-uniform this past weekend. I pressed the ReprapDiscount display back into service, and it works just fine. I’m still using the MicroSD slot on the SKR instead of the display’s SD slot…not much of a difference.
This is largely similar to my previous post, except that you’ll want to make up your cable with female connectors all around. Connections between the MAX31865 board and the SKR Pro 1.4 Turbo are as follows. The SPI connector is near the MicroSD slot; E1-CLS is the closed-loop motor connector for E1 from which we’re drawing 3.3V. The colored boxes overlaid on the board diagram show visually where everything plugs in.
| MAX31865 pin | color | signal | SKR connection type | SKR connection pin |
| 2 | white | GND | female | SPI, pin 6 |
| 3 | black | VDD | female | E1-CLS, pin 2 |
| 4 | brown | SCK | female | SPI, pin 3 |
| 5 | red | SDO | female | SPI, pin 1 |
| 6 | orange | SDI | female | SPI, pin 4 |
| 7 | yellow | CS | female | SPI, pin 5 |
This varies a bit from the software-SPI config. First, the changes to Configuration.h in the thermal-settings section:
#define TEMP_SENSOR_0 -5
#define MAX6675_SS_PIN P0_26
#define MAX31865_SENSOR_OHMS_0 100
#define MAX31865_CALIBRATION_OHMS_0 430
#define MAX31865_USE_60HZ // omit if you're in a 50-Hz part of the world
#define MAX31865_USE_AUTO_MODE
#define MAX31865_USE_READ_ERROR_DETECTION
Make sure SDSUPPORT is enabled:
#define SDSUPPORTMake sure you’re using the zeleps port of the Adafruit driver, and not the original…the original has lengthy delay loops that will slow your printer considerably. Go into ini/features.ini and look for this line:
TEMP_.+_IS_MAX31865 = Adafruit MAX31865 library@~1.1.0Change it to this (all on one line):
TEMP_.+_IS_MAX31865 = AdafruitMAX31865Library=https://github.com/zeleps/Adafruit-MAX31865-V1.1.0-Mod-M/archive/master.zipNext, if you’re using a display plugged into EXP1 and EXP2, you’ll need to disable it. Other features you may have enabled that depend on having a working display may need to be disabled as well. A UART-connected display can be left enabled.
#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER // if it's what you're usingIn Configuration_adv.h, make sure the onboard MicroSD slot is selected instead of a display-connected SD slot:
#define SDCARD_CONNECTION ONBOARDDue to a pullup on the SCK line, we need to use SPI mode 3 instead of mode 0. AFAIK, this doesn’t affect performance; it just changes signaling a little bit. Three changes need to be made to Marlin/src/HAL/LPC1768/HAL_SPI.cpp, which will be presented below as a patch…basically, there are three occurrences of SPI_MODE0 that need to be changed to SPI_MODE3:
diff --git a/Marlin/src/HAL/LPC1768/HAL_SPI.cpp b/Marlin/src/HAL/LPC1768/HAL_SPI.cpp
index 99db15f6e9..ee2bc1fa3d 100644
--- a/Marlin/src/HAL/LPC1768/HAL_SPI.cpp
+++ b/Marlin/src/HAL/LPC1768/HAL_SPI.cpp
@@ -123,7 +123,7 @@
SPI.setModule(2);
#endif
SPI.setDataSize(DATA_SIZE_8BIT);
- SPI.setDataMode(SPI_MODE0);
+ SPI.setDataMode(SPI_MODE3);
SPI.setClock(SPISettings::spiRate2Clock(spiRate));
SPI.begin();
@@ -187,7 +187,7 @@ SPIClass::SPIClass(uint8_t device) {
#if BOARD_NR_SPI >= 1
_settings[0].spi_d = LPC_SSP0;
- _settings[0].dataMode = SPI_MODE0;
+ _settings[0].dataMode = SPI_MODE3;
_settings[0].dataSize = DATA_SIZE_8BIT;
_settings[0].clock = SPI_CLOCK_MAX;
//_settings[0].clockDivider = determine_baud_rate(_settings[0].spi_d, _settings[0].clock);
@@ -195,7 +195,7 @@ SPIClass::SPIClass(uint8_t device) {
#if BOARD_NR_SPI >= 2
_settings[1].spi_d = LPC_SSP1;
- _settings[1].dataMode = SPI_MODE0;
+ _settings[1].dataMode = SPI_MODE3;
_settings[1].dataSize = DATA_SIZE_8BIT;
_settings[1].clock = SPI_CLOCK_MAX;
//_settings[1].clockDivider = determine_baud_rate(_settings[1].spi_d, _settings[1].clock);
If you haven’t previously fixed Adafruit_MAX31865.h (look for it under .pio/libdeps/LPC1769/), find this line near the top: Skip this step, as the zeleps driver includes this fix already:
#if (ARDUINO >= 100)and change ARDUINO to ARDUINOLPC:
#if (ARDUINOLPC >= 100)At first, I had noticed a bit of lag in the printer with the temperature sensor using a soft-SPI connection and thought I’d try switching to a hardware SPI port to see if it’ll lighten the load a bit. It didn’t. It was mainly noticeable in the display and when homing the printer. It didn’t seem to affect print speed or quality when printing from local storage, but streaming a print from something like OctoPrint or Pronterface stumbled pretty badly. What finally fixed this issue was the updated MAX31865 driver.
If you want to use the SD-card slot on the ReprapDiscount display, you might try using the SPI bus on the EXP2 connector instead. This might require driving the MAX31865 board with 5V instead of 3.3V to match the display’s 5V interface. The easiest way to tap into the signals would likely be a 2×5 female insulation-displacement connector on the EXP2 ribbon cable, into which pins can be stuck in the appropriate places. Set SDCARD_CONNECTION to LCD instead of ONBOARD if you go this route.
MOAR PLEASE:
Hundreds of parents showed up to the Vail [AZ?] School Board meeting to demand the board make masks optional. The board didn’t want to hear it so they walked out of the meeting before it even began. So the parents, under Robert’s Rules of Order, voted in a new school board. Then, the new members voted to end the mask requirement in Vail Schools. The old school board members revealed exactly who they are and that includes GOP LD 10 Chairman, Chris King.
The link to Rumble came from a radio station in Tucson, so I’m guessing the “Vail” mentioned above is the one in Arizona, not the one in Colorado. Vail, AZ, is maybe 15 or so miles southeast of Tucson.
I wanted to upgrade one of my 3D printers to make it capable of printing with high-temperature materials. One of the things needed to pull that off is to replace the usual hotend thermistor (which maxes out around 280°C) with either a thermocouple (which can go into the thousands of degrees) or a platinum RTD (which, as packaged for printers, can usually go to 500° or so). Either of these requires additional electronics to make the device compatible; for a PT100 RTD, the device in question is a little board with a MAX31865 on it, which converts the small change in resistance of the RTD to a digital readout over SPI.
There is a guide to getting all this stuff working, but it seems unnecessarily involved while not providing all of your options. What follows is a simpler explanation that will get you up and running.
(I assume that you’re running the bugfix-2.0.x branch of Marlin, and that your printer has a single hotend with a thermistor that you want to replace with an RTD. For my upgrade, I also replaced the aluminum heater block with a nickel-plated copper block. I also have a 60W heater on order, as the 40W heater I’ve been using is having a hard time maintaining temperature with the blower running. Further, I assume that you’re using Trinamic 2130 or 5160 drivers and that you’re using SPI to configure them…we’re going to share that SPI connection. We’ll tap into most of the SPI signals at the E1 connector. If you have a second extruder, you might want to build something like this adapter.)
When the parts arrive, you’ll most likely need to solder connectors onto the MAX31865 board. They should be in the bag with the board; assembly is self-explanatory. There are also a couple of jumper pads that need to be soldered together to put the chip in 2-pin mode.
You’ll also want to make a cable to connect to the SKR 1.4 Turbo. It should have a six-pin female Dupont connector on the MAX31865 end. The SKR end should have six one-pin Dupont connectors: one female (for the CS signal, along one edge of the cable if you’re using ribbon cable) and the rest male. Let’s say you’re using the same color coding that I used, based on the cables I had laying around:
| MAX31865 pin | color | signal | SKR connection type | SKR connection pin |
| 2 | white | GND | male | E1, pin 8 |
| 3 | black | VDD | male | E1, pin 9 |
| 4 | brown | SCK | male | E1, pin 3 |
| 5 | red | SDO | male | E1, pin 5 |
| 6 | orange | SDI | male | E1, pin 2 |
| 7 | yellow | CS | female | PWRDET, pin 3 |
Pins 1 (5V) and 8 (RDY) on the MAX31865 aren’t used, as it and the printer motherboard are both 3.3V devices. A color-coded map of connections to the SKR 1.4 Turbo follows:
The RTD should be connected to the middle two terminals on the side opposite the SPI connector. Mine came with a 2-pin Molex connector, so I just knocked together a little adapter with a Dupont connector and some wire. Take note that the 6-pin connector is centered on the board’s 8-pin connector.
With the hardware sorted, we now turn to configuring Marlin. Most of the changes can go in the thermal-settings section of Configuration.h.
#define TEMP_SENSOR_0 -5
#define MAX31865_MOSI_PIN TMC_SW_MOSI
#define MAX31865_MISO_PIN TMC_SW_MISO
#define MAX31865_SCK_PIN TMC_SW_SCK
#define MAX6675_SS_PIN POWER_LOSS_PIN // MAX31865_CS_PIN is copied from this
#define MAX31865_SENSOR_OHMS_0 100
#define MAX31865_CALIBRATION_OHMS_0 430
#define MAX31865_USE_60HZ // omit this if you're in a 50-Hz part of the world
#define MAX31865_USE_AUTO_MODE
#define MAX31865_USE_READ_ERROR_DETECTION
Trinamic drivers on the SKR 1.4 Turbo use software SPI, so that’s what we end up selecting here. MOSI (SDI), MISO (SDO), and SCK pins are set to the same ones the Trinamic drivers use, while the CS pin is set to a pin that we’re not using so we can still install a second extruder in the future. Any pin that doesn’t have a pullup or pulldown is OK…I’m using the pin on the PWRDET connector.
To use hardware SPI, the MAX31865_*_PIN entries don’t need to be defined. Just define MAX6675_SS_PIN, which is copied internally to MAX31865_CS_PIN. From what I’ve read, if there are multiple hardware SPI buses, the driver will default to using one of them and there’s no way to choose the other. I haven’t had a chance to verify this behavior.
If you’re using a PT1000 instead of a PT100, the MAX31865_*_OHMS values both need to be multiplied by 10 and you need to replace the Rref resistor on the MAX31865 board with a 4.3kΩ part (stock is a 430Ω 0.1% 0805 SMD resistor).
There’s also a change needed in Adafruit_MAX31865.h (in my source tree, it’s in .pio/libdeps/LPC1769/Adafruit MAX31865 library). Line 49 (or thereabouts) looks like this:
#if (ARDUINO >= 100)
ARDUINO isn’t defined by the LPC176x Arduino framework; instead, it needs to look at ARDUINOLPC:
#if (ARDUINOLPC >= 100)
Without this change, you’ll get compile errors saying that WProgram.h can’t be found.
Instead of the above, there’s an updated driver for the MAX31865 that also fixes some serious performance issues with the original. Go into ini/features.ini and look for this line:
TEMP_.+_IS_MAX31865 = Adafruit MAX31865 library@~1.1.0Change it to this (all on one line):
TEMP_.+_IS_MAX31865 = AdafruitMAX31865Library=https://github.com/zeleps/Adafruit-MAX31865-V1.1.0-Mod-M/archive/master.zipWith these changes made, compile, write the firmware.bin file that’s produced to a MicroSD card, pop it into the slot on the SKR, and hit Reset (or power it up).
I’ve noticed that the Marlin UI (on one of the cheap 128×64 graphical LCDs) is a bit laggy, but the printer is otherwise running properly. Switching from the software SPI used for Trinamic drivers to one of the hardware SPI channels might fix that. If I’m not mistaken, there are two: one is brought out on the EXP2 connector for cheap 128×64 graphical LCDs like mine (to go to the SD-card slot on such devices), and another goes to the onboard MicroSD slot and is also available on an SPI header adjacent to that slot. Changing MAX31865_MOSI_PIN, MAX31865_MISO_PIN, and MAX31865_SCK_PIN to use those other channels ought to do the trick (and leave out MAX31865_USES_SW_SPI if you do that).
Display lag and other issues were the result of lengthy delays hardcoded in the Adafruit driver. The zeleps fork of that driver appears so far to have fixed that problem. I currently have the MAX31865 board sharing hardware SPI with the onboard MicroSD slot, but sharing it with the display or with Trinamic drivers should work as well, whether with hardware or software SPI.
I’ve also given some thought to trying ReprapFirmware, now that you don’t need to fork over the big bucks for a Duet to run it. How this setup would cooperate with that, I don’t know.