Ansible variables

Been doing some abstraction refactoring for work and ran into a situation where I had a task that used the command module in a loop and I needed to be able to use the stdout value in a template later on. My first thought was to use dynamic variables (e.g., register: {{ item.foo }}_output) but Ansible treats the variable name as a literal string for both register and add_fact so that was an utter failure. After much doc trawling and searching, I used the debug module to dump the variable registered and found it was a gnarly (and deeply nested) dataset consisting of a dictionary of with both lists and more dictionaries of lists. The upside is that nearly all the data about the task is there, including the items used in the loop as well as the results I needed.

The task (cleaned up a bit):

- name: record git revision of repositories
local_action:
command git rev-parse HEAD
chdir="{{ foo }}"
with_items:
- "{{ service_modules }}"
sudo: no
register: repo_checkouts

The relevant portion of the template:

{% for checkouts in repo_checkouts.results %}
Repository: {{ checkouts.item.git_location }}
Targeted Branch/Tag/Commit: {{ checkouts.item.git_reference }}
Actual Revision: {{ checkouts.stdout }}

Note that the repo_checkouts.results includes a dictionary in each list named ‘item’ that includes all the info passed via with_items, and stdout is the output from the command. Each list also includes a ‘cmd’ dict with the input to the command module, an ‘invocation’ dict with the module and params details, and various other details like return code and time stamps.

Mendel90 Marlin

For those looking to run a recent version of Marlin on a Mendel90 from nophead, I track upstream in my own branches on GitHub. There are two versions; one for running with the Panelolu2 LCD and the other without.

A few gotchas to be aware of:

  • The Melzi drivers are included from nophead, they’re in ArduinoAddons/Arduino_1.x.x/Melzi and must be copied into your sketchbook/hardware/ folder or you will have issues with carriage movement.
  • If you’re using the LCD branch you must have the Panelolu2 attached or it will hang at start. There’s some patches floating around that might fix this but I haven’t tested yet. If you remove the LCD make sure you disable the panel in Configuration.h.
  • The LCD requires a recent checkout of the LiquidTWI2 libraries in your sketchbook/libraries/ directory.

The README for each of my branches details other changes/features and I’ll keep em updated as I make changes.

3D Printing Tips

Just a few things I’ve learned over the past few weeks:

  1. Travel rate matters – On both my Prusa I3 and Mendel90 I had the non-print travel rate ratched up to 250mm/s and thought I was okay since it didn’t miss steps. However, it made for odd artifacting and layers not properly lining up due to the momentum of the extruder body (especially bad on the mendel, it’s a heavy beast). Shaving it back to 150mm/s on the Mendel90 and 175mm/s on the Prusa made for a HUGE improvement in finish quality.
  2. Firmware retraction is nice – Newer versions of Marlin allow controlling retraction/recovery via firmware (using G10/G11 g-codes) and Slic3r has an option to use it over it’s normal g-code generation. Just started playing with it so we’ll see how it does quality-wise, but being able to control via M207/M208 during a print makes for much better fine tuning than the old slice/print/repeat route.
  3. Ambient temp matters a LOT – At least for first layer adhesion with PLA. The two most important factors in my experience for proper first layer adhesion are proper Z height calibration (most critical) and temperature. It’s gotta be hot enough for the first layer to stick and then drop below PLA glass transition temp so it hardens and holds properly. The trick is that with higher ambient temperatures the time for that drop takes a bit longer, it can stay pliable a bit too long. I’ve found printing the first layer at 75C and then dropping to 60C seems to work well, but I’ll be interested to see if that holds as the weather warms.

Mendel90 Build

(My name is Matt S., and I’m a practicing 3D printing addict)

My adventures with the MakerFarm I3 has taught me quite a lot, but it’s very much of a learning tool and I’ve ended up spending as much time upgrading/tweaking/breaking as printing with it.  The rest of the family hasn’t ended up with nearly as much printing time as they would like so I went looking for a solid kit that would be much closer to user-friendly.  I’ll get into more of the specifics around the decision in another post, but I found that in the reprap world the Mendel90 is arguably the most solid of the bunch. I also managed to get Jake interested in 3D printing so we decided to each order a kit and do a mini group build.

Ordering was a breeze, a few emails back and forth with Chris’ SO got us the cost and shipping details sorted. The kits shipped the day after we PayPal’d over the funds and the kits showed up a few days later. Amazingly enough it took less time for UPS to ship the kits from the UK than it does for average ground from the West Coast. Unfortunately that also meant the kits were going to be sitting in my living room taunting me for a little over a week before we started the build…

The kits themselves were an impressive bit of work. They include everything but a few tools and the power supply (tho UK kits include the PS) and are extremely well thought out. The personalized cover letter in each was a nice touch, as was the micro SD card (with USB adapter) that had all the firmware, Chris’ customized version of Skeinforge, and an already sliced android test print. There was also a sample of some green PLA from faberdashery to use once the build was complete. Really quite top-notch.

The build took us roughly 20 or so hours to complete. The PDF manual was an absolute joy to follow, extremely detailed and generally easy to follow. The only real issues were once we got to wiring the power supply, but those were mostly due to my own inexperience and paranoia rather than the instructions. We ended up using the 12v and ground wires from the ATX and CPU connectors for power which gave a nice solid 12v input, and simply wiring the PSON/sense to ground rather than using the resistor.

Initial calibration was a challenge for me, not so much due to difficulty level but because it was very different from what I was used to. The printer uses positive/negative values for X/Y instead of 0-$MAX like the other printers I’ve used. The biggest difference was in calibrating the Z axis since it homes to MAX (printer top) so calibration requires measuring and updating firmware to get a proper 0 position. Once done tho it very rarely should need to be tweaked if the printer is stationary and so far it’s proved to be very accurate.

In the two weeks since the build was done, we’ve been getting extremely impressive prints. It took less than a week to get it dialed in and the prints have been extremely consistent. The printer is significantly louder than our I3 (moving along Z is the worst offender) but not overwhelmingly so. The noise is mostly due to the design and use of a metal panel frame rather than the wood used in the I3.

I would absolutely recommend this kit for anyone looking to do a build. The instructions and kit were great and the support from Chris, Mary, and the community have been excellent.

Build album.

Adventures in CEC

Our trusty Harmony 880 has decided to start a somewhat rapid plunge into non-usefulness, started with the light no longer coming on when picked up and buttons are taking progressively more pressure to register. Gotten some good years from this remote and generally good experiences from the Harmony line, but with CEC becoming more prevalent I decided to see if I could forego buying another expensive remote and instead use a “standard” route. It almost, kinda works.

First thing is that all of my hardware is at least a few years old, with the TV being a 2009 model. LG and Onkyo have their own branded CEC implementations (Simplink and RIHD respectively), and neither of em are complete. For XBMC, I used the Pulse Eight USB-CEC adapter which plugs in to both the USB port on the PC as well as inline on the HDMI output.

Hardware in play:

  • TV – LG 42LH40
  • Receiver – Onkyo TX-SR608
  • XBMC – Acer Revo 3700
  • Gaming/Streaming Video – PS3

The Good:

  • XBMC is seen by and talks to both my TV and receiver without issue.
  • I can control the volume on my receiver from XBMC (meaning I can use Yatse on my Android devices).
  • Powering XBMC on and resuming from suspend (WOL FTW!) turns the receiver and TV on. Same for the PS3.
  • Powering off the TV turns everything else off.
  • Everything can be controlled from my Onkyo remote, XBMC and PS3 via CEC commands.

The Bad:

  • Powering XBMC, PS3, or Receiver down doesn’t turn off the TV. Saw some reports that LG doesn’t (didn’t?) implement the power off function.
  • XBMC control via CEC is somewhat limited, the Onkyo remote implements all the basics and a few extras for a total of roughly 28 commands (including numbers). Not really bad for a universal type remote, but the Harmony has me spoiled here.
  • Related to above, since the Onkyo remote is universal, the button labels don’t always make much sense. Confusing setup is confusing.

The Ugly:

  • Receiver can’t control the TV via CEC at all. Had to find the proper code for the remote to send IR commands instead. Bad interop!

So the usage for controlling everything is much more of a process to be learned. To power everything up with a single button, you have to hit the relevant device button on the Onkyo remote and then the power button. To turn everything off, you have to hit the TV button followed by the power button. When switching inputs, you have to remember to turn off the device you’re no longer watching. Contrast this with using the Harmony route which is a single button push to do any of the above tasks. Adding CEC into the mix does bring some added remote XBMC control features I’ve been wanting, but I can’t see using it as the primary way to manage these devices.

The process has been pretty frustrating to try to sort through overall. My takeaway is that while CEC is an option, vendors tweaking or only partially implementing it can really kill the overall usefulness. I’ll certainly be taking this experience into account whenever I end up purchasing replacement kit and hopefully will find solid hardware with proper standards support.