Back
[02:09:44] <cradek> jepler: "save gcode as..." gives me a traceback
[02:09:50] <cradek> File "/usr/bin/axis", line 2911, in save_gcode
[02:09:51] <cradek> except (shutil.error, os.error), detail:
[02:09:51] <cradek> AttributeError: 'module' object has no attribute 'error'
[02:11:04] <cradek> oh ... in an unwritable directory
[02:11:35] <jepler> probably should be (shutil.error, IOError)
[02:11:52] <jepler> good catch; I'll test and fix here
[02:12:21] <cradek> there's also a little debug output when it works
[02:12:55] <jepler> I see that
[02:13:13] <jepler> maybe whether it works or not?
[02:13:22] <cradek> yes
[02:16:58] <cradek> whee, optional stop and block delete work
[02:17:17] <cradek> testing is fun when stuff actually works
[02:18:44] <cradek> DTG units are right...
[02:21:00] <cradek> halshow doesn't work
[02:21:07] <cradek> Error in startup script: couldn't load file "/usr/share/emc/tcl/hal.so": /usr/share/emc/tcl/hal.so: cannot open shared object file: No such file or directory
[02:21:15] <jepler> probably missed by 'make install'?
[02:21:21] <cradek> that seems like a wrong path...?
[02:21:41] <jepler> yes the path seems fishy too
[02:21:50] <cradek> while executing
[02:21:52] <cradek> "load $::emc::TCL_DIR/hal.so"
[02:22:08] <jepler> tcl's hal.so isn't in 'make install' or the debian package
[02:22:33] <jepler> but in addition to that we need to discriminate between a 'lib' and a 'share' tcl dir, since it now has an arch-specific file in it
[02:24:54] <jepler> any idea why comp.1 and motion.1 are listed in .cvsignore? I think I added them, but that makes no sense
[02:24:59] <jepler> what was I thinking?
[02:25:43] <cradek> umm sorry, no idea
[02:26:20] <jmkasunich_> are they generated from something else?
[02:26:31] <jepler> jmkasunich_: no, I am pretty sure they're not
[02:27:44] <jepler> cradek: I'm working on fixing the hal.so problem as well
[02:28:05] <cradek> thank you
[02:28:07] <cradek> I'm continuing to test
[02:31:32] <cradek> shift-home (touch off to zero) fails with a traceback
[02:31:58] <cradek> 6,7,8 (u,v,w) are missing in the key reference
[02:34:16] <cradek> if I try to home with a shared switch closed, I get the error twice, but some things do move/home anyway
[02:34:26] <cradek> seems like it ought to not do anything
[02:34:35] <cradek> (I was using home all)
[02:39:31] <cradek> doubleclicking on the item to probe in halmeter does nothing
[02:46:03] <SWPadnos> hmmm
[02:46:10] <SWPadnos> I thought I had fixed that at Fest
[02:46:26] <SWPadnos> or maybe I was working on keyboard navigation only
[02:46:39] <cradek> the keyboard navigation sort-of works
[02:47:05] <cradek> I think I can select, but I can't see what I am typing because it doesn't scroll to that spot
[02:47:17] <SWPadnos> right
[02:48:05] <SWPadnos> I think the last I knew, we could have that bug, or some other focus-related one plus the ever-shrinking horizontal scrollbar-handle
[02:48:36] <SWPadnos> so I guess I chose to have only one bug, annoying though it is, until I (or someone) could figure out how to get rid of it
[02:55:24] <cradek> should I put this stuff in TODO?
[02:55:58] <SWPadnos> what - "stop using UI libraries with annoying bugs"? :)
[02:56:13] <jepler> I'm working on shift-home and uvw keyboard shortcuts now
[02:56:23] <cradek> ok thanks
[02:57:29] <cradek> SWPadnos: I also want keyboard search very much, but I think for now I'd trade the half-functional search for a doubleclick like halscope has (if that's what broke doubleclick)
[02:57:45] <SWPadnos> I don't think it is, thinking about it more
[02:58:09] <SWPadnos> I remembered that I was working on it at Fest, but didn't remember exxactly in what way
[02:58:36] <cradek> I have exactly the same (fuzzy) memory
[02:58:40] <SWPadnos> I'm pretty sure now (without looking at the logs) that I didn't change double-click behavior
[02:58:45] <SWPadnos> heh
[02:59:02] <cradek> maybe it has always not worked...
[02:59:12] <SWPadnos> that may be true
[02:59:21] <cradek> (too bad halmeter/halscope don't share those common bits)
[03:00:05] <fenn> what is double-click supposed to do?
[03:00:08] <SWPadnos> yeah. that was a bit too much to do at Fest (for me at least)
[03:00:22] <SWPadnos> you can single-click and hit ALT-A though - I made the accelerators work
[03:00:28] <fenn> select a signal in halmeter?
[03:00:29] <cradek> fenn: probably select that thing and exit the chooser
[03:00:31] <cradek> yeah
[03:00:47] <cradek> or, I'd be happy with 'apply' behavior instead
[03:00:59] <cradek> but it should do _something_
[03:01:21] <cradek> probably the "OK" behavior is the most stnadard
[03:01:31] <jepler> OK that's all I'll be fixing tonight
[03:01:38] <cradek> thank you!
[03:01:40] <jepler> see you folks around
[03:01:42] <cradek> goodnight
[03:01:49] <jepler> cradek: thanks for doing the unglamorous task of looking for the bugs
[03:01:51] <SWPadnos> you could probably add "double-clicked" to the list of events used
[03:01:54] <SWPadnos> night jepler
[03:06:06] <cradek> oh hey, turning on the brake actually turns off the spindle
[03:06:26] <cradek> that's a nice feature
[03:06:32] <fenn> clever
[03:06:35] <SWPadnos> indeed
[03:07:03] <fenn> but what if you're going around a curve and you want to shift into low gear quickly
[03:07:14] <cradek> uhh
[03:07:27] <cradek> then you ought to get back on your medication
[03:07:31] <SWPadnos> you brake before the curve, and accelerate out of the curve
[03:14:36] <SWPadnos> hmmm. it appears there's no specific double-click event for a GTK_CLIST
[03:14:57] <SWPadnos> so I think it would be a PITA to get double-click working
[03:15:15] <cradek> does halscope do something strange?
[03:15:24] <SWPadnos> could be
[03:15:27] <cradek> oh maybe it works on single click
[03:15:37] <cradek> (since there's only one operation)
[03:15:42] <fenn> it does single click
[03:15:42] <cradek> halmeter has ok vs apply
[03:15:49] <SWPadnos> halscope selects on the single click
[03:15:51] <SWPadnos> right
[03:15:58] <cradek> ok that's bogus too then
[03:16:13] <SWPadnos> halmeter actually updates the meter when you apply, whereas halscope does it after the dialog is dismissed
[03:16:25] <fenn> what's wrong with single-click for halmeter?
[03:16:27] <SWPadnos> halscope probably needs that since it has to tell the RT portion what to sample
[03:16:48] <cradek> fenn: ok vs apply
[03:16:49] <SWPadnos> the idea behind not dismissing the dialog immediately is that you might want to look at a few signals for a second
[03:16:58] <fenn> click on the item and it applies?
[03:17:02] <SWPadnos> so you click / apply on each one
[03:17:08] <SWPadnos> it doesn't at the moment, but that may be a good idea
[03:17:16] <SWPadnos> if you can live without "cancel"
[03:17:22] <fenn> could add a cancel too
[03:17:26] <fenn> and get rid of apply
[03:17:40] <SWPadnos> halmeter has cancel
[03:17:56] <SWPadnos> but you can't cancel if single-clicking applies and dismisses the dialog
[03:18:17] <fenn> i think the idea is so you can look at a bunch of things quickly without having to open the dialog each time
[03:18:26] <SWPadnos> it would be possible to apply if the selected row is clicked again
[03:18:32] <SWPadnos> right
[03:18:57] <fenn> why not just apply it the first time?
[03:19:21] <SWPadnos> because that eliminates the possibility of canceling
[03:19:33] <fenn> why does it?
[03:19:43] <fenn> apply doesnt close the dialog
[03:19:44] <SWPadnos> unless you start keeping track of what was being watched before the dialog was popped up
[03:19:57] <fenn> well, cancel doesnt do anything now anyway
[03:20:04] <SWPadnos> "apply" changes the name of the signal that the main meter window monitors
[03:20:26] <SWPadnos> sure it does. if you click on a new signal, then click cancel, it doesn't change the signal it's watching
[03:20:47] <fenn> cancel doesnt do anything
[03:20:53] <fenn> it just closes the select dialog
[03:21:00] <jmkasunich_> cancel was a way to dismiss the dialog without changing what you are viewing
[03:21:04] <SWPadnos> right
[03:21:30] <jmkasunich_> if you've clicked on a line in the list, I see nothing wrong with immediately switching the display to that item
[03:21:31] <SWPadnos> it allows you to not change what's being monitored. the way it does that is to do nothing, rather than changing the monitored item
[03:22:03] <SWPadnos> single-click select would certainly simplify that dialog - you'd only need a "close" button
[03:22:17] <jmkasunich_> cancel is for "oh crap, I didn't mean to open that dialog", not "oh crap, I didn't mean to open that dialog and I also didn't mean to click on an item in it"
[03:22:41] <jmkasunich_> yep
[03:22:51] <jmkasunich_> open the dialog, click, you have the new channel
[03:22:56] <jmkasunich_> click close to dismiss it
[03:23:11] <jmkasunich_> and for convenience, open the dialog, and double click on an item to select that item and dismiss the dialog
[03:23:34] <fenn> we cant figure out how to double-click (well, swp can't :))
[03:23:37] <SWPadnos> except there's no CLIST double-click event :(
[03:23:47] <SWPadnos> you can do it, it's just a PITA
[03:23:52] <jmkasunich_> oh well, forget the double click part
[03:24:02] <jmkasunich_> single click to select, with a close button
[03:24:18] <SWPadnos> you can probably access the parent class double-click event, or just apply if the selected row is clicked
[03:24:29] <SWPadnos> you need a timer for double-click
[03:25:01] <fenn> if (ev->type == GDK_2BUTTON_PRESS) looks like its supposed to work
[03:25:37] <SWPadnos> I guess that would be the parent (or grandparent ...) class double-click event ;)
[03:25:55] <fenn> you do that in the click handler
[03:26:39] <cradek> jmkasunich_:
http://pastebin.ca/753315
[03:26:57] <SWPadnos> there isn't a specific click handler in the seelction dialog code
[03:27:01] <SWPadnos> selection
[03:27:21] <cradek> jmkasunich_: if the XZ home switch is closed, UVW still home on 'home all'; is it a feature?
[03:27:34] <jmkasunich_> uhhh
[03:28:18] <SWPadnos> HOME_IS_SHARED isn't set (to 1 or 0) for axes 1, 4, 5
[03:28:27] <cradek> surely it defaults to 0
[03:28:39] <jmkasunich_> sequential homing was added by jeff, I haven't used it yet and would have to read docs to see what it is supposed to do
[03:28:46] <SWPadnos> it is set to 0 for 6,7,8, so I noticed :)
[03:29:27] <SWPadnos> I think it may be a feature
[03:29:46] <cradek> I think it's not obviously wrong, but it was surprising
[03:29:54] <cradek> I wish I knew what I did to get double errors though
[03:29:57] <SWPadnos> UVW are independent of the XZ switch, so XZ being homed has no effect on the UVW homing sewuence
[03:30:09] <SWPadnos> s/has no effect/should have no effect/
[03:30:32] <cradek> it seems likely the error message could be better
[03:30:52] <SWPadnos> oh - I didn't see an error
[03:30:54] <SWPadnos> message
[03:30:58] <cradek> "cannot home ..." while it's homing some stuff right behind that dialog looks wrong
[03:31:03] <SWPadnos> heh
[03:31:10] <cradek> "cannot home while shared home switch is closed [OK]"
[03:31:38] <SWPadnos> and then it proceeds on to YABC doesn't it?
[03:31:45] <cradek> not sure what it's doing
[03:31:53] <SWPadnos> or does it wait for the dialog to be dismissed?
[03:31:55] <cradek> sometimes I get 2 errors, but everything ends up homed anyway
[03:31:58] <cradek> no it doesn't wait
[03:32:02] <SWPadnos> ok
[03:32:30] <cradek> I'm starting to think we should have all or nothing
[03:33:41] <SWPadnos> OT silly question: is there a way (in bash) to negate the sense of an if, other than sticking the desired action in an else clause?
[03:33:41] <cradek> (fwiw, this config is axis_9axis in very recent trunk)
[03:33:50] <SWPadnos> (I didn't see a "not" command)
[03:34:00] <cradek> man test
[03:34:04] <SWPadnos> heh
[03:34:13] <cradek> (!)
[03:34:26] <cradek> you mean negate some test in [] ?
[03:34:41] <SWPadnos> this is so I can start realtime if it's not running, so I'm just looking at the "if $REALTIME > /dev/null" clause in halrun
[03:34:46] <SWPadnos> no, it's not a []
[03:34:48] <cradek> yes you're just supposed to know that [ is spelled "test"
[03:34:53] <SWPadnos> I did know that, acutally
[03:34:57] <SWPadnos> :)
[03:34:57] <cradek> :-)
[03:35:30] <cradek> oh, testing an exit code
[03:35:35] <SWPadnos> right
[03:35:43] <cradek> that's a bit harder, I don't know the answer
[03:35:50] <SWPadnos> ha!
[03:35:53] <SWPadnos> err - thanks :)
[03:36:11] <SWPadnos> maybe I'll just do the else thing for now
[03:36:13] <cradek> I prefer $REALTIME || otherwise
[03:36:29] <SWPadnos> hmmm. true
[03:36:30] <cradek> but that only works for a simple one-command 'otherwise'
[03:36:59] <SWPadnos> can you $REALTIME || do blah blah ; done
[03:37:36] <cradek> no
[03:37:42] <SWPadnos> bummer
[03:37:47] <cradek> $R || (a; b)
[03:37:53] <cradek> but that's getting stupid
[03:37:55] <SWPadnos> heh
[03:38:11] <cradek> chris@rover:~$ false || (echo hello; echo bye)
[03:38:11] <cradek> hello
[03:38:11] <cradek> bye
[03:38:10] <SWPadnos> it would be better to know how to do if !$REALTIME
[03:38:25] <SWPadnos> I guess test should do that though
[03:38:34] <cradek> chris@rover:~$ if ! false; then echo hi; fi
[03:38:34] <cradek> hi
[03:38:44] <cradek> when in doubt, try the obvious thing
[03:38:46] <SWPadnos> hmmm
[03:38:57] <SWPadnos> if only the bash man pages were easily searchable
[03:39:08] <SWPadnos> without finding 17000 extra bits
[03:39:11] <SWPadnos> thanks
[03:39:24] <cradek> yeah manpages get less useful as they get bigger
[03:40:09] <cradek> it says ! is a reserved word, for whatever that's worth
[03:40:38] <cradek> If the reserved word ! precedes a pipeline, the exit status of
[03:40:38] <cradek> that pipeline is the logical negation of the exit status
[03:40:46] <cradek> neat, I didn't know this
[03:40:59] <cradek> it works everywhere, it's not special `if' behavior
[03:41:12] <SWPadnos> hmmm
[03:41:21] <cradek> chris@rover:~$ ! false; echo $?
[03:41:20] <cradek> 0
[03:41:27] <SWPadnos> I get "bash: !": event not found
[03:41:35] <SWPadnos> I probably need to excape my strings better
[03:41:39] <SWPadnos> escape, too
[03:41:56] <cradek> put a space after the !
[03:42:10] <SWPadnos> I was trying to echo real! or unreal!
[03:42:14] <SWPadnos> with "" around them
[03:42:25] <SWPadnos> I probably needed a \ also
[03:43:00] <cradek> use single quotes if you don't want the shell to mess with anything
[03:43:26] <cradek> double quotes allow several kinds of expansion
[03:43:42] <SWPadnos> quoting rules could be a semester-long class, I think
[03:44:05] <SWPadnos> (if sub-shells and remote logins ... are part of it)
[03:44:17] <cradek> yeah no kidding
[03:44:38] <cradek> and don't forget ````m4''''
[03:44:52] <SWPadnos> I'm sorry, what was that? I forgot already
[03:45:11] <cradek> the first week would be getting all the whiners to use a font that lets them tell ` from '
[03:45:37] <SWPadnos> I don't even know how to type the upside-down quotes
[03:46:13] <cradek> hey look at the time
[03:46:23] <cradek> I have to go to work tomorrow and relax. I better rest up.
[03:46:24] <SWPadnos> damn
[03:46:45] <jmkasunich_> yeah, damn
[03:46:53] <jmkasunich_> I have to leave for the airport at 6am
[03:47:13] <cradek> jmkasunich_: the HGR guy called back and quoted me $250 shipping! haha
[03:47:35] <jmkasunich_> why didn't he just say "f__k you" while he was at it?
[03:47:48] <cradek> good question
[03:48:09] <cradek> he could at least buy me dinner first
[03:48:16] <SWPadnos> he was probably pissed off about the red sox
[03:48:25] <cradek> so, I'll look around some more :-)
[03:48:34] <cradek> not like there's any rush
[03:48:59] <cradek> I just would like to be rid of the noisemaker someday
[03:49:14] <jmkasunich_> rotary phase converter?
[03:49:19] <cradek> yeah
[03:49:45] <jmkasunich_> what kind of transformer(s) are in the machine now?
[03:50:00] <jmkasunich_> maybe some creative rewiring can be done to make it work on single phase?
[03:50:19] <cradek> the main one (DC bus) is a 3 phase deal, then there are a half dozen other single phase
[03:50:40] <cradek> so it will take one new transfomer AND creative rewiring
[03:51:11] <cradek> all the others are small 115v or 24v out, 240 single phase in
[03:51:39] <jmkasunich_> those are a piece of cake
[03:51:42] <cradek> I've already shuffled some around so all the electronics are on the good phase
[03:51:49] <cradek> yeah, trivial
[03:51:59] <cradek> but that main one needs to be replaced, and it's big
[03:52:12] <jmkasunich_> three core legs, and windings on all three?
[03:52:15] <cradek> yes
[03:52:29] <cradek> 6 diodes and some caps
[03:53:49] <jmkasunich_> you'll likely need more caps - a 3 phase bridge has much less ripple current than single phase
[03:54:08] <cradek> yeah I had figured on that too
[03:54:23] <fenn> why do you need such a huge transformer?
[03:54:32] <cradek> if they're original (probably) it wouldn't hurt to replace them anyway
[03:54:47] <jmkasunich_> I'm wondering if there isn't a way to use two legs of the three phase transformer on single phase
[03:55:02] <cradek> jmkasunich_: not enough iron is there?
[03:55:27] <jmkasunich_> gotta think about that a bit
[03:55:34] <fenn> there are toroidal transformers of all sizes on ebay, reasonably priced i think
[03:55:42] <cradek> fenn: the books say it wants about 3kva
[03:55:50] <jmkasunich_> if reasonable is $150/kva
[03:55:57] <cradek> toroids only seem to go up to 1kva unless there's a style I haven't seen
[03:56:19] <jmkasunich_> the transformer at HGR is only $40 for 3KVA
[03:56:19] <SWPadnos> I think mine is 2 kVA
[03:56:25] <fenn> oh, well that makes a bit of difference
[03:57:11] <cradek> the boss control won't ever rapid all 3 axes together - it may even be a bit underpowered
[03:57:24] <jmkasunich_> bah
[03:57:48] <cradek> :-)
[03:57:51] <jmkasunich_> there are two issues, droop and transformer heating
[03:58:08] <jmkasunich_> the latter is a non-issue, unless you are gonna write a program that does nothing but three axis rapids all day
[03:58:50] <jmkasunich_> for the former, I'd be astonished if an industrial transformer (like the HGR one) droops by more than 10% under rated load
[04:07:20] <cradek> ok
[04:08:20] <cradek> I won't worry so much. I bet it could get down pretty low without faulting anyway.
[04:10:35] <cradek> goodnight now...
[04:11:40] <jmkasunich_> goodnight everybody
[04:12:23] <SWPadnos> night
[10:38:39] <tissf_> tissf_ is now known as tissf
[12:14:04] <jepler> tissf: you should go ahead and "cvs commit" the axis_fr.lyx file with the improvement to the index.
[12:21:55] <tissf> Yes I will try, but I had to restore my machine and I lost my. ssh: (
[12:24:00] <tissf> the accent problem is resolved
[12:27:20] <tissf> All works well except that the compiler asks a xref.html
[12:49:50] <alex_joni> tissf: re: ssh, if you don't have the private key anymore, you need to generate a new keypair, and send the public key to cradek
[12:50:26] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?DeveloperAccess
[12:57:42] <jepler> tissf: I can also get the 'xref.html' error now; I'll fix it
[12:58:13] <tissf> ah ok :)
[12:59:02] <tissf> before commit, I will await a little to know if I organize the translation under gutsy or under dapper
[12:59:32] <jepler> I think it would be best to work on dapper. otherwise you have to go through the extra "lyx2lyx" step before each commit.
[13:01:38] <tissf> yes but on this PC I have just feisty and gutsy, I must remake a partition for dapper
[13:02:50] <tissf> The PC with dapper is at the workshop and it does too cold:)
[13:05:49] <tissf> jepler It is impossible to have lyx2lyx -- à 221 automatic one with the compilation?
[13:30:22] <Guest998> Guest998 is now known as skunkworks_
[13:47:04] <jepler> tissf: no, because on ubuntu dapper, lyx2lyx can't read the newer files
[13:47:22] <jepler> it has to be done on the system where the newer version of lyx is installed, not where the older version is installed
[13:47:28] <jepler> bbl
[13:54:50] <tissf> ah ok thanks
[13:56:37] <tissf> I will install dapper on a disc usb that I easily will be able to transport
[13:58:02] <tissf> I sent my ssh to Chris by mail
[14:02:27] <cradek> tissf: done
[14:35:00] <tissf> cradek: thanks
[17:26:11] <tissf> I have again the following probleme
[17:26:12] <tissf> unable to parse objects/xref.xml
[17:26:14] <tissf> make: *** [../docs/html/xref.html] Erreur 6
[17:35:36] <alex_joni> tissf: did you cvs up?
[17:35:48] <tissf> can you tell me how you fix ?
[17:35:50] <tissf> jepler>tissf: I can also get the 'xref.html' error now; I'll fix it
[17:36:44] <tissf> no at this time cvs lgin dont work ... I have to read the doc before !!!
[17:37:28] <tissf> or can you please tell me the syntax for commit ?
[17:39:06] <alex_joni> I think I saw a commit message from jepler fixing the xref problem
[17:39:25] <alex_joni> so you need to do 'cvs up -dP' in your dir to get the latest changes
[17:39:41] <alex_joni> if you want to commit something the syntax is : cvs commit -m "message"
[17:39:58] <tissf> ok for cvs update no problem but for commit ?
[17:40:28] <alex_joni> in order to commit you need to have checked out the sources with your username
[17:40:36] <alex_joni> cvs co -d:ext:tissf:...
[17:40:43] <alex_joni> not :ext:anon
[17:40:58] <tissf> ah thanks
[17:41:01] <alex_joni> if you are working on an anon-checked out repository you won't be able to commit, as it's readonly
[17:41:18] <alex_joni> so the best would be to check out the sources again (with your username), and move the changes over, then commit
[17:41:27] <alex_joni> (test, then commit :)
[17:42:05] <tissf> ah ok ok thank you !)
[17:42:10] <alex_joni> no problem :)
[17:47:23] <tissf> I probably did not use cvs commit for 15 years!
[17:55:47] <alex_joni> well.. I only started using it 2-3 years ago :)
[17:57:59] <tissf> Problem,
[17:58:01] <tissf> cvs [checkout aborted]: must specify at least one module or directory
[17:59:25] <alex_joni> cvs co -d:ext:tissf@cvs.linuxcnc.org/cvs co -d emc2.TRUNK emc2
[17:59:28] <tissf> It is necessary to indicate the branch?
[17:59:37] <tissf> ok
[17:59:47] <alex_joni> (-d emc2.TRUNK means it will create a directory called emc2.TRUNK)
[18:00:13] <alex_joni> I usually create more than one dir (emc2.0, emc2.1, emc2.TRUNK, etc)
[18:01:58] <tissf> cvs checkout: No CVSROOT specified! Please use the `-d' option
[18:02:59] <alex_joni> can you tell me the command you tried?
[18:03:10] <alex_joni> maybe try : export CVS_RSH=ssh;
[18:03:12] <jepler> and in what directory
[18:03:13] <tissf> cvs co -d:ext:tissf@cvs.linuxcnc.org/cvs co -d emc2.TRUNK emc2
[18:03:22] <jepler> "-d:ext..." must go before "co"
[18:03:34] <alex_joni> oops.. my bad
[18:03:37] <tissf> in ~/
[18:03:40] <jepler> cvs -d .. co -d emc2.TRUNK emc2
[18:03:46] <jepler> confusingly, the two -d mean different things
[18:06:05] <tissf> that load :)
[18:09:14] <tissf> After loadin I place my files translate and I commit?
[18:10:01] <alex_joni> you need to 'cvs add' if the file didn't exist
[18:10:21] <alex_joni> then 'cvs commit' to finalize the commit
[18:26:03] <tissf> Ok, fr_axis.po commited, now for cvs add I have to add the path ?
[18:36:37] <alex_joni> no, you go to the path where the file will be
[18:36:39] <alex_joni> and cvs add filename
[18:36:51] <alex_joni> (you need to create/copy the file first)
[18:43:23] <tissf> fine
[18:43:35] <tissf> Thank for the help
[18:43:47] <alex_joni> tissf: no problem
[18:52:35] <tissf> can you tell me if *_fr.lyx compile under dapper ?
[18:52:49] <alex_joni> hang on
[18:53:52] <tissf> hang on ?
[18:53:58] <alex_joni> wait a moment :)
[18:54:13] <tissf> :)
[18:55:20] <tissf> Time to eat here, soon
[18:56:58] <alex_joni> (I have some packages missing on this machine.. dvipng for now)
[19:10:02] <jepler> there's at least one problem, but it's one I need to fix: UnicodeEncodeError: 'ascii' codec can't encode character u'\xf4' in position 3857: ordinal not in range(128)
[19:10:16] <jepler> I think it's because there are non-ascii characters in an index entry, and I'm not handling that properly
[19:10:34] <jepler> after that fix, the html documentation builds .. let me see if it looks OK
[19:11:08] <jepler> yes looks good including the index
[19:11:57] <jepler> I can't check the PDF documentation right now, however
[19:13:29] <alex_joni> jepler: did you commit the fix?
[19:14:35] <alex_joni> (nm.. seen the P ..)
[19:15:27] <alex_joni> tissf: the pdf seems ok over here
[19:28:29] <jepler> alex_joni: yes, I did - <cia> must be lazy today
[19:30:53] <alex_joni> yup
[20:00:56] <tissf> alex_joni: fine
[20:01:27] <alex_joni> hi rayh
[20:02:06] <rayh> HI alex
[20:03:37] <rayh> How you doing?
[20:03:59] <cradek> jepler: a few things on this page
http://www.linuxcnc.org/docs/devel/html/gui_axis.html are incorrectly center justified
[20:04:04] <cradek> hi ray
[20:05:05] <rayh> Hi Chris.
[20:05:51] <jepler> cradek: yeah I noticed that too
[20:05:56] <jepler> I probably don't know HTML well enough
[20:06:12] <jepler> it's because I want the figure itself centered, but that's spilled over to center the text inside the figure as well
[20:06:15] <jepler> (I think)
[20:12:42] <cradek> every word of our documentation should be read by one of us ... but man what a task
[20:13:01] <cradek> maybe we could find a way to split it up.
[20:13:21] <cradek> whenever I start, I get through ten pages and then quit
[20:23:16] <alex_joni> well.. I think I read it twice so far
[20:23:24] <alex_joni> but then again, that doesn't mean much :)
[20:24:06] <alex_joni> rayh: pretty good, a bit busy
[20:31:30] <rayh> I can see that.
[20:32:13] <rayh> alex_joni, Roland was wondering if you were going to make it to the cnc workshop this year?
[20:32:21] <alex_joni> yeah, I was wondering too :D
[20:32:29] <rayh> June 16-21 is the date.
[20:32:35] <alex_joni> ok, that's good to know
[20:32:49] <alex_joni> * alex_joni puts it on the TODO list
[20:33:00] <cradek> you better come
[20:33:41] <rayh> We planning for another EMC get together there?
[20:34:43] <skunkworks_> * skunkworks_ hopes so..
[20:34:53] <cradek> it's always hard for me to see so far in the future, but I'll probably be there if anyone else is
[20:36:18] <jepler> I sure look forward to spending a couple days with you guys
[20:36:33] <cradek> rayh: do you think you would be able to come this time?
[20:41:27] <rayh> I sure hope so.
[20:41:46] <rayh> Doing pretty well these days.
[20:41:58] <skunkworks_> Good to hear. :)
[20:42:44] <rayh> Roland wants me to take a couple days and work with him on the Mazak before the new year.
[20:43:21] <rayh> I'll need to find out where we left it after the last workshop.
[20:47:44] <rayh> My ISP has had a real problem with email for the last three days.
[20:48:42] <SWPadnos> I think we were contemplating putting the head lifter under EMC control
[20:53:22] <rayh> Ah.
[20:53:38] <rayh> Were you thinking of using the stop switches or what?
[20:54:05] <SWPadnos> dunno, actually ;)
[20:54:37] <SWPadnos> I think jmk had a couple of things he wanted to do, but I don't recall what they are
[20:58:33] <cradek> I think there are contactors already in place and working that move the head - but they're not hooked to that knob on the front panel
[20:58:45] <jepler> one thing I know he wanted, but which we didn't do, was make the "tool prepare" happen before the "tool load", rather than having both happen when the tool finally could be loaded
[20:58:54] <cradek> not sure what emc should do with the head actually
[20:59:47] <jepler> (iocontrol needs some fairly extensive modifications for this to work right in a number of strange circumstances, so I put it off)
[20:59:58] <cradek> rayh: the only trick to the tool changer is to unload the tool before exiting emc (T0 M6). it works great then (puts the tools back where it got them)
[21:00:21] <jepler> oh yeah that's a bit of an annoyance
[21:00:48] <jepler> one night I think chris, steve, and john spent an hour trying to recover from a mistake where emc's idea of the tool-in-spindle didn't match reality
[21:00:58] <cradek> I wish it had a sensor there, but it doesn't
[21:01:06] <cradek> not sure what else we can do without a sensor
[21:01:25] <rayh> Okay.
[21:01:56] <cradek> rayh: you might want to take some american ER40 collets with you when you go... (at least I think they're ER40)
[21:02:16] <cradek> we had virtually no tooling that worked
[21:02:23] <rayh> I think that Roland has some now.
[21:02:30] <cradek> ok good
[21:02:35] <jepler> maybe a procedure needs to be devised and written down, or maybe something can be done on the vcp to make the needed operations easy
[21:02:35] <rayh> I'll confirm that
[21:02:49] <jepler> (for fixing up after a tool change problem or mistake)
[21:03:21] <rayh> EMC was waking up thinking tool 0 was in the spindle?
[21:03:31] <cradek> jepler: I think the procedure is yank out whatever is in pocket 0
[21:03:40] <rayh> Where would the "sensor" be.
[21:03:44] <jepler> yes, emc always assumes no tool is in the spindle at start -- that's the same as "tool zero"
[21:03:51] <cradek> yes when EMC starts it thinks "tool 0" is in the spindle
[21:04:09] <cradek> then to load something real, it "puts tool 0 away" into pocket 0 which must be empty
[21:06:23] <rayh> Most of the control's that I've worked with did have a vcp like manual tool operations page.
[21:07:21] <rayh> I can see how it would be good to be able to change pocket number and such.
[21:07:40] <rayh> as well as manually rotate the change arm and intermediate arm.
[21:07:55] <SWPadnos> hmmm. I thought we did get tool-prep working before load
[21:07:58] <cradek> SWPadnos: nope
[21:08:37] <SWPadnos> maybe I'm thinking of prepping the "previous tool" pocket while the change is taking place
[21:09:10] <cradek> yeah that works
[21:09:26] <cradek> it all works right, except some prep work could be done ahead of time, and it isn't
[21:09:34] <rayh> Were you able to get it to rotate the carousel to the next tool?
[21:09:44] <SWPadnos> oh sure, toolchanges work fine
[21:09:52] <cradek> rayh: yes Tx M6 does load tool x and put the previous tool away in the right place
[21:09:55] <SWPadnos> they may not be time optimized though
[21:10:06] <rayh> Ah.
[21:10:48] <SWPadnos> the video on linuxcnc.org (and youtube, I think) shows a full drill, countersink, and rigid tap cycle, including tool changes
[21:11:06] <rayh> If I remember, the tool prepare NML is issued as soon as the last tool change has completed.
[21:11:12] <cradek> yeah and you can laugh at our tooling too!
[21:11:14] <rayh> last/previous
[21:11:24] <rayh> I saw that video.
[21:11:37] <rayh> I also saw the tapped material.
[21:11:43] <SWPadnos> heh - so you did :)
[21:11:57] <rayh> thanks SWP
[21:12:13] <SWPadnos> oh right - I think I played it for you on the camera
[21:12:21] <cradek> did you get plastic or aluminum? I forget
[21:12:22] <rayh> yep
[21:12:28] <SWPadnos> metal
[21:12:31] <cradek> neat
[21:12:38] <SWPadnos> I think I have the tapped piece though
[21:12:58] <cradek> I have the first aluminum block with one tapped hole in the center :-)
[21:13:20] <cradek> (I have a few EMC trophies...)
[21:13:27] <rayh> Perhaps we should send that to the Smithsonian!
[21:13:33] <cradek> haha
[21:13:41] <cradek> I'm sure they get many stranger things.
[21:14:00] <rayh> I just imagine.
[21:15:10] <cradek> interesting - looks like we had 2 collet chucks
[21:15:15] <cradek> (I'm watching the video)
[21:15:35] <rayh> lucky guy. That would take a week of download here.
[21:16:07] <cradek> and I can't tell what that jacobs chuck is held in...
[21:16:17] <cradek> it sure is long though
[21:16:26] <rayh> I'm seeing only one update to the demo_mazak config from that date.
[21:17:02] <rayh> I wonder if the final config was in the machine only?
[21:17:13] <cradek> http://cvs.linuxcnc.org/cvs/emc2/configs/demo_mazak/demo_mazak.clp?graph=1
[21:17:43] <cradek> the 2007-06-16 must be the latest
[21:18:04] <cradek> I'm positive we would have checked in the final config.
[21:19:32] <rayh> I'll try a cvs up here and see what I get.
[21:20:00] <cradek> +# Yes really, this .0024 backlash is right, workshop 2007
[21:20:44] <SWPadnos> a little bit of a non-sequitur: does anyone know if EMC2/RTAPI/RTAI ... will run if the root filesystem is read-only?
[21:20:49] <rayh> Good. Thal should help.
[21:21:33] <cradek> SWPadnos: that depends on whether everything it needs to be writable is writable...
[21:21:49] <SWPadnos> sure - I'm talking about mounting / ro
[21:21:58] <cradek> sure I understand
[21:22:06] <cradek> ... it depends what's on /
[21:22:13] <SWPadnos> heh
[21:22:16] <SWPadnos> duh! :)
[21:22:24] <SWPadnos> "everything"
[21:22:27] <cradek> I'm trying to kindly say your question is useless
[21:22:39] <cradek> ... and I just failed :-)
[21:22:48] <SWPadnos> I could have said "if all filesystems are mounted ro"
[21:22:59] <SWPadnos> sniff sniff
[21:23:10] <cradek> a ro root does not imply that there are no writable areas
[21:23:19] <cradek> surely some things need to be writable
[21:23:23] <SWPadnos> sure
[21:23:35] <SWPadnos> I guess /tmp and /var would need to be writable
[21:24:21] <SWPadnos> the idea is to allow someone to power off without shutting down, and not have an fsck the next boot
[21:24:33] <rayh> some systems start with /tmp and /var in RAM disk.
[21:24:42] <jepler> sure seems like you could remount "read only" after the application is started ..
[21:24:46] <SWPadnos> yeah. I think that's where I'll end up
[21:24:47] <cradek> a setup like that is possible but will be a lot of work
[21:25:03] <jepler> loadusr mount -o remount,ro /
[21:25:25] <cradek> you want some stuff written: var file, tool table, gcode...
[21:25:26] <SWPadnos> I tried that (at a shell prompt), but got the dreaded "/ is busy" message
[21:25:33] <jepler> cradek: his app is not emc
[21:25:38] <cradek> ohhh
[21:25:47] <SWPadnos> true - it's not EMC, it's just HAL/RTAPI
[21:25:51] <cradek> but ... he says EMC2 above in his question
[21:25:59] <jepler> you're right, he did
[21:26:07] <SWPadnos> though the question is also applicable to EMC2, as an appliance
[21:26:08] <cradek> * cradek waves his hands and talks to himself
[21:26:12] <SWPadnos> heh
[21:26:15] <SWPadnos> so he did
[21:26:18] <SWPadnos> his bad
[21:27:35] <jepler> you could try figuring out how to activate the kernel "emergency remount read-only" which you can do from the console with alt-sysrq-u
[21:27:43] <cradek> when I've wanted this kind of thing in the past for an appliance, I ran my own replacement for init that did only what I wanted
[21:28:03] <SWPadnos> jepler, interesting idea
[21:28:08] <cradek> that's very low level hackery that you probably don't want in this case
[21:28:19] <SWPadnos> cradek, well, I'd still like to be able to log in to make changes, so some init is needed
[21:28:49] <SWPadnos> I'll make a wiki page with the changes I've done to rc2.d to strip it down
[21:29:02] <SWPadnos> (once I'm happy with them)
[21:29:43] <cradek> the bridgeport detects power failure and shuts itself down nicely in the brief moment it has before the caps run out
[21:30:01] <SWPadnos> I did make a "halapp" script in /etc/init.d, but it needs to be pretty specific - I should make it read the hal start and stop script names from a file, or require them to be named something specific
[21:30:12] <SWPadnos> I considered that today as well
[21:30:20] <cradek> but even a basic "sync" can take seconds and seconds
[21:30:46] <SWPadnos> I think this will work anyway - there's only one application running, and it doesn't write (except for logs_
[21:30:58] <SWPadnos> the disk is an SSD, so there won't be any head crashes
[21:31:16] <SWPadnos> it's just an annoyance that it takes an extra minute to start up since it fscks then reboots
[21:31:27] <jepler> static void sysrq_handle_mountro(int key, struct pt_regs *pt_regs,
[21:31:27] <jepler> struct tty_struct *tty)
[21:31:27] <jepler> {
[21:31:27] <jepler> emergency_remount();
[21:31:27] <jepler> }
[21:31:30] <cradek> ext2?
[21:31:36] <jepler> just call this from a custom kernel module
[21:31:37] <SWPadnos> yep, ext2
[21:31:43] <SWPadnos> so there's no journald running
[21:31:52] <cradek> that's going to bite your ass one of these times
[21:31:58] <SWPadnos> it could
[21:32:04] <SWPadnos> hence the ro question ;)
[21:32:10] <cradek> right
[21:32:42] <SWPadnos> I think I'll get intimately acquainted with lsof options in the next day or two
[21:32:48] <cradek> my appliance app puts the (very few) things that have to be on the fs in /dev/shm
[21:33:01] <jepler> on a writable fs, you mean?
[21:33:04] <cradek> it's some kind of magic ramdisk
[21:33:05] <cradek> right
[21:33:35] <cradek> it has a few of its own state files that don't need to be saved across runs
[21:58:57] <alex_joni> good night all
[22:06:36] <rayh> night alex. say hello to the family.