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