EMC: 03seb 07TRUNK * 10emc2/docs/man/man9/hostmot2.9: (log message trimmed)
EMC: hostmot2 release 0.9:
EMC: Fixed stepgen.stepspace, it was not getting set correctly on the FPGA.
EMC: Fixed stepgen.position-fb, it was not getting set reported correctly
EMC: to HAL.
EMC: Added stepgen.maxvel.
EMC: Added raw.dump_state, a way to cause hostmot2 to dump its internal
EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/ (ChangeLog hostmot2.c hostmot2.h raw.c stepgen.c): (log message trimmed)
EMC: hostmot2 release 0.9:
EMC: Fixed stepgen.stepspace, it was not getting set correctly on the FPGA.
EMC: Fixed stepgen.position-fb, it was not getting set reported correctly
EMC: to HAL.
EMC: Added stepgen.maxvel.
EMC: Added raw.dump_state, a way to cause hostmot2 to dump its internal
did I see an issue with putting negative scale into the ini?
that was fixed
[12:16:13] <skunkworks> http://cia.vc/stats/author/jepler/.message/246ef1
[12:16:41] <skunkworks> http://www.cnczone.com/forums/showthread.php?p=491649#post491649
skunkworks: it depends what "can't insert a negative number" means. The bug is not that a negative number can't be typed into the window, the bug is that when you enter a negative number it doesn't work right (the axis won't move)
the fix for that problem will be in 2.2.7, and the workaround is to enter all positive numbers and use "invert" on the direction pin
ok - I will pass that on.
good morning, and you're welcome
I just wish I hadn't fould up stepconf in that way :(
oh - so it isn't an ini issue? it is a stepconfig issue?
if you manually changed the ini scale to negative - it would work? (yes I know you cannot then go back and use stepconf to make changes)
that doesn't seem so bad :)
basically, when stepconf writes a negative SCALE it also ends up writing a negative MAXVELOCITY
I was thinking - boy - that is going to break a ton of configs.
ah - ok
jepler: what happens if you edit the ini/hal manually and then try to re-run stepconf? do you loose your changes?
no, you lose your changes.
no loose changes in *these* inis
yay, that means there will be a 2.2.7 that I can try to sneak new features into
I know I've got some I want :-P
I'll help you check them, if it would help.
(and clearly one of them is a bugfix for the "I can't abort when an operator message is shown" bug)
I should add the gs2_vfd module too, but I can't remember why I didn't
what does that do?
SWPadnos: it's a given that you can just throw that in TRUNK
modbus control of a gs2 series VFD
(from Automation Direct)
I wonder if it had to do with the license for the modbus library
oh hey, I think that's what I have
if that uses a library, then it is tougher to put it in 2.2 -- so far we've not required additional packages to be installed for upgrades within the 2.2.x series
it's a source library, I don't think there's a package
like NML, for the most part
any ideas how to fix bug sf#2046178 ?
speaking of sf bugs, is there any way to take a bug number and directly get the report?
it seems like you have to know what project, and what tracker, and then scan the "request id"s in that tracker...
micges: the answer is "run from line needs serious work and many developer hours of time to work like people want"
type it into the sesarch box at the top right of the EMC main page
[13:02:11] <skunkworks> http://www.cnczone.com/forums/showthread.php?p=491709#post491709
* SWPadnos just learned that ;)
(suppose that you have the program: G0 X0 Y0 Z0 / G2 X0 I1 / M2. What should a control do if you actually jog to X10 then run from the G2 line? It doesn't even make sense! there's no an arc from X10 Y0 to X0 Y0 with the center at X11 Y0!)
I agree with jepler, and if you jog, none of the arcs are ever going to be what you want
but, even without jogging, the behavior is a little puzzling
it could be argued that stop/restart from the same line would be least surprising if it acted like pause (feedhold)
though I have no idea how to make that true - I suspect it's not trivial
jepler: It should run line with G2 with it as it is said "this is next line to run"
maybe we should ask the user list what most controls do or what they would expect
I don't think we have enough information to (a) decide to do a lot of work to make it do something we like or (b) decide it's too hard to get right
if you think that is stupid, I think that it must be consistent
no, not stupid, just unclear (note that I'm not testing this right now, so I haven't seen the actual behavior)
if you stop a program during an arc, and you want to complete the arc when you restart the program, then it's important that the machine is still on the arc
otherwise the math either doesn't work, or the recalculated arc is wrong
Remember that the interp doesn't know where the machine is. It only knows where it told it to go.
so if you've moved at all, or hitting Estop allowed the motors to get off the path, then there's a problem that probably can't be solved by the computer
Lerman, unless you have servos and feedback
Since jogging isn't seen by the interp, it can't know that you jogged.
No. Servos and feedback tell emc where it is, but not the interp.
uh - yes, the interp knows where jogging takes the machine
I think we have a terminology problem here (probably on my end :) )
the interp certainly knows what the machine position is when it starts a move
Or maybe at mine. :-) When I say interp, I mean the thing that reads the gcode.
That does not include the RT stuff.
that must also know what the machine position is, or it couldn't calculate the arc in the first place
The interp (as I use the term) doesn't know or care whether it is a stepper system or a servo system.
(emcstatus exposes that stuff to userspace, as do some HAL pins)
true, either feeds position back to the upper userspace layers
it's just synthesized for stepper
The interp knows what it told the machine to do. It says go to x, y, z and sets that as its current position.
this is why people with stepper machines can get following errors
if stepgen isn't correctly configured
I know all this up to now
From a layer closer to the hardware than what I'm calling the interp.
isn't that 'motion' - not interp?
oh - yes, you're right that that's how the interp is able to keep interpreting while long past lines are being executed
let's forgot about jog
My partial solution to some of the problems is to move some of this back up the hierarchy into what I call the interp.
but when you switch to auto mode from jog/MDI it has to re-sync, so it will know where the machine actually is at the start
Yup. And it wants to start at the beginning of the program.
To get all of the mode, etc stuff right.
aside from that - there is the problem micges is mentioning (which I haven't reproduced yet, though it seems cradek and jepler have)
in fact, they're so quiet, I'm almost expecting a CVS commit message in a few minutes ;)
funny how that usually works
Lerman: how is the conversion to emc2 going?
ok test is:
I'm still working on it. Axis is now running OK. I'm getting limit switch errors when I try to run. It tells me that I'm on the limit when I'm not.
1. run emc/sim
I suspect the logic in the ini file that tells the sense of the switches has changed.
I decided to RTFM and I'm starting to do that now.
the old ini parameters named xxx_INDEX are no longer used, they're HAL-ified now
I run sim all the time on another machine. That's how I've been able to contribute to the source.
2. load gcode:
G0 X0.0000 Y0.0000
Yeah, I figured it was something like that. Do you know if there is an EMC1 to EMC2 upgrade guide around.
G1 X100.0000 Y0.0000
micges, I think the steps to reproduce are in the bug report - I just don't have a PC runnung with EMC at the moment
G3 X143.3013 Y25.0000 I0.0000 J50.0000
G3 X143.3013 Y75.0000 I-43.3013 J25.0000
G3 X100.0000 Y100.0000 I-43.3013 J-25.0000
G1 X0.0000 Y100.0000
G0 X0.0000 Y0.0000
Lerman, I think the idea is to take the sample config that uses your hardware, and change the things that are machine-specific in the HAL/ini files (scales, PID, I/O pin assignment, etc)
That's what I did. I'm just not done yet. :-)
heh - see you
SWPadnos: I take care to make sure that machine is on the arc when run from it
point is that Im call "start from 44" and emc is going to run 43 in some way
everytime that actual arc is after g1 line , that g1 line is executed
that the problem
everything else is in all correct
I think that behavior is done on purpose, to insure that the arc is correct
you have to be at the correct start point for the arc calculation to come out the same
I agree with jepler that we do not have a coherent design for run-from-line so adding bugfixes is the wrong approach
like he pointed out, if you jog, there is no arc and starting at the arc lines like in micges's bug report is an error
in this way I don't agree with micges's "expected behavior" in the bug report. To me the expected behavior is an error message about an invalid arc.
I agree - I think the expected behavior is what happens the first time - a move to the start, then continue from there
there is a bug though, the second one doesn't do that
the bug being that they're treated differently, not that I really know which is right
when you have 0.5 kW laser and you stop in middle of 1m radius arc (burned with 100mm/min) to check anything, then you can't move to begin and burn it again..
yep, I was thinking about laser/plasma/watercutting
SWPadnos: no, he is saying the opposite, that the first behavior is wrong and the second one is right
to me they are both wrong
I know :)
oh ok, I was wondering about your reading comprehension there for a minute
do you have an idea of what's right?
I'm not sure there are any other options than "don't allow that"
neglecting implementation complexity, I would point out that if you haven't jogged, you are on the arc, and you could in theory construct a new arc that follows the rest of the old arc
I think behavior 1 is better. micges thinks behavior 2 is better. you don't like either, so you have to come up with 3 :)
I suggested 3: give an error
I suggest 4: let user choose
because you can't run that line from the current machine position; it makes no sense to do so
error for what? selecting an arc as the "next line"
correct: let intergrator choose
I like the user choosing
no, selecting an invalid arc
that's a non-answer
start from here or start from the beginning
when resuming a program
you can't start from here
it is not a valid arc
you may not be able to start from here, but the machine can't tell if you wanted to based on whether the math works out
you can't start from middle but its burn correctly ? strange
I don't see how I got the arc I got, unless IJ arcs always have asolution (barring pathological cases like zero radius)
in somehow something allow it to run correctly in second arc from bug report
no, it does not follow the original arc, look again
it makes some other (wrong, buggy) arc
incorrectly - that isn't the programmed arc
right, there is an arc, but not the one you wanted
if you are using r style arcs... It could theoretically make an arc where ever you are.
or not the one that was programmed
skunkworks: consider +/- r. r arcs are not fully specified either
that's my point - unless you calculate the "original" arc, and the "arc from current position", and see if one is part of the other, you can't tell if you're on the programmed path or not
but the user didn't ask for the programmed path, he asked for starting on line NNN, where NNN is an arc that may be valid considering the current position
you could make THAT arc, and you can tell if it's valid by doing the math
this is what I mean by there-is-no-coherent-design
right, hence my argument that the control can't tell which it should do based on the math working or not working out
heh, ok, we agree
you can't hear my typing from there can you?
there's a train, so it's muted a bit
so our task, should we choose to accept it, is to try to come up with a coherent design
our second task would be to implement it
I must go home now, I will write on wiki my current go-to-line behavior
maybe its help a bit
one thing that may be coherent (not just for arcs) is to save the last position when the machine is stopped, and if it's restarted within DEADBAND or some user-settable amount, simplify the decision-making somehow
the interpreter does read and resync the current machine position sometimes
that's not a problem
my position is that RFL will simply never work
that would have to be combined with an integrator-set option regarding the start point of run-from-line (move to start and repeat entire move, or continue move from new position)
I didn't mean re-sync current pos with machine pos, I meant compare position at restart to saved position at stop
I have what I think is a coherent design. It is possible to implement it. It is fairly simple.
what we have now is simple too
it's just that the users don't like it
and certainly implementable
(I'm talking about more than just this issue regarding arcs)
1) when someone asks for run-from-line, ignore all lines in the file above that line, and run starting with that one. 2) allow mdi and manual "mode setup" to be preserved across mode changes so the operator can set modal stuff to make part 1 useful
if the line makes no sense (as it would with an improper arc), give the correct error
if it makes sense, but is wrong, then GIGO
and error if the line is inside any O-construct?
I don't think so
so the operator would load the tool, set the TLO, maybe move to a position, start the spindle, start the coolant, maybe set G90, set G20, then RFL
if I start a loop, and decide I want it to run longer, then I might want to stop, set the loop counter higher, and continue
jepler: you would run from the given line. If you meet an O-endloop without having seen a matching O-loop, you would give the appropriate error
but the O-LOOP would have been in the "previous run"
[14:07:52] <jepler> http://pastebin.ca/1180682
what does this mean?
you'd get a G0, then an abort with error "endsub without sub"
if you ROFL line 4, you'd get 'O100 subroutine not defined' or however it's spelled
you think users will like this implementation enough not to complain about it?
I can't predict that
I think it would work pretty decent for typical gcode
but more importantly, I don't think we can do better, I think it's nearly the only possible coherent design
(someone correct me if I'm wrong)
don't O calls now search the current file (and some subdir), or is that only in trunk?
I'm not sure
SWPadnos: beats me, but NO FUCKING WAY is a completely new ROFL implementation going into 2.2
ok, so we're talking TRUNK anyway then ;)
(the "O" is for "Operator"?)
Run Off, Fine Loser
nevermind., time for more coffee
"O" stands for "'O'nly letter that was not used yet"
that would be E
or is that ls ?
E is used in g76 I think
interesting. I think it wasn't a couple of years ago
I used all the remaining letters :-/
(we were discussing ellipses, and as luck would have it, E was available ;) )
beware that my proposed design won't give micges what he wants
machinery's handbook talks about an ellipse gcode, or is it a parabola? some of that silly stuff is in 274d
it should - it does it "right" half the time anyway
huh? no it doesn't
for micges' definition or "right"
no, he's mistaken, he thought it follows the arc, but it doesn't
it follows an arc though, at least when I tried it
ok, but to call the behavior "make any old arc" correct just means he is mistaken
so if you restart without moving, it will be pretty close to "the" arc
actually, it should be "the" arc
but it's not the arc the line of gcode asks for...
actually, it should be the rest of the arc the G-code asks for, if the machine hasn't moved
it's the arc the line of gcode asks for if it's run immediately after the previous line
hmmm. not when I ran it - at least that's not what I interpreted it as
lemme put up a screenshot
I'm not being clear
consider that a g3 command makes an arc from the current position with the center calculated incrementally from the current position
or if you move back to the position where you stopped before restarting, I think
if you stop in the middle of the arc, then run that same g3 command again, you get a different arc, probably an undefined one
oh, that's true isn't it
this is what I got: http://www.cncgear.com/images/arc-bug.png
in my proposed implementation you would get an error because the arc is invalid
yes you got "any old arc" which is clearly (to me) not the right behavior
just so I'm clear, how would you determine that the arc is invalid?
the interp does this (for IJ) by calculating the center incrementally from the start point, then comparing the start and end radii
invalid and incorrect are not synonyms here
(it must be doing something wrong currently)
the arc I got was valid but not correct
the arc you asked for should have been invalid
I do not know what you think the correct arc would have been
asked for by restarting, or asked for by entering it in the G-code?
specifically in micges's example where you jog off the path
I don't see a correct possible arc
all I see is an error condition
[14:25:24] <SWPadnos> http://www.cncgear.com/images/arcbug-top.png
it's mathematically correct
err - maybe it isn't after all. hmmm
would you define 'correct' please
I think I understand 'valid'
well - no, I won't define correct with that arc ;)
I'm trying to see how the center point was "found"
somewhere in the arc-representation shuffle it assumed some things that aren't so, and managed to come up with a valid arc
is there an environment variable you can set to get debug output?
like EMC_DEBUG=0xFFFFFFFF emc
file/set debug whatever, task issue
remember there are comments in the posemath arc code that imply it can represent spirals or some funky crap like that
it will do multi-turn non-axis-aligned helixes
so will TP
only gcode won't
I think it's using the programmed "previous endpoint" to get the arc center, rather than the actual position
(like lerman suggested)
ok, but it doesn't make an arc around that center (it can't -- there isn't one)
IMO, figuring out the exact implementation of the current bug is unimportant compared to designing what it should do
hmmm - no, I must be wrong, there's no way to get to the NW quadrant that way, and the arc clearly does that
I think they're both significant
depending on what we find, there may be a bugfix and a feature change here
as separate items
ok I see, we have different goals, you are interested in maybe changing this one behavior to make it a little better
yes, a 2.2-compatible bugfix, vs a 2.3-compatible functionality change
if there is one - I'm not convinced either way yet
EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: add item to quickref
[15:01:11] <jepler> http://emergent.unpy.net/files/sandbox/½
of what cradek wants.patch
amazingly, that URL works
not on IE of course
[15:12:43] <cradek> http://emergent.unpy.net/files/sandbox/%C2%BD%20of%20what%20cradek%20wants.patch
* skunkworks wonders how someone can digest the code that fast and spew out new code.
I think the key is to stop arguing and do it
but mostly he did it to prove that I didn't want what I said I wanted
(I do not think he succeeded)
I need the magic incantation to determine what the hal pins on ppmc are.
halcmd show pin ppmc
oops. I meant RTFM, bonehead!
From the beginning, please. Doing a halcmd loadrt.. tells me that rtapi error could not open shared memory...
oh, I thought you meant "when EMC was already running"
if you have a HAL file that loads the driver, then you should be able to use "halrun -i <yourfile.hal>"
though it may be -I, not -i
that will drop you into an interactive halcmd "shell"
(after starting the RT system and loading the hal file)
I always just start emc. if there's a bad line in the hal file, I comment it out to get emc to start
yep, that's a good way, especially because you can change connections around and see if they do what you want, then change the hal files to match
The more direct question is: For the ppmc driver what are the inverted input pins called. RTFM didn't work.
...in-not, like all the other drivers with digital I/O
if that's not what you get, then it should be considered a bug in the driver
Got it. halrun followed by the loadrt line followed by the show line. Ah. in-not NOT in.not Thanks.
is there a manpage for the hal_ppmc driver?
(can't tell since I'm on a non-RT system at the moment)
Yes. It is badly wrong.
It shows: (B I T) ppmc.<port>.in.<channel>.not
complain to your vendor!
oh, then that should be fixed
by your vendor! :)
Last time I looked, fixing a manual required the installation of additional tools.
if you verify what the right thing is, let me know what it is and I'll get it fixed in the manual.
bigjohnt would also be happy to do it
Finding the source is non-trivial. A suggestion: each of the manuals should have a section either at the beginning or as an appendix telling how to regenerate the manual and where the source is.
yes, editing the manual requires the version of lyx that comes with ubuntu 6.06 -- at the moment there's no effective way to edit the manual on 8.04 machines.
That way, any idiot (even me) could do that.
the source for the manuals is in an emc2 checkout, and it's built by 'make' when you --enable-build-documentation and have the appropriate tools.
theoretically, you could fix it with nano
but I think you'd go insane first
* BigJohnT :)
what am I doing jepler
the hal_ppmc section gives incorrent names for the inverted inputs
BigJohnT: making fixes to the manual suggested by others
they say "...in.not" when it should be "...in-not"
yeah if I read the source code right it's in-not (but out.invert, go figure!)
Lerman: is the error on the man page? I'm on a windoze machine...
I think it's in hal/drivers.lyx -- I'll go fix it now
ok thanks jepler
I don't think there's a ppmc manpage
no, I didn't see one in my source tree
yep I see it on hal/drivers.lyx
EMC: 03jepler 07TRUNK * 10emc2/docs/src/hal/drivers.lyx: fix ppmc pin naming error
EMC: 03jepler 07v2_2_branch * 10emc2/docs/src/hal/drivers.lyx: from branch: fix ppmc pin naming error
EMC: 03swpadnos 07TRUNK * 10emc2/src/hal/drivers/hal_ppmc.c: Fix pin naming of -invert input pins
hmmm. I'm insane now, looking at lyx code in nano
jepler, can you take out the comment about changing the name in a later version
SWPadnos: yeah, you should be using vim :)
I'm sure that would have helped
... me go insane sooner
EMC: 03jepler 07TRUNK * 10emc2/docs/src/hal/drivers.lyx: yay, swp fixed this
heh - thanks
ok, that's what I thought I had to do, but I couldn't check it
hmmm. I wonder if I fixed that wrong
the canonical input definition just says there's a "(bit) invert" parameter
err - output
or else those docs are wrong too
IMO everything should be like hal_parport -- in in-not out out-invert
while you guys are insane... what do you think of splitting the quick start part out of the Integrators manual and making a short "Getting Started" that can be downloaded from the web site
oh, then my fix is wrong, it doesn't do out-invert
it does blahblah.dout.##-invert
so parport doesn't match the online docs
well, the cods are ambiguous
[16:27:29] <SWPadnos> http://www.linuxcnc.org/docview/html//hal_general_ref.html#cha:Canonical-Device-Interfaces
the way I read it, the "base name" would be ppmc.#.dout.##.
to which you add out and invert for the pin and param
but it isn't really specific
(since of course we don't have a separate write function for each bit)
looking (randomly) at ax5214.h, the name is also mangled relative to the spec
ax5214h.#.in-##-not vs ax5214h.##.##.out-not (or something like that)
[17:14:09] <micges> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?RunFromLine
interesting, but still has failure modes
for instance, edit/reload the file and now the line numbers are screwed up (maybe far fetched, maybe not)
what may be nice would be to have a "continue" vs a "re-run" option when restarting
instead of having EMC try to figure out which one you wanted
"run from line" vs. "run from within line" :)
correction inserted read again :)
ok. I don't think that changes my suggestion though :)
there are a few options, which are kind of orthogonal to each other
1) restore state from the program or keep the state that was set up in MDI (or reset parts of it, like it does now by default, but I don't think that's too useful)
2) start the motion from where it was when stopped, or start the motion from the beginning (ie, from the prior endpoint)
there was a third, but I forgot it :
I hate it when that happens
ad 1. keep the state that was set up from mdi
oh - 3) use current endpoint or move to other start point (either the original programmed start or the stop point)
so technically item 2 has 3 options
ad 2. that could be settable by integrator(from begin for mills. from where was stopped for laser, waterjests)
that's your choice, I'm saying that the integrator or operator should have that choice - EMC shouldn't decide for them
maybe I'll send an email to the user list asking what behavior(s) are desirable
that would be cool
hey - off-topic question: you're somewhere between Kielce and Warsaw, right? (more or less)
200km from kielce and 220 from warsaw
ok. just wondering. my sister is probably going to a wedding in Olsztyn - wasn't sure how far away that is
200 km :P
also, I recently found velokraft in Krakow: http://www.velokraft.com/
very cool bikes
hmmm. I wonder what it would cost to do a jaunt from Germany to Krakow when I'm there next month
where in germany ?
Gottingen, so I could leave from Hamburg or Frankfurt easily, maybe Cologne/Dusseldorf too
I can take a train most of the way there - I'll have a Germany/Czech Republic rail pass
then trip to Krakow wouldn't be problem
have good connection with Germany
and with Czechy
heh, stepconf is used by a lot of people
two hundred bazillion
or at least two hundred
yeah, but most of them come up with pertinent feature requests
the problem is that by implementing them all, it will grow really huge
I don't think it's gotten too bloated yet, but the feature pminmo wants could make it get that way
I think that would require stepconf to load in the current settings from the ini file, which I believe it doesn't do at the momet
(it just checks md5 sums to see if the file has changed)
yeah, but it loads an xml
I'd like to help in some way, as it feels like I'm hooked on emc2 , but being such a novice at emc and linux I'm not sure how, except documentation. Even there somebody would need to direct me and check what I have done. I'm also really new to irc and that netiquitte as emc has lead me here. So if I can offer something of help, who, what, where....? Phil
hi pminmo, you can share with me the changes
you would have to be running 6.06 to edit any of the docs...
right now i'm in windoozs, but if I reboot I'm in 8.04
SWPadnos: can I slap 400 MB of stuff somewhere on dreamhost? A community college teacher is interested in a copy of my yggdrasil beta CD for a class project using vintage hardware.
pminmo: even knowing the docs and answering questions here is a big help
BigJohnT has read all of it and I'm amazed how many obscure questions he answers :-)
I can try to answer questions, but I learn each day what I thought I understood but didn't....
what are you trying to say cradek ?
that I appreciate what you do
so what do you think about ripping out the basic getting started from the integrators and making a short "Getting Started Guide"?
is that a question for me?
I have thought about how nice it would be if there would be a one-sheet-of-paper getting started guide. I've never written it because I know the shorter something is, the harder it is to write
I think it might take a sheet or two
one was my goal... maybe counting the back, but preferably not
anyway, I think it's a good idea, it would be less overwhelming.
my thought is if newbee could download a short pdf to guide them through the download, burn, install of the live cd it has to be better than 400 pages :)
for me, I didn't find Stepconf untill after I had spent hours tweaking the .ini and hal files
and perhaps the stepconf so they could get up and running asap
yikes, then we should fix that
pminmo: this is how you can help - you don't have to know all the details
but you can help with a new-user perspective
I have done that in the Quick Start section of the newer manuals
well they don't come much greener that I have
* BigJohnT is going home and Phil and I will work on the Getting Started Guide
if there is an emc for dummies i would resemble that....
think quality control
anyhow I'm off to the house now, I've made enough chips for the day
chow time bbl
EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/config/ini_config.lyx: add servo configuration
help tried to do a
./configure --enable-run-in-place --enable-build-documentation=pdf
checking installation prefix... /usr/local
checking for RT dir... Using /usr/realtime-2.6.24-16-rtai/bin/rtai-config as the RT signature
checking for location of kernel headers... using value from RTS: /usr/src/linux-headers-2.6.24-16-rtai
checking for cc version... found gcc in rtai-config
checking for gcc... gcc
checking for C compiler default output file name... configure: error: C compiler cannot create executables
See `config.log' for more details.
have you built (anything) on this machine before?
SWPadnos: I had Phil do a anon cvs checkout
I can put the logfile on pastebin if needed
the you need to run the following command:
apt-get build-dep emc2
presumably, you've already done `apt-get install emc2-dev`
then do both of those and run configure again :)
emc2-dev may not be needed, but what the heck
I'm not sure what else is needed to be able to build docs though, I think there are some additional dependencies
it's off doing the build now, thanks
fast connection there ;)
3M or 6M forget
must be cable with NetBoost or whatever they call it when they give you faster for a few minutes/seconds
is this going to build a different config of emc than what I got of the live cd and did an update on?
your doing a run in place
with pdf docs
you're also building TRUNK/pre-2.3, unless you did a CVS checkout of v2_2_branch
depends on what cvs incatation you did..
he did trunk
ok, so there will be some differences between the released 2.2.6 and the result of this build, in addition to being run-in-place
BigJohnT is driving, I'm just trying to hang on
remember to always source /your/build/location/emc2/scripts/emc-envrionment
you need to do that in any shell you want to use with the run-in-place version
SWPadnos: after the make he is just looking at the pdf's
ok, that's easier ;)
but they'll be slightly wrong for the installed version, I think
I'm still in my linux diapers
I don't know exactly where though
he will be current with me
remember to get the specific version of lyx if you want to do any editing