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