Chris Morley wrote:
>
> Sorry I was talking of a possible way to incorporate dual joint homing as in
> a patch
> to master. I think your referring to how to do it with existing 2.5
> limitations.
>
Yes, but I'd sure like to see this problem get integrated somehow into
LinuxCNC. As it is, ther
> Date: Mon, 27 May 2013 14:34:18 -0500
> From: el...@pico-systems.com
> To: emc-developers@lists.sourceforge.net
> Subject: Re: [Emc-developers] axis.N.home-state
>
> Chris Morley wrote:
> >
> > -when one joint hits switch and index, it zeros the count, but
Chris Morley wrote:
>
> -when one joint hits switch and index, it zeros the count, but keeps moving
> both joints
>
The way it works now, in trivkins, and assuming HOME_OFFSET =0, is that
the axis stops immediately when it hits the index pulse. Assuming both
sides
are close to their home p
> Date: Mon, 27 May 2013 11:17:24 -0500
> From: el...@pico-systems.com
> To: emc-developers@lists.sourceforge.net
> Subject: Re: [Emc-developers] axis.N.home-state
>
> John Thornton wrote:
> > One more rambling thought could you move both motors together through
> &
John Thornton wrote:
> One more rambling thought could you move both motors together through
> the whole search, back off, slow seek move and record the offset counts
> between the two and at the end of the homing move square the gantry by
> moving each motor 1/2 the distance toward the other an
It seems to me that gantry homing needs to not be a set sequence but
rather a configurable sequence that the integrator can set up to suit
the machine. From reading all the chatter on this it appears not all
gantries are the same or require the same homing sequence.
It seems that there are vari
Dave wrote:
> Perhaps the solution to this situation is to not use index pulse homing
> on a gantry machine and simply use a precision home limit switch on each
> side of the gantry?
>
Well, if I sell a system to the customer, then we will see how the machine
is actually built, and whether the
On 5/25/2013 6:26 PM, Jon Elson wrote:
> Tom Easterday wrote:
>
>> In practice you will rarely have to realign the encoder indexes.
>>
>>
> Right, we expect it needs to be only done once unless the machine is pulled
> apart for repairs.
>
> Jon
>
> --
On 25 May 2013 23:24, Jon Elson wrote:
> This may also be a moot problem, as we may make some progress
> on this at the fest.
Indeed.
I rather think that nearly all the parts are there. One missing part
is paired gantries waiting for each other to finish a stage.
(My first guess is that if the
Tom Easterday wrote:
> In practice you will rarely have to realign the encoder indexes.
>
Right, we expect it needs to be only done once unless the machine is pulled
apart for repairs.
Jon
--
Try New Relic Now & We'll
andy pugh wrote:
> 4) One motor (could be either) sees the index, and the axis position
> is set to HOME_OFFSET. It then rapids to HOME_POSITION
>
>
> During 4) the rapid is a serious concern.
>
>
Right, this is the big problem. So, HOME_OFFSET must be zero for both
sides, and you can't use HOM
On May 25, 2013, at 12:40 AM, Jon Elson wrote:
> But, the first side to find the index marker will stop there, the second
> side will
> have to travel to the index mark, thereby racking the gantry. that is
> unacceptable.
> So, the two encoders MUST have the index marks aligned. Depending on
On 24 May 2013 18:00, Dave wrote:
> I think index homing on a gantry would only be worthwhile if home
> offsets could be applied after the index/marker pulse was found.
They are. When the index is seen then the axis position is set to the
HOME_OFFSET from the INI file.
(Actually, I am making an
On May 25 2013 12:21 PM, Jon Elson wrote:
> Dave wrote:
>>
>> If you have a big gantry, you don't want to have to rotate the
>> motors or
>> encoders to get the index pulses aligned.
>>
>> Consider a gantry that has 1+ kw motors on each side of the gantry
>> with
>> gearboxes and encoders integra
Dave wrote:
>
> If you have a big gantry, you don't want to have to rotate the motors or
> encoders to get the index pulses aligned.
>
> Consider a gantry that has 1+ kw motors on each side of the gantry with
> gearboxes and encoders integral to the motors.
>
> That would not work.
>
So, your
On 5/25/2013 12:34 AM, Jon Elson wrote:
> andy pugh wrote:
>
>> I understand that gentrivkins and ja3 works acceptably, but I have no
>> idea if this also includes index-homing. It seems to me that it can
>> only really work if the two indexes are set up in the right place.
>> (or, I suppose, i
Dave wrote:
>>
>> I suggested it earlier as a way to check that two slaved axes were
>> acceptably in-synch.
>> One unpleasant scenario in the machine described is the failure of one
>> home-switch, but not the other. I suggested a component that would
>> panic if one axis was still searching more
andy pugh wrote:
> I understand that gentrivkins and ja3 works acceptably, but I have no
> idea if this also includes index-homing. It seems to me that it can
> only really work if the two indexes are set up in the right place.
> (or, I suppose, if the encoder components grew a fixed-offset pin)
>
On Fri, May 24, 2013 at 11:36:11AM -0500, Jon Elson wrote:
> Great, this has come up several times in the past, and I really didn't
> have a way
> to test anything short of building a mockup. I could bring a few extra
> pieces
> of hardware too, if that helps.
My mockup is nice, and is good an
On 5/24/2013 12:18 PM, andy pugh wrote:
> On 24 May 2013 17:02, Chris Radek wrote:
>
>
>> I thought it was a pin already. I had always thought (in my "it
>> shouldn't be too hard..." way) that keying off that would be a way
>> to make an external component that slaves two motors and fakes all
Chris Radek wrote:
>
> I still hope to work on joint slaving at fest next month - I have
> the test hardware built and with jepler's help (a loaner 7i30 and
> 5i20) I should have the hardware to run it.
Great, this has come up several times in the past, and I really didn't
have a way
to test anyth
On 24 May 2013 17:02, Chris Radek wrote:
> I thought it was a pin already. I had always thought (in my "it
> shouldn't be too hard..." way) that keying off that would be a way
> to make an external component that slaves two motors and fakes all
> the home signals etc. It'd be pretty horrible bu
On Fri, May 24, 2013 at 10:43:16AM +0100, andy pugh wrote:
> I don't see any reason for this to be a parameter. And I can think of
> a use for it as a pin. (see users list, gantry thread)
>
> A parameter-to-pin switch should never break any configs, so I suggest
> changing it to an output pin, and
andy pugh wrote:
>On 24 May 2013 15:38, Sebastian Kuzminsky wrote:
>
>> I object to changing it in 2.5, but i don't object to changing it in
>master (if you test it and make sure none of the sample configs break).
>
>I can't test every sample config, I don't have all the hardware.
>I can confi
On 24 May 2013 15:38, Sebastian Kuzminsky wrote:
> I object to changing it in 2.5, but i don't object to changing it in master
> (if you test it and make sure none of the sample configs break).
I can't test every sample config, I don't have all the hardware.
I can confirm that a gitweb grep ind
On May 24, 2013, at 03:43 , andy pugh wrote:
> I don't see any reason for this to be a parameter. And I can think of
> a use for it as a pin. (see users list, gantry thread)
>
> A parameter-to-pin switch should never break any configs, so I suggest
> changing it to an output pin, and pushing that
26 matches
Mail list logo
