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.
----- Reply message -----
From: "Peter C. Wallace" <p...@mesanet.com>
Date: Tue, Sep 27, 2011 21:14
Subject: [Emc-developers] FW: [Emc-users] bug(s) in 2.4.6 using Gantrykins?
To: "EMC developers" <emc-developers@lists.sourceforge.net>
On Wed, 28 Sep 2011, Chris Morley wrote:
> Date: Wed, 28 Sep 2011 01:43:09 +0000
> From: Chris Morley <chrisinnana...@hotmail.com>
> Reply-To: EMC developers <emc-developers@lists.sourceforge.net>
> To: EMC DEV <emc-developers@lists.sourceforge.net>
> Subject: [Emc-developers] FW: [Emc-users] bug(s) in 2.4.6 using Gantrykins?
>
>
>
> Sorry I sent this to Seb instead of the list:
> From: chrisinnana...@hotmail.com
> To: s...@highlab.com
> Subject: RE: [Emc-users] bug(s) in 2.4.6 using Gantrykins?
> Date: Wed, 28 Sep 2011 01:29:59 +0000
>
>
>
>
>
>
>
>
>
>>
>> Try some tweaks to the hm2 stepgen params:
>>
>> Try setting .maxaccel to 0, this means "accelerate as hard as the
>> trajectory planner asks you to".
>>
>> Try setting .maxvel to 0, this means "go as fast as the timing params
>> let you".
>>
>>
>> --
>> Sebastian Kuzminsky
>
> Actually I wouldn't advise this. In pncconf I abandoned that as it
> caused following errors particularly in one direction.
>
> Peter advised setting limits for max vel and max accel and the problem
> went away.
>
> Chris M
>
Not sure if Tom E's problems are related but there are some
lingering hardware stepgen problems.
I suspect these stepgen problems are caused by servo thread jitter and
software/hardware timebase issues. I'm pretty sure the fact that the stepgen
driver somewhat inappropriately mimics the software stepgen is the root cause
of these problems. Luckily these problems don't crop up terribly often but
only in certain configurations. The problem does show up more:
1. On 5I20s where the clock may be off by a percent or two
(this is fixable by calibrating, which is probably good for any mixed hardware
software time base system even if the hardware is more accurate)
2. When a base thread is running (this causes jitter in the servo thread since
it can be interrupted by the base thread)
3. On systems with greater jitter
4. On systems with large dir change delays
The problem seems to go away if reasonable values of stepgen maxaccel are used
which suggests that perhaps improper velocity corrections due to thread
jitter are the cause of the problem.
Imagine a system slewing at a high speed (accel = 0), if a 1 mS thread took
1.5 mS, the stepgen driver (that calculates errors based on a assumed perfect
1ms thread time) would make a large and inappropriate velocity correction
(slowing down the step rate) when in fact no correction is needed since the
velocity is constant
I think this situation with the possible addition of time base errors cause
the control loop to go crazy (to use a technical term)
I suspect the solution is to:
1. Calibrate the stepgen hardware (a 1 second run of the stepgen on a system
with a 1ms servo thread with 50 Usec max jitter would get the hardware within
100 PPM of the servo tic rate) One of the stepgens can be run before outputs
are enabled to do this calibration
This is where it gets all hand wavy and fuzzy:
2. Make the stepgen driver either use the actual time (we know the jitter,
why not use it?) when doing its corrections, or somehow trust the hardware
more for short term timing and the servo tic more for long term (I realize
setting stepgen-maxaccel accomplishes this to some extent)
Peter Wallace
Mesa Electronics
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
