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