Here's Ken Lerman's idea worked in: jog in coordinated mode during pause
http://www.youtube.com/watch?v=2wabcOH9YAA
I'm entertaining feedback on the principle; this is not a patch yet; it's still
shaky on abort and limit checking.
The nice thing is that it's fairly unintrusive - all through H
Looking good. Is this capable of using the existing jog mechanism? For
instance I have MPGs on my machines so ideally they need to still
function correctly.
Les
On 26/04/2012 09:10, Michael Haberler wrote:
> Here's Ken Lerman's idea worked in: jog in coordinated mode during pause
>
> http://www
Am 26.04.2012 um 11:48 schrieb Les Newell:
> Looking good. Is this capable of using the existing jog mechanism?
not as it stands now, it just honors an offset pose input via HAL if enabled
but I dont see a reason in principle why it shouldnt work; worst case is a
separate HAL comp to deal with
2012/4/26 Michael Haberler :
>
> The only gotcha I see is - this is coord mode, so its axes not joints input,
> this might be a bit confusing for an MPG and a non-trivkin machine
Well, I think that it is great that it is axes, not joints... How will
You jog a puma robot straight up (not to break
so what's the idea?
Do you want to have the option to jog in coordinated mode in manual?
- Michael
Am 26.04.2012 um 12:53 schrieb Viesturs Lācis:
> 2012/4/26 Michael Haberler :
>>
>> The only gotcha I see is - this is coord mode, so its axes not joints input,
>> this might be a bit confusing
2012/4/26 Michael Haberler :
> so what's the idea?
>
> Do you want to have the option to jog in coordinated mode in manual?
>
Ideally - INI file option for automatic switching to teleop mode as
soon as all joints are homed. So that user does not interact with
joint mode - they tend to forget about
Makes sense to me. Except inthe case of an emergency, how do you want to
jog away from a limit switch Viesturs?
It is ultimately a joint that is out of bounds then.
j.
On Thu, Apr 26, 2012 at 2:57 PM, Viesturs Lācis wrote:
> 2012/4/26 Michael Haberler :
> > so what's the idea?
> >
> > Do you
If you were running a gantry, I would think that it would still be
pretty obvious which way you would need to move even in
coordinated mode with non trivial kinematics.
Dave
On 4/26/2012 9:08 AM, Jan de Kruyf wrote:
> Makes sense to me. Except inthe case of an emergency, how do you want to
> jog
yes, but hexapods and robots are a problem
j.
On Thu, Apr 26, 2012 at 3:42 PM, Dave wrote:
> If you were running a gantry, I would think that it would still be
> pretty obvious which way you would need to move even in
> coordinated mode with non trivial kinematics.
>
> Dave
>
> On 4/26/2012 9
Il giorno gio, 26/04/2012 alle 13.53 +0300, Viesturs Lācis ha scritto:
> 2012/4/26 Michael Haberler :
> >
> > The only gotcha I see is - this is coord mode, so its axes not joints
> > input, this might be a bit confusing for an MPG and a non-trivkin machine
>
> Well, I think that it is great that
2012/4/26 Jan de Kruyf :
> yes, but hexapods and robots are a problem
>
There is no way to jog single joint on hexapod without causing damage
to the construction of machine!
Jogging in "joint" mode is dangerous with machines with parallel
kinematics, including gantries. It is awkward for serial ki
Mmm, yes you might be very right.
I postulated a theoretical case there, since I have no real experience to
speak of on those machines.
OK, so what about the old trusted way of supplying a springloaded
key-switch in the electrical cabinet that allows joint mode.
But at the same time travel in the
I liked the idea of automatically switching back to world mode, so the
user has to work at getting back to joint mode. I guess this could be
disabled on some machines (like hexapods), but I can see joint mode
being useful for setting up and calibrating. Regardless, I think it
would be very go
On Thu, 26 Apr 2012 13:53:51 +0300, Viesturs Lācis wrote:
> ...
>
> As I have said before - IMHO after homing joint mode is _never_
> needed
> for normal operation of machine. Especially non-trivial kinematics.
> When something is wrong and debugging is needed - yes, then there
> might be necessit
2012/4/27 EBo :
>
> but I can see joint mode
> being useful for setting up and calibrating.
Just like You mentioned - for setting up, calibration. I would add
also troubleshooting and debugging.
IMHO all of these things are outside "normal everyday use" realm.
> Actually, this makes sense. How a
> Either by pressing button (Jan would like that)
Bitter experience with the human race, and more particularly the subspecies
that habitually operates machines:
The are very good at confusing computers.
And at the same time a properly implemented switch needs the supervisor to
attend the correct
In my view, there are three different roles that we consider:
1 -- the system integrator
2 -- the supervisor (or owner)
3 -- the operator
Changing .ini files is the part of the integrator role.
Fixing problems when a limit switch is hit is an owner role.
Running the machine is an operator role.
On 27 April 2012 14:56, Viesturs Lācis wrote:
> Basically it is needed to do this only once after the machine is
> homed, so I tried to do this on rising edges of "is-homed" pins, but
> this approach failed as I could not predict, how long time would be
> between first and last joint to get homed
2012. gada 27. aprīlis 18:45 andy pugh rakstīja:
>
> You probably needed a oneshot linked to the output of your and5.
Hmm, and then next time oneshot would output a signal would be, when
and5 output had rising edge, respectively, at least one joint was
unhomed and rehomed.
This one really _should
On 27 April 2012 17:35, Viesturs Lācis wrote:
> But that "non-writing
> state" is something I am not sure I have ever seen, not to speak of
> actually coding that by myself.
The "tristate" functions do that, they are useful for writing to
bidirectional HAL pins, and only output a value on reque
2012/4/27 andy pugh :
> On 27 April 2012 17:35, Viesturs Lācis wrote:
>
>> But that "non-writing
>> state" is something I am not sure I have ever seen, not to speak of
>> actually coding that by myself.
>
> The "tristate" functions do that, they are useful for writing to
> bidirectional HAL pins,
I had to write a component recently had incorporated "edge functions" -
I just looked at the code for the edge function and incorporated that
concept into my custom component.
Basically the edge function remembers the last state and when the state
changes, ( the current state is not the same as
It is not written to in that case.. IE it is not assigned a value.
Dave
On 4/27/2012 12:52 PM, Viesturs Lācis wrote:
> 2012/4/27 andy pugh:
>
>> On 27 April 2012 17:35, Viesturs Lācis wrote:
>>
>>
>>> But that "non-writing
>>> state" is something I am not sure I have ever seen, not
On 27 April 2012 18:05, Dave wrote:
> I looked at the tri-state comp functions and although I understand what
> a tri state is, I didn't see it as really being very useful.
Its main use is probably simply as an interface between IO pins (such
as the PID gain pins) and output pins. You can't norm
2012/4/27 Dave :
> It is not written to in that case.. IE it is not assigned a value.
>
Sorry, but I think that there are 2 options - either it is 0 or 1.
Your answer seems to indicate that there is third option. Or is it too
much beer for one evening?
Viesturs
>
> On 4/27/2012 12:52 PM, Vies
>>Or is it too much beer for one evening?
Or not enough.. ;-)
That is why it is called a "Tri" (as in three) state.
There is on, off, and don't write the value.
Dave
On 4/27/2012 2:03 PM, Viesturs Lācis wrote:
> 2012/4/27 Dave:
>
>> It is not written to in that case.. IE it is not assi
On 4/27/2012 1:45 PM, andy pugh wrote:
> On 27 April 2012 18:05, Dave wrote:
>
>
>> I looked at the tri-state comp functions and although I understand what
>> a tri state is, I didn't see it as really being very useful.
>>
> Its main use is probably simply as an interface between IO pins
2012/4/27 Dave :
>>>Or is it too much beer for one evening?
>
> Or not enough.. ;-)
>
> That is why it is called a "Tri" (as in three) state.
>
> There is on, off, and don't write the value.
>
So output holds whatever value it has at the moment, when enable goes false?
Viesturs
-
On 27 April 2012 19:03, Viesturs Lācis wrote:
> Sorry, but I think that there are 2 options - either it is 0 or 1.
> Your answer seems to indicate that there is third option.
Think in terms of TTL logic, there is 0V, 5V or unconnected.
In the latter case the value will be whatever anything else
On 27 April 2012 19:33, Viesturs Lācis wrote:
> So output holds whatever value it has at the moment, when enable goes false?
In practice a HAL pin is a memory location in shared memory, used by
one or more variables inside the net-ed components.
So it can be written "true" on each thread cycle,
For tri-state, don't write to the pin. Normally components process the
input and write to the output every cycle. However if you only write to
the pin when your data changes you get a sort of tri-state.
A normal component:
read inputs
do something
write to pin
A tri-state component:
read input
2012/4/27 Les Newell :
> You can connect a number
> of tri-state outputs together and they (mostly) won't fight. A better
> solution is to have an 'enable' input. When the enable is true you
> update the output every cycle as normal. When it is false you leave the
> output alone. You do then have t
On 4/27/2012 3:00 PM, Viesturs Lācis wrote:
> 2012/4/27 Les Newell:
>
>> You can connect a number
>> of tri-state outputs together and they (mostly) won't fight. A better
>> solution is to have an 'enable' input. When the enable is true you
>> update the output every cycle as normal. When it is
Viesturs Lācis wrote:
> 2012/4/27 Dave :
>
>> It is not written to in that case.. IE it is not assigned a value.
>>
>
> Sorry, but I think that there are 2 options - either it is 0 or 1.
> Your answer seems to indicate that there is third option. Or is it too
> much beer for one evening?
34 matches
Mail list logo
