2012/5/2 Michael Haberler mai...@mah.priv.at:
Assuing that existed: when you hit 'Pause' and 'switch to MDI', the following
things need to happen:
- The currently executing trajectory planner queue in motion is put to rest,
as is the executing task+interpreter instance (note I explored
Am 02.05.2012 um 08:22 schrieb Viesturs Lācis:
2012/5/2 Michael Haberler mai...@mah.priv.at:
Assuing that existed: when you hit 'Pause' and 'switch to MDI', the
following things need to happen:
- The currently executing trajectory planner queue in motion is put to rest,
as is the
2012/5/2 Michael Haberler mai...@mah.priv.at:
So, 'changing to MDI, fiddling some parameters and returning to auto with the
new parameter settings' in the general case isnt what you want because of the
side effects. What is probable doable is: use MDI mode as way to move around,
and
Am 02.05.2012 um 10:30 schrieb Viesturs Lācis:
2012/5/2 Michael Haberler mai...@mah.priv.at:
So, 'changing to MDI, fiddling some parameters and returning to auto with
the new parameter settings' in the general case isnt what you want because
of the side effects. What is probable doable
2012/5/2 Michael Haberler mai...@mah.priv.at:
The only change wrt to the interpreter is the access modality for tool length
offset and tooldiameter parameters (#54xx): so far those were considered
untainted because no entity except the interpreter could change them. They
now can change at
Am 02.05.2012 um 11:08 schrieb Viesturs Lācis:
2012/5/2 Michael Haberler mai...@mah.priv.at:
The only change wrt to the interpreter is the access modality for tool
length offset and tooldiameter parameters (#54xx): so far those were
considered untainted because no entity except the
2012/5/2 Michael Haberler mai...@mah.priv.at:
I'd think a set of HAL pins would be a starting point;
note that there's already 'motion.tooloffset.{a-w}', they are currently
read-only
Yes, You are right. HAL is the right answer!
Viesturs
Hi Michael,
I like it.
I take issues, though, with the final line: the implementation cost is
low: two bit masks per block, one bit mask per parameter
I agree that the implementation cost (I assume you mean execution time)
is low, but it is higher than what you say. You leave out the time for
OK -- I just have to go for a case where it might make sense to actually
do something during MDI while paused.
I'm machining a piece and notice a lot of vibration -- the part is not
clamped down well because the stock (a cast iron part) is not flat under
one of the clamps. I pause the
Michael,
It appears that there might be a problem with cutter radius
compensation. Whenever that mode is on, lookahead will be effectively
disabled because any pause can cause the diameter to change. (Or do I
not understand something?)
Regards,
Ken
On 5/2/2012 4:57 AM, Michael Haberler
Ken,
you're perfectly right.
I'll update the note with a rundown of per-parameter, per-block, and global
memory and processing 'cost'. I guess I was carried away when I wrote up what
looks like a CS101 homework in style that eventually, all it needs to do is
fiddle a few bitmasks.
It is
If we unify named and numbered parameters, it might also make sense to
have the parameter with the name 1 be the same as parameter #1.
Ken
On 5/2/2012 11:23 AM, Michael Haberler wrote:
Ken,
you're perfectly right.
I'll update the note with a rundown of per-parameter, per-block, and global
right, there's no point in keeping the distinction. it's going to be all names,
some a bit special.
- Michael
Am 02.05.2012 um 17:37 schrieb Kenneth Lerman:
If we unify named and numbered parameters, it might also make sense to
have the parameter with the name 1 be the same as parameter #1.
Am 02.05.2012 um 16:07 schrieb Kenneth Lerman:
Michael,
It appears that there might be a problem with cutter radius
compensation. Whenever that mode is on, lookahead will be effectively
disabled because any pause can cause the diameter to change. (Or do I
not understand something?)
Am 02.05.2012 um 18:24 schrieb Michael Haberler:
Am 02.05.2012 um 16:07 schrieb Kenneth Lerman:
Michael,
It appears that there might be a problem with cutter radius
compensation. Whenever that mode is on, lookahead will be effectively
disabled because any pause can cause the
on #linuxcnc-devel there's currently a discussion (mostly cradek and me in the
last few days) about a future linuxcnc design. In that context, 'queuebusters'
and the synchronization of interpreter state came up.
I think I came up with a more elegant, flexible and language independent
solution
2012/5/1 Michael Haberler mai...@mah.priv.at:
on #linuxcnc-devel there's currently a discussion (mostly cradek and me in
the last few days) about a future linuxcnc design. In that context,
'queuebusters' and the synchronization of interpreter state came up.
I think I came up with a more
Am 01.05.2012 um 22:35 schrieb Viesturs Lācis:
2012/5/1 Michael Haberler mai...@mah.priv.at:
on #linuxcnc-devel there's currently a discussion (mostly cradek and me in
the last few days) about a future linuxcnc design. In that context,
'queuebusters' and the synchronization of interpreter
2012/5/2 Michael Haberler mai...@mah.priv.at:
The background was the following: we discussed changes which would permit
changing tool offset and cutter radius during a pause operation.
Under the current scheme, this would mean:
- the handling of parameters 5400-5413 needs to be changed in
Am 01.05.2012 um 23:22 schrieb Viesturs Lācis:
2012/5/2 Michael Haberler mai...@mah.priv.at:
The background was the following: we discussed changes which would permit
changing tool offset and cutter radius during a pause operation.
Under the current scheme, this would mean:
- the
20 matches
Mail list logo
