Newsgroups: comp.robotics
Path: brunix!cat.cis.Brown.EDU!agate!library.ucla.edu!csulb.edu!csus.edu!netcom.com!jonk
From: jonk@netcom.com (Jonathan Dale Kirwan)
Subject: Re: Problem with PW driver from PC
Message-ID: <jonkCv7sqq.9Ep@netcom.com>
Organization: New World Computing Services
X-Newsreader: TIN [version 1.2 PL1]
References: <33iegl$q7r@io.salford.ac.uk>
Date: Sat, 27 Aug 1994 22:20:50 GMT
Lines: 45

J.W.D.Boucher (j.w.d.boucher@aeromech.salford.ac.uk) wrote:
: At the moment Im trying to drive some small precision position servos 
: using a pulse width modulated signal from a PC.  Im using a Digital 
: output card  ( FPC - 024; 8255 i/o card - if thats relevant ) which holds 
: an output bit high for a given number of clock cycles, and then goes low. 
:  It all works great except that randomly each of the servos being driven 
: by the program coughs ( turns quickly one way or the other by about 10 
: degrees and then returns to where it was supposed to be ).  The time 
: between coughs seems to be of the order of 1 minute and the best idea 
: I've had is that there might be some kind of refresh routine that I dont 
: know about in the PC.

: That's all the info I have at the moment, but if anyone has had similar 
: problems or better still the solutions, I'd be glad to hear about it.

: Thanks in advance....   

I agree that disabling the interrupts would make a good test (there is a 
non-maskable interrupt [that is maskable, of course], but it won't cause 
you any _unannounced_ problems.)  The timer, keyboard, CMOS interval 
timer, etc, all can cause you problems for precise timing.

If you want to let the PC keep track of time and you need to support the 
keyboard (and the rest), consider issue in turn and devise a solution for 
it.  For example, the timer helps DOS and BIOS keep track of the 
seconds.  However, many other functions may "hook" themselves into the 
timer's interrupt vector so they can also get control then.  Sometimes, 
they go off and do something really serious and you lose a big chunk of 
CPU time.  (The printer driver is a good example here.)  To handle this, 
hook the timer vector with a short routine of your own that does _not_ 
call the other drivers.  Just keep track of the number of "ticks" that 
have taken place.  The routine should take only a microsecond or two and 
you can probably tolerate that kind of "jitter" in your timing.  Then, 
when your routine has time, perhaps only at certain points of your 
application, you flush out the saved up ticks by repeatedly calling the 
driver chain.  Each driver chain call decrements your count by one.  Once 
it is back to zero again, your PC time will be back in sync and you will 
have prevented the needs of that driver chain from interfering with your 
timing requirements.  Sometimes you can handle a couple of calls to the 
chain between your timing pulses, if the duty cycle is right.  Anyway, 
there are creative ways to solve these problems without having to go to a 
completely different O/S or making a "big" deal of it, otherwise.

Jon K

