Stepper motor control

[Pedro]

Hi and thanks in advance for reading this.
I have a setup with 4 stepper motors. 3 of them, which are working perfectly, are connected to Parker E-AC drives and controlled using a NI PXI-7334 motion controller. However, the 4th motor is a very high torque one that comes with a drive/analog speed controller already included, and the only way to control it is sinking the start/stop (0V=start 5V=stop) input. To do this I use a PCI-CTR05 DIO card from measurement computing. As it's easy to see the motor will move for the time the start/stop input is low and will stop as soon as it goes high again. A VI to do this is pretty much straightforward: send a TRUE command through one of the DIO card's outputs to activate a relay that will close the start switch
, wait for a desired time, and then send a FALSE command for the relay to open the circuit again. The problem I have is that, as I mentioned before, the motor has a very high torque, so we need to use limit switches to kill the motor in any case we reach the limits to avoid any damage. The switches are connected to 2 of the DIO card's digital inputs and we already have a simple VI that constantly polls these inputs to determine when a limit switch is active. However, I haven't been able to make both things, moving the motor and poll the limit switches status, to work together in a single VI. The main problem is that when the motor is engaged the VI won't execute anything else until the "wait for X ms" command had been executed, so it's impossible to run the while loop to poll the digital inputs. I've tried several options to make this work, but either the motor will move until the wait time has passed ignoring the limit switches, or it will move erratically as the CPU give priority to
either the while loop or the wait command. Please let me know if you have any suggestion on how to make both things to work together.
Thanks for you time.

[Jochen]

Pedro,

it looks like the measuremente computing driver is only single threaded. Thus your vi that polls the limit switches blocks the move commands. I don't know anything about the measurement computing driver and their LabVIEW vis but if my assumption is correct you need to make sure that only one attempt to access the driver is made at a time. Maybe using semaphores could be a solution.
By the way: The latest NI-DAQmx driver for National Instruments data acquisition products is multi threaded and doesn't cause these kind of problems :-).

Another consideration:
Your approach seems to be a bit hazardeous to me. What you are trying to do is to implement a safety feature in software on a Windows operating system. I strongly recommend not to do this! On Win
dows as on every non real-time operating system there is always the chance for non deterministic dropouts. Even if everything is working fine for some time you never should rely that it will work fine for the next minute.
It's a pitty that you are not using a PXI-7344 board but a 7334. On the 7344 you could run an onboard program in a real-time environment that reads and writes the digital lines so you could run the motor control and the limit switch monitor on the board.

I assume you have to stick with your hardware so I would recommend building some simple external circuitry to inhibit your high torque axis whenever a limit switch becomes active. You would have to implement also some logic to be able to clear the inhibit signal (e. g. you could reset it with one of your DO lines).

I hope this gives you some ideas to start with.

Best regars,

Jochen Klier
National Instruments Germany

[Buechsenschuetz]

I totally agree that is a hazardous approach to control safety or limit switches with a non-real time environment. We have similar problems with a very simple motor controller based on a 8051 microcontroller. Besides the step and direction output this controller has three general purpose i/o lines we are using for controlling the limit switches. Since the motor controller can't run several tasks at a time we have to use external circuitry which will block the step pulses and allow for re-starting the motor in the opposite direction (off the limit position) only.

And that's the point I don't understand completely. How do you move your motor off the limit position when you can't control the direction of the drive?

However I think it is even possibl
e to control your motor like a stepper motor. You can add a missing pulse detection circuitry (which is not too difficult to design using the good old NE555) and connect its input to the step output of the 7334. Now you can use the limit switch inputs as usual. The 7334 will stop the step pulses as soon as the limit switche(s) are reached, the missing pulse detector will detect no incoming pulses and stop the drive.

You have to select a rather high step rate since the missing pulse detector may produce a 'jitter' between detecting no step pulses and switching the drive off, this time lag should be as short as possible and can't be shorter (i.e. has to be somewhat longer) than the pulse rate of the step pulse.

Also you should try to set the 7334 such that the step pulse frequency does not change too much, i.e. the acceleration ramps should be as short as possible (zero if possible). Otherwise the missing pulse detector will not start the drive until a certain step rate is reached
during acceleration.