Back
[01:13:41] <jmkasunich> jepler: around?
[01:17:36] <jmkasunich> I'm trying to decide what to do with a patch from Dewey Garrett
[01:18:00] <jmkasunich> this isn't the halscope one, this is a simpler (I thought) one for hal_joystick
[01:18:42] <jmkasunich> the existing hal_joystick uses "hal_joystick<pid>" as the component name, and "joystick.0" as the default prefix for pins, etc
[01:18:54] <jmkasunich> there is a cmd line arg for changing the prefix, the comp name is fixed
[01:19:47] <jmkasunich> that fails when you use halcmd loadusr -W hal_joystick, because it waits for "hal_joystick" not "hal_joystick<pid>"
[01:20:11] <jmkasunich> and you can't use Wn, because you don't know what <pid> is gonna be
[01:20:32] <jmkasunich> (I used pid to allow you to load multiple instances)
[01:21:44] <jmkasunich> dewey's patch uses the same string for both the prefix and the comp name - default "joystick.0", but settable with cmd line option, as before
[01:22:02] <jmkasunich> wait, I got that wrong
[01:22:26] <jmkasunich> the default is "hal_joystick", but you can change it on the cmd line
[01:22:45] <jmkasunich> making the default comp name the same as the executable name makes -W work
[01:22:59] <jmkasunich> and making it the same as the cmd line settable custom prefix lets -Wn work
[01:23:51] <jmkasunich> but it means that pin names will be with "hal_joystick.foo" instead of "joystick.0.foo"
[01:24:14] <jmkasunich> I was gonna ask you about how -Wn and -W worked, but I think just typing it out has helped me figure it out
[01:25:21] <jmkasunich> does hal_input allow you to load multiple instances? (my python reading skills have gone away, but it seems the answer is no)
[01:25:48] <jmkasunich> the comp name is hardcoded to "hal_input" to keep -W happy,. and the prefix is "input"
[01:26:23] <jmkasunich> I don't like the part of dewey's patch that prepends "hal_" to every signal name
[01:36:46] <jepler> jmkasunich: hal_input lets you load any number of devices in one invocation, so there's no need for multiple instances.
[01:37:28] <jmkasunich> that makes it inconvenient if you want to load another one "later", but it is no worse than the situation with RT comps
[01:38:01] <jmkasunich> I guess my choices are:
[01:38:50] <jmkasunich> 1) use his patch - default pin names change, you can still use multiples if you read between the lines
[01:39:24] <jmkasunich> 2) hardcode the name to "hal_joystick", and keep the default prefix the same - you can only load one, but pin names don't change
[01:39:36] <jepler> can you do multiple joysticks with one invocation?
[01:39:47] <jmkasunich> not as currently coded
[01:40:04] <jmkasunich> and since input supersedes joystick, I don't want to re-code it
[01:40:45] <jmkasunich> 3) add command line options to independently set name and prefix, default name hal_joystick to keep -W happy, default prefix joystick,0 to keep the pin names the same
[01:41:37] <jepler> what about this: comp name hal_joystick + prefix joystick by default, with argument use for both prefix and component name. So 'loadusr -W hal_joystick /dev/js0' works, and 'loadusr -Wn stick2 hal_joystick -c stick2 /dev/js1' works too
[01:42:01] <jmkasunich> -c = comp name?
[01:42:31] <jepler> whatever switch letter you like -- I think pyvcp uses -c for this purpose. -n might make sense too.
[01:43:38] <jmkasunich> do you mean use the same cmd line option to set both prefix and name (to the same value) but have the defaults be two different values? or do you mean have two options, one to set comp name and one to set prefix?
[01:43:48] <jepler> the former
[01:44:11] <jmkasunich> I was thinking the latter, but I really can't come up with a valid reason to have two different names
[01:44:41] <jmkasunich> -p is already used to set the prefix, I wouldn't change the letter
[01:44:50] <jmkasunich> I would just have it set the comp name at the same time
[01:44:58] <jmkasunich> that sounds like a good solution
[01:44:59] <jepler> ah, hm. I didn't know there was a -p.
[01:45:19] <jmkasunich> -p was all that was needed prior to -W
[01:45:34] <jmkasunich> the name could be anything, only the prefix had to be unique
[01:45:41] <jepler> yeah
[01:46:00] <jepler> too bad my implementation of 'halcmd -W' is based on component name and not .. something else that I didn't think of at the time
[01:46:04] <jepler> (and still haven't)
[01:46:15] <jmkasunich> I can't think of anything else that would be more suitable
[01:46:25] <jmkasunich> I'm liking this solution
[01:46:43] <jmkasunich> minimal changes to the man page (just add a note that -p changes the comp name as well as the prefix)
[01:46:51] <jmkasunich> and minimal code changes
[01:47:08] <jmkasunich> (dewey also fixed the fact that joystick wasn't calling hal_ready)
[01:47:24] <jmkasunich> I'm gonna do that
[01:47:25] <jepler> I guess people have to change the inifile anyway to take advantage of hal_joystick working with loadusr -W, so nobody will have a broken configuration if -p changes a component name
[01:47:37] <jepler> that sounds fine to me
[01:47:44] <jmkasunich> while I have you here...
[01:48:04] <jmkasunich> do you know anything about what would be needed to give halscope a menu bar (File, etc, menus)?
[01:48:21] <jepler> I am sure I could figure it out -- I assume that a menubar is just a widget or group of widgets
[01:48:41] <jmkasunich> yeah, I could read my GTK book and/or online docs
[01:48:56] <jmkasunich> just wondering if you had done something similar already in GTK
[01:49:07] <jepler> I don't think I've ever coded a gtk menubar in C, so I don't have any specific knowledge
[01:49:13] <jmkasunich> dewey's halscope patch lets you say "load this scope setup" on the cmd line, which is nice
[01:49:29] <jmkasunich> File->Load Config and File->Save Config would be even nicer
[01:49:40] <jmkasunich> (I'd still want the cmd line option)
[01:50:06] <jepler> and File > Print for a nice postscript or pdf rendition of what's onscreen
[01:50:10] <jmkasunich> maybe today I'll be happy with adding his patches (tweaked as needed)
[01:50:13] <jepler> and Edit > Copy so you can paste into excel or gimp
[01:50:21] <jmkasunich> yeah, and File->Save Data
[01:50:55] <jepler> I think my life is calling me again
[01:51:03] <jmkasunich> File -> Load/Save Config are trivial except for adding the menu
[01:51:06] <jmkasunich> the others are hard
[01:51:11] <jepler> yeah I know
[01:51:13] <jmkasunich> have fun
[01:51:15] <jepler> see you
[02:12:06] <CIA-32> EMC: 03jmkasunich 07TRUNK * 10emc2/docs/man/man1/hal_joystick.1: make hal_joystick play nice with 'loadusr -W' - based on a patch submitted by Dewey Garrett
[02:12:16] <CIA-32> EMC: 03jmkasunich 07TRUNK * 10emc2/src/hal/user_comps/devices/hal_joystick.c: make hal_joystick play nice with 'loadusr -W' - based on a patch submitted by Dewey Garrett
[02:55:34] <jmkasunich> odd - halcmd_main.c invokes getopt(), but I can't find where getopt.h is included
[02:57:59] <cradek> unistd.h
[02:58:04] <jmkasunich> oh, it is in unistd.h
[02:58:22] <jmkasunich> dewey used getopt in his halscope patch, and he included getopt.h
[02:58:38] <jmkasunich> I wanted to be sure I wasn't adding a dependency, so I looked for other usages
[02:59:01] <jmkasunich> I guess I should include unistd.h, not getopt.h?
[03:00:09] <cradek> yes I think so
[03:00:22] <cradek> I think getopt.h has the gnu extentions
[03:11:52] <jmkasunich> hmm, halscope doesn't have a manpage
[03:12:35] <jmkasunich> bah - something for another day, its 11pm
[03:12:50] <cradek> neither does hal_parport, even though I look for it all the time
[03:13:30] <cradek> now that halscope has a commandline, it's more likely to need a manpage
[03:13:31] <CIA-32> EMC: 03jmkasunich 07TRUNK * 10emc2/src/hal/utils/scope.c: allow halscope to read and save configs to files other than the default .scope.cfg - patch by Dewey Garrett
[03:13:37] <cradek> otherwise, nah, not so much
[03:13:52] <jmkasunich> yeah, I was thinking "I should update the manpage with the new options"
[03:14:03] <jmkasunich> but I'm not gonna write on from scratch tonight
[03:14:18] <cradek> has anyone already said it would be nice if it had file/open, file/save, etc?
[03:14:36] <jmkasunich> read back about 2 hours
[03:14:45] <cradek> but, it's not clear whether that would be data or scope config
[03:14:55] <jmkasunich> File->Save Config
[03:15:03] <cradek> no I doubt you need more people telling you what you already know
[03:15:28] <jmkasunich> I was actually asking Jepler if he had ever done menubar stuff on a GTK program
[03:15:45] <jmkasunich> making the menus is the hard part of the config file task
[03:16:01] <jmkasunich> well, that and invoking file open and file save dialogs - I hate that gui stuff
[03:16:12] <cradek> yeah I bet it's tedious
[03:16:46] <jmkasunich> jeff pointed out that some other commands would be nice, like File->Print
[03:16:51] <jmkasunich> and Edit->Copy
[03:17:17] <jmkasunich> copy could capture data so you could drop it into a spreadsheet, for example
[03:17:20] <cradek> ooh print
[03:17:22] <SWPadnos> I was recently lamenting the lack of more complex triggering
[03:17:31] <cradek> feature creep!
[03:17:33] <SWPadnos> though that can be done externally
[03:17:36] <SWPadnos> (in some cases)
[03:18:00] <cradek> I'd like a couple stages of ddt built in...
[03:18:19] <jmkasunich> so you could get velocity or accel on any analog signal?
[03:18:24] <cradek> yes
[03:18:38] <SWPadnos> I was thinking more logic, or "rising edge on channel 1 while channel 2 is high"
[03:18:45] <cradek> such a waste of signals to get pos/vel/accel for a bunch of axes otherwise
[03:18:46] <jmkasunich> I used a Tek DSA-602 some years ago
[03:19:03] <jmkasunich> you could define expressions to be displayed
[03:19:05] <cradek> these are all easy to program but a gui nightmare
[03:19:21] <SWPadnos> yes, it's the GUI that usually limits this kind of thing
[03:19:30] <jmkasunich> trace 1 = chanA * integ(chanB)
[03:19:53] <jmkasunich> I used to do trace 5 = integ(chanA * chanB)
[03:20:19] <jmkasunich> where A was current thru an IGBT, and B was voltage across it - the integral over a switching event was the switching loss (energy per event)
[03:21:37] <SWPadnos> patches gratefully accepted :)
[03:21:49] <jmkasunich> it will take a better man than me
[03:22:03] <SWPadnos> I have an infix parser around here somewhere
[03:22:13] <jmkasunich> I'll be thrilled if I can figure out how to add a menu bar and File->Save Config + File->Load Config
[03:22:30] <jmkasunich> oh, and Help->About ;-)
[03:22:34] <SWPadnos> heh
[03:22:46] <jmkasunich> I guess that would be the first one to implement
[03:22:51] <SWPadnos> help->about that doesn't printf to the terminal :)
[03:23:20] <jmkasunich> that would be the second
[03:25:42] <cradek> goodnight folks
[03:26:15] <jmkasunich> night
[03:26:30] <SWPadnos> see you
[03:29:06] <jmkasunich> time for me to walk the dog and get some sleep
[03:32:57] <SWPadnos> night
[03:33:09] <SWPadnos> maybe an early(ish) bedtime is good all around :)
[12:43:29] <jepler> jmkasunich: main problem with doing math in halscope is that you can't do it in the base thread ..
[12:43:35] <jepler> unless you fancy writing a whole fp library to do it
[12:44:08] <jepler> (though if you trusted halscope to find whether fp is enabled in the thread and set a flag for scope_rt...)
[12:44:39] <jepler> nah, no good -- you might want to trigger on accel but capture step pulses
[12:51:50] <skunkworks_> morning jepler
[12:51:57] <skunkworks_> logger_dev: bookmark
[12:51:58] <skunkworks_> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-05-21.txt
[13:03:22] <SWPadnos> jepler, when you and Ingrid went to Europe last year, did you just use the trains, did you rent bikes, cars ... ?
[13:03:35] <jepler> SWPadnos: we rely on trains
[13:03:36] <SWPadnos> (it is Ingrid, right?_
[13:03:38] <SWPadnos> ok
[13:03:38] <jepler> yes
[13:03:45] <SWPadnos> wow - I remembered a name
[13:03:50] <jepler> we talked about renting a car but didn't.
[13:04:03] <SWPadnos> yeah, that gets dicey when you're illiterate (like me)
[13:04:03] <jepler> and I'm not big on cycling
[13:04:06] <SWPadnos> heh
[13:04:43] <SWPadnos> we're heading to Germany in July, and will be training around. we'd like to get bikes, but I'm not remembering much space to carry them on the trains (especially the ICE :) )
[13:05:09] <jepler> good question
[13:05:13] <jepler> I don't know the answer
[13:05:38] <SWPadnos> I'm kind of bummed that even the mega rail pass doesn't include anything east of Germany - so no trips to Prague, Krakow, Budapest ...
[13:05:46] <SWPadnos> I'll ask my sister - she may know
[13:06:10] <jepler> they have a good website in english, at least it's good for checking time tables:
http://www.bahn.de/international/view/en/index.shtml
[13:06:59] <SWPadnos> yep - been there many times. thanks :)
[13:07:23] <jepler> but no, I've never tried to take a bike on any train in europe
[13:07:42] <SWPadnos> ew may just walk around a bit in the various cities we visit
[13:07:44] <SWPadnos> we
[13:08:08] <SWPadnos> the rail pass also gives access to all or most of the bus/boat/U-bahn lines
[13:09:57] <jepler> I've never been east of germany either .. ingrid has once or twice
[13:10:19] <SWPadnos> I went to Poland a couple of years ago, and it was very nice
[13:10:54] <SWPadnos> we were looking at a bike trip from Prague to Vienna, which was what got us on the bike thing
[13:11:10] <jepler> if that's your thing..
[13:11:13] <SWPadnos> heh
[13:11:21] <SWPadnos> well, it's her thing, and I can survive :)
[13:11:55] <jepler> how many riding days is that?
[13:12:23] <SWPadnos> it's 5 or 6 days off riding, but there's a van to take you through the mountains
[13:12:29] <jepler> hm, 250 miles .. that'd be about 50 days for me
[13:12:30] <SWPadnos> it's only 15-30 miles a day
[13:12:34] <SWPadnos> heh
[13:12:42] <SWPadnos> you could walk it in that time ;)
[13:15:45] <SWPadnos> hmmm - lathe threading question on the CAD-CAM list
[13:16:10] <SWPadnos> I think the guy has a single index pulse and a 48-slot wheel, probably not a quadrature encoder
[13:16:37] <SWPadnos> does the counter module support that?
[13:16:43] <SWPadnos> (like clock/direction counting)
[13:17:00] <cradek> encoder module does support it
[13:17:06] <jepler> you can do unidirectional that way
[13:17:08] <SWPadnos> ok
[13:17:11] <cradek> you'd have to fake up an index pulse somehow
[13:17:19] <SWPadnos> right - threading only cares about unidirectional anyway
[13:17:26] <skunkworks_> I thought that is what hydra is using.
[13:17:26] <SWPadnos> he has a separate index, I think
[13:17:32] <jepler> dunno if 96 per revolution is enough
[13:17:36] <cradek> yes I think he does
[13:17:41] <SWPadnos> he says "1PPR and 48 slots"
[13:18:07] <jepler> but yes, at least at one point I had nist lathe threading on A+Z (though it has A+B+Z)
[13:19:38] <skunkworks_> Additionally, after some time, I connected the pre-existing "encoder" (a 100-hole disc) attached to the spindle to EMC, which gave me threading support with the new HAL counter module, which works very well.
[13:19:48] <SWPadnos> ah, so setp blahblah.counter-mode 1
[13:20:02] <skunkworks_> http://www.lerneaenhydra.net/index.php?option=com_content&task=view&id=15&Itemid=28
[13:23:07] <SWPadnos> if only he had posted his ini file :)
[13:23:10] <SWPadnos> and hal files
[13:25:42] <skunkworks_> he is such a loser.. :)
[13:28:24] <skunkworks_> SWPadnos:
http://www.lerneaenhydra.net/index.php?option=com_joomlaboard&Itemid=34&func=view&id=25&catid=3
[13:29:04] <skunkworks_> well crap. can you get at them? they may be broken links
[13:29:09] <SWPadnos> it doesn't appear to count on both edges
[13:29:20] <SWPadnos> X4 is true
[13:29:57] <SWPadnos> skunkworks_, nope, can't get the files
[13:30:50] <skunkworks_> darn.
[13:31:26] <SWPadnos> no biggie - I just tested it out in sim :)
[13:37:27] <SWPadnos> is "counter" meant to be replaced by the encoder counter-mode?
[13:49:00] <SWPadnos> does this look right?
http://pastebin.ca/1024824
[13:59:23] <cradek> at a glance, yes
[13:59:34] <cradek> and yes 'counter' should be defunct
[13:59:50] <SWPadnos> ok
[14:00:06] <SWPadnos> there are a couple of typos/thinkos (there/s no '.0' in the two functs)
[14:00:18] <SWPadnos> do you need to use a sacle block to get RPM vs RPS?
[14:00:25] <SWPadnos> I see that in sim_lathe
[14:05:21] <cradek> I think that's for display on the vcp
[14:06:05] <SWPadnos> ok - right. motion gets spindle-pos anyway
[14:06:25] <jepler> yes. if you don't want a RPM display you don't need that scale block. feed per revolution mode takes feedback in rps, if you are using it.
[14:06:26] <cradek> yes threading uses position
[14:06:42] <cradek> css/fpr uses velocity
[14:07:01] <cradek> I think encoder has a nice velocity output
[14:07:16] <SWPadnos> yep - I'll add that
[14:09:35] <SWPadnos> I wonder how far off the velocity would be just using encoder with a single pulse
[14:09:45] <SWPadnos> it would suck the first time for sure
[14:14:16] <jepler> that's the main reason for deprecating counter and moving the functionality into encoder -- to get the better velocity estimate
[14:14:27] <SWPadnos> yep
[14:41:08] <cradek> "G17, G18 or G19 must not be designated in the mode of coordinate system rotation."
[14:41:21] <cradek> does this mean you can't switch to another plane when rotated?
[14:41:54] <SWPadnos> or that G17/18/19 ignore rotation, or that the designations are in un-rotated coordinates?
[14:41:58] <jepler> sounds like
[14:42:19] <SWPadnos> oh - must not = don't do that, so maybe they are disallowed
[14:42:31] <SWPadnos> does that mean arcs don't work?
[14:42:54] <cradek> yes I think it would mean that arcs in the other planes are not possible
[14:43:09] <SWPadnos> or in any plane?
[14:43:25] <cradek> why do you think that?
[14:43:43] <SWPadnos> unless the rotation is limited to the C axis (XY only), you have the arbitrary plane problem
[14:44:01] <cradek> I still don't follow
[14:44:09] <jepler> I think that in G17, the rotation is in XY and an arc must be in XY
[14:44:15] <jepler> so it remains a planar arc no matter the rotation
[14:44:16] <cradek> yes
[14:44:24] <SWPadnos> if rotation allows you to effectively tilt the table, then even a G17 arc is in an arbitrary plane
[14:44:54] <cradek> I think you cannot rotate except in one plane
[14:45:21] <SWPadnos> ok, and that would be the same plane as the arc plane, most likely (as jepler said)
[14:45:34] <cradek> yes it's definitely the same plane
[14:45:41] <skunkworks_> I suppose.. most post proccessors don't output g2/3 code anymore anyways.. but still - if you're going do rotation - why not make it transparent to the gcode.
[14:46:41] <jepler> I don't understand why they don't; you can approximate a curved surface much better with arcs than with lines, and they have other advantages for motion planning (they can be tangential at endpoints, unlike lines)
[14:48:01] <cradek> aha they forbid changing coordinate systems when rotation is in effect
[14:48:54] <SWPadnos> geez - that's too easy
[14:49:23] <cradek> I have to think for a while about whether that makes g92's operation "obvious"
[14:50:09] <SWPadnos> I wouldn't think so
[14:50:26] <SWPadnos> but then again, I haven't looked up what G92 does recently ;)
[14:50:53] <cradek> it's an offset that applies to all fixture coordinate systems
[14:53:01] <cradek> I can't follow their example Fig 14.10(c)
[14:53:43] <cradek> (but they do have a G92 in it)
[14:58:00] <BigJohnT> http://www.cnczone.com/forums/showthread.php?p=453984#post453984
[14:58:21] <BigJohnT> Happy Hardy User
[22:16:54] <SWPadnos> jepler: it looks like there's a bug in stepconf regarding spindle scaling
[22:17:19] <SWPadnos> I think it's inverting the number entered, but it shouldn't do that
[22:18:16] <SWPadnos> also, using counter mode there doesn't seem to be "x2" counting - ie, it's only counting rising edges, not both rising and falling, so the cycle count entered should be used directly, not multiplied by 2
[22:31:55] <CIA-32> EMC: 03swpadnos 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: Fix incorrect scaling for counter-mode spindle feedback
[23:29:23] <jepler> SWPadnos: beats me. you think I even tested that part once?
[23:34:46] <SWPadnos> nope, but I found and fixed the problem, so no worries :)