Wiring up a Super Vexta Stepper Driver

Backstory: I'm retrofitting an old 35mm motion picture scanner (mid-late 1990s) with an LED light source and modern 4k Cameralink-based sensor. I've done a fair bit of programming, but this is my first project involving hardware/software interaction. The basic plan is to use one or more arduino boards in between my software (via serial control) and the scanner, to drive the film transport motors as well as the motors for focus, camera positioning, etc. All of the mechanical elements are already there, I basically just have to get it hooked up and moving in the right way. There are a ton of stepper motors in the unit. Most are controlled by a proprietary backplane/Vexta driver card setup. Two of them are controlled by these standalone drivers: Serious stepper motor drivers | They may or may not be usefu… | Flickr

I want to re-use these two drivers to control the two sprocket drive stepper motors in the scanner. My goal for this weekend is to get one of these working under Arduino control, through the Vexta driver, moving forward and backward the correct distance for one frame of film. I've barely scratched the surface with Arduino, but I think I get the gist of it, having done the first 5 or 6 tutorials in the starter kit.

My questions are:

  1. I'm not really sure how I'm supposed to connect it to the arduino. I'm guessing that "CW" and "CCW" are Clockwise and Counterclockwise, but what pins do I need to connect to from the Arduino?

  2. Once connected, what exactly do I need to write to those pins?

  3. Is it possible to use one driver to control two motors simultaneously to do the same thing? I'm thinking the two sprocket drive motors should move in tandem, so if I can just put both on the same driver, will that just work automatically?

Ideas? Has anyone used one of these drivers with an arduino?

Thanks!

You need to post a link to the specifications for the drivers if you want any useful advice. Photos don't tell us anything.

My guess is any of the Arduino pins (apart from 0,1) will do. But you need software that is compatible with the pins you choose.

...R

Have a look at this PDF file especially around pages 20 -. It can be driven either by CW/ CCW or by Pulse/Direction by way of a switch. What you would want is Pulse(Step) /Direction.

They use optoisolatars and it looks like they can be driven with no external resistor by the arduinos 5volts output pins.

The stepper driver examples in the IDE use 4 pins to drive the coils but what you want are just a 2 pin driver for step and direction. Just use 2 pins in the setup and the library driver will output it that way. Don't remember if it's Step/Dir or Dir/Step . If it doesn't seem to work just swap the pins.

Since the signals are isolated you do not need to hookup a ground to do this test.

Pete

24M006.pdf (485 KB)

Cool - thanks!

I had downloaded that manual, but was a little confused by what it all meant, and I wasn't sure if it was the right one.

I'm going to play with this tomorrow!

Where are you located?

At one time I started to work on a similar project for a guy in Hollywood who did sound editing and effects.

Went up there to see how some of it was done. The way it had been done for ages was the way he was used to doing it. Sound put on the same size of film and it would be cut and spliced and timing info marked on it.

After taking a tour of the place and seeing how they had built a huge room full of computers to do the sound and sound effects I kinda saw that the project was kind of outdated.

We're on the East Coast, but the scanner we're modifying came from LA a couple weeks ago.

The double-system sound method you describe was the norm for decades, and didn't start to go away until computer-based editing came in in the early 90's. But the hardware and software was so expensive to do things digitally (especially the cost of transfers to digital from film), that a lot of people stuck with the old ways until the last 5-10 years. At this stage it's pretty impractical to a fully photochemical process though - most processing labs are closed, and those that remain open are doing hybrid film/digital workflows rather than all film workflows (they process, but the intention is to scan the film and do everything else digitally, rather than making photochemical prints). We specialize in digital restoration of film and do archival work, but there are a lot of folks still shooting new material on film, including Super 8 and 16mm (there's even a really cool new camera in development for Super 8 from a company in Denmark, shipping this year. They're doing a nice job of blending new tech with an old format - http://www.logmar.dk - we scanned the sample footage on their website that was shot in Hamburg, Germany. If you can believe it, that came from a negative smaller than your pinky fingernail!).

We do a lot of 8mm and 16mm scanning right now on a very high end, very expensive scanner, but have had some call for 35mm lately. Not enough to justify the $250k it costs to buy a new 4k scanner, but enough to justify this summer project. So my goal is to have it all working in a couple months. Once the motors are doing what we want, it's mostly a software problem, and I'm pretty optimistic this is going to succeed. What I've seen so far in playing with my little Arduino Uno is really impressive, and I think starting from an existing platform like this (the 90's era scanner) makes the whole thing easier - there's basically no mechanical engineering to be done, just swapping control of the motors from proprietary hardware and software to the arduino and our software, and installing a new camera and light source.

It won't be a fast scanner, but it should be very high quality.

Hi, you ask if the two sprocket motors can be driven from the same driver, how are they driven at the moment, do you have a circuit of the unit?
If not can you see how they are connected, I'd do a mud map of the system before doing any mods, and lots of pictures of the wiring and mechanics.

Tom....... :slight_smile:

Hi Tom,

The original motors were wired to separate drivers. In addition to the two standalone drivers in my original post, there's this rack unit that was installed in the back of the machine. It had a backplane made by the scanner manufacturer, and contained slots for 8 separate motor drivers (the original design of the scanner was based on a line array, rather than an area sensor, so there's a lot more motion control happening in the old design than in what I'm doing). In any case, the slots in that backplane are filled with Vexta (SPD5625) drivers. The problem is that the backplane was in turn connected to a proprietary computer made by the scanner manufacturer. None of that is being used because it's not relevant to my design and frankly I wouldn't even know where to begin!

My goal is just to use the transport and existing motors (which I know are correctly sized for the weight of 35mm film), but to replace the imaging system entirely. I was hoping that all the steppers would have standalone drivers, but only two of them do. Because those two are the two most precision-critical movements in the old scanner design (moving the slit light source and line array in sync on separate rails on opposite sides of the machine), I think they used them instead of the more generic looking drivers that move less critical parts around the machine. In my design, the most critical motion is going to be the transport, so I want to use these drivers for that purpose.

I'll be keeping 6 of the original stepper motors in the scanner, and removing the rest of them to keep as spares. That also means I'll need to pick up 4 more standalone drivers in the near future because I can't use the proprietary driver system that was originally installed.

I'd love to know if I can piggyback two motors onto one driver though - since they will both do the exact same thing at the exact same time, it seems like the easiest way to go. You can see the two sprocket drives here: Threaded | Some 35mm threaded through the gate. It's pin-reg… | Flickr they're a few inches apart on either side of the film gate, and move in tandem.

Thanks!

The sprockets were driven separately probably to keep the film taught in the imaging area.

Maybe one is the actual position control stepper and the other is just used for slack control ( a dc motor could have been used for this).

If there is access to the back you might be able to tie the 2 together (what I did on mine but it was to be a documenting type of transport so the film did not need to be taught).

If the film needs to be taught and you only want to drive it by one motor there is a way to do it somewhat in the manner that a dial caliper (used for measuring with a needle going around to indicate position) keeps it's needle from flopping about. I've had mine apart and the mechanism is pretty clever. Of course there would need to be some room to do it.

Looks like some long days ahead for you but it sounds like a fun project.

The film transport isn't designed to run in continuous motion, it's actually intermittent. In the original design the actual scan took something like 30 seconds per frame, because it would move the film into position, then slowly sweep the sensor and light across the film. In my design, with off-the-shelf cameras the basic sequence is this:

  • Move frame into position
  • Engage registration pin plate (stepper motor that makes 1 complete revolution to engage pins and pressure plate)
  • (scan image, triggered from software)
  • Disengage registration pin plate
  • Move to next frame

If I can get it into the 1fps range, I'll be pretty happy. Any faster will be a bonus (the test camera I'm getting can do 4fps).

I don't think there's a need to keep it taut between the sprocket rollers, because of the pressure plate/registration pins - those ensure that each frame is in exactly the right position. After looking more closely at it, I'm guessing that at any given time, only one of these sprocket wheels is engaged: the one on the left when rewinding, and the one on the right when moving forward. That way, it's always pulling, not pushing, the film through the transport. Tension on the feed and takeup reels is kept with an AC torque motor (another whole project, figuring that out, I'm guessing!)

Some success! I'm using the oneStepAtATime stepper motor example in the IDE, and I am able to make the motor turn, but wow is it slow.

Even with the delay removed, it's taking a long time to complete a single rotation. With the motor I'm testing with, it should be 500 pulses to do a single rotation, no? (.72 degrees per step). According to serial monitor, it's taking a couple thousand. The driver is a microstep driver, and there are two rotary DIP switches on it, labeled DATA 1 and DATA 2. I gather these determine the size of the microsteps, so I set both to zero, and that's getting me the fastest speed overall, but that's still taking 2000 pulses to make one revolution: 4x what I'd expect.

I see the same speed when I put the Vexta driver in Test mode, which is just supposed to rotate the motor in one direction. The motor I'm testing with is a Vexta PK545-NBC, which was pulled from a part of the scanner I won't be using, and was the motor that was matched up to this driver originally. Is the speed a function of the motor or the driver, and is there a way to make this move at a more usable speed?

I have Digital Pin 8 connected to the Driver's CW- and Digital Pin 9 connected to CW+
My code looks like this:

#include <Stepper.h>

const int stepsPerRevolution = 500 ;  // change this to fit the number of steps per revolution
                                     // for your motor

// initialize the stepper library on pins 8 through 11:
Stepper myStepper(stepsPerRevolution, 8,9,10,11);  //NOTE: Also tried "myStepper(stepsPerRevolution, 8,9)" -- same result           

int stepCount = 0;         // number of steps the motor has taken

void setup() {
  // initialize the serial port:
  Serial.begin(9600);
}

void loop() {
  // step one step:
  myStepper.step(1);
  Serial.print("steps:" );
  Serial.println(stepCount);
  stepCount++;
  //delay(1);
}

By the way, since all these motors use the same quick-connect plugs throughout the system, I've tried the driver on a number of them, and they're all slow like this, even in test mode. That makes me wonder if there's something up with this driver that I have misconfigured. any ideas?

I picked up a non-microstepping driver on ebay this weekend to try out. Can't seem to locate any documentation about the exact model Vexta driver I'm currently using - the closest one I've got (the one posted earlier in this thread) is for a similar unit, but mine has some different controls on it than that one, and clearly something is not set correctly in mine. Hopefully motors will be spinning by Wednesday!

In your test code, you might consider increasing the baud rate, as well as only printing the step count every 50 or so - Serial comms are slow. If you do of course, you may have to reinstate a delay to get the motor stepping again, but you'll have better control of the speed then.

Thanks - I'll give that a try this morning. However, it still doesn't explain why the driver is taking 2000 steps to make one rotation, when it should be 500. This happens even when it's in self-test mode, totally disconnected from the Arduino.

For this particular application, I don't need that kind of resolution: 500 steps should be more than enough.

Awesome - that did it. I actually removed the serial stuff entirely, and when I did it was obvious the motor was getting the pulses too quickly (no spin, lots of noise). So I added a delay of 50 and got slightly faster speeds. A little back and forth and I was able to get it to do a single revolution in about 2.5 seconds (plenty fast), with a delay of 2.

Thanks!

-perry

Here's the first test of the sprocket drive motor, in action:

Also, I found out from Oriental Motor that the driver I'm using was only sold in Japan, which is why I haven't been able to find a manual. They only published one in Japanese.

Thanks for all the suggestions!

So the non-Vexta driver I bought on ebay arrived and works. This one is a Mycom UPS50, and can be used in half or full step mode through the use of a switch on the driver.

I'm still having the same issue regarding the number of steps to complete a rotation. The motor is .72 degrees, so it should be 500 steps, correct? When I set the stepsPerRevolution to 500, and tell the motor to do 500 steps, it only goes partway around, never making a full rotation. Here's my code, which is supposed to trigger a single rotation when a sensor is tripped:

#include <Stepper.h>
const int stepsPerRevolution = 500 ;  // change this to fit the number of steps per revolution
                                     // for your motor

// initialize the stepper library:
Stepper myStepper(stepsPerRevolution, 8,9);            
int stepCount = 0;         // number of steps the motor has taken

void setup() {
  pinMode(7, OUTPUT);     
}

void loop(){
  int sensorState = analogRead(A0);

  if (sensorState == HIGH) {    
    while(stepCount < 500){
      myStepper.step(1);
      stepCount++;
      
      //light up the LED, just so we know
      digitalWrite(7, HIGH);
      delay(2);
    }
  }
  else {    
      //turn off the LED
      digitalWrite(7, LOW);
      delay(2);
 }
  //reset the counter
  stepCount = 0;

It doesn't matter if I'm using the Vexta microstepping driver, or this new simpler one, I'm only getting 1/4 rotation with 500 pulses. Any idea what's going on here?

Sorry but in my thinking that the stepper library had an option for having only 2 pins meant that it supported step/direction.

Just had a look at what it does. It does not support true step/ direction. In a way it does do step/direction but in a roundabout way. It takes four steps thru to actually produce a pulse. Direction works because of the sequence.

From the library-

The sequence of controls signals for 2 control wires is as follows
(columns C1 and C2 from above):

Step C0 C1
1 0 1
2 1 1
3 1 0
4 0 0

So, sorry to have been misleading you by me not fully understanding of the library but I thought I saw this somewhere.

To actually be able to use step/direction use the AccelStepper library.

http://www.airspayce.com/mikem/arduino/AccelStepper/

Great! thanks - I'll give that a try tomorrow!