Monthly Archives: January 2019

New product: Tic T249 USB Multi-Interface Stepper Motor Controller

via Pololu Blog

I am excited to announce the release of the Tic T249 USB Multi-Interface Stepper Motor Controller, the fourth model in our line of Tic Stepper Motor Controllers. The Tic T249, which is based on the TB67S249FTG IC from Toshiba, features a broad 10 V to 47 V operating range and can deliver up to approximately 1.8 A per phase without a heat sink or forced air flow, making it our highest-power Tic yet. In addition to the array of high-level features offered by the other members of our Tic family, the Tic T249 offers access to several innovative features of the TB67S249FTG driver.

One of the most exciting new features is Toshiba’s Active Gain Control (AGC), which automatically reduces the stepper motor current below the set limit based on the actual load on the motor, allowing for reduced unnecessary heat generation and higher peak power when the motor actually needs it. The driver also incorporates Toshiba’s Advanced Dynamic Mixed Decay (ADMD) technology, which dynamically switches between slow and fast decay modes based on the actual motor current, providing higher efficiency and smoother steps at high speed than you get with traditional timing-based mixed decay.

The AGC has several configuration options, and our Tic Control Center software makes it easy to configure over USB:

The “Input and motor settings” tab for a Tic T249.

Like the other members of the Tic family, the T249 makes basic speed or position control of a stepper motor easy, with lots of configurable parameters (e.g. max speed and acceleration) and support for six high-level control interfaces:

  • USB for direct connection to a computer
  • TTL serial operating at 5 V for use with a microcontroller
  • I²C for use with a microcontroller
  • RC hobby servo pulses for use in an RC system
  • Analog voltage for use with a potentiometer or analog joystick
  • Quadrature encoder input for use with a rotary encoder dial, allowing full rotation without limits (not for position feedback)

This video gives a brief demonstration of these interfaces in action:


The Tic T249 is available with connectors soldered in or without connectors soldered in. If you do not need the high-level interfaces provided by the Tic and want to control Toshiba’s stepper driver directly, we also offer stepper motor driver carriers for the TB67S249FTG and TB67S279FTG.

Here is a handy comparison chart with all four Tic stepper motor controllers:


Tic T500

Tic T834

Tic T825

Tic T249
Operating voltage range: 4.5 V to 35 V(1) 2.5 V to 10.8 V 8.5 V to 45 V(1) 10 V to 47 V(1)
Max continuous current per phase
(no additional cooling):
1.5 A 1.5 A 1.5 A 1.8 A
Peak current per phase
(additional cooling required):
2.5 A 2 A 2.5 A 4.5 A
Microstep resolutions: full
half
1/4
1/8
full
half
1/4
1/8
1/16
1/32
full
half
1/4
1/8
1/16
1/32
full
half
1/4
1/8
1/16
1/32
Automatic decay selection: Yes Yes
Automatic gain control (AGC): Yes
Driver IC: MP6500 DRV8834 DRV8825 TB67S249FTG
Price (connectors not soldered): $19.95 $29.95 $29.95 $39.95
Price (connectors soldered): $21.95 $31.95 $31.95 $41.95

1 See product pages and user’s guide for operating voltage limitations.

New firmware features

The Tic T249 also has updated firmware (version 1.06) that includes several new features (which are available to the rest of the Tic family as well).

Example pin configuration for a Tic with limit switches.

By popular demand, this new firmware adds support for limit switches: any of the Tic control pins (SCL, SDA, TX, RX, or RC) can be configured as a digital input for a forward or reverse limit switch. When the limit switch is active, the Tic abruptly shuts down any movement in the specified direction, but allows the motor to move in the other direction. You can use limit switches to help prevent your system from leaving its desired range of motion.

If you configure a limit switch, you can use the Tic’s new homing procedure. The new “Go home” command, which is available over serial, I²C, and USB, starts the homing procedure. The Tic will start moving in the direction specified by the command until it hits a limit switch for that direction. Then it will change directions, move until the limit switch deactivates, and set its current position to 0. The stepping speeds used by the Tic during the homing procedure are configurable.

You can also use the homing feature automatically, without sending a command. If automatic homing is enabled, the Tic performs the homing procedure whenever it is being commanded to go to a specific position but it is uncertain of its current position (e.g. immediately after motor power is applied). This feature is intended to be used in the “RC position”, “Analog position”, and “Encoder position” control modes.

The new firmware also adds several features to the Tic’s TTL serial interface that make it more usable in systems with large numbers of Tics and in half-duplex serial buses. Specifically, it adds support for an alternative device number so any Tic can optionally be addressed by two different device numbers. It adds an option to enable 14-bit device numbers so you can have more than 128 Tics on a serial bus. The Tic now has an option to encode its serial responses using only bytes between 0 and 0x7F, which can be useful in setups where the serial response from one Tic will be seen by other Tic devices, and you don’t want it to be misinterpreted as a command. We also implemented several changes to make the Tic less susceptible to noise on the serial lines, and you can now enable CRC bytes for serial responses sent by the Tic so that you can confirm the data you received matches what the Tic sent.

Introductory special

As usual, we are offering an extra introductory special discount on the Tic T249, to help share in our celebration of releasing a new product. The first hundred customers to use coupon code T249INTRO can get up to three units for just $19.95! And we’ll even cover the shipping in the US!

Enginursday: Motion-Controlled, Wearable LED Dance Harness

via SparkFun: Commerce Blog

I’m pretty ambitious whenever I get inspired to do a project – after research and testing, I consider the time constraints and how much experience I have doing whatever I’m interested in doing. I then usually take a step back and dial it down to something a bit more manageable. Instead of tackling the whole project all at once, I break it down and complete it in small chunks. This was the case after being inspired by some dancers using EL wire for their performance. In 2014, I started drawing out plans to build some light up costumes for my students at the old SparkFun building. I thought it would be cool and fun for them.

If you remember from my Enginursday post last year, I shared two designs that I used with my students. The first design used EL tape and panels. The second design used non-addressable LED strips.

Mark I: EL Dance Shirt Mark II: LED Dance Harness

Mark III: Motion Controlled Wearable LED Dance Harness

It would have been a shame to not reuse the parts that I spent so much time building for seven students. Instead of designing a new costume, I decided to focus my energy on a small upgrade at their 2016 spring performance with Streetside Studios. For Mark III, I mixed different colors and replaced the custom power adapter with a motion controller. The motion controller used an ADXL335 triple axis analog accelerometer, transistor, and Arduino Pro Mini to switch the LEDs between patterns. It was simple and easy to use. Here’s a quick demo of it in action with one of my bboys.

Motion Controlled Wearable LED Dance Harness in Action

How Do You Build Such a Thing?

Assuming that you have already prepared the LEDs and harness tailored to your size, check out the tutorial linked below for more details on making your very own motion-controlled wearable LED dance harness! Oh and don't be scared of the numbers that I provided for calibrating all eight sensors; they’re pretty interesting in my opinion.

Motion Controlled Wearable LED Dance Harness

Have you ever added an accelerometer or IMU to a wearable project involving dance or movement? Let us know your thoughts below in the comments. Tune in sometime in the future when I show you Mark IV. I’ll need a bit more time to explain what I did for the next version. ;D

comments | comment feed

Name that Ware January 2019

via Hacking – bunnie's blog

The Ware for January 2019 is shown below.

Thanks to Jesse for contributing this handsome retro-ware.

This one should be a cakewalk — I did not blur out the part numbers because I felt like by the time I finished obscuring the ware there wouldn’t be much left for guessing! Instead, I’m just appreciating a retro-ware for what it is — a reminder of a time when not everything could be done in software, and we had to rely on special purpose chips to do even the simplest of things.

I also included a picture of the back side of the board because it illustrates a common problem seen in PCBs from the 80’s — namely, what happens when soldermask is applied directly over tin/lead plating. Tin/lead can be used as an etching barrier; conveniently, once the etch is done, the tin/lead plating doubles as the solderable finish for the PCB. So, if you scrape back the soldermask of the older PCBs like this, you won’t immediately find bare copper: you’ll first encounter a layer of tin/lead plating.

Unfortunately, when the PCB is subject to reflow temperatures (and particularly wave soldering), the entire tin/lead layer liquifies, and excess solder from the pads will flow under the soldermask, creating the wrinkling, ripples and bumps seen under the larger traces.

Modern PCBs still use a tin mask as an etch barrier, but the tin is stripped off entirely before the soldermask is applied (hence the term “SMOBC”, or soldermask on bare copper), and then solder is re-applied to all the pads using a HASL (hot air solder leveling) process (or ENIG, OSP, or whatever finish is required). Seems like a lot of work to apply a finish only to strip it off, but bare copper won’t allow solder to seep underneath the soldermask, so it’s worth it.

Winner, Name that Ware December 2018

via Hacking – bunnie's blog

The ware for December 2018 is from a 454 Sequencer. The direction of flow is actually from a single input port, splitting into two separate ports, each driven by independent peristaltic pumps downstream of the splitter. The four black boxes are customized Introtek “IntroFlow” ultrasonic non-invasive flow detectors. It’s interesting to see that many readers assumed the flow went in the combining direction, not the splitting direction.

I originally thought the ware was a simple flow splitter because the machine had a single reagent cartridge, and reagents are expensive so if they needed reagents in two spots it would be worth it to include a mechanism for splitting and measuring the flow. But after reading Stuart’s comment, I think he’s probably right, it’s a bubble trap. When I removed the device from the machine, I hadn’t quite traced the pipes back far enough — the inlet goes to a valve that looks like it can either select from a set of reagent sources, or a port that is labeled “air out”. So congrats to Stuart, email me for your prize!

Rover team from IIT Madras places first in Indian Rover Challenge

via Pololu Blog

Congratulations to Team Anveshak from IIT Madras, who took first place at the 2019 Indian Rover Challenge! The IRC is a robotics and space exploration-based competition for college students. Participating teams design and build a Martian rover prototype and use that rover to compete in various tasks like obtaining soil samples, operating electrical racks, and picking up and delivering objects.

Team Anveshak’s winning rover, Caesar, uses 10 different Pololu products! We are especially excited to hear that their rover prominently features our newer G2 High-Power Motor Driver 24v13 and TB9051FTG motor drivers, using 9 of each of those boards.

We love seeing all the awesome things like this that people are doing with our products! For a more complete list of the Pololu parts used in Caesar, check out the related products listed below. If you want to learn more about the team, check out their website.

8 March 2019 Update: See a video of Caesar in action here.

More Python with the SparkFun LumiDrive!

via SparkFun: Commerce Blog

Last week, we started poking at SparkFun’s new LumiDrive LED Driver and played a little with the available digital pins broken out on the board. This week, we’ll take a look at the analog pins, play with them as inputs, and see if we can put something together using both digital and analog pins.

If you didn’t catch its release, let me introduce you to the SparkFun LuMini LED Driver. This board boasts a SAMD21G-AU microcontroller, to allow you to run Python, micropython, circuitpython, etc.

LumiDrive

The SparkFun LumiDrive LED Driver. So powerful. So elegant. So red.

Let’s dig into analog input on the LumiDrive. The first thing we need to do is import the proper library. So just as we imported the digitalio library to read and control things connected to the digital pins, this time we’ll need to import the analogio library.

import analogio

# Then we impliment it with this line

analog_in = analogio.AnalogIn(board.A3)

There is another way to do this, which I didn’t discuss last week. Unlike programming in Arduino, with Python (or microPython, or circuitPython) you don’t need to import the entire library. If you are only using a single element from that library, it is also possible to do this:

from analogio import AnalogIn

# Now our sketch knows where AnalogIn came from, so
# we don't need to instruct it where to look. We can just use

analog_in = AnalogIn(board.A3)

High value potentiometers

If you’re coming from the world of Arduino (or C), you would expect the analog value coming in from your potentiometer to be somewhere in the 0-1023 range – and you would be correct. However, things are a little different here. Your analog reading will fall within the range of 0-65535 (assuming 16-bit), so there’s a much higher resolution.

Let’s say we just want to see what value our trim pot is returning. Well first, of course, we need to attach our potentiometer. The hookup to the LumiDrive is simple, and just as you would expect. The outside legs of your potentiometer go to 3.3V and GND, with your center leg going to an analog pin. In this case I’m using A3.

Breadboard setup

Adding digital inputs to D8 and D9, and an analog input to A3

The pin.value call will return the raw data from your potentiometer, so with a simple sketch, we can see what our potentiometer is telling us.

import time
import board
import analogio

analog_in = analogio.AnalogIn(board.A3)

# Just read pin value
def get_pin_value(pin):
    return pin.value

while True:
    print (get_pin_value(analog_in))

time.sleep(0.05)    

Once you’ve saved that sketch to your LumiDrive (as main.py or code.py), you can open up a serial terminal and you should see something like this.

Analog Read

Returned analog values from our potentiometer

Note! Even though Mu has its own serial window, the LumiDrive is not yet recognized by it, and will tell you something like:

Could not find an attached device.

Make sure the device is plugged into this computer.

Blah blah blah other important things.

For the time being, I'm simply using TeraTerm. You should have no problems with TeraTerm, CoolTerm or whatever your favorite terminal program happens to be.

Now you probably notice that the value never gets all the way down to zero. With a resolution of 65535 across its rotation, and the little bit of float, that is to be expected. There are ways to eliminate that, but that’s an issue for a whole different post.

Variations

A potentiometer is a means to an end. That is, the values returned from a potentiometer are generally not as exciting as what we do with those values. Let’s consider a few ideas.

Suppose we want to know the voltage going through our potentiometer. Since we’re on a 3.3V setup, we’ll want to take the returned value from our pot, multiply it by 3.3, and then divide it by the full range of our potentiometer. So it’s not just a stream of numbers flying by, let’s tell the casual observer what we’re showing them. Try this.

import time
import board
import analogio

analog_in = analogio.AnalogIn(board.A3)

# Read pin value, calculate voltage on a 3.3V circuit
def get_voltage(pin):
    return (pin.value * 3.3) / 65535

while True:
    print ("Voltage is ", (get_voltage(analog_in)))

time.sleep(0.05)    

Notice that to print a string and a variable together, you just need to add a comma between the two. Now what if instead of voltage, you want to change your RGB values? Just like with the voltage indicator, you simply need to multiply the pin value by the number of your desired range - in this case 256 - and then divide it by the potentiometer’s resolution, 65535.

import time
import board
import analogio

analog_in = analogio.AnalogIn(board.A3)

# Map pin value to a scale of 0-255
def get_color(pin):
    return (pin.value * 256) / 65535

while True:
    print ("Color value is ", (get_color(analog_in)))

time.sleep(0.05)

Floating

Returning a value in the range of 0-255. But come on, your LED isn’t interested in (0, 255, 87.6239).

Of course, this gives us a float, when we really just want an integer. There are a few different ways to do this, and if you have a favorite, or you think my way is terrible, please let me know! For this example, I’m going to use the truncate command from the math library. Remember, we can either import the entire math library, of just the part we need.

import time
import board
import analogio
from math import trunc

analog_in = analogio.AnalogIn(board.A3)

# Map pin value to a scale of 0-255
def get_color(pin):  # Returning only integers this time
    return trunc((pin.value * 256) / 65535 ) #If we used 'import math', this would need to be return math.trunc()

while True:
    print ("Color value is ", (get_color(analog_in)))

time.sleep(0.05)

Integer

Ah, now that’s more like it. Integers as far as the eye can see.

Off the screen and into the wild

We’ve only seen our values returned to us in our serial terminal window. Let’s try to make something happen that doesn’t need a computer screen to show results.

With our three digital inputs from last week, and our analog input from this week, let’s try this. Since I just added components to last week’s breadboard, I still have a yellow momentary button on D8, and a green momentary button on D9, and I’m just adding a potentiometer on A3. We’ll use D6 as well, since it’s there. I want to create a circuit that does the following:

If I push the green button, the LuMini 2-inch ring lights up green; push the yellow button, and the ring lights up yellow; push the on-board button, and the ring will light up red. I’m pretty sure that’s close to what we did last week. But I also want it to blink, and I want to be able to control the speed of the blink with my potentiometer. Let’s try this:

import adafruit_dotstar # The LED library
import math
import time
import board
import digitalio
import analogio

# Setting up the board's blue stat LED to blink
led = digitalio.DigitalInOut(board.D13)
led.direction = digitalio.Direction.OUTPUT

analog_in = analogio.AnalogIn(board.A3)

#Setting up the board's onboard button
button6 = digitalio.DigitalInOut(board.D6)
button6.direction = digitalio.Direction.INPUT
button6.pull = digitalio.Pull.UP

# Setting up the digital IO pins as input buttons
button8 = digitalio.DigitalInOut(board.D8)
button8.direction = digitalio.Direction.INPUT
button8.pull = digitalio.Pull.UP

button9 = digitalio.DigitalInOut(board.D9)
button9.direction = digitalio.Direction.INPUT
button9.pull = digitalio.Pull.UP


# These two variables should be adjusted to reflect the number of LEDs you have
# and how bright you want them.
num_pixels = 40 #The 3" ring has 60, the 2" ring has 40, the 1" ring has 20
brightness = 0.25 #Set between 0.0 and 1.0, but suggest never running at full brightness


# Some standard colors.
BLACK = (0, 0, 0)
RED = (255, 0, 0)
YELLOW = (255, 150, 0)
ORANGE = (255, 40, 0)
GREEN = (0, 255, 0)
TEAL = (0, 255, 120)
CYAN = (0, 255, 255)
BLUE = (0, 0, 255)
PURPLE = (180, 0, 255)
MAGENTA = (255, 0, 20)
WHITE = (255, 255, 255)

# This creates the instance of the DoTStar library.
pixels = adafruit_dotstar.DotStar(board.SCK, board.MOSI,
    num_pixels, brightness= brightness, auto_write=False)

# This function takes a color and a delay and fills the entire strand with that color.
# The delay is given in the case you use multiple color fills in a row.
def color_fill(color, wait):
    pixels.fill(color)
    pixels.show()
    time.sleep(wait)

# Here's where the action happens
while True:
    if not button8.value:
        led.value = True
        color_fill(YELLOW,0)
    elif not button9.value:
        led.value = True
        color_fill(GREEN,0)
    elif not button6.value:
        led.value = False
        color_fill(RED,0)
    else:
        led.value = False
        color_fill(BLACK,0)

    time.sleep((analog_in.value * 2) / 65535) #delay is determined by potentiometer reading

    color_fill(BLACK, 0)

    time.sleep((analog_in.value * 2) / 65535) #delay is determined by potentiometer reading

You’ll notice a couple of things in this last example. The first is that while we defined functions to get our analog values in all of the previous examples, we did not in this one. To read our time.sleep variable, we read the analog_in.value within our while True loop. I did this because Python can’t convert a function to a float, and the time.sleep call expects a float as its argument. Second, in getting the value for our time.sleep, I’ve multiplied our analog_in value by two before dividing it by 65535. This sets our maximum sleep time at two seconds, just like multiplying by 3.3 in the earlier example gave us our voltage range.

Wait, there’s more!

But not this week. Again, this is mostly geared toward those among us (myself included) who haven’t done much Python programming as it applies to the physical world. I’m sure there are better or more efficient ways to do exactly what I’ve just done, and since as long as I’m still breathing, I’m still learning, I’d love to see your suggestions and improvements in the comments.

I also recall saying last week that if all went well, I would try to use all of this in some sort of practical application or project. Well, things went well, but not quite that well. I have a head full of ideas as to how to use all of this in a build, but this week there just wasn’t enough time, so that will be a post for another day.

comments | comment feed