Controlling a stepper motor with c language

Give me some help with this, im in windows xp, i have no experience controlling hardware with programming languages, all i know is that the parallel port has the direction 0x378 and it's different in each OS.

Reply to
Vicfred
Loading thread data ...

formatting link

You're screwed as far as a simple method. The parallel port API has been cleaned up (probably especially with the advent of USB-based parallel port replicators).

The Lizard

Reply to
Jujitsu Lizard

This might give you some ideas:

formatting link

An intro course for kids ... but a good study on steppers/parallel port Cheers, Rob.

Reply to
Spam

Not exactly. Ports can be controlled directly under Windows with DriverLinx. It's only real limitation is that input requires polling

- there is no interrupt support. It works on all 32-bit versions of Windows except Vista.

formatting link

You can still read and write the port, but you don't have immediate access and you can't see all the signal lines. But DriverLinx can fix that.

George

Reply to
George Neuner

The OP wants to control stepper motors and for that you need very good timing: individual step pulses have to be evenly spaced in time, because otherwise you end up fighting the motor inertia and will lose steps and make lots of noise. Even in Linux people tend to use Real Time extensions and generate pulses from the realtime tasks.

--
		Przemek Klosowski, Ph.D.
Reply to
przemek klosowski

Windows has a 'realtime' priority class which is higher than the OS. User process threads in that class are not interruptible - they run to completion or to voluntary wait - and they are not subject to priority juggling.

I have not tried to run steppers from 32-bit Windows, however I have built and maintained industrial HRT systems on several versions of Windows and I have used Driverlinx on NT and 2K to good effect. I have not done HRT work with XP or embedded XP (I have written normal applications for XP).

I have not found Windows to be terribly troublesome ... early versions of some drivers had bad interrupt behavior, but all the important drivers were fixed by the mid 1990's. I think the continued (and IMO unjustified) bad press frightens many people away from even trying Windows even if would be easier to build on. My experience has been that so long as you have control of the software configuration, Windows is a very reliable and responsive platform.

I have reproducibly timed, with digital scope under heavy CPU load, round trip from external interrupt to signaled event to realtime priority user process thread to output on a port through DriverLinx at

Reply to
George Neuner

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.