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