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 el...@pico-systems.com 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: 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
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
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 p...@mesanet.com wrote: On Sat, 30 Jun 2012, Scott Hasse wrote: Date: Sat, 30 Jun 2012 18:01:02 -0500 From: Scott Hasse scott.ha...@gmail.com Reply-To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net 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
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 el...@pico-systems.com 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: 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
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
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
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
