
Copy-paste this on the command-line:
import time w1="/sys/bus/w1/devices/28-000002e34b73/w1_slave" while True: raw = open(w1, "r").read() print "Temperature is "+str(float(raw.split("t=")[-1])/1000)+" degrees" time.sleep(1)
You should see something like this:
Temperature is 32.375 degrees Temperature is 32.437 degrees Temperature is 32.437 degrees Temperature is 32.5 degrees Temperature is 32.562 degrees
And that is how hot it is on a Saturday night on Oslo when the CTO of the company we share office space with insists on having the severs in-house
.
-n.st
Update January 21. 2013: Also, please note that there are two different versions of the Dallas W1 temperature device. One works fine (Marking: 18B20) with the latest Linux W1-gpio driver. The other (Marking: 18B20P) only spits out 85 deg.
Terrific posts. I followed the ds1820 steps. worked great, though I had different w1/devices than yours. Is there a simple tutorial explaining device trees? I’ve tried reading. I couldn’t understand it.
Thanks for sharing your explorations!
Ron
This is the closest thing I’ve come to any structured documentation:
Pingback: การใช้ GPIO ใน Linux ของ BeagleBone Black | BeagleBone Lover in Thailand
Hi Elias,
How do you plan on interfacing the BBB with Replicape to existing 3D printing software suites such as Pronterface and Repetier?
Will the slicer run directly on the BBB/Replicape or does it handle Gcode printing only?
Cheers
GP, nice to hear form you again! Interesting question, right now there is just one queue that takes commands from USB, Ethernet and a local FIFO file and executes them as they come in. That way to send commands in the normal way via a host software or to the printer locally, say from a GUI. The gui would then just pipe the commands to the file. The queue remembers where the command came from and answers appropriately. Obviously there should be a lock when printing so no-one can accidentally send commands..
Eventually the printer will handle slicing as well, yes.
Hmm. So how would you interface that setup with Proterface or Repetier? I would like to build and help test a Replicape with a new Mendel build I am doing, is that possible at this juncture?
Hi Elias, glad to hear your project is moving along nicely.
So with those APIs and when you say “command”, is that a method of interpreting g-code natively? I am trying to figure out how this will work with existing 3D printing suites. Have you considered making those APIs compatible with existing 3D controllers such as the Merlin firmware, so that the BBB/Replicape simply appears as a RAMPS-type controller to facilitate printing from suites such as Pronterface and Repetier?
Yes, replicape will be compatible with repetier, but it will not “be” marlin or teacup. The g-codes it accepts will be the same, in addition to a few new ones such as a command for microstepping, and one for setting the stepper current etc. There might be a compatibility mode though in case there are host softwares that act quirky for some g-codes. I’m about to order a few boards with assembly to cover early adopter demands, so I can get one extra for you if you want!
Yeah pick me up an extra board and let me know what it costs. Ideally the API connection between the Hipsterbot and the BBB/Replicape would be bidirectional as well, so that common configuration settings made with the touchscreen (infill type, stepping rates etc, Slic3r settings etc) could propagate automagically from the Replicape without any need for changing the application itself.
When I run “dtc -O dtb -o BB-W1-00A0.dtbo -b 0 -@ BB-W1-00A0.dts” I receive “dtc: invalid option — ‘@’” any ideas as to fix this.
You need a patched version of dtc to compile for BBB. See I just booted BBB with original Ångström Linux and produced the file using it’s dtc, then used the resulting BB-W1-00A0.dtbo in Debian on BBB.
The patch doesn’t cleanly apply to version 1.4.0 of the device-tree-compiler.
I’ve fixed it and uploaded the new patch, the patched sources, armv7l binaries and.dts and.dtbo files to my website:
I’ve tested it on a BeagleBone Black with Debian 7.2, kernel 3.8.13-bone30, and it works perfectly (unless you count two warnings when compiling dtc).
Had to adjust this based on what was on my system.
“echo BB-W1:00A0 > /sys/devices/bone_capemgr.9/slots”
didn’t work because
“bone_capemgr.9″
is
“bone_capemgr.8″
on my system.
And
“28-000002e34b73″
is
“28-000004df3c7f”
on my system.
Once I’d made those changes, it was off to the races.
Thanx for this.
Question:
“print “Temperature is “+str(float(raw.split(“t=”)[-1])/1000)+” degrees”
reports out Celsius.
Can that be modifed to report out Farenheit? If so, how?
Correct me if I’m wrong. I think this does it:
print “Temperature is “+str((float(raw.split(“t=”)[-1])/1000) * 9.0 / 5.0 + 32.0)+” degrees”
Tweaked from here:
When I try to load the overlay, the beaglebone can’t parse the line:
gpios = ;
Can you explain (or point me to a reference) the meaning of this line?
Thank you VERY much for set of guides. It’s the most useful I have found after hours of googling.
BTW, under Ubuntu 13.04, the w1-slave file is here:
cat /sys/devices/w1_bus_master1/28-000001284447/w1_slave
If you are considering something beyond just a breadboard, like putting temperature monitors all over your house, you will have consider a host a consideration that are introduced when you have long lines and more than one sensor on the wire. A must read:
In theory 1-wire lets you have several sensors on a bus line, but after you read or skim the Wire Design Guide you’ll see there are several restrictions on possible network topologies. The complexity about 1-wire design for anything beyond 10 feet quickly makes it a very expensive deployment — probably have to have intermediary multiplexers, a single line for each sensor, and patch connectors at the multiplexer station.
It almost makes wireless nodes such as Zigbee back in the running simply based on expense. I wish I had studied carefully the network topology gotchas before even thinking about 1-wire of dreaming of a project that would monitors many stations to create a thermal mapping.
According to your script you are using “P9.22″ and “gpio0_2″ and on the picture you are using P8.22.
Can you tell me if this is correct?
ups – diregard, got the wrong pin layout.
This is awsome, thank you Elias, your guide worked well
Btw, is it possible to change the data-pin? For me, the best would be to use an only-gpio pin, like P9.15 (gpio1_16), so i can use uarts for other purposes. At first attempt, I tried to move it to UART4_RXD with following changes in the dts, but had no success, it doesn’t recognises the probes : /
$ diff BB-W1-00A0.dts BB-W1-00A0.dts.orig
“P9.22″,
—
“gpio0_2″;
—
< pinctrl-single,pins = ;
> pinctrl-single,pins = ;
I can’t guess what’s missing, and would appreciate for any help…
Best,
Aron
You need to change both the pinctrl line and the GPIO line in order for it to work. Any pin should be ok.
Oh the diff got formated by the website
Here are the changes again:
“P9.11″ -> “P9.22″
“gpio0_30″ -> “gpio0_2″
“0×070 0×37″ -> “0×150 0×37″
gpios = < &gpio1 30 0>;
Thank you!
In general a great way to read a 1-wire sensor and it worked for me some days. Since 2