As I am used to saying and hearing
Strive for perfection, but done beats perfect
B
On Thu, May 24, 2012 at 1:31 PM, Kent A. Reed wrote:
> On 5/24/2012 1:13 PM, Jon Elson wrote:
> > Well, not really elegant, but I think it would work, and not require
> months
> > of firmware design.
> That mak
On 5/24/2012 1:13 PM, Jon Elson wrote:
> Well, not really elegant, but I think it would work, and not require months
> of firmware design.
That makes it elegant, at least in my world where the perfect is not
allowed to be the enemy of the good.
Regards,
Kent
Jeshua Lacock wrote:
>
> Would you be interested in designing and building me a few? Just let me know
> what it might cost (on or off list is fine with me).
>
Well, I guess I could do that. I'll have to look up some parts and see how
simple I could get it. I have a Gecko 320 here for testing
Kent A. Reed wrote:
>
> Well, shoot, can't we make it more complicated? This sounds like a Don
> Lancaster solution straight out of the pages of Popular Electronics :-)
> In the good old days I could think this way but 40 years of digital
> electronics have fried my brain.
>
Yeah, this is not
What is your opinion of such a solution:
put simple magnets on all of the motor shafts, install hall-sensor, connect it
to LinuxCNC and program it to estop when encoder and hall-sensor signals
mismatch. Good recommendation I think would be to connect hall-sensor and
encoder using different cabl
Le 23.05.2012 19:11, Jon Elson a écrit :
>> On May 23, 2012, at 2:01 AM, Claude Froidevaux wrote:
>>
>>
>>> 1) make a hal check, that disable drive if more than 5-10 consecutive
>>> sample period with maximum drive output without any encoder change
>>>
>>>
> This won't work in Jeshua's setup. Whe
Hi Kent,
The GeckoDrive G320X (latest drives) now have inbuilt encoder failure
detection, which asserts the Fault output when the failure is detected.
Cheers,
Peter
---
Peter Homann
http://www.homanndesigns.com/store
On Thu 24/05/12 1:06 PM , "Kent A. Reed"
On May 23, 2012, at 8:45 PM, Jon Elson wrote:
> I think a very simple circuit, largely analog plus some one
> shots and
> a logic gate could do it. Probably 3 chips per axis. Some RC feeding an
> opto-coupler, a 74HC123 and a gate package. If the output to the motor
> exceeds some value (may
On 5/23/2012 10:45 PM, Jon Elson wrote:
> Kent A. Reed wrote:
>> Of course all roads lead to LinuxCNC, but is there some reason one
>> couldn't/wouldn't start with one of the many microcontroller chips or
>> even ARM-based SoCs and build a separate watchdog for the purpose of
>> detecting and stop
On Wed, 23 May 2012, Jon Elson wrote:
> Date: Wed, 23 May 2012 21:31:26 -0500
> From: Jon Elson
> Reply-To: "Enhanced Machine Controller (EMC)"
>
> To: "Enhanced Machine Controller (EMC)"
> Subject: Re: [Emc-users] Encoder Redundancy?
>
>
Kent A. Reed wrote:
> Of course all roads lead to LinuxCNC, but is there some reason one
> couldn't/wouldn't start with one of the many microcontroller chips or
> even ARM-based SoCs and build a separate watchdog for the purpose of
> detecting and stopping servo runaway in its tracks? It would
John Kasunich wrote:
>
> I guess I must have missed something. I never saw him say he was using
> drives with step/dir inputs.
Gecko G320
> If that is the case, then he probably
> isn't
> using PID loops at all - the drives are closing the position loop and
> LinuxCNC is treating them like st
Peter C. Wallace wrote:
> Which is a good illustration of the limitations of step/dir servos since
> LinuxCNC can't "see" whats happening in the drive, which rules out a lot of
> hardware fault mitigation strategies.
>
Well, really, detecting all possible cases of a failed encoder is not
that
Peter C. Wallace wrote:
>
> I think the saturated PID output is a fairly good way to detect this
> condition
> and certainly would have workied in this circumstance.
No, I believe not. This happened probably before the LinuxCNC PID loop
was even
turned on. It was purely the G320 coming active
On 5/23/2012 3:29 PM, John Kasunich wrote:
>
> On Wed, May 23, 2012, at 12:13 PM, Jon Elson wrote:
>> andy pugh wrote:
>>> On 23 May 2012 07:08, Jeshua Lacock wrote:
I am guessing there is not an easy way to detect this condition,
>>> It should be possible to check if your PID is saturated fo
On Wed, May 23, 2012, at 12:13 PM, Jon Elson wrote:
> andy pugh wrote:
> > On 23 May 2012 07:08, Jeshua Lacock wrote:
> >> I am guessing there is not an easy way to detect this condition,
> >
> > It should be possible to check if your PID is saturated for more than
> > a second or so.
> >
> B
e:
>
> > Date: Wed, 23 May 2012 12:13:34 -0500
> > From: Jon Elson
> > Reply-To: "Enhanced Machine Controller (EMC)"
> >
> > To: "Enhanced Machine Controller (EMC)" >
> > Subject: Re: [Emc-users] Encoder Redundancy?
> >
> &
On Wed, May 23, 2012 at 07:38:06AM -0400, John Kasunich wrote:
>
> If your PID loop is saturated during normal operation, that
> means you are no longer accurately controlling tool position,
Yes! I have pid.N.saturated hooked directly to axis.N.amp-fault-in on
both my machines. Properly tuned
On Wed, 23 May 2012, Jon Elson wrote:
> Date: Wed, 23 May 2012 12:13:34 -0500
> From: Jon Elson
> Reply-To: "Enhanced Machine Controller (EMC)"
>
> To: "Enhanced Machine Controller (EMC)"
> Subject: Re: [Emc-users] Encoder Redundancy?
>
> andy
andy pugh wrote:
> On 23 May 2012 07:08, Jeshua Lacock wrote:
>
>
>> I am guessing there is not an easy way to detect this condition,
>>
>
> It should be possible to check if your PID is saturated for more than
> a second or so.
>
But, this still doesn't detect a servo runaway when the
> On May 23, 2012, at 2:01 AM, Claude Froidevaux wrote:
>
>
>> 1) make a hal check, that disable drive if more than 5-10 consecutive
>> sample period with maximum drive output without any encoder change
>>
>>
This won't work in Jeshua's setup. When coming out of E-stop, there is
no com
Jeshua Lacock wrote:
> Jon, can your power switch and braking module (and/or the brake on the Gecko
> Interface) be used like for something like this?
>
This is EXACTLY the condition it is designed for, BUT, it needs to know
that a problem
exists. You should have hit the E-stop button when th
Lester Caine wrote:
> Jeshua Lacock wrote:
>
>> I am guessing there is not an easy way to detect this condition, but I
>> wanted to see if anyone else has any thoughts on the subject.
>>
>
> I would have thought that if the motor turned more than 1/2 a turn or so but
> the
> encoder feed
On Wed, 23 May 2012, Jeshua Lacock wrote:
> Date: Wed, 23 May 2012 00:08:12 -0600
> From: Jeshua Lacock
> Reply-To: "Enhanced Machine Controller (EMC)"
>
> To: "Enhanced Machine Controller (EMC)"
> Subject: [Emc-users] Encoder Redundancy?
>
>
Jeshua Lacock wrote:
> Greetings,
>
> I turned on the power to my system today and my 180 pound gantry shot full
> speed crashing hard into the end of my table.
>
>
>
> I was a stumped at first as the last time I used it everything was stable. It
> turns out that I had a loose connection to the e
On 23 May 2012 15:19, dave wrote:
> Les Watts had some interesting shock absorbers on his router.
> Half-inch threads on the cylinder with about .75 travel on the plunger.
They are reasonably standard components.
http://www.slamproof.co.uk/Industrial-Shock-Absorbers
Though not cheap
http://uk.rs
On Wed, 23 May 2012 08:36:46 +0100
Lester Caine wrote:
> Jeshua Lacock wrote:
> > I am guessing there is not an easy way to detect this condition,
> > but I wanted to see if anyone else has any thoughts on the subject.
>
> I would have thought that if the motor turned more than 1/2 a turn or
> s
Le 23.05.2012 10:05, Jeshua Lacock a écrit :
> On May 23, 2012, at 2:01 AM, Claude Froidevaux wrote:
>
>> 1) make a hal check, that disable drive if more than 5-10 consecutive
>> sample period with maximum drive output without any encoder change
>>
>> 2) if you use a hal encoder (brushless motor),
I really like this approach, but I think one second is far
too long of a delay.
If your PID loop is saturated during normal operation, that
means you are no longer accurately controlling tool position,
and are probably making scrap parts. So you should adjust
your accel down until it never satura
On 23 May 2012 07:08, Jeshua Lacock wrote:
> I am guessing there is not an easy way to detect this condition,
It should be possible to check if your PID is saturated for more than
a second or so.
loadrt debounce cfg=3
addf debounce.0 servo-thread
setp debounce.0.delay 1000 #1 second delay in a
On May 23, 2012, at 2:01 AM, Claude Froidevaux wrote:
> 1) make a hal check, that disable drive if more than 5-10 consecutive
> sample period with maximum drive output without any encoder change
>
> 2) if you use a hal encoder (brushless motor), use it as second encoder,
> and cut motor power
1) make a hal check, that disable drive if more than 5-10 consecutive
sample period with maximum drive output without any encoder change
2) if you use a hal encoder (brushless motor), use it as second encoder,
and cut motor power if more than about 20° of error between both
theses are not perf
On May 23, 2012, at 1:11 AM, Roland Jollivet wrote:
> I'm no expert on this, but I think there should be a secondary limit switch
> connected to a relay and a power resistor. If this is activated, it will
> connect the motor directly across the resistor. The resistor should be
> matched so that t
On May 23, 2012, at 1:36 AM, Lester Caine wrote:
> Jeshua Lacock wrote:
>> I am guessing there is not an easy way to detect this condition, but I
>> wanted to see if anyone else has any thoughts on the subject.
>
> I would have thought that if the motor turned more than 1/2 a turn or so but
>
Jeshua Lacock wrote:
> I am guessing there is not an easy way to detect this condition, but I wanted
> to see if anyone else has any thoughts on the subject.
I would have thought that if the motor turned more than 1/2 a turn or so but
the
encoder feed produced no pulses then this would be an ea
On 23 May 2012 08:08, Jeshua Lacock wrote:
>
> Greetings,
>
> I turned on the power to my system today and my 180 pound gantry shot full
> speed crashing hard into the end of my table.
>
> It hit with so much force it actually lifted the front two legs of the
> 500+ pound table 6+ inches off the
Greetings,
I turned on the power to my system today and my 180 pound gantry shot full
speed crashing hard into the end of my table.
It hit with so much force it actually lifted the front two legs of the 500+
pound table 6+ inches off the floor! Yikes!
Luckily the machine only suffered minor d
37 matches
Mail list logo