On Tue, Dec 25, 2007 at 08:30:09PM +0100, Jesús Bas wrote:
> - No matter what numbers you put in stepconf for steplen, step space,
> dirhold and dirsetup, the generated .hal file reflect wrong data.
I believe that the values written by stepconf are exactly what I
intended. Let me explain how stepconf arrives at each figure in
question.
> In my case, the following requested numbers were (I use Gecko drives):
>
> - steplen 4000
> - stepspace 500
> - dirhold 20000
> - dirsetup 1000
(not shown: you must have entered a "latency test result" of 30000)
> and the corresponding lines in the generated .hal file is allways (no
> matter what numbers you input):
>
> - setp stepgen.0.steplen 1
> - setp stepgen.0.stepspace 0
> - setp stepgen.0.dirhold 50000
> - setp stepgen.0.dirsetup 31000
(not shown: setp parport.0.reset-time 4000)
(not shown: inifile BASE_PERIOD of at least 39500)
BASE_PERIOD 39500
This is at least as big as machine latency + reset_time + 5000
but may be a larger value if your step rate is low.
reset-time 4000
this is the step length you entered in stepconf. After the step
"1" bit is written to the parport, it is reset back to "0" after
at least 4000ns has passed (but maybe longer)
steplen 1
this means "the shortest step length possible". the actual
minimum length of the pulse on the parport is 4000ns, defined by
parport.0.reset-time
stepspace 0
this means that steps are allowed in subsequent base_periods
("doublestep"). The actual minimum length of the space on the
parport is defined by
BASE_PERIOD - machine latency - reset-time - overhead
where "overhead" is any time above and beyond the minimum
reset-time that the step pulse is "high", plus any other
variations (such as cache misses) that make the time between one
"reset" and the subsequent "write" (in the next base-thread
invocation) vary. It is assumed that this is less than 5000ns
in all cases, but has only been measured on a few machines.
dirhold 50000
dirsetup 31000
these are the dirhold and dirsetup values you entered, plus the
latency test result you entered.
Perhaps someone will point out an error in these calculations, but for
now I simply cannot see it.
Other possibilities are:
* The signal path from your PC to the gecko has other
characteristics (e.g., weak drive stringth in the parport,
additional external signal conditioning) that lead to increased
rise/fall time for signals and require higher step length and
space in emc
* another error in your configuration, such as an incorrect "invert"
on a step output pin
* there is a (yet unknown) bug in the hal_parport driver that causes
the step output bit to be reset too early (this is based on CPU
speed, so if linux misdetects your CPU that could also be the
cause)
* the arbitrary "max overhead" value of 5000ns is not appropriate
for all machines
If the *only* change you made was to modify the inifile stepspace to
a nonzero value, then the only effect is to increase the step space by
approximately one base-period--e.g., from 500ns minimum to 40000ns
minimum. The step pulse will still be short (as short as 4000ns) unless
you made other changes (e.g., remove the "setp parport.0.pin-##-reset 1"
lines, or the "addf parport.0.reset base-thread" line)
Jeff
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
