Back
[01:05:52] <cradek> yeah I notice that too
[01:06:04] <cradek> I should fix (?) FO
[01:30:01] <cradek> arg
[01:30:13] <cradek> I think I need design help
[01:30:31] <DanielFalck> with what?
[01:30:38] <cradek> how feed override should work
[01:31:03] <cradek> say the machine's max is 60ipm
[01:31:10] <cradek> my gcode has F100 in it
[01:31:20] <cradek> I set FO to 50%
[01:31:27] <cradek> how fast should it cut?
[01:31:30] <DanielFalck> 30 ipm?
[01:31:39] <SWPadnos> 50
[01:31:39] <cradek> that's one answer :-)
[01:31:46] <SWPadnos> (the other answer)
[01:31:48] <cradek> ... and that's the other
[01:31:59] <cradek> beware: I haven't asked the hard question yet
[01:32:18] <DanielFalck> 50 ipm would be better
[01:32:46] <cradek> ok is everyone ready? how fast is a G0 rapid now?
[01:33:03] <DanielFalck> 60
[01:33:10] <SWPadnos> I chose the 50IPM answer because I think the FO should affect programmed rates, not manhine limits
[01:33:14] <SWPadnos> yes, 60 for G0
[01:33:28] <cradek> so FO should not affect G0? that's a very big change.
[01:33:29] <SWPadnos> unless we add a separate G0 override (as petev has asked for)
[01:33:32] <DanielFalck> or 30 : )
[01:34:06] <cradek> I don't want to add a separate rapid FO tonight (or for 2.2.0), so I want to not discuss that right now
[01:34:33] <SWPadnos> if you define FO as affecting G0 as well, then you may as well scale everything - so the example would go at 30
[01:34:33] <cradek> that leaves us with G1 = 50, G0 = 30, which seems unsatisfactory
[01:34:46] <SWPadnos> since you don't wnat any feed move to exceed the speed of a rapid traverse
[01:35:49] <fenn> i'll toss in my vote for 50IPM for what it's worth
[01:36:00] <SWPadnos> I would be somewhat suprised running F100 code on my 60IPM machine at FO 50, and getting 30 (which is 30% of 100)
[01:36:02] <cradek> ok, I think we'd all like it to be 50
[01:36:29] <cradek> SWPadnos: but, that's what emc has done since day 0
[01:36:32] <SWPadnos> I don't know what to do about G0 though
[01:36:53] <SWPadnos> ok, in that case others (who have actually used EMC) would be more surprised ;)
[01:36:53] <fenn> i think there is often a separate feed override for g0
[01:37:01] <cradek> I don't either, that's why I'm talking instead of committing
[01:37:01] <SWPadnos> not in EMC at the moment
[01:37:06] <fenn> for proofing programs and stuff
[01:37:38] <DanielFalck> running rapids at a slower speed for proofing is good
[01:37:44] <cradek> my BP has complicated rules for when FO affects rapids. when in normal auto/running mode, it doesn't
[01:37:45] <DanielFalck> we do that at work
[01:38:06] <cradek> but, it has only the one knob
[01:38:28] <DanielFalck> but, I think we have seperate knobs for g0 and g1
[01:38:39] <DanielFalck> or I mean rapids vs feed
[01:38:45] <cradek> DanielFalck: yeah I know some machines do have that
[01:39:10] <fenn> what's the difference between "feed" and "traverse"?
[01:39:23] <DanielFalck> I'd lean towards slowing down rapids with that one knob
[01:39:24] <SWPadnos> G1 vs G0
[01:39:25] <cradek> fenn: pretty much G1 vs G0
[01:39:34] <fenn> so would "traverse override" sound weird?
[01:39:42] <DanielFalck> sure does
[01:39:47] <fenn> thought so :)
[01:39:48] <SWPadnos> Rapid Rapid Reduction!
[01:40:18] <cradek> DanielFalck: if so, in my example above, how fast should the G0 move?
[01:40:32] <cradek> (example was: machine is 60ipm, gcode F100, FO 50%)
[01:40:39] <DanielFalck> 30
[01:40:50] <cradek> so the rapid is slower than the G1
[01:41:07] <DanielFalck> you got me on that one
[01:41:28] <cradek> yeah, this is where I'm stuck
[01:41:35] <fenn> instead of limiting just the traverse rate, you could have the other knob control the machine's limits
[01:41:42] <SWPadnos> I don't know that one answer works in both the situations we're discussing
[01:42:00] <fenn> then it would clamp the velocity for both kinds of moves
[01:42:24] <DanielFalck> tell everyone to make faster machines : 0
[01:42:29] <cradek> fenn: so in the example, what would be the cutting speed?
[01:42:39] <fenn> 30
[01:43:17] <fenn> is that the way it is now?
[01:43:29] <cradek> I think so
[01:43:51] <cradek> I mean yes
[01:44:28] <fenn> DanielFalck: does feed override normally affect traverse rate?
[01:45:02] <cradek> fenn: I'm sure the answer is "sometimes"
[01:45:10] <DanielFalck> let me look at something real quick....
[01:45:27] <fenn> the important thing is what "feed override" "means" to the average operator
[01:45:40] <fenn> not what the words actually mean separately
[01:45:49] <cradek> sure
[01:46:12] <cradek> but on some machines it does both, or only sometimes it does both (like on mine)
[01:46:41] <cradek> I bet "the average operator" will tell you he expects what the last machine he used does :-)
[01:47:02] <fenn> principle of least astonishment and all, i think that's a decent goal to shoot for
[01:47:04] <DanielFalck> can you make it configurable? or do we even want that?
[01:47:49] <cradek> configurability is a poor replacement for a good design
[01:48:09] <cradek> (fenn is definitely right about least astonishment)
[01:48:20] <cradek> cuts faster than rapids != least astonishment
[01:48:31] <fenn> this sounds like something for the mailing list
[01:48:45] <fenn> or we could put up a poll on joomla :)
[01:48:48] <cradek> argh
[01:50:23] <cradek> I think I should try to get the old behavior and leave it at that
[01:50:40] <cradek> since I've never heard anyone say they were astonished by it
[01:50:49] <fenn> ok
[01:51:02] <DanielFalck> so 30 ipm and 30 ipm in the example above?
[01:51:11] <fenn> yes
[01:51:21] <cradek> yes
[01:51:27] <DanielFalck> that works for me
[01:51:29] <SWPadnos> that could make sense
[01:51:44] <fenn> and if you program F30 what do you get?
[01:51:48] <SWPadnos> 15
[01:51:51] <DanielFalck> 15
[01:52:00] <cradek> rapids 30, feed 15
[01:52:29] <cradek> move to tool change 30, etc etc
[01:52:43] <fenn> that's a different move type? eesh
[01:52:53] <cradek> it's a rapid-like move
[01:52:55] <DanielFalck> I'm looking at a Daewoo Puma lathe panel in a manual and it only has 1 knob, so I think it would work the same
[01:53:13] <cradek> does it say explicitly when the knob applies?
[01:53:29] <cradek> like I said, the BP applies it to rapids 'sometimes'
[01:53:38] <cradek> which was pretty 'astonishing' to me
[01:54:02] <cradek> (but I sure see the reasons.)
[01:54:04] <DanielFalck> no
[01:54:12] <DanielFalck> it doesn't mention it
[01:54:17] <fenn> i think adding a separate override for rapids only could be useful, but a separate override for feeds only is dangerous
[01:54:34] <fenn> but the rapid override would clamp the maximum velocity too
[01:54:45] <cradek> fenn: I would support "scale the max" + "scale the F word"
[01:54:50] <fenn> it just wouldn't divide intermediate velocities
[01:55:30] <cradek> I still insist that rapid-only override is stupid (because F999 still crashes)
[01:55:43] <fenn> no, the rapid override clamps feeds to the rapid speed
[01:55:54] <fenn> so f999 would be like if you programmed g0
[01:56:05] <cradek> right that would be the sane thing
[01:56:15] <SWPadnos> not quite
[01:56:22] <fenn> in your example, with rapid override 50%, f30 would still give 30ipm
[01:56:36] <cradek> ok
[01:57:00] <SWPadnos> F999 wouldn't get scaled to F19.99 at 1%, it would get left alone, but clamped to an effectively lowered machine limit
[01:57:00] <cradek> petev has supported the thing I think is bad: rapid override scales rapids, feed override scales feeds
[01:57:35] <DanielFalck> maybe rapid should override should also scale feed values
[01:57:49] <fenn> DanielFalck: that would be the same thing as feed override then
[01:58:03] <DanielFalck> so a G0 would be 30 ipm and F3 would be 1.5 ipm
[01:58:09] <cradek> DanielFalck: I think 'rapid override' is bad user interface. the slider should be 'machine speed cap' and be in ipm
[01:58:27] <DanielFalck> yes
[01:58:31] <DanielFalck> on slider
[01:58:34] <DanielFalck> one
[01:58:41] <cradek> then, FO% should scale the F word in the obvious way (multiplying by FO%)
[01:58:45] <fenn> you could call it 'speed limit' and have a highway sign :D
[01:59:00] <cradek> fenn: maybe 'feed limit'
[01:59:16] <fenn> but it limits rapids too
[01:59:18] <cradek> I don't know about the wording, but I do know how it should work
[01:59:30] <cradek> true, but 'speed' means something else
[01:59:36] <fenn> it does?
[01:59:49] <SWPadnos> spindle
[01:59:56] <fenn> aww come on
[01:59:59] <cradek> speed means alternately spindle speed (rpm) or surface speed (fpm)
[02:00:02] <SWPadnos> feeds and speeds, man!
[02:00:19] <cradek> don't shoot the messenger :-)
[02:00:20] <fenn> speed limit does not mean surface or spindle speed
[02:00:40] <cradek> fenn: why not? there's a spindle speed (rpm) override too.
[02:00:46] <SWPadnos> the word speed in machining is almost universally applied to the spindle or tool
[02:00:51] <cradek> yes
[02:00:55] <DanielFalck> yes
[02:01:04] <SWPadnos> whereas feed is almost universally applied to tool movement
[02:01:08] <DanielFalck> yes
[02:01:09] <cradek> yes
[02:01:10] <cradek> :-)
[02:01:12] <SWPadnos> yes
[02:01:18] <fenn> but feed also means a cutting movement, does it not?
[02:01:19] <DanielFalck> feed rate and spindle speed
[02:01:29] <fenn> like you're feeding a plank into a planer
[02:01:37] <SWPadnos> feed = a cutting move, traverse means a non-cutting move (for the most part)
[02:02:07] <cradek> maybe nobody except emccanon programmers say traverse, they say rapid(n)
[02:02:15] <SWPadnos> that's woodworking. we don't use that kind of language in here! ;)
[02:02:31] <fenn> well it was an easy analogy
[02:02:45] <cradek> dangit now where am I
[02:02:58] <DanielFalck> I used to be a woodworker. we measured things in decibels then.
[02:03:18] <cradek> haha, feed that wood into the planer at 85dB
[02:03:18] <SWPadnos> I think you're at reimplementing Fo as it is (if it needs reimplementation now)
[02:03:46] <cradek> earplugs make the cuts go faster
[02:03:57] <DanielFalck> they sure reduced the pain
[02:04:14] <DanielFalck> I think you can leave things as is
[02:04:16] <SWPadnos> everything gets scaled, including G0, so in the example, G0 would be 30 IPM and F100 would be 30 IPM
[02:04:45] <cradek> I would not have touched it except for the wrench alex threw in the works
[02:04:48] <SWPadnos> you just end up with more F words getting clamped to the lowered G0 rate
[02:04:51] <cradek> (which was my idea, to be fair)
[02:04:51] <DanielFalck> eventually we'll all have machines with high powered linear ways and we won't even have to worry
[02:05:05] <fenn> DanielFalck: no, that's why i'm suggesting the rapid override
[02:05:22] <fenn> DanielFalck: when you're testing out the program you dont want to rapid at 1000ipm, but you do want to cut the metal at the right speed
[02:05:38] <fenn> otherwise your testing isnt worth much
[02:05:55] <DanielFalck> we have some Wasino lathes at work that have rapid over ride knobs
[02:06:00] <cradek> fenn: but you don't want rapid override (%), you want a cap
[02:06:07] <fenn> cradek: right
[02:06:20] <cradek> ok I'm glad nobody's arguing that tonight :-)
[02:06:44] <fenn> hence why i said 'speed limit' since its universally understood (by americans at least)
[02:07:04] <DanielFalck> If you are proving out a program and your feed is too slow, it usually doesn't hurt much
[02:07:18] <DanielFalck> unless you're routing wood : )
[02:07:19] <cradek> I agree that's a good way to express the idea, except for the problematic usage of the word "speed"
[02:07:40] <fenn> DanielFalck: if you have a fixed speed spindle and are cutting plastic, it matters
[02:08:03] <DanielFalck> yes, I know. I've melted it myself once ....
[02:08:06] <DanielFalck> or twice
[02:08:26] <cradek> I either cut air to test, or cut a part, not both
[02:08:34] <DanielFalck> and you can burn wood with a router bit too
[02:09:00] <cradek> (and when using emc I don't bother cutting air, I can look at the preview just fine thank you)
[02:09:04] <DanielFalck> with a lathe, it's not as much a problem if the spindle is tied to feed rate
[02:09:20] <fenn> cradek: your setups dont involve lots of clamps and stuff do they?
[02:10:01] <cradek> usually I just cut between clamps/jaws, I use the 'extents' numbers to check that the entirety of the program is between them
[02:10:24] <cradek> or, I jog to the extents and look to see where the tool goes
[02:10:48] <cradek> and it's easy to see when no lines go 'further'
[02:11:20] <DanielFalck> proving out a program on a turret lathe can be really scary- when you watch a turret rotate another tool in place. There is no feed override for that.
[02:11:57] <DanielFalck> If you want, I can look at the mills and lathes at work to give you a survey of what does what
[02:12:06] <cradek> I suppose tool changers that take a lot of clearance are that way too
[02:12:44] <cradek> on the mazak we had a tool 5? inches longer than another, the head was pretty low for the short one, and the long one barely cleared the table
[02:12:54] <cradek> (when changing)
[02:13:27] <cradek> I suppose the right answer is 'get better tooling'...
[02:13:42] <cradek> DanielFalck: thanks but I think we'll have the old behavior for a bit
[02:13:51] <DanielFalck> ok
[02:14:10] <cradek> someday I would like 'motion cap' and 'scale the F word' functions
[02:14:42] <cradek> but the majority of the work for that is tedious NML and GUI
[02:15:05] <DanielFalck> do you have an actual feed rate read out in Axis?
[02:15:14] <cradek> yes
[02:15:14] <DanielFalck> I have one on my Centroid
[02:15:20] <DanielFalck> cool
[02:15:34] <DanielFalck> that's pretty valuable to have
[02:15:36] <cradek> in emc2.2 it's very good, in 2.1 it's pretty poor
[02:15:45] <cradek> yes
[02:15:48] <fenn> did you actually have velocity displayed with different colors or was skunkworks making that up?
[02:16:03] <cradek> ?
[02:16:04] <DanielFalck> that's what really counts when you're afraid of busting a cutter
[02:16:29] <fenn> like, blue for 0 and red for 50 ipm
[02:16:41] <cradek> no, I've never done that
[02:16:56] <cradek> I have had colored blends for debugging blending
[02:16:59] <DanielFalck> is it different line types for rapids and feed moves?
[02:17:03] <DanielFalck> I can't remember
[02:17:07] <cradek> yes, rapids are dashed
[02:17:12] <cradek> or grey or something
[02:19:26] <DanielFalck> when I'm checking out g-code from apt, I always make the feed moves very high - 400 ipm and then check the code out in axis
[02:20:08] <fenn> i usually set feed override to 500%
[02:20:16] <fenn> and run it on a sim config
[02:20:27] <DanielFalck> yes, I'm running from sim
[02:20:56] <fenn> then i can slow it down to watch something interesting
[02:21:06] <fenn> i guess you could do that anyway
[02:22:45] <DanielFalck> my bridgeport can do something like 250 ipm, but it's too much for what I do
[02:25:39] <DanielFalck> with little tiny cutters and a bridgeport spindle
[02:54:31] <LawrenceG> perhaps all emc needs is a warning when program is loaded/verified if any F words are found that exceed machine capabilities
[02:57:43] <fenn> no that's just annoying
[03:21:46] <LawrenceG> clipping without warning gives the dreaded WTF? response
[03:24:17] <cradek> I think I disagree - if my machine goes 60, and I get someone else's gcode with F200 in it, it's not a "WTF moment" if my machine still goes 60
[03:25:10] <cradek> but, having to tell emc every time I load his program that it's ok my machine is still 60 is a "WTF moment"
[03:25:36] <LawrenceG> seems like the program should be fixed to run on the machine
[03:26:08] <LawrenceG> its like someone trided to load a program setup for a vmc on a desktop mill
[03:27:44] <fenn> yes i'd just love going through and fixing each of the 5000 f-words
[03:28:16] <LawrenceG> thank goodnes I'm not suggesting 5000 warnings!
[03:28:28] <cradek> it's true any program that was originally for a grossly different machine will need some editing
[03:28:51] <cradek> but for a slightly different one, maybe not
[03:29:01] <cradek> Invalid F word on line 1!
[03:29:04] <cradek> Invalid F word on line 2!
[03:29:08] <cradek> haha
[03:29:15] <fenn> error: can't do that
[03:29:23] <LawrenceG> seems a basic fuction of verifying the gcode when loaded
[03:29:37] <LawrenceG> sorry cant type tonight...
[03:30:37] <fenn> this could be one use of colored backplots
[03:30:50] <fenn> er, preview
[03:31:18] <fenn> i might try to fix a mis-colored line if i were a perfectionist
[03:31:34] <fenn> but clicking 'ok' each time i reload the program wears on your nerves
[03:31:49] <fenn> s/your/my/
[03:33:49] <LawrenceG> yes, pop-ups are ugly... better in a scrolling status bar so there is some history
[03:34:33] <LawrenceG> that way if there are 5 errors in a program, one doesnt get 5 popups
[03:35:07] <LawrenceG> or maybe a scrolling message window that only pops up if there is a problem
[03:42:44] <LawrenceG> on feeds, operator is used to the FO working within the speeds the machine is configured for.
[03:44:06] <LawrenceG> if a program uses wildly odd speeds, I think simple clipping within the machine limits is the way to go... if operator likes to run machine with dial at 50%, it should never run a program faster than 50% of configured machine speed
[03:45:33] <LawrenceG> this could be considered a safety issue
[03:47:24] <LawrenceG> ie.. if operator has machine set at FO of 50%, no program should be able to make it run faster than the expected 50% or machine configured value
[03:47:44] <LawrenceG> or/of
[03:48:11] <LawrenceG> bbl guys... have a good Sat PM
[13:51:21] <tissf> hello can someone could help me to compile the doc after french translation?
[13:52:21] <alex_joni> hi tissf
[13:52:27] <alex_joni> what is your exact issue?
[13:53:15] <tissf> some compilation error, wait please i cut the message
[13:53:58] <tissf> Building ../docs/src/Master_HAL.pdf
[13:53:59] <tissf> Locale fr_FR could not be set
[13:54:01] <tissf> Locale en_US could not be set
[13:54:02] <tissf> Error in latexParagraphs: You should not mix title layouts with normal ones.
[13:54:04] <tissf> convert: error while loading shared libraries: libGraphicsMagick.so.1: cannot open shared object file: No such file or directory
[13:54:05] <tissf> /usr/share/lyx/./scripts/convertDefault.py ERROR
[13:54:07] <tissf> Execution of "convert" failed.
[13:54:51] <tissf> an idea ?
[13:59:44] <SWPadnos> do you have imagemagick installed?
[14:00:46] <tissf> oups no !
[14:01:02] <SWPadnos> That could be the problem ;)
[14:01:37] <tissf> juste installed gutsy
[14:03:43] <tissf> another error:
[14:03:44] <tissf> convert: error while loading shared libraries: libjasper-1.701.so.1: cannot open shared object file: No such file or directory
[14:04:23] <tissf> libjasper 1.9 installed
[14:08:55] <tissf> that works, imagemagick library missing !
[14:09:04] <tissf> Thank you
[14:25:01] <SWPadnos> you're welcome
[14:25:17] <SWPadnos> or should I say pas de quoi
[14:30:45] <tissf> :o) Thanks
[14:31:53] <tissf> some dYet the difficulties in compiling files French
[14:33:00] <tissf> The doc will compile ... But in English!
[14:33:56] <SWPadnos> yes - I think you would need to replace all the .lyx files with French translations to get french-language docs
[14:34:14] <SWPadnos> the translations that are there now are for messages and menu/button labels in the program
[14:36:53] <tissf> I have translated one docs/gui file.py for testing and added the name in Submakefile:
[14:36:53] <tissf> ifeq ($(BUILD_DOCS),yes)
[14:36:54] <tissf> DOC_SRCS := \
[14:36:56] <tissf> code/Code_Notes.lyx \
[14:36:57] <tissf> code/Style_Guide.lyx \
[14:36:59] <tissf> gui/axis.lyx \
[14:37:00] <tissf> gui/axis_fr.lyx \ <<<<< added by me
[14:37:29] <tissf> I have missed other parameters !!
[14:38:02] <SWPadnos> hmmm. I don't know enough about how the lyx files get combined or how they refrence each other
[14:38:28] <SWPadnos> you might try removing the english version of axis.lyx and just use the french translation
[14:38:43] <SWPadnos> but I'm not sure that will help (or hurt)
[14:39:23] <tissf> with same filenames ?
[14:40:23] <tissf> I have to wait Jef help :)
[14:40:29] <SWPadnos> try it with the _fr extension first, then renamed as axis.lyx
[14:40:40] <tissf> yes
[14:40:45] <SWPadnos> yeah, waiting for someone who knows what they're talking about is also a good option :)
[14:41:38] <tissf> sûre that's but thank you for the help :)
[14:41:48] <SWPadnos> you're welcome
[15:00:32] <tissf> How to avoid this compilation error? Which is the cause?
[15:00:34] <tissf> make: Entering directory `/home/francis/emc2-trunk/src'
[15:00:36] <tissf> Building ../docs/src/Master_HAL.pdf
[15:00:37] <tissf> Locale fr_FR could not be set
[15:00:39] <tissf> Locale en_US could not be set
[15:00:40] <tissf> Error in latexParagraphs: You should not mix title layouts with normal ones.
[15:01:27] <SWPadnos> don't know - sorry
[15:48:36] <jepler> maybe this is the cause and solution?
http://www.mail-archive.com/lyx-users@lists.lyx.org/msg47299.html
[15:49:05] <jepler> but those may just be warnings, this is the real error: convert: error while loading shared libraries: libGraphicsMagick.so.1: cannot open shared object file: No such file or directory
[15:49:10] <jepler> are you sure all requirements of lyx are installed?
[15:50:15] <jepler> or maybe you resolved that one
[15:50:21] <tissf> hello jef :)
[15:51:03] <jepler> I have not developed the documentation on gutsy .. note that configure will print a message warning you that the documentation should be edited only with version 1.3.x, while gutsy seems to have 1.5.1.
[15:51:17] <tissf> libgraphicsmajick's solved
[15:51:47] <tissf> under gutsy some tools disapear
[15:52:29] <tissf> but i solved by cp en paste from feysty to gutsy /usr/bin !
[15:53:18] <tissf> now the html compile fine with your blue color :o)
[15:54:56] <tissf> for v 1.3.x but all in english !
[15:56:30] <jepler> the .lyx documentation must be compatbile with lyx 1.3.x, to build pdf documentation on ubuntu dapper
[15:57:50] <tissf> ahhh yes I can compile under dapper, feisty or gutsy but lyx under dapper is a pain !
[16:00:38] <jepler> if the files you write can be processed on ubuntu dapper, I don't care what version of linux you use. but if they can't be processed on dapper, it's no good
[16:01:33] <tissf> OK
[16:02:35] <tissf> the compilation is correct but the French files are ignored
[16:02:42] <tissf> !
[16:03:23] <tissf> I have to set fr_FR and us_US correctly
[16:03:24] <jepler> can you send me taxis_fr.pyx and I will see if I can figure out how to make it work on dapper?
[16:04:17] <jepler> axis_fr.lyx, I mean
[16:04:27] <jepler> maybe in e-mail? i have to leave now.
[16:04:40] <tissf> :) yes by mail, I join some explanations
[16:04:41] <jepler> and thank you for undertaking this work
[16:05:42] <tissf> I want the first file_fr compile correctly before the big work
[16:05:52] <tissf> thank you for help
[17:21:43] <alex_joni> SWPadnos: around?
[17:44:01] <alex_joni> SWPadnos: n/m, I managed to make it work :)
[17:44:14] <alex_joni> * alex_joni remembered a trick cradek told me about once
[18:31:43] <tissf> jepler>maybe this is the cause and solution?
http://www.mail-archive.com/lyx-users@lists.lyx.org/msg47299.html
[18:31:45] <tissf> It seems that the problem is here
[19:28:38] <jepler> tissf: I didn't have any trouble processing the french-language files on my Ubuntu Dapper machine, after converting the lyx file to version 221 using lyx2lyx.
[19:29:01] <jepler> however, without converting the file using my Ubuntu Gutsy machine, the version of lyx on Dapper couldn't read the file at al
[19:29:04] <jepler> all
[19:30:17] <tissf> thank you Jeff
[19:30:49] <jepler> hmmm .. terms in all languages will appear in a single index..
[19:30:55] <jepler> I'll have to fix that
[19:31:57] <jepler> http://www.linuxcnc.org/docs/2.2//EMC2_User_Manual_fr.pdf http://linuxcnc.org/docview/2.2/html/gui_axis_fr.html
[19:35:34] <tissf> Wow! You are the god of lyx :)
[19:36:12] <jepler> it still doesn't explain why you had the problems you did
[19:36:36] <tissf> I write really better french than English!
[19:37:08] <jepler> your english is fine, don't worry about it.
[19:37:33] <jepler> I assume your french is even better
[19:37:59] <tissf> ;)
[19:38:16] <tissf> I will leave gutsy and build under dapper
[19:38:38] <jepler> I hope that's not too inconvenient for you
[19:40:04] <tissf> no problem. Where can I find lyx2lyx?
[19:41:19] <jepler> you have to invoke it using the full path: /usr/share/lyx/lyx2lyx/lyx2lyx
[19:41:33] <jepler> I mentioned this in the docs/src/README file, it gives an example commandline
[19:43:00] <tissf> thank you I have to read it :) sorry
[19:44:08] <tissf> Time to eat here! Soon
[19:44:53] <jepler> enjoy your meal
[19:47:05] <jepler> tissf: you will need to change the index entries so that they are french terms instead of english ones
[20:17:50] <jepler> tissf: by the way, my gutsy system has /usr/bin/epstopdf from the package texlive-extra-utils
[20:19:40] <jepler> and convert from package imagemagick
[22:42:13] <tissf> jepler: ok packages problem resolved
[22:43:09] <tissf> I correct the indices
[22:43:21] <tissf> index sorry