Back
[00:58:30] <alex_joni> jtr_: better?
[00:59:06] <alex_joni> cradek: what are you testing? sim or rt?
[00:59:13] <cradek> sim
[00:59:20] <alex_joni> ok, I'll build the rt package
[00:59:24] <cradek> ok thanks
[00:59:40] <alex_joni> * alex_joni likes debuild
[00:59:38] <cradek> I did not check it in - just mv postinst to emc2.postinst
[00:59:47] <alex_joni> same here
[01:00:29] <cradek> that successfully removed it from emc2-sim
[01:00:58] <alex_joni> nice.. I'll know in a bit if it's still in the emc2 package
[01:02:18] <cradek> still extra junk in the sim package - rtapi.conf, init.d/realtime
[01:02:55] <alex_joni> ulapi.conf :D
[01:02:56] <jepler> I think those are actually used, as little sense as that makes
[01:03:03] <alex_joni> init.d/nonrealtime
[01:03:15] <cradek> ok, they're harmless anyway
[01:03:55] <alex_joni> * alex_joni wonders what's up with the timezone again
[01:04:03] <alex_joni> I feel so fresh :)
[01:07:26] <cradek> it's a little late for you, isn't it
[01:07:38] <alex_joni> doesn't feel like that
[01:07:48] <alex_joni> anyways, the postinst is still in the emc2 package
[01:08:06] <cradek> yay
[01:08:14] <cradek> I committed it already :-)
[01:08:36] <alex_joni> I saw
[01:08:41] <alex_joni> CIA was quick this time
[01:11:39] <cradek> jepler: do you remember the mime helper trick for .desktop files? I can't figure it out (again)
[01:15:15] <jepler> cradek: which trick?
[01:15:19] <jtr_> alex_joni: sorry - phone. Thanks, see them now. Was having trouble getting connected with xp, tried to read the logs, and found them missing.
[01:15:31] <jepler> cradek: (I'm afraid that may be a "no")
[01:15:39] <cradek> you found some app that looks up a mimetype and runs the right application to handle it
[01:15:51] <jepler> oh
[01:15:52] <cradek> I thought it was somethign like gnome-mumble-mimetype-handler
[01:17:03] <alex_joni> I think he has the pdf as the executable
[01:17:05] <jepler> there's gnome-open
[01:17:20] <alex_joni> err.. sorry
[01:17:24] <jepler> but dare I say that's gnome specific
[01:17:37] <alex_joni> evince is in the emc2-doc.desktop
[01:18:12] <cradek> I suppose it doesn't matter, since these are specific to dapper/breezy and we know pretty well which apps to use
[01:18:42] <cradek> I wonder if these menus work in kde - I don't remember if someone tried it
[01:18:48] <jepler> that's what I thought you might have been asking about
[01:21:32] <cradek> yes I think so, thanks
[01:25:49] <jepler> iirc, the secret to making kde work was the "cnc.directory" file which seems to be in the debs
[01:26:09] <cradek> great
[01:27:29] <alex_joni> cradek: are you still playing with the debian/ folder?
[01:27:43] <alex_joni> if so, I'll make some newer packages tomorrow :)
[01:27:56] <cradek> I think I'm done for now
[01:28:26] <alex_joni> mind if I make it alpha1 ?
[01:28:29] <cradek> -sim looks pretty good here now - menu entries work, etc
[01:28:33] <cradek> please do
[01:28:34] <alex_joni> I want to get update working
[01:28:44] <alex_joni> ok
[01:32:22] <cradek> wonder if I should put my g92 "fix" on the branch so it doesn't get forgotten
[01:32:48] <cradek> (I'm pretty sure it's better than the old behavior)
[01:33:37] <alex_joni> then go for it
[01:41:00] <jepler> you can make a .desktop file which is a "Link" to another file (think microsoft .lnk) -- but it won't display in (kde, at least) menus -- only on the desktop
[01:41:14] <jepler> too bad, because that would get you your desktop's default behavior for the file of that type
[01:41:29] <cradek> I think that's what I tried first when I did that
[01:41:39] <cradek> I thought it was a stupid limitation
[01:42:03] <jepler> yeah
[01:44:01] <jepler> there must be two kinds of desktop environments: those I complain about, and the one I use
[01:44:24] <cradek> there's only one kind for me
[01:44:44] <jepler> I'm being generous to call icewm a desktop environment, but it *does* have a task bar
[01:47:13] <cradek> I'm so ashamed of that hack
[01:47:17] <alex_joni> yay..
[01:47:28] <alex_joni> the quick reference works in the upgraded package
[01:47:29] <alex_joni> :)
[01:47:48] <cradek> cool
[01:47:57] <cradek> I like that quick reference - I use it a lot
[01:49:34] <alex_joni> uploading new packages
[01:50:56] <cradek> keystick doesn't work...
[01:51:33] <alex_joni> does here
[01:51:50] <jepler> works here (HEAD)
[01:52:01] <jepler> RIP
[01:52:35] <alex_joni> cradek: you're using the right config.. right?
[01:52:49] <jepler> works with a recent package 2.1.0
[01:54:34] <cradek> installed -sim, running sim/keystick
[01:54:47] <alex_joni> and it's not running?
[01:55:01] <alex_joni> does it run from TRUNK ?
[01:55:18] <cradek> it flashes a window that immediately exits
[01:55:34] <cradek> and xemc is missing the big font somehow
[01:55:42] <cradek> Warning: Cannot convert string "-adobe-courier-bold-r-normal--64-*-*-*-*-*-*-1" to type FontStruct
[01:56:09] <alex_joni> cradek: I noticed that too..
[01:56:15] <alex_joni> changed the font to no avail
[01:56:18] <alex_joni> :(
[01:56:31] <alex_joni> cradek: try keystick from a terminal?
[01:56:40] <jepler> I was running from terminal
[01:57:18] <alex_joni> I ran it from the menu
[01:57:23] <cradek> + xterm -xrm 'XTerm*metaSendsEscape:false' -ls -e /usr/bin/keystick -ini /home/chris/emc2/configs/sim/keystick.ini
[01:57:29] <cradek> seems right...
[01:57:32] <cradek> must be something dumb
[01:58:25] <jepler> xterm is installed?
[01:58:36] <cradek> yeah, it does map a window briefly
[01:59:01] <jepler> add -hold?
[01:59:03] <jepler> to the xterm flags
[01:59:06] <jepler> maybe it prints an error
[01:59:27] <cradek> emc/usr_intf/keystick.cc 1388: emcStatus buffer not available
[01:59:35] <alex_joni> maybe /home/chris/emc2/configs/sim/keystick.ini ?
[01:59:42] <alex_joni> try /etc/emc2/...
[02:00:03] <alex_joni> you said you installed a sim..
[02:00:30] <cradek> alex_joni: I don't understand
[02:01:02] <alex_joni> sounds like you're running a config from ~/emc2/
[02:01:05] <alex_joni> not one of the sample configs
[02:01:08] <cradek> I tried both
[02:01:13] <alex_joni> oh, ok
[02:01:18] <cradek> that's just a copy of the new sample configs
[02:01:46] <cradek> sleep 2 before running keystick fixes it
[02:02:11] <jepler> oh YUCK
[02:02:19] <alex_joni> argh.. I hate those fixes :/
[02:02:21] <jepler> * jepler hides from the problem
[02:03:06] <cradek> I guess it starts (much) faster than everything else
[02:03:40] <alex_joni> doesn't it check a few times?
[02:03:54] <alex_joni> the emcStatus buffer should have been created by emcsvr
[02:04:01] <alex_joni> I think
[02:04:04] <alex_joni> been a while :(
[02:05:00] <jepler> yes but there's nothing to wait for emcsvr to be ready
[02:05:28] <alex_joni> waitusr ? </joke>
[02:06:23] <jepler> loadusr -W </not joke<
[02:06:34] <jepler> but we don't have time to change emcsvr to be a hal component today
[02:07:54] <alex_joni> loadusr -W doesn't load only hal components :)
[02:08:33] <jepler> -W needs a component that calls hal_ready()
[02:09:12] <alex_joni> loadusr -W halui
[02:09:20] <alex_joni> I think halui only says ready after it connected to emc
[02:10:11] <jepler> not sure, maybe
[02:10:57] <alex_joni> nope.. before :(
[02:11:07] <alex_joni> it wouldn't have been a real solution anyways :D
[02:11:31] <jepler> no
[02:20:13] <alex_joni> cradek: there is a thing called #DEBHELPER# which supposedly helps if put in one of the {post,pre}inst/rm files
[02:20:26] <alex_joni> according to that..
http://lists.debian.org/debian-mentors/2001/02/msg00372.html
[02:21:01] <alex_joni> tried it, doesn't do a thing
[02:21:56] <alex_joni> anyways.. I'm off to bed now
[02:22:12] <alex_joni> good night all
[02:37:01] <jmkasunich> cradek you're killin' me
[02:37:08] <jmkasunich> you commit one or two files every hour or so
[02:37:18] <jmkasunich> and the compile farm starts building again....
[02:37:24] <jmkasunich> I don't think its stopped all day
[02:37:39] <jmkasunich> ;-)
[03:48:02] <cradek> heh, sorry
[03:48:10] <cradek> at least I get them right on the first try!
[03:51:42] <cradek> there goes another one...
[04:02:38] <cradek> oh hell
[04:02:57] <cradek> sim/lathe won't run on trunk because of the nml change, and it won't run on the 2.1 branch because of a halcmd change (I think?)
[04:03:54] <cradek> need your help on this one jmkasunich
[04:12:06] <jmkasunich> whats up
[04:12:45] <cradek> the lathe hal files don't load since some of your changes: HAL: ERROR: signal 'spindle-index-en' already has output pin
[04:13:22] <jmkasunich> oh
[04:13:36] <jmkasunich> actually, you're the one I wanted to discuss that with
[04:13:43] <jmkasunich> lemme bring myself back up to speed
[04:13:47] <cradek> this is a goofy thing where an inverter is required. maybe we should fix it "right"
[04:13:52] <cradek> (whatever "right" is)
[04:14:10] <SWPadnos> hi guys
[04:14:15] <cradek> hi
[04:14:22] <SWPadnos> always some fallout from better error checking, huh? :)
[04:14:49] <jmkasunich> "corrected type of axis.N.index-enable from OUT to IO. (note: motion.spindle-sync should also probably be IO, but thats not just a docs change)"
[04:14:55] <jmkasunich> from a commit a few days ago
[04:14:56] <cradek> well, I'm learning a lot by trying to run each of the sample configurations.
[04:15:37] <cradek> so hooking two IO together with a not isn't really going to work
[04:15:47] <jmkasunich> in the spindle-sync code, you set your output true to tell the encoder to reset on index
[04:16:16] <jmkasunich> you never read the pin to see if it actually did, you just look for the value to drop, right?
[04:16:40] <cradek> yes, and that sucks
[04:16:50] <jmkasunich> if you make that pin IO, then you can read it if you want
[04:16:57] <jmkasunich> don't have to of course
[04:17:13] <cradek> this cat is driving me crazy
[04:17:18] <jmkasunich> what you do have to do is write a one to it again, when it drops, as long as you want the encoder to keep resetting
[04:17:22] <jmkasunich> mr. rhino?
[04:18:51] <cradek> no, this one sits between me and the screen and tries to eat the mouse pointer
[04:22:44] <jmkasunich> why the 'not' anyway?
[04:22:58] <cradek> when the spindle isn't synced, the encoder is resetting each time
[04:23:11] <cradek> it wouldn't have to, but right now it does
[04:23:10] <jmkasunich> the spindle-sync bit out of motmod is going to a canonical encoder's index-enable, make it do the right thing
[04:23:35] <cradek> yep that's my thinking too
[04:24:17] <cradek> wonder if there's a better name for the pin
[04:24:36] <jmkasunich> spindle-index-enable?
[04:25:19] <cradek> I am not happy about having to do this right before the release.
[04:26:14] <jmkasunich> should we revisit the new rules about what can link with what?
[04:26:43] <jmkasunich> (I'd rather not, I believe they are correct, and motmod is wrong)
[04:28:22] <cradek> no, I guess we should fix it right
[04:36:49] <cradek> so motion will only set it to 1, and the encoder only sets it back to 0, right?
[04:44:07] <jmkasunich> right
[04:44:14] <jmkasunich> (sorry, stepped away)
[04:44:19] <cradek> 'sokay
[04:46:33] <cradek> do you know about the shm blocks and semaphore arrays that are leftover?
[04:51:48] <jmkasunich> no
[04:52:18] <jmkasunich> are they just the nml related ones, or are hal ones left too?
[04:52:32] <cradek> I don't know how to tell the difference
[04:52:46] <jmkasunich> I probalby can tell the diff,
[04:52:52] <jmkasunich> but I dunno how to get into that state
[04:53:30] <jmkasunich> what do I do to create these leftover blocks?
[04:53:50] <cradek> put an error in a hal file and run
[04:55:25] <jmkasunich> nist lathe takes care of that...
[04:55:35] <jmkasunich> now how do I see them afterwards?
[04:55:38] <cradek> ipcs
[04:56:03] <jmkasunich> damn, should have done that first
[04:56:14] <cradek> oops, sorry
[04:56:14] <jmkasunich> so I could diff the before and after
[04:57:06] <jmkasunich> I have a huge load of those things
[04:57:18] <jmkasunich> are they used by other stuff besides EMC
[04:57:34] <cradek> yes I think so
[04:57:41] <jmkasunich> IOW, am I asking for trouble if I indiscriminately use ipcrm?
[04:57:44] <cradek> I think the ones with 777 are emc?
[04:58:24] <cradek> the keys are 0x3xx
[04:58:35] <cradek> well that's obscure
[04:58:43] <cradek> the keys are between 0x300 and 0x3ff
[04:58:54] <cradek> (I guess)
[05:00:25] <cradek> looks like they ARE cleaned up after a successful run
[05:00:50] <jmkasunich> strange, the ones that are allocated thru RTAPI don't show up
[05:01:01] <jmkasunich> (I'm running a config that does start properly
[05:01:31] <jmkasunich> jmkasunich@ke-main-1006:~/emcdev/emc2head$ cat /proc/rtapi/shmem
[05:01:31] <jmkasunich> **** RTAPI SHARED MEMORY ****
[05:01:31] <jmkasunich> ID Users Key Size
[05:01:31] <jmkasunich> RT/UL
[05:01:31] <jmkasunich> 01 10/3 1212238898 131000
[05:01:32] <jmkasunich> 02 1/1 111 1047664
[05:01:36] <jmkasunich> 03 1/0 319616006 64252
[05:01:53] <jmkasunich> those keys and sizes don't appear in ipcs
[05:02:42] <jmkasunich> the first one is hal shmem, the second is motmod<->task comms, and the third one is halscope
[05:03:27] <jmkasunich> obviously NML uses a completely different method to allocate shmem compared to rtapi
[05:03:46] <jmkasunich> and I don't know squat about how it works, or why it fails to release sometimes
[05:04:01] <SWPLinux> why do you say it uses a completely different method?
[05:04:18] <jmkasunich> because the rtapi ones don't appear in ipcs and the nml ones do
[05:04:24] <SWPLinux> ok, that would do it :)
[05:04:37] <jmkasunich> I think the nml ones maybe be user<->user shmem, the rtapi ones are user<->kernel
[05:04:58] <jmkasunich> user<->user<->kernel to be precise
[05:05:49] <jmkasunich> are you running sim?
[05:06:01] <jmkasunich> what does cat /proc/rtapi/* show for you?
[05:06:09] <jmkasunich> maybe nothing at all....
[05:06:18] <SWPLinux> if you sudo ipcs, you get more info ...
[05:06:31] <SWPLinux> it only lists shmem you have access to
[05:07:13] <SWPLinux> there's only one extra line for me as root, though this is on sim
[05:07:23] <SWPLinux> (so I have no /proc/rtapi ...)
[05:07:27] <jmkasunich> even with sudo, I don't see any that match up to rtapi shmems (size, or id)
[05:08:09] <jmkasunich> do any that are visible with ipcs on sim match in id or size with the ones I pasted a few mins ago?
[05:10:03] <jmkasunich> I wonder how jepler implemented rtapi_shmem_new for sim?
[05:10:50] <jmkasunich> irrelevant I guess. the real question is how NML does its shmems and sems
[05:11:17] <SWPLinux> src/emc/libnml/buffer ...
[05:11:33] <SWPLinux> shmem.cc
[05:12:06] <SWPLinux> oops. -emc there: src/libnml/buffer ...
[05:16:17] <jmkasunich> on a different topic - I have a manpage style question
[05:16:41] <jmkasunich> I'm doing a single manpage for freqgen and stepgen since they have so much in common
[05:17:05] <jmkasunich> for a normal man page, the pin list has the full name of the pin "mux2.N.in"
[05:17:29] <jmkasunich> in this case, I'd have to write "freqgen.N.counts" and "stepgen.N.counts"
[05:17:33] <jmkasunich> or just write "counts"
[05:17:39] <jmkasunich> which to you like better?
[05:18:31] <cradek> maybe you could write it for one of them like normal, and then put a note at the top that says how they are the same
[05:22:25] <SWPLinux> how large do you expect the file to be?
[05:22:34] <jmkasunich> the manpage?
[05:22:34] <SWPLinux> yep
[05:22:41] <jmkasunich> multiple screens, maybe 10 total
[05:22:52] <SWPLinux> so 20k or so?
[05:22:59] <jmkasunich> lots of words, the pin lists themselves won't be more than a couple screens
[05:23:31] <SWPLinux> well, at the risk of suggesting bloat, I'd do separate manpages
[05:23:59] <jmkasunich> eww
[05:23:59] <SWPLinux> they do different things, but have similar pinout options
[05:24:03] <jmkasunich> 90% or more is the same
[05:24:13] <cradek> http://pastebin.ca/323271
[05:24:24] <cradek> can you guys tell me if this is right?
[05:24:38] <cradek> I have to do the bidir handshaking by copying the values in and out of the stat buffer
[05:24:57] <jmkasunich> I
[05:25:06] <jmkasunich> I'm not sure what you are trying to do
[05:25:29] <jmkasunich> my understanding was that when not in sync (normal), you kept spindle-sync true so the encoder would keep resetting
[05:25:39] <jmkasunich> when in sync, you take it low so the encoder accumulates
[05:26:04] <cradek> now I'm trying to do it more like the encoder interface wants: only ask for a reset when starting a pass
[05:26:05] <SWPLinux> that code detects "edges" in the status buffer, and only updates the pin once per edge. is that what you wanted?
[05:26:40] <cradek> well the status buffer should drive the hal pin high, and the hal pin should drive the status buffer back low.
[05:26:40] <jmkasunich> actually, I see nothing wrong with repeated resets when not in sync
[05:26:47] <SWPLinux> err - nevermind. I need to read more :)
[05:27:18] <jmkasunich> the encoder interface doesn't "want" anything in particular, it will do what you tell it
[05:27:43] <jmkasunich> if you tell it to reset every rev when not threading, that keeps the spindle position from winding up to infinity
[05:30:09] <SWPLinux> argh. I've got to get to bed. good night guys
[05:30:24] <cradek> duh, I found my bug
[05:30:27] <cradek> goodnight swp
[05:30:48] <jmkasunich> goodnight SWPLinux
[05:53:15] <cradek> fixed, and the updating instructions added to
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?UpdatingConfigurationsForDevelopmentVersions
[05:53:28] <jmkasunich> cool
[05:54:12] <cradek> there are a few other lathe configs that need to be fixed, but they can wait until tomorrow, it's late
[05:54:46] <cradek> besides, the cats are circling for dinner
[07:05:16] <jmkasunich> I never realised how many little nagging differences there were between freqgen and stepgen
[07:05:30] <jmkasunich> differences that aren't justified
[07:05:46] <jmkasunich> (there are a few that are inherent in the nature of the two components)
[07:06:19] <jmkasunich> for 2.2, I think I want to pull the common code into a separate source file to get rid of the duplication, and harmonize the two components as much as possible
[07:06:30] <jmkasunich> for 2.1 I'm just gonna document them as they are
[11:11:45] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[17:03:08] <jepler> the '8255 driver is nowhere near ready. I don't think it's reasonable to make it a goal for 2.1.0.
[17:06:21] <alex_joni> jepler: what if you includeit anyways with limited functionality?
[17:07:44] <jepler> I'd rather finish it up and then talk everyone into letting it into a subsequent 2.1.x release.
[17:08:09] <jepler> a new driver can't break working systems, after all
[17:29:07] <cradek> jepler: I'm trying to figure out where to point PROGRAM_PREFIX in the sample inis. I think it has to point to /usr/share/emc/ncfiles, but after being copied to a home directory, that's no longer ideal because it's not a writable directory
[17:37:07] <jepler> cradek: everything but tkemc/keystick would understand "~/ncfiles"
[17:37:35] <jepler> er
[17:37:40] <jepler> everything but xemc/keystick
[17:37:56] <cradek> I wonder if we should create that directory (~/emc2/ncfiles) and change the ini when it copies
[17:38:30] <cradek> maybe even put something in it
[17:39:38] <rayh> That is what we did with BDI so that we'd always find the sample files in a known location.
[17:43:39] <jmkasunich> good morning
[17:44:40] <jepler> I'd rather not complicate the pickconfig right before release
[17:44:56] <rayh> Hi John
[17:45:01] <jmkasunich> hi ray
[17:46:50] <jmkasunich> I'd appreciate it if somebody could look over the stepgen/freqgen man page, see if I left anything important out
[17:47:03] <jepler> jmkasunich: I read it, though I didn't check for completeness.
[17:47:39] <jmkasunich> well, I know I didn't leave out any pins or params, I had the source open, as well as a halcmd show pins/params
[17:48:03] <alex_joni> hi guys
[17:48:07] <jmkasunich> more like "did I skip anything that is important to know"
[17:48:21] <jmkasunich> hi alex
[17:50:56] <rayh> How do I get emc's man pages to work directly from the man command?
[17:51:29] <jmkasunich> you mean for a RIP emc?
[17:51:40] <jmkasunich> man -M path-to-pages
[17:51:51] <jmkasunich> for example, if you are at the top level of your checkout
[17:51:55] <jmkasunich> man -M docs/man stepgen
[17:51:57] <rayh> right rip
[17:52:40] <rayh> okay thanks.
[17:54:40] <jepler> after ". scripts/emc-environment", "man stepgen" on its own will work
[17:54:47] <jmkasunich> :-P
[17:55:43] <jepler> $ . emc2/scripts/emc-environment
[17:55:43] <jepler> $ echo $MANPATH
[17:55:44] <jepler> /home/jepler/emc2/docs/man:...
[17:58:08] <rayh> ah that sounds good to me.
[18:04:15] <cradek> jepler: I share that feeling too, but I'm torn because it should probably point somewhere writable (and not distributed)
[18:05:33] <jmkasunich> talking about ncfiles?
[18:05:44] <cradek> yes
[18:05:47] <jmkasunich> that needs to be a single directory right? not a path?
[18:06:01] <jmkasunich> it would be nice if it could point to both ~/whatever and our samples
[18:06:11] <cradek> yeah, it can't do that
[18:07:37] <cradek> jepler: if I promise to test it extensively, would you do it?
[18:08:04] <cradek> (we have over a week to make sure it's right)
[18:08:11] <rayh> Would it be appropriate to add a "DeveloperTipsAndTricks" to the wiki.
[18:08:21] <cradek> rayh: definitely
[18:08:24] <rayh> k
[18:08:34] <cradek> it's almost always appropriate to add to the wiki :-)
[18:08:49] <alex_joni> it's appropiate to add almost anything to the wiki :-)
[18:08:50] <jmkasunich> unless its fud or misonformation
[18:19:13] <rayh> fud and misinformation is about all I've got these days.
[18:25:55] <jepler> cradek: so the program changes the line starting with "PROGRAM_PREFIX" to say ~/emc2/nc_files/, and creates ~/emc2/nc_files if it doesn't exist?
[18:28:26] <cradek> yes that's what I'd like, if you guys think it's good
[18:29:25] <rayh> I think that's a good plan. That would place those files right alongside any custom configs
[18:29:32] <jmkasunich> should that be "converts the lin starting with PROGRAM_PREFIX unless the user has already pointed it somewhere?"
[18:29:47] <cradek> jmkasunich: no, this is when the sample configs are copied
[18:29:54] <jmkasunich> oh, ok
[18:29:56] <cradek> (when you check that box on pickconfig)
[18:30:00] <alex_joni> jepler: maybe it should also copy the default files from /usr/...
[18:30:08] <jmkasunich> (I realized that was probably the case, right after I made that comment)
[18:30:09] <cradek> errr no, this is when you answer 'yes' to the dialog
[18:30:26] <cradek> alex_joni: my fear is then they will edit those, and their changes will get nuked
[18:30:40] <alex_joni> edit the ones in /usr/share/ ... ?
[18:30:46] <alex_joni> thought that's readonly for users
[18:31:00] <cradek> no, copy a sample config, then edit ~/emc2/nc_files/cds.ngc, then copy another sample config
[18:31:08] <alex_joni> I agree
[18:31:22] <alex_joni> but I meant along with the create folder if it doesn't already exist
[18:31:24] <cradek> ok let's leave it empty, just create it if it's not there
[18:31:41] <alex_joni> so only copy if the folder doesn't exist. create it and copy the samples
[18:31:48] <cradek> oh, hmm
[18:31:50] <alex_joni> if it exists do nothing
[18:31:56] <jmkasunich> can we do a "copy if destination doesn't exist" to get the samples into ~/ncfiles ?
[18:31:56] <alex_joni> even if it might be empty
[18:32:10] <alex_joni> jmkasunich: that's what I meant
[18:32:38] <cradek> what alex says is fine with me if you guys agree, I have to run for a bit
[18:32:47] <jmkasunich> run run run
[18:32:54] <alex_joni> the doors?
[18:33:11] <rayh> jepler: Is there a way to make the emc2/docs/man persist in the path searched by man?
[18:33:18] <alex_joni> cradek: is the change to include the Integrators manual on the menu ok?
[18:33:32] <alex_joni> rayh: only if you edit your bash_rc or the like
[18:34:16] <rayh> I was trying to find a .bash but didn't.
[18:34:45] <alex_joni> .bash_rc I think
[18:36:44] <rayh> perhaps a ubuntu install doesn't create these for each user.
[18:37:04] <alex_joni> sorry.. .bashrc
[18:37:09] <alex_joni> and it is there on my fresh dapper
[18:38:27] <rayh> nothing here.
[18:39:21] <alex_joni> ~/.bashrc
[18:39:27] <alex_joni> it's hidden starting with .
[18:39:30] <alex_joni> just start to edit it..
[18:44:48] <rayh> I don't see any hidden .bashrc. That is what I was looking for.
[18:45:05] <alex_joni> you may create it then
[18:46:00] <alex_joni> juve@taurus:~$ ls -al .bash*
[18:46:00] <alex_joni> -rw------- 1 juve juve 32080 2007-01-21 17:30 .bash_history
[18:46:00] <alex_joni> -rw-r--r-- 1 juve juve 220 2007-01-12 22:09 .bash_logout
[18:46:00] <alex_joni> -rw-r--r-- 1 juve juve 414 2007-01-12 22:09 .bash_profile
[18:46:00] <alex_joni> -rw-r--r-- 1 juve juve 2226 2007-01-21 20:45 .bashrc
[18:46:32] <rayh> wierd. ls -a says it's there
[18:47:18] <rayh> ah. the file browser lumps all .xx at the end.
[18:47:23] <rayh> dumb me.
[18:47:29] <jepler> cradek: test test test
[18:47:57] <alex_joni> jepler: I will now..
[18:50:24] <jmkasunich> I should really write man pages more often
[18:50:32] <jmkasunich> preferrabley before I write the code
[18:50:46] <jmkasunich> it helps to define what the component is supposed to do
[18:50:53] <alex_joni> I'll hold you up on that
[18:51:34] <awallin> since, pyvcp is now in 2.1, should I include the vcp documentation in the 2.1 integrator manual ?
[18:52:00] <alex_joni> I'd say so
[18:52:04] <jmkasunich> yes
[18:52:27] <jmkasunich> question: should we remove vcp (the C version) from 2.1?
[18:52:37] <jmkasunich> or at least mark it as deprecated?
[18:53:36] <awalli1> awalli1 is now known as awallin-VM
[18:54:38] <alex_joni> jmkasunich: there's a config with halui & halvcp
[18:54:51] <alex_joni> I'm not sure what to do about it
[18:55:04] <alex_joni> but it's the main config that shows halui
[18:55:11] <jmkasunich> ok, that answers that
[18:55:30] <jmkasunich> besides, I just remembered that there are few things that VCP can do that pyvcp doesn't do (yet)
[18:55:39] <jmkasunich> like let you put an LED inside a button, etc
[18:56:38] <jmkasunich> maybe for 2.2 we can convert every config over to use pyvcp, supply a script that can convert a .vcp file to a pyvcp .xml that does approximately the same thing, and remove vcp
[18:56:55] <jmkasunich> for now, I'd like to make vcp print a warning recommending that you use pyvcp
[18:57:15] <jmkasunich> so we don't have lots of people writing .vcp files during the 2.1 era
[18:57:48] <alex_joni> ok
[18:58:03] <alex_joni> and maybe get rid of those strange warning messages in halvcp
[18:58:53] <jmkasunich> ?
[18:59:06] <alex_joni> or did I take those out?
[18:59:18] <alex_joni> there were about 4-5 messages printed by halvcp on startup
[19:00:06] <alex_joni> I think I put #if 0's around them
[19:00:23] <jmkasunich> I had a lot of debugging messages in there
[19:00:38] <alex_joni> yeah .. those are #ifdef DEBUG'ed
[19:01:50] <cradek> jepler: testing, thank you
[19:02:04] <alex_joni> what is configs/stepper/sim_inch.ini ?
[19:02:38] <jepler> alex_joni: iirc it uses the PC speaker to output the step pulses
[19:02:56] <alex_joni> oh.. right
[19:04:43] <awallin-VM> jepler, now hal/vcp.lyx is included in the 2.1 integrator book, but I don't know anything about how the HTML is built, so could you include vcp.lyx in the HTML for 2.1?
[19:05:08] <cradek> when running demo_sim_cl I get an error that says Sequential: 0xb7bc4740 [OK]
[19:06:29] <jepler> awallin-VM: yes I'll look at it
[19:06:49] <jmkasunich> cradek: just noticed that all of your config cleanups are in 2.1
[19:06:59] <jmkasunich> are we going to copy them to trunk?
[19:07:04] <alex_joni> I ran demo_step_cl here, and got an error saying Sequential: d0fdb740
[19:07:11] <alex_joni> [OK]
[19:07:36] <cradek> jmkasunich: not the ncfiles change, since trunk is usually run rip
[19:07:43] <cradek> jmkasunich: the rest, possibly
[19:07:44] <alex_joni> cradek: it does run though
[19:07:48] <cradek> yeah it does run
[19:08:02] <alex_joni> rest = removing *PROBE* entries from the ini's
[19:08:11] <cradek> and turning off debug output
[19:08:27] <jepler> someone backport that arrays.c change if it fixes it in HEAD
[19:09:40] <cradek> it does
[19:09:43] <alex_joni> same here
[19:09:43] <cradek> I will
[19:10:02] <alex_joni> ULAPI: WARNING: module 'HAL_classicladder' failed to delete shmem 04
[19:10:05] <alex_joni> I get that on shitdown though
[19:10:19] <jepler> I don't think that's a 1-liner fix
[19:10:28] <alex_joni> err... shutdown *blush*
[19:11:37] <alex_joni> cradek: can you fix a file in CVS?
[19:11:41] <cradek> sure
[19:11:42] <cradek> http://pastebin.ca/323798
[19:11:50] <cradek> can anyone sopt the error here?
[19:11:52] <cradek> spot
[19:11:52] <alex_joni> emc2/configs/dallur-thc/README is executable
[19:12:41] <cradek> done
[19:12:54] <awallin> is there a log for emc-devel?
[19:13:03] <jepler> cradek: no, I don't see an error
[19:13:07] <jepler> logger_dev: bookmark
[19:13:07] <jepler> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2007-01-21.txt
[19:13:15] <alex_joni> cradek: same here.. don't see the error
[19:13:27] <alex_joni> unless the warning returned by mandb is treated as an error
[19:13:28] <cradek> strange, worked fine last night, I did it a dozen times
[19:13:29] <jepler> awallin: yes, though the logger bot isn't always up
[19:13:46] <alex_joni> jepler: we try to keep it afloat :)
[19:16:55] <awallin> jepler: I'm looking for tomp's pastebin message, he had a dial widget he wanted to include in pyvcp
[19:17:33] <cradek> http://pastebin.ca/322809
[19:18:13] <awallin> cradek: thanks, hopefully that is the latest version from tomp
[19:19:59] <alex_joni> is there a G50 ?
[19:20:34] <jmkasunich> was that the short lived code for enable (or maybe disable) adaptive feed?
[19:20:41] <jmkasunich> that is now an M code
[19:20:42] <alex_joni> yeah.. you're right
[19:20:44] <alex_joni> what's it now?
[19:20:46] <alex_joni> M50 ?
[19:20:50] <cradek> /* 500 */ -1,
[19:21:16] <alex_joni> M52
[19:21:25] <jmkasunich> alex_joni: not sure - we have M codes that let you enable/disable adaptive feed, feed override, spindle override, and feedhold, individually
[19:21:29] <alex_joni> M52 P1 to turn it on
[19:21:32] <cradek> echo $?
[19:21:33] <alex_joni> M52 P0 to turn it off..
[19:21:37] <cradek> argh
[19:21:43] <alex_joni> no echo in here
[19:21:59] <jmkasunich> in here.... here.... here.....
[19:25:26] <alex_joni> whoa.. emc is 4th place
[19:25:27] <alex_joni> http://cia.navi.cx/
[19:26:05] <cradek> Giving up on target file `../docs/src/hal/vcp.tex'.
[19:26:43] <awallin-VM> vcp.lyx !
[19:26:49] <jepler> uh oh did I botch that makefile backport?
[19:26:57] <alex_joni> the tex is created from the lyx
[19:26:58] <jepler> I didn't check that it was right, I just merged it from HEAD
[19:27:03] <alex_joni> in order to create the html
[19:27:21] <jmkasunich> and cradek is #1 ;-)
[19:27:24] <alex_joni> yeah
[19:27:26] <jepler> I get this when I run th emc2.1 doc build:make: *** No rule to make target `../docs/src/hal/pyvcp_mypanel.png', needed by `depends/Master_HAL.d'. Stop.
[19:27:43] <jepler> I'm guessing the doc backport was incomplete
[19:27:58] <jmkasunich> heh, if we're gonna be appearing on the cia top-20 list, we need a little icon
[19:28:46] <alex_joni> hmm.. I don't get that on 2.1
[19:28:47] <awallin-VM> jepler: ah, yes, sorry I didn't move over the images. will do that
[19:29:03] <jepler> I'll fix it
[19:29:12] <awallin-VM> ok...
[19:29:14] <jepler> I'm already halfway through
[19:29:25] <awallin-VM> thanks.
[19:29:45] <cradek> should we put the override override stuff in the gcode quickref?
[19:29:51] <jmkasunich> yes
[19:30:17] <cradek> more importantly, can any of us remember how it works?
[19:30:35] <jmkasunich> ..
[19:31:20] <alex_joni> I know M52 P1 / P0 is for adaptive on/off
[19:31:22] <jepler> m5x seem to be in the documentation
[19:31:27] <alex_joni> and it's described in the lyx
[19:31:39] <jepler> http://linuxcnc.org/docs/devel/html/gcode/main/index.html#sub:M48_-M49:-Override
[19:35:50] <cradek> my build is going farther now, thanks
[19:37:13] <cradek> what do you think about putting pyvcp in one of the sample configs? in TRUNK there's a spindle speed readout on sim/lathe
[19:37:30] <jmkasunich> go for it
[19:37:49] <alex_joni> yeah..
[19:38:25] <alex_joni> hmm.. here's a small problem
[19:38:36] <alex_joni> I have emc2 TRUNK in emc2/ and v2_1_branch in emc2.1/
[19:38:58] <awallin-VM> I remember back in the EMC1 days there was a utility that displayed the parport pins with LEDs, that could be done with pyvcp now
[19:38:59] <alex_joni> when I run emc2.1/scripts/emc I get the config picker to chose from ~/emc2/configs and /etc/emc2/sample-configs/
[19:39:23] <cradek> alex_joni: that's right - don't do that
[19:39:23] <alex_joni> no way to chose from emc2.1/configs/... , and I'm sure that was a previous behaviour
[19:39:33] <alex_joni> do what?
[19:39:39] <alex_joni> put TRUNK in emc2?
[19:39:45] <cradek> yes
[19:39:52] <cradek> and if you configure for installed, you don't get the source tree's configs
[19:39:52] <alex_joni> <mumble> ok
[19:39:58] <jmkasunich> I use emc2head for my development checkout of emc2 trunkj
[19:40:11] <alex_joni> and emc2trunk for head :D
[19:40:25] <jmkasunich> ;-P
[19:40:53] <alex_joni> cradek: building packages left it configured for installed
[19:41:42] <alex_joni> jepler: M48/49 were in the original docs I think
[19:41:48] <jmkasunich> jepler: M48 and M49 are "traditional" and should remain
[19:41:50] <alex_joni> in the rs274ngc
[19:41:55] <jepler> this is about the QUICK REFERENCE
[19:42:04] <jepler> m48/49 are still in the full documentation
[19:42:10] <alex_joni> ok then :)
[19:42:13] <jmkasunich> ok
[19:42:14] <jepler> that's not obvious from the file name
[19:42:15] <alex_joni> * alex_joni shuts up
[19:42:20] <jmkasunich> * jmkasunich shuts up
[19:42:20] <alex_joni> indeed
[19:42:31] <alex_joni> but it's html.. should have known better :)
[19:42:36] <alex_joni> full docs are .lyx
[19:44:43] <alex_joni> jepler: need a bit of your understanding here.
[19:44:52] <alex_joni> I'm trying to fix the hex config..
[19:44:59] <alex_joni> needs to loadrt genhexkins
[19:45:09] <alex_joni> but when I do that I get the following missing symbols:
[19:45:19] <alex_joni> [ 5387.279669] genhexkins: Unknown symbol pmCartCartSub
[19:45:19] <alex_joni> [ 5387.279731] genhexkins: Unknown symbol pmCartMag
[19:45:19] <alex_joni> [ 5387.279793] genhexkins: Unknown symbol pmCartCartAdd
[19:45:19] <alex_joni> [ 5387.279835] genhexkins: Unknown symbol pmMatCartMult
[19:45:19] <alex_joni> [ 5387.279877] genhexkins: Unknown symbol pmCartUnit
[19:45:24] <alex_joni> [ 5387.279938] genhexkins: Unknown symbol pmCartCartCross
[19:45:24] <alex_joni> [ 5387.279999] genhexkins: Unknown symbol pmRpyMatConvert
[19:45:30] <alex_joni> those all come from posemath.h I think
[19:46:56] <alex_joni> _posemath.c gets compiled / linked into motmod
[19:47:03] <alex_joni> but not into the genhexkins
[19:47:16] <alex_joni> figured it out...
[19:47:35] <cradek> mini and tkemc both have PROGRAM_PREFIX behaviors I don't understand
[19:47:45] <cradek> mini seems to ignore it and get it from somewhere else?
[19:47:56] <cradek> tkemc shows the symlink in there twice, once as a folder and once as a document (different icons)
[19:48:31] <jepler> alex_joni:
[19:48:31] <jepler> -genhexkins-objs := emc/kinematics/genhexkins.o
[19:48:31] <jepler> +genhexkins-objs := emc/kinematics/genhexkins.o libnml/posemath/_posemath.o
[19:48:36] <jepler> it means two copies of posemath, but BFD
[19:48:39] <alex_joni> and sincos..
[19:48:41] <jepler> cradek: how .. challenging
[19:48:49] <alex_joni> jepler: testing and commiting now
[19:48:58] <jepler> alex_joni: it worked with only posemath listed
[19:49:05] <alex_joni> not for me
[19:49:14] <jepler> must be a sim vs rt thing then
[19:49:15] <alex_joni> [ 5655.677687] genhexkins: Unknown symbol sincos
[19:49:40] <alex_joni> hahaha
[19:49:48] <alex_joni> tkemc with 6 axes on 1024x768 looks funny
[19:49:57] <alex_joni> there's no place for the bottom controls
[19:50:58] <jepler> cradek: I don't understand the tkemc symlink behavior -- they should both be using the same Tk file request dialog
[19:51:10] <cradek> set programDirectory $emc::NCFILES_DIR
[19:51:14] <cradek> ^^ mini
[19:51:26] <cradek> anyone mind if I fix it?
[19:51:46] <jmkasunich> ask rayh
[19:52:06] <alex_joni> http://dsplabs.cs.utt.ro/~juve/dropbox/tkemcfunny.png
[19:52:07] <cradek> he's here
[19:52:30] <cradek> alex_joni: hmm, something tells me you should pick a different font
[19:52:43] <alex_joni> something tells me I should move on :)
[19:53:03] <alex_joni> it's not a real problem
[19:53:15] <cradek> right
[19:53:17] <alex_joni> people with 6 axes can afford displays that do more than 1024x768 :D
[19:53:31] <alex_joni> mine does 1600x1200.. but I'm too lazy to change it
[19:53:36] <cradek> jepler: now mini shows the same behavior as tkemc
[19:54:00] <jepler> cradek: but they're all using the standard Tk file dialog!!
[19:54:44] <alex_joni> jmkasunich: I pity your compile farm :(
[19:55:05] <jmkasunich> you should
[19:55:15] <jmkasunich> my cpu load has been at 100% all day
[19:55:16] <cradek> you could turn it off since we're all constantly compiling
[19:55:20] <alex_joni> yeah..
[19:55:26] <jepler> cradek: axis does the same thing if you select "All Files (*)"
[19:55:32] <cradek> ahhh
[19:55:47] <jepler> cannot .. control .. rage
[19:55:51] <jepler> (at the ineptness of the tk people)
[19:56:01] <alex_joni> * alex_joni kichert
[19:58:42] <jepler> alex_joni: ?
[19:59:06] <elson> Hello, on this board.
[19:59:18] <jepler> good afternoon
[19:59:40] <awallin-VM> hi jon
[19:59:43] <elson> Chris, the change you wanted me to check re: aborts vs G92, is it ONLY in tkemc?
[19:59:50] <cradek> yes
[19:59:51] <elson> Hello, Anders!
[20:00:14] <elson> OK, and where do I find this version of tkemc?
[20:00:20] <alex_joni> TRUNK
[20:00:25] <cradek> in cvs, just update like normal
[20:00:30] <alex_joni> (or latest HEAD as we used to say)
[20:00:42] <elson> OK, it IS in the development head, then.
[20:01:23] <elson> I will test it first before updating, to make sure I have the sequence that makes it misbehave.
[20:01:52] <jmkasunich> we just recently learned that we were misusing the word head - head = the latest version of _any_ branch, so 2.0 has a head, 2.1 has a head, etc
[20:02:10] <jmkasunich> trunk is the main development "branch" (which has a head of its own)
[20:02:31] <elson> Another Q, is there a sample config that uses a jog encoder? How do you select which axis is jogged?
[20:02:45] <elson> Ohh, I'm getting a "head" ache!
[20:03:14] <jmkasunich> re: jogging - dunno about samples, doubt it
[20:03:24] <elson> So, which head is the revised tkemc in? I quess I can just browse the CVS.
[20:03:30] <cradek> I think 'max' has a jogwheel
[20:03:35] <jmkasunich> trunk head
[20:03:49] <cradek> but I haven't tried it lately
[20:03:57] <elson> Thanks, Chris - seems like I remember seeing it somewhere. I'd like to try it out.
[20:04:06] <cradek> elson: it works really great
[20:04:12] <jmkasunich> re: jogging - each axis has hal pins for the wheel counts (can send counts from one wheel to all axes, or use one wheel per axis, or any combo
[20:04:23] <jepler> cradek: I don't see it in the config
[20:04:24] <jmkasunich> each axis also has a pin to enable, and a scale factor
[20:04:31] <cradek> jepler: darn
[20:05:03] <jmkasunich> if you are using one wheel for all axes, then you probably only want to set one enable pin true at a time (unless you want to jog at 45 degrees ;-)
[20:05:21] <elson> OK, so there is no code as part of one of the GUIs that supports a jog wheel now. That is a bit of a complication.
[20:05:36] <jmkasunich> ?
[20:05:43] <jepler> if you're using AXIS, it provides a pin that reflects the last axis selected in the GUI
[20:05:46] <jmkasunich> gui's are only indirectly involved in jogsheels
[20:05:49] <jepler> but jog wheel is really not in the GUI
[20:05:51] <jmkasunich> jogwheels
[20:06:00] <alex_joni> I think AXIS has some hal pins which match the selected joint/axis
[20:06:05] <elson> Jeff, OK, that's what I was looking for, as a start.
[20:06:09] <jmkasunich> the wheel itself, and the enable pins, can be driven directly from hardware buttons, etc
[20:06:16] <cradek> better to have a rotary switch, but you can make do with AXIS
[20:06:28] <alex_joni> or halvcp/pyvcp
[20:06:32] <jmkasunich> _or_ you can use axis outputs that automatically make the wheel affect whichever axis is selected in the gui
[20:06:47] <alex_joni> jmkasunich: that's what he & jeff & me meant
[20:06:49] <awallin-VM> elson: my preliminary jogwheel setup is here
http://www.anderswallin.net/2006/11/jogging-emc2/ you can download the hal file and look at how I did it
[20:07:02] <jepler> awallin-VM: great!
[20:07:15] <elson> Yes, I understand the wheel -> axis is not through the GUI, what I'm wondering is how you select the wheel to jog a specific axis - or none.
[20:07:23] <jmkasunich> the enable pins
[20:07:35] <jmkasunich> imagine a rotary switch on the panel next to the wheel
[20:07:47] <jmkasunich> it enables one of the axis jog enable pins
[20:07:55] <jmkasunich> and when you turn the wheel, only that axis responds
[20:08:02] <jmkasunich> even though all axes are getting the counts
[20:08:48] <elson> John, I wanted to start with something REALLY simple at first, then for later, you are right.
[20:08:52] <alex_joni> that does mean that you need 3-4I/O's for the axes
[20:09:20] <jmkasunich> if you want to use a real rotary switch, yes
[20:09:27] <jmkasunich> you can also use pyvcp radiobuttons
[20:09:38] <jmkasunich> or the "selected axis" pins from axis
[20:10:27] <cradek> File "/usr/bin/axis", line 2820, in ?
[20:10:27] <cradek> import vcpparse
[20:10:27] <cradek> ImportError: No module named vcpparse
[20:10:38] <cradek> I don't think pyvcp is complete yet for installed
[20:10:57] <jepler> $(FILE) ../lib/python/*.py ../lib/python/*.so $(DESTDIR)$(SITEPY)
[20:11:02] <awallin-VM> is it in lib/python ?
[20:11:02] <jepler> it should be getting installed by this rule
[20:11:03] <elson> Thanks, Anders, it will take me a while to digest this, but that's what I was looking for!
[20:11:27] <cradek> ls: /usr/lib/python2.4/*vcp*: No such file or directory
[20:11:35] <jepler> oh -- not listed in emc2-files.in
[20:13:37] <cradek> jepler: I think the pickconfig change is right, I haven't been able to make it do anything strange
[20:14:03] <elson> Thanks, guys, and Chris, I'm going to test the tkemc fix now.
[20:14:08] <cradek> great
[20:14:23] <cradek> is someone working on the vcp install or should I?
[20:14:59] <jepler> I am
[20:15:04] <cradek> ok thanks
[20:15:35] <jmkasunich> * jmkasunich 's CPU cools down (stopped the compile farm VMs)
[20:15:44] <awallin-VM> in python, I get funny numbers when I have float's close to 0, instead of 0 I get 0.349834e-14
[20:15:59] <awallin-VM> is there a way to tell when you are really close to zero?
[20:16:25] <jepler> abs(x) < .001 ?
[20:16:51] <awallin-VM> btw how many bits are HAL_FLOATs ?
[20:16:57] <jepler> 24 bit mantissa
[20:17:31] <jepler> C "float"
[20:19:22] <awallin-VM> the dial output might be better as a Decimal
[20:21:08] <awallin-VM> hm. how did that work? a= decimal.Decimal ?
[20:24:53] <awallin> damn, VM seems to have locked up
[20:26:20] <jepler> cradek: with the last package I built, the sim/lathe's pyvcp panel worked
[20:26:26] <cradek> cool
[20:26:44] <cradek> you changed the sim/lathe config in cvs too?
[20:27:41] <jepler> sim/lathe had a panel for awhile on the TRUNK
[20:27:51] <jepler> I backported it as a way to test pyvcp worked
[20:27:58] <cradek> great
[20:29:50] <jmkasunich> is dithery a word?
[20:30:00] <jmkasunich> " dither-pwm has no effect if pwm-freq is zero (PDM mode),
[20:30:00] <jmkasunich> since PDM is an inherently "dithery" process.
[20:30:00] <jmkasunich> "
[20:30:53] <jepler> "dithered"?
[20:31:06] <jepler> "is inherently dithered"
[20:31:07] <jmkasunich> yeah, thats better
[20:32:42] <cradek> jepler:
[20:32:43] <cradek> File "/usr/bin/axis", line 2820, in ?
[20:32:43] <cradek> import vcpparse
[20:32:43] <cradek> ImportError: No module named vcpparse
[20:32:47] <cradek> I still get this
[20:32:54] <jepler> did you re-run debian/configure ?
[20:33:12] <cradek> * cradek blushes
[20:37:04] <jmkasunich> jepler: do new manpages in man.9 automagically get installed, or do they need to be individually added to the makefile somewhere?
[20:37:23] <jmkasunich> (also, do they get converted to html, etc)
[20:38:24] <elson> Chris, you definitely did change the behavior!
[20:38:33] <cradek> haha
[20:38:39] <jmkasunich> change ~= fix ?
[20:38:50] <jepler> jmkasunich: mostly they need to be added to emc2.files.in, which I'm doing now for stepgen/freqgen
[20:38:51] <jmkasunich> or != ?
[20:38:55] <jepler> I'll do pwmgen too
[20:39:01] <jmkasunich> ok
[20:39:06] <jmkasunich> encoder is next
[20:39:09] <jmkasunich> I'm very slow...
[20:39:24] <elson> But, not necessarily for the better. Now, it blitzes the offset when the abort happens, it doesn't wait for you to try to G92 an axis.
[20:39:52] <elson> After I hit the abort, relative and machine position read the same, and G92.3 does nothing.
[20:40:07] <cradek> it unapplies it, just like M2 does. you can get it back with g92.3
[20:40:20] <cradek> you can't get the offset back with g92.3?
[20:40:34] <elson> No, I can't. I tried it several times, after the abort, G92.3 has no effect.
[20:40:56] <cradek> are you running a config that's writable in your home directory?
[20:41:31] <elson> I believe so. There should be a .var file that updates every time EMC is shut down.
[20:41:46] <cradek> yes I'm wondering if your var file is writable
[20:41:58] <elson> I will check specifically, just a minute.
[20:42:49] <cradek> if I run tkemc, go to MDI, g92x.1y.2z.3 (offsets appear), hit escape (offsets disappear), g92.3 (offsets reappear)
[20:42:58] <jmkasunich> does this mean that anyone running a sample config will lose all functionality that depends on the var file being writable?
[20:43:07] <cradek> if they don't copy it, yes
[20:43:33] <cradek> it's been that way all through 2.0 too
[20:43:49] <cradek> the copy is now automatic, which makes it trivial to get right
[20:44:06] <cradek> jepler: sim/lathe with vcp works for me now, thanks
[20:44:24] <jepler> cradek: great
[20:45:13] <elson> Yes, the files seem to be writable. I see a ppmc.var and a ppmc.var.bak with time stamps of a couple minutes ago. I note that the parameters are ALL zero except for 5213 and 5220.
[20:45:20] <jmkasunich> I wonder if the main script should do "if [ ! -w <varfile> ] then change varfile to someplace in /var or /tmp "
[20:45:50] <cradek> elson: would you try the sequence I said above please
[20:46:07] <elson> Chris, I think you have to abort a running program for the behavior to be seen.
[20:46:20] <cradek> let me try that
[20:46:46] <cradek> a program ending in M2 right?
[20:47:17] <elson> Well, I didn't let it reach the M02, but yes, it is there.
[20:47:38] <alex_joni> it might still reach the M2, even if you stop it before..
[20:47:44] <alex_joni> the interp is quite fast, and has a lot of lookahead
[20:47:59] <elson> Right, interpreter lookahead, and it is a short program.
[20:48:07] <cradek> elson: it works for me, g92.3 puts the offsets back after abort
[20:48:27] <cradek> program is g1x1f1 / m2
[20:48:50] <elson> ARRRGH. I did not do a full update, just got the tkemc.tcl file. This was updated 2 weekends ago.
[20:49:47] <cradek> I think that one file is enough
[20:50:07] <elson> Maybe I should send you my cnc file?
[20:50:14] <cradek> sure
[20:52:05] <cradek> use pastebin.ca if it's short
[20:52:28] <elson> Umm, how do I do that, web browser?
[20:52:46] <cradek> yes
[20:53:06] <cradek> just paste it in the box, hit submit, give us the URL it assigns
[20:54:28] <elson> OK, here it is
http://pastebin.ca/323889
[20:56:06] <elson> It may make a difference whether the axes are homed or not. I had a strange thing happen after putting in the new tkemc.tcl - I got a message "move 7 out of range" when I tried to run it before homing the axes. It worked after I did a home.
[20:56:43] <cradek> abort/g92.3 works with your program
[20:56:57] <cradek> ok, let me try homing first, but that must be unrelated
[20:57:52] <cradek> move 7 out of range means line 7 of your program went past a soft limit
[20:58:02] <cradek> unhomed, it's hard to say where the soft limits are
[20:58:16] <elson> Great! That's wonderful news! How can there be soft limits before you home an axis?
[20:58:36] <elson> So, soft limits are supposed to be disabled until you home.
[20:58:53] <cradek> no, I think they're not
[20:59:31] <alex_joni> I tried the following: opened sim/tkemc, went to some arbitrary XYZ position, rightclicked each of the axes in tkemc, and entered 0 as the offset. I then opened the file from the pastebin, and ran it for a couple of lines and hit Esc. After that I could see Work offsets: 0,0,0. I switched to MDI and issued G92.3, and had the previous offsets restored
[20:59:53] <elson> This could make homing impossible, unless the homing procedure disables them.
[21:00:16] <cradek> I'm sure homing does ignore them
[21:00:21] <alex_joni> I think task checks for soft limits, homing doesn't
[21:00:34] <cradek> alex_joni: that's the (right) behavior I'm seeing with jon's program too
[21:01:06] <elson> Hmmmm, well that's not what I get here. It may require you to do a G92 of all the axes, run prog, abort, then try to G92 the Z. That was the problem before the change.
[21:01:29] <jmkasunich> re soft limits: the RT motion controller code applies them to commands (such as line, arc, or jog) as soon as they are recieved from task, they are not checked during a move, so they don't affect homing
[21:01:32] <alex_joni> elson: why not restore the offsets (g92.3) before the new G92 ?
[21:02:00] <cradek> yes if you want to change just Z, you will have to g92.3 first, otherwise XY are 0 (as it shows in the Work Offsets thing)
[21:02:38] <cradek> the fix mainly makes sure the Work Offsets display is correct after the abort - it was wrong before
[21:02:42] <elson> Well, maybe that is the way to do it, but that requires you to click over to MDI first. OK, well, if that is how it works, I'll have to do it, but it is cumbersome.
[21:03:29] <elson> So, is this a tkemc deficiency, or in emc itself? (sounds like tkemc.)
[21:03:32] <cradek> for what it's worth, I agree it's bad. however it might work reliably for you
[21:04:05] <alex_joni> I think it's less of a problem for AXIS which uses G54 not G92
[21:04:17] <cradek> seems like it's a combination of lots of things. it's hard to point the finger.
[21:04:21] <elson> I wonder if we could just put a G92.3 in there before setting any axis through the mouse right click?
[21:04:22] <alex_joni> but I think it's a combination of the abort, M2 and the state of emc2 which doesn't tell tkemc some parts
[21:04:31] <cradek> I think AXIS works much better for work offsets.
[21:04:46] <elson> Yeah, I HAVE to start learning to use Axis!
[21:05:12] <cradek> elson: that's a "pick your poison" deal. that will make the other numbers jump if you MEANT to be in g92.2 mode
[21:05:53] <elson> Yeah, without knowing what you are doing, assumptions can be problems.
[21:06:29] <cradek> have you tried using g54/g55 offsets instead of g92? I think that's what ray teaches (but I'm not sure)
[21:06:32] <elson> Maybe I will spend an hour or so working through this same drill with Axis, and get comfortable with it.
[21:06:58] <cradek> we have put in some (all?) of your suggestions at last fest. I think you'll have no problem using it.
[21:07:14] <elson> But the mouse right click does G92 (in tkemc). Maybe I should just hack it to G54 instead.
[21:08:40] <cradek> in AXIS when setting a work offset, you can type for instance .123/2 (any gcode expression), which is nice for a lathe, edgefinder, etc
[21:08:47] <elson> Well, I hate to just leave this time bomb in TkEmc if there's a simple fix. Many people have run into the same thing. But, if no easy fix, maybe it is not worth any further effort.
[21:09:05] <elson> That's cool, too!
[21:09:11] <cradek> I still don't understand why it's not working for you right now
[21:09:33] <alex_joni> cradek: if you don't go G92.3 before the new G92 then it's not working "right"
[21:10:03] <cradek> yes it is - it sets that work offset, leaving the other two alone (at 0)
[21:10:21] <elson> Yeah, I don't know what the difference is, either. But, it seems pretty reproducible, here.
[21:11:05] <elson> But, I don;t think the X and Y offsets were zero, before the abort.
[21:11:09] <cradek> maybe you are not sucessfully updated.
[21:11:38] <cradek> no they weren't, but all the g92 offsets are 0 after the abort, since it unapplies like g92.2
[21:11:45] <elson> Who knows? OK, maybe I need to do a real cvs update and recompile.
[21:11:50] <cradek> if you want them back you have to use g92.3
[21:12:51] <alex_joni> to summerize: M2 and abort reset the offsets (like G92.3)
[21:12:52] <elson> OK, so the deal is that if the offsets are cleared by the abort, and you then G92 ONE AXIS, it forgets the "preserved" offsets for the other axes. Is this right?
[21:13:20] <alex_joni> to continue using offsets you need G92.3 to restore them, only after that you can use G92 to alter one of them
[21:13:22] <cradek> yes I think it saves all three "new" ones, two of which are zero
[21:14:27] <elson> OK, so the behavior is explained. Well, I just have to remember this procedure when using tkemc. Thanks!
[21:14:53] <elson> OK, let me work with this, thanks!
[21:15:00] <cradek> welcome
[21:15:27] <alex_joni> yay, that means no additional delays
[21:15:52] <alex_joni> darn.. he left too soon
[21:16:51] <cradek> Suppose the current point is at X=4 in the currently specified coordinate system and the current X-axis offset is zero, then G92 x7 sets the X-axis offset to -3, sets parameter 5211 to -3, and causes the X-coordinate of the current point to be 7.
[21:17:31] <cradek> notice it does not say it affects parms 5212,5213
[21:17:46] <cradek> maybe this behavior IS buggy
[21:18:09] <alex_joni> * alex_joni tries to pay attention
[21:18:11] <cradek> g92.1 / g92x1 / g92.2 / g92y2 / g92.3
[21:18:32] <cradek> this currently gives 0,2 for offsets, but maybe it should give 1,2
[21:19:03] <alex_joni> maybe we should ask Kramer :)
[21:20:04] <cradek> fwiw
http://www.isd.mel.nist.gov/personnel/kramer/pubs/RS274NGC_3.web/RS274NGC_33a.html#1015878
[21:20:50] <alex_joni> "If an axis word is not used for a given axis, the coordinate on that axis of the current point is not changed."
[21:21:07] <cradek> true, but what about the saved parms
[21:21:16] <cradek> You can set axis offsets in one program and use the same offsets in another program. Program G92 in the first program. This will set parameters 5211 to 5216.
[21:21:36] <cradek> this seems to say any G92 sets all the parms, but I'm not sure it's meant that way
[21:22:12] <alex_joni> "If other programs are to run between the the program that sets the offsets and the one that restores them, make a copy of the parameter file written by the first program and use it as the parameter file for the second program."
[21:22:27] <cradek> oh god
[21:23:11] <alex_joni> guess newer G92's overwrite the old ones
[21:23:22] <alex_joni> might be a reason for the .var.bak files
[21:33:37] <alex_joni> cradek: one more thing to fix for the packages..
[21:33:51] <alex_joni> the HELP_FILE for xemc / tkemc
[21:35:00] <cradek> arg, again?
[21:35:09] <alex_joni> not sure.. was it working?
[21:36:22] <cradek> oh, off and on :-)
[21:36:28] <alex_joni> :-)
[21:36:38] <alex_joni> one time for RIP, one time for installed.. right?
[21:36:47] <cradek> probably
[21:37:54] <alex_joni> I tested most of the configs again, looks fine to me
[21:38:07] <alex_joni> even the ones that fail, report the proper things :)
[21:38:23] <cradek> great
[21:38:33] <cradek> "CVS is old, arcane, crufty and buggy, and sometimes exhibits non-deterministic behavior which some claim as proof that it is actually merely the Newtonian manifestation of a sentient transdimensional entity."
[21:38:51] <alex_joni> says the developer of bazaar?
[21:39:04] <cradek> no, says the freebsd folks who use cvs
[21:39:19] <alex_joni> http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/cvs.operations.html
[21:39:21] <alex_joni> found it
[21:41:05] <alex_joni> hmm.. do you still remember weekends when CVS was down on SF?
[21:41:44] <jepler> i remember the month that it was down
[21:42:56] <cradek> me too, remember it well
[21:44:46] <cradek> now it's always the same slow speed, which is just fine by me
[21:45:11] <jepler> it's usually quite fast for me!
[21:45:13] <jepler> whiners
[21:45:23] <cradek> haha
[21:45:53] <jepler> actually it seems slow today -- somebody else must be using that poor old laptop
[21:46:22] <alex_joni> it's quite OK for me
[21:46:50] <alex_joni> not the fastest, but I always prefer slow & steady over fast & buggy
[21:47:27] <cradek> yep
[22:06:26] <jmkasunich> I guess cradek is our repomeister
[22:15:13] <alex_joni> heh
[22:15:53] <alex_joni> it's odd..
[22:16:15] <alex_joni> every once in a while I think.. now emc2 is fairly ok, all is stable bugs are fixed, not much development will happen
[22:16:21] <alex_joni> then it starts all over again
[22:16:57] <jmkasunich> heh
[22:17:03] <alex_joni> thinking back, the 2.0.0 version was quite small compared to 2.1.0, and at the time it seemed like so much work :)
[22:17:27] <jmkasunich> this is certainly quite an effort these last couple of weeks
[22:19:10] <alex_joni> what was that other service running on cvs.linuxcnc.org ?
[22:19:27] <SWPadnos> webcvs?
[22:19:30] <SWPadnos> or cvsweb?
[22:19:39] <alex_joni> no.. some other tool which looks through the code
[22:19:44] <SWPadnos> lxr
[22:19:49] <alex_joni> yeah, that
[22:19:58] <jepler> cvs.linuxcnc.org/lxr ?
[22:20:02] <alex_joni> http://cvs.linuxcnc.org/lxr/source
[22:20:16] <alex_joni> wonder if anyone still uses that :)
[22:54:13] <jmkasunich> in hindsight, I wish I hadn't made the default "num_chan" for encoder be three
[22:54:56] <jmkasunich> that means that people didn't have to specify the number for the most common case, which means that we can't change the default without breaking those configs
[22:55:41] <SWPadnos> is 3 wrong in many cases?
[22:55:56] <SWPadnos> (or do you just get extras when you don't specify 1?)
[22:56:07] <jmkasunich> you get 3 unless you specify a number
[22:56:20] <jmkasunich> thats a domain specific default, not very generic at all
[22:56:26] <jmkasunich> (the domain being 3-axis machine tools)
[22:56:28] <SWPadnos> right - I'm wondering why (other than uniformity) 3 is a bad number ...
[22:56:31] <SWPadnos> right
[22:57:14] <jmkasunich> I'm somewhat obsessive about hal being generic
[22:57:19] <SWPadnos> at some point, there will need to be a relatively major change to the ini system. that would be a good time to make the change
[22:57:24] <jmkasunich> (as I'm sure you've already noticed)
[22:57:32] <SWPadnos> heh - me? no, I haven't noticed ;)
[22:58:38] <SWPadnos> heh - EMC is 4th in activity on cia.navi.cx - behind Gentoo, KDE, and Gnome :)
[22:58:49] <SWPadnos> (and above FreeBSD ...)
[22:58:58] <alex_joni> been that all day :)
[22:59:09] <jmkasunich> yep
[22:59:15] <SWPadnos> I noticed it in the top 15 yesterday as well
[22:59:32] <alex_joni> jmkasunich: 3 is a lucky number, used in most our traditional tales & stories
[22:59:38] <jmkasunich> cradek was #1 author for a little while
[23:00:02] <SWPadnos> heh - he and Alex are still up there
[23:00:16] <jmkasunich> hmm, every time the microwave cycles on, my UPS clicks and briefly runs on battery power
[23:00:28] <cradek> I wish we could all go out together for mexican food, like at fest, after this busy weekend
[23:00:32] <SWPadnos> rewired the house yet?
[23:00:44] <jmkasunich> cradek: that would be good
[23:00:55] <SWPadnos> I just had mexican today
[23:00:59] <cradek> we kicked butt getting things ready
[23:01:12] <jmkasunich> I still have a half-dozen man pages to do
[23:01:18] <cradek> we may even beat our goal of end-of-month
[23:01:20] <jmkasunich> but I think I'm getting faster
[23:01:29] <cradek> cool
[23:01:33] <alex_joni> I think I'm wearing down :)
[23:01:34] <SWPadnos> it was funny - sitting in a Mexican restaurant in Stowe, VT, and having a trio of young spanish-speakers sit next to us :)
[23:01:58] <SWPadnos> (and nobody in the restaurant understanding a word :) )
[23:02:00] <alex_joni> but you guys can come over for some mexican food :)
[23:02:13] <cradek> SWPadnos: that's funny
[23:04:26] <jmkasunich> that was a pretty good mexican restuarant (at least for being in the middle of Illinois)
[23:04:44] <SWPadnos> yeah - it was good, actually
[23:04:47] <cradek> yes it was good
[23:05:12] <cradek> I was surprised by that place and the nice hippie-food store whose name I forget
[23:05:26] <jmkasunich> I forget the name too
[23:05:31] <SWPadnos> right - the vegetarian diner/store (with all the teas)
[23:05:33] <jmkasunich> the one with the bakery attached
[23:05:49] <jmkasunich> (I don't do hippie food, but the bakings were tasty)
[23:05:54] <cradek> yep I would have been kind of lost without it
[23:06:32] <cradek> I'm ready for fest (and summer) now
[23:06:35] <jmkasunich> ditto
[23:06:52] <jmkasunich> actually, I'm glad we have some time - I want to get to FPGA work before the fest
[23:06:52] <cradek> I just moved a foot of snow one drivewaywidth to the south
[23:07:36] <cradek> (which doesn't sound that bad until I say my driveway is 2 or 3 drivewaylengths long)
[23:08:24] <cradek> jmkasunich: I noticed you promised that in public now...
[23:08:33] <jmkasunich> yeah
[23:08:55] <jmkasunich> notice that I said a "few" months
[23:09:01] <cradek> yes
[23:09:04] <jmkasunich> few is open to inerpretation
[23:09:23] <jmkasunich> interpretation even
[23:09:28] <cradek> a few months is less than a year, but other than that, you can fudge it
[23:09:28] <jmkasunich> interpolation?
[23:09:38] <jmkasunich> extrapolation?
[23:09:39] <cradek> inertification
[23:09:56] <alex_joni> a few months is less than half a year imo
[23:10:12] <jmkasunich> didn't ask you ;-P
[23:10:39] <jmkasunich> but to be honest, less than half a year is the target
[23:10:43] <jmkasunich> fest is the target
[23:10:45] <alex_joni> http://www.peters-cnc-ecke.de/forumupload/uploadFiles/11086_115674027908_SIMPEL1.JPG
[23:10:49] <alex_joni> can you see that?
[23:11:00] <cradek> yes
[23:11:03] <jmkasunich> yes
[23:11:19] <alex_joni> the user asks what values he needs to change for the puma kins to work :((
[23:11:30] <cradek> hahaha
[23:11:34] <jmkasunich> all of them
[23:11:57] <alex_joni> I wonder how I can say it nicely
[23:11:57] <cradek> the main value I'd have to change to get that to work is my IQ
[23:12:29] <cradek> alex_joni: you could try "sorry, I don't know"
[23:12:36] <alex_joni> cradek: don't think IQ is a problem with him..
[23:12:41] <alex_joni> he actually built that bot
[23:12:48] <cradek> cool
[23:12:52] <alex_joni> but math/coding might be a problem
[23:13:03] <cradek> yeah
[23:13:24] <alex_joni> http://www.peters-cnc-ecke.de/forumupload/uploadFiles/2982_115674027908_11086_115674027908_roboter123_000.jpg
[23:13:59] <jmkasunich> I smell dinner (chili)
[23:14:01] <jmkasunich> back later
[23:14:07] <cradek> alex_joni: neat!
[23:14:30] <SWPadnos> yeah - nice robot
[23:14:44] <alex_joni> cradek: care to write some kins for it?
[23:14:43] <alex_joni> :))
[23:15:00] <alex_joni> oh, I know.. SWPadnos: you could make some in LabView
[23:15:04] <cradek> you must be confusing me with someone else
[23:15:07] <SWPadnos> fcuk htat ;)
[23:19:10] <SWPadnos> one question on packages - I'm trying to get something simple for a stepper quick-start, and would like to do a servo one as well (at least for step-to-servo stuff), should I just add dummy files now so those can be in the install packages?
[23:19:38] <SWPadnos> I think they can be completed in the next week (depending on how much infor we try to get in there)
[23:21:04] <jepler> SWPadnos: how is step-to-servo different than stepper?
[23:21:07] <SWPadnos> encoders
[23:21:21] <SWPadnos> so you get the worst of both worlds :)
[23:21:36] <jepler> I didn't know the PC saw the encoders in those kinds of setups
[23:21:47] <SWPadnos> it can, if you want to monitor actual machine progress
[23:22:02] <SWPadnos> which is how it's done with the USC at least
[23:22:35] <cradek> contents aside, if you add dummy files, it would let us get the packaging right sooner
[23:22:49] <SWPadnos> ok. I'll add lyx files with titles at least :)
[23:23:02] <SWPadnos> where should they go?
[23:23:15] <cradek> is the target another pdf?
[23:23:31] <SWPadnos> err - dunno. that would probably make sense
[23:24:03] <cradek> with the rest of the docs then?
[23:24:08] <cradek> (not sure what you are asking exactly)
[23:24:26] <SWPadnos> heh - I'll look at the dir structure and ask a better question if I need to :)
[23:25:03] <cradek> docs/src/config, or a new docs/src/quickstart maybe
[23:25:58] <SWPadnos> hmmm. yeah - a separate quickstart dir may be a good thing. various others can be stuck in there (for other kins maybe, tuning, analog servos ...)
[23:27:05] <alex_joni> the kins docs are fairly short
[23:27:21] <alex_joni> servo info is missing from the integrators manual
[23:27:34] <SWPadnos> I guess I'm thinking about a couple of the common questions, like slaved axes and stuff
[23:27:36] <alex_joni> I think it would be great if you could add it..
[23:27:59] <SWPadnos> I'm doing the stepper thing first, hopefully I'll get it mostly right :)
[23:28:18] <alex_joni> oh.. I misremembered
[23:28:28] <alex_joni> I added some servo stuff, the theoretical PID tuning
[23:28:32] <alex_joni> but nothing for steppers
[23:29:11] <alex_joni> Tuning servo systems
[23:29:11] <alex_joni> \layout Standard
[23:29:11] <alex_joni> \begin_inset Include \include{motion/pid_theory.lyx}
[23:32:07] <alex_joni> good night all
[23:33:55] <cradek> goodnight alex
[23:34:00] <cradek> thanks for all the hard work this weekend
[23:34:03] <SWPadnos> see you Alex
[23:34:05] <cradek> and to everyone else
[23:34:24] <alex_joni> cradek: right back at you :)
