any interp folks in here?
thinking about error messages for the g90.1/g91.1 command
it is an error if you don't supply both center coords
that can result in one of 6 messages, or I can compress them to 3, or even 1
"I word missing for absolute center arc in XY plane" <--- 1 of 6
"missing I J or K in G2 command in absolute center mode"
but yeah, thats the question - detailed but many, or generic?
btw, for new errors, use ERM("the string here") instead of the list
maybe I mean ERS
whichever it is
I see ERM(NCE_BUG_PLANE_NOT_XY_YZ_OR_XZ)
that must be the one that takes a code
ERS("Cannot set reference point with cutter compensation in effect");
you're saying I don't need to define a string in _errors.cc and a code in _return.cc?
that makes it so easy, make them as specific as you want
how does translation work with ERS
I thought the reason for _errors was to get them all in one place for translation?
jmkasunich: ERS strings are marked for translation too - see definition of ERS
I did look at the definition, I didn't see anything that screamed out "translate me"
if I invoke ERS in two places with the same string, will that result in two identical strings to be translated?
no they should be jonied in the catalog
right now I have "I word missing in absolute center arc", as well as J and K versions of that
each is invoked twice
I for XY and XZ planes, etc
if you rewrite it as "%c word missing" the translator will only have to deal with one message
how do I pass the char?
ERS("%c word missing in absolute center arc", 'I' )?
yes I think so
guess I can try it and see
I did test the version I have, G90.1/G91.1 are parsed, and the error messages are printed when appropriate
looking at the def of ERS, I don't see how I can get away with passing it a string and a char
it just wants a string
it passes it to setError, which is varargs goo
between varargs, the preprocessor, and C++, I'm somewhat lost
oh maybe you have to use ERF
emc/rs274ngc/interp_convert.cc:149:53: error: macro "ERF" passed 2 arguments, but takes just 1
maybe some extra parens...
that made it compile, testing
ERF needs parens: ERF(("format", value, value))
makes sense, it does setError error_args;
turns into setError ("format", value, value);
I've been looking at find_ends()
lovely isn't it
I think I need something like find_center()
(our friend indent did that to it)
I was originally thinking I could simply use find_ends() with different inputs, to get I and J after offsets, etc
g53 is legal for arcs isn't it?
don't think so
[02:37:40] <cradek> http://www.linuxcnc.org/docs/devel/html/gcode_main.html#sub:G53:-Move-in
error if: G53 is used without G0 or G1 being active,
yeah - I was thinking of G53 as being a modifier that could apply to any motion
so my find_center doesn't have to worry about that
actually it will be pretty simple
this is gonna have a ripple effect tho
right now the arc_data functions expect to be passed offsets, but I'm gonna be getting the actual center, not offsets, in find_center
it won't be hard to fix the arc_data functions to expect absolute centers
I suppose I could make find_center return offsets from current position, but that just seems wrong
especially since find_ends returns absolute
cradek: am I confused here? I originally thought that the interp did its work in machine coords, and that find_ends was responsible for removing offsets,etc, to reduce the g-code numbers to raw machine coordinates
but it seems the other way around - find_ends returns the values in the g-code unaltered, UNLESS you are in G53, then it applys offsets
this code is weird
convert_arc2 is called to deal with either ij arcs, or r arcs
the block is passed into it, as well as the i and j values, but not the r value
if its an r arc, the value is extracted from the passed in block, if an ij arc, it uses the args
I understand the reason - because they want to use one function for all three planes
the interp works in the coordinate systems that are currently active
yeah, that threw me for a loop, but ok
when _are_ the coords converted to machine space?
between the canon calls and the motions being added to the interp_list
the interp lets the canon level know the offsets with ST_OROGIN_OFFSETS and SET_TOOL_LENGTH_OFFSET etc
so basically at this level I can ignore offsets
"this level" = convert_arc() and the stuff it calls, like arc_data()
I think so
like find_ends you have to handle only a few things: what to do if the number is not specified in the block (error), what to do if cutter comp is in effect (nothing special in this case?)
find_ends doesn't do any error checking
yes but it handles the case where some words are missing
(by using the old value)
you'll handle that differently (earlier, probably)
the checks for missing words are earlier
are you deciding you don't need find_center because it doesn't do anything?
well, it does a little
I'm debating whether it should be finding the center, or finding offsets
[03:30:56] <jmkasunich> http://www.pastebin.ca/1250042
that is the center version
this hurts my head
that looks right to me I think
took me a while to see that the comp stuff is right
in convert_arc_comp1 if(move == G_2) move = G_3; else move = G_2;
oh, duh, that is just changing 2 to 3, and 3 to 2
why isn't radius comp allowed in YZ?
oh, XY is for mill, XZ is for lathe
still, the code seems to imply that I could do a compd move in XZ on a mill
yes you could
that's the cost of having only one interpreter
in reality, XZ and YZ are equally bad for mill, and XY and YZ are equally bad in lathe
we error on one and not the other
why not allow all?
never mind, if I keep digressing I'll never get anywhere
what is scaring me is the amount of coupling between all these routines
yeah it's all icky in there
I don't dare touch most of it
I think I want to get rid of find_center
instead, in abs mode I should find the incremental values that will result in the desired center, and then feed them into the remainder of the code
haha, /* compute other data */ ... then a dozen lines of inscrutable crap
/ tread not here, let ye be consumed
* jmkasunich runs away
what worries me is that neither of the convert_arc_comp functions is passed any center info
they pick the info right out of block->i_number, etc
which means, I'll have to actually modify that
the only place it's used is to pass arc_data_comp_ijk
hmm, so maybe I should do what you suggested in the first place, leave well enough alone until it gets all the way down to the arc_data functions?
there are lots of nice tests with arcs in them, in the test suite
IOW, "stop talking and do something, then see if it works"
cam-nisley has 257 arcs in it, I bet most of them are comped
none of them use absolute centers
first goal: don't break anything
you could change some to use absolute centers and it should not change the output
testing is all well and good
but I'm trying to decide what is the best way to write the code
where "best" = least likely to break things, least likely to make a future maintainer say "wtf?", and oh yeah, most likely to work
that middle criteria doesn't seem to have been all that important in the past
is this like "pick any two"?
yeah I was going to suggest picking #1 and #3 if so
the idea of adding another coat of wtf on top of what is already there makes me cringe
I'd rather be removing a layer if possible
we may have a style difference. I always make the minimum change possible. I still think you could change just those 4 lines and patch up the hypot()s and it would work correctly
but at a bare minimum there are comments that need changes
double i_number, //!< first coordinate offset of center from current
will be wrong
yes it would be nice to fix them
"would be nice" ?
you mean "a future maintianer will have the right to shoot me if I don't fix them:
(I rarely read and certainly never trust those comments)
then how do you figure out the code?
if you don't know what a functions inputs and outputs are, you are totally blind
EOW (end of weekend)
so far (aside from the parsing code already committed) the checks for missing IJK words, and the probalby useless find_center
I'm tempted to remove find_center, and commit what I have, then start fresh tomorrow evening with the actual implementation
missed some words there....
meant to say "I have the checks"
EMC: 03jmkasunich 07TRUNK * 10emc2/src/emc/rs274ngc/interp_convert.cc: checks for required IJK words in absolute center mode
I've noticed on my 64-bit/sim system that I don't get thread or function times or tmaxes in halcmd show.
I should look into that..
I think I remember they show up on i386/sim
EMC: 03cradek 07TRUNK * 10emc2/docs/src/gcode/main.lyx: clarify G10 L2
Period FP Name ( Time, Max-Time )
1000000 YES thread1 ( 0, 0 )
but the thread is running; encoder.0.rawcounts changes
is a hal_s32_t a long on 64-bit systems?
EMC: 03cradek 07TRUNK * 10emc2/docs/src/gcode/main.lyx:
EMC: Document additional UVW planes, make it explicit that G91 does not affect G10,
EMC: clean up plane-specific stuff in the canned cycles, be more explicit about how
EMC: repeats work, clean up G92 by describing the behavior instead of the
EMC: 03cradek 07TRUNK * 10emc2/docs/src/gcode/main.lyx: argh, missed one
EMC: 03eric-johnson 07TRUNK * 10emc2/src/emc/usr_intf/emclcd.cc: Intermediate update, added command line handling and additional features
[20:52:17] <seb_kuzminsky> http://nappy.colorado.edu/buildbot/waterfall
i built that before i saw jmk's new compile farm work...
need to fix the runtests
Runtest: 25 tests run, 23 successful, 1 failed + 1 expected
alex_joni: you made the 8.04 livecd, right?
trunk tests ran correctly last night when I tried them
cradek: I suspect it's based on the VM which has bad latency
seb_kuzminsky: yeah, why>
I should review what the threads test is trying to test
--- /home/farmer/BuildBot/slave/ubuntu-8.04-rtai-x86/hardy-x86-trunk-realtime-rip/build/tests/overrun: overrun detected in sampler, re-running test
the overrun test is supposed to fail
I should figure out a better way to test that the overrun detector works
seb_kuzminsky: anything on your mind regarding 8.04 livecd?
alex_joni: well, i was thinking it'd be cool to test on amd64
and that would be much easier if there was an amd64 livecd ;-)
jepler did the amd64 packages :)
* jepler hides
* seb_kuzminsky seeks
I wonder if my laptop would run x86_64
threads.0 may also turn out to be a test of realtime latency, and it may test a stronger condition than rtapi threads provide
would that run on a T5300 core 2 duo?
alex_joni: yes, according to intel that has EM64T
alex_joni: I run 64-bit ubuntu on my T7500 laptop
ah, cool.. maybe I'll try some day :)
but right now I feel drained
seb_kuzminsky: but using a default ubuntu 64 install cd + emc2 install script should be just as easy
alex_joni: ok, i'll try that
if the buildbot work survives community scruitiny ;-)
this is a very fogiving community
also quite small :D
alex_joni: if I tag a 2.2.7 will you have time to build it?:
today or tomorrow, american time
what's the url to the amd64 .debs? i mostly need the kernel & rtai stuff i guess
whoa hold on there jeff
the only thing I was partly worried is the stg stuff
but it's ok if it will go into 2.2.8 ;)
seb_kuzminsky: the apt list is the same for amd64 and i386
let me push the latest hostmot2 stuff into 2.2, i'll try to do it today or tonight ok? when are you tagging?
[21:10:58] <alex_joni> http://linuxcnc.org/hardy/dists/hardy/base/
that should work for both x86_64 and x86
EMC: 03cradek 07v2_2_branch * 10emc2/docs/src/gcode/main.lyx: backport clarification of G10 L2
EMC: 03seb 07TRUNK * 10emc2/debian/rules.in: if files are left out of the debian packages, show what they are
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/common/Stepper_Diagnostics.lyx: add some content on common problems
EMC: 03seb 07TRUNK * 10emc2/src/Makefile: install the firmware for the other Hostmot2 boards too
EMC: 03seb 07TRUNK * 10emc2/debian/ (5 files):
EMC: Make debian packages for the firmware for all the Mesa Hostmot2 boards.
EMC: (sorry Jeff)
seb_kuzminsky: just so you don't bugger up the 2.2 packages, you're welcome to explore whatever you think makes sense in 2.3.
you want to keep all hostmot2 firmwares in emc2.deb in 2.2?
it's bad to rearrange packaging during a stable release cycle
SWPadnos: i agree, but this is not really rearranging anything, it's adding new packages for the firmwares for newly supported hardware
jepler: i'll be happy to do whatever you think is right in 2.2 of course, but i'm not exactly sure what you want
seb_kuzminsky: scenario: a user has a working hostmot2 setup in 2.2.6 (ha ha). he upgrades to 2.2.7, but the firmwares are gone because they're in a separate package.
jmkasunich: i didnt see your compile-farm updates until it was too late!
seb_kuzminsky, changing what packages provide what and/or the dependencies is rearranging stff :)
it seems we're rarely in here at the same time
having the main package depend on the firmware package defeats the purpose
so that leaves the only choice for 2.2 as "don't split the packages"
it was probably a week from when I started (and was griping in here about memory issues) till the first pass message went out
jepler: emc2.deb recommends emc2-firmware seems to me to do the right thing
"if you just upgrade, you get everything including the new stuff"
"if you know what you're doing, you can remove the firmware without horking anything"
is that the plan for 2.3 as well?
seems that it defeats the purpose of a separate fw package
jmkasunich: that's what i put in trunk yes
cause 99.9% of people do whatever the default is
so everybody downloads and installs the whole thing, then 0.1% of them remove the stuff they don't need
that sounds right to me
the alternative is:
people upgrade to 2.2.7 or 2.3 or wahtever, but dont have the firmware and it looks broken to them
the firmware packages are not *that* big
"here's a nickle kid, buy yourself a better modem"
2.2.7 and 2.3.0 are two totally different issues
2.2.6 -> 2.2.7 must be simple and transparent
2.2.x to 2.3.0 _will_ require config changes
if it also means reading some docs and realizing that you need to install the fw packages, so be it
probalby 5% of the users will want mesa stuff
jepler: i'll make 2.2 put all the firmware in emc2.deb, no prob
is it too early to add g90.1 and g91.1 to trunk?
5% will have other high-end cards (stg, pico, motenc), and the other 90% will be doing software stepping
seb_kuzminsky: speaking of that, how are we for releasing a 2.2.7?
seb_kuzminsky: in terms of hostmot2
jmkasunich: would you accept emc2.deb Suggests emc2-firmware.deb?
jepler: i'll check it in later tonight, will that work?
seb_kuzminsky: I'm just stating an opinion, I don't know the meaning of recommends vs suggests
although I gather that recommends means will install by default, can be removed
and suggests means will not install by default
seb_kuzminsky: it's mostly for hm2 that I think we need the release (we do, right?) so yeah I'll certainly wait for your say-so
jmkasunich: that's right
seb_kuzminsky: I've just realized that if I don't do it tonight or tomorrow night, the next week or so is not going to give me the time..
BigJohnT: if you want to write words for G90.1/G91.1, go ahead - I hope to have it coded in the next couple of days
i'll merge hm2 from trunk into 2.2 tonight
gotta go, see y'all later
ok thanks jmkasunich
seb_kuzminsky: see you
I should run too
no work and all play
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gcode/main.lyx: add G90.1 and G91.1 and a bunch of spellos
that didn't take long
it was all ready there from the other day