any interest in a tool table editor? http://filebin.ca/zrfvy/tooledit.txt
isnt there already something like that?
part of mini
i guess not
dgarr: hm, "edit tool table" and "edit part program" don't have separately configurable editors? that should be fixed
jepler: i have no idea what you said
AXIS assumes you want to use the same program to edit the tool table and the gcode
... which is a problem if you want to use a smarter tool table editor
in the patch i tested, i just made a new entry to use tooledit.tcl as a simplified way to edit, you could still open your [DISPLAY]EDITOR for conventional editing
I figure actual users will only want one editor (the graphical one)
so there should be inifile settings for both
(with the default set to your program, if we incorporate it into the main tree)
i don't agree but i see your point. adding ini items for function-specific-editing seems confusing to me
different users will want different programs to edit the tool table
some users will probably want ones that use a tool-length sensor to perform measurements, for example..
EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/ (TODO hostmot2.h stepgen.c): This copies the hm2 stepgen behavior from JMK's software stepgen.
jepler: modified for a separate [DISPLAY]TOOL_EDITOR http://filebin.ca/pdtyq/tooledit.txt
jepler: i changed os.spawnvp() to system() because i don't know how to handle otherwise a program that could be a script or an executable
jepler: you probably know a better way to do that :)
thanks for looking at it
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/images/ (halmeter-1.png halmeter-select.png): add image
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/tutorial.lyx: update first section and halmeter section
Hey BJT. I've decided to become a contributor =)... Making my way through the IntegratorsManual as we speak. I just _have_ to get my laser up'n'running...
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/tutorial.lyx: missed a few, almost done
EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py:
EMC: * fix loading of 2.2 stepconf files
EMC: * fix limit switch bug reported by cmorley (thanks!)
EMC: * remove some debugging prints
so -- beta2 and branch this weekend? branch now and beta2 this weekend?
jepler: any suits me
how about beta2 now, and branch this weekend?
(now as in later today) ?
how sure are you about stepconf?
cradek: I tested it for seconds and seconds
looked like big changes...
it's less than it looked like, actually
some were formatting / python aligning
the "the pin migration routine doesn't work at all" bug was fixed by changing indentation
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/tutorial.lyx: halscope updates, almost done
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/images/ (9 files): halscope updates, almost done
jepler: I'm also starting like a branch is due. We are avoiding working on stuff because we haven't branched.
The only remaining problem I know of that needs examination before 2.3 is the halscope thing
I suspect it will be a small fix in only one or two files once jmkasunich finds/understands it
er, 'starting to feel like'
I keep leaving words out, today
which halscope problem?
s/which/what/ - I'm not implying that there are a lot to choose from
it crashes with an off-by-two error, memcpying into an array or somesuch
I hope the debugging we did is in the irc logs...
we had it narrowed down
heh - yeah, I was just thinking that
I remember the discussion now
this patch has been working for me: http://filebin.ca/ydvs/halscope_06mar.txt
dgarr: good to know - if jmkasunich doesn't have time to figure out whether there is a bigger problem, we know we can just apply that.
also an update for tool editing using a seaparte ini [DISPLAY]TOOL_EDITOR http://filebin.ca/pdtyq/tooledit.txt
> If a mill-tool-line has a pathological _comment_ that begins with 4 or more
> whitespace-separated numbers, it is indistinguisable from a lathe-tool-line.
ha, I never thought about this. ick.
once we have a good editor, we could "easily" change the format of the tool table.
dgarr: it should be left as spawnvp, and if your editor is a script you should make it +x and put the appropriate #!-line.
EMC: 03seb 07TRUNK * 10emc2/docs/man/man9/hostmot2.9: update manpage to reflect new stepgen maxaccel behavior
jepler: done: the problem was that the usual tricky fist two lines for a tcl script don't work with spawnvp() fixed: http://filebin.ca/vardjg/19mar09.txt
also, i modified the script, per a comment by cradek, so that comments are prepended with a leading "# " to stifle creation of pathological files where mill items could be confused with lathe items. did you have any comments on the editor implementation itself?
dgarr: I didn't run it. the screenshot looks fine.
I'm worried about the two writers/two readers situation. I wonder if there's a better way to handle direct tool table editing.
you can't edit the whole tool table through the MDI commands
until that's possible, the best you can do is try to make your write+reload come close together
that is true, but could be fixed (except for comments)
you can edit the whole tool table through nml (I think)
except for perhaps deleting a tool (could be fixed)
I am putting parenthesized statements after everything I say (at the end)
(those are g-code compatible)
it's worse than write+reload, it's write1+read2+modify2+write2+reload (1=emc, 2=tooltable.tcl)
I notice bigjohnt puts g10l1 in his gcode files. if you ever ran one of those programs with tooltable.tcl open, you would be bitten
in fact it would be best if tooltable.tcl would show the updated value right away
monitor the file for changes
like gedit does
there's a library, which I forgot the name of, that can do that
[none of these problems are new and they are not due to any fault in tooltable.tcl]
yes EMC_TOOL_SET_OFFSET can set all things in the tool table
you could write changes with NML and have one writer
you still have two readers/no locking/stale data though
or pyinotify, if you want to use python
I have a nagging feeling about that. that feels like it could work but would be the wrong overall approach.
since tooledit can already parse a tool table, and with inotify it should be able to see if the open file changes, it should be possible to hilight or warn about changes to individual tools
it may be the wrong approach
but it could work ;)
yes I agree with both statements :-)
I wonder what might be right though, if an external, modification-aware editor is wrong
I guess the editor would need to speak NML
except for the comment problem
doing it all over nml, which is our existing solution to multi-ui
well the nml message could take a comment/description string I suppose
if we really need it
so per-tool comments and overall file comments are the stumbling block
the comments are not in stat, currently
overall file comments are silly
I was thinking about that, but doesn't the interp throw away comments relatively early on
not if you have several tool palettes
# THIS IS THE TOOL TABLE YOU PUT THE TOOL TABLE THINGS HERE
what does the interp have to do with it?
oh - just thinking about access to comments from all sides
if I G10L1..., does that eliminate an existing comment?
no, amazingly enough
I painstakingly keep them
should ...? dunno
pick your poison
I think they shuold be left alone
even though you might change some numbers that make the comment wrong :)
I guess that's my feeling too
is there an NML message to load a different tool table?
emc only has one tool table with a fixed name
ok, and you have to copy other information into it if you have a tool palette system
I am wrong
char file[LINELEN]; // name of tool table, empty means default
uh-oh, can of worms
time to go fishing
time to have lunch
dgarr: when I run tooledit, I only get a small empty window with title "tooledit"
oh -- I can't call it tooledit without changing the file
as written, it has to be named tooledit.tcl -- this supports using it standalone or sourced in a large context. this could be changed of course
hm, when I click the X, it dismisses but doesn't exit
no, it ends up zombied
tooledit.tcl duh.tbl & works for me from a shell
yes but click the window manager X to exit it
the window disappears, but it does not actually exit
works for me, does Dismiss zombie?
Dismiss works to exit the program
i dont know then, i can't seem to reproduce that problem. what window manager (i'm using gdm)
cradek, are you running it from a terminal or from AXIS?
steps to reproduce:
at prompt, run tooledit sim.tbl
click X in upper right corner of tooledit
notice no prompt comes back
in other terminal, run ps x, notice still-running tooledit
what does Check Entries do? If I put something bogus in, it turns red without me clicking Check
should the table headers be flat? Currently they look like entries that are disabled, which makes me feel there's something I can do to cause them to enable so I can change them
in AXIS, the status line is left-justified, which I think is fairly standard - maybe this should match
maybe this will fix it: http://filebin.ca/majpxp/tooledit.tcl
Check Entries currently makes another check for duplicate pocket numbers
that did not fix the exiting problem
I think the buttons should have keyboard shortcuts (one letter underlined)
also, it would be more keyboardable if up/down arrows would move up/down in the table
the dismiss button works correctly, but the window X button doesn't (for me)
can't really do right/left though, since those are needed for editing - tab is good enough for that
dgarr: (I hope this is the kind of feedback you wanted...)
I'm just exploring it as a new user and saying the things that surprise me a bit - not trying to be critical.
if you destroy tooledit, how does the variable::tooledit::finis ever change (such that the tkwait will "wake up")?
in tk you would define a "wm protocol . WM_DELETE_WINDOW" that just does the same thing the dismiss button would do
I tried that, but it didn't work
which led me to think that the tkwait could be a problem
Download Server 1 - North America. Download Server 2 - Europe. If you are unsure as to which server is closest to you please select Server 1.
it does seem like it should be difficult to not know which one is closer
but I guess if you're in India somewhere it might not be obvious
true, I guess
or the ISS
but that may change too quickly
I saw it go by Tuesday night
i fixed a few things, maybe the X-close: http://filebin.ca/bthaky/tooledit.tcl
i think shortcuts for buttons requires key-bindings and is different from
menus. In a menu, the focus is clear to direct the key but a user viewing the
buttons may have focus in an entry window and unexpected things could happen
with shortcut keys. i'd have to work on arrow keys if that's a showstopper.
aha, exit works now
not sure how much validation you want to do, but it accepted a tool orientation (lathe) of 666 which is invalid. 0..9 inclusive are valid
cradek: I guess they were thinking about iceland & Dallur when they wrote the server stuff
i added a wm protocol as jepler suggested but don't know why i couldn't reproduce it
yeah I don't understand that either - but it works now
dgarr, what version of tcl do you have?
I've got 8.4 here, on Hardy
mine is dapper
set tcl_patchLevel 8.4.16
SWPadnos: hard to believe he has a different version
emc2 has 8.4 as a install dep
well, just throwing it out there :)
so unless he compiled emc2 from source, he has to have 8.4
you can still install 8.5 though, can't you?
(even build-deps has 8.4)
yeah, but you need to go through hoops to get there
not that it matters, since that's not the problem :)
it doesn't .. but it fits our digression pattern
i can put in more validations, accepted orientations are 0 thru 9?
i'll wait a few hours for other suggestions or validations and post another version
i'm only doing this because my machine is down for a few days
so if we sabotage it to be down longer, you'll jump on more enhancements?
not likely:P i took out a servo amp, solderedl near some teeny-tiny resistors and broke it (i thought), jon elson examined found no problem, and after a lengthy search i found a wire connection that had come loose in my dissasembly
jepler: did you decide something regarding beta2?
you can set vec2ngc.py as a filter for DXF
alpha but working
it is stripped from my cam module
micges: cool, thanks
I notice it's GPL
is that v2 ?
I don't see a license info on the files
I'm adding it now
alex_joni: svn co https://vec2ngc.svn.sourceforge.net/svnroot/vec2ngc
(I don't fully understand file release system of SF)
micges: file release is usually for packages
make a tar.gz with the files, and make a new release
then upload the tar.gz, and link it to the new release
but since it's still alpha, I wouldn't make releases yet ;) (but that's your choice)
btw, you forgot conv.py ;)
alex_joni: since I finally got off my ass and did the things that I thought needed to be done before beta2, I was hoping to get on with it
jepler: so I guess there are a couple more things to cross out?
[21:09:10] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Emc2.3Status
out of curiosity, has anyone else tested the halcmd completion changes?
alex_joni: this one is done isn't it? moving sample configuration files from /etc/emc2/sample-configs to /usr/share/doc/emc2/examples/sample-configs
SWPadnos: It's for bash completion of commandlines starting 'halcmd', right?
specifically when RT isn't loaded, but on RT installs
sim magically loads RT for you, so it doesn't exhibit the problem
(or it has other problems)
oh hmm - is the profile.d (or whatever) stuff in the 2.3 package, such that completion will work?
I think there's just the magic in emc-environment
I don't think it applies to run-installed systems
completion for halcmd/halrun/others might be nice
I haven't looked at what other things it does
(emc-environment, that is)
SWPadnos: it completes to only "halcmd -h"
(when realtime's not running)
yep, that sounds about right :)
since everything else needs RT to be useful
except -R, which is "hidden"
at least, that's how it seemed to me - I didn't see anything else, including --help, which could be used without RT
yay I can reproduce dgarr's halscope bug now
did you try his patch?
not quite; I came up with a different formulation
ctrl_shm->pre_trig = (ctrl_shm->rec_len-2) * ctrl_usr->trig.position;
ok. (I never looked at his patch, so it's hard for me to tell what's different :) )
say you have 4000 samples available. setting the trigger at 4000 is plainly nuts (because the samples are numbered 0..3999). Setting it at 3999 turns out to be a problem as well, because at least one sample is always recorded after the trigger (i.e., the cycle when the trigger occurs)
so the range should go 0..rec_len-2
trig.position goes from 0.0 to 1.0
hmmm. that sounds like a buglet in the capture code though
dgarr's patch is this:
+ ctrl_shm->pre_trig = -2 + ctrl_shm->rec_len * ctrl_usr->trig.position;
+ if (ctrl_shm->pre_trig <0) ctrl_shm->pre_trig = 0;
- ctrl_shm->pre_trig = ctrl_shm->rec_len * ctrl_usr->trig.position;
the 0..3999 thing isn't, but capturing another sample after the trigger is (a bug)
that's how the state machine works
PRE_TRIG -> TRIG_WAIT -> POST_TRIG and each state captures one sample
yep. there should probably be a special case for trig_len == buf_len, but it's not critical to fix it in that way
jmkasunich: sorry if I'm stepping on your toes, but I went ahead and checked a fix in
I'm sure he'll be thrilled ;)
even if his toes are sore
dgarr gets the real reward
.. a working halscope :)
(but he'd fixed it himself 3 weeks ago or something anyway)
jepler: did you fix "reportedly, stepconf can generate configurations which encounter following errors" ?
alex_joni: did I cross it out?
I didn't do anything that I think addressed it
I don't think I have a real bug report either
no, that was on the known problems page
in here: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?UpdatingTo2.3
isn't that related to the magic 0.95*max_vel calculation?
"I set it to X, but I get slightly less than X max velocity"
oh hey, I get the "ugly large fonts in pickconfig" problem on my hardy test machine also
gah. got to leave the computer until the sun is below the horizon
it's impossible to block it out sufficiently, and the slivers of eye-numbing brightness are too much to bear :)
you need a danker, darker room
try the basement
ah, argh, it appears the max velocity calculation is wrong in sherline (non-doublestep) mode
EMC: 03jepler 07TRUNK * 10emc2/src/hal/utils/scope.c:
EMC: Fix dgarr's halscope crashing bug.
EMC: Subtract 1 because samples are numbered (e.g.,) 0..3999 when there are 4000 samples.
EMC: Subtract 1 more because a sample is always captured one cycle after the trigger
EMC: (is this a bug in the scope_rt state machine?)
good night all
see you micges
* alex_joni kicks CIA-2
oh alex_joni I forgot to mention that the Goldwing will go from 0 to 140 mph faster than you can write out the check for the ticket :)
so I'll take the 40-45 mpg
heh, in that case ;)
* BigJohnT looks for the "heh" key on this old keyboard
if anyone gets a chance take a look at the hal tutorial... I get to the "more channels" section but can not see the step pulse so I must have something wrong...
EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: fix following error in generated configs when in sherline mode
BigJohnT: in the HAL User Manual?
does the position on the stepgen change?
I've converted it over to stepgen but I must have made a mistake
with a show pin?
or with halscope
maybe you can pastebin the output of halcmd show
[23:29:54] <BJT-Hardy> http://pastebin.ca/1365697
3 bit IN FALSE stepgen.0.enable
BigJohnT: setp stepgen.0.enable 1
ok so I need a setp for that
BigJohnT: setp stepgen.1.enable 1
1 or TRUE
crumb, I have to start over :/
I hit ctrl v and it knocked it off
or ctrl c I forget which one
you now have the output from halcmd show
you can simply load that
halcmd -kf < file
or something like that
anyway I'm sure that enable is the problem
or was that with halcmd save ?
yea, that is with save
I'll do it again in the morning, thanks for looking at it
gotta shut down for a bit talk to you later
jepler: my toes are quite happy - I've been stuck working on these CIM jigs
I don't consider "capture one sample in each state" a bug - it isn't important that the user be able to set the trigger point _exactly_ at the end of the captured data
in fact, I'm gonna call it a feature that you can always see the triggering event (since you get at least one sample before and after)
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/images/halscope-10.png: add image