Adding support for bus-based temperature sensors

[EDG5000]

Being able to connect many temperatue sensors to Duet3D on a bus would be useful for monitoring, for example inside a heated chamber.

As a bus protocol, Dallas 1-Wire or similar could be used.

An exemplary use case is: connect eight DS18B20 sensors with total cable length of about 3 meters. (optionally using shielded and twisted cabling)

Benefits of bus sensors:

• Simplifies wiring, allows connecting more sensors than would be practical with analog/serial sensors.

Ways of achieving:

• Implement support for a fifth temperature sensor type, "serial temperature sensor". Which allows connecting an arbitrary peripheral which will deal with all the temperature sensors. (such as a cheap ATMega 328P MCU).
• Implement support for 1-Wire directly on RRF. Issues: Timing? Noise? Software complexity?
• Use a sensor that supports daisy chaining using UART (optionally using differential pairs?). An example could be the TI TMP107 sensor.
• Use a daughter board on i2C with an 328P or simmilar to handle the OneWire bus and perform any filtering(?).

I have looked through the code but I have no clue which option would be the easiest. I have read that there would be timing issues to deal with when implementing 1-Wire on RRF. I am not familliar at all with the codebase and with the MCU used. I also heared

If anybody has any thoughts whatsoever, I am eager to hear them.

--

*Offtopic:

I have been building a DIY 3D printer with a heated chamber.

To asses the heating gradient, as well as monitoring heaters and motors, about 8 temperature sensors are used for monitoring, in addition to the 3 used by RepRapFirmware .

Right now I use an 8-bit AVR connected via USB-UART dongle to a machine on the network, which collects the data from RepRapFirmware using HTTP and uses the AVR for the chamber measurements. This allows logging the jobs to a HDD. It does not scale well for multiple printers, due to needing a networked machine or SBC with UART dongle and an AVR for each printer. But must of all, it feels like an ugly solution, and has been giving me nothing but headaches.

This is done for analysis.

Maybe I am just incompetent, but it has been a real pain for the past two years to deal with many temperature sensors.*

[dc42]

@hc3d said in Adding support for bus-based temperature sensors:

Being able to connect many temperatue sensors to Duet3D on a bus would be useful for monitoring, for example inside a heated chamber.
As a bus protocol, Dallas 1-Wire or similar could be used.
An exemplary use case is: connect eight DS18B20 sensors with total cable length of about 3 meters. (optionally using shielded and twisted cabling)

Most bus-based protocols are very sensitive to picking up interference. That includes the Dallas 1-wire protocol and I2C. This can be mitigated by using shielded cable; however that increases the line capacitance, and because bus-based protocols rely on passive pullups, that in turn limits the data rate and/or cable length.

There are two bus-based protocols that have higher resistance to interference: CAN bus and Lin bus. CAN is of course what we use for connecting expansion boards to Duet 3; but it's an expensive option for individual sensors. Lin bus costs much less, although it still requires a transceiver chip or equivalent circuitry. It's much slower (19.2kbps) than CAN (up to ~4Mbps) but fast enough for many sensing applications.

If you want to add a lot of sensors, perhaps including 1-wire protocols, you could consider connecting them to a SAMMYC21 which in turn is connected to the CAN bus. That would allow you to expose them in the object model.

[EDG5000]

@dc42 said in Adding support for bus-based temperature sensors:

you could consider connecting them to a SAMMYC21

Chip45 has been honest about availability to me; the Sammy will be unavailable until at least until dec. 9. (Filastruder may still have stock; I am unsure).

Using sensors on a bus is part of an attempt to write a C++20 Linux daemon running on the same network as multiple RepRapFirmware instances. It would scan for printers (using mDNS?) and automatically record to a database of print jobs, logging frames at 1Hz, recording as much as possible, dumping it all in a PostgresSQL database.

In addition to temperature sensors, a libgphoto2-compatible camera would be connected to the machine on which the daemon is running, taking a snapshot at, say, 0.1Hz.

Implementation has started, with the goal of making it open source.

A Linux SBC/PC is mounted near a Duet-based printer. An AVR board (ATMega 328p-based) is connected to the SBC through USB-UART to handle the temperature bus. A camera is attached over USB to the SBC as well. The SBC uses HTTP over Ethernet to connect to the Duet.

A cleaner solution is on my mind as well, supporting multiple RepRap machines with only a single daemon running anywhere on the local subnet. Using a Sammy for each Duet board would be a more elegant solution, however there are two benefits with going with the above AVR-based approach:

1. Availability of the Sammy is unsure.
2. Connecting a gphoto2-supported camera over USB will require a separate Linux SBC/PC for each printer anyway, voiding the benefits of developing a new solution with the mentioned SAMC21G18A-based solution, as I already have many cheap ATMega328p breakout boards on stock, and have put more hours of development time into my AVR-based solution than I would like to admit. (the AVR-based firmware would be is for release as FOSS as part of the code for the mentioned Linux daemon, assuming it would all reach a usable state.

[rjenkinsgb]

@hc3d said in Adding support for bus-based temperature sensors:

A Linux SBC/PC is mounted near a Duet-based printer. An AVR board (ATMega 328p-based) is connected to the SBC through USB-UART to handle the temperature bus.

If you have a spare serial port (5V or 3.3V UART) on the SBC, that can be used directly for the onewire bus.

It's a common and well-documented technique, no critical timing or software timing involved.

https://www.maximintegrated.com/en/design/technical-documents/tutorials/2/214.html

[o_lampe]

Isn't there a 1-wire header on Duet3 (mini) for NeoPixel support? Could this be used for serious stuff?

[dc42]

@o_lampe using 1-wire for comms with a single transmitting node is straightforward, because the transmitter can use a low impedance output that is resistance to interference. You can't do that when there are multiple transmitting nodes on the wire.

[EDG5000]

@rjenkinsgb That is amazing. It allows total elimination of the AVR altogether.

There is even a well-written library out there, implementing it: https://github.com/dword1511/onewire-over-uart

Offtopic: Learning to write C for an 8-bit AVR in Eclipse, fiddling bitwise with the registers to interact with the peripherals (such as PWM & timers) on the 328P is a bit of a pain for a youngster like me. But for €4 shipped (Arduino Nano-style breakout board), you can't complain.

[achrn]

@hc3d said in Adding support for bus-based temperature sensors:

A Linux SBC/PC is mounted near a Duet-based printer. An AVR board (ATMega 328p-based) is connected to the SBC through USB-UART to handle the temperature bus. A camera is attached over USB to the SBC as well. The SBC uses HTTP over Ethernet to connect to the Duet.

Sorry, I'm late to this discussion.

If you're using a Pi and open to additional hardware, you could use a dedicated 1-wire bus driver, which will not only do the protocol interfacing but also do more clever driving of the 1-wire bus (strong pullup, slew rate control etc.).

DS2482-100 or DS2482-800 are the ones I've used most, they are I2C-to-1-wire and they come on various Pi interface boards. https://www.sheepwalkelectronics.co.uk/product_info.php?cPath=22&products_id=67 is an 8-channel one I've used. https://www.sheepwalkelectronics.co.uk/product_info.php?cPath=22&products_id=73 is the single channel alternative.

There are other Pi boad based around the DS2482 - https://www.abelectronics.co.uk/products/17/raspberry-pi-a-b-2-3 have a couple that look nice that I've never used.

If you go this route, I suggest looking at https://owfs.org/ which mounts the buses as file systems via FUSE, so you just need to read file objects to get the temperatures (etc) e.g. :

achrn@heating:~ $ cd /mnt/1wire/uncached/28.673BBC040000
achrn@heating:/mnt/1wire/uncached/28.673BBC040000 $ ls
address  errata    id          power      r_locator    temperature10  temperature9  tempres
alias    family    latesttemp  r_address  scratchpad   temperature11  temphigh      type
crc8     fasttemp  locator     r_id       temperature  temperature12  templow
achrn@heating:/mnt/1wire/uncached/28.673BBC040000 $ cat type
DS18B20
achrn@heating:/mnt/1wire/uncached/28.673BBC040000 $ cat temperature
57.0625

(That one is on some heating pipework.)

Some caveats - OWFS was apparently long-unmaintained even 8 years ago. There are python modules that are supposed to work but I couldn't get them going, so use only the FUSE mounted filesystem. It has some quirks, like listing all devices twice (most, but not all the time):

achrn@heating:/mnt/1wire/uncached $ ls
28.0677EE020000  28.2155A3040000  28.5F2227050000  28.673BBC040000  28.A576A3040000  28.C449EE020000  simultaneous
28.0677EE020000  28.3057A3040000  28.5F2227050000  28.6D70A3040000  28.A576A3040000  28.E051EE020000  statistics
28.1B9F27050000  28.3057A3040000  28.606DA3040000  28.6D70A3040000  28.B554A3040000  28.E051EE020000  structure
28.1B9F27050000  28.4B46EE020000  28.606DA3040000  28.8C75A3040000  28.B554A3040000  alarm            system
28.1C5EA3040000  28.4B46EE020000  28.6669A3040000  28.8C75A3040000  28.B817BD040000  bus.0
28.1C5EA3040000  28.5E59A3040000  28.6669A3040000  28.A3D7BC040000  28.B817BD040000  bus.1
28.2155A3040000  28.5E59A3040000  28.673BBC040000  28.A3D7BC040000  28.C449EE020000  settings

Actually I cheated up the posting, and when reading device files you don't get a line feed at the end, so it really looks like this (though I rarely read them manually - a script does it outinely and prepares graphs and stuff):

achrn@heating:/mnt/1wire/uncached/28.673BBC040000 $ cat type
DS18B20achrn@heating:/mnt/1wire/uncached/28.673BBC040000 $ cat temperature
54.5achrn@heating:/mnt/1wire/uncached/28.673BBC040000 $

[zapta]

@dc42 said in Adding support for bus-based temperature sensors:

There are two bus-based protocols that have higher resistance to interference: CAN bus and Lin bus

Is RS485 signaling useful here?