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.

"Vicfred" <toonanime@gmail.com> wrote in message 
news:b9fe4336-8bd4-4950-8dc6-c3fe52c6a42d@u18g2000pro.googlegroups.com...
> 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.

http://www.epanorama.net/circuits/parallel_output.html

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 

On Thu, 29 Jan 2009, Vicfred wrote:
> 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.
>

This might give you some ideas:

 	http://www.taomc.com/bits2bots/

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

On Thu, 29 Jan 2009 20:45:10 -0500, "Jujitsu Lizard"
<jujitsu.lizard@gmail.com> wrote:

>"Vicfred" <toonanime@gmail.com> wrote in message 
>news:b9fe4336-8bd4-4950-8dc6-c3fe52c6a42d@u18g2000pro.googlegroups.com...
>> 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.
>
>http://www.epanorama.net/circuits/parallel_output.html
>
>You're screwed as far as a simple method.

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.

http://www.driverlinx.com/DownLoad/DlPortIO.htm


>The parallel port API has been cleaned up (probably especially with
>the advent of USB-based parallel port replicators).

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

On Sat, 31 Jan 2009 01:09:17 -0500, George Neuner wrote:
 
> 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.

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. <przemek.klosowski at gmail>

On Mon, 02 Feb 2009 04:21:30 GMT, przemek klosowski
<przemek.klosowski@gmail.nospam> wrote:

>On Sat, 31 Jan 2009 01:09:17 -0500, George Neuner wrote:
> 
>> 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.
>
>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.

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
<10us on a 1GHz P4 running NT4.

As far as precise timing, you have the same choices in Linux as in
Windows - you can deal with the scheduler, or you use CPU cycle
counters (which you can't wait on), or you write a computed delay loop
in assembler.  Windows drivers have access to the 1ms heartbeat and
can wake up reliably at 1ms granularity.  User processes are limited
to ~10ms granularity _unless_ they are running at realtime priority.
Realtime user process threads can wake up reliably at 2ms granularity
(at least in NT and 2K).  

From my own experience I haven't encountered anything I could do in
RTLinux that I could not do in Windows (and without the hassle of
building a kernel).  YMMV.

George