Re: [Emc-developers] (no subject)

[Peter C. W. <pc...@me...>]

On Wed, 28 Sep 2011, Sebastian Kuzminsky wrote:

> Date: Wed, 28 Sep 2011 10:09:43 -0600
> From: Sebastian Kuzminsky <se...@hi...>
> To: Peter C. Wallace <pc...@me...>
> Cc: EMC developers <emc...@li...>
> Subject: Re: 
> 
> On Sep 28, 2011, at 08:10 , Peter C. Wallace wrote:
>
>> On Tue, 27 Sep 2011, se...@hi... wrote:
>>
>>> It'd be convenient if the stepgen module provided a TSC register like the Quadrature Counter module, then we could just use that.  If it counted microseconds, 16 bits would be plenty.
>>
>> Thats easily do-able but I have some reservations
>>
>> 1. Some 5I20 stepgen configs are really close to being full. Its possible a TSC would put some over the top so it would be good if driver code could support TSC and non TSC stepgens.
>>
>> 2. Calibration is likely still desireable even with the TSC to make sure that the stepgens clock (or TSC) is close to whatever generates the PCs servo thread (8253?)
>
>
> Yes, you're right.  I remembered after i sent that, that the ClockLow frequency reported in the IDROM is not reliable.
>
> This stepgen bug comes from us not knowing how much wall-clock time has elapsed between sequential invocations of hm2_read(), and this reduces the quality of stepgen velocity estimation.
>
> I think there are two ways we could know this number: we could measure it on the PC, or the FPGA could tell us.
>
> Back in 2008 John Kasunich warned me that measuring the time on the PC is not easy: <http://thread.gmane.org/gmane.linux.distributions.emc.devel/1174/focus=1174>
>
> Jeff Epler did some work on this earlier this summer, it was merged into 2.5 in July but as far as i know the period reported to realtime functions is still the idealized one, not the measured one that Jeff's commits seems to enable:
> <http://thread.gmane.org/gmane.linux.distributions.emc.devel/4607> <http://thread.gmane.org/gmane.linux.distributions.emc.devel/4641>
>
> So if we want to measure the actual servo thread period on the PC, that's 
> probably an approach to examine.
>
> The other option is to measure the time on the FPGA.  This has two 
> components: calibrate the FPGA clock to the PC clock, and then read the FPGA 
> clock every time through the servo loop.  This option has an additional 
> benefit: by calibrating the FPGA clock to the PC clock, we'd get better 
> encoder velocity estimates.
>
> The Quadrature Counter module already has a TSC register.  If we moved that 
> register (and the TSDiv register) out to their own module, we wouldn't take 
> much more FPGA space, and we'd have a single place to calibrate and read the 
> FPGA clock.
>
>
> Thoughts?

I think thats fine as long as the driver gets along with older firmware as 
well

Note that if used for the encoder, the TSC would have to be like the encoder 
one, a programble divider rather than a DDS so you would have large frequency 
steps (you could not tune it)

if space was not an issue, a wilder idea is to have a separate DDS based TSC 
thats phase locked to the servo thread (this could happen automatically as a 
side effect of reading the count every servo thread)



>
>
> -- 
> Sebastian Kuzminsky
>

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.