Attached are photos of an electromagnetic linear actuator, taken from an old SyQuest EZ135 ejectable cartridge disk drive.  The actuator gives the cartridge its final kick out of the housing when the eject command or eject button on the drive is used. 

I have been unable to find anything on the web for this device (no power requirements or specifications on how to make it work).  Is anybody familiar with this type of device?  If so, how does one cause it to function?

I suspect it must be run like a stepper motor from a driver chip.  Any other guesses?

Any feedback will be appreciated.  I do have an L293D motor driver circuit that works for DC motors and stepper motors.  With the right parameters and specifications for programming, it should do the job.

I have a disk drive motor, NIDEC DLC-312, with a 5 lead connector.  I have contacted the vendor and the motor does not show up on their site and the vendor says the specs are proprietary and not available (come on, its from a 12 year old SyQuest EZ135 cartridge drive). 

Does anybody know anything about this motor or motors of this kind (from disk drives)?

Is there a decent documented way to test such motors to determine the configuration of their power and sense leads so they can be used with a driver shield?

Good topic.  This was my area of expertise when I worked on mainframe computers and distributed servers.  Interestingly enough, this is the big area of focus on the internet, collecting data about activity, then making use of that data for whatever (marketing, spying, theft, building dossiers, or, as the cover story goes, quality assurance metrics to improve upon your web experience).

Okay, back to Arduino data collection...

Indeed, I find myself in the middle of this with almost every project.  This would require a libray implementation, where a data collection can be instantiated, a few calls for adding data to the log, and controlling when the loggin occurs (start/stop, or criteria thereof). 

Results can be directed as pointed out, to a serial connection, for immediate display, though that would require some type of PC connection, transmission mode, perhaps an intermediate server, or non-computer display (such as those for home weather stations).  In fact, a home weather station, with an outdoor data module and indoor display module, seems to be a very nice model for this type of activity.  I have thought about getting a complete home weather station, and then building my own interface for acquiring the data, performing the analysis and visualization. 

One should also consider use of an attached SSD for data storage as an alternative to a real-time connection.  Keep in mind that in the limited memory space of the Arduino, data collection is indeed a luxury item.  Other micro-controller boards, such as the ARM based unit, would be better equipped for this type of activity.

I am puzzled as to why there is no official announcement for REV 3 of the UNO board.  Seems counter to the open source environment.

I see from AdaFruit that Radio Shack will be selling the Arduino UNO REV 3 board.   Does anybody know anything about this board?  Is there an announcement anywhere in this regard?  What is fixed?  What is new?  What is different?

I know the make, model and year of the car.  However, the component is used in 25 different cars covering 6-7 years (1999 to 2005, depending on the overlap between model years and year of production).  The ACDelco # and the GM # are more meaningful at this point.

I did search the web for auto repair manuals but all of them cost money (purchase of a physical or electronic copy, or one year subscription to a repair manual service).  For the sites that indicate they will provide free repair manuals, it generally boils down to search, search, search, curse, curse, curse, then repeat.  Nobody has posted any specific material for this component or even any discussion about problems with this component.  Its all a big secret, I guess.

Wiring diagram pinouts would be nice but not necessary.

The device in the subject line is a failed (or failing) steering column assembly that controls turn signals, cruise control, windshield wipers (& washer), high/low beam, and emergency flashers.  It has two cable connectors with a total of 29 pin outs.  ACDelco # D6280C or GM # 88963625 (made in Mexico).

I want to test out the pins and determine what type of Arduino programming is necessary to respond to this device.  I have searched for wiring diagrams but have not found them (apparently, one must be a registered or licensed tradesman/mechanic to access such material). 

Has anybody done this with other oddball devices?  How did you acquire wiring diagrams or pinouts?  I don't even know the voltage (probably 12 volts) or which wires are VCC and GND. 

One last update...

In attempting to use the new Arduino UNO SMD R2 device today, it once again FAILED to load a new sketch.  Ouch!  Reboot with the device plugged in also failed. 

On a whim, I connected it with the USB cable that I normally use for my older UNO.  It worked.

Then, I swapped out the USB cable that came with the SparkFun kit, and used one from my inventory.  It worked.  It appears that I got a bad USB cable with the SparkFun kit.

So, for now, I am up to Circuit 5, and progressing.

I moved my new UNO back to its intended USB connection and with a restart, both COM6 and COM7 are working as expected.

A reboot of Win7 did not eliminate the ghost device.

I have the expected devices, COM3 and COM4, with COM5 as a ghost device (have the same port/hub location as COM4).

I used USBDview in administrative mode, to uninstall COM5.  Unfortunately for me (or not), selecting uninstall for the ghost device uninstalled all Arduino devices, COM3 through COM5.

I rebooted, Win7 detected the Arduino connections, and now have only two devices, but called COM6 and COM7.  I don't understand that!  I read somewhere that there is a limit when you hit COM10, that the Arduino IDE can't handle it (feedback please).

But, no more ghost device and for some time now, that should be okay.  However, I worry about moving the new UNO back to its former USB port location.  What will that bring?

One observation worthy of note:  if you add an additional UNO to your USB ports (with one or more already connected), make sure all are connected, including the new one, and then do a power up boot.  That seems to be the cleanest way to have a new Arduino recognized.  However, the dynamic nature of USB connections and Arduino devices is such that I expect the COM numbers to routinely change over time. 

I also have the same UNO board (SMD R2) and had this issue.

I moved the device to a different USB port and it then worked.  My resolution may have been for a different problem (I have two UNOs) but you should try it (if not already done).

Search for USBDview (Google), and examine its output for clues as well. 

With regard to "can't talk to both", that was only partially correct.  I actually hit two different problems.  One was a message indicating COM4 was busy.  The other was that a sketch load would compile but then hang and not finish the uploading.  Firmata would also hang.

However, I have achieved some success.

Using the Sysinternals Process Explorer for Win7, I found a hung process, called AVR or AVRdude, that was terminated when the sketch upload was hung (even though the IDE was stopped successfully).  I believe this orphaned process was holding COM4 and later produced the subsequent message about COM4 being busy.

Next, I installed a program called USBDview.  This lists all the USB device connections.  I found a ghost device for the new UNO board (I will take steps to eliminate this ghost device).  Noting that the ghost device and the real device were on the SAME USB port and hub, I then plugged the new UNO board into a different physical USB port on the computer. 

That worked.  In USBDview, it now shows up at a different  port/hub.  I could talk to the device using Firmata_test.  In fact, I brought up 2 copies of Firmata_test, one to COM3 and one to COM4, and both function as expected.  I was able to load a sketch to the new UNO and the sketch ran properly. 

My first UNO board is an R2 version with the removable CPU chip.  This new UNO board is an SMD R2 version but it has updated firmware (0.01 versus 0.00, numbers reported by USBDview).  Who has information on that firmware update?  It might be hard to find since we have seen little about the R2 revision itself.

Lastly, I need to get rid of that ghost device.  I will try rebooting Win7, and failing that, USBDview has an option to remove entries.

I had been happily using my first UNO board, and then added a 2nd board (Win7, 32-bit, Arduino-0022 IDE).

The 1st UNO always showed up as COM3 and worked fine.

Plugging in the 2nd UNO brought it on as COM4 when both are plugged in.  No device found dialogs, no driver installs (all on board already).

Plugging in each alone to the same USB cable, I am able to talks to each, upload and use a sketch.

Plugging in both, one connecting as COM3, the other as COM4, always generates the message that COM4 is busy when I try to upload to COM4 (COM3 does okay).

I thought I saw this discussion several months ago but could not find the relevant entry (if it exists).  Any suggestions on being able to use both UNO boards concurrently connected to separate USB cables?

My bad.  I posted on the wrong board.  I meant to go to Processing.org.

Please ignore.

There are errors in Processing that cause output to be placed off location.  Run this example:

boolean sw = true;

void setup() {
  size(480,480);
}

void draw() {
  fill(0);
  textSize(24);
  text("Draw this message repeatedly", 10, 30);
  if (sw) text("Draw this message once", 10, 60);
  sw = false;
  noLoop();  // remove or comment out after first run
}

The on screen text in the repeated message degrades as the pixels start to mush out around the target area.  It also happens when the background and fill values are changed. 

Is this a bug?  How does one put text on the screen that doesn't turn to mush with repeated calls to draw()?