A new MachineKit image is now available. While there are no dramatic changes with this release, pretty much everything got updated. There's a new kernel (-bone33), the latest Debian (7.3), and continued updates to LinuxCNC. One somewhat major change is switching from the xdm display manager to lightdm, which plays nice with consolekit so the shutdown/reboot buttons work, user-mode USB mounting works, etc.
There's no dramatic reason to update if your current system is working well. This is primarily a baseline build I wanted to make available before I head off and start seriously working with the joints-axis code on the BeagleBone for controlling the non-Cartesian 3D printers I'm building (a Mini-Kossel-Pro mashup, and Nicholas Stewart's Wally and GUS Simpson).
Sunday, December 29, 2013
Monday, December 2, 2013
New BeagleBone Cape Available
Alex Joni has finished up his bbb_parport cape and has them available for sale!
This cape provides support for up to 6 axis, and has an optional ADC for analog inputs. There is a DB25 connector that should allow direct connection of an existing LPT based CNC machine to a BeagleBone. If you're more interested in cutting metal than printing with plastic, this is the cape for you!
Great work, Alex!
This cape provides support for up to 6 axis, and has an optional ADC for analog inputs. There is a DB25 connector that should allow direct connection of an existing LPT based CNC machine to a BeagleBone. If you're more interested in cutting metal than printing with plastic, this is the cape for you!
Great work, Alex!
Tuesday, November 5, 2013
BeBoPr-Bridge Purchase Page
To make it even easier to purchase a BeBoPr-Bridge board set, I have added a purchase page complete with nifty PayPal "add-to-cart" buttons.
I have stock levels linked to the buttons, so if PayPal lets you send me money, I have the PCBs and connectors in-hand and ready to ship to you (saving weeks vs. ordering direct from OSH Park).
I also have another BeBoPr and BeagleBone Black coming, so I'll be putting together my second Bridge board set soon and I promise this time I'll take lots of pictures and put up some assembly instructions. When I built the first Bridge board I didn't realize I would eventually be selling them! :)
I have stock levels linked to the buttons, so if PayPal lets you send me money, I have the PCBs and connectors in-hand and ready to ship to you (saving weeks vs. ordering direct from OSH Park).
I also have another BeBoPr and BeagleBone Black coming, so I'll be putting together my second Bridge board set soon and I promise this time I'll take lots of pictures and put up some assembly instructions. When I built the first Bridge board I didn't realize I would eventually be selling them! :)
Monday, October 21, 2013
Configuring Multiple Home Switches on LCNC
Back in July, I showed how to configure a home switch with a BeBoPr board. That blog post is a bit out of date now, as Charles has integrated many of the needed changes (including additions to the device tree config and setup.sh) into the main MachineKit branch. Nice!
Still, you need to modify the default configuration a bit, and that post only showed how to set up a single axis. This post will show how to configure multiple home switches in a few ways:
- Axis-at-a-time: press the home key for each axis. Common on machine tools; homing each axis separately avoids crashing a milling head into a vise or workpiece.
- Sequential: each axis moves until it presses a home switch, in turn. Common with 3D printers; the Z axis is typically homed last, so that the hotend doesn't scratch up the print surface.
- Combined: all axes moves simultaneously, until each one hits the switch. Necessary with delta robot 3D printers, where moving just one axis might smash the head into one of the tower.
You can follow the full explanation, or just skip to the bottom section and pull in the config changes for combined homing.
Saturday, October 19, 2013
Hung Task Bug in Xenomai Kernel
Thanks to Ralf Roesch, some glitches I had been writing off to bad SD cards have been shown to be a significant bug in the Xenomai patched kernel for the BeagleBone. The symptom is the kernel hangs and prints a message similar to the following:
To 'tickle' this bug, all you have to do is boot, get to a console prompt, and run:
There's a thread over on the Xenomai list about this issue, and it looks like it's a problem with the interrupt code for the am335x MMC or DMA driver (the MMC code makes heavy use of DMA). I'm not sure how long it will take to track down this bug, or if I'll be able to recruit any help from TI or elsewhere.
NOTE: You can still use LinuxCNC on the BeagleBone, as this issue doesn't really show up that often (I've done overnight prints and had systems run fine for a couple weeks straight), but it is definitely something that needs to get fixed.
UPDATE: I initially figured this was probably an issue with the TI code for the AM335x mmc controller, but it looks like it could possibly be an actual kernel bug based on the following very similar issue:
[26160.894920] INFO: task mmcqd/0:74 blocked for more than 60 seconds. [26160.901577] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [26160.909811] mmcqd/0 D c0699e08 0 74 2 0x00000000 [26160.916607] [] (__schedule+0x5b8/0x774) from [ ] (schedule_timeout+0x1c/0x21c) [26160.925943] [ ] (schedule_timeout+0x1c/0x21c) from [ ] (wait_for_common+0x130/0x170) [26160.935718] [ ] (wait_for_common+0x130/0x170) from [ ] (mmc_wait_for_req_done+0x1c/0x74) [26160.945851] [ ] (mmc_wait_for_req_done+0x1c/0x74) from [ ] (mmc_start_req+0x50/0x158) [26160.955712] [ ] (mmc_start_req+0x50/0x158) from [ ] (mmc_blk_issue_rw_rq+0xa4/0x348) [26160.965485] [ ] (mmc_blk_issue_rw_rq+0xa4/0x348) from [ ] (mmc_blk_issue_rq+0x3fc/0x450) [26160.975624] [ ] (mmc_blk_issue_rq+0x3fc/0x450) from [ ] (mmc_queue_thread+0xa0/0x104) [26160.985481] [ ] (mmc_queue_thread+0xa0/0x104) from [ ] (kthread+0xa0/0xb0) [26160.994345] [ ] (kthread+0xa0/0xb0) from [ ] (ret_from_fork+0x18/0x38) [26161.002875] Kernel panic - not syncing: hung_task: blocked tasks [26161.009184] [ ] (unwind_backtrace+0x0/0xe0) from [ ] (panic+0x84/0x1e0) [26161.017756] [ ] (panic+0x84/0x1e0) from [ ] (watchdog+0x1d4/0x234) [26161.025866] [ ] (watchdog+0x1d4/0x234) from [ ] (kthread+0xa0/0xb0) [26161.034065] [ ] (kthread+0xa0/0xb0) from [ ] (ret_from_fork+0x18/0x38) [26161.042529] drm_kms_helper: panic occurred, switching back to text console
To 'tickle' this bug, all you have to do is boot, get to a console prompt, and run:
grep TestConfig /usr -r
There's a thread over on the Xenomai list about this issue, and it looks like it's a problem with the interrupt code for the am335x MMC or DMA driver (the MMC code makes heavy use of DMA). I'm not sure how long it will take to track down this bug, or if I'll be able to recruit any help from TI or elsewhere.
NOTE: You can still use LinuxCNC on the BeagleBone, as this issue doesn't really show up that often (I've done overnight prints and had systems run fine for a couple weeks straight), but it is definitely something that needs to get fixed.
UPDATE: I initially figured this was probably an issue with the TI code for the AM335x mmc controller, but it looks like it could possibly be an actual kernel bug based on the following very similar issue:
- MMC locking: mmc_request accesses from dw_mmc driver ok?
- [PATCH 0/7] mmc: core: cleanup and locking patches description
Sunday, October 13, 2013
BeagleBoard 3D Printer and CNC Capes
The BeagleBone is rapidly becoming a key player in the CNC and (I hope) 3D Printing space. Don't believe me? Just check out the list of 3D, CNC, and motion control capes I threw together. It turned out to be a *LOT* longer than expected! Even better, most of these will work out-of-the-box with my existing MachineKit version of LinuxCNC. Support for the Replicape will need some programming (it requires working I2C and SPI for proper operation, not just twiddling I/O pins), which will probably happen as soon as I can either buy a board or someone sends me one (hint-hint).
If I missed anything, you notice any goofs, or if you have more details on any of the boards (including YouTube "Action Videos" or similar!) please let me know.
If I missed anything, you notice any goofs, or if you have more details on any of the boards (including YouTube "Action Videos" or similar!) please let me know.
Thursday, October 10, 2013
Bridge Boards Arrive!
Look what came in the mail:
After a long wait (which was sort of the point of ordering boards to have available for sale in the first place), 4-and-10 BeBoPr Bridge board sets finally arrived in the mail!
For those of you who have sent me money, I will be mailing your boards out tomorrow (Friday, Oct. 11). If you are interested in purchasing a set, let me know. Prices are in my previous post, and are quite reasonable (you actually save both money and time!).
Now buy some from me so I don't regret deciding to sell them at cost! :-)
Tuesday, October 1, 2013
BeBoPr Support Forums
Bas, creator of the BeBoPr board, has a new support forum for the BeBoPr boards online. Hopefully this will become a great resource for anyone using a BeBoPr board with the BeagleBone. Note that I generally prefer e-mail lists over forums, so while I intend to monitor the BeBoPr forums, don't hesitate to "nudge" me (forum username: cdsteinkuehler) via direct message if there's something you think I missed.
Also remember to monitor the BeBoPr wiki pages which have lots of details that haven't made it to the forums yet.
Finally, if you're interested in using a BeBoPr with a BeagleBone Black, I should soon have stock of a quantity of the Bridge Boards (which let you use the HDMI interface to run stand-alone) if you don't want to order 3 (or more) direct from OSH Park or mill them yourself, or you can get the BeBoPr+ boards (with the Bridge included) direct from Bas.
Also remember to monitor the BeBoPr wiki pages which have lots of details that haven't made it to the forums yet.
Finally, if you're interested in using a BeBoPr with a BeagleBone Black, I should soon have stock of a quantity of the Bridge Boards (which let you use the HDMI interface to run stand-alone) if you don't want to order 3 (or more) direct from OSH Park or mill them yourself, or you can get the BeBoPr+ boards (with the Bridge included) direct from Bas.
Monday, September 23, 2013
Another Success
Alexander Rössler and Michael Haberler have gotten Alexander's MendelMax 3D printer working with LinuxCNC running on the BeagleBone. This conversion has extra significance because Michael is presenting a paper at the upcoming OSADL Real Time Linux Workshop. Michael will be covering the changes made to LinuxCNC to allow it to run on a variety of real-time operating systems, and Alexander's very nice looking MendelMax will be providing a great bit of real-world show and tell!
If you can manage to be in Lugano-Manno, Switzerland around the end of October, you should register and attend!
And remember to send me details and pictures or video of your machine if you have something controlled by LinuxCNC on the BeagleBone!
Thursday, September 19, 2013
BeagleBone RAMPS Interface
For a long time now, I have wanted an interface to connect a BeagleBone to a RAMPS board to control a 3D printer. Wouldn't you know, all I had to do was seriously start work on designing one, and a finished project would magically appear on Hack-a-Day:
This looks like a great board, and I hope to get one in soon for testing. The pinout looks to match the BeBoPr-Bridge setup, which means you should be able to run LinuxCNC from my MachineKit image straight "out-of-the-box".
One potential issue is the thermistors. The BeBoPr has a different resistor network arrangement than most 3D printer shields/capes (an actual network, vs. a simple pull-up resistor). It is reasonably easy to compensate for this in the temperature reading python code, but if you used this board without tweaking the temperature code, your temperatures would be precise but not be very accurate.
If you have one of these capes or are otherwise using LinuxCNC on the BeagleBone, please let me know.
This looks like a great board, and I hope to get one in soon for testing. The pinout looks to match the BeBoPr-Bridge setup, which means you should be able to run LinuxCNC from my MachineKit image straight "out-of-the-box".
One potential issue is the thermistors. The BeBoPr has a different resistor network arrangement than most 3D printer shields/capes (an actual network, vs. a simple pull-up resistor). It is reasonably easy to compensate for this in the temperature reading python code, but if you used this board without tweaking the temperature code, your temperatures would be precise but not be very accurate.
If you have one of these capes or are otherwise using LinuxCNC on the BeagleBone, please let me know.
Sunday, September 15, 2013
Making chips with MachineKit
While I continue to work on building my linear delta 3D printer, John Prentice has hooked up a BeagleBone running the MachineKit LinuxCNC image to a mill and is making sawdust! It's nice to see someone else actually moving motors and even better to see John actually making chips on a real mill!
John's mill has a standard parallel port step/dir interface, which he hooked to the BeagleBoard using a prototype cape. You can see the Axis gui interface and the BeagleBone with cape starting around the 3:00 minute mark in the above video. If you look closely at the cape, you can see some LS series logic chips to handle voltage conversion from the 3.3V BeagleBone GPIO levels. While perhaps not strictly necessary (most PC motherboard parallel ports have had 3.3V levels for at least a decade), it's never a bad idea to have some protection between a chunk of silicon BGA with sub-micron features and a milling machine with lots of (electrically) noisy motors and long cable runs.
Kudos to John, and extra credit for making a video and sending me the link! If you've got a BeagleBone driving actual hardware (3D printer, lathe, mill, or whatever), send me details along with some pics or a video so I can post some more success stories!
Tuesday, September 10, 2013
BeBoPr Bridge Boards Available
In an effort to help promote the use of LinuxCNC on the BeagleBone Black, I am having a medium run of the bridge boards fabricated by OSH Park. You can order these boards directly from OSH Park if desired, but it's about $20 for a set of three boards, with a 2-3 week turn time. I will try to keep boards on-hand, so I can ship from stock, and I will try to have connectors available so you can buy them at the same time and save on shipping.
Send me a direct e-mail if you'd like to buy a board set. Pricing is as follows:
Hint: If you need a short piece of ribbon cable, you ought to be able to dig up an old floppy-disk or standard IDE cable that isn't being used and cut a chunk out of that.
Each package comes with one set of BeBoPr Bridge circuit boards, crafted from Bas Laarhoven's BBR_R1 design which is available from OSH Park.
If you buy the connectors as well, they are from Major League:
This is intended for folks in the US, buying the original BeBoPr board from the CircuitCo BoardZoo webstite. If you are in Europe, you should contact Bas Laarhoven directly. He is selling the BeBoPr+ with the bridge board functionality already built-in. If you are interested in purchasing boards for delivery outside the US, please contact me with details and I will figure out shipping costs.
NOTE: The OSH Park panels just went to fab today (Sept. 10, 2013), so I expect to have boards available in about 2 weeks (around Sept. 24, give or take).
UPDATE: The connectors arrived today (Sept. 19, 2013), and I hope to receive the circuit boards sometime next week.
UPDATE: The PCBs finally arrived (Oct. 10, 2013), so I now have stock of both boards and connectors. If you have already paid, your order will ship out tomorrow (Oct. 11). If you are reading this post at some later point in time, I probably have boards and connectors available for immediate shipment, just drop me an e-mail and let me know what you're interested in.
Send me a direct e-mail if you'd like to buy a board set. Pricing is as follows:
- $8 BeBoPr Bridge PCB ONLY via 1st class mail. You provide connectors!
- $15 BeBoPr Bridge PCB with 2 header and 2 socket connectors via 1st class mail.
- $20 BeBoPr Bridge PCB with 2 header and 2 socket connectors via Priority Mail.
Hint: If you need a short piece of ribbon cable, you ought to be able to dig up an old floppy-disk or standard IDE cable that isn't being used and cut a chunk out of that.
What do I get?
Each package comes with one set of BeBoPr Bridge circuit boards, crafted from Bas Laarhoven's BBR_R1 design which is available from OSH Park.
If you buy the connectors as well, they are from Major League:
- Sockets: SSHQ-123-D-06-GT-LF
- Headers: TSHC-123-D-06-240-GT-LF
This is intended for folks in the US, buying the original BeBoPr board from the CircuitCo BoardZoo webstite. If you are in Europe, you should contact Bas Laarhoven directly. He is selling the BeBoPr+ with the bridge board functionality already built-in. If you are interested in purchasing boards for delivery outside the US, please contact me with details and I will figure out shipping costs.
NOTE: The OSH Park panels just went to fab today (Sept. 10, 2013), so I expect to have boards available in about 2 weeks (around Sept. 24, give or take).
UPDATE: The connectors arrived today (Sept. 19, 2013), and I hope to receive the circuit boards sometime next week.
UPDATE: The PCBs finally arrived (Oct. 10, 2013), so I now have stock of both boards and connectors. If you have already paid, your order will ship out tomorrow (Oct. 11). If you are reading this post at some later point in time, I probably have boards and connectors available for immediate shipment, just drop me an e-mail and let me know what you're interested in.
Monday, September 2, 2013
New MachineKit Image Available
I am pleased to announce that a new MachineKit image for running LinuxCNC on the BeagleBone is now available! This image took a while to put together and there are a lot of things that changed:
This is the latest BeagleBone kernel available via RCN's kernel build scripts (it is identical to the just committed -bone27 kernel except for the version ID of 26.1). There are lots of updates to this kernel so HDMI and USB should hopefully work a lot better.
I have forked RCN's kernel build scripts and and added the ability to pull in the Xenomai patches directly from the Xenomai git repository. The provided kernel was built with the absolute latest available version of the arm Xenomai code, which is soon to become the next Xenomai stable release (waiting mostly for updates to stabilize 3.10). This means you can now build the Xenomai patched kernel used in the MachineKit image completely from the latest source pulled directly from git using a few simple commands.
This is the really big change. The LinuxCNC folks are working towards a 2.6 release, which is slated to include something called the "unified build". No, not that one! :) This unified build allows the same LinuxCNC binary code to run on top of different RTOS systems using a DLL layer to hide the gory details of interfacing to Xenomai, RTAI, RT_PREEMPT, or plain old Posix threads.
The current MachineKit branch of LinuxCNC is based on the 2.5 LinuxCNC code-base, and it is virtually impossible (with a reasonable amount of effort) to merge the unified build code into LinuxCNC 2.5.
Not to worry, the hard work has been done already, mostly by John Morris and Michael Haberler (THANKS!!), but the change does mean there is no easy "fast-forward" merge and the git setup is now fundamentally different. The alternate Xenomai RTOS work the MachineKit branch has been built on was happening outside the official LinuxCNC repository on a private git server run by Michael Haberler. The new unified build code is slated for inclusion into LinuxCNC 2.6, and can be found in the official LinuxCNC git repository. The official repo is also available on github, where I have cloned it and added a MachineKit-ubc branch. This branch will track the unified build branch (and the LinuxCNC 2.6 branch as it comes together) but make sure the code builds and runs on the BeagleBone. There may also be a few configuration changes specific to the arm or BeagleBone platform.
I will be keeping the MachineKit and MachineKit-ubc branches in my previous github repository up to date for a while, but these should generally be considered deprecated. If you are not using my pre-built images, please switch to using the new linuxcnc repo as soon as you can.
Kernel version -bone26.1
This is the latest BeagleBone kernel available via RCN's kernel build scripts (it is identical to the just committed -bone27 kernel except for the version ID of 26.1). There are lots of updates to this kernel so HDMI and USB should hopefully work a lot better.
Xenomai Updates
I have forked RCN's kernel build scripts and and added the ability to pull in the Xenomai patches directly from the Xenomai git repository. The provided kernel was built with the absolute latest available version of the arm Xenomai code, which is soon to become the next Xenomai stable release (waiting mostly for updates to stabilize 3.10). This means you can now build the Xenomai patched kernel used in the MachineKit image completely from the latest source pulled directly from git using a few simple commands.
LinuxCNC Unified Build Candidate
This is the really big change. The LinuxCNC folks are working towards a 2.6 release, which is slated to include something called the "unified build". No, not that one! :) This unified build allows the same LinuxCNC binary code to run on top of different RTOS systems using a DLL layer to hide the gory details of interfacing to Xenomai, RTAI, RT_PREEMPT, or plain old Posix threads.
The current MachineKit branch of LinuxCNC is based on the 2.5 LinuxCNC code-base, and it is virtually impossible (with a reasonable amount of effort) to merge the unified build code into LinuxCNC 2.5.
Not to worry, the hard work has been done already, mostly by John Morris and Michael Haberler (THANKS!!), but the change does mean there is no easy "fast-forward" merge and the git setup is now fundamentally different. The alternate Xenomai RTOS work the MachineKit branch has been built on was happening outside the official LinuxCNC repository on a private git server run by Michael Haberler. The new unified build code is slated for inclusion into LinuxCNC 2.6, and can be found in the official LinuxCNC git repository. The official repo is also available on github, where I have cloned it and added a MachineKit-ubc branch. This branch will track the unified build branch (and the LinuxCNC 2.6 branch as it comes together) but make sure the code builds and runs on the BeagleBone. There may also be a few configuration changes specific to the arm or BeagleBone platform.
I will be keeping the MachineKit and MachineKit-ubc branches in my previous github repository up to date for a while, but these should generally be considered deprecated. If you are not using my pre-built images, please switch to using the new linuxcnc repo as soon as you can.
Friday, August 30, 2013
BeBoPr Boards Available Online!
After about a year (or an eternity in the 3D printer world), the BeBoPr board is FINALLY available for purchase through the folks at Circuitco via their BoardZoo.com site:
http://boardzoo.com/index.php/beaglebone/bone-bebopr.html
With any luck, vendors who have had the BeBoPr listed but unavailable for ages (like Mouser and DigiKey) will also have stock soon.
Note that this is the version of the BeBoPr designed for the BeableBone White (remember that year or so I mentioned?), but these boards will work just fine with the newer BeagleBone Black with a few minor tweaks. If you don't need the on-board HDMI, you can get the BeBoPr working with a BBB by cutting two pins and soldering two wires. If you need HDMI or plan to attach an LCD cape, you have to move a bunch of pins around. The easiest way to do this is to get a bridge-board and build it up with some wire and connectors. You can order a set of boards directly from OSH Park, or I will probably be getting a quantity made since you probably won't need all three, and lead time on OSH Park PCBs is a couple weeks. Contact me directly via e-mail: charles (at) steinkuehler (dot) net if you're interested in a set of boards, but note that it will be at least 2-3 weeks until I have any in-hand.
Bas (the BeBoPr designer) has more details on both of these options on his wiki, along with a bunch of other useful information.
The boards from Circuitco should be exactly the same as the board I got directly from Bas (from an early prototype run) and have been using to drive my 3D printer, so it should work just fine with my MachineKit image.
UPDATE:
Bas has a new version of the BeBoPr, the BeBoPr+, which is a BeBoPr with the bridge board directly soldered on. These boards are not yet available through BoardZoo or other online retailers, but Bas has a supply available for EUR 117 each. Contact him directly via e-mail if you're interested: bebopr@aeselectronics.nl
Oh, you might think the bridge board looks a little funny and I agree. It looks kind of funny...but when I'm hooking all the wires to my 3D printer, I REALLY appreciate the extra space between the BeBoPr and the BeagleBone. Not only does it allow me to keep my serial terminal connected, but it keeps the HDMI, USB, and micro-SD cards away from all the wires going to the printer. Having used the BeBoPr both ways, the extra space provided by the bridge board really helps to keep all the connections more accessible.
Saturday, August 17, 2013
Check Your Temperature
Printing vases is hard, but I finally managed to get it right:
I kept getting gaps in my vases, which looked for all the world like the motors were skipping during the print. This wasn't simply loosing steps, however, as later layers were still aligned correctly, so something strange was going on. I spent MANY hours over several days trying to see if I could get LinuxCNC to cause one of the goofs while I was watching, to no avail (each print takes almost 4 hours).
Finally, I thought I found a reliable way to cause the glitching by using the Mini gui and enabling the back-plot display. Except it turns out that for some unknown reason, when you enable the back-plot the Mini gui actually pauses real-time motion ON PURPOSE until the plot is generated, then starts things back up again, which was causing the glitch I was seeing. <sigh>
Anyway, since some of the goofs had a bit of the "burned plastic" look about them (brownish discoloration of the normally translucent plastic), I figured I'd try reducing the temperature a bit. Dropping from 180 degrees to 170 helped a LOT, and resulted in only a few errors in a 3+ hour vase print (vs. at least 20-30 usually). Another ten degrees lower, and printing at 160 degrees completely cleared up the glitches, and I got my first clean printed spiral vase (above). Here's a close-up:
I had been happily printing more 'normal' objects (with infill) at 180 degrees without issue both with LinuxCNC and with my earlier Ardunio/RAMPS combination. I never printed a vase with my Ardunio, so I'm not sure yet if the reduced temperature is required because of a difference between the temperature readings on the Arduino/RAMPS board and the BeBoPr with LinuxCNC, or because when printing a vase there's not enough plastic going through the extruder fast enough to keep the hot-end from heat-soaking and causing "mini-jams" or cooking the plastic a bit. Probably a little of both.
I kept getting gaps in my vases, which looked for all the world like the motors were skipping during the print. This wasn't simply loosing steps, however, as later layers were still aligned correctly, so something strange was going on. I spent MANY hours over several days trying to see if I could get LinuxCNC to cause one of the goofs while I was watching, to no avail (each print takes almost 4 hours).
Finally, I thought I found a reliable way to cause the glitching by using the Mini gui and enabling the back-plot display. Except it turns out that for some unknown reason, when you enable the back-plot the Mini gui actually pauses real-time motion ON PURPOSE until the plot is generated, then starts things back up again, which was causing the glitch I was seeing. <sigh>
Anyway, since some of the goofs had a bit of the "burned plastic" look about them (brownish discoloration of the normally translucent plastic), I figured I'd try reducing the temperature a bit. Dropping from 180 degrees to 170 helped a LOT, and resulted in only a few errors in a 3+ hour vase print (vs. at least 20-30 usually). Another ten degrees lower, and printing at 160 degrees completely cleared up the glitches, and I got my first clean printed spiral vase (above). Here's a close-up:
I had been happily printing more 'normal' objects (with infill) at 180 degrees without issue both with LinuxCNC and with my earlier Ardunio/RAMPS combination. I never printed a vase with my Ardunio, so I'm not sure yet if the reduced temperature is required because of a difference between the temperature readings on the Arduino/RAMPS board and the BeBoPr with LinuxCNC, or because when printing a vase there's not enough plastic going through the extruder fast enough to keep the hot-end from heat-soaking and causing "mini-jams" or cooking the plastic a bit. Probably a little of both.
Wednesday, August 7, 2013
K9 SmorgasBoard
A new toy:
While I was on vacation, the great folks over at Practical Micro Design sent me a geeky new toy to play with, the K9 SmorgasBoard! This awesome board has just about every sort of I/O you might want if you're working on machine control using a BeagleBone. There are Pololu sockets for the 3D printer crowd, more traditional DB25/LPT connectors for "legacy" motor drivers as used in LinuxCNC, analog inputs and outputs (including support for thermocouples), RS422/differential encoder inputs, and lots more.
I saw one of these at the LinuxCNC dev-fest in Wichita, but it's a lot more fun having one to play with! Not to worry if you have a BeBoPr, however...I am keeping my BeBoPr and bridge board setup as the controller for my MendelMax printer, and I'm going to use the K9 for experiments. I'm currently planning on building a slightly modified Mini-Kossel, but I'll have to see how it turns out. It may wind up being more than just slightly modified. :)
If you're not completely living on the bleeding edge and trying to drive all your machine control applications with a BeagleBone, checkout the other products from the PMDX folks. They have a lot of stuff that might help you move motors and make some chips. Also, drop them a line if there's something you REALLY want to see in a BeagleBone expansion cape, or if you'd like to have them make a BeagleBone product at all. The K9 is mostly a proof of concept and test platform, so pipe up and let them know if you want to see a real product or it may never happen!
Oh, and if you want to get geeks writing code for you for free, send them some nifty new hardware to play with (hint-hint!). Let's see, I could use a... ;-)
Sunday, July 28, 2013
Happy Birthday BeagleBoard!
Wow! It's been five years since the introduction of the first Beagle Board, and they just keep getting better! Many thanks and happy birthday wishes to the folks over at BeagleBoard.org. Keep the coolness coming!
Title: BeagleBoard.org celebrates 5 years of enabling Linux DIY hacks
Title: BeagleBoard.org celebrates 5 years of enabling Linux DIY hacks
Date: July 28, 2013
BeagleBoard.org launched with support of Digi-Key in 2008 and DIYers quickly adopted BeagleBoard for migrating XBMC to ARM, building GPS accurate down to the centimeter, eight-legged robots and creating controller hacks. In 2010, Google Summer of Code students contributed numerous projects to help other open source developers, including sniffing USB traffic and XBMC performance optimizations. GSoC students are back at it again in 2013, providing solutions for booting
BeagleBone from a Nexus phone, running Arduino sketches and even
building new peripherals out of an on-chip microcontroller.
With the introduction of BeagleBoard-xM in 2010, projects accelerated with homemade tablet computers, open graphing calculators, cluster computing in a briefcase,repurposed laptop LCDs, remote presence and versatile RC robots, space cameras, USB killswitches and wearable LED matrices. BeagleBoard-based wearables back in 2010 even provided a strikingly similarity to today's Google Glass.
With the introduction of BeagleBoard-xM in 2010, projects accelerated with homemade tablet computers, open graphing calculators, cluster computing in a briefcase,repurposed laptop LCDs, remote presence and versatile RC robots, space cameras, USB killswitches and wearable LED matrices. BeagleBoard-based wearables back in 2010 even provided a strikingly similarity to today's Google Glass.
BeagleBone launched in 2011 to the cheers of robot makers everywhere, even robot makers looking to replace guide dogs and soothe the everyday angry bird, but inventiveness wasn't limited to awesome, futuristic robots. The tiny, low-power processing solution enabled tidy home power usage monitors, off-the-grid wireless outposts,QR code controlled door locks, networked LED marquees, portable 3D cameras and even cameras that would print scene descriptions in words. BeagleBone's portable performance was utilized for countless goals, including cracking passwords, manufacturing money and helping to save the world from pollution.
BeagleBone seemed to find a surprising home in retro computing, mimicking PDP11 blinkenlights and saving dot-matrix printers from the dust bin.
This seemed to be an inspiration for inventive minds seeking to teach
others about the more subtle capabilities the board is packing. The two,
small 200MHz 32-bit microcontrollers on-board were used to mimic external peripherals to a discrete 6502 processor, enabling more people to understand the capabilities of these independent units previously demonstrated performing independent generation of VGA signals using a simple resistor ladder.
The tutorials continued with everything from twiddling an LED and running Ubuntu with a full GUI, to extracting video signals and wiring up your own LIDD displays, evenbuilding your own dedicated Pandora radio. This is all before BeagleBone Black launched, boosting performance to 1GHz, adding on-board eMMC and HDMI and dropping the price down to $45.
BeagleBone Black is just getting its legs underneath it in its initial production run of 125,000 units with around half of those shipped so far. Early adopters were able to share some of their creations at Maker Faire, including LED strips being used to display live video. Beyond the obvious and popular lighting solutions, BeagleBone Black has found an early home in manufacturing solutions, especially with makers like Elias Bakken, who created the contest-winning Replicape 3D printer-enabling add-on board and a tiny HDMI display for use with BeagleBone Black, and Charles Steinkuehler, who has created the MachineKit software image containing LinuxCNC and Xenomi real-time Linux kernel. Both Elias and Charles have been steady contributors to the project of late and have helped enable several of the improvements making BeagleBone Black a complete and easy to use solution for all sorts of makers.
BeagleBone Black is just getting its legs underneath it in its initial production run of 125,000 units with around half of those shipped so far. Early adopters were able to share some of their creations at Maker Faire, including LED strips being used to display live video. Beyond the obvious and popular lighting solutions, BeagleBone Black has found an early home in manufacturing solutions, especially with makers like Elias Bakken, who created the contest-winning Replicape 3D printer-enabling add-on board and a tiny HDMI display for use with BeagleBone Black, and Charles Steinkuehler, who has created the MachineKit software image containing LinuxCNC and Xenomi real-time Linux kernel. Both Elias and Charles have been steady contributors to the project of late and have helped enable several of the improvements making BeagleBone Black a complete and easy to use solution for all sorts of makers.
As of the recent June 20th software release for BeagleBone Black,
significant improvements have been made since launch. Monitor support
is greatly improved with better automated resolution setting and a
documented process for setting specific resolutions over the
command-line or at boot-up, including resolutions up to 1920x1080 at
24fps. The node.js-based BoneScript library, used in such fun things as multi-room physically interactive video games, has several bug fixes and a growing body of interactive wiring examples that
work within Chrome and Firefox browsers. Support for the on-board
32-bit microcontrollers called PRUs has been improved with an updated assembler and documentation supporting
previously undocumented instructions, including multipliers, and hints
have been made at a C compiler being developed, including Pantelis
Antoniou's example of using the PRU C compiler to add 32 additional channels of pulse-width modulation (PWM). The value of aggressively chasing the mainline kernel is
also being shown with simple command-line statements for enabling
UARTs, SPI, I2C, CAN and more peripherals, including improved cape add-on board support.
With an amazing community,
stand-out performance and capability, a true open hardware approach
that is sustainably profitable but not greedy, continuous demonstrated
improvements and a focus on educating aspiring engineers and hobbyists alike,
BeagleBoard.org has proven to be a DIY force with which to reckon and
an inspiration for makers everywhere. Happy Birthday Boris!
Monday, July 22, 2013
BeBoPr Bridge: Stand-alone Machine Control
UPDATE: If you buy a small LCD, I suggest getting one with slightly
higher resolution. I am wising in particular I had a bit more vertical
resolution when running the Axis GUI for LinuxCNC.
One of the few things I don't like about the BeBoPr board is since it pre-dates the BeagleBone Black it conflicts with a bunch of pins that are now reserved for the new on-board HDMI and 2G eMMC.
Fortunately, Bas has released the BeBoPr-Bridge board, which is a set of boards that shuffles around the I/O pin-out and allows an otherwise stock BeBoPr to work with a BeagleBone Black without causing any pin conflicts. The Bridge board even solves the problem of how to access the serial boot console when using the BeBoPr!
Thanks to the folks at OSH Park, I was able to get three sets of the Bridge board fabricated and shipped to me for a total cost of $23.10 (including shipping), or about $7 each! Once the boards arrived and I got them built up, it was time to print something stand-alone using the BeagleBone Black and my $79 eBay special HDMI monitor:
If you want to follow along, make sure you're using my latest MachineKit image (with the -bone23 kernel), and do a git pull to grab the latest configuration files from the MachineKit branch of LinuxCNC. Launch LinuxCNC with the BeBoPr-Bridge configuration, and make sure you have not disabled the HDMIN cape in uEnv.txt. The latest image comes setup properly by default (HDMI disabled, and HDMIN enabled), but if you have been using a stock BeBoPr board you probably have both versions disabled.
Here are a couple still photos, you can find more on my G+ page.
One of the few things I don't like about the BeBoPr board is since it pre-dates the BeagleBone Black it conflicts with a bunch of pins that are now reserved for the new on-board HDMI and 2G eMMC.
Fortunately, Bas has released the BeBoPr-Bridge board, which is a set of boards that shuffles around the I/O pin-out and allows an otherwise stock BeBoPr to work with a BeagleBone Black without causing any pin conflicts. The Bridge board even solves the problem of how to access the serial boot console when using the BeBoPr!
Thanks to the folks at OSH Park, I was able to get three sets of the Bridge board fabricated and shipped to me for a total cost of $23.10 (including shipping), or about $7 each! Once the boards arrived and I got them built up, it was time to print something stand-alone using the BeagleBone Black and my $79 eBay special HDMI monitor:
If you want to follow along, make sure you're using my latest MachineKit image (with the -bone23 kernel), and do a git pull to grab the latest configuration files from the MachineKit branch of LinuxCNC. Launch LinuxCNC with the BeBoPr-Bridge configuration, and make sure you have not disabled the HDMIN cape in uEnv.txt. The latest image comes setup properly by default (HDMI disabled, and HDMIN enabled), but if you have been using a stock BeBoPr board you probably have both versions disabled.
Here are a couple still photos, you can find more on my G+ page.
Complete system with the BeagleBone Black mounted on top of the BeBoPr using the Bridge Board.
Bridge board mounted on my BeagleBone Black with serial cable, USB mouser/KB receiver, and HDMI cable connected.
Friday, July 19, 2013
Multiple ADC Readings
Heated Bed Working
It turns out the BeagleBone ADC "helper" kernel drivers are very particular about exactly how you talk to them. If you try to read from them too fast, or even worse have two threads trying to read ADC values at the same time, Bad Things happen. What exactly? You can get illegal values (outside the 0-4095 range of the ADC), values from the wrong analog input channel, or have your program crash with access errors. This has been preventing me from getting the heated bed working on my printer, since I initially coded the ADC thermistor HAL component with the idea that each thermistor would be read by it's own thread.I have re-worked the python code to support reading more than one thermistor, and it seems to be working well. I managed to finish a print that took a couple hours, and I left the system running overnight and it is still working as expected this morning. For comparison, with two threads reading thermistor values, one of the threads would die within a couple of minutes.
Configuration should be fairly obvious, refer to the example BeBoPr and BeBoPr-Bridge configurations. There is a new --num_chan parameter, and the existing --adc and --therm parameters now take a list of values, one for each analog input channel. Also added is a short-hand notion for the thermistor table, so you can now use "1" (the equivalent Marlin thermistor table number) instead of "epcos_B57560G1104". Handy if you have 3 thermistors attached!
Wednesday, July 17, 2013
Linear Delta Kinematics
I started working with LinuxCNC when I saw Johann Rocholl's Rostock linear delta printer. Trying to squeeze reverse kinematics for non-Cartesian movements into an AVR seemed like a fools errand to me, so I turned to LinuxCNC, which has pluggable kinematics. But someone has to write those kinematics!
Thanks to Viesturs, I found this awesome video of a linear delta robot controlled by LinuxCNC from back in 2011! Hg5bsd (Jozsef Papp) has provided the lindeltakins.c file used to control his 'bot, and a sketch of the control layout. If you are lucky enough to have a working linear delta mechanism (mine is currently in-progress), you should try out LinuxCNC with these kinematics and see how it works for you!
Everything old is new again
"Official" LinuxCNC Support
In similar news, LinuxCNC developer Jeff Eppler has acquired a Rostock Max, and has also written some linear delta kinematics. Keep up with his delta changes in the jepler/lineardeltakins branch at git.linuxcnc.org.Monday, July 15, 2013
Custom HDMI Resolution
UPDATE: If you buy a small LCD, I suggest getting one with slightly higher resolution. I am wising in particular I had a bit more vertical resolution when running the Axis GUI for LinuxCNC.
As follow-up to my post on how to force HDMI Resolution, I recently obtained a small 7" 800x480 LCD display with HDMI input and found I need to not only force a particular resolution, but a resolution that is non-standard as well.
It turns out this is pretty easy once you filter through all the hints that don't work (lots of fbset and xrandr instructions). If you want a custom display mode, all you have to do is give the kernel your desired resolution and tell it to calculate the cvt timings. There are some details in the kernel documentation for modedb.txt, and the following uEnv.txt entry (which turns into a kernel command line argument) got my display working properly:
Note the "M" after the resolution and before the "@", which is what tells the kernel to calculate timings for this resolution rather than try to find it as a pre-existing standard. You can specify other details, like reduced blanking or interlaced mode, see the modedb.txt documentation for details.kms_force_mode=video=HDMI-A-1:800x480M@60
This setting works with my latest MachineKit Debian image, based on Robert C Nelson's Debian image, with xfce and xdm added for a desktop environment. The kms_force_mode uEnv.txt variable is supported in Robert's latest images, and the actual kernel command line parameter you want to set is "video=HDMI...".
For those of you still running Angstrom, the above setting only affects the display while the kernel is booting. Once the system is running, Angstrom's custom version of Gnome takes over, blindly ignores any prior resolution settings, and forces the HDMI output into whatever video mode it considers "best" based on your EDID settings. This is all well and good for most monitors, but my low-end LCD panel doesn't have it's native resolution listed as any of it's EDID options. I tried "lying" to the system by crafting a custom EDID and overriding the EDID from the display, which seems like it should work, but absolutely nothing changed. Probably because the default BeagleBone kernel is compiled with CONFIG_DRM_LOAD_EDID_FIRMWARE disabled.
Here's a screen shot of my BeagleBone Black happily running in 800x480 mode, nicely mapping 1:1 to the native resolution of my $79 eBay HDMI special:
And here's the actual display:
Sunday, July 14, 2013
Adding Home/Limit Switches
Home switches are especially convenient on 3D printers to return the printer to a known location, to get perfect adhesion from a perfect first layer height. They're pretty much a requirement for delta 3D printers as well.
This post will walk through the steps to modify the base MachineKit image with LinuxCNC to add a limit switch. Walking through the steps will take some time, but helps to explain concepts like the HAL and Device Tree.
In a commit from 7/14, Charles checked in code to export and set up the limit switch inputs, in the MachineKit branch, so to get most of the code needed, do:
... then follow the instructions and notes below to modify BeBoPr.ini and BeBoPr.hal for your specific printer.
BeBoPr Limit Switches
The BeBoPr board has 6 switch inputs which can be used as limit or home switches.
Our goal is to wire up one input switch to LinuxCNC so that when the X axis starts to home, pressing the NC (inverted-logic) switch causes the axis to stop and detect home. To do this, we'll modify a bunch of files.
We'll use X-Max, the limit switch closest to the PWM outputs at the edge of the BeBoPr. According to the BeBoPr manual, the BeagleBone black manual (BBB_SRM.pdf pg 80), and tracing the board traces, the X-max input switch is pin 32 on connector 8 and gpio0.11.
First, LinuxCNC needs to know that you want to use a limit switch when homing an axis. The .ini file sets all kinds of config specific to your board and machine.
Setting an axis instance with a homing search velocity causes it go in the specified direction when you click the home button. Here's a change that enables this:
For more details on homing, see Sec 4, Homing Configuration, in:
http://www.linuxcnc.org/docs/LinuxCNC_Integrator_Manual.pdf
You'll definitely want to make sure that the polarity of HOME_SEARCH_VEL is the right direction for your machine to drive it toward the home axis.
Now when you click the Home button in the LCNC GUI, you'll see the axis move. Great! But it has no way to find home, so it'll keep searching forever.
The HAL in LinuxCNC is the Hardware Abstraction Layer. It provides a higher-level way to wire up in input to outputs, without having to recompile the LinuxCNC base code.
We also need to wire up a signal in the HAL so that the limit switch pin is connected to the axis homing logic. home-sw-in is a pre-defined attribute of the axis instance that is meant for this:
However, this change won't be enough, as the pin is unknown to the HAL. Running this code will cause LCNC to exit:
To get one step closer to making the pin accessible, modify this line at the top:
Add input_pins = 132 to the line. Why 132?
From ~/linuxcnc/src/hal/drivers/hal_bb_gpio.c, line 191 has this comment:
Valid pins are 101-146 for P8 pins, 201-246 for P9 pins
You'll notice that every component seems to have its own numbering scheme.
Running this then yields:
The HAL can only provide access to a pin if the OS knows the pin. Board-specific pin definitions are in the most recent version of Linux as the Device Tree. We'll next add the missing pins to the device tree.
The file ~/linuxcnc/configs/BeagleBone/BeBoPr/BB-LCNC-BEBOPR-00A0.dts contains the device tree for the BeBoPr. Here are some notes from Charles:
The relevant section for the device tree is toward the bottom, and it configures attributes of pins. The chip in the BeagleBone uses a big pin multiplexer for this:
For each pin, there are two values:
First Value: The first value is the address offset of the pinmux register (or more specifically, the conf_<module>_<pin> register). See the TRM section 9.3.51 for details, and table 9.10 for the addresses. Note in the DTS file that the addresses are offsets from the start of the conf_ register section instead of the start of the control registers, so you have to subtract 0x800 from the listed address.
There's a nice spreadsheet on github that combines all the BeagleBone specific I/O stuff:
https://github.com/selsinork/beaglebone-black-pinmux
...it will save you from having to cross correlate data from 3 or more manuals! :)
Second Value: The second value is pin usage, which is also defined TRM section 9.3.51. For example, pru1.r30.13 is to be used in mode 5 ("by the PRU"), and with bit 3 (pullup) disabled, bits 2-0 are 5, making this byte 0xd. Other GPIO pins are mode 7, so the byte is 0xf. Pin usage is also defined on page 98 of the BBB SRM.
Now we'll mod the device tree file. As a reminder, gpio0.11 is the X-max input switch, which is pin 32 on connector 8.
Page 80 of the SRM shows this pin to also be called gpmc_a19, lcd_data15, and UART5_RSTN. Table 9-10 of the TRM shows offset 8DCh for lcd_data15; subtracting the 0x800 base, we get 0xdc for the first value.
The second value will be a bit different, too, because we want to set the RXACTIVE and PULLTYPESEL bits to 1. These bits make the port an input and enable a pullup. Hence, the second value in the .dts for input pins should be 0x3f, not 0x0f.
After making these changes, run dtc.sh in the same dir (and possibly reboot):
dtc.sh looks like this:
It's invoking the device tree compiler to form a device tree file for the kernel to load.
There's one more place we need to make some mods.
The next file to mod is ~/linuxcnc/configs/BeagleBone/BeBoPr/setup.sh. The bottom of this file looks like:
There are several different numbering schemes in use; the gpio numbers
in setup.sh use the kernel pin numbering which is:
Kernel Pin = (<gpio_bank> * 32) + <gpio_pin>
Charles' pin assignments for the PRU are very similar, but off by 32 so that
a value of zero results in no pin being driven:
hal_pru_generic pin = ((<gpio_bank> + 1) * 32) + <gpio_pin>
...or for PRU direct pins:
hal_pru_generic pin = ((4 + 1) * 32) + <PRU_pin>
And you already read about about the hal_bb_gpio pin numbering based on the
P8/P9 pin numbers.
Here were my changes:
Now linuxcnc should start! Almost there.
First, verify that your limit switch pin is connected. When you press it, the corresponding light on the BeBoPr should toggle.
Then, verify that Linux sees the same thing:
You should see this:
Then press the switch, and the top line should go low:
If that works, go to linuxcnc, toggle e-stop, toggle machine power, and then home the X axis.
Click 'Home X'. The axis should move until the button is pressed; then it'll reverse until the button is released.
Woo! You now have a working home switch.
This post will walk through the steps to modify the base MachineKit image with LinuxCNC to add a limit switch. Walking through the steps will take some time, but helps to explain concepts like the HAL and Device Tree.
Getting the Code
In a commit from 7/14, Charles checked in code to export and set up the limit switch inputs, in the MachineKit branch, so to get most of the code needed, do:
cd linuxcnc/src git pull make sudo make setuid
... then follow the instructions and notes below to modify BeBoPr.ini and BeBoPr.hal for your specific printer.
BeBoPr Limit Switches
The BeBoPr board has 6 switch inputs which can be used as limit or home switches.
Our goal is to wire up one input switch to LinuxCNC so that when the X axis starts to home, pressing the NC (inverted-logic) switch causes the axis to stop and detect home. To do this, we'll modify a bunch of files.
We'll use X-Max, the limit switch closest to the PWM outputs at the edge of the BeBoPr. According to the BeBoPr manual, the BeagleBone black manual (BBB_SRM.pdf pg 80), and tracing the board traces, the X-max input switch is pin 32 on connector 8 and gpio0.11.
BeBoPr.ini
First, LinuxCNC needs to know that you want to use a limit switch when homing an axis. The .ini file sets all kinds of config specific to your board and machine.
Setting an axis instance with a homing search velocity causes it go in the specified direction when you click the home button. Here's a change that enables this:
diff --git a/configs/BeagleBone/BeBoPr/BeBoPr.ini b/configs/BeagleBone/BeBoPr/BeBoPr.ini index f3b92a5..2bb64f7 100755 --- a/configs/BeagleBone/BeBoPr/BeBoPr.ini +++ b/configs/BeagleBone/BeBoPr/BeBoPr.ini @@ -165,8 +165,8 @@ MIN_FERROR = 0.25 HOME = 0.000 HOME_OFFSET = 0.00 -#HOME_SEARCH_VEL = 0.10 -#HOME_LATCH_VEL = -0.01 +HOME_SEARCH_VEL = -10.0 +HOME_LATCH_VEL = 10.0 #HOME_USE_INDEX = YES #HOME_IGNORE_LIMITS = YES
For more details on homing, see Sec 4, Homing Configuration, in:
http://www.linuxcnc.org/docs/LinuxCNC_Integrator_Manual.pdf
You'll definitely want to make sure that the polarity of HOME_SEARCH_VEL is the right direction for your machine to drive it toward the home axis.
Now when you click the Home button in the LCNC GUI, you'll see the axis move. Great! But it has no way to find home, so it'll keep searching forever.
BeBoPr.hal
The HAL in LinuxCNC is the Hardware Abstraction Layer. It provides a higher-level way to wire up in input to outputs, without having to recompile the LinuxCNC base code.
We also need to wire up a signal in the HAL so that the limit switch pin is connected to the axis homing logic. home-sw-in is a pre-defined attribute of the axis instance that is meant for this:
diff --git a/configs/BeagleBone/BeBoPr/BeBoPr.hal b/configs/BeagleBone/BeBoPr/BeBoPr.hal index 2bc5b38..1d9de6f 100755 --- a/configs/BeagleBone/BeBoPr/BeBoPr.hal +++ b/configs/BeagleBone/BeBoPr/BeBoPr.hal @@ -91,6 +91,10 @@ setp [PRUCONF](DRIVER).stepgen.00.steppin 0xA2 # P8.44 PRU1.out4 setp [PRUCONF](DRIVER).stepgen.00.dirpin 0xA3 +# Example from http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Homing_And_Limit_Switch +# Connect X-max input to X min input. +net home-x bb_gpio.p8.in-32 => axis.0.home-sw-in +setp bb_gpio.p8.in-32.invert 1 # ################ # Y [1] Axis
However, this change won't be enough, as the pin is unknown to the HAL. Running this code will cause LCNC to exit:
BeBoPr.hal:96: Pin 'bb_gpio.p8.in-32' does not exist Shutting down and cleaning up LinuxCNC...
To get one step closer to making the pin accessible, modify this line at the top:
loadrt hal_bb_gpio output_pins=103,105,107,120,121,127,128,129,130,139,140,141,142,143,144,145,146
Add input_pins = 132 to the line. Why 132?
From ~/linuxcnc/src/hal/drivers/hal_bb_gpio.c, line 191 has this comment:
Valid pins are 101-146 for P8 pins, 201-246 for P9 pins
You'll notice that every component seems to have its own numbering scheme.
Running this then yields:
linuxcnc@arm:~/linuxcnc/configs/BeagleBone/BeBoPr$ LINUXCNC - 2.6.0~pre ... memmapped gpio port 0 to 0xb6f5c000, oe: 0xb6f5c134, set: 0xb6f5c194, clr: 0xb6f5c190 Waiting for component 'hal_bb_gpio' to become ready................................................................................................ BeBoPr.hal:25: /home/linuxcnc/linuxcnc/bin/rtapi_app exited without becoming ready BeBoPr.hal:25: insmod failed, returned -1 Shutting down and cleaning up LinuxCNC...
The HAL can only provide access to a pin if the OS knows the pin. Board-specific pin definitions are in the most recent version of Linux as the Device Tree. We'll next add the missing pins to the device tree.
Device Tree for BeBoPr Cape
The file ~/linuxcnc/configs/BeagleBone/BeBoPr/BB-LCNC-BEBOPR-00A0.dts contains the device tree for the BeBoPr. Here are some notes from Charles:
- Every used I/O pin needs to show up in the dts device tree file, with an appropriate pin mux setting.
- Any GPIO pin driven by the PRU (ie: Step, Dir, PWM) needs to be exported in setup.sh.
- Direct PRU I/O pins do *NOT* need to be exported in setup.sh.
- At least _one_ pin needs to be exported in setup.sh to enable the low-level gpio hardware, or the hal_bb_gpio module will fail. It is OK to export a pin used by hal_bb_gpio for this...it is just not required that all hal_bb_gpio pins get exported
- Any GPIO pins not driven by the PRU should be listed in the hal_bb_gpio command line.
The relevant section for the device tree is toward the bottom, and it configures attributes of pins. The chip in the BeagleBone uses a big pin multiplexer for this:
fragment@0 {
target = <&am33xx_pinmux>;
__overlay__ {
foo_pins: foo_pins {
pinctrl-single,pins = <
0x18 0x0f /* p8.3 gpio1_6 */
0x08 0x0f /* p8.5 gpio1_2 */
For each pin, there are two values:
First Value: The first value is the address offset of the pinmux register (or more specifically, the conf_<module>_<pin> register). See the TRM section 9.3.51 for details, and table 9.10 for the addresses. Note in the DTS file that the addresses are offsets from the start of the conf_ register section instead of the start of the control registers, so you have to subtract 0x800 from the listed address.
There's a nice spreadsheet on github that combines all the BeagleBone specific I/O stuff:
https://github.com/selsinork/beaglebone-black-pinmux
...it will save you from having to cross correlate data from 3 or more manuals! :)
Second Value: The second value is pin usage, which is also defined TRM section 9.3.51. For example, pru1.r30.13 is to be used in mode 5 ("by the PRU"), and with bit 3 (pullup) disabled, bits 2-0 are 5, making this byte 0xd. Other GPIO pins are mode 7, so the byte is 0xf. Pin usage is also defined on page 98 of the BBB SRM.
Now we'll mod the device tree file. As a reminder, gpio0.11 is the X-max input switch, which is pin 32 on connector 8.
Page 80 of the SRM shows this pin to also be called gpmc_a19, lcd_data15, and UART5_RSTN. Table 9-10 of the TRM shows offset 8DCh for lcd_data15; subtracting the 0x800 base, we get 0xdc for the first value.
The second value will be a bit different, too, because we want to set the RXACTIVE and PULLTYPESEL bits to 1. These bits make the port an input and enable a pullup. Hence, the second value in the .dts for input pins should be 0x3f, not 0x0f.
diff --git a/configs/BeagleBone/BeBoPr/BB-LCNC-BEBOPR-00A0.dts b/configs/BeagleBone/Be
index 50f1709..67279d2 100644
--- a/configs/BeagleBone/BeBoPr/BB-LCNC-BEBOPR-00A0.dts
+++ b/configs/BeagleBone/BeBoPr/BB-LCNC-BEBOPR-00A0.dts
@@ -20,6 +20,7 @@
"p8.28", /* gpio2.24 Z_Ena */
"p8.29", /* pru1.r30.9 Z_Dir */
"p8.30", /* pru1.r30.11 E_Step */
+ "p8.32", /* gpio0.11 X_Max */
"p8.36", /* gpio2.16 J4_PWM */
"P8.39", /* pru1.r30.6 Y_Dir */
"P8.40", /* gpio2.13 Y_Ena */
@@ -36,6 +37,7 @@
"gpio1_2",
"gpio2_2",
"gpio1_31",
+ "gpio0_11",
"gpio2_24",
"gpio2_16",
"gpio2_13",
@@ -57,6 +59,7 @@
0xe8 0x0d /* p8.28 pru1.r30.10 */
0xe4 0x0d /* p8.29 pru1.r30.9 */
0xec 0x0d /* p8.30 pru1.r30.11 */
+ 0xdc 0x3f /* p8.32 gpio0_11 */
0xc8 0x0f /* p8.36 gpio2_16 */
0xb8 0x0d /* p8.39 pru1.r30.6 */
0xbc 0x0f /* p8.40 gpio2_13 */
After making these changes, run dtc.sh in the same dir (and possibly reboot):
cd ~/linuxcnc/configs/BeagleBone/BeBoPr/ sudo ./dtc.sh
dtc.sh looks like this:
#!/bin/sh dtc -O dtb -o BB-LCNC-BEBOPR-00A0.dtbo -b 0 -@ BB-LCNC-BEBOPR-00A0.dts && \ cp BB-LCNC-BEBOPR-00A0.dtbo /lib/firmware/ dtc -O dtb -o BB-LCNC-BEBOPRBR-00A0.dtbo -b 0 -@ BB-LCNC-BEBOPRBR-00A0.dts && \ cp BB-LCNC-BEBOPRBR-00A0.dtbo /lib/firmware/
It's invoking the device tree compiler to form a device tree file for the kernel to load.
There's one more place we need to make some mods.
setup.sh
The next file to mod is ~/linuxcnc/configs/BeagleBone/BeBoPr/setup.sh. The bottom of this file looks like:
# Export GPIO pins
# This really only needs to be done to enable the low-level clocks for the GPIO
# modules. There is probably a better way to do this...
while read PIN DIR JUNK ; do
case "$PIN" in
""|\#*)
continue ;;
*)
[ -r /sys/class/gpio/gpio$PIN ] && continue
sudo -A su -c "echo $PIN > /sys/class/gpio/export" || pin_err
sudo -A su -c "echo $DIR > /sys/class/gpio/gpio$PIN/direction" || dir_err
;;
esac
done <<- EOF
38 low # gpio1.6 P8.3 Enable
34 high # gpio1.2 p8.5 Enable_n
66 high # gpio2.2 p8.7 Enable_n (ECO location)
92 out # gpio2.24 P8.28 Z_Ena
80 out # gpio2.16 P8.36 J4.PWM
77 out # gpio2.13 P8.40 Y_Ena
74 out # gpio2.10 P8.41 X_Ena
EOF
There are several different numbering schemes in use; the gpio numbers
in setup.sh use the kernel pin numbering which is:
Kernel Pin = (<gpio_bank> * 32) + <gpio_pin>
Charles' pin assignments for the PRU are very similar, but off by 32 so that
a value of zero results in no pin being driven:
hal_pru_generic pin = ((<gpio_bank> + 1) * 32) + <gpio_pin>
...or for PRU direct pins:
hal_pru_generic pin = ((4 + 1) * 32) + <PRU_pin>
And you already read about about the hal_bb_gpio pin numbering based on the
P8/P9 pin numbers.
Here were my changes:
diff --git a/configs/BeagleBone/BeBoPr/setup.sh b/configs/BeagleBone/BeBoPr/setup.sh
index 5a3843f..abf8e1a 100755
--- a/configs/BeagleBone/BeBoPr/setup.sh
+++ b/configs/BeagleBone/BeBoPr/setup.sh
@@ -54,6 +54,7 @@ while read PIN DIR JUNK ; do
esac
done <<- EOF
+ 11 in # gpio0.11 P9.32 X_Max
38 low # gpio1.6 P8.3 Enable
34 high # gpio1.2 p8.5 Enable_n
66 high # gpio2.2 p8.7 Enable_n (ECO location)
Now linuxcnc should start! Almost there.
Testing It
First, verify that your limit switch pin is connected. When you press it, the corresponding light on the BeBoPr should toggle.
Then, verify that Linux sees the same thing:
sudo cat /sys/kernel/debug/gpio
You should see this:
GPIOs 0-31, gpio: gpio-11 (sysfs ) in hi GPIOs 32-63, gpio: gpio-34 (sysfs ) out lo gpio-38 (sysfs ) out hi gpio-52 (eMMC_RSTn ) out lo GPIOs 64-95, gpio: gpio-66 (sysfs ) out lo gpio-74 (sysfs ) out hi gpio-77 (sysfs ) out hi gpio-80 (sysfs ) out lo gpio-92 (sysfs ) out lo
Then press the switch, and the top line should go low:
GPIOs 0-31, gpio: gpio-11 (sysfs ) in lo
If that works, go to linuxcnc, toggle e-stop, toggle machine power, and then home the X axis.
Click 'Home X'. The axis should move until the button is pressed; then it'll reverse until the button is released.
Woo! You now have a working home switch.
Saturday, July 13, 2013
MachineKit 2013-07-13 Available
I have released an updated version my MachineKit Image for running LinuxCNC on the BeagleBone.
Support has been added for the new BeBoPr Bridge, and HDMI is enabled by default allowing the BeagleBone to run stand-alone. A remote display is still required to use hardware that requires disabling the HDMI output, such as the original BeBoPr board without the Bridge adapter.
In addition, the kernel has been updated with the latest BeagleBone specific patches, and the LinuxCNC git working copy includes lots of minor fixes and tweaks made over the last month.
Significant changes in this release include:
Support has been added for the new BeBoPr Bridge, and HDMI is enabled by default allowing the BeagleBone to run stand-alone. A remote display is still required to use hardware that requires disabling the HDMI output, such as the original BeBoPr board without the Bridge adapter.
In addition, the kernel has been updated with the latest BeagleBone specific patches, and the LinuxCNC git working copy includes lots of minor fixes and tweaks made over the last month.
Significant changes in this release include:
- Switch to 3.8.13xenomai-bone23 kernel
- Leave HDMIN (no audio) enabled by default in uEnv.txt
- Add xfce desktop and netsurf web browser
- Remove apache and udhcpd
- Remove linuxcnc user from admin group to enable existing NOPASSWD setting in sudoers.d to work properly:
gpasswd -d linuxcnc admin
- Switch ~/linuxcnc working copy to MachineKit branch:
cd ~/linuxcnc git fetch origin git checkout -t origin/MachineKit cd src make sudo make setuid
Saturday, July 6, 2013
Slicing for LinuxCNC
With LinuxCNC running my 3D printer, I have had to tweak my slicing settings to get good results. I normally use Slic3r, but Johann uses KISSlicer, so I tried both.
Anyway, the auto-homing typically inserted at the start of a gcode file generally won't do what you expect, so it is important to make sure you have manually homed the X, Y, and Z axis before your first print, and REHOME THE EXTRUDER AXIS to zero just before printing anything! If you do not home the extruder axis, the first thing that will happen when you start your print is your extruder will try to 'unwind' all the filament it has extracted and end up ejecting the filament out of the extruder, and you will get to start over again. I am looking into fixing this with gcode remapping, incremental coordinates, or some other solution, but for now just remember to re-home the A (extruder) axis before each print!
It turns out the current version of slic3r (0.9.10b) forces a few settings if you select the Mach3/EMC gcode flavor. Essentially, selecting this gcode flavor forces retraction to be combined with subsequent travel in a g0 move, and disables wipe entirely. LinuxCNC performs coordinated g0 moves, so if the travel distance was very far, the retraction wasn't happening fast enough to avoid ooze no matter what I set it to. And wipe wasn't helping because it was being disabled by my selection of the Mach3/EMC gcode flavor. I made a small patch that fixes this issue and hopefully it will get resolved in a newer version.
Here's a print from slic3r with my 3mm filament/0.5mm nozzle with 0.2mm layers and 0.4mm infill:
EXTRUDER WARNING
If you are printing with LinuxCNC, it is important to note that homing is completely different than with typical Arduino firmware. This is partly because the Arduino firmware essentially ignored decades of standardized gcode prior art, and partly because controllers like LinuxCNC have multiple coordinate systems (machine, world, part, and joint coordinates, for instance) which are generally all swept into "world" coordinates in most 3D printers.Anyway, the auto-homing typically inserted at the start of a gcode file generally won't do what you expect, so it is important to make sure you have manually homed the X, Y, and Z axis before your first print, and REHOME THE EXTRUDER AXIS to zero just before printing anything! If you do not home the extruder axis, the first thing that will happen when you start your print is your extruder will try to 'unwind' all the filament it has extracted and end up ejecting the filament out of the extruder, and you will get to start over again. I am looking into fixing this with gcode remapping, incremental coordinates, or some other solution, but for now just remember to re-home the A (extruder) axis before each print!
KISSlicer
My issues with KISSlicer mostly related to not having any familiarity with it. I started with Johann's Rostock config from the settings in his Kossel github repo (my printer uses 3mm filament and a 0.5mm nozzle like his Rostock). These slicing settings were reasonable, but I couldn't get gcode that worked for LinuxCNC (it still used E for the extruder axis instead of A). Finally, I found the "Axis" pull-down on the Printers -> Extruders tab, which let me set the axis to A. Using the "5D - Absolute E" firmware type setting, this got the axis setting fixed up. Temperature was still not working properly. M1xx parameters in RS274D/ISO 6983 require P and Q parameters, not S as used in Marlin and friends. This can be fixed in the Ptr G-code tab under Select Extruder. While there go ahead and fix the Deselect Extruder temperature setting, and add your personal prefix/postfix gcode.Slic3r
I default to using Slic3r, which has a straight-forward Mach3/EMC gcode flavor setting under the printer settings tab. Despite having well tuned slic3r settings for this printer when I had it running via Marlin, I was having a terrible time with blobs and ooze. Nothing I did with the retraction settings or wipe seemed to fix the problem, although dialing up retraction did seem to help a bit.It turns out the current version of slic3r (0.9.10b) forces a few settings if you select the Mach3/EMC gcode flavor. Essentially, selecting this gcode flavor forces retraction to be combined with subsequent travel in a g0 move, and disables wipe entirely. LinuxCNC performs coordinated g0 moves, so if the travel distance was very far, the retraction wasn't happening fast enough to avoid ooze no matter what I set it to. And wipe wasn't helping because it was being disabled by my selection of the Mach3/EMC gcode flavor. I made a small patch that fixes this issue and hopefully it will get resolved in a newer version.
Here's a print from slic3r with my 3mm filament/0.5mm nozzle with 0.2mm layers and 0.4mm infill:
Wednesday, June 26, 2013
Using a BeBoPr with a BeagleBone Black
There are some problems using the BeBoPr with the BeagleBone Black. The first issue is you cannot use the serial port header if you have a cape plugged in. This is not specific to theBeBoPr board and affects all capes. I saw someone making a friction fit right-angle connector to solve this issue, but the easy solution is to just make the headers longer using stacking connectors.
I design electronics, so the nice folks at Samtec sent me a few stacking connectors as samples, but they are available for low-volume purchase as well. Official connectors from the BeagleBone SRM are also available via the Major League BeagleBone store:
The next issue is BeBoPr specific. Since the BeBoPr was designed for the initial BeagleBone white, it happens to overlap with the HDMI and eMMC pins. Even worse, the two board enable signals are mapped to eMMC pins that are active during boot, meaning if you have a machine hooked up it could exhibit strange behavior while the BeagleBone Black is booting. One solution is to *REALLY* make your BeagleBone Black behave like a White, but this requires changing boot resistors soldered onto the board and using a custom-built device tree. The easier solution is to apply the ECO developed by the board designer that moves the enable pins away from the eMMC pins that wiggle during boot. Note that my mod does not look exactly like Bas' because I tied pins P8.5 and P8.7 together on the stacking connectors instead of on the BeBoPr, but it's the same mod. My LinuxCNC configuration is setup to drive both the old and the new enable pins, so it should work regardless of which 'Bone you're using and whether or not you've applied the ECO.
Finally, the BeBoPr does not have any provisions for connecting additional circuitry, such as a character LCD or an encoder as typically used in an Arduino based 3D printer as a stand-alone interface. You could solder wires directly to the 'Bone, BeBoPr, or the stacking connectors. However I recommend a breadboard cape, the very cool breakout cape (which also solves the problem of the serial port header interference), or since the 'Bone headers are on a 0.1" grid, just do what I plan on doing and use old-school perf-board from the 'Shack (get whatever size you want, there are several choices). NOTE: For everything but the breakout cape, you will probably have to cut/trim/drill to provide clearance for the serial header and possibly the parts on the BeBoPr board. Break out the Dremel! :)
Stay tuned, I may be adding a section on getting HDMI working with the BeBoPr, but that will require moving a lot of pins.
Problem: Serial connector hits cape
Problem Solved!
I design electronics, so the nice folks at Samtec sent me a few stacking connectors as samples, but they are available for low-volume purchase as well. Official connectors from the BeagleBone SRM are also available via the Major League BeagleBone store:
Samtec SSQ-123-03-T-D
Major League SSHQ-123-D-08-GT-LF
The next issue is BeBoPr specific. Since the BeBoPr was designed for the initial BeagleBone white, it happens to overlap with the HDMI and eMMC pins. Even worse, the two board enable signals are mapped to eMMC pins that are active during boot, meaning if you have a machine hooked up it could exhibit strange behavior while the BeagleBone Black is booting. One solution is to *REALLY* make your BeagleBone Black behave like a White, but this requires changing boot resistors soldered onto the board and using a custom-built device tree. The easier solution is to apply the ECO developed by the board designer that moves the enable pins away from the eMMC pins that wiggle during boot. Note that my mod does not look exactly like Bas' because I tied pins P8.5 and P8.7 together on the stacking connectors instead of on the BeBoPr, but it's the same mod. My LinuxCNC configuration is setup to drive both the old and the new enable pins, so it should work regardless of which 'Bone you're using and whether or not you've applied the ECO.
Finally, the BeBoPr does not have any provisions for connecting additional circuitry, such as a character LCD or an encoder as typically used in an Arduino based 3D printer as a stand-alone interface. You could solder wires directly to the 'Bone, BeBoPr, or the stacking connectors. However I recommend a breadboard cape, the very cool breakout cape (which also solves the problem of the serial port header interference), or since the 'Bone headers are on a 0.1" grid, just do what I plan on doing and use old-school perf-board from the 'Shack (get whatever size you want, there are several choices). NOTE: For everything but the breakout cape, you will probably have to cut/trim/drill to provide clearance for the serial header and possibly the parts on the BeBoPr board. Break out the Dremel! :)
Stay tuned, I may be adding a section on getting HDMI working with the BeBoPr, but that will require moving a lot of pins.
Monday, June 24, 2013
BeBoPr Group Purchase
UPDATE: All the BeBoPr boards I purchased have been sold and shipped out. If you are interested in obtaining a board, please contact Bas directly.
Since the BeBoPr boards are not readily available yet via the usual outlets (they've been back-ordered at Mouser for ages and CircuitCo doesn't seem to have a production run scheduled in the near future) I am coordinating a group purchase of some assembled boards remaining from the initial sample run directly from the board designer (Bas Laarhoven) to save on shipping costs and overall hassle.
Most of the boards are spoken for, but I am buying a few extras. If you are interested in obtaining one, please contact me directly.
List price is EUR 107 each FOB Europe, but I hope to be able to come in at or under that including shipping by doing a group buy. I should have final pricing in a couple of days, once shipping and currency conversion has been dealt with. I also have some technical details I can provide if you're interested.
The boards are on their way across the ocean. If you want one, the cost is $135 including priority mail shipping. Contact me directly via e-mail if you're interested:
charles@steinkuehler.net
Since the BeBoPr boards are not readily available yet via the usual outlets (they've been back-ordered at Mouser for ages and CircuitCo doesn't seem to have a production run scheduled in the near future) I am coordinating a group purchase of some assembled boards remaining from the initial sample run directly from the board designer (Bas Laarhoven) to save on shipping costs and overall hassle.
Most of the boards are spoken for, but I am buying a few extras. If you are interested in obtaining one, please contact me directly.
List price is EUR 107 each FOB Europe, but I hope to be able to come in at or under that including shipping by doing a group buy. I should have final pricing in a couple of days, once shipping and currency conversion has been dealt with. I also have some technical details I can provide if you're interested.
The boards are on their way across the ocean. If you want one, the cost is $135 including priority mail shipping. Contact me directly via e-mail if you're interested:
charles@steinkuehler.net
Sunday, June 23, 2013
Force BeagleBone Black HDMI Resolution
UPDATE: You may find the modedb documentation helpful, in particular note you can add an 'M' to the settings below to force a non-standard resolution, and an 'e' to force the HDMI output to be enabled. I also have another post on setting a custom resolution.
A lot of people seem to be having problems with the HDMI output on the BeagleBone Black (myself included, when I tried it...I usually live at the serial console).
While the newer image releases seem to be improving the operation of HDMI "out of the box", the auto-detection software always seems to pick some crazy resolution with my HDMI monitor and things just don't work properly. If you don't see HDMI output or are still having problems with the latest images (like the display disappears once the 'Bone has booted), you can try forcing your resolution to something your monitor supports.
ALL HDMI monitors are REQUIRED to support 640x480@60 and one of 720x480@60 (NTSC) or 720x576@50 (PAL) depending on their native format. If you force the 'Black output to one of these formats, you should get a working HDMI display.
To force the resolution, you need to add a kernel command line parameter in the uBoot file on the FAT partition of the SD Card (or in the eMMC boot partition if you're running out of the on-board memory).
The kernel command line parameter you need to pass is one of:
If your HDMI is still not working, you can verify you got the setting actually passed to the kernel by looking at the kernel command line in /proc. Here's mine (from a Debian based SD card boot):
Once you get HDMI working at all, you can start to play around and see if you can get a higher resolution to work. The 'Bone can't handle full 1080p60, but 720p should work on almost any modern HDMI display:
Note that my Samsung monitor/TV only disables overscan on one of the two HDMI inputs, and you have to set the source name to "DVI-PC" or it assumes you're feeding it from a video source and stretches the image a bit to get rid of any garbage at the edges.
IMPORTANT
All of the above only applies to what you see while the kernel is booting and simply verifies your monitor and BeagleBone will communicate properly. Once the kernel boots, the BeagleBone launches a Gnome session which takes over full control of the display and picks it's own screen resolution. My system typically defaults to 1080p24, which the BeagleBone can handle (vs. 1080p60, which requires a higher pixel clock frequency than the 'Bone can generate).
One issue I have had with the 'Black is if you do not have a keyboard or mouse plugged in, the system immediately goes into a power-saving mode and shuts down the HDMI output to turn off the monitor. This apparently only happens if Ethernet is connected, which sets the system clock via NTP on boot (and makes your BeagleBone think it has been sitting idle 13+ years waiting for user input!). You can disable the monitor power management for good via the graphical configuration settings in the GUI, or temporarily by giving the frame buffer a "wake up call" and telling it to come out of blanking:
If you know a way to use the command line to disable Gnome monitor power management or force a particular display resolution, let me know in the comments.
A lot of people seem to be having problems with the HDMI output on the BeagleBone Black (myself included, when I tried it...I usually live at the serial console).
While the newer image releases seem to be improving the operation of HDMI "out of the box", the auto-detection software always seems to pick some crazy resolution with my HDMI monitor and things just don't work properly. If you don't see HDMI output or are still having problems with the latest images (like the display disappears once the 'Bone has booted), you can try forcing your resolution to something your monitor supports.
ALL HDMI monitors are REQUIRED to support 640x480@60 and one of 720x480@60 (NTSC) or 720x576@50 (PAL) depending on their native format. If you force the 'Black output to one of these formats, you should get a working HDMI display.
To force the resolution, you need to add a kernel command line parameter in the uBoot file on the FAT partition of the SD Card (or in the eMMC boot partition if you're running out of the on-board memory).
The kernel command line parameter you need to pass is one of:
...and typically you would add this to the optargs= setting to get it passed to the kernel, ie:video=HDMI-A-1:640x480@60 video=HDMI-A-1:720x480@60 video=HDMI-A-1:720x576@50
Note that you can edit the uEnv.txt file on a Windows machine if you boot from an SD card, just be careful not to change the line endings. If you're stuck with a 'Black that doesn't display an interface, upgrade to a recent Angstrom release and you'll at least have a serial console via USB you can use to edit the uEnv.txt file in the on-board eMMC.optargs=video=HDMI-A-1:640x480@60
If your HDMI is still not working, you can verify you got the setting actually passed to the kernel by looking at the kernel command line in /proc. Here's mine (from a Debian based SD card boot):
...if you see the "video=..." section and HDMI still isn't working, something lower level is wrong.$ cat /proc/cmdline console=ttyO0,115200n8 video=HDMI-A-1:640x480@60 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fixrtc ip=
Once you get HDMI working at all, you can start to play around and see if you can get a higher resolution to work. The 'Bone can't handle full 1080p60, but 720p should work on almost any modern HDMI display:
...configuring your HDMI display to disable overscan so you can see the entire image is left as an exercise for the reader! :)NTSC (North America, Japan): video=HDMI-A-1:1280x720@60 PAL (Europe): video=HDMI-A-1:1280x720@50
Note that my Samsung monitor/TV only disables overscan on one of the two HDMI inputs, and you have to set the source name to "DVI-PC" or it assumes you're feeding it from a video source and stretches the image a bit to get rid of any garbage at the edges.
IMPORTANT
All of the above only applies to what you see while the kernel is booting and simply verifies your monitor and BeagleBone will communicate properly. Once the kernel boots, the BeagleBone launches a Gnome session which takes over full control of the display and picks it's own screen resolution. My system typically defaults to 1080p24, which the BeagleBone can handle (vs. 1080p60, which requires a higher pixel clock frequency than the 'Bone can generate).
One issue I have had with the 'Black is if you do not have a keyboard or mouse plugged in, the system immediately goes into a power-saving mode and shuts down the HDMI output to turn off the monitor. This apparently only happens if Ethernet is connected, which sets the system clock via NTP on boot (and makes your BeagleBone think it has been sitting idle 13+ years waiting for user input!). You can disable the monitor power management for good via the graphical configuration settings in the GUI, or temporarily by giving the frame buffer a "wake up call" and telling it to come out of blanking:
Obviously you have to do this from a serial console or an ssh session, and you'll need a mouse hooked to the BeagleBone temporarily to disable the display power management for good. Once power management is disabled, you can remove the mouse and your display will stay alive on subsequent boots.echo 0 > /sys/class/graphics/fb0/blank
If you know a way to use the command line to disable Gnome monitor power management or force a particular display resolution, let me know in the comments.
Sunday, June 16, 2013
Creating SD Image Without a Linux Machine
If you have a BeagleBone and want to play with my MachineKit image but are stuck on Windows without a handy Linux system (other than the 'Bone itself), I've created a page with instructions on how to do it.
You will need a USB Hub, a 4G or larger USB Key, and a USB SD Card Reader in addition to the uSD card itself, your BeagleBone, and a Windows system.
I went through this process because someone reported problems extracting the tar.xz file using a USB key on the BeagleBone, since they didn't have a conventional Linux system handy. As long as you untar the image file on a system with lots of disk space and memory (the xz compression uses a lot of run-time resources, and most BeagleBone systems aren't setup with swap), the BeagleBone can be easily used to run the extracted setup_sdcard.sh script and make a working image.
The excellent 7-Zip archiver utility can be used on Windows to extract the tar.xz file onto a USB key, which can then be hooked to the BeagleBone, where you can run the setup_sdcard.sh script and actually create the image.
You will need a USB Hub, a 4G or larger USB Key, and a USB SD Card Reader in addition to the uSD card itself, your BeagleBone, and a Windows system.
I went through this process because someone reported problems extracting the tar.xz file using a USB key on the BeagleBone, since they didn't have a conventional Linux system handy. As long as you untar the image file on a system with lots of disk space and memory (the xz compression uses a lot of run-time resources, and most BeagleBone systems aren't setup with swap), the BeagleBone can be easily used to run the extracted setup_sdcard.sh script and make a working image.
The excellent 7-Zip archiver utility can be used on Windows to extract the tar.xz file onto a USB key, which can then be hooked to the BeagleBone, where you can run the setup_sdcard.sh script and actually create the image.
Saturday, June 15, 2013
Temperature Conversion Working
Thanks to python and the flexibility of LinuxCNC, last night I was able to throw together a routine to convert ADC readings to temperature, add a PID loop to control the extruder heater, got the M104 temperature set command working, and add the current and set temperature values in a custom panel on the GUI interface:
I still need to tune my PID settings (it's working pretty much just like the bang-bang controller I was using, as I have no I or D terms, and not enough P gain), but that's for another day. If you want to check out the new code, just grab it from the repository. The linuxcnc directory on the image is a full git clone so all you have to do to update is:
I have also several of the GUI interfaces that come with LinuxCNC. The default axis interface is currently a CPU hog, and will need to be switched to something with better performance (or perhaps whatever is chewing up cycles can be identified and fixed). The gscreen interface currently suffers from the same problem, while the tkemc interface is light on CPU cycles, but somewhat harder on the eyes. A customized interface for 3D printing is on the list of features to work on, but I'm more of a low-level guy. Holler if you'd like to help out!
I still need to tune my PID settings (it's working pretty much just like the bang-bang controller I was using, as I have no I or D terms, and not enough P gain), but that's for another day. If you want to check out the new code, just grab it from the repository. The linuxcnc directory on the image is a full git clone so all you have to do to update is:
The compile step is optional for this update, as all that really changed is some configuration files, but the above is generally how you would track updates on the development branch.cd ~/linuxcnc/src git pull origin make sudo make setuid
I have also several of the GUI interfaces that come with LinuxCNC. The default axis interface is currently a CPU hog, and will need to be switched to something with better performance (or perhaps whatever is chewing up cycles can be identified and fixed). The gscreen interface currently suffers from the same problem, while the tkemc interface is light on CPU cycles, but somewhat harder on the eyes. A customized interface for 3D printing is on the list of features to work on, but I'm more of a low-level guy. Holler if you'd like to help out!
Friday, June 14, 2013
Machinekit Image Available
See the MachineKit page for the latest version and updates!
After spending some time struggling with the new Linux 3.8 kernel and device tree overlays, I now have a Linux 3.8 build working as well as the 3.2 build. Even better, I spent quite a bit of time setting up automated builds, and can now generate a customized Debian install that runs LinuxCNC "out of the box".
The images are named "machinekit", and they are built from scratch using a modified version of Robert C Nelson's omap-image-builder scripts. If you don't want to pull the build scripts and make your own image (warning: it takes quite a while), you can just download the pre-built image. Since my images are just tweaked versions of the rcn Debian release, the instructions on eLinux.org apply. For the impatient or link challenged:
Once the image has booted, login via ssh with X11 forwarding enabled, or set an appropriate DISPLAY environment variable (pointing to an open remote X server) and run linuxcnc. Select the BeagleBone -> BeBoPr configuration, and follow along with the video if you are unfamiliar with the LinuxCNC Axis interface. If you don't have a BeBoPr board, you can still watch the step/dir lines toggle on an oscilloscope.
WARNING: While I have an analog input working and reading the thermistor, the temperature control logic is extremely crude. I do NOT recommend connecting your hot-end heater and trying to print unless you REALLY know what you are doing and are prepared to manually disconnect your hot-end if something goes wrong. Currently, the temperature logic is just trying to slave to an ADC value that is set in the BeBoPr.HAL file (but can be changed on the command line using halcmd or via a python HAL script if you know what you're doing). I expect to get the conversion to actual temperature and the various temperature M1xx codes working before long...stay tuned.
Close up of the BeagleBone Black / Linux 3.8 print from the video:
After spending some time struggling with the new Linux 3.8 kernel and device tree overlays, I now have a Linux 3.8 build working as well as the 3.2 build. Even better, I spent quite a bit of time setting up automated builds, and can now generate a customized Debian install that runs LinuxCNC "out of the box".
The images are named "machinekit", and they are built from scratch using a modified version of Robert C Nelson's omap-image-builder scripts. If you don't want to pull the build scripts and make your own image (warning: it takes quite a while), you can just download the pre-built image. Since my images are just tweaked versions of the rcn Debian release, the instructions on eLinux.org apply. For the impatient or link challenged:
wget http://www.machinekit.net/deb/rootfs/wheezy/debian-7.0.0-machinekit-armhf-2013-06-14.tar.xz tar xJf debian-7.0.0-machinekit-armhf-2013-06-14.tar.xz cd debian-7.0.0-machinekit-armhf-2013-06-14 sudo ./setup_sdcard.sh --mmc /dev/sdX --uboot bone_dtb Username: linuxcnc Password: linuxcnc md5sum debian-7.0.0-machinekit-armhf-2013-06-14.tar.xz 305aeda1edd4637ea4b284f9e982fdb9 debian-7.0.0-machinekit-armhf-2013-06-14.tar.xzWhen you first boot the image, be patient. It regenerates ssh host keys on the first boot and it will take a moment to become visible via ssh. Ideally, you should monitor for progress and errors via the serial port.
Once the image has booted, login via ssh with X11 forwarding enabled, or set an appropriate DISPLAY environment variable (pointing to an open remote X server) and run linuxcnc. Select the BeagleBone -> BeBoPr configuration, and follow along with the video if you are unfamiliar with the LinuxCNC Axis interface. If you don't have a BeBoPr board, you can still watch the step/dir lines toggle on an oscilloscope.
WARNING: While I have an analog input working and reading the thermistor, the temperature control logic is extremely crude. I do NOT recommend connecting your hot-end heater and trying to print unless you REALLY know what you are doing and are prepared to manually disconnect your hot-end if something goes wrong. Currently, the temperature logic is just trying to slave to an ADC value that is set in the BeBoPr.HAL file (but can be changed on the command line using halcmd or via a python HAL script if you know what you're doing). I expect to get the conversion to actual temperature and the various temperature M1xx codes working before long...stay tuned.
Close up of the BeagleBone Black / Linux 3.8 print from the video:
Monday, June 10, 2013
Black is White is Grey
Got a BeagleBone Black and a cape for the white that uses the eMMC signals?
Bas Laarhoven has verified a fix for turning your BBB into a BBW (or perhaps that's BeagleBone Grey?). Details are in the Google groups thread (scroll to the bottom for the fix), and summarized here:
If you want to completely mimic the original BeagleBone boot behavior, you need to swap four resistors on the 'Black, or otherwise set the proper boot mode via the LCD_DATA pins on P8. Details of what needs to be setup:
Oh, and if you're worried about wasting money on the on-board eMMC card, don't be. Even if you disable the eMMC card at boot time via the resistor mods it's not gone. You can still load a device tree overlay and start talking to it (assuming you don't have a conflicting cape plugged in). If you are leaving 'Black booting from the on-chip eMMC, just tweak uEnv.txt and pop out your SD card and you're back to full Black, booting from the on-board flash.
Bas Laarhoven has verified a fix for turning your BBB into a BBW (or perhaps that's BeagleBone Grey?). Details are in the Google groups thread (scroll to the bottom for the fix), and summarized here:
- Find the mmc2 section in the BeagleBone Black device tree and change
status = "okay"
-to-
status = "disabled" - Add "gpio set 52" to your uboot configuration to put the eMMC chip in reset at boot time
- Enable the eMMC hardware reset pin. This is a one-time configuration (it survives power cycles and cannot be changed once enabled) you can perform with either uboot or the mmc-utils program.
If you want to completely mimic the original BeagleBone boot behavior, you need to swap four resistors on the 'Black, or otherwise set the proper boot mode via the LCD_DATA pins on P8. Details of what needs to be setup:
- SYS_BOOT0 = 1: Move R95 to R70 or pull down LCD_DATA0 during reset
- SYS_BOOT1 = 1: Move R94 to R69 or pull down LCD_DATA1 during reset
- SYS_BOOT2 = 1: No change needed, leave R68 alone
- SYS_BOOT3 = 0: Move R67 to R92 or pull up LCD_DATA3 during reset
Oh, and if you're worried about wasting money on the on-board eMMC card, don't be. Even if you disable the eMMC card at boot time via the resistor mods it's not gone. You can still load a device tree overlay and start talking to it (assuming you don't have a conflicting cape plugged in). If you are leaving 'Black booting from the on-chip eMMC, just tweak uEnv.txt and pop out your SD card and you're back to full Black, booting from the on-board flash.
Subscribe to:
Posts (Atom)