hello Afternoon Alex well.. my head is pretty near to exploding ;) likewise for John & Dave hello John... paul_c: did you take a look at my commit? hi jmk: I've commited some rework on make install actually we were going the wrong way (autoconf dirs & such...) it should be a lot simpler make puts stuff where they have been put so far and make install simply takes them from there and copies them to the proper dirs "proper dirs" being defined by install.map? I started fixing emc.run... but I stumbled over the following problem... what goes into emc.conf, hal.conf, rtapi.conf ? not much a little bit redefined but they are stated in install.map yes - install.map is an evolving document and I expect it to be changed a few more times... I expect that the .conf files will look like a highly simplified Makefile.inc RTMOD_DIR=something so... do these get modified during install? and perhaps a couple other lines yes the run-in-place one would say:L I agreed with paul that emc.run shouldn't get modified RTMOD_DIR=/rtlib the installed one would say: absolute paths? RTMOD_DIR=/lib/modules/{KVER}/hal for run-in-place no need to... I think or whatever ./configure decided was the proper place (absolute paths that is...) hi Why are we checking GCC twice ? because ;) first we check the kernel version from version.h with any gcc and later when we have that one we can check to see what gcc has been used to compile the rtai-modules I think... and why are we back to AC_PREREQ(2.13) ? beats me... are you talking about emc or emc2? emc2 autoconf branch * alex_joni thinks we need some naming standards for bash variables it's just a big letter-soup right now... Doing the same test twice (or any test) is daft. anyways... short question paul... is it possible to have some kind of #ifdef #endif in emc.conf ? that get's used with 'source emc.conf' from emc.run ? why? dunno - What is emc.conf used for ? like... ifdef LOCALRUN -> define folders ifdef INSTALLEDRUN -> define folders so when the emc.conf get's installed a INSTALLEDRUN=YES get's added * paul_c looks at the emc2/configs dir that's implied by the emc.conf that gets called Not another damned config ! we're talking about run-in-place vs. run installed (I think) if you execute /scripts/emc.run, you want it to use things from , if you execute an installed copy of emc.run, you want it to use installed stuff alex_joni: we may not need emc.conf, hal.conf, and rtapi.conf - there is probably some duplication there rtapi.conf has 90% of the info we need already * alex_joni3 had connection problems... what's the last thing you saw? hmmm... I talked about that I don't like sed from make install we didn't see that - last from you was "so when the emc.conf get's installed a INSTALLEDRUN=YES get's added" yup... I don't really think it's nice to have make install sed all the dirs it's much clearer if it's the same emc.conf with 2 sections and emc.run figures out that it's an installed or a run-in-place version but it still has to sed something - the INSTALLED variable or maybe 2 files one emc.conf.installed and emc.conf.rip emc.run knows what kind it runs... it needs to (because of finding emc.conf) take a look at scripts/rtapi.conf in the emc2 main branch yes note that there is _no_ rtapi.conf in cvs - it gets created from scratch when you do "make" that's what I've started with emc.run hmmm... that one would continue to exist in /scripts, and a new one would be created in /etc when you do make install I see... I would like to avoid ifdefs, because bash scripts aren't the only thing that will read the file C progs (like halcmd) might read it also ok... so we have 2 different files and the "if" would make the parsing harder one that stays in cvsroot/configs and one that gets installed in /etc/emc2 right? but bith contain the same stuff.. only dirs differ yes yes s/bith/both/ do they both get created by make? or by configure? both ways are possible the second would be created by make install how about if ./configure generates them both emc.conf and emc.conf.install and make install copies the later to /etc/emc2/emc.conf ? question: if you intend to install a prog in a non-default location (say /opt instead of /usr/local ), is the established method to specify that location at ./configure time, or at make install time? at ./configure ./configure --prefix= so basicly ./configure takes care of special dirs hello ray hi ray ok, then I guess having ./configure make both files sounds good Mornin, John. Hi Guys. today (emc2head), make makes the rtapi.conf file - I don't know if there was a reason for that doesn't seem to be any info in there that wasn't available at ./configure time well.. the only reason is that ./configure wasn't around when rtapi.conf has been written (at least not the autoconf ./configure) ok, I think I like .conf and .conf.install working on that right now we need a couple of snippets (C and bash) that can detect whether we're installed or not, and locate the appropriate .conf file(s) the realtime script contains a start on that (we were looking at it last night) I'll tackle the job for C (in halcmd.c) will tcl need it's own, or can it use the bash one? hmmm.. that extends beyond my tcl knowledge ;) mine too So just how many configs/ini/whatever files do we now have to run emc2 ? well... Could you explain the tcl need a bit more? emc.run is the run-script this has to do with run-in-place vs. installed which opens emc.conf and hal.conf (those exist for run-in-place and for installed) if you just did a cvs up (or untarred a tarball), then ./configure and make you have an emc2 that is compileed but not installed and that runs... if you run it, it needs to look in it's own directory tree for stuff, and ignore any previously installed emc2 once you install it, it needs to look in different places we're working out how to do that emc itself is no problem - emc.run will figure out if it's installed, and set env vars like EMC2_HOME, RTLIB_DIR, etc to point to the right places those will be available to tcl scripts started from within emc.run but if someone invokes a tcl script manually, they won't Now I start extra tcl stuff with a command from ~/emc the user's home directory? like plat/nonrealtime/bin/mini -- -ini sm.ini I've been building it there of late. the ~/ could be most anyplace and the result would be the same. ~ is always /home/, is it not? Sorry to confuse you. Try this ??/emc but what is ?? In a traditional emc1 case. /usr/local/emc is your startup directory jmk, paul_c: some values are used in emc.run (GREP, INSMOD, etc.) That is where you are running emc1 from. you must cd to /usr/local/emc before you can run it? those get discovered by ./configure I know not how you start emc2 as an installed system. you don should I change those values in emc.run ? or include them afterwards? you don't, yet.... we're designing that now it should be... ./configure make make install emc.run (from anywhere) In emc1 I'd cd to the directory that I want to start from ??/emc but we were trying to make it like any other program, you can start it from your own home directory, or wherever you wish emc.run will be in $PATH and the config files in /etc/emc2 you can still specify where other files get installed (prefix-style) right now it has been discussed that prefix is /usr/local/ makeing the user cd to the proper directory makes things easier - the whole "run-in-place In that case you would start an extra tcl script by passing it the name of the config in /etc vs "installed" issue goes away But you can create some ownership issues. so stuff go into /usr/local/bin, lib, etc... but you can always ./configure --prefix=/opt/emc (and stuff gets installed to /opt/emc/bin, lib, etc) I need to learn more about tcl tcl will start from anywhere you must bear in mind that the kernel modules should go to /lib/modules/KVER/foo (where foo is emc, or hal or something else- not 100%decided yet) at least that would be the proper way to do it But you would need to point you tickle script to a good version of emcsh. should be in $PATH Which you are compiling. The top three lines of tkemc points you to that location. exec bin/emcsh "$0" "$@" what exactly does that do? #!/bin/sh # the next line restarts using emcsh \ exec plat/UNKNOWN_PLAT/bin/emcsh "$0" "$@" Tickle begins by starting an interpreter. there could be a source emc.conf here plain vanilla tcl uses tclsh for a text based interpreter which includes the proper TCL_DIR and EMC2_BIN_DIR it uses wish for a graphical interpreter. would need to do more than just source the .conf, it would have to figure out which .conf We expand wish with the EMC specific commands emc_xxx yes... that too and name that file emcsh. does that mean that the first three lines are not really tcl, they are just plain ole shell script? #!/bin/sh so before restarting with emcsh... you can do a lot ;) Yes. And when tcl starts it re reads those three lines as comment. how does it know to skip only 3 lines? cause they have # in front or a \ at the end. the \ is a continue the last line with the next. so emcsh sees the 3rd line as a comment and /bin/sh doesn't Yes it does. Right on both. nice trick so in order to include more: #comment \ sh command if we had a 20 line snippet in there to find and source the appropriate *.conf, it might get ugly #comment 2\ sh command2 etc. I'd think it would be more efficient to work it the other way round. I have 4 lines to check for emc.conf During .configure you set the third line to match the current location. but it can be written on one line... :) not really... but that means configure must modify every tcl script ./configure gets run only once That is the way we run make now. I'd rather limit configure to changing only a couple .conf files and it doesn't know if the software runs-in-place or will be installed that's decided later (by make, make install) besides, if you modify a tcl script in the original cvs tree, then you'll have problems with later cvs up or commits the .conf files don't exist in cvs, so that avoids those problems We could parallel the way that tickle installs wish since it is an executable just like wish. if it's only a four line snippet, that isn't bad at all it can be fitted to 2 lines (readable) we can just use that as a standard "preamble" jmkasunich: That is the reason I prefer a packup script and then make elsewhere. we think we can avoid both the cvs problems, and the packup script ideally, you should be able to do a cvs checkout, or untar a source tarball, and from that point on everything is identical ./configure, make, make install and the source tarball is nothing more or less than a cvs tree with all the CVS directories ignored or a SRPM ;) alex_joni: does the snippet check to see if the variables (from .conf) are already defined? many times the tcl will be called from within emc.run, and the vars will be already set nope... it's the snippet from emc.run that checks for emc.conf sourcing emc.conf if it's already been run doesn't hurt anything, so I guess that's OK, just a little delay can you post the snippet here? hmm... I just looked ... forgot a few lines... it's the SCRIPT_DIR from scripts/realtime and after that EMC2_DIR=`echo $SCRIPT_DIR | sed s#/scripts##` if [-f $EMC2_DIR/configs/emc.conf] ; then source $EMC2_DIR/configs/emc.conf; elif [-f /etc/emc2/emc.conf] ; then source /etc/emc2/emc.conf; else echo "error, emc.conf not found"; exit -1; fi looks pretty good the sed used to back up from emc2/scripts to emc2 can probably be replaced with a /../ yes EMC2_DIR=`echo $SCRIPT_DIR/..` how would you copy the *.conf.install to /etc/emc2/ as *.conf ? the make install target would do that that's what I'm trying... not sure how to rename the files thou.. cp? or do you want to use install? gotta sed the extension... right? nope cp *.conf.install *.conf ? make install is running in the dir that contains the original, so do: cp foo.conf.install /etc/emc2/foo.conf one at the time? why not there's a maximum of three there is much to be said for trying to merge them into one ok... guess I was trying to make things look good when it's easier like this :D I was actually trying a for, sed the extension, etc... lol easier to read too you have to think about what the for/sed loop is doing yup * alex_joni is getting close there is one slight problem uh-oh emc.ini contains a reference to emc.nml the problem is? which was $EMCCONFDIR/emc.nml and got changed with sed when installing.. (me don't like that) emc.nml should be in the same dir as emc.ini... so simply emc.nml should be enough... trying now does the script cd to that dir? seems not... gotta do that how about $EMC2_DIR/etc/emc/nml? still.. you gotta sed it with make install why? because inivar knows nothing about $EMC2_DIR duh... you mean $EMCCONFDIR/emc.nml actually appears inside emc.ini? yes but I'll change emc.run it reads the NMLFILE and prepends the dir to the var doesn't seem to be helpfull point me at the problem: what line(s) in emc.ini and emc.run? let me commit first I did change a lot ;) ok on it's way.. got iy it * alex_joni doesn't get what gets done with $NMLFILE in emc.run line num? 209 I got it now... emc.run reads emc.ini but it's not the only one... emc.run, line 209? or some other file yes emc.run/line 209... sorry.. in autoconf it's 195-198 ok, that's better * jmkasunich was confused that stuff isn isn't quite right if the ini file specifies a nml file without a path, the path should be the same as the path to the ini not EMC2DIR/configs/ yes... but emc.nml isn't found because ... task? or whoever is run from path with absolute path to emc.ini damn - still have that "kernel source not configured" error here, so I can't run configure :( I think emc.run needs to split the ini file name into INI_PATH and INI_FILE then it can do INI_PATH/NML_FILE the problem is not with emc.run the problem comes from the c-sourcecode somewhere what C? emc.run doesn't do squat with NMLFILE it's not used ... emctask I think... The nml is set in the emc.ini milltaks as an executable yup and is read from milltask but emc.run is responsible for making sure the env var NMLFILE points to the right place no env is read from the sources AFAIK milltask (and others) read the inifile and parse it oh... so milltask gets the _name_ from the inifile, but doesn't know the path exactly because milltask is run from $PATH I'm not really sure how it found the path before... it was always run from the same place I just saw that NML_FILE is configs/emc.nml in emc.ini from the main emc2 branch I think a cd to the EMC2_CONFIG_DIR would resolve problems which works as long as you run from the main emc2 dir - doesn't work once installed resolve some, make others it does work if the user runs emc from his own home dir, where all his g-code files are, then IMO it should stay there, so when he goes to open a g-code file that's the directory he gets because EMC2_CONFIG_DIR is /etc/emc2 on installed systems * alex_joni had an idea what if we run the task program with parameters to the nml file sounds reasonable I'm afraid we might be getting bogged down in details and losing the big picture big picture: how do _all_ parts of emc find the things they need task needs a .nml file yup... my wife just got home, need to go for lunch back later ok.. I think I'll be gone tooo anybody around? wondering the same thing........ well... I am ;) jmk: around? guess not... well.. I got it so far: in order for milltask to find emc.nml (extracted from emc.ini) it needs to be run from that dir (where emc.ini is $EMC2_CONFIG_DIR), and this works... but... tkemc.tcl also needs some adjustments 1. find emcsh (done already.. /bin/sh checks for EMC2_BIN_DIR from emc.conf and runs emcsh) 2. it includes some relative dirs (TCLBIN and TCLSCRIPTS), and I have no idea how I could change those... ok... gotta run... dinner time * alex_joni will be back later... I always thought a binary gui is better... but I'm not really sure ok, that's kind of part of the gui (callbacks), if i get your point I think for now the tcl stuff is quite ok yes well, that should be fairly easy to replace. i'm not asking you to do it, i'm only saying if i had a couple of week-ends off, i would do it :) ray henry wrote much of the GUI stuff - he is our GUI expert, and tcl is his language of choice Truth: There's never enough weekends for any project I might quote you on that one jmk: any minute now ;) ok... i'll let you know when i have some time :) after i've converted my mill (and lathe, maybe) to cnc, written all my private code, finished two earlier projects, and bought all christmas present :) I'll have some after Pinky and I take over the world ;) yipieee ? * alex_joni has finally got emc2 to run from the install dir Hm...5pm here...what time is in in the UK? bout 10pm I think hacked tkemc.tcl to use the env for the path well it's almost 00 here ;) sorry I had to disappear for so long (when the wife commands, I must obey) uk time: 21:55 Heheh...saw some great bumperstickers about marriage today... Hm...maybe I should work on emcplot3d myself...I'm using all G01 moves, with M62/M63, and I'd love to have a preview of the differences meep? Still, it'd be nice if M62/M63 would work with G00 hey robin meep!! * robin_z meeps Great, robin's turned into one of those mog-things from Final Fantasy meepity meepity meep coo, jmkasunich is fluent in meep! I only know the bad words so asdfqwega, did you find any lenses yet? Well, there's a couple ebay auctions, but I'm leary of them... pour quoi? No real specs on them, so I suspect they're windows, not lenses mee pity too 'k http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&category=7321&item=3848885384&rd=1&ssPageName=WDVW http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&category=294&item=5711623887&rd=1&ssPageName=WD1V try asking on alt.lasers ... ?? I don't have newsgroup access at the moment groups.google.com all the newsgroup access you need There's some places online, that have some lenses < $100 * alex_joni is getting a kilt... asdfqwega: what are m62/m63? Motion sync'd DI/O M62 turns a pin on at the beginning of a move M63 turns a pin off at the beginning of a move aha I imagine this has something to do with lasers with any cutting machine Works alot better than using M03/M05 are those something you have recently added? I don't see them in the spec at nist.gov yeah, those two 0.5" ones do look like windows ... pity all the ones I have err 'spare' have the usual fault for CO2 lenses ... robin_z: There's a meniscus lens, also on ebay ahh :) http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&category=1267&item=3848382856&rd=1&ssPageName=WDVW yeah .. 1.5" big one too are you in the US? The one that came with my laser is 1.1" Yes oh yeah .. I remember I thought sf was going to make it so anonymous cvs saw checkins immediately thta ones a 7.5" focla length ... they said they will... but AFAIK it didn't happen use a developer cvs I can confirm it didn't happen! well... developer is the way to go... do you have emc2 checked out? I had lots of fun today tryning to cut 3mm holes in 4mm plate cleanly ... me? I have had it off and on did you try the autoconf stuff? robin_z: is groups.google only web-based, or can I put that address into my news program? web only its a read-only srvice. cant post but it's one of the few where you can post can you? you can post if you register at least the last time I tried oh, I never knew that alex_joni: not since we were talking about it a week or so ago robin_z: I could probably get by with my 1.75" FL lens...but I definately need to change the nozzle to extend down towards the focal zone the 0.5" ones say something about 2.94 microns, which is a bit funny what kind of laser power are you guys talking about? well.. right now it should have some parts fixed about 20W make install mainly oh yeah, so you can!! 20W? what's that good for? can you even melt steel with it? :) I redid that part... hopefully zwisk won't be too mad ;) if it's only 20w, then loss in the window or lens isn't going to be much of an issue * robin_z has 1700w of CO2 and 800w of NdYag robin: I found out why my laser was so weak 20W is ok... you could ... ahhhmmm ... you could... ahmmmm... there must be something you can do ;) asdfqwega: why? but i think the 0.5" has coating specified for 2.94u, not 10.6u, i.e. not CO2 robin: Some bastard tucked a diode inside the head yes, you can melt many ceramics with it, but not metals... diode? what for? * andras has 270W of CO2 at work cradek: let me know if you try it out.. * andras has seen a ZnSe window melt I dont think you use ZnSe a 2.4u ... you can use pyrex at that sort of wavelenght ... My power is a neon sign transformer...and the diode was only letting it operate at half power Ive seen lots of ZnSe windows get damaged ... ahh ... yes, but why does the ebay auction say znse, but then 2.94u? btw, if these auctions are real and you get fairly good condition items, they are a bloody bargain hmmm ... also it says coating R=90% at balh so its an output coupler andras: the guy says they're labeled 2.05mm alex_joni: is there some tag I should use, or just `co emc2'? alex_joni: I am at my rtlinux machine now thickness could be around 2.05mm certainly not 2.05 mm dia either Edge thickness? output couplers? i thought these lasers use proper nichol prisms for that nah speciall coated windows don't think 90% is bad at all just a normal window i guess 90% reflection .... 10% pass through ... oh that's weird no, thats normal :) ok, this is not a window then at least not a normal one * asdfqwega is definately going to have to build a 50+ watt flowing CO2... no .. indeed its not a norma window .. its an output coupler .. looks like a window, passes only 10% ok but youre also right .. it is set up for 2.94u ... Oh...I was looking at the wrong auction :P adsf: do you have any idea how much a commercial CO2 laser costs? :) right .. 2.94u is Er:Yag erbium doped ... * asdfqwega wonders how hard it would be to take windows and figure them into lenses... used for .. surgical stuff, mainly bone drillign apparently asdfqwega: hard. small low power ones will be cheap enough I guess anyway robin: K's of $, and Yeah, I know nah yes, but they aren't good for much are they? :) asdf: our 270W laser at work cost UKP60k that's about $100k I menat small lenses ... Well, let me ask this: How much wattage is needed to cut 1/4" plate steel? of co2? or YAG? Hm...CO2 what wavelength does yag give you? lets say 600w of co2 minimum * asdfqwega falls down andras: 1.064u i agree. i can just about melt iron with 270W, focused Oh, wait...there's a laser welder someplace I know for $600... and that's without a vessel, i.e. little thermal conductivity yeah, 600 maybe on the low side ... I'll have to check the wattage 1.064u? so you'd probably even need more power, right? no, less why is that? absorbed 2 to 3x as efficently as 10.64u co2 short wavelengths have more energy,and better coupling? oh * robin_z nods and ... no, that's nothing to do with that asdf you get a 'waveguide' effect in molten steel at 1.064 ah, that's an important point my yag will cut 10mm ok and ... :) Ah, I remember reading about that years ago and it goes down a fibre optic :) no mirrors, no alignment problems :) Heh ah, that's very convenient and safe yeah :) So YAG would probably be my choice, later on :) yip mcuh easier to build than a co2 my mat built a 400w YAG from bits and pieces s/mat/mate/ btw, you don't need to worry too much about safety... when the infrared beam hits your eye, everything goes dark, so there is no way of missing that moment :) Oooo it stays dark after that, of course * robin_z nods my mate doesnt wear safety goggles when spraying laser about .. reckon if a kw of co2 hits you, goggles aint going to save you :) anyway .. enough laser talk, or I'll get told off for distracting the channel;) * robin_z shuts up good day/evening gents hello! I'm wondering if anyone has any experience on PID tuning on a yaskawa set with EMC? im not really a PID expert ... what yaskawa? SDGA servopack I know very little about PID tuning ... the tiny bit I have done was not on EMC, basically all I did was monitor the correction signal and apply impulses ( that is hit it! ) and tune for minimum overshoot and steepest slope ... EMC has some rather weird values for PID, I never really got to understand ti . it inetresting...prob is that the servopack has internal PID and so does EMC. might get tricky.. oh. hmmm. so waht exactly does the servopac need as an input? dc voltage? ie as a control input nope ac 220V I mean how do you tell it what position to go to? sorry yes -+10VDC and it has internal PID? yup, all digital weird ... so the encoder goes to EMC, emc then goes to +-10 ? usually +-10V is for velocity correct ... and it could have a tacho... but not PID thats why I dont understand ... I might be wrong thou do you think antimatter could have any affect? possibly ... Murphy has a bag full. if the encoder went to the servo drive, then it could have PID, but if the encoder goes to EMC, I dont see how you can do PID without an encoder going into the drive ... the encoder goes to the amp then to emc, emc outputs +-10v for looks and so .. I tried running with an encoder going to the servo (in my case a gecko for DC) and to emc (with my read-out board) and? uh huh, but then EMC is not closing the loop it does +- goes back to the amp. well, I dont understand at all ... surely the drive must know where its supposed to be going to do PID? no ...?? well.. it didn't work really well.. finally I switched emc back to freqmod and let the gecko to do the stuff.. if it was a didgital drive, where you sent a digital command "go to here, at this speed' then I would understand it ... but right now, I cant understand what the loop looks like ... to do PID, you need to know where you are, and where you are trying to get to ... and where you were e.g. how you moved lately well yes, velocity and position * robin_z nods so ... and accel and derivate of accel ... to do PID the drive would have to be told where it is supposed to be going to ... yup the loop is simple encover goes to amp, amd send the encover signal to the emc, emc sends +-v to correct the velocity loop.. and it should know where it is going (e.g. encoder conected to it) yup...encover goes trough the amp to the emc.. I see... ottos: so how does the drive discover the destination position from the +-10v control signal??? the amp uses encoder only to tune the speed like an tacho only digitally I think so.. are these AC servos? yup right. and it's encoder? so its using the encoder to commutate the motor look like it... not resolver? where do you connect it? but you dont need a PID loop to commutate the motor ... STG? * robin_z needs beer Vital indeed so. beer is vital. robin_z: how much blood do you have in your beer ? American historical quote: "Beer is a sign that God loves us, and wants us to prosper." Guess who? Ben Franklin hello again alex_joni cradek: shoot not me :-) BANG! ok, sorry wasn't me ;) things like iosh that make no sense for the user to run at the shell should not be in the user's path they should be in a libexec directory IMHO sure... complicate it even more... lol * alex_joni is actually open to suggestions... * robin_z prods picnet well.. problem is they can go in emc2/bin with all the other bins first it was done the autoconf way with all those bindir libdir, fsckdir there were at least 10 a nightmare ;) doesn't really fit to emc I though the following way: everything should go in /usr/local/emc/ (bin, lib, doc, etc...) is there a real fit problem (more than any other app would have, and exclusive to emc), or is it just different fromw hat we're used to? I think it's at least partly real I see where it's a little nasty to have them spread around a lot different.. not more not less, just not compatible not without breaking the run-in-place what if they were named like /usr/local/libexec/emc-iosh that's ok too can be done autoconf was written with "normal programs" in mind, most normal programs don't generate kernel modules then they would at least be identifiable jmkasunich: completely true well... I wasted some hours with john yesterday to figure this out jmkasunich: why not put the kernel modules in /lib/modules/.../misc and let the normal depmod/modprobe mechanism handle it? that's where they get installed right now ack, sorry if I'm coming into this late no problem it's never too late (maybe when it's on a LIVE-cd...) cradek: hal modules aren't normal kernel modules either since they really contain code that will be executed by the RTOS, not the normal kernel I see we are planning on putting them in the /lib/modules tree they go there already!!! probably /lib/modules/.../hal but only after make install ;) right - before install they are in /rtlib and they gotta stay there for run-in-place yes modprobe and depmod only work if things are in the /lib/modules tree I didn't like putting all bins to ${prefix}/bin either if ${prefix} is /usr/local but insmod can be given a path to the module, wherever it is ok... guys... I'll leave it up to you... I'm wasted it's 1 am again :D goodnight! goodnight gotta work tomorrow.. ugh keep me posted thanks for all your work, this is tough stuff I wish I could be more usefull well.. I am glad to be helpfull you have done a LOT (more than enough) already anyways... could you send me an email with the rest of the discussion? seems that my logger died .. (may he rest in pieces) ok thanks... mine died too, part way thru, but I restarted don't know how much I missed without more lurking/research I don't think I know enough about this to have a strong opinion you should get together with paul too.. if he comes in again (probably not...) thing is... some stuff is clear (and agreed) sure like: 1. modules go to /lib/modules/.../hal 2. conf stuff goes to /etc/emc2 agree 100% 3. man goes to mandir 4. bin btw... I forgot --prefix ./configure --prefix= some dirs are relative to prefix yeah $PREFIX/etc/emc2 I assume not really conf can be in /etc/emc2 no more headaches ok (no strong opinion) configs are one of the ones that are _not_ relative to $PREFIX because when you run emc.run.. you need to find some of those files I guess it's "fallen out of style" to user /usr/local/etc and if they are relative to something you don't know... but make install would put that in emc.run waitaminnit! nope make install doesn't alter emc.run ;) just thought of something! make install simply cp stuff shoot... alex_joni: but it could cradek: it has... we have a snippet in emc.run (and eventually other scripts) that looks for a foo.conf relative to where the script is located but it doesn't anymore if it doesn't find it, it uses /etc/emc2/foo.conf jmk: yes.. so far why don't we simply _always_ have the foo.conf in the same place relative to the script ? because... same code is in tkemc.tcl right now now put the confs relative to the tcl dir tcl is in /usr/local/share/emc2/tcl and in cvsroot/tcl confs in cvsroot/configs * alex_joni really likes /etc/emc2.. it simplyfies the hell out of things but does it really? sure does if a script, or tcl prog, or C prog, can find foo.conf using relative paths before install, why can't it do exactly the same thing after install? it still can lets say you run emc.run from the cvsroot/ not scripts/emc.run * alex_joni slaps himself... relative paths are on the script executed :( It shows that I'm tired... right - not on your current directory, but on the location of the script itself if I run emc.run (actually /usr/bin/emc.run) yup.. anyways... /etc/emc2 is more easy on the user so it doesn't matter where you are when you issue the command, the command can use $0 to find out where _it_ is, and look for foo.conf relative to that location yes.. we're doing that for run-in-place, but then if we're installed, we do something different (/etc/emc2) why not do them both the same? well.. you might think it's more simple but it's not at least I'm not seeing it right now as simpler don't think you can have the same realtive dir on the install location if it's $PREFIX/bin and $PREFIX/etc, sure you can but it's not ... look at install.map and directory.map you can check out also the install target from cvsroot/Makefile I really am leaving now ... bye ok goodnight goodnight let me know how this ended n8 it will probably end right now that seems likely I feel rotten saying "what if!?" after all his work my only beef was stuff that makes no sense for the user to run by itself (like iosh), in /usr/local/bin and inivar and maybe others, I don't know what most of these are those should not be in the path if they aren't things that are meant to be run by the human the current plan (per our discussions last night) was for all executables and scripts to go into /usr/local/emc/bin (actually $prefix/emc/bin) and put symlinks in /usr/local/bin only for those that should be in the users $PATH don't know what others think of that idea ahh, it must be that install.map is out of date * paul_c thinks symlinks are not nice.... hi paul! Yo install.map isn't out of date, it's up-to-date'er than it was last night (the symlink thing was in there last night, looks like alex removed it) I have to say I don't care for that usage of symlinks either hi paul! Hi Tom you know, to be honest, I don't know enough about linux conventions to intelligently contribute to this - I just want to write realtime code I sent an email last night, to tell you about the "NCF" signs at first glance the only symlinks in my path are used for "this is a historical or alternate name for a program that is now called XXX" * asdfqwega is used to things going into /usr/* or /usr/local/* I am a realtime newbie but am an old unix administrator on many: sysv, bsd, linux. I'm the exact opposite - I've been doing embedded stuff for a couple decades, *nix for a year and a half I've seen the good, the bad, and the ugly (HP-UX) * paul_c checks the filtered emails.... I should ignore this autoconf stuff and focus on the hal refactor and writing drivers we're probably a good match then. I hope I'm not speaking out of turn, but I've noticed that on teams this size people tend to overemphasize consensus. Sometimes it's better to realize there are several right ways, and we should divide up the work and trust people to make *one* of the right decisions. in reflecting this, I'm a little sorry I opened my mouth about pathnames... you have a point there are only a few things I care about relative to the autoconf system: for instance I'd rather see /usr/local/etc/emc2. But if it's in /etc/emc2, who cares? Either is "right". did I miss a punch up ? paul_c: not at all, just that we all have different ideas and we're probably all right. 1) need to be able to run in place after a compile without doing an install (good for testing a new version, for instance) 1) agree 100% and that we're going around and around and around on the same details 2) I want rtapi and hal to be usable by themselves, without emc proper Just keep in mind somebody, somewhere, much later from now...is going to be reading your code and laughing/swearing/crying 3) should probably have been #1 - things need to be _documented_ * asdfqwega shuts up not every potential developer knows about autoconf (nor should they need to) we should have docs that let someone like me (knows little about linux) to add a module "cookbook" style A competent C programmer should be able to read docs and contribute As long as the sources (configure.in or plain old C) have plenty of comments right, it would be nice if a programmer could jump in, fix a bug, send a patch, and be done - no big investment in a learning curve, etc. even autoconf becomes understandable.. what does configure.in mean to a C programmer? "there be demons here" 'pends if they are grounded in *nix exactly not only that, but working on open source projects many folks with the embedded/realtime skills are not neccessarily grounded in *nix I've administered unix for years and run a build environment for a huge commercial project, and have never written a configure.in look at the comments in Make.rules those were written for the former (non autoconf) build system, and they assume little or no *nix experience (cause I wrote 'em, and I didn't have the experience - I was writing about it as I learned it) Much of the advice I have seen relating to autoconf is to "borrow" an existing configure.in which leads to a lot of unnecessary tests/cruft "checking sizeof char... 1!" I've seen this, I swear For our needs, it is not rocket science talk about cruft yeah - multi-minute runtimes for ./configure and much of the work has been done by the RT config then a 30 second "make all" ;-) I'm hungry guys, time for me to go too I'll be around during the week to throw more sabots into the machinery. WTH... emc-commit is bouncing my SF account.