On Sat, 30 Jun 2012, Scott Hasse wrote:
> Date: Sat, 30 Jun 2012 18:01:02 -0500
> From: Scott Hasse <[email protected]>
> Reply-To: "Enhanced Machine Controller (EMC)"
> <[email protected]>
> To: "Enhanced Machine Controller (EMC)" <[email protected]>
> Subject: Re: [Emc-users] encoder component in counter mode velocity stability
> issues
>
> My base thread is 20000 ns (50 khz) and my servo thread is 1000000 ns. I
> am running the update-counters in the base thread. I was thinking that
> should limit my sampling noise to ~2% but instead it is ~20%. I don't
> think I'm getting bounce errors as the parallel port pins in halscope show
> regular pulses as I would expect. To understand this issue better, I've
> set up the following standalone hal configuration:
>
> ******************
> loadrt threads name1=base-thread period1=20000 name2=servo-thread
> period2=1000000
> loadrt probe_parport
> loadrt hal_parport cfg="0x378 out "
> setp parport.0.reset-time 5000
> addf parport.0.read base-thread
> addf parport.0.write base-thread
> addf parport.0.reset base-thread
>
> loadrt encoder num_chan=1
> loadrt lowpass
> setp encoder.0.counter-mode true
> net encoder-0-phase-A encoder.0.phase-A <= parport.0.pin-10-in
> setp encoder.0.position-scale 1.0
> addf lowpass.0 servo-thread
> setp lowpass.0.gain 0.001
> net lowpass-0-in lowpass.0.in <= encoder.0.velocity
> net temp-0-in-filtered <= lowpass.0.out
> addf encoder.update-counters base-thread
> addf encoder.capture-position servo-thread
> start
> ******************
>
> that I kick off like so:
>
> halrun -U
> sudo /etc/init.d/realtime restart
> halcmd -f thermal-input.hal
> halmeter &
>
> and added some logging to the encoder.c component and installed it via:
>
> sudo comp --install encoder.c
>
> and then I see the my additional error-level logging in /var/log/messages
>
> As an aside, I was astounded how easy it is to develop (or at least modify
> and debug existing) c-level components. Great job to all who have made
> that system what it is. I thought it might take me days to get a
> re-compiled encoder.c component working and was pleased to find it was
> actually only minutes.
>
> Doing that showed me that although the base thread runs were sufficient in
> number and capturing the transitions properly, there actually was variance
> between the between-rising-edge times it was catching, ranging in a short
> sample from 817us to 1173us for what should be a fairly steady 1khz/1000us
> signal. Modifying the encoder component to have it log a count of update
> runs between pulses shows anywhere from 40 to 60 runs between a rising edge
> detection, but always averaging right at 50 and typically subsequent
> intervals compensating for the previous intervals in terms of overall time.
> For instance, an interval with 45 base thread runs between a rising edge
> detected would be followed by an interval with 55 base thread runs.
>
> This is leading me to wonder about timing in the parport driver. I see
> there is a reset function for pushing values faster, but it seems like that
> is for output. Is anyone aware of how input data propagates through the
> parport driver and if there are opportunities for delay?
>
> Thanks much,
>
> Scott
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Emc-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
a couple of thoughts:
It seems unlikely that the parallel port driver could cause this large a
jitter, as it really only does a little bit munging and a direct inb or outb
for the parallel port I/O (hal_parport.c). Also jitter this large would pretty
much kill step generation
Is it possible that your V-F has noise/hum ? A 1 KHz
square wave from a hardware stepgen or some other known source could test
this if thats handy.
I wonder if its just a bug in the encoder comp (its pretty involved with the 2
threads and the possibility of the base thread interrupting the servo thread
code)
you might be able to check this with a simplified counter comp that just
counts base thread executions between signal rising edges (double buffered of
course)
Peter Wallace
Mesa Electronics
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users
