Back
[01:23:00] <cradek> guess nobody else is interested in playing in the sandbox
[01:27:29] <cradek> git 1.6 packages for dapper are now in the repository.
[01:43:11] <cradek> lerman: Lerman__: Lerman_: if you'd like to start using git for GWiz, you could do it now. I can help you get it started.
[01:44:33] <cradek> lerman: I was going to do that for you, but I don't see the source.
[02:49:16] <jepler> cradek: try this:
http://emergent.unpy.net/index.cgi-files/sandbox/0001-Directly-use-X-font-metrics-because-Tk8.5-font-meas.patch
[02:49:43] <jepler> it's entirely possible that it's broken, because I used git-gui to stage only some of my changes (I had unrelated changes in my working tree)
[02:50:43] <cradek> testing...
[02:51:16] <cradek> wooo
[02:52:00] <jepler> it's not fuzzyfonts, but I hope everything's at least in the right place?
[02:52:06] <jepler> did you try changing font size (I didn't)
[02:52:26] <cradek> everything looks right to me
[02:52:29] <jepler> yay
[02:52:39] <cradek> slick, thanks
[02:52:40] <jepler> hm, the keyboard shortcut shown for View > Large coordinate font (r) doesn't work
[02:52:48] <jepler> because it's also "rotated side view"
[02:53:03] <cradek> it sure is - I would have never noticed that.
[02:58:15] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/ (configure configure.in): detect a common rtai configuration error
[03:00:01] <jepler> (I wonder if that configure error will make any farm slots error...)
[03:02:12] <jepler> a slightly more daring change, not sure yet if I want to make it:
http://emergent.unpy.net/index.cgi-files/sandbox/0002-Use-python-opengl-instead-of-our-hacked-opengl-but.patch
[03:02:30] <cradek> yep, sounds daring
[03:02:32] <jepler> it would make emc require python-opengl, but get rid of 800 lines of unmaintained opengl wrappers
[03:02:46] <jepler> oops, I sure fouled that up .. that stuff shouldn't be in the patch!
[03:02:53] <SWPadnos> heh
[03:02:56] <jepler> (sim.var.bak and 0001-*)
[03:03:02] <SWPadnos> I just noticed the Tk stuff
[03:03:05] <cradek> but we've never had to touch the wrappers since writing them, have we?
[03:04:54] <jepler> occasionally I add to them
[03:05:21] <jepler> occasionally they foul up people building emc, but mostly because they invited nvidia to take a big old dump all over their system
[03:05:48] <SWPadnos> now that's not fair
[03:06:09] <SWPadnos> NVidia only dumps all over the graphics, OpenGL, and PCi/AGP/PCIe bus areas of the system
[03:07:03] <jepler> there, revised
http://emergent.unpy.net/index.cgi-files/sandbox/0002-Use-python-opengl-instead-of-our-hacked-opengl-but.patch
[03:07:40] <jepler> I wish I remembered some more details about the PyOpenGL problems .. Togl (the Tk interface) was always a problem, and then there was also a terrible memory leak I tickled
[03:08:08] <cradek> I'm struggling to see why the payoff would be worth it, but you're the boss
[03:08:25] <jepler> I am?
[03:08:25] <jepler> wow cool
[03:08:35] <cradek> my nvidia-crapped-up systems work just fine - what do people manage to do?
[03:09:09] <cradek> end up with the crap half-installed somehow? can pyopengl really fix that? I thought they ended up with no working glx extension in the x server.
[03:09:22] <cradek> as in glxgears doesn't even work
[03:09:37] <jepler> there's another problem where you end up with non-working opengl headers
[03:09:52] <jepler> I don't really understand it; I just insult them until they reinstall Ubuntu from scratch due to the burning shame
[03:09:58] <cradek> oh so they can run, but not build?
[03:10:10] <jepler> In this scenario I'm thinking of, yes
[03:10:16] <cradek> I haven't seen that one I guess. no clue here.
[03:10:34] <SWPadnos> me either
[03:10:36] <jepler> this inspired the check AC_MSG_CHECKING(for working GLU quadrics)
[03:10:40] <jepler> which has probably been there a long time
[03:11:07] <SWPadnos> oh look, buildbot failures :)
[03:11:11] <cradek> "for god's sake stop following instructions you read on the internet ... except if I say so ... on ... irc"
[03:13:11] <jepler> hm, where'd cia go anyway?
[03:13:13] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/ (configure configure.in): revert the RTAI_MATH check until we can sort out the failures it caused
[03:13:32] <jepler> oh hai
[03:13:34] <jepler> 'night guys
[03:13:38] <jepler> I've probably done enough damage for one day
[03:14:27] <cradek> heh, goodnight
[03:14:31] <cradek> thanks for fixing the fonts
[03:15:07] <SWPadnos> see you
[03:15:36] <jepler> cradek: you're welcome
[03:15:38] <SWPadnos> now to see why python is so screwed up on one dapper machine, but not on the other (nearly identical) machine
[03:15:41] <jepler> cradek: how is 9.04? good?
[03:15:50] <cradek> my thinkpad suspends right
[03:16:07] <cradek> the network manager and printing notifier thingy are nicer
[03:16:11] <jepler> I wonder if I shouldn't break my own, reasonbly-working laptop
[03:16:22] <jepler> nah, forget I mentioned it
[03:16:32] <cradek> wfm
[03:16:37] <SWPadnos> 9.04 seems better in a few ways - faster bootup and shutdown, nicer applications (like net manager ...)
[03:16:40] <cradek> nothing is newly-broken
[03:16:54] <SWPadnos> I think the install even includes gcc
[03:17:23] <cradek> I'm just so happy to have working suspend...
[03:17:25] <SWPadnos> oh, and the "make a bootable USB stick" program works
[03:17:28] <cradek> oh, also bluetooth
[03:17:42] <SWPadnos> cool. I should mess with suspend on my laptop
[03:17:47] <SWPadnos> and bluetooth :)
[03:18:10] <SWPadnos> maybe it's time for another hard drive upgrade in there
[05:34:04] <CIA-2> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/stepgen.c: Handle firmwares with stepgens v0-v2, but warn about bugs in v0 and v1
[10:57:28] <micges1> micges1 is now known as micges_emc
[11:33:07] <jepler> apparently all old smp rtai had killer bugs, but he's far from specific about what they *are*:
http://pastebin.ca/1464746
[12:43:39] <alex_joni> and an update from Paolo:
http://pastebin.ca/1464803
[12:43:44] <alex_joni> a bit more specific, but not much
[12:44:00] <alex_joni> basicly 2.6.26 and 2.6.27 are a big no-no for use with RTAI
[12:44:02] <jepler> BigJohnT: did you get a chance to try out the new git.linuxcnc.org? I wrote that e-mail about how to switch to it without a huge download just for you
[12:44:19] <BigJohnT> I just did a few seconds ago
[12:44:40] <BigJohnT> trying to sort it out atm
[12:44:46] <jepler> ok
[12:44:48] <jepler> I'm around if you have questions
[12:45:23] <BigJohnT> it still looks like it is emc-experimental when I load up git-gui
[12:45:55] <alex_joni> BigJohnT: I found it easiest to edi .git/config by hand (iirc the name)
[12:46:45] <jepler> BigJohnT: is it possible that's just showing your local directory name?
[12:47:22] <BigJohnT> config has emc2-sandbox.git as remote so I think your on it jepler
[12:48:24] <BigJohnT> yep
[12:48:49] <alex_joni> you can also safely rename the folder name
[12:49:28] <BigJohnT> just did that :)
[12:59:27] <BigJohnT> is there a way to tell git to ignore backup files like .lyx~
[13:00:54] <jepler> yes
[13:01:14] <jepler> git uses ".gitignore" files for this purpose. They're similar to .cvsignore files, but of course more powerful.
[13:01:35] <BigJohnT> thanks
[13:01:45] <jepler> if you run this command, you'll get a change that converts .cvsignore files to .gitignore files: git pull git://git.unpythonic.net/emc2-ignores.git master
[13:02:42] <jepler> for editor backup files, it is recommended to use a global .gitignore file. Set up ~/.gitignore as your global gitignore file: git config --global core.excludesfile ~/.gitignore
[13:02:56] <jepler> then put patterns in your ~/.gitignore file such as *~
[13:03:32] <jepler> this pattern is automatically applied in every directory of every git project you use
[13:05:30] <jepler> (the reason that editor backup files are recommended to be put in a personal gitignore file rather than a project gitignore file is that your editor might use different backup filenames than mine)
[13:05:44] <BigJohnT> ok thanks
[13:08:41] <jepler> I put this in our wiki page in a new "tips and tricks" section:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Git#Use_a_global_ignore_file_for_editor_backups
[13:10:20] <BigJohnT> jepler: thanks
[13:18:03] <BigJohnT> jepler: that is working now... I'm off to work now
[13:40:00] <cradek> jepler: Jun 18 08:22:19 git git-daemon: [54551] 'receive-pack': service not enabled for '/git/emc2-sandbox.git'
[13:40:06] <cradek> does this mean someone is trying to push to a git:// checkout?
[13:40:10] <jepler> yes
[13:40:22] <cradek> oh, ok - that's not gonna work.
[13:41:24] <cradek> seems like gitosis doesn't have a graceful way to handle more than one key per developer
[13:42:10] <jepler> I *think* I read that you can actually put as many keys you want in the files, but maybe that's not true
[13:42:16] <cradek> oh, ok
[13:42:24] <jepler> (that would certainly be a sensible way to do it)
[13:43:49] <cradek> this is interesting, and could be useful on a host where you can't do fancy stuff, but I think my setup gives superior security in several important ways
[13:44:15] <SWPadnos> would gitosis be useful on DH?
[13:44:25] <cradek> (also managing the keys in git is a cute trick)
[13:45:12] <cradek> SWPadnos: if there is a problem with creating several user accounts, it would solve that problem
[13:45:40] <cradek> it wouldn't solve the other problems like how you can't run git-daemon
[13:45:58] <SWPadnos> heh - ok
[13:46:48] <cradek> it also doesn't solve the problem of letting each user admin his own keys - the best possible solution would have that too, I think.
[13:48:19] <SWPadnos> I guess that depends on who has access to what parts of the ssh key repo
[13:48:42] <jepler> in git you can't protect different parts of a single repo differently
[13:48:51] <cradek> yeah, you'd need per-file acl for files in the key git, which surely isn't in git
[13:49:01] <jepler> so if my key and your key are in a single repo, and I can write my key, I can write yours
[13:49:05] <jepler> hi BJT-Work
[13:49:11] <SWPadnos> ok
[13:49:13] <BJT-Work> hi jepler
[13:59:14] <cradek> I notice that I *do* have the full history of branches in my clone. I can convert the branches to local and/or checkout them without contacting the server
[13:59:40] <cradek> so I think we *will* each have full backups, like we hoped.
[14:00:07] <jepler> yes, that's my understanding as well
[14:01:28] <jepler> If the repository on git.linuxcnc.org had remotes with branches, *that* is the information you wouldn't have in your clone
[14:01:31] <jepler> but it *shouldn't*
[14:01:38] <micges> bbl
[14:04:16] <cradek> ok, that eliminates one of my disappointments. yay
[14:29:39] <cradek> Ken L and I talked at fest about how to package wizards and integrate them with emc. I have the source for GWiz and was about to make a git repo for it and do an initial import, but I wonder if that's what we want. I was also considering a "wizards" repository where gwiz would be just one directory. I figure we might have several kinds of wizards and we might want to package them together as emc2-wizards. what do you all think?
[14:30:20] <cradek> I guess the immediate question I have is whether to call the repository "gwiz" or "wizards" or something else
[14:31:04] <Lerman_> Hello sailor. It's not polite to talk about someone behind his back. :-)
[14:31:23] <BJT-Work> If there is more than one wizard then I'd say wizards
[14:31:30] <cradek> well, there were three of you, so I didn't know if I was behind you or not.
[14:31:49] <Lerman_> There will be more than one set of wizards (I expect).
[14:32:16] <BJT-Work> might even find some of the ones on wiki useful to add
[14:32:30] <cradek> so I should make it a "wizards" repository?
[14:32:50] <Lerman_> I've interacted with at least two different people who are interested in publishing wizards.
[14:32:54] <BJT-Work> that makes sense
[14:32:56] <cradek> I guess I don't have a vision for how it will eventually work out
[14:32:57] <cradek> ok then
[14:33:25] <jepler> If the goal is to get wizards into a package that is installed by default, then we should try to collect them in one place even if they're from multiple authors
[14:33:26] <Lerman_> When herding cats, don't assume that they will all want to go in the same direction.
[14:33:39] <cradek> Lerman_: of course, so true
[14:34:06] <jepler> hopefully 80+% of them will fit within the gwiz framework
[14:34:11] <Lerman_> As you probably noticed, I've created two .deb packages -- one for the gwiz framework and one for demo wizards.
[14:34:18] <cradek> jepler: I think that's my goal (not sure about default, but I'd like to be able to install a package and then (somehow) have them available in a consistent way)
[14:34:46] <cradek> Lerman_: I must admit to not even having installed them yet.
[14:35:49] <cradek> I was concentrating on how to get set up for people (including me) to contribute to them
[14:36:06] <cradek> (for example, I have an unpolished wizardy thing I wrote for boring)
[14:36:08] <jepler> my gut reaction is to put gwiz + (well-tested) wizards in one git repository, distinct from the emc2 repository
[14:36:21] <cradek> yes, me too
[14:36:45] <Lerman_> The directory /usr/share/gwiz/wizards is the root of all wizards. Various users can create their own trees within that directory. I'd suggest that each user who wants to can create his own tree under there.
[14:36:59] <cradek> it can be one of those things where if you have side-by-side checkouts, they can be told to know about one another (for RIP)
[14:38:00] <Lerman_> Right now, gwiz isn't smart enough to let someone enable only the subtrees of interest. But someday...
[14:38:43] <jepler> as for tree organization, I'd think grouping by purpose (e.g., boring, facing) makes more sense than grouping by author (e.g., cradek's unrelated wizards, ken's unrelated wizards)
[14:40:25] <Lerman_> The problem is that the author determines the underlying required context. For instance, one author might say that #<_feed> is a global containing the selected feed rate for all of his wizards, while another author passes the feed rate as a parameter to each wizard.
[14:41:54] <Lerman_> Having to select among four different circular pocket wizards might be difficult without knowing the author and the context he assumes. In the long run, we will probably come up with some "best practices", but for now, it will probably just be a free for all.
[14:42:28] <Lerman_> In the long run, I agree with jepler.
[14:42:59] <Lerman_> In the short run, perhaps the description should include the author or package name.
[14:44:24] <jepler> I'm not saying not to credit the author, or that there may be only one "boring" wizard
[14:44:35] <jepler> I'm imagining the user who is staring at the tree of wizards in gwiz and has a task to perform
[14:44:56] <jepler> show the information that will help the user find the right wizard most prominently
[14:45:45] <Lerman_> I can't disagree, since that is how I set up my wizards.
[14:47:19] <cradek> git clone ssh://yourname@git.linuxcnc.org/git/wizards.git
[14:50:55] <Lerman_> Done.
[14:51:22] <cradek> cool, next stick your source in there!
[14:51:49] <jepler> cradek: how will wizards.git work as far as cia and emc-commit?
[14:52:03] <cradek> I haven't done either. what do you suggest?
[14:52:32] <jepler> I'm not sure I have a suggestion
[14:52:37] <jepler> probably something more than silence
[14:53:49] <Lerman_> Copied.
[14:56:11] <jepler> then "git add ." (assuming all the files should be added), "git commit -s" (enter message), "git push"
[14:56:38] <jepler> if you have stuff like editor backup files, then either remove them before 'git add .', or 'git add' each individual filename
[14:57:00] <cradek> (I think the -s thing is silly)
[14:59:58] <Lerman_> Done. I think. How do I get it to use a real editor :-) instead of vi? EDITOR environment variable?
[15:00:26] <Lerman_> Now how do I delete the editor backup files?
[15:01:01] <cradek> yes set EDITOR to whatever you like -- lots of stuff uses that.
[15:02:42] <jepler> Lerman_: also, you should configure your identity --
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Git#Configure_your_identity
[15:04:12] <micges> cradek: short about my path error: It looks like three lines of G0 executes wrong in some points, my patch was to make G0, G4 P0.01, G0, G4P0.01, G0, G4P0.01, and from about 1.5 days everything is ok, before was error about 2 times/24h (tomorrow I'm going to install trunk on one of them and see if my memory init patches works in some way on three consecutives G0)
[15:04:39] <jepler> Lerman_: assume for the moment that you had noticed the backup files were added to the history, and wanted to fix it
[15:04:54] <cradek> micges: I would be very happy if you could give me a way to reproduce the problem on an unmodified sim
[15:05:14] <Lerman_> Yup. I noticed that.
[15:05:35] <Lerman_> And want to delete them plus the .deb files I created.
[15:05:38] <jepler> Lerman_: you can tell git to remove a file with 'git rm -f': git rm -f GWiz/*~ GWiz/*/*~
[15:06:21] <jepler> (there are a few more that doesn't catch.. but you get the idea and can do the rest)
[15:07:32] <jepler> now, if you *hadn't* pushed, you could amend your commit: git commit --amend
[15:08:05] <jepler> but since you *did* push, you can only do a regular "git commit"; your mistake remains in the history forever
[15:08:45] <SWPadnos> cradek, do you want one or two of those opto-22 boards?
[15:08:50] <SWPadnos> or anyone who uses Mesa, I guess
[15:09:36] <cradek> SWPadnos: ooh, tell me more
[15:10:06] <SWPadnos> G4PB24 relay racks, direct plug-in to Mesa card, swappable per-pin for AC in or out or DC in or out
[15:10:20] <SWPadnos> screw terminals for all connections
[15:10:30] <SWPadnos> $30 on eBay
[15:11:13] <SWPadnos> the guy has 5 of them, and I can get all 5 for $25 + reduced shipping, so I can send out a few for $30-ish with shipping
[15:11:22] <SWPadnos> with modules even
[15:11:33] <SWPadnos> (that's $25 each, of course_
[15:11:35] <SWPadnos> )
[15:11:52] <cradek> I'll happily take one for that
[15:12:00] <SWPadnos> ok
[15:12:17] <SWPadnos> it seems like a nice price for a 7i37T+terminals setup :)
[15:12:23] <SWPadnos> though they are bigger
[15:12:57] <cradek> but they have blinky lights
[15:13:17] <SWPadnos> yes, lights for all the I/O modules, plus the output modules take fuses
[15:13:24] <Lerman_> OK. I accidentally deleted most everything. How do I get it back? (I left out a ~ on a find...)
[15:14:16] <cradek> git reset --hard
[15:14:50] <Lerman_> Works for me. Thanks.
[15:16:16] <cradek> there should not be .deb files in git - just the rules to make them
[15:17:02] <Lerman_> I'm deleting them now. How do I get rid of a directory. git rm -rf GWIZ.deb removes the contents; but not the directory itself.
[15:17:48] <cradek> rm -r does remove the directory
[15:18:08] <skunkworks_> SWPadnos: how many do you have now?
[15:18:17] <SWPadnos> I will have 5
[15:18:35] <skunkworks_> heh - I would like 2 if you can spare them...
[15:18:36] <SWPadnos> I've got several others here already, I'm just trying to get a better mix of modules
[15:18:38] <SWPadnos> ok
[15:18:40] <Lerman_> Not git rm -r?
[15:19:43] <cradek> oh, git rm -r? I don't know
[15:20:27] <cradek> brb
[15:20:29] <Lerman_> git rm -r didn't do it.
[15:21:12] <SWPadnos> is there a git rmdir?
[15:21:38] <Lerman_> I tried it and there wasn't.
[15:35:06] <cradek> maybe you can just adjust things with the regular commands (like rmdir) and then git add . or git commit -a
[15:37:48] <cradek> looks like you got it
[15:38:34] <cradek> SWPadnos: you want some payment now? are the modules extra?
[15:39:05] <SWPadnos> no payment now, and some modules are included
[15:39:10] <jepler> Lerman_: what version of git do you have? I have "-r" and "-f" flags for "git rm". git version 1.6.2.1.469.gdffc
[15:39:15] <SWPadnos> think about what mix you want
[15:39:43] <cradek> SWPadnos: ok, I'll try to make a list, thanks
[15:39:50] <SWPadnos> sure
[15:44:50] <Lerman_> Git version 1.6.3.1
[15:45:56] <cradek> I think if you remove all the files in a directory, the directory may go too. git apparently doesn't know about empty directories.
[15:48:23] <Lerman_> Does .gitignore work on a per directory basis or will it inherit from its parent directory?
[15:49:10] <cradek> Lerman_: maybe you want this:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Git#Use_a_global_ignore_file_for_editor_backups
[15:49:22] <cradek> (I think it does not inherit)
[15:49:24] <jepler> Lerman_: 'man gitignore' for all the gory details, but basically you can put projectwide rules in the top .gitconfig
[15:50:06] <Lerman_> That's what I need. Thanks.
[15:50:09] <cradek> imo, editors should know not to make droppings when using VC
[15:50:52] <jepler> cradek: I'm not sure I agree, but even then there are vim .swp files and the like
[15:51:23] <cradek> editors also shouldn't crap out .swp files everywhere
[15:52:06] <jepler> given that we're all using imperfect software, it's nice that git has solutions that you can set up once and forget about
[15:59:19] <skunkworks_> stuart got it working!
[15:59:28] <skunkworks_> (it looks like)
[15:59:52] <cradek> jepler: to install stuart's vismach and kinematics, I just did comp --install his-kins.c and comp --install his-vismach.py. that's neat, thanks.
[16:00:16] <cradek> skunkworks_: yep it is looking better and better. I helped him last night with one last (?) detail.
[16:07:33] <geo01005> is this a new vismach?
[16:07:58] <cradek> he made a model of his cincinati to help himself develop the kinematics for it
[16:08:15] <geo01005> ahh, I see.
[16:08:40] <geo01005> is there any cad software that makes that easier?
[16:08:49] <cradek> makes what easier?
[16:08:58] <geo01005> making a vismach model.
[16:09:11] <jepler> no, it's purely done by editing a text file that declares the geometry
[16:10:30] <geo01005> I was just wondering is the format in the text file would be similar at all to some cad format. Oh well that is ok, it only has to be done once (for your machine)
[16:10:54] <jepler> no, the format is a Python program
[16:11:54] <jepler> for single parts that move as a unit, you can use ASCII STL and ASCII OBJ formats, whatever those are (alex_joni made me add them)
[16:12:04] <jepler> if you want to closely model some specific part of the machine like a vise
[16:16:09] <geo01005> Ti uses openGL, right?
[16:17:27] <geo01005> It^^
[16:21:19] <skunkworks_> emc seems like it would be great for machines that are consistantly off. ;)
[16:27:25] <cradek> hm, when I do git log -SXXX, I get a bunch of changes to binary files
[16:29:35] <cradek> maybe it can't know...
[16:38:23] <cradek> the vast majority of adding/removing XXX comments have my name on them :-)
[16:50:24] <alex_joni> geo01005: you can model the whole machine in 3d cad, if you're using assemblies and parts
[16:50:44] <alex_joni> then you just need to convert each moving part to a different drawing, and export those to obj or stl
[16:51:03] <alex_joni> (or any other mesh, there's MeshLab at sourceforge which converts between arbitrary mesh formats)
[16:51:29] <geo01005> I see.
[16:52:04] <alex_joni> you still need to define how to position the imported obj, and where the connection point to the next model is
[16:52:05] <geo01005> Too bad you can't leave them in a light weight format like STEP.
[16:52:10] <alex_joni> and how they relate to each other, etc
[16:52:16] <geo01005> Sure I expected that.
[16:52:26] <alex_joni> geo01005: yeah, but STEP doesn't really define motion & interactions either
[16:52:42] <alex_joni> or maybe some substandard does, I haven't seen something that reads it though
[16:54:08] <geo01005> parasolids could... but you aren't getting that opensource ;)
[16:54:25] <alex_joni> x_t ?
[16:54:49] <geo01005> yeah.
[16:55:05] <alex_joni> I'm happy that my cad imports parasolid now ;)
[16:55:14] <alex_joni> a bit far from open source though
[16:55:56] <geo01005> I love the whole parasolids engine, but it is far from being free as well.
[18:06:06] <skunkworks_> does this sound ok?
[18:06:07] <skunkworks_> http://pastebin.ca/1465134
[18:07:28] <SWPadnos> yes, but I fixed a typo or two :)
http://pastebin.ca/1465136
[18:08:35] <skunkworks_> SWPadnos: thanks!
[18:08:46] <SWPadnos> sure
[18:15:25] <micges> I want emc log all debug info from emc to file but set_rcs_print_file() from rcs_print.cc won't work
[18:15:42] <micges> anyone used that ?
[19:31:11] <micges> cradek: give me few minutes
[19:35:17] <micges> cradek: steps to reproduce:
[19:35:36] <micges> 2.3 branch ccvs copy
[19:36:01] <micges> extend sim_mm max limit from 254 to 1254 in x and y
[19:37:45] <micges> load this rpgoram:
http://www.pastebin.ca/1465229
[19:37:56] <micges> I've run it from begn to end 2 times
[19:38:23] <micges> and at 3rd I've enabled all debug to console
[19:39:32] <micges> and then I've few times break program on g0 between figures and selected rfl some else G0 ( but only those g0 which moves at Z=3)
[19:39:48] <micges> and after few such times I've run it to end
[19:39:55] <micges> thats all
[19:40:07] <cradek> you use rfl to make this wrong behavior happen?
[19:40:57] <micges> yes
[19:41:06] <cradek> WHY DIDN'T YOU SAY THAT
[19:41:10] <jepler> well that's an interesting fact that didn't emerge before now
[19:41:44] <cradek> if you abort somewhere and select a line that is "G0 Z10" elsewhere, it will make a diagonal move to that line's endpoint
[19:41:50] <cradek> that is very well known behavior
[19:42:52] <micges> don't be silly, it's not behaviour I'm talking about
[19:43:27] <cradek> I have no idea what you're talking about - you have to explain, not make me guess
[19:43:50] <micges> rfl is working fine and predictible
[19:44:06] <micges> bad path on screen was about 1000 lines afterr rfl
[19:45:37] <jepler> what cradek is trying to get is a step by step way that he can follow and see the buggy behavior
[19:46:11] <jepler> you are being unclear about how RFL is related to this problem you're reporting
[19:47:27] <micges> sorry
[20:01:21] <cradek> hi awallin, haven't seen you around for a while.
[20:06:57] <awallin> hi cradek, not much time for irc lately. we've moved our cnc mill, hope to set it up in the new workshop soon
[20:07:01] <micges> http://www.pastebin.ca/1465274
[20:07:38] <micges> cradek: look at line 53 aND 56
[20:08:17] <micges> maybe this will help
[20:09:57] <alex_joni> micges: you mean that 2791, 92, 93, 94 and 95 are missing?
[20:11:44] <micges> yes
[20:12:08] <micges> look at the preview:
http://imagebin.ca/view/6OomJ4X.html
[20:13:33] <micges> brb
[20:16:22] <cradek> does this happen with the naive cam detector turned off? (g64 or g61)?
[20:16:37] <cradek> I see that line 2792 is a short, strange move
[20:17:51] <jepler> according to that backplot, it rejoins in the middle of line 2496
[20:18:05] <jepler> are you sure this is not a display glitch? there is no guarantee that axis samples the commanded position at a fixed interval
[20:18:51] <alex_joni> good night all
[20:19:18] <cradek> rejoining in the middle of a line does sound like a display glitch
[20:19:29] <jepler> that one shape is not unique in having degenerate moves
[20:20:26] <cradek> it seems like we should have received some motion id 2794 though...
[20:21:59] <jepler> I don't know what "motion id"s are. are they supposed to correspond to physical line numbers?
[20:22:00] <micges> iab
[20:22:14] <cradek> yes I think so
[20:23:45] <micges> emcTrajSetMotionId(emcStatus->task.currentLine);
[20:24:06] <micges> current executed lines
[20:24:44] <micges> jepler: I'm sure that isn't dispaly gliches
[20:25:51] <jepler> mine finally reached line 2796 and it is just fine
[20:27:25] <micges> http://www.pastebin.ca/1465298
[20:27:36] <micges> adding to interp list is ok
[20:29:47] <jepler> I have "took xxx seconds" for motion id 2790, 91, 93, 94, 95, 96, 97, 98, 99, 2800, 2082, 2084 in my log
[20:31:30] <micges> jepler: this in not specifilcally that part generate error
[20:31:52] <micges> it is potentally on every deeping into material
[20:32:17] <micges> there is no repeat of place of error
[20:33:01] <cradek> micges: are you sure you are running exactly the same code as we have from -rv2_3_branch, with none of your recent changes?
[20:33:39] <jepler> reading the source code, I don't see any guarantee that every motion gets a "Motion id %d took %f seconds" print; it's printed in userspace in emcTrajUpdate based on polling
[20:33:48] <micges> yes
[20:35:25] <cradek> void SET_MOTION_CONTROL_MODE(CANON_MOTION_MODE mode, double tolerance)
[20:35:27] <cradek> ...
[20:35:31] <cradek> canonMotionTolerance = FROM_PROG_LEN(tolerance);
[20:35:40] <cradek> however:
[20:35:44] <cradek> double GET_MOTION_CONTROL_TOLERANCE()
[20:35:47] <cradek> return canonMotionTolerance;
[20:36:17] <cradek> if you have changes that try to preserve this using this GET call, it seems like you might lose some factors of 25.4
[20:36:31] <cradek> I'm pretty sure this is wrong, BUT it is unused in my version
[20:37:09] <micges> good night all
[20:37:58] <cradek> it also ran ok for me here
[20:39:13] <jepler> cradek: you're imagining that, with the patch that adds calls to GET_MOTION_CONTROL_TOLERANCE, the tolerance value gets magnified every time by FROM_PROG_LEN(1)
[20:39:27] <cradek> yes
[20:39:33] <jepler> sounds likely to me
[20:39:46] <cradek> but I don't know if that patch exists - I haven't been keeping up with all that
[20:40:02] <jepler> I think it's one of the ones I reverted; it's the one that broke the testsuite
[20:40:03] <cradek> I removed the GET call from my canon and rebuilt -- nothing uses it in -rv2_3_branch
[20:40:13] <jepler> (not because the testsuite showed that problem, but just because it changed the output)
[20:41:10] <cradek> I'm grasping at straws. I still haven't seen the problem unfortunately.
[20:44:26] <cradek> jepler: I see after further examination that the potential problem I found would only affect us inchers.
[20:44:36] <jepler> that's a novel turn of events
[20:44:41] <cradek> isn't it though
[20:45:40] <jepler> Motion id 982 took 0.003816 seconds.
[20:45:40] <jepler> Motion id 983 took 0.004046 seconds.
[20:45:40] <jepler> Motion id 984 took 0.004058 seconds.
[20:45:40] <jepler> Motion id 985 took 0.012160 seconds.
[20:45:40] <jepler> Motion id 988 took 0.006865 seconds.
[20:45:43] <jepler> Motion id 982 took 0.003816 seconds
[20:46:00] <jepler> here's an exmaple where there are missing motion IDs, simply because the segments were very short and task didn't poll during every one of them
[20:46:34] <jepler> in this case, it's interesting to note that the motion *before* the missing motions is reported as having taken longer
[20:47:07] <jepler> #
[20:47:08] <jepler> Motion id 2790 took 1.019885 seconds.
[20:47:21] <jepler> in micges example, it's also the one just before the missing ones that is reported as taking a long time
[20:48:23] <cradek> are you sure those are not legitimately skipped motions due to naive cam?
[20:48:25] <jepler> 2790 is a short move down 3.5mm
[20:48:39] <jepler> cradek: I programmed G64 with no P value.
[20:48:47] <cradek> oh ok
[20:49:01] <jepler> Issuing EMC_TRAJ_LINEAR_MOVE -- (+220,+116, +0,8.836660,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000, +2,30.480000,30.480000,508.000000, +0,)
[20:49:06] <jepler> Outgoing motion id is 985.
[20:49:48] <cradek> so we still have no real conclusive evidence :-/
[20:49:49] <jepler> a 3.5mm move at F2000 shouldn't have taken 1 second. It's a userspace glitch that caused task not to update for about 1 second
[20:51:47] <jepler> maybe there's a real problem that causes emc to not actually follow the path
[20:52:01] <jepler> but this screenshot and debug log isn't it
[20:52:14] <cradek> I think you have convinced me of that
[21:05:08] <jepler> killall -STOP milltask; sleep 1; killall -CONT milltask
[21:05:35] <jepler> ^^^ having done that during a run, I caused a backplot that looks a lot like micges's:
http://emergent.unpy.net/files/sandbox/just-like-micges-behavior.png
[21:10:16] <SWPadnos> ohcool. gcc has a "deprecated" attribute, which results in a warning whenever the {variable,function,type} is used
[21:10:43] <SWPadnos> (at compile time, of course)
[21:14:41] <jepler> yeah, we use it a little bit at work
[21:30:58] <SWPadnos> might it make sense to add e.g. G2.1 and G3.1 which would allow one to program center locations in non-relative coordinates?
[22:04:28] <cradek> we already have that feature but it's spelled g90.1/g91.1
[22:04:39] <SWPadnos> oh, OK
[22:04:51] <SWPadnos> it makes IJK act like absolute vs. relative?
[22:04:56] <cradek> yes
[22:05:04] <SWPadnos> that was quick :)
[22:05:10] <SWPadnos> or I'm slow :)
[22:05:16] <cradek> try to keep up, jeez
[22:06:12] <cradek> I see that's not in the gcode quickref.
[22:06:24] <SWPadnos> oh. lucky me
[22:06:26] <SWPadnos> I looked at that
[22:23:39] <CIA-2> EMC: 03cradek 07TRUNK * 10emc2/docs/html/gcode.html: absolute arc centers have been available for a while...
[22:24:14] <jepler> SWPadnos: (do you have in mind something to mark as deprecated in emc?)
[22:25:44] <cradek> bbl
[22:35:01] <SWPadnos> jepler, no, it just seemed like a cool feature
