did you see I totally changed the change request about homing?
after you said you agreed with me :-)
the one that wanted to verride soft limits? or something else
the one where I wanted "unhome"
I've decided that's not the real request
[00:21:39] <cradek> https://sourceforge.net/tracker/?func=detail&atid=356744&aid=1491243&group_id=6744
you have some good points there
good for 2.2 ;-)
I guess "override limits should override soft limits too" is still an important part of it
yes I've been tempted to put it in the trunk
just need a few more messages from the guis, passed through the layers, handled in motion
so how would you set soft limits?
would it remember the new values?
that gui button should be optional;
after switching emc off I mean
yeah I don't know
if you have a machine with real home switches, the machine builder is gonna want to set limits that the operator can't change
maybe have some big soft limits (never overrideable)
and some params which are a subset of that
jmkasunich: what I'm saying agrees with you :)
so you can set some job specific soft limits
jmkasunich: I disagree. think of a tailstock. home switch or not has little to do with it
or did you mean limit?
still inside the machine soft limits, inside of machine hardware limits
agreed - but think of a mazak - the override-soft-limits button should not work there
(fwiw I home my machines without home switches at all)
cradek: same here.. but I know how it's supposed to work
why not allow the user to set a (lower Z) soft limit when he puts in a tool or probe?
you might want additional limits for things like tailstocks or clamps, but that doesn't mean the basic ones should be overrideable from the GUI
if you allow that, you have to allow the override too
the soft limits for robots prevent it to crash any joints
ok I see
the ones you set at the gui would be INSIDE the inifile soft limits
yes, that's what I've been saying :)
true clamp/tailstock/chuck avoidance is more than limits on a per axis basis anyway
its a 3D thing
what we're talking about is not _changing_ the behavior of the existing soft limtis, its about adding a new set of limits
and I'm all in favor if we take that approach
maybe you're right
of course I'm right, I'm always right ;-)
but the override soft limits might still be usefull/needed
obtw, I think I've managed to make a mess of halcmd.c ;-)
jmkasunich: when you're not left
er.. that should have been:
I'm afraid I'm not making the decision about backporting net any simpler
because I've been changing stuff, which makes the backport riskier
I thought we *had* decided to backport net
but I wanted to review it first
when I started, I made the mistake of looking at other stuff in halcmd
found some potential buffer overflows in the code that substitutes ini file vars and/or env vars into halcmd input lines
and found inconsistencies (which jepler had already noted) in the handling of OUT and IO pins by net
the same inconsistencies also existed in linksp and linkps, but I couldn't leave well enough alone
the inconsistency was:
you could add an IO pin to a signal already containing an OUT pin, but you couldn't add an OUT pin to a signal already containing an IO pin
are the index enables really the only IO pins?
I think so, but we have a lot of components.... I no longer trust my memory
I don't have a good grasp of how IO pins should work
seems like you would hook two of them together, and not much else
think tri-state logic chips
that's how index enable works
you can hook IO to other IO, or input
but no output allowed
a signal can have any number of input plus any number of IO or _one_ output, but not both
builds are really slow when four are going on at once
I mean five
cradek: did you see the email from Frank Jungclaus?
I should test that (I thought it worked)
I see in his traceback that he is using a recent cvs head...
jmkasunich: you around?
but you're not
hey if you don't respond in 1 minute, he doesn't have time for you
hello again :)
jmkasunich: still watching?
is the problem about the pin or the jump or both or??
the jump, in some cases
i got some old code... tcltk tkdial and it worked pretty well
the solution I thought of is to check the scale for changes, and if a change is detected, set an internal offset to the current output
the output is always internal_offset + (delta since changing offset * scale)
uh, i'm still trying to understand...
you wacth for a change in scale ( like changing 10x to 100x on microscope )?
that kinds scale change?
yeah, but possibly with finer granularity than that
like .0001 to .000001
that's still several orders of magnitude
even from 1.0 to 1.1 should be looked for, I think
consider what happens if the output is 25000, and you cahnge the scale from 1 to 10 ...
what is 1 unit of change worth?
depends on what it's driving
i think 1unitofchg is multiplied by the scale you mention
you guys still hashing out a wheel widget?
don't scale the output, scale the change in output
differentiate, scale, integrate
in that order
that's basically what I was describing
but use a constant as the base for differences, and update it when the scale changes
(which is more complex, I guess)
whats the benefit of that approach
none, now that you mention it ;)
am i following you? diiferentiate, scale, integrate = old-new, (old-new)*scale, sum=oldsum+ ((old-new*scale) ??
actually, you're generating the counts, so you don't really need to differentiate
the code that says "out = out +- 1" would change to out = "out +- scale"
minus the quoting error :)
right a discrete change what do you say to soemthng like the jogwheel with radio buttons for 10^n
I'd say leave the radio buttons as a separate thing that gets connected in HAL
outside the widget?, something that wired to it thru hal?
however - a set of radio buttons that can select from one of a series of float values (output on one pin), rather than an array of booleans, may be a good thing
the more specific you make things, the harder they are to use for anything you didn't think of when you wrote them
right, i try to make lists of uses , i call the useless lists :)
ok, i gotta think this over a bit. thanks
is the source for the jogwheel in CVS at all?
yes, and a new one today, awallin chgd the pointedStick to a speedknob of sorts
ah right - I remember that message now. thanks
jepler: do you think its a good idea to put up a testing package somewhere?
* jepler shrugs
is that a shrug yes or shrug no ?
I thought the board had talked about this and decided ... something
tomp: hi, I'm working, but will reply here every now and then :)
no problem, me too
i'm restarting on the widget, didnt like tkturndial, and asked for guidance last nite
JMK said to look at a comp 'knob2float'
that's a hal component afaik
if you want a knob widget, look at pyvcp_jogwheel
i had the idea use a simlified jogwheel 'ticker' that output tiks
the tiks got scaled, and accumulated
can comps be used in pyvcp? (SWP wanted the function bundled inside the widget to avoid hal wiring)
tomp: comps wouldnt be 'in' pyvcp
you would first create the panel
then load the comp
then hooku everything
can the description and hookup be done thru pyvcp? or would it be 'kludge' ?
but yes, it would be cleaner to do the calculation in python
tomp: there's halrun if you want to do everything in a script
hmmm, where could i see a halrun example?
wiki shows the cmd format ( broken link ) but i see the format,
so bundling into single place is good for user, scaling a tik & accumulating is good, i'll go that route now, thanks
jmk posted something about DRO pwith pyvcp
user group post or irc?
the mailing list
he had an example halrun file there also
ok, back to the email machine :) tromp tromp tromp...