Re: [Emc-users] encoder component in counter mode velocity stability issues
Scott Hasse wrote: > As a follow-up I had a chance to look at my frequency signal with a digital > scope and found that it was indeed unstable to the tune of 20%. Well, when nothing makes sense, it is always best to start at the beginning, and make sure the input to the first component is good before moving down the line. Glad you found the source of the problem. Jon -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] encoder component in counter mode velocity stability issues
As a follow-up I had a chance to look at my frequency signal with a digital scope and found that it was indeed unstable to the tune of 20%. I had not expected that as I used an LM331 chip with seemingly appropriate components. Hooking a real function generator to the input worked great, with the expected ~2% fluctuation (20,000 ns base thread sampling a 1kHz signal). I'm now looking closer at my circuit and supply voltages to determine where the variances are coming from. Very glad this is not a problem in the parallel port hardware nor LinuxCNC, and glad to see with the function generator I should be able to get a usable input once I am generating a frequency appropriately. Thanks everyone for their insight on this issue. Scott On Mon, Jul 2, 2012 at 9:01 AM, Jon Elson wrote: > Scott Hasse wrote: > > John is correct. My logging could be more clear. The "time between" is > > the since the last rising edge of the input pulse as detected by the > update > > function of the encoder running in the base thread. The "counts between" > > is the number of base thread runs since the last rising edge input pulse. > > The time goes with the count of runs directly below it. For the sample > Jon > > referenced, I believe the the two data points are: > > > > 40 runs in 796760 ns = 19919 ns/run > > 60 runs in 1195140 ns = 19919 ns/run > > > > The 1035788 ns time is actually from 52 runs, also = 19919 ns/run > > > OK, I admit I didn't read the code, so I made wrong assumptions. Well, > then, if this isn't > thread jitter, then the pulse source must be quite irregular. Or else, > the device reading > the input signal is pretty imprecise in detecting it. > > Granted, this is the time passed into the update function as the period, > > not an actual system time, but I think that shows there is very little > (if > > any) thread timing jitter. There is absolutely variance there, but the > > data I have would seem to point toward an unstable input signal (or > somehow > > a significant amount of random variance being introduced somewhere > between, > > which would be very odd), but it would also be odd for my input signal to > > vary based on the way I am generating the signal. I can confirm all that > > once I get back in a week or so. > > > It will be interesting to find out what the cause of this is, but if the > test signal is no good, then > the test doesn't answer any questions. > > Jon > > > -- > 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 > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] encoder component in counter mode velocity stability issues
Scott Hasse wrote: > John is correct. My logging could be more clear. The "time between" is > the since the last rising edge of the input pulse as detected by the update > function of the encoder running in the base thread. The "counts between" > is the number of base thread runs since the last rising edge input pulse. > The time goes with the count of runs directly below it. For the sample Jon > referenced, I believe the the two data points are: > > 40 runs in 796760 ns = 19919 ns/run > 60 runs in 1195140 ns = 19919 ns/run > > The 1035788 ns time is actually from 52 runs, also = 19919 ns/run > OK, I admit I didn't read the code, so I made wrong assumptions. Well, then, if this isn't thread jitter, then the pulse source must be quite irregular. Or else, the device reading the input signal is pretty imprecise in detecting it. > Granted, this is the time passed into the update function as the period, > not an actual system time, but I think that shows there is very little (if > any) thread timing jitter. There is absolutely variance there, but the > data I have would seem to point toward an unstable input signal (or somehow > a significant amount of random variance being introduced somewhere between, > which would be very odd), but it would also be odd for my input signal to > vary based on the way I am generating the signal. I can confirm all that > once I get back in a week or so. > It will be interesting to find out what the cause of this is, but if the test signal is no good, then the test doesn't answer any questions. Jon -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] encoder component in counter mode velocity stability issues
John is correct. My logging could be more clear. The "time between" is the since the last rising edge of the input pulse as detected by the update function of the encoder running in the base thread. The "counts between" is the number of base thread runs since the last rising edge input pulse. The time goes with the count of runs directly below it. For the sample Jon referenced, I believe the the two data points are: 40 runs in 796760 ns = 19919 ns/run 60 runs in 1195140 ns = 19919 ns/run The 1035788 ns time is actually from 52 runs, also = 19919 ns/run Granted, this is the time passed into the update function as the period, not an actual system time, but I think that shows there is very little (if any) thread timing jitter. There is absolutely variance there, but the data I have would seem to point toward an unstable input signal (or somehow a significant amount of random variance being introduced somewhere between, which would be very odd), but it would also be odd for my input signal to vary based on the way I am generating the signal. I can confirm all that once I get back in a week or so. 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] encoder component in counter mode velocity stability issues
On Sun, Jul 1, 2012, at 04:59 PM, Jon Elson wrote: > Scott Hasse wrote: > > Are you perhaps associating the wrong run count and run times log entries? > > In the four-line log snippet you show I believe the middle two entries > > would be associated with each other. I see the times between divided by > > runs between to be quite stable. I have run the latency tests and get > > about 8000 ns on this 525mw with hyper threading disabled and the other > > recommended tweaks. > > > No, I'm comparing 40 vs 60, and 796760 vs. 1035788, both of these are > pretty large > variations. The last two numbers are 796 us and 1035 us, so that is a > difference of > 239 us! YOW! I'm not sure exactly what this "time between" > measurement is, > I was assuming it was the time difference between your executions of the > encoder.n.capture-position HAL function. I think that assumption is wrong. Scott will have to confirm this, but I'm pretty sure these aren't the times of individual executions of the thread. They are the times and number of thread executions between each time the code sees an edge of his incoming signal. That would seem to indicate that the incoming signal has a bunch of jitter. And he has said he is going to get the instrumentation to actually look at it and see. A real scope (as opposed to halscope) would be the best bet. -- John Kasunich jmkasun...@fastmail.fm -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] encoder component in counter mode velocity stability issues
Scott Hasse wrote: > Are you perhaps associating the wrong run count and run times log entries? > In the four-line log snippet you show I believe the middle two entries would > be associated with each other. I see the times between divided by runs > between to be quite stable. I have run the latency tests and get about 8000 > ns on this 525mw with hyper threading disabled and the other recommended > tweaks. > No, I'm comparing 40 vs 60, and 796760 vs. 1035788, both of these are pretty large variations. The last two numbers are 796 us and 1035 us, so that is a difference of 239 us! YOW! I'm not sure exactly what this "time between" measurement is, I was assuming it was the time difference between your executions of the encoder.n.capture-position HAL function. If that is so, then this particular hal config is NOT performing the way your latency test indicates it SHOULD be. This wild latency variation sure corresponds with the large fluctuation in velocity you are getting from the encoder component, so I tend to believe the numbers bear out that something is really killing your latency. Note that rtapi also collects run time info on all rt components, possibly one of your components is malfunctioning and burning large and variable amounts of time, causing all later components in the thread to suffer a lot of jitter. This data can be seen with halscope, for instance. Jon -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] encoder component in counter mode velocity stability issues
Are you perhaps associating the wrong run count and run times log entries? In the four-line log snippet you show I believe the middle two entries would be associated with each other. I see the times between divided by runs between to be quite stable. I have run the latency tests and get about 8000 ns on this 525mw with hyper threading disabled and the other recommended tweaks. Scott On Jul 1, 2012, at 11:38 AM, Jon Elson wrote: > Scott Hasse wrote: >> Jun 30 17:48:41 scott-desktop kernel: [ 4078.255547] ENCODER runs between: >> 60 >> Jun 30 17:48:41 scott-desktop kernel: [ 4078.256330] ENCODER time between: >> 796760 >> Jun 30 17:48:41 scott-desktop kernel: [ 4078.256344] ENCODER runs between: >> 40 >> Jun 30 17:48:41 scott-desktop kernel: [ 4078.257366] ENCODER time between: >> 1035788 >> > It appears you have really large real time jitter in this system. It > could be either the base thread or the servo > thread, not completely sure. But I see about 30% jitter on the time, > and 50% on the runs! That will make any control loop > malfunction badly. Have you run the latency tests on this system? > > Jon > > -- > 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 > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] encoder component in counter mode velocity stability issues
Scott Hasse wrote: > Jun 30 17:48:41 scott-desktop kernel: [ 4078.255547] ENCODER runs between: > 60 > Jun 30 17:48:41 scott-desktop kernel: [ 4078.256330] ENCODER time between: > 796760 > Jun 30 17:48:41 scott-desktop kernel: [ 4078.256344] ENCODER runs between: > 40 > Jun 30 17:48:41 scott-desktop kernel: [ 4078.257366] ENCODER time between: > 1035788 > It appears you have really large real time jitter in this system. It could be either the base thread or the servo thread, not completely sure. But I see about 30% jitter on the time, and 50% on the runs! That will make any control loop malfunction badly. Have you run the latency tests on this system? Jon -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] encoder component in counter mode velocity stability issues
n: 48 Jun 30 17:48:41 scott-desktop kernel: [ 4078.260315] ENCODER time between: 1035788 Jun 30 17:48:41 scott-desktop kernel: [ 4078.260329] ENCODER runs between: 52 Jun 30 17:48:41 scott-desktop kernel: [ 4078.261291] ENCODER time between: 976031 Jun 30 17:48:41 scott-desktop kernel: [ 4078.261305] ENCODER runs between: 49 Jun 30 17:48:41 scott-desktop kernel: [ 4078.262266] ENCODER time between: 976031 Jun 30 17:48:41 scott-desktop kernel: [ 4078.262280] ENCODER runs between: 49 Jun 30 17:48:41 scott-desktop kernel: [ 4078.263323] ENCODER time between: 1055707 Jun 30 17:48:41 scott-desktop kernel: [ 4078.263337] ENCODER runs between: 53 Jun 30 17:48:41 scott-desktop kernel: [ 4078.264299] ENCODER time between: 976031 Jun 30 17:48:41 scott-desktop kernel: [ 4078.264313] ENCODER runs between: 49 Jun 30 17:48:41 scott-desktop kernel: [ 4078.265487] ENCODER time between: 1175221 Jun 30 17:48:41 scott-desktop kernel: [ 4078.265490] ENCODER runs between: 59 Jun 30 17:48:41 scott-desktop kernel: [ 4078.266422] ENCODER time between: 936193 Jun 30 17:48:41 scott-desktop kernel: [ 4078.266426] ENCODER runs between: 47 Jun 30 17:48:41 scott-desktop kernel: [ 4078.267327] ENCODER time between: 916274 Jun 30 17:48:41 scott-desktop kernel: [ 4078.267342] ENCODER runs between: 46 Jun 30 17:48:41 scott-desktop kernel: [ 4078.268503] ENCODER time between: 1175221 Jun 30 17:48:41 scott-desktop kernel: [ 4078.268517] ENCODER runs between: 59 Jun 30 17:48:41 scott-desktop kernel: [ 4078.269529] ENCODER time between: 1015869 Jun 30 17:48:41 scott-desktop kernel: [ 4078.269533] ENCODER runs between: 51 Jun 30 17:48:41 scott-desktop kernel: [ 4078.270446] ENCODER time between: 916274 Jun 30 17:48:41 scott-desktop kernel: [ 4078.270450] ENCODER runs between: 46 Jun 30 17:48:41 scott-desktop kernel: [ 4078.271231] ENCODER time between: 796760 Jun 30 17:48:41 scott-desktop kernel: [ 4078.271245] ENCODER runs between: 40 Jun 30 17:48:41 scott-desktop kernel: [ 4078.272267] ENCODER time between: 1035788 Jun 30 17:48:41 scott-desktop kernel: [ 4078.272281] ENCODER runs between: 52 Jun 30 17:48:41 scott-desktop kernel: [ 4078.273243] ENCODER time between: 976031 Jun 30 17:48:41 scott-desktop kernel: [ 4078.273257] ENCODER runs between: 49 Jun 30 17:48:41 scott-desktop kernel: [ 4078.274259] ENCODER time between: 1015869 Jun 30 17:48:41 scott-desktop kernel: [ 4078.274274] ENCODER runs between: 51 The between-pulse variance is clear in that data, which I think for the most part rules out an encoder.c defect. It is seeing and counting the pulses. I think my next step is to either get a hold of a real frequency generator or scope (local hackerspace to the rescue!) so I can confirm my current LM331-based frequency generator. Unfortunately, that will have to wait a week as I am heading out on vacation today. Thanks much for the solid advice so far and I'll update this thread once I get a good look at my frequency generator to confirm how stable it is. Scott On Sat, Jun 30, 2012 at 7:10 PM, Peter C. Wallace wrote: > On Sat, 30 Jun 2012, Scott Hasse wrote: > > > Date: Sat, 30 Jun 2012 18:01:02 -0500 > > From: Scott Hasse > > Reply-To: "Enhanced Machine Controller (EMC)" > > > > To: "Enhanced Machine Controller (EMC)" > > > Subject: Re: [Emc-users] encoder component in counter mode velocity > stability > > issues > > > > My base thread is 2 ns (50 khz) and my servo thread is 100 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=2 name2=servo-thread > > period2=100 > > 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 > &g
Re: [Emc-users] encoder component in counter mode velocity stability issues
On Sat, 30 Jun 2012, Scott Hasse wrote:
> Date: Sat, 30 Jun 2012 18:01:02 -0500
> From: Scott Hasse
> Reply-To: "Enhanced Machine Controller (EMC)"
>
> To: "Enhanced Machine Controller (EMC)"
> Subject: Re: [Emc-users] encoder component in counter mode velocity stability
> issues
>
> My base thread is 2 ns (50 khz) and my servo thread is 100 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=2 name2=servo-thread
> period2=100
> 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
> Emc-users@lists.sourceforge.net
> 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
Re: [Emc-users] encoder component in counter mode velocity stability issues
My base thread is 2 ns (50 khz) and my servo thread is 100 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=2 name2=servo-thread period2=100 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] encoder component in counter mode velocity stability issues
Scott Hasse wrote: > All- > > I've been attempting to get a simple low-cost frequency-based analog input > to LinuxCNC using an LM331 voltage-to-frequency chip for measuring > temperature inputs from thermistors (as part of my RAMPS board parallel > port adapter I mentioned in a different thread). The good news is that I > have that basically working and will provide a documented circuit once I > get the bugs worked out. Interestingly, when I use the software encoder > hal component in counter mode, I get a lot more variance in the velocity > than I would expect. Yeah, the velocity is jumping up and down about 200 counts from sample to sample! > In my test cases, the pulse rate is very stable, the > pulse frequency is low enough that the parallel port input is capturing > every pulse, and the encoder.0.count is going up linearly as I would > expect. No, it actually is NOT going up all that linearly, it just is at a small enough scale that it looks MOSTLY linear. I see clear artifacts that correspond to the jumps in the velocity trace. I think there may be some noise or reflections that are causing it to count several times on each proper edge. If the pulse rate is regular, then the velocity should be regular, also, with only a +/- one count fluctuation. Are you running the encoder component's update-counters task in the base thread? If not, it will not be able to handle more than about 1/2 the servo thread rate of encoder pulses. Jon -- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] encoder component in counter mode velocity stability issues
On Wed, 27 Jun 2012, Scott Hasse wrote:
> Date: Wed, 27 Jun 2012 23:09:32 -0500
> From: Scott Hasse
> Reply-To: "Enhanced Machine Controller (EMC)"
>
> To: "Enhanced Machine Controller (EMC)"
> Subject: [Emc-users] encoder component in counter mode velocity stability
> issues
>
> All-
>
> I've been attempting to get a simple low-cost frequency-based analog input
> to LinuxCNC using an LM331 voltage-to-frequency chip for measuring
> temperature inputs from thermistors (as part of my RAMPS board parallel
> port adapter I mentioned in a different thread). The good news is that I
> have that basically working and will provide a documented circuit once I
> get the bugs worked out. Interestingly, when I use the software encoder
> hal component in counter mode, I get a lot more variance in the velocity
> than I would expect. In my test cases, the pulse rate is very stable, the
> pulse frequency is low enough that the parallel port input is capturing
> every pulse, and the encoder.0.count is going up linearly as I would
> expect. I've attached an image showing a halscope capture of the parallel
> port input, the encoder counts and the velocity. The velocity varies by
> 10-20% with a stable input frequency.
What is your base thread? a 10 KHz base thread would cause ~10% PP noise in a
1 KHz frequency measurement at 1 KHz servo thread due to sampling time
quantization, that is the time stamp would only have a resolution of 100 usec.
Of course base thread jitter adds to this as well.
>
> I initially thought perhaps the fact that my input pluses were not
> symmetric could causing some velocity issues, but according to the encoder
> component documentation (and source from what I can tell) the encoder in
> counter mode only counts the rising edges. In any case I tried x4-mode
> false and it was still just as unstable.
>
> I understand that I can smooth this out with a lowpass filter, but even
> with a gain of 0.001 there is enough variance to be noticeable. More gain
> than that and the measurement takes noticeably long to come up from zero to
> the measured value. (As an aside, I am wondering about the value of a
> simple enhancement that could be made to the lowpass component such that on
> the first read it sets the out value to the initially in value to make the
> initial settle period much lower. As I improve my .comp skills I'll look
> to create a patch. There is a load mode on the lowpass already, but it
> needs to be enabled then disabled.)
>
One thing that commonly done for this is a step acquire mode. What this does
is check the filter output and input and if they differ by more that some
threshold (a ratio) the filter output gets set to the input value.
This does not work well for "spikey" noise but is good for noise that has a
bounded amplitude (like quantization noise)
>
> Interestingly, the frequency of my analog input is just about the same as
> the servo thread (100 uS) and 1kHz. If I increased the servo thread
> interval then the velocity variance decreases, seemingly in proportion to
> how much I increase the servo thread. This makes a certain amount of sense
> (in essence I am averaging the measured interval over more than one data
> point), but I'm hoping to understand why I am getting so much variance in
> my current case.
For temperature measurement it probably does not make much sense to caulculate
more often than about every 100 1 ms servo threads anyway (which should
reduce your noise to the 0.1% to 0.2% region
>
> Looking at the source code for the encoder component it looks like the
> update function keeps track of the timestamp of the last pulse seen, and
> the capture function uses that timestamp if no pulses were seen in the last
> servo loop to estimate a velocity, but only uses the estimated velocity if
> it is lower than the last actually-measure velocity. That all seems good
> from what I can see, so I'm having trouble understanding how so much
> variance could be coming into the velocity value for a stable frequency
> input.
>
> Anyone have thoughts on why I might be experiencing that?
>
> Thanks much,
>
> Scott
>
>
> Thanks in advance for any thoughts on this subject.
>
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
