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 bef
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
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
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.
Th
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 di
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
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
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-deskto
> > 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
&
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 counte
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
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).
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-
13 matches
Mail list logo
