Category — General Commentary

I’ve been going through my eclectic electric motor collection, and I’ve had a lot of problems finding accurate information on many of the motors.   I love manufacturers that still provide datasheets for out of production products, especially when they make it easy to find.

My Electro-Craft E-3618-E-F00AN motors are a great example; even using my best google-fu I couldn’t find any data online, just people trying to sell them or repair them.  I finally hit paydirt when I went looking for, and found, an old paper Electro-Craft catalog from 1993.  Sometimes having packrats around is good….

Do product names matter to technical folks?  I think they can be important in retail marketing (e.g. iPhone, Word, Windows), but to engineers?

A lot of companies still use numeric product names; for example, a Kollmorgen AKM21 servo motor, the ST STM32 MCU, etc.  Other companies prefer using words; for example, Copley Controls has the Accelnet, Xenus, and others.

However, I’ve noticed a trend towards using easily pronounceable words for product lines.   TI is a great example; everything used to have a number (TMS320C6201, TMS320F2401, etc), but now TI has OMAPs, Sitaras, Delfinos, Piccolos, Wolverines, and probably a few I’ve missed.   Of course, Intel changed over from “x86″ to Pentium, but I believe the original reason was because “86″ couldn’t be trademarked but Pentium could.

I don’t care either way; I guess it’s easier to say “Accelnet” instead of ADP-055-18, but it also conveys less information.

I’ve been doing some updates on my Trac site; it really needs a lot of updating, but I’m concentrating on improving and adding to the motor section (which ties into the XY Table series…which I will get back to real soon now).

I recently fixed some older compact computer keyboards: two Unicomp Mighty Mouse M keyboards with separate numeric keypads and a IBM/Lexmark SpaceSaver.  One keyboard had some keys that didn’t work at all, and the others had a couple that didn’t respond reliably.

All three keyboards are pretty similar.  They use a collapsing rubber dome to press together contacts laid out on two sheets of plastic separated by a plastic spacer.

I’m not going to give detailed steps, since other keyboards are probably a bit different, but here are my notes:

• I used Aqua’s Key Test which I found via Geekhack.org to test each key so I knew where to look for problems.  It’s very hard to test all the keys using a normal program like Notepad.
• I highly recommend taking plenty of pictures at each stage.  OK, I didn’t, but I had two other keyboards I could look at when putting everything  back together.
• I used CaiKote 44 to repair broken traces and re-coat unreliable contacts.  I paid ~$6 for the 1.0g jar at Fry’s.  It worked well, although it’s hard to apply precisely, especially using the included applicators, and worked best with a long time to dry (I let it dry for a day before re-testing the keyboard).  The jar looks small, but it does last: I was able to fix up all my keyboards, and a friend fixed a musical keyboard, without running out.
• I took all key caps off.  I think there’s a chance you could get the keyboard apart with the keys still on, but in any case, I needed to see how I could take everything apart and I wanted to clean the keyboar

Was it worth it?  Yes, because I like the size and feel of these keyboards, and you can’t buy either model today.

Overall, I’m still pretty happy with our Ooma system.  However, I have run into a few quirks:

• Apparently, this option can be changed, but Ooma won’t make the change anymore.
• However, everyone on the forums recommends totally splitting your lines: Ooma connected to Internet only, local phone line connected to a different phone.  You do get extra features for free this way, for example, caller ID.
• Ooma occasionally changes their web interface around.  For example, the connection tone option (Ooma plays a special sound when the connection is made) has been removed.

Some final Ooma notes:

The reality: there aren’t any automation trade shows in Silicon Valley.  Here are my ratings for the closest:

1. Semicon (July) has the most automated equipment (mostly wafer robots and back-end wire bonders) and vendors.  I’ve found some good new products at Semicon, but not many.  Heck, even most of the local automation distributors skip it, since the substantial exhibition costs outweigh the benefits.  I’ve skipped it the past few years.
2. Photonics West (January) has very little; typically there are a few data acquisition vendors and some lab automation oriented vendors.  Last time I went, there were a bunch of companies with serial or USB stepper motor packages with horrible, “intuitive” simple protocols.  Sometime I’ll write a rant about how I hate those; maybe it’s OK if you’re truly doing something simple and you’ve only used one brand, but I’ve used way too many different ones.
3. Embedded Systems Conference (April) typically has nothing directly related to factory automation, but I enjoy going because many of the underlying products are here, such as microcontrollers (MCUs), digital signal processors (DSPs), Field Programmable Gate Arrays (FPGAs), and Real Time Operating Systems (RTOS).

Pretty funny post over at Paul Rako’s Anablog on pranks, starring analog chip designers.

I like my Emprex CS561 59-in-1 USB card reader; it’s compact, reads almost everything (including SIM cards), and has a built-in USB plug.

But when I plug it into a Windows 7 64-bit system (I’ve tried 2 so far), Win7-64 thinks it is an eHome Infrared Receiver (USBCIR).  The solution:

1. Go to Device Manager and look under Universal Serial Bus Controllers for the “eHome Infrared Receiver”, right click on it, and select “Update Driver Software”.
2. Select “Browse my computer for driver software”, press Next.
3. Select “Let me pick from a list of device drivers on my computer”, press Next.
4. Win7-64 then comes up with a choice of “eHome Infrared Receiver” or “USB Composite Device”.
5. Pick “USB Composite Device”, let the drivers install, and you’re done.  It’s worked great for me twice.

Note that this only works for the standard memory slots; if you want to use the SIM card reader, you have to install the Emprex software.

Serial buses and networks such as Ethernet, CAN, USB, and Firewire are popular.   But you can’t just say “I need to transfer 1Mbps, therefore I can use CAN.”  You need to understand a bit about the physical layer and your chosen software layers before you can pick a bus that will work.

All serial buses have some protocol overhead, and software layers add even more.

I’ll take a quick look at CAN:

• CAN messages can carry between 8 and 64 bits of data.
• At 1Mbps, the maximum actual throughput is roughly 17543 messages/sec (1 byte data) to 8771 messages/sec (8 byte data) or 140,344 to 561344 bits per second of actual data.
• CAN does have many good features, like extremely fast arbitration (much faster and more predictable than CMSA/CD Ethernet), and producer/consumer messaging.
• So CAN is a good choice for a real time network that isn’t transferring a lot of data.  It’s even better if many nodes need to consumer data produced by one node (so the data is only sent once, unlike in a master/slave network where the master has to receive the data and then send it out again to each slave node).
• On the other hand, it’s not a good fit for a 1M sample/sec 16-bit ADC; high speed USB 2.0 or 100Mbps/1000Mbps Ethernet would be better choices.
• There’s also a cable length / speed trade off; as the bit rate increases, the maximum cable length (and branch length) decreases.
• The maximum number of messages gives an idea of what kind of update rates you can realistically see.  For example, a 100 node CAN network could handle a maximum of roughly 175 1-bytes messages or 88 8-byte messages per node per second.  So a 1 msec update rate for all nodes is impossible, but a 10 msec rate might be achievable.

Ethernet has its own set of considerations.  Just a few:

• Ethernet has significant protocol overhead, especially for small data sizes.  (Summation frame systems such as EtherCAT reduce this, but require non-standard hardware).
• If you’re using hubs, you have to take collisions into account.
• If you’re using switches, you have to consider the time the switches add.
• Ethernet and its typical protocols require a lot of resources; if your product uses an underpowered controller, even if it’s physically on 100BaseT, it might only be able to manage 1Mbps or less.
• For long distances, the time traveling between nodes can be significant.
• Higher level protocols such as TCP, ftp, NTFS, etc can add substantial delays and additional overhead along with their added features.

I’m not a USB expert, but I know USB 2.0 can’t deliver actual data at its advertised speed.

I’m not going to disclose any great plans for this blog.  There is so much I’d like to write about, but family and work are more important (especially during the Christmas season).

Another problem is that my posts almost always seem to grow.  I’m still slowly working on Assembling the PCB model for the Creating a 3D PCB Model with Eagle and Alibre, but a single post has mushroomed into 2 or 3 posts.  And I’ve decided I need to do more research, too.

I’m not interested in Twittering, Facebook, forums (been there, done that), and such.  With my limited time, I’d rather be working on unique content with depth that will last, not ephemeral tweets, even if I don’t post as often.

However, my New Year’s resolution for this blog still is:

• To post more often, with a goal of at least once a week.