Back
[00:18:46] <mozmck> stepconf is looking in /usr/share/doc...etc for emc.nml, but I have emc installed in /usr/local/
[01:14:33] <mozmck> has emc.var been removed from the sample configs?
[01:15:09] <mozmck> I don't see it...
[02:15:19] <jepler> the var file is automatically created if it doesn't exist
[02:15:46] <jepler> the nml thing may be a bug; few people actually install emc to /usr/local. patches are welcome.
[02:16:05] <jepler> (developers mostly --enable-run-in-place, and almost everyone else uses packages)
[02:28:22] <mozmck> I found and fixed the nml thing.
[02:28:49] <mozmck> the reason for the var question is stepconf tries to copy it from the sample configs and it is not there anymore
[02:30:25] <mozmck> so can I remove the code in stepconf that tries to copy emc.var?
[02:35:03] <jepler> yes I think so
[02:35:11] <jepler> and in trunk the nml copy should be unnecessary too
[02:35:29] <mozmck> oh, ok.
[02:35:44] <jepler> (but maybe broken for --prefix=/usr/local systems, I never tested that)
[02:36:10] <mozmck> the problem there was with the 'distdir' variable and I think it is used elsewhere also.
[02:36:42] <mozmck> I'll try and put up a patch shortly. haven't done it with git yet.
[02:36:49] <mozmck> do I need to commit first?
[02:37:52] <mozmck> I'm working with trunk...
[02:40:24] <jepler> yes, commit first, then you can create a patch suitable for e-mailing or putting on pastebin or whatever with git format-patch
[02:42:00] <jepler> if you want to create a patch of just your last commit: git format-patch --stdout HEAD^
[02:42:10] <jepler> 'night
[03:24:52] <cradek> jmk-st: do you have tomorrow off work too?
[03:24:57] <jmk-st> no
[03:25:02] <cradek> darn
[03:25:08] <jmk-st> why?
[03:25:42] <cradek> just wondered - we get a long weekend.
[03:28:25] <jmk-st> they gave us a floating holiday for the 4th
[03:28:48] <cradek> ah, we have a rule where we get the nearest weekday in cases like this
[03:29:26] <cradek> I think it's nicer when the company actually closes for a holiday
[06:30:50] <micges> alex_joni: around?
[08:36:42] <alex_joni> shortly :)
[09:01:34] <micges> My tip is to have M67/m68 to program analog output with/without motion sync
[09:01:58] <micges> m67 En Qnn.n
[09:02:41] <micges> alex_joni: what do you think?
[09:03:00] <alex_joni> sounds ok
[12:37:46] <BigJohnT> in my Git Gui window for 2.3 branch it shows a whole lot of unstaged changes... did I forget to do something?
[12:41:11] <CIA-1> EMC: 03bigjohnt 07v2_3_branch * r8664937ebdd6 10/docs/src/hal/pyvcp.lyx: Add -g option to manual
[12:41:27] <CIA-1> wizards: 03lerman 07master * rd383ae5189d0 10/GWiz/ (buttons/conversational.png gwiz.py makegwiz.sh makewiz.sh): Added conversational mode to GWiz.
[12:41:27] <CIA-1> wizards: 03lerman 07master * rbd3413724780 10/GWiz/ (gwiz.py makegwiz.sh): Fixed a bug in image scaling reported by Frank Tkalcevic.
[12:58:00] <jepler> BigJohnT: I've seen this (untracked files, particularly) when going from 2.3 -> master, but not the other way around..
[13:02:10] <BigJohnT> mostly .o.cmd files and a few others
[13:04:30] <BigJohnT> for the most part the files in /src/ it looks like
[13:05:35] <SWPadnos> you didn't do a "git commit -a" or anything like that, did you?
[13:05:47] <SWPadnos> or git add I mean
[13:07:07] <BigJohnT> no
[13:07:26] <jepler> hmm, probably the gitignores are incomplete in the v2_3_branch then
[13:07:35] <BigJohnT> I'm on my 6.06 computer with just 2.3 branch
[13:07:37] <jepler> .o.cmd is created in the build process
[13:09:23] <jepler> I'll look into it and update the ignores
[13:09:29] <BigJohnT> thanks
[13:10:34] <jepler> I removed all the trailing whitespace from .c, .h, .cc, .hh, .tcl, .py, and .comp files in master. should I push the change? 373 files changed, 5390 insertions(+), 5390 deletions(-)
[13:14:25] <SWPadnos> ouch
[13:14:41] <cradek> does trailing whitespace cause a problem?
[13:14:45] <SWPadnos> you might as well run indent while you're at it :)
[13:15:01] <SWPadnos> cradek, think of the disk space
[13:15:02] <jepler> cradek: it makes git whiny when rebasing
[13:15:16] <cradek> SWPadnos: :-P
[13:15:45] <cradek> jepler: sounds bizarre, I didn't see that in my big rebase
[13:16:32] <jepler> so the consensus is "no"?
[13:16:40] <jepler> fair enough
[13:16:47] <jepler> or was it "no, unless I run indent too?"
[13:16:51] <cradek> ack
[13:17:08] <cradek> if it's solving a problem, maybe -- otherwise, no
[13:17:16] <cradek> I don't understand the answer to that question yet
[13:17:51] <jepler> it's something like this:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514651
[13:18:25] <SWPadnos> if it causes a problem which should be fixed, and there are other formatting-only "problems" with the code, then I would do one "prettifying" change with everything
[13:19:22] <cradek> I was using my dapper git1.6 packages - maybe hardy 1.5 is just wrong
[13:19:47] <cradek> frankly, sounds like a stupid "feature" of git to me
[13:21:18] <cradek> the cost is noisy diffs, the benefit is you eliminate a warning when rebasing due to a setting in a git version many will use
[13:21:52] <cradek> I guess I'm changing my answer to "I don't know"
[13:22:21] <CIA-1> EMC: 03jepler 07master * r8890a5695ab0 10/debian/.gitignore: a new generated directory
[13:22:29] <cradek> but I sure do know you shouldn't run indent :-)
[13:24:20] <CIA-1> EMC: 03jepler 07v2_3_branch * rf7298992acd7 10/configs/.gitignore: ignore var files and their backups
[13:24:20] <CIA-1> EMC: 03jepler 07v2_3_branch * r7aa34a376e05 10/ (35 files in 35 dirs): clean up ignores some more
[13:24:21] <CIA-1> EMC: 03jepler 07v2_3_branch * r36fc5c874f2a 10/debian/.gitignore: a new generated directory
[13:26:06] <cradek> if someone pushes many commits at once, like I did recently, we still get a flood. I could change that (make one that says "jepler branch * 50 commits!") but it would make the cia stats/logs less good. is there a better alternative I don't see?
[13:29:30] <jepler> so far I haven't really minded the occasional spew
[13:29:46] <jepler> it's still much shorter than a bad cvs spew, which could go to hundreds of lines
[13:30:42] <jepler> at the same time, we've got all these other easy ways to look at history, so CIA is mostly useful for just knowing "something happened"
[13:30:52] <jepler> so that short a message is probably fine
[13:31:15] <jepler> BigJohnT: did those commits fix your untracked files in v2_3_branch?
[13:32:51] <CIA-1> EMC: 03jepler 07master * r3b99b93a100a 10/src/emc/usr_intf/stepconf/stepconf.py: stepconf fixes for non-standard directory installs
[13:32:55] <cradek> yeah we've changed from many dirs at once causing a flood to many commits at once (something we didn't do) causing it
[13:33:10] <cradek> I agree it's less bad
[13:33:25] <cradek> I'll do nothing, at least for now
[13:39:16] <BigJohnT> jepler: I pulled then rescaned and it still is the same...
[13:41:37] <BigJohnT> when I do this "git config --global core.excludesfile ~/.gitignore" does it matter what directory I'm in?
[13:43:33] <jepler> BigJohnT: no
[13:43:46] <jepler> pastebin the output of "git status" then
[13:45:09] <BigJohnT> ok
[13:48:01] <BigJohnT> jepler: git status
http://pastebin.ca/1483008
[13:50:24] <jepler> in the top emc2 directory is there NOT a line that reads "*.cmd"?
[13:50:55] <jepler> er, in that .gitignore
[13:50:57] <jepler> emc2-dev/.gitignore
[13:51:45] <BigJohnT> I have a seperate emc2.3-dev
[13:51:59] <jepler> ok, in emc2.3-dev then
[13:52:27] <BigJohnT> no
[13:52:38] <BigJohnT> build-stamp
[13:52:40] <BigJohnT> lib
[13:52:41] <BigJohnT> share
[13:52:54] <jepler> did you pull my changes?
[13:53:00] <BigJohnT> yes
[13:53:27] <jepler> does your git log or gitk show the commit '
[13:53:28] <jepler> clean up ignores some more'
[13:53:45] <BigJohnT> just did a git pull again and got a bunch of stuff
[13:53:49] <jepler> aha
[13:54:15] <BigJohnT> now I'm down to a handful of files
[13:55:40] <BigJohnT> http://pastebin.ca/1483011
[13:56:53] <BigJohnT> ok, I just got rid of the backups
[13:56:56] <jepler> pcncconf, tooledit, schedrmt are stuff in TRUNK that's not in 2.3.
[13:57:07] <jepler> backups should go in your personal ~/.gitignore, I assume that's what you did
[13:57:13] <BigJohnT> yes
[13:57:27] <jepler> same seems to go for feedcomp, joyhandle, thc
[13:57:56] <BigJohnT> ignore the src/1make.txt file that is mine
[13:58:37] <jepler> (and of course when I say 'in TRUNK', I mean 'in master')
[13:58:49] <jepler> so those you should just remove by hand from your emc2.3-dev directory
[13:58:55] <jepler> you must have built master, then made the copy
[13:59:08] <jepler> (you can use 'git clean' to remove the files too if you want)
[13:59:43] <BigJohnT> ok, I'll try that
[14:01:32] <BigJohnT> YEA! thanks jepler
[14:02:06] <jepler> bbl, breakfast
[14:02:12] <BigJohnT> me too
[14:04:19] <CIA-1> wizards: 03lerman 07master * r5c8ad1da8278 10/GWiz/ (gwiz.py makegwiz.sh): Change the code that displays the wizard tree to get rid of an unecessary level.
[16:09:49] <CIA-1> EMC: 03jepler 07master * rc296015c0a59 10/src/emc/usr_intf/stepconf/stepconf.py: . is dash-compatible, source is not
[16:09:50] <CIA-1> EMC: 03jepler 07master * r480301507e4b 10/tcl/bin/pickconfig.tcl: fix systems where the directory name "Desktop" is localized
[16:09:52] <CIA-1> EMC: 03jepler 07v2_3_branch * r477f3f405be1 10/src/emc/usr_intf/stepconf/stepconf.py: . is dash-compatible, source is not
[16:09:53] <CIA-1> EMC: 03jepler 07v2_3_branch * rdf1cd5d2edde 10/ (debian/changelog tcl/bin/pickconfig.tcl): fix systems where the directory name "Desktop" is localized
[16:24:04] <mozmck> jepler: what does ". is dash-compatible, source is not" mean?
[16:39:08] <cradek> dash is a shell used as /bin/sh instead of bash now on some installs
[16:39:24] <cradek> . and source are both shell commands that read commands from a file
[16:40:05] <cradek> dash and bash are incompatible in various ways and this is one that our configure script tripped on
[16:40:18] <mozmck> oh, I see. I ran into some incompatibility the other day on another project, and finally just told it to use bash.
[16:41:15] <cradek> yes that's a common way to fix it
[16:41:39] <mozmck> why did ubuntu switch to dash I wonder?
[16:42:17] <cradek> I think you are not the first or last to wonder that...
[16:48:57] <jepler> https://wiki.ubuntu.com/DashAsBinSh
[16:49:17] <jepler> > The major reason to switch the default shell was efficiency. bash is an excellent full-featured shell appropriate for interactive use; indeed, it is still the default login shell. However, it is rather large and slow to start up and operate by comparison with dash. A large number of shell instances are started as part of the Ubuntu boot process.
[16:50:15] <cradek> oh, to make it boot faster?
[16:50:21] <jepler> (on my system it's 3ms vs 7ms to run an empty shell script with dash vs bash, not a huge difference..)
[16:50:29] <cradek> they should have made the boot scripts use /bin/dash then
[16:51:07] <jepler> cradek: they discuss and dismiss that very idea on that wiki page
[16:51:20] <jepler> > Rather than change each of them individually to run explicitly under /bin/dash, a change which would require significant ongoing maintenance and which would be liable to regress if not paid close attention, the Ubuntu core development team felt that it was best simply to change the default shell
[16:52:08] <cradek> interesting
[17:10:26] <cradek> why on weekends do I have so many things to do, but as mid-day comes, all I feel like doing is taking a nap?
[17:14:20] <skunkworks> * skunkworks is a sweatball from doing siding.
[17:43:50] <jepler> skunkworks: an image I did not need in my head
[18:02:36] <Lerman_> Why is jog disabled during pause? What must be changed so that I can enable it?
[18:03:29] <Lerman_> (I mean pause as caused by M0)
[18:18:55] <cradek> because if you move the machine, the gcode may not make sense when you resume (for example, imagine the next move is an arc)
[18:19:30] <cradek> (hasn't this subject been beat to death?)
[18:22:58] <cradek> the answer to the second question is not so easy - something like come up with a design (what should happen when you resume after the machine has been moved?) and then implement it (nontrivial)
[18:39:09] <Lerman_> I'd be happy if the machine behaved as if I had done a g0 to the present location. Or if it assumed that it was at the same location as before I jogged.
[18:40:07] <cradek> with both of those behaviors, the arc after your M0 will fail because its geometry is messed up
[18:42:05] <Lerman_> Yes. So, don't jog where it could cause a problem. I suppose we could add another Mword that did a pause and allowed manual motion. It winds up that if I keep the machine in MDI mode I can do what I need. I still have to add some introspection to get the current coordinates, but that shouldn't be too hard.
[18:42:38] <cradek> you can get the current coordinates with probing commands or g28.1/g30.1
[18:43:32] <cradek> 'current coordinates' is hard to define because there are so many of them
[18:44:57] <Lerman_> Ah. g30.1 is what I need. Yes, current coordinates is hard to define. But gcode should be able to convert from what g30.1 gets to the currently selected coordinate system.
[18:45:33] <cradek> yes in a very roundabout way it can do that (but beware units)
[18:45:53] <cradek> if someone is using their g30 position for something, though, you screw them
[18:46:01] <cradek> (I use it for tool change location)
[18:46:15] <cradek> so maybe it's not really what you want
[18:46:26] <Lerman_> I could save them, then do the G30.1, then restore them.
[18:46:31] <cradek> ah! true
[18:47:17] <Lerman_> The G30.1 units are in the native machine units, I assume.
[18:48:50] <cradek> yes
[18:49:16] <cradek> so are the offsets you will have to manipulate
[18:49:34] <cradek> but you don't know the units of your program when you subsequently use them in a G1
[18:51:45] <Lerman_> Well, I could always define the subroutines to use native units. I don't think that's overly restrictive. I just want this as a way for a user to be able to manually set a position that will later be used in a subroutine.
[18:52:13] <cradek> yeah I think that's a neat idea
[18:52:35] <cradek> I'm thinking of facing a block or something - who cares how big it is, you want to do the whole thing
[18:53:29] <cradek> but jogging-while-paused is a can of worms - and I bet you could do it without that.
[18:53:59] <Lerman_> Yup select the upper left corner, select the lower right, set the depth, the step over, and go. Where upper left refer to the projection on the xy coordinate system; not the depth.
[18:55:00] <Lerman_> Yes. Setup MDI. Go to position. Use the set upper left wizard. (That will call a subroutine using MDI).
[18:55:02] <cradek> I can see a lathe equivalent is some kind of roughing a shoulder
[18:55:03] <Lerman_> Repeat for the other corner.
[18:57:11] <Lerman_> Sure. You can use the machine as if it were manual with a DRO to set your positions. The machine does all of the passes, though.
[18:57:28] <cradek> that's exciting
[18:58:43] <Lerman_> Some guy on CNCzone was complaining about how hard it is to use this CNC stuff and saying that he could do the simple stuff in a fraction of the time manually. I think I can prove him wrong using this stuff.
[19:00:04] <cradek> yeah, seems like you should be able to get it down to the same time spent, but less tedious cranking
[19:00:08] <cradek> for common operations anyway
[19:49:07] <SWPadnos> lerman_, in the facing example, you might consider having the top, left, bottom, and right all individually settable
[19:49:47] <SWPadnos> so I could jog somewhere and maybe touch off on an edge, then set "top" at that Y point
[19:50:03] <SWPadnos> move to the right side and touch off just right with X ...
[19:51:33] <Lerman_> I was thinking that when facing a surface, the exact overlap isn't important. So, just get somewhere close and you are in business.
[19:51:51] <SWPadnos> the overlap isn't important, but the overall zie could be
[19:51:57] <SWPadnos> more so for posketing I guess
[19:52:02] <SWPadnos> pocketing
[19:53:12] <Lerman_> Is there a way to display a parameter in pyvcp? How about to cause a command to be issued to axis (execute arbitrary python code would do this)? If so, I could have a widget display the saved points and have buttons to save the points.
[19:54:00] <Lerman_> You can't touch off on a pocket because the edge of the pocket doesn't exist yet. But sure, you could have multiple wizards to do multiple different things.
[19:55:02] <SWPadnos> G-code parameter ot HAL parameter?
[19:55:04] <cradek> no, vcp only shows hal things; it doesn't know interpreter things
[19:55:24] <SWPadnos> G-code can set an "analog output" so it's visible in HAL
[19:55:58] <Lerman_> G-code parameter. OK. How do I associate an analog output with a HAL "pin".
[19:56:12] <SWPadnos> they are pins
[19:56:23] <SWPadnos> (if that feature is implemented)
[19:57:40] <SWPadnos> nope. no analog output yet
[19:58:08] <SWPadnos> at least not in the git version I have from a week or so ago
[19:58:30] <micges> SWPadnos: will be this weekend implemented
[19:58:31] <SWPadnos> it would be called something like motion.analog-out-## if it exists
[19:58:36] <SWPadnos> pk :)
[19:58:39] <SWPadnos> ok
[20:01:49] <Lerman_> It would be pretty straightforward to have all numbered parameters visible in HAL. Put the parameters in contiguous memory and map it to a file. Then the interpreter just stores them (the way it does now) and HAL can have a component that maps the file and reads the value. My understanding is that VCP runs in user space, so a widget would be able to map the file without any problems. (Of...
[20:01:51] <Lerman_> ...course, a widget would also be able to change the file -- and thus change parameters on the fly.)
[20:02:20] <SWPadnos> that's problematic
[20:02:43] <SWPadnos> in fact, it's the exact opposite of the direction we should take with vars (which is to make an API for accessing them)
[20:02:49] <Lerman_> Only if you allow it. :-) and don't know what you are doing.
[20:03:51] <Lerman_> It's very cheap to do. So, have an API if you want. But that's a pretty natural way to implement the guts.
[20:04:40] <SWPadnos> all offsets and the current coordinate system are in there. I'm not sure it's wise to allow another program direct access to that
[20:05:46] <Lerman_> We trust the integrators, don't we? But should we :-)
[20:06:28] <Lerman_> If we wanted to, we could map just a section of the file.
[20:08:46] <Lerman_> bbl.
[20:15:36] <micges> good night all
[20:15:57] <SWPadnos> see you
[20:31:36] <jepler> $ git branch --with $commit ;# on which branches is the bad commit in?
[20:31:40] <jepler> wow, does that work?
[20:45:11] <alex_joni> heh, cool
[20:45:44] <alex_joni> jepler: that should be usefull after bisect, or whatever that option is called that identifies a faulty commit
[22:38:41] <cradek> jepler: whoah, the backplot sure is wrong now
[22:40:10] <cradek> in trunk
[22:40:30] <cradek> looking...
[22:42:48] <jepler> uh oh
[22:43:05] <cradek> weird, you hardly touched it
[22:43:25] <jepler> what kind of code? 3d?
[22:43:31] <cradek> no, simple lathe code
[22:43:34] <cradek> working on a pastebin
[22:44:01] <cradek> http://pastebin.ca/1483445
[22:44:08] <jepler> sim/lathe?
[22:44:12] <cradek> yes
[22:44:41] <jepler> I'll look now
[22:44:45] <cradek> cool
[22:44:48] <cradek> I don't spot it
[22:47:47] <jepler> how's it wrong?
[22:48:33] <cradek> http://imagebin.ca/view/ue56EWbG.html
[22:48:57] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/lathe-looks-ok-to-me.png
[22:49:16] <cradek> 2.4.0~pre ?
[22:49:36] <jepler> yes
[22:49:44] <jepler> I have a sinking feeling. try reverting 2a019987bb35c9761750103afa55b234b184fba2
[22:49:44] <cradek> ummmmmm
[22:50:05] <jepler> (though I'm not sure if that'll work, subsequent commits depend on it)
[22:50:47] <jepler> or maybe see whether the bad goes as far back as 2a019987bb35c9761750103afa55b234b184fba2
[22:51:29] <jepler> (is it lathe specific, or is that just all you tried?)
[22:51:47] <cradek> I've not tried anything else
[22:55:17] <cradek> I'm building 2a01998
[22:55:18] <cradek> (I think)
[23:01:20] <jepler> be back after dinner..
[23:19:26] <cradek> nope, it is change 13e7 that breaks it
[23:21:36] <cradek> specifically, the epsilon change
[23:25:55] <cradek> if( fabs(dp) < epsilon || fabs(dq) < epsilon ) return true;
[23:26:15] <cradek> this was supposed to protect against divide by zero, but it also returns true on suitably slow motion
[23:33:22] <CIA-1> EMC: 03cradek 07master * ra154c59995e9 10/src/emc/usr_intf/axis/extensions/emcmodule.cc: Fix incorrect backplot when motion is very slow
[23:35:27] <skunkworks> that wasn't what micges was seeing?
[23:35:39] <cradek> jepler: I see in your screen shot that you changed the program so it wouldn't reproduce it, and then said you can't reproduce it! that's funny.
[23:35:58] <skunkworks> heh
[23:36:12] <skunkworks> * skunkworks goes back to siding
[23:36:14] <cradek> skunkworks: I don't know. He insists that the machine motion is wrong in those cases, and if that's true, no
[23:36:26] <cradek> this was only a backplot bug.
