Back
[06:00:26] <freeform> hello
[06:01:01] <freeform> can anyone help me with JA4 gentrivkins&
[06:02:51] <freeform> i have build a medium size gantry machine with servo on all axes, XYYZ config
[06:03:53] <freeform> trying to launch it with gentrivkins, but have no success
[06:05:42] <freeform> having errors : HAL: ERROR: pin_new(halui.jog.selected.increment) called with already-initialized memory
[06:05:43] <freeform> HAL: ERROR: pin_new(halui.jog.selected.increment-plus) called with already-initialized memory
[06:05:43] <freeform> HAL: ERROR: pin_new(halui.jog.selected.increment-minus) called with already-initialized memory
[06:06:38] <freeform> and in dmesg: [ 3668.469702] halui[17915]: segfault at 0 ip 0804d440 sp bfaa9770 error 6 in halui[8048000+e000]
[06:07:44] <norbert> 2.6 or 2.5 or ???
[06:08:04] <freeform> 2.6 JointAxes4
[06:08:41] <norbert> have you done . ./scrips/rip-environment
[06:08:56] <freeform> yes
[06:09:07] <norbert> and make clean befor compiling
[06:09:23] <freeform> no
[06:09:48] <norbert> Please do that, sometimes there are thinks laying around giving problems
[06:10:18] <freeform> ok, try another time
[06:11:22] <freeform> what is correct sequence of commands?
[06:11:44] <norbert> cd linuxcnc-dev
[06:11:47] <norbert> cd src
[06:11:50] <norbert> make clean
[06:11:56] <norbert> ./autogen.sh
[06:12:03] <norbert> ./configure
[06:12:05] <norbert> make
[06:12:17] <norbert> sudo make setuid
[06:12:20] <norbert> cd ..
[06:12:36] <norbert> . ./scripts/rip-environment
[06:12:39] <norbert> linuxcnc
[06:12:47] <freeform> ok, i check
[06:22:31] <freeform> done
[06:22:38] <freeform> same errors
[06:23:19] <norbert> uncomment all hal files in your INI and try again
[06:23:45] <norbert> sorry not uncomment commend them out
[06:26:30] <freeform> no changes, but not starting at all
[06:26:45] <freeform> HAL: ERROR: pin_new(halui.jog.selected.increment) called with already-initialized memory
[06:27:13] <freeform> halui[3288]: segfault at 0 ip 0804d440 sp bfd20890 error 6 in halui[8048000+e000]
[06:27:53] <freeform> i`m trying to load sim gantry config
[06:28:52] <norbert> do you have in your INI file mentioned an NML_FILE ? If so please commend that one out
[06:30:01] <freeform> no
[06:30:41] <freeform> sorry for my english, it`s not my native
[06:32:58] <norbert> hjere sim /axis /gantry is starting fine
[06:33:53] <freeform> if i using gantrykins, it works fine
[06:34:10] <freeform> but i want gentrivkins
[06:35:02] <norbert> Sory, but I can not help in this
[06:35:08] <skunkworks> I see a few references to that error on ja3/4
[06:35:13] <freeform> with gatrykins it works well both with sim and real hardware configs
[06:36:29] <skunkworks> you might want to post on the mailing list..
[06:36:47] <skunkworks> sounds similar to
http://comments.gmane.org/gmane.linux.distributions.emc.devel/5597
[06:36:55] <skunkworks> I don't see a solution though
[06:38:53] <freeform> yes, i have read tyat
[06:38:57] <freeform> that
[07:39:07] <jepler> retval = hal_pin_float_newf(HAL_IN, &(halui_data->jog_increment[num_axes]), comp_id, "halui.jog.selected.increment");
[07:39:42] <jepler> this probably needs to be num_joints, because above the array was used from 0 up to num_joints-1 in the loop
[07:39:45] <jepler> retval = hal_pin_float_newf(HAL_IN, &(halui_data->jog_increment[joint]), comp_id, "halui.jog.%d.increment", joint);
[07:40:03] <jepler> this problem would only show up on systems where num_joints > num_axes, i.e., a gantry
[07:48:53] <skunkworks> Nice find!
[07:49:17] <freeform> ok, i try
[07:50:04] <freeform> [joint] or [num_joints] ?
[07:50:45] <freeform> ok
[07:54:09] <jepler> on my system I do see the warning but not the crash
[07:57:06] <jepler> Here's the patch I just wrote, which makes the warnings go away:
http://emergent.unpythonic.net/files/sandbox/0001-Fix-pin_new-already-initialized-errors.patch
[07:57:21] <freeform> recompiled, errors cleared
[07:57:23] <jepler> if this helps you as well, then someone with push access can arrange to incorporate it.
[07:57:32] <jepler> bbl
[07:57:46] <freeform> but it does not work properly
[07:58:13] <freeform> looks like it can not enter teleop mode
[07:58:49] <freeform> when i trying to jog, jogging works wrong
[08:00:14] <freeform> X axis ok, but when i trying to jog Y, AXIS show me speed, but Y position stay at 0
[08:01:02] <freeform> and when i jog Z, Y position is changing, not the Z
[08:02:38] <freeform> this behavior was before halui errors, and it stay after clearin them
[08:21:52] <jepler> the halui jogging seems to be in joints now. I can't tell if it supports jogging in joints.
[08:22:10] <jepler> micges might know more about the current status if he were here
[08:22:21] <jepler> but it looks like he's not
[12:10:46] <dgarr> a suggested change to axis to address request for adding set_mdi_mode axisui pin:
[12:10:50] <dgarr> http://www.panix.com/~dgarrett/stuff/axisupdate.mbox
[12:14:50] <cradek> ooh I like the idea of that
[12:15:36] <cradek> that's big-picture thinking that I was not quite getting to
[12:17:05] <cradek> does that eliminate the last of the weirdness that we got from having the actual mode and the showing-tab be separate?
[12:18:49] <dgarr> i don't understand enough to answer that
[12:19:50] <cradek> the other problem getting mixed in with this is halui.cc:2000 (which might have been a bad idea?) not handling teleop
[12:20:59] <cradek> the idea was you could use halui-mdi without doing the mode switching manually -- it would switch to mdi, send the command, wait for it to complete, and then put the mode back (so you could jog again or whatever)
[12:21:14] <cradek> but as-is, it dumps you out of teleop
[12:21:53] <cradek> (I'm not sure at a glance how you get back into, or stay in, teleop)
[12:22:29] <cradek> I wonder if russell would be interested in trying your patch, and then using ONLY halui mode-get/set to manipulate the modes
[12:26:10] <dgarr> i will post the patch on the list
[12:26:55] <cradek> thanks, I think you've got the winning strategy
[12:27:31] <cradek> there may also be little halui bugs to fix, and I can help with that (or russell will) - he said something about all the -is-manual, -is-mdi, etc pins starting at false
[12:34:17] <cradek> norbert: are you here? I got your mail about your key not working, and answered you
[12:34:31] <seb_kuzminsky> i agree, dgarr's change makes a good kind of sense
[12:34:51] <seb_kuzminsky> make axis show what linuxcnc's mode is, and use halui to change linuxcnc's mode as desired
[12:35:10] <cradek> yes -- the only glitch is that there are three modes but only two tabs
[12:35:43] <cradek> the auto mode is shown by disabling everything (I think)
[12:36:02] <cradek> but I don't think it's auto mode that's biting russell
[12:43:39] <seb_kuzminsky> agreed, it's the mdi/manual split that's messing him up
[12:43:49] <seb_kuzminsky> the exact same thing messes me up too
[12:44:07] <cradek> yay two testers
[12:44:18] <seb_kuzminsky> i've got a control panel (instead of a pendant) on my mill, and some of the buttons want to jog and some of them want to run mdi (both via halui
[12:44:23] <seb_kuzminsky> and i even use axis :-)
[12:45:25] <cradek> I suppose I became immune to all this when I started using touchy
[12:46:00] <cradek> I wonder what's involved in making halui teleop-aware (and if it's different on ja4)
[12:46:49] <cradek> I think halui never had kins machines in mind
[12:47:28] <seb_kuzminsky> when you poke halui's mdi-cmd-* input pins, halui first switches to mdi mode, then sends the requested mdi command
[12:47:37] <cradek> yes
[12:47:57] <seb_kuzminsky> i wonder if it should similarly switch to manual mode when you poke its jog pins (if it's not running a program)
[12:48:16] <cradek> then waits for it to finish, and switches back (unless it was teleop, in which case it does a wrong thing)
[12:48:57] <seb_kuzminsky> err, i wasnt imagining that halui should automatically switch back to its previous mode
[12:49:23] <cradek> I understand, but that's what it currently does
[12:49:26] <seb_kuzminsky> just that it should switch to the mode that the user just tried to use, without the user having to explicitly request it
[12:49:31] <seb_kuzminsky> oh i see
[12:49:52] <seb_kuzminsky> does it? i think when you run an mdi command halui leaves the controller in mdi mode
[12:50:09] <cradek> you're talking about "hiding" the modes (just-in-time switching), which is how AXIS used to work
[12:50:28] <seb_kuzminsky> oh, no, i see you're right
[12:50:40] <cradek> ... but that has come to look like less and less of a good idea over time
[12:50:48] <seb_kuzminsky> right, hiding is what i meant
[12:50:59] <seb_kuzminsky> what are the drawbacks? i dont remember, dont know if i ever knew
[12:51:00] <cradek> that's pretty much gone from AXIS now
[12:51:05] <cradek> especially with dewey's change
[12:51:27] <cradek> people expecting explicit mode switches when (in AXIS's case) switching the tabs
[12:51:40] <seb_kuzminsky> i remember being surprised, a long time ago, that the arrow keys jogged while in the mdi tab in axis
[12:51:40] <cradek> because of interaction with other UIs that don't have the modes hidden
[12:51:51] <cradek> yes that sounds surprising
[12:52:54] <cradek> if all UIs hide modes, or if all UIs have explicit mode switches, it would be OK
[12:52:59] <cradek> a mix makes for surprises
[12:53:16] <cradek> if ALL hide the modes, then the modes are stupid and they should just be removed from task
[12:54:48] <skunkworks> I think that is mhablers thoughts..
[12:56:59] <seb_kuzminsky> i think i dont care about mode hiding, but i think i want just-in-time mode switching
[12:57:13] <cradek> in halui you mean?
[12:57:29] <seb_kuzminsky> we have 4 modes, right? free, teleop, mdi, and auto?
[12:57:45] <seb_kuzminsky> in halui yes, but also in axis
[12:57:59] <cradek> it's not quite that simple
[12:58:00] <cradek> looking
[12:58:36] <seb_kuzminsky> oh wait, free and teleop are not the same *kind* of mode
[12:58:38] <cradek> task has three modes [manual auto mdi]. motion has 3 modes [free coord teleop]
[12:58:44] <seb_kuzminsky> they're variations on manual
[12:58:47] <seb_kuzminsky> ick
[12:58:52] <cradek> yeah and how exactly they interact is mysterious to me
[12:58:57] <seb_kuzminsky> heh
[12:59:01] <cradek> that's why fixing halui to be teleop-aware isn't so trivial
[12:59:41] <cradek> maybe after you switch to manual you also send the teleop message again?
[13:00:09] <seb_kuzminsky> not all combinations of task-modes and motion-modes make sense, right?
[13:00:19] <cradek> quite likely that's true
[13:00:24] <seb_kuzminsky> for example, you'd never want task=auto, motion=free
[13:00:31] <cradek> yes
[13:01:00] <seb_kuzminsky> motion=free means "jog each joint individually"
[13:01:20] <seb_kuzminsky> motion=teleop means "use kins & jog in world coordinates"
[13:01:39] <seb_kuzminsky> motion=coord means "run canon commands" (can come from task=auto or task=mdi)
[13:02:07] <cradek> yes with you so far
[13:03:06] <seb_kuzminsky> i'm not sure i'm going anywhere with this, just trying to see if i understand how the controller works
[13:06:07] <seb_kuzminsky> back to the UIs hiding the controller mode from the user... what i think would fix my problem (and maybe russell's) would be if halui did just-in-time switching to task=manual, motion=teleop(?) mode when the user poked its jog pins in hal
[13:06:30] <seb_kuzminsky> just like it currently switches to task=mdi, motion=coord when you poke its mdi pins in hal
[13:06:46] <seb_kuzminsky> i think i dont care if it automatically switches to another mode when it's done
[13:07:16] <seb_kuzminsky> and i think i do want the other UIs to monitor the mode (via the Status structs) and reflect the mode the machine is currently in
[13:07:24] <cradek> yes I think I agree - and dewey's patch is good whether we have halui-jit or halui-explicit with a button (that's russell's expectation right now I think)
[13:07:28] <seb_kuzminsky> am i missing something bad about this behavior?
[13:08:01] <cradek> I don't think so
[13:08:07] <norbert> Hallo Chris, I am back now
[13:08:36] <cradek> teleop (making halui handle it) is a separate issue, although viesturs and I both got distracted by it
[13:08:46] <seb_kuzminsky> dgarr's patch makes axis reflect the controller state, and reverts the commit to axis that adds the explicit mode-change pin, right? that all seems fine
[13:08:55] <cradek> yes
[13:09:20] <seb_kuzminsky> i wonder if there's a risk in having halui switch to manual mode - for example if the user hits a jog button by mistake
[13:09:34] <seb_kuzminsky> i guess using the controller mode as a kind of safety is stupid to start with
[13:10:26] <cradek> I have a hard time predicting what safety-related objections people will or won't have
[13:11:58] <seb_kuzminsky> i'll put dgarr's changes on a branch, add this halui-jit-manual thing we talked about, and ask russell to test it
[13:12:29] <cradek> awesome
[13:14:38] <cradek> norbert: did you find the problem?
[13:15:39] <norbert> cradek: I am just sending you a mail with the results of ssh test, but I did not find a mistake here
[13:16:09] <cradek> ok
[13:16:32] <norbert> cradek: Email has left my server
[13:18:00] <cradek> debug1: Offering public key: /home/emcmesa/.ssh/id_rsa
[13:18:17] <cradek> this one corresponds to the pub you sent me?
[13:18:38] <norbert> yes, shell i send it again?
[13:19:46] <cradek> no, let me make sure I didn't mangle it
[13:21:13] <cradek> sorry, I did make a mistake, please try again
[13:22:15] <norbert> No it runs till the end, let me try make a new clone
[13:23:17] <cradek> yay
[13:23:40] <norbert> He is making now a new git clone ! Yipi!!!
[13:23:53] <cradek> I got it right in only two tries!
[13:24:17] <norbert> That is better than winning the lotterie ;-)
[14:25:21] <KGB-linuxcnc> 03Dewey Garrett 05halui-jit-manual 8db189c 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis: change tab when task_mode changed * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8db189c
[14:25:22] <KGB-linuxcnc> 03Dewey Garrett 05halui-jit-manual 40f0e8e 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis: remove axisui.set-manual-mode pin * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=40f0e8e
[14:25:22] <KGB-linuxcnc> 03Sebastian Kuzminsky 05halui-jit-manual 487fe00 06linuxcnc 10src/emc/usr_intf/halui.cc halui: switch to Manual when the user requests jog * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=487fe00
[14:25:23] <KGB-linuxcnc> 03Sebastian Kuzminsky 05halui-jit-manual c296d0d 06linuxcnc 10src/emc/usr_intf/halui.cc halui: dont bother changing mode if we're already in the target mode * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c296d0d
[14:25:28] <KGB-linuxcnc> 03Sebastian Kuzminsky 05halui-jit-manual 85cc9a0 06linuxcnc 10src/emc/usr_intf/halui.cc halui: don't automatically change mode after mdi * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=85cc9a0
[14:36:55] <seb_kuzminsky> this works but i noticed two problems
[14:37:20] <seb_kuzminsky> 1: it breaks jogwheel jogging somehow (motion no longer reacts to axis.*.jog-counts)
[14:39:13] <seb_kuzminsky> 2: there's a perceptible delay when switching to task=manual for continuous jogs via halui.jog.*.{plus,minus}, which is very jarring
[14:39:55] <seb_kuzminsky> i'm used to my continuous jog buttons either working instantly (when the controller's in the right mode already) or not working at all (when the controller's in the wrong mode), having it wait for a quarter second before starting the jog is slightly terrifying
[14:40:36] <seb_kuzminsky> i guess i'll point russell at this branch anyway, with those warnings
[14:41:11] <seb_kuzminsky> oh, and thanks to dgarr's patches, axis correctly switches tabs to manual and mdi when halui switches the task mode
[14:44:44] <andypugh> How does the code tell you are jogging rather than cursoring round the MDI history?
[14:45:03] <andypugh> Or is this not about keyboard jog?
[14:45:15] <seb_kuzminsky> err well
[14:45:16] <andypugh> Actually, I think I can guess the answer.
[14:45:37] <seb_kuzminsky> i think the axis gui checks which widget hsa focus, and does the appropriate thing
[14:46:43] <andypugh> I have often (dozens of times a day) noticed that you can't keyboard-jog at all if the F5 tab is active.
[14:46:56] <seb_kuzminsky> yes, i often notice that too
[14:47:11] <seb_kuzminsky> and that you can't jog by poking halui's jog pins in hal if axis is showing the mdi tab
[14:47:15] <andypugh> But I can't think of any way to make Axis more Psychic.
[14:47:19] <seb_kuzminsky> the branch i just pushed changes that
[14:47:40] <seb_kuzminsky> hold on, i'm emailing an explanation to that thread
[14:47:43] <andypugh> Poking the jog pis certainly has no right to be disabled, now I think about it.
[14:49:10] <seb_kuzminsky> it's all about the crazy internal state that the controller keeps
[14:53:41] <seb_kuzminsky> andypugh: ok i just posted to emc-developers
[14:53:52] <seb_kuzminsky> should show up in the next dozen hours or so, when sf gets around to it
[14:55:04] <seb_kuzminsky> modulo those two bugs, i like the new behavior better, beats having to go hit f3 all the time
[16:01:11] <KGB-linuxcnc> 03Norbert Schechner 05master 77c8a85 06linuxcnc 10(6 files in 2 dirs) after compiling the first time I got this changes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=77c8a85
[16:01:11] <KGB-linuxcnc> 03Norbert Schechner 05master 1c806fa 06linuxcnc 10(9 files in 7 dirs) gmoccapy_0_9_9_1 - solved a bug when showing DRO in gremlin preview * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1c806fa
[16:03:54] <norbert> This was my first push by my own, and I do beleave I already made a mistake, the first push got 6 files, whitch did apear after an initial checkout and compiling, the second one is the one I wished to push, how can I avoid the first one, after compiling?
[16:10:16] <jepler> everything committed "since" origin/master will be pushed when you push your master branch. The way to not push changes you don't want to push is to not commit the changes, and to always review commits before pushing (e.g., by git push--dry-run, gitk @{u}.., and other git stuff that is available)
[16:12:34] <norbert> I did make git push --dry-run and also the git-test-sequence, but I could never see an error. Do that files destroy the tree?
[16:13:01] <andypugh> I have got into the habit of doing git push --dry-run then copying the sha tags (fdfkdfk::aslkdsld) and using that as the argument to a git log -p. Then I read through that to make sure it looks like what I expect. And now I only mes up 50% of the time.
[16:14:15] <cradek> I don't understand what the 77c8a85d commit is
[16:14:18] <jepler> gitk @{u}.. is magic shorthand for "all my commits since my upstream branch" and generally (I can't think of any plausible exceptions) the same as what you will push
[16:14:33] <norbert> I will write that down and better ask more frequent at the beginning
[16:15:27] <jepler> gremlin_view.py and I assume the rest are files that are copied around within the source tree and not listed as ignored files at the copied-to location. norbert added the copied file.
[16:15:28] <cradek> should we force-push a removal of that, before any more time passes?
[16:16:05] <norbert> cradek: IThe files apears, after I first time compiled the master tree
[16:16:29] <cradek> lib/python/gscreen/preferences.py has my "Touchy" copyright notice
[16:16:34] <cradek> I have no idea why that would be
[16:16:59] <cradek> also python/gscreen/mdi.py
[16:17:11] <jepler> cradek: yes, forcibly revert to before 77c8a85 and then cherry-pick 1c806fa on it
[16:17:50] <norbert> Hope I didn't mess the thinks to much up
[16:18:12] <KGB-linuxcnc> 03Chris Radek 05master 519bb5d 06linuxcnc fast forward * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=519bb5d
[16:18:33] <andypugh> The git log -p helps to see exactly what will be pushed.
[16:18:52] <KGB-linuxcnc> 03Norbert Schechner 05master a6eefbb 06linuxcnc 10(9 files in 7 dirs) gmoccapy_0_9_9_1 - solved a bug when showing DRO in gremlin preview * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a6eefbb
[16:19:07] <norbert> I am just copying the commands to be more sure the next time
[16:19:54] <andypugh> Git still baffles me, and I have been making bad pushes for years.
[16:20:33] <norbert> I am not willing to push bad thinks for yaear, ones is enough ;-)
[16:20:47] <jepler> the real root of the problem is that these files in lib/python/gscreen and lib/python/gremlin* are copied into place
[16:20:56] <jepler> there is no reason for them to be copied in this way
[16:21:03] <jepler> (at first glance)
[16:21:19] <jepler> if there's no reason, then they should just be committed in lib/python, not commited in src/ and copied
[16:21:40] <jepler> if there is a reason, then there need to be .gitignore entries for the files so they don't appear as "new files waiting to be added"
[16:22:39] <jepler> It looks like Pavel S., Dewey G., and Chris M. have all written variants of this and I would like to understand why
[16:23:10] <norbert> Unfortunately this files aren't from me, so I do not know if they must be there, for working with gscreen and gmoccapy they must be in lib dir IMHO
[16:23:15] <cradek> what does norbert need to do, now that I have done that? git fetch; git reset --hard origin/master?
[16:23:58] <norbert> Cradek: I will just delete the dev dir and clone again, that is the most secure I beleave
[16:24:18] <jepler> If deleting the directory is OK, then the sequence that cradek describes is OK too
[16:25:04] <norbert> I haven't made any changes accept the ones I pushed, so I do not loose any work
[16:25:26] <jepler> if it wasn't (because you had additional uncommitted changes, or committed but not pushed changes) then the "git reset --hard origin/master" step would discard some of your work.
[16:28:51] <norbert> OK, now that the worst has been solved, thanks to you, I will go to sleep. good night
[16:30:33] <jepler> and pyngcgui
[16:32:41] <KGB-linuxcnc> 03Jeff Epler 05master 7617a1c 06linuxcnc 10lib/python/.gitignore ignore generated (copied) files * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7617a1c
[16:32:59] <jepler> now after building those files should no longer show as "untracked" files in git status
[16:35:18] <cradek> thanks
[16:36:45] <cradek> fwiw, I tried to run gmoccapy and it went wrong in several ways
[16:37:29] <cradek> 4 errors in dialogs with OK buttons, and lots of ominous things on stderr
[16:49:41] <seb_kuzminsky> i think the jog wheel stuff in motion (axis.*.jog-counts) only works in free mode, and somehow my change maybe messed that up?
[16:50:28] <cradek> what change?
[16:51:16] <seb_kuzminsky> the one i pushed to halui-jit-motion a bit ago
[16:53:09] <cradek> bbbut you didn't touch motion
[16:53:20] <cradek> wheel jogging has nothing to do with halui
[17:17:33] <KGB-linuxcnc> 03Andy Pugh 05master ac5345e 06linuxcnc 10docs/man/man9/hostmot2.9 10src/hal/drivers/mesa-hostmot2/hostmot2.h 10src/hal/drivers/mesa-hostmot2/stepgen.c Add support for the Table-mode to the Hostmot2 stepgens * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ac5345e
[17:18:24] <seb_kuzminsky> cradek: agreed... but wheel jogging only works if motion=free, and dgarr and i did change how mode commanding is done, so maybe?
[17:18:34] <seb_kuzminsky> i should try master
[17:37:39] <cradek> andypugh: yay!
[17:53:12] <andypugh> <Thinks> I really ought to pull that branch onto actual hardware and make sure that it still works with normal stepgens..
[17:53:27] <andypugh> I will do that tomorrow, 'tis too late here now.
[19:28:26] <seb_kuzminsky> hrm, when i tried it on master, the jogwheel didnt work there either
[19:28:43] <seb_kuzminsky> then i tried 2.5 and it worked, and i went back to master and it worked, and i tried halui-jit-manual and it also worked
[19:28:53] <seb_kuzminsky> so maybe something didnt get rebuilt right? or something? i dont know
[19:29:09] <cradek> aww I hate that.
[19:41:34] <skunkworks> I have notice that when the display is showing offsets and such - the velocity disappears...
[19:41:38] <skunkworks> like
http://www.youtube.com/watch?v=PAVuByKH_Fw
[19:42:46] <cradek> yeah that stuff is not quite right in several ways (there's a bug about at least some of it)
[19:43:55] <cradek> http://sourceforge.net/p/emc/bugs/335/
[19:44:04] <cradek> it's afu
[19:48:39] <skunkworks> ah - cool
[19:48:59] <skunkworks> I mean that is a positive bug tracking sort of way...
[19:49:06] <cradek> ha, yep
[19:49:47] <dgarr> jepler: i've tried to fix the makefiles for the problem you mentioned for pyngcgui, gremlin_view. Could you review, please:
[19:49:49] <dgarr> http://www.panix.com/~dgarrett/stuff/0001-pyngcgui-gremlin_view-eliminate-unneeded-copies.patch
[20:57:47] <jepler> +TARGETS += ../bin/pyngcgui
[20:57:48] <jepler> +../bin/pyngcgui: ../lib/python/pyngcgui.py
[20:57:48] <jepler> + cp $< $@
[20:57:48] <jepler> + chmod +x $@
[20:57:50] <jepler> why are these copies?
[20:58:16] <jepler> is pyngcgui.py something that is imported but which also has a 'main' function?
[20:58:52] <jepler> If so, make the script installed as bin/pyngcgui very small and simple: import pyngcgui; pyngcgui.main()
[20:59:13] <jepler> it's unfortunate I set a bad example with axis, but it is not suitable to 'import' so it's less important
[21:01:52] <jepler> i.e. move the stuff under 'if __name__ == '__main__':' into a proper function
[21:27:30] <KGB-linuxcnc> 03Jeff Epler 05joints_axes4 f8c781a 06linuxcnc 10src/emc/usr_intf/halui.cc Fix pin_new already-initialized errors * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f8c781a
[21:31:31] <dgarr> jepler: thanks, a new try:
http://www.panix.com/~dgarrett/stuff/v2-0001-pyngcgui-gremlin_view-eliminate-unneeded-copies.patch
[21:32:07] <dgarr> i had to contradict the * in bin/.gitignore to add bin/pyngcgui, bin/gremlin_view -- is that ok?
[21:43:35] <dgarr> handpiece bearings eventually go, motors need periodic brush replacement (and blow out the carbon)
[21:52:52] <jepler> dgarr: I feel like I'm being such an ass to you today, but for bin/ we *need* copies so that we set the #!-line properly for system Python as in src/emc/usr_intf/axis/Submakefile under emc/usr_intf/axis/scripts/%.py
[21:53:22] <jepler> sigh, just forget it. I'm making you waste your time over a few kB of hard drive space. forget I said anything.