hello hi ray hi paul Hi Folks Hi all Hi Guys. * rayh was away drawing cad. paul_c: seen the last commit on configure.in? hi ray and all hi les How is the configuration stuff coming along? slowly... ;) hey emc is getting a workout down here... customer liked initial production of the turkey calls and ordered another 500 Alex, is emc2 working at the moment ? I don't recall that it wasn't working... but depends on what you mean by working .. *g* les: That's great. have a basic linux question though... if it is compiling for example :-) well.. all I've done is in a sepparate branch.. so main branch for emc2 isn't touched perhaps you could try it out? I could need some testing... les: Someone here can help with Linux. ok then i make a update of my copy, because i have a problem with my servo code at the moment. if i call it with the stepper ini-file it is running, but with my servo ini not ray: I modified emcmot.c and emcsegmot.c and recompiled for the Ferror fix (which works) and recompiled but... the machine is not networked and has no cdrom burner I need to get that tarball off the machine is there any other way than untarring , copy to floppy, and taring in another machine? Certainly. If you want to compress them before putting them on the floppy. tar czvf mytar.tgz (add each file name) (or directory) it can (compress) copy a single large file across multiple floppies? Then mount the floppy and drag mytar.tgz to it. What is the single large file? just emc.tgz would need to pipe the output through split I think we need to discuss directories in emc2... You want to tar the whole emc. ok I will study the split thing...thanks Yep split will do it. Get you that command in a minute. alex_joni: Which directories had you in mind ? alex_joni: about directorys, a suggestion about some month ago was to make a directory per driver in ..../hal/drivers split -b 1400k (sourcefilename) (destfilename) I was thinking about BIN_DIR, LIB_DIR, INC_DIR, etc thanks ray Split will name them destfilename.aaa .bbb .ccc and such. i wanted to write a driver vor a heidenhain counter card, i think for this one i have more than one source file, so it is also good to have a own directory paul_c: I got emc2 to compile with autoconf generated ./configure but RT-stuff needs some more work... alex_joni: That's great stuff. especially rtlinux stuff, as I can't test it.. did you see my comment about the compiler ? yup would also suggest aborting if the search finds more than one RT signature alex: Why were you thinking of BIN_DIR, LIB_DIR, INC_DIR, etc well... right noe everything is in emc2/ right now ;) Ray: Had a visit from Paul Hamler (who has been up your way) last week what a craftsman I am setting up emc for him les: Isn't he terrific. He sent me some engravings a while back. autoconf can produce (and this is the usual way for autoconf) $srcdir, $bindir, $builddir, etc... that functional 7" tall Bridgeport blew me away les: What kind of machine is he wanting help with. and these get written to the Makefile as such so that later from make (or make install) the default path's can be changed.. something for drag type engraving les: That is what he sent me. I need a second cnc in the shop as well so we will set up both machines couple of series II will work... les: Fantastic. Glad that you guys got together. He built a new big shop quite close to here I've got a series 2 sized machine, converted moog hydropoint if you need it and have a way to get it there before winter gets to deep. alex_joni: So the directories you want to name will be post make but whereever the emc2 source is located. and from there they may be moved about the file system by make install? something like that hmm...I am looking around but of course distance is a big issue src and include-dir's are only needed for compiling and can be in emc2_home but there is a need for a install_dir or package_dir I never want to drive over the mountains wil a truck load of machine tools again! :) Hi John to build .tar.gz or rpm Hi John I think I understand now. Be good to get JohnK's opinions on names for these. not only opinion on names... ;) maybe some help too :) * jmkasunich needs to come up to speed Imperator_: What would be wrong with .../emc2/drivers/heiden (and wake up - went to bed at 4:30am) I need some help from the emc1 experts rayh: what do you mean exactly ? how do you do a build given a fresh cvs checkout? I need a script that does the build and returns success or failure Imperator_: Are you working in emc1 or 2. (can be customized for the system if needed, ie. PLAT=whatever) compile_bditng is included in emc-1.0.0.tar.gz need one that works from a cvs checkout probably make PLAT=foo it shoudl work... you need to edit it, and adjust your PLAT's Rayh: EMC2 I'll take a look here's why I need it: http://www.linuxcnc.org/compile_farm/ there are 2 of them REALTIMEPLAT= and NONREALTIMEPLAT= NICE !!!! I've been talking about doing that for well over a year ;) did you read about the autoconf branch? yeah the scripts I have for the farm can do branches as well I will have it testing emc2-head, emc2-lathe-fork, and emc2-autotools eventually I hope autotools fork won't be around very long ;) jmkasunich: I see a directory emc2/src/hal/drivers. Would it be appropriate to add a subdirectory there for specific sets of hardware like ppmc or Imperator's Heidenhain card stuff? but I want to get rcslib and emc working I suppose to date the drivers are all single files, seems like a directory with only one file in it is kinda over-the-top ;) even a "big" driver is probably less than 5 files, isn't it? jep, john Right. But Imperator wants several Heidenhein files. I have no real objection to it... there will be a lot of little makefiles though separate directories might help the "compile only the drivers I need" thing Yes there will. Would that make it easier to skip a set of drivers like I got you steamed about the other day. ;) but i was thinking on the time i was trying to write a driver for emc1. specialy the makefile is terrible. I think with sub directorys that cannot happen rayh: skipping drivers isn't what got me steamed Oh. Sorry. s'ok Wanna talk about that after a bit. but a make config would be really something ;) can anybody talk about mathtest.c ? mybe we can make subdirectorys for sets of drivers, for example one for steppers, one for allinone_servocards like STG or my siemens-card, and a subdirectory for special cards, like the countercard of alex ... btw.. I have a IO board for PC104 done. (schematics at least...) : 16 In, 16 Out nice mybe we can open a page on linuxcnc.org with open hardware i can add my PCI card if it is running but that is a long way :-) Directory per I/O device makes for better control, less uncertainty of what goes with what. Not sure it is worth the overhead in make process. What about a place for user manuals etc. for new I/O devices? there is emc2/docs could add some subdirs there? emc2/docs/hardware ? parport, specific drivers, etc.. ? emc2/docs/drivers may be more appropriate well the parport driver is documented in hal_introduction.pdf Why not make a subdir in documents? and I was planning on putting all the driver docs in there a big book about hal, not bad. But then you have to rename it sometimes something other than "introducton" you mean? jep, even now it is more then a introduction ! btw. great document John I thought "a place for user manuals etc" rather than the kinds of technical stuff, man pages and such. Ok, summery: we don't make subdirectorys in hal/drivers, or but if the makefile is lok like the one in EMC1 we talk again :-) we could switch to automake ... :) what is the diff between automake and autoconf? autoconf takes a configure.in and creates a ./configure file automake takes Makefile.am and produces Makefile's for autoconf you still write your own makefiles? Makefile is not touched I think I like it that way all is touched right now is Makefile.inc you are strictly doing autoconf, right? not automake? which is created from Makefile.inc.in when ./configure is run only autoconf good very small step ;) small steps are good * jmkasunich senses a lull in the action I think I'm gonna KVM away for a bit, try to get rcslib and emc working on the farm maybe you could check it out ... the branch I mean .. when you get the time once rcslib and emc are working, I intend to do just that ok.. I'll commit some more till then dammit... rcslib doesn't even have a README or INSTALL how are you supposed to compile this bastard? cd $RCSLIB_MAIN_DIR/src make HAVE_RTLINUX=1 PLAT=$NONREALTIMEPLAT RCSLIB_MAIN_DIR=$RCSLIB_MAIN_DIR RCS_INSTALL_DIR=$RCSLIB_INSTALL_DIR make_dirs headers depend all * jmkasunich scribbles maybe HAVE_RTAI=1 ;) if that's more appropiate make HAVE_RTAI=1 PLAT=$REALTIMEPLAT RCSLIB_MAIN_DIR=$RCSLIB_MAIN_DIR RCS_INSTALL_DIR=$RCSLIB_INSTALL_DIR make_dirs headers depend all what is $NONREALTIMEPLAT? usually I have PLAT=linux-2.4.21 or whatever kernel you have sorry :( ok PLAT=linux_2_4_21 long time ;) but you have to make sure there is a .def for your kernel in rcslib/etc/ e.g. linux_2_4_21.def assume I did the checkout into ~/farm/rcslib, and I'm in that directory if you are there, it is a wise thing to check the following scripts: For a live compile, you'll need Paul's rtai.def and linux_rtai.def rather than the ones in the repository. ./linuxkerneldir ./linuxdir ./rtaidir damn... I can't scribble fast enough ./have_rtai.sh so: ~/farm/rcslib/etc/ contains most def's if i start EMC2 with my servo.ini file, i got with my fresh copy of EMC2 the error ./scripts/emc.run: [: 1: unary operator expected how can i find out what is wrong ?? Imperator_ is your code on cvs? servo.ini ? rayh: does that mean a fresh, unmodified CVS checkout will never compile on a Live box unless you modify/replace those .defs? not the ini files is it a good idea to commit them also ? not your personal inis that's John call... the committed ones are generic we need to discuss how to deal with sample ini's maybe put them on linuxcnc.org/inis my thoughts are that users shouldn't modify emc.ini, instead they should make a copy with a new name, like "mylathe" or "gantrymill" or whatever, and customize that or maybe include their specific code... the ones in the repository should serve as examples and leave emc.ini as a standard... i talk about servo.ini and core_servo.hal Right now emc.ini is a basic servo with bridgeport task and io for emc2? that's emc1 generic is a basic stepper with mini task and io. emc2's emc.ini is stepper DAMN! and it doesn't have a generic.ini jmk: maybe name them emc2.ini ? * rayh goes for coffee and a valium. * jmkasunich wonders if emc.ini should go away I like imperator's idea of servo.ini (maybe) btw... I found my favorite error so far ... mybe servo_evoreg.ini error: cannot find myself; rerun with an absolute path LOL the thing is - ini files and hal files and all the rest of the config are _SPECIFIC_ to the unique machine that you are building ANY ini files in the CVS are there ONLY as examples, or as bases for machine integrators to build on In absolute terms you are correct. For for the first time a newbee installs, it is really nice to be able to say, "issue ./generic.run in /usr/local/emc and a system will start up. a system that may or may not match his hardware maybe a system with no hardware ... seems to me, if you want something to start with no configuration at all, it should have simulated motors and no real drivers exactly my point I like the idea that the generic.ini would start up a simulated machine. That will always work and is safe. when it's time to help the newbie deal with hardware, you ask him "stepper, servos?" etc. and point him at one of several sample ini's (none of which are called emc.ini or generic.ini - use descriptive names) stepper.ini :D the newbie instructions should also tell him to copy the chosen file(s) to new names before he starts further customization maybe a script to do that? get input from newbie copy initial .ini in fact I would recommend that the sample ini's be installed with read only permissions halgui could help there ... in the long run, that would be a great place for a somewhat intelligent configiurator Hell most newbees I know don't even know how to copy a file from here to there. This whole thing is just going to frustrate that person. go... halgui click'n'point Aunt Tillie is yelling in my ear here. drag a stepper ;) rayh: you gotta be shitting me how the hell do they edit an ini? Nope. Notabit. well... ini's should be made by integrators... and they should be able to copy files :-? unfortunately some integrators (hobbiests) are the end users, and they can be pretty clueless s/some/most/ If it even takes a day before a first timer can start and see a working CNC, we'll loose half of them. I knew Aunt Tillie would get her foot back in the door... 8-) if they have a completely "standard" setup (hardware, pinouts, etc) then they can use a copy of one of the sample ini's (or use the sample itself) She's a bitch, isn't she! Right, John. And generic did just that. You needed no machine to see it run. for one specific setup - not generic at all... you said "start and see a working CNC" The problem with Steve's suggestion about sim is that sim requires no working rt. Perhaps the "simulated" machine in the generic.ini could acutally spawn a screen window and show the "machine" on the screen. That at least would give the newbie the feeling that EMC was running. did you mean a GUI on the screen (sim) or a working CNC as in moving table? So a guy sees sim run and thinks he got a system. rayh: emc1 again emc2 has no "sim" as in "no realtime needed" instead it would have a "sim" as in "hal modules simulating motors" but it would be realtime Yes. But us guys who provide "help" will have one more ifdef to sort through. emc1 vs emc2 is gonna be one hell of an ifdef - there's no doubt about that but that's the whole reason behind a clean break But 2 will get to the point where a newbee should be able to start it and see it run. Or it will not get to the point of acceptance with the noby retrofitter crowd. oops. fat fingers and falling behind. the present emc2 version of emc.ini is a stepper machine, similar to generic and it will run with no hardware about the error i have, it happens exactly after motmod is loaded, and modmot is the only module which will be loaded ? the error was ./scripts/emc.run: [: 1: unary operator expected how can i debug it ? my head is spinning do you have any idea where in the run script it is crashing? Imperator_ send me the ini files me too I'll dig into it jmk.. you have better things to do ;) ok but if you insist :P that's a bashy error message back to newbies and inis in the ideal world, we'de have something (GUI or not) that walks a clueless newbie machine configurator thru setting up his very own ini and hal files Having a stepper implemntation double as a simulated machine appeals to me. It would still be nice to have visual feedback that it was running even if no hardware was attached. at the same time, such babysitting could be easily bypassed by someone who wants to use the real tools that's what we have now in the long run, we could make a true simulation Imperator_: say when the files are on their way... but not a high priority I was referring to another window that showed the simulated machine AS DRIVEN by the parallel port. you have mail that could be done... hal supports user space access of HAL variables... so a GUI could draw a machine and read axis.0.position-cmd from the HAL to make it move kinda like backployt ployt ;-) Yes but looking more like a physical machine. right that's a project for somebody who does opengl or something nice ... Tickle could easily do that as well. unfortunately tickle has no hooks into the HAL (yet) Dave Anderson had an animated graphic machine throwing chips that ran the first year I was at NAMES Imperator_: you are using an old version of the ini file (from before I added the "loadrt" command to halcmd, and disposed of RTMODn, RTMODCFGn_ if you want to keep using the old script, then you must have a RTMODCFGn for every RTMODn - that's probably your bug Tangent to the newbee discussion, where were we thinking of putting all of those example ini files. I would recommend getting a current checkout and moving your realtime modules to the .hal file (use loadrt - see stepper_core.hal) emc2/configs? emc2/configs/samples? Then how about emc/configs/samples as well. up to you Just trying to make things match as much as possible. ok, john i have to check this changing the old to match the new isn't neccessarily a good thing the old is known and understood by many people, warts and all the new is a clean break, we hope to fix some warts So where possible lets make the new match the old. removing the same warts from the old will confuse those who have become accustomed to them Change your emc.ini and make a generic. but keeping warts on the new just to match the old doesn't make sense how about sim.ini Just told you why not sim ? I'd vote stepper.ini before that but we already have one of those that is pretty specialized. already have? in 1 you mean? Yep. In 1 sim is a nonrealtime setup. we're so far apart in how we see things that we aren't communicating One of the issues that we had with "Kim" a while back was sim worked for him and he couldn't understand why he didn't get sigs from a real emc His problem was that rt wasn't working at all. I view 2 as a complete break from the old - nothing is sacred - we should decide what is best for folks who have never seen either the old or the new, as if emc1 never existed. We certainly can draw much good from emc1, but compatibility or even similarity isn't real high on my priority list for emc2, there is no such thing as a non-realtime sim And I'm thinking of a transitional help line and trying to get folk to figure out what the hell they need to do next. Just to clear the air a bit, I am in the clean break camp. Hard decision, but we are steadily falling behind Mach2 and I feel effort should concentrate on getting EMC2 to be the system recommended to newbies. There is no reason that I can see why we should not make as much operational similarity between them as we possibly can. operational similarity will be there, simply because they use the same GUI install and config similarity not so much Bull s&^%. Youre already changing 274 for new tkemc is completely unchanged for emc2 same buttons, etc changes to the g-code interp? You do stuff at whim without any consideration of the work of NIST or any of the emc developers. Now I;'m steamed. * rayh takes a walk. * alex_joni is puzzled Ray gets the unplesant task of being the default support for newbies due to his long presence working with EMC. As such he get to see many things that other developers do not encounter. I know Answering for alex_joni... I have no problem with Ray telling them "I don't know anything about emc2, talk to John" but I strongly feel that design decisions on emc2 should be made based on "what is the best we can possibly do", not "what is similar to emc1" sometimes the best will be the same or similar to emc1 other times it won't I certainly don't want to make those decisions single handedly Like with the autoconfig stuff, heated debate is good. Not fun, but it exposes us all to more ideas and feelings. The more opinions expressed, the better the potential end product. I dunnot what the Ray's comment about changing 274 was about... I haven't touched the interpreter well... discussion is ok ;) a lot better than nothing at all jmk: sis you get my mail the other day? did s/sis/did which mail? I have 276 this week ;-( * paul_c hacked the interpreter... But it is still the same code.. * Imperator_ my servo is running again, thanks for the help you're welcome ;) :-) well.. I was playing with hal lately oh, that one I ran a stepper withstepping type=5 and I was wondering about a ./halcmd flush I sent a reply - did you get it? * jmkasunich looks in sent mail sent on 10/15, want me to resend? (you probably have 200+ emails too) sure had.. now I have 0- :D please resend on the way * rayh coffee worked valium didn't. Will try xanax;) my points exactly... Over time, I expect emc2 to BE emc. In the mean time, once 2 gets near the working a machine stage, there will be a great deal of overlap in applications. Some will try both with the same machine. rayh: What is/was the issue with the rs274ngc interp ? They will want help that works. Not a "get ahold of John." Not only that, John does not want to deal with the 100 or so help requests that I get each wee. week. not really... but if the choice is between making suboptimal choices for emc2 to remain similar to emc1, or handling the support, I choose the support I don't give a flying rats ass if we are falling behind some other brand -- what I care about is that we are moving toward a target that is more capable than we are now. I don't claim to be able to make the optimal choices alone, and I don't want to I don't see how the naming of an ini file makes one system less optimal this isn't about the name of one file Making the same named file do a similar thing is much more valuable to me as a help provider. is there a sim.ini in emc1? Hey I'm all for moving all the system ini and run files to a new subdirectory. the base is much to cluttered now. there is a sim.ini in emc1 emc.ini minitetra.ini rtsim.ini univpwm.ini generic.ini ppmc.ini sim.ini univstep.ini lukas.ini rs274ngc_new_sim.ini stepper.ini vital.ini then I retract my suggestion to call it sim.ini I was specifically looking for a name that did NOT have a previous meaning generic does emc does emc2 has no trace of the "non-realtime" simulation that existing with emc1, so the Kim problem Ray mentioned earlier simply won't happen I don't at all mind moving all of these into some other location. If we can make one that runs without any interference available easily. in emc2 configs are in emc2_home/configs jmk: how do I get a list of signals? I used emc.ini when I started the emc2 run script exactly because that's what emc1 used... however, I made it stepper because that's what emc2 can do right now... I would have been better off picking something unique alex_joni: bin/halcmd show sig I think inside halcmd ;) ? halcmd.c :P oh... programmer, not user I am adding a function do_delsig_cmd() you have to run the linked list - look at the code for "show sig" isn't there already a "delsig"? or are you adding "all"? ok.. thx.. that's ok... wonder why I didn't think of that I am adding all cool there is no delsig_cmd yet ;) oh, I see - I just called signal_delete directlly from the parser take a look at the implementation of "unloadrt all" too I already did you don't want to run the list while issuing the delete commands need to run the list and save the names, then issue the commands yup this direct access to the linked lists is something that I hope to fix with the hal refactor, if I ever get there jmkasunich: When you get to the point of tbl and nml config files, will they also reside in emc2/configs? I guess. nothing I'm doing touches them I'm open to discussion - I don't want to make these decisions unilaterally emc2/directory.map is the "master plan" such as it is Gotta run, will leave on for logging. Cheers. tool tables should be with programs (in my opinion) it's not cast in stone I agree that tool tables are not really machine configuration, more like job setup They are config in emc1's sence of having only one available. NIST didn't understand the way that tool files really worked in a shop environment. seems like there are two kinds of tool files: the one that represents the tools currently loaded in the turret and the one(s) that represent the tools that should be loaded to make a particular part the former is a machine config the latter is job config does that make any sense> ? The only way to change is in the ini file. Cause you can't load a new tbl from the gui. At least I was not able to the last time I tried. is there any way that the gcode can say "tool 1 should be a 3/8 endmill", or does it just say "use tool 1 now"? The tbl has four columns for each tool. pocket or tool number, length, diameter, and comment. so when you change the tool that is in a pocket, you need to change the file You can use any length and diameter you want with any tool. Those are h and d respectively. I'm trying to understand the scenarios... suppose the machine just finished a run of part "A" now a guy walks up, needs to make part "B" he has floppy in hand with the gcode program how does he make sure the right tools are in the right pockets? Yep. Gotta edit the tbl file. if B needs different tools than A? so he has paper, or comments in the g-code that tell him what tools are needed? he uses the paper to select and load tools, then modifies the tbl file so the machine knows what it has? Isn't there some way of specifying a tool table in the NGC file ? Yes. You can do it that way. I'd have preferred some sort of "get this tbl file." thats the way we do it at work, john getting the file doesn't change the tools tho, that's manual %TOOL-TABLE=foo.tbl Or get these tbl defs from the g-code. paul_c: does that work during a run. seems there needs to be a "part A" tool table, a "part B" tool table, etc rayh: It was a suggestion on how to handle tool tables Good one -- it is. It would be very dangerous to have the G code file assume what tools are loaded Operators have to sometimes make substitutions too I'd also like to see one that allows for reading all of the tool info from the g-code itself. T1 D2.76 L-2.00076 When a tool plate is set up the appropriate table must be edited C-0.497 end mill danfalck: or the carousel set to the tool table. We have jobs on mills that use standard tool numbers such that tool 3 is always a 1/4" c'sink or tool 1 is always a 3/8" end mill you can set up the programs to use different tool numbers and just leave the tools where they are jmkasunich: I'll post a note re emc1 and moving ini, run, and var files to emc/configs. that way set up time is reduced no touching off required if the parts are similar rayh: don't make any changes to emc1 yet! I'm done on do_delsig_cmd.. should I commit? you're only changing emc1 to make it similar to 2, right? so wait until we're _sure_ we're happy with the plan for 2 jmkasunich: Right. seems like tools at least are still up in the air I've got no problem with the idea of a configs directory. That will get stuff like lukas.ini and run out of sight. i think it will be very good to have the tool tables in the user enviroment Yep. That will be valuable. and if it don't find any, it loads a example tool table from configs maybe danfalck: I hear what you are saying. These are shopwise decisions that can be allowed for in var. alex_joni: yeah, go ahead and commit I wanted to test it a bit first... seems to work... maybe you can take a look is it ok like this? did you take a look? just doing the cvs up now I posted a note to developers proposing the emc(1)/configs directory. Would suggest a cleanup of the run scripts also One core generic.run How would we do this? and all others call "generic.run -ini foo.ini" right that's complicated for the simple user... who can't really create a desktop icon to execute that command .. :-? Look at some of the shorter foo.run scripts where the foo.run scripts anyway? now I know what you mean duh I've seen that. We would still need to create individual run scripts but they would be only three or four lines. that Homer moment ;} damn colored ls - my eyes skip right over the light green ones * alex_joni is hungry... I'm gone for a bite see you later... bye alex Great work alex. with what ? ;) delsig all works fine here the auto stuff and your committment to regular time spent on emc.' * jmkasunich adds alex to the list of contributers at the top of halcmd.c well.. catch you later guys... * rayh Gotta Run. Thanks for the stimulating discussion. sorry about the steam ray Oh hey. That will happen as we work through these things. Sorry for venting. * jmkasunich goes back to trying to compile rcslib hi all hello did sucessfully compile emc2 cvs (kernel 2.4.27, rtai vesuvio, gcc-2.96, debian sid) cool yes! i tried kernel 2.6.8.1 and gcc-3.3.5 before but i did'nt work at all john can you change my email adress in halcmd jmkasunich: mkuhnle_nospam AT users DOT sourceforge DOT net is the right one my machine is stepper controlled and i can't get it out of E-STOP... can i comment out some lines in EMCTASKMAIN.cc to make it work ( i don't need e-stop)? * paul_c hopes babu used gcc-2.95, not gcc-2.96 s/2.96/2.95.4 sorry for that Imperator_: sure, I'll change it thx emc2 already has estop commented out babu: error messages in emc2 don't always make it to the screen... take a look near the end of /var/log/messages (kernel log) and see if you have following errors or something like that keeping you from coming out of estop i did a ./scripts/emc.run and that "nice" tk-gui came up. i did F2 then F1 to reset e-stop and turn the machine on then i did some joging in (+) direction this works but then suddenly it goes into e-stop (override limits is enabled) jmkasunich: ok i'll have a look at joint 0 following error! that beast! if i use freqgen.o i don't need to tune the PID right? use stepgen freqgen is the one that needs a PID loop and tuning erhm sorry i'm so lazzy today i use core_stepper.hal which does use stepgen ok let me think a minute what have you changed from the standard ini and hal files? core_stepper.hal: setp stepgen.x.position-scale alex is gone, eh? Great work on the configure stuff, anyway. babu: what were the old and new values? standard_pinout.hal: order of the linksp commands connecting Xdir, Xstep and so on to the according parport (pysiccally)pins jmkasunich: i'm in switzerland so i want to use the metric system (also changed a few things in emc.ini because of that) old value was 5080 new is 80 (80 steps per unit (mm)) so in the axis section, UNITS=1 ? yes and you also updated MAX_VELOCITY and MAX_ACCELERATION to mm/s and mm/sec^2 LINEAR_UNITS = 1.0 too yes i updated those too 5.0 and 20.0 MIN_LIMIT and MAX_LIMIT is set to -200.0 and +200.0 (i guess this is the work range in mm??) yes you said jogging in + direction works... how far were you able to jog it? a few mm? is there a real machine attached to your parport? i'm on the end of the table but just a few mm, yes.. yes this is the real machine without limit switches (in the moment) did the displayed position change? did the displayed change match the actual movement? ie. machine moves 3mm, display changes by 3mm yes i guess yes but after 2.4 mm there was an estop again (in + dir!) Issuing EMC_AXIS_ABORT -- (+120,+16, +9, +0,) <-snip-> mail me your ini and hal files, I will try here. I haven't tested a mm setup yet ok i'll send you core_stepper.hal, standard_pinout.hal and emc.ini your max vel and max acc seem _very_ easy (400 steps/sec, and 1600 steps/sec^2), so I don't understand the following errors usually that happens with fast accels I've done 10000 steps/sec and 1,000,000 steps/sec^2 maybe it was only 100,000 steps/sec^2 but far more than i want to reach... the e-stop is because of the following error? sent! got it... give me some time ok! I'm confused why? the attachments seem to be messed up they got inlined into the mail body core_stepper.hal seems to be missing i resend the whole stuff send 3 messages, one with each attachment hmmm... sorry to bust in, but can somebody add me to the cvs access list on sourceforge so I can check out alex's latest fixes. The anon cvs is delayed, it seems... i send 3 messages without attachement (inlined) * babu has received his email correctly got the emails zwisk - stand by please okie... thanks. is your sourceforge ID "zwisk"? with registration as a developer comes great resonsibilties (darn... missed a P in there..) (and great power.) Yep, I know. I promise to use it only for Good. and a commitment to committing changes for the good. is your sourceforge ID "zwisk"? indeed. Thanks for checking in that last configure fix for me. I hope you don't mind doing reviews like that for me. I do like to have things peer reviewed before checking them in. john: 'zwisk'.l Hope you didn't take umbrage at the first rejection.. nope. You were totaly right. (Which is why I like having peer review ;) ) Hopefully, the uglyness of the configure script can be lost inside configure.in trading one form of ugly for another... jmkasunich: sent you another mail: taskintf.cc 856: Error on axis 2, command number 192 indeed. Alex had some good points that I saw up there with respect to having a install or package directory different from the source directory. It seems now that the scripts all get hard coded absolute paths to their build location rather than their zwisk: what do you want to be - developer, tester? install location. developer, please... make installs to predefined locations (as set in Makefile.inc) ok, you should be in but most of it is relocatable thank you sir. if/when the --prefix option is used, we will probably need several target directories that can be specified on the command line. paul_c: I think rtapi.conf gets generated from the makefile and contains absolute directories that tend to be the build directories. --prefix and some of the other configure standards [sh/c]ould help with that. Agreed maybe a rtapi.conf.in autotools provides for quite a bit of flexability in what can be achieved. perhaps. I think the makefile currently just echo's the values into rtapi.conf. That's probably not all that bad of a thing. An 'install' target might just echo install directories rather than build directories. well... (as I'm sure John will agree) the original configure was just a hack to get things moving it seems to have gotten things along a pretty good distance. agreed about it being a hack babu: what is all the [STRING] stuff in your ini file? forget about that.. i perhaps want to write a configuration frontend and did some remarks. but it will be real complicated todo so because you have to specify abunch of parameters for a servo system and perhaps to modify those hal scripts... it looks like good documentation... alot of people use old dos based commercial software to control their homemade cnc machines because emc is hard to configure what do you think about the taskintf.cc 856 error message I've seen that before. It's not a very usefull error message. IIRC it means that a command sent to the realtime motion controler failed, but it says nothing about why it failed ok are you planning to use limit switches and a home switch? (I see a non-zero HOMING_VEL) your MIN_FERROR is pretty low 0.002mm try raising it to 0.1 as a test, if things work better we can refine it later yes i plan to i forgot to change MIN_FERROR so 0.002 mean 0.002 inch i guess if you have 80 steps/mm, then each step is 0.0125mm, so minferror should be at least 0.025mm ack! i'll give it a try to all: i promise i will contribute to emc2 (a boost/sleep feature in stepgen, some docs and beta testing) keep up that work! jmkasunich: it works! thx.. it would be nice if emc would give abit more and a bit less details about whats wrong.... yes - the following error message should appear on the screen, not just the kernel log that would point you toward things like MIN_FERROR there are 8 steps, make_dirs, headers, depend, and all, for nonrt and rt all I see are the 8 make commands yes nothing else is echoed to the screen strange... try running one manually... see what happens ran the make_dirs one paused a few seconds, then done no output (maybe they're already made tho) nope that makes things like rcslib/plat/linux_rtai/bin, etc? is it a fresh cvs? yup fresh except for me trying to compile in it ;) cvs up doesn't delete anything how about make all? still no output? just do a "make all" with nothing else you should get an error about PLAT not defined in the src dir, results are: ../etc/determineplat.def:49: /home/John/farm/rcslib/etc/.def: No such file or directory exactly make: *** No rule to make target `/home/John/farm/rcslib/etc/.def'. Stop. same here now : make all PLAT=linux_rtai it's doing things bunch of copies, now it's compiling why was I messing around with those long lines from the compile_bditng script, setting all kinds of variables and stuff? plain old make all PLAT= seems to be working fine now that you have those env's sure ;) but it only works if you have the dirs I started too from the script... but got to the point where I issued everything by hand make all PLAT=foo make all PLAT=realfoo ;) and it worked.. the only question is what env vars need to be set before issuing those two make commands I only know of those I told you about theoretically you shouldn't need any of them * jmkasunich3 starts a new shell with a virgin env but it sureley speeds things up ./linuxkerneldir is a script that first checks for KERNEL_SOURCE_DIR env and if it's not found... it starts looking in /usr/src and this is done everytime a Makefile is accesses e.g. for every directory in wich you compile same for RTAIDIR there is a buildrcs script inside rcslib/ but I never tested that one out... :-? started with a virgin environment, and make all PLAT=linux_rtai seems to be working I'm gonna do it that way I think don't forget you need make all PLAT=rtai right total of two fairly simple make lines WTF is all that other stuff for ;-) ;) a LOT of machines ;) not so great put together as is the TNG ;) now I get to do the same thing on BDI-2.xx and BDI-Live oh joy short question... on emc2 shoot are there all directories after cvs checkout? ? or are some created at first make? for emc1 or 2? emc2 * jmkasunich3 checks I think they all come from CVS I have a patch to take care of the directory issues you just referred to... would someone like to review it?' describe it first ;) what seemed to be the problem? emc2/include, /bin, and /lib, /rtlib are empty when checked out, but they are created by CVS, not by the make process primarily, before doing an 'install -p ' of a file, it does an install -d ... this is in the Make.rules I don't know why we have those four empty directories in CVS so the problem was in Make.rules? I also made the main make file stop instead of continuing to build on errors. on the main branch? The *real* problem si that the cvs directories are empty (and so they don't get created), and/or the make system doesn't create them. No, this is your autotools branch. ok... commit ;) I wonder if the dir issue is not in the main branch... uh oh... cvs [server aborted]: "commit" requires write access to the repository hmm... maybe jmk can add you as a developer yup... I thought he just did. you did a cvs -d:ext:zwisk@cvs.sourceforge.net:/cvsroot/emc co emc2 checkout? (after I added you?) I thought so, but I'll do it again... save your changes somewhere you have the "export CVS_RSH=ssh" ? yep, ssh all the way... and it's re-checking out... whooops... your command, howver, is not checking out the autotools branch... sorry... I skipped that part of the command just checked your status, you should have CVS access jmk: forgot to ask you.. how's the delsig all ... is it ok? looks good to me works too ;-) nice to hear ;) hmm.. worked this time. Cool. yummy... a clean compile using autoconf ; configure ; make I love it. well... you really don't need autoconf you should be able to just run configure and make even better. :) from a fresh CVS http://www.linuxcnc.org/compile_farm/ rcslib ok on slot 3 autoconf only creates a new configure now to get the other two working, and then emc1 sweet! I'm impressed at all the progress happening in the last few weeks! still got 2 warningss ;) Trying to determine if RTLINUX is installed. Set the environment variable HAVE_RTLINUX to YES or NO to override. Trying to determine if RTAI is installed. Set the environment variable HAVE_RTAI to YES or NO to override. something else: I know this is not the most important thing... But I think a small icon (either green or red) would look great :P as far as HAVE_XXX, it managed to figure out the right answer by itself, so I think there is no need to override it yes - also the date and time of the last compile but it's hard to pull it off there is one index.html, and 8 slots - each one ftp's index.html to local disk, runs sed to change the appropriage words, then ftp's it back to linuxcnc.org I can't run scripts or anything at all on the server itself does the server allow php? it's a windows NT server, over which I have little or no control ok.. then not ;) I wish I could send emails to the list when a compile fails or succeeds... actually, now that I think of it, little red/green icons would be pretty easy yup only change a letter the icon is always on the server actually I'd do the opposite what? the trick I use now (download index.html, sed it, upload) is vulnerable to contention if two slots try to access it at the same time instead, I'd have a static index.html, it would link to images called emc2_slot3.gif, for instances my script would do either "put green.gif emc2_slot3.gif" or "put reg.gif emc2_slot3.gif" red.gif actually, could be simpler than that... if red.gif and green.gif reside on the server, simply need to execute a remote cp, no need to "put" at all ultimately, I'd like to have a farm script that others could run as well no reason to limit ourselves to 8 slots nice right now the script reads a local file called "trees" that tells it what CVS trees to download and test I want to put that on the server too instead of manually copying it from one slot to the next cool...;) I just sent you an email with 2 icons currently I have to do the initial checkout manually, so having "trees" on the server doesn't really mean much maybe you like them red is actually blinking yellow on my screen well... yellow but it's blinking ;) have to look into that (after I get rcslib and emc working) do you know the appropriate plats for BDI-2.xx is is just linux_rtl and rtl? setenv NONREALTIMEPLAT 'linux_2_2_18'setenv REALTIMEPLAT 'rtlinux_3_0' taken from compile_bdi2xx but never tried it out... seems promising is the procedure for making emc similar to rcslib? yup same thing cd src ; make all PLAT=foo cool here you'll probably need the TCLTKINCFLAGS or you'll get a weird error from gcc at least I did cannot use -c with multiple files or smthg like that I'm just gonna let it run and see what happens compile times on this hardware are many minutes rcslib is building now, emc will follow (on slot 2) nice meep? hello robin ;) eveny what's up? the moon not here anyway, another day designing bits of metal and writing SolidWorks macros well that's weird... the rcslib build ended with an error, and the message: "the following error was intentionally inserted to prevent running the make twice" nice ;) wow jmk: never seen that one before jmkasunich : sounds like you are trying to compile it too quickly the emc build is going now - when it's done both logs will be visible online jmkasunich : slow it down a bit .. thats the usual cause of follwing errors ;) lol unfortunately the error almost certainly caused it to skip the realtime portion of the build so the emc build will probably fail too anyway ... todays fun was all in aid of trying to automate the solidworks assembly -> nested parts on the laser process. i think I can now write all the outlinbes out as DXFs automagically, convert them to .geo format for the trumpf stuff and preapre a job spec file for the trumpf nesting/technolgy programmes ... and I've learnt a LOT about bending ... results are online now robin_sz: http://www.linuxcnc.org/compile_farm/ you're missing etags etags? /bin/sh: etags: command not found make[1]: [TAGS] Error 127 (ignored) cute I don't think the build really failed etags are only really of any use to developers right? are you talking about the emc on or rcslib one? rcslib they should not be built in a normal, user, build ... shurley? and dont call me shirley .. why not? no use to users AIUI ... this is the emacs editor tag library stuf right? I don't even know what an etag is (tho it sounds vaguely familiar) me neither it generates tag files for emacs basically it makes up a tag library, a sort of index to speed up editing the source with emacs ... two points: not needed ;) users need it not and ... emacs is the workk of the devil anyway lol really? I was always wondering why it's that "nice" yeah, think so. its certainly the worst web server ive ever had to use web server? emacs ... its a web server isnt it ?? oh wait no .. its a mail client .. well... maybe media player;) I think theres an editor in there as well, somewhere .... anyway ... etags need not be in the main build process, don't tell me, I don't do emc1/rcslib... I just set up the compile farm * robin_sz nods when someone commits a change, it will try to compile again good point. (checks once per hour, when I have it powered up) CPAN does that .. what is CPAN? or PAUSE does anyway .. you submit a perl module and the compile farm tries to build it .. if its OK, it goes live the Perl archive network ... * asdfqwega is a vim man, meself... you know how knopix/debian have repositorys of modules you can install over the net? jmk: you're missing pci/pci.h *** Signoff: sxpert (Connection reset by peer) that's why emc is failing on slot2 CPAN is like that, but just Perl libraries ... with a very very kewl installer .. a bit like apt-get I guess * robin_sz shuts up again where should pci/pci.h be? well... in pci/ ? /usr/include from the pci-utils dev package I have pci in /usr/include/linux/pci.h so linux/pci.h no not pci/pci.h wrong header robin_sz: laser works...but disappointed: No starwars "skreeeooooo" sound :) so it's needed pci/pci.h from dev? linux/pci.h is for the kernel just tell me what package I should install ;-) asdfqwega: I believe you can get cheap chinese sound-bomb devices .. all the laser noises you'll ever need for under 2 dollars pciutils-dev asdfqwega: burnt anything yet? note to paul: BDI-2.2x should install that if the user wants a developers install BDI-2.24 will. robin_sz: yes asdfqwega: post jpegs robin_sz: Of what? a piece of balsa I waved in the beam while trying to hold a 9V battery on the control leads? tee hee you going to chop balsa with it in the project? No, I was going to burn patterns onto hardwood oh, ok paul_c: take a look at rcslib-compile output on slot 2 ever seen something like that? ok, pciutils-dev installed, build restarted the compile farm thing is cute ... can I make a teeny weeny suggestion? sure on the status page ... have links to the tarballs that it built from, it doesn't build from tarballs, it builds from CVS or maybe the tar-balls with the build ? well, the appropriate cvs commands then good idea especially since I will be adding some branches I want to run it on the lathe-fork and the autobuild branch as well as emc2-HEAD Hm...what made the latest cvs of emc fail on rc46, I wonder? rc46 isn't started yet click on it.. you'll see look at the logfile paul_c: ray said something about special .defs needed to build rcslib and emc1 on BDI-Live? compile farm status page: good idea [goes back to lurking] Extract rtai.def and linux_rtai.def from the src tarball in /usr/local how do you uncompress a .bz2? (I'm used to .gz) bzip2 -d tar -xjvf foo.bz2 thanks the j flag replaces the z flag paul_c: autoconf kinda works but there's a lot of testing needed especially for rtlinux... * paul_c prods zwisk not to mention rtlinuxpro but that's a different story rt-pro can be left for FSM labs to work on. yup I was wondering... who did all the autoconf stuff for emc1? that got removed? guy named ebo, contractor working for fsmlabs prod? wha? :) I removed the autoconf stuff earlier in the year I've been reading a lot about him lately... oh, older stuff 'cos it didn't work I know.. though you meant the recent stuff I tried it out a few months ago... thought few=many :) didn't quite get the results I hoped for zwisk: You need to subscribe to the emc-commit list with your sourceforge account oh... I'm on with my normal email address... Will I get 2 copies? set one to nomail you can turn one off (or simply unsubscribe) right... ok... well guys... guess I'll call it a day paul_c: got those .defs - do they simply overwrite the ones in rcslib/etc? goodnight alex yup so the next cvs up will in turn overwrite them You could set the attrib to read-only or rename them but that means CVS will always think they've been modified but then you need different PLAT's I was thinking that we should commit them for instance PLAT=linux_rtai_live or something like that I have no problem invoking the appropriate plat on my build hmmm... PLAT=BDI_live_linux PLAT=BDI_live_rtai guess rcslib didn't compile after all emc is failing because of missing rcs_print.hh on slot2 that is emc now builds on slot 3 paul_c: your call on the PLAT=linux_rtai_live or whatever hi ebo Hi... just got up. pretty sick what's up here? finally got the compile farm kinda working (after well over a year of talking about it) not bad, just I sleep alot whenever I get a cold or flu ;-) Boy some of those around-to-it projects take awhile... up till 4:30 this morning still fighting with rcslib and emc1 on slot 2 (aka BDI-2.xx, RTLinux) I have a portable forge I am reassembling that I can take anywhere after someone stole most of my old equiptment and about to try on slot 4 (BDI-Live) 4:30 am is I guess WAY after you bedtime that's one way to keep warm on a cold fall day (well maybe not too cold where you are) is the emc1 fight the old code or mine? the old are you up for trying out mine? I dunno understand. gotta get emc1 and rcslib working on all three slots ten have two other emc2 branches that I want to get working s/ten/then yep. and getting the canonical version up is likely a necessity I'll be lucky to finish that today during the week I don't get much done ask me again next weekend ;-) yep. that's a lot of work ;-) next weekend it is mind if I wack the hornets nest with a big stick again? paul_c: if I hear no objection from you, I'll commit those two defs as linux_rtai_live and rtai_live. OK? Not yet There is the issue of symlinks that need to be resolved first. ok. I copied them to rcslib/etc/xxx_live.def for testing, no need to commit them right away (test build in progress) well, that didn't last long died? some kind of error... I'm gonna restart it with the script, so the results go online results are at http://www.linuxcnc.org/compile_farm/ but the BDI-Live results will take a few more minutes ummm... the follwoing error is *not* that helpful: Building emc - note that this is a test script that always fails so it fails with no other error is that a failure? that's from the last pass - no actual build the "build" script in that case was a dummy ahhh... a run with the real build script is in progress now okems... slow boxes here, 5-10 mins for results well that's strange already done, and apparently passed did you do a clean? no the old scrip does not do a proper clean but I've never done a build from that checkout BTW, to clean or not to clean is a question I've been wondering about for the farm probably should clean ahhh... then I have no idea what's yp... sorry no help here Ahhh... I would have to look at the setup. I *always* want a clean and uninstall function that removes ***everything*** the unstaill that is makes sense and a clean cakes things back to config, and deepclean/distclean/etc. takes it back to distro but for the farm, I'm not doing an install in the first place ^cakes^takes^ just "cvs up -dP ; build" ok, but where does everything do to? where "build" is "./configure ; make" for emc2, and something more complicated for rcslib and emc1 note no "make install" ahhh... if I am not mistaken, "cvs up -dP ; build" or .configure... leaves files around (like blawoof.o) tons o'stuff the goal with the compile farm is just to know if the compile succeeded ahha! ,,, jmkasunich is a M$ employee! then when you rerun it may not build things that should do to the if the config changed. "hey, it compiles ... ship it!" as for the install/no-install on the compile farm. Understood. I was just saying that these additional functions are things I like to see and use everyday hahahah... good one robin_z but seriously, I like the availability of a compile farm what tools do you use to set it up (particularly auto generating the summary page) damn - my IRC client on the other box must have timed out... I was talking to myself for a bit sigh ... there went the old me tools: not much - grep, awk, sed, etc. the summary isn't really autogenerated... it was manually generated once with emc2, I think I will revise "build" to do "./configure ; make clean ; make" with emc1 and rcslib, I dunno what to do, and frankly I don't want to spend all day fighting with it I'm providing the compile farm, I hope the emc1 experts can figure out why it doesn't build then each slot does "ftp get index.html ", uses sed to modify the lines related to that slot, and then "ftp put" once emc2 actually has a working "make install", it might make sense to test it ;-) for now, it gets built and executed in the emc2 tree well that was weird - those comments must have went the long way around (wrote them 5 mins ago) ahhh... If interested some time you might take a look at the boost unittest tools which generate such summerys my prob is that I have (up to) seven different boxes, that all want to put their two cents into one html summary and I don't want to spend lots of time setting up NFS shares, etc * robin_z nods so each one stands alone in fact, once it's a little more refined, the script could be used on other boxes (at other locations) all results in the same place the boost/spirit stuff is designed to work on M$/Linux/VMS... and collect the results in a single place. what are the dependencies? whatever work. I like the functuinality for the boost stuff? yeah I will have to look. these boxes are very barebones no guis on most command line ftp client, and basic command line utils plus cvs, ssh, and of course the compiler and tools Boost is the bleading edge test platform for the C++ steering comittee. This is one of their testing tools. Everything that boost needs to build is typically in the boost tree. * jmkasunich3 doesn't like bleeding edge - I'm a fscking dinosaur still don't own a cell phone (and never will if I can avoid it) it is backilly commandline and inline c++ templates as far as I know. The unit tests would be some script front end I expect now actual testing on the compile farm, that would be cool but also way too much work re: bleading edge: the low level tools just work. The bleeding edge is painful but neither EMC nor you have to go there ebo: careful saying things like "unit tests" around here ... next up you'll be saying 'Junit" and then all hell breaks loose no... not junit, but what is up with junit? nothing ... ummm... right. I know a historic allusion when I hear it but its connectetd to the J word .. and people arounf here break out in hives when its mentioned J word? he said the J word!!!! rymes with lava and should be tossed into the nearest volcano Ahhh........ I get it! nononono... No *unit, unittest! mind ewe, some of them start frothing a bit when you mention C++ .... who, me? I've admitted that I _should_ start learning that language that's a far cry from actually doing so though but there again, theyv eprobably only seen the "C++" in emc, so its understandable /// true true ... there was an implicit smiley on most of that I know - here, you can use mine ;-) Hmmm.. I must have started the hounds to baying when I mentioned my experimental fully runtime polymorphic rs274 parser written using spirit++ (c++ inline templates utalizing functional programming techniques) actually the parser is so far away from the parts I like to work on that I didn't even pay any attention I'm already suffering from information overload cant we do it in Haskell instead? hmmm... do you REALLY want to go there? what I really want to do is start the HAL refactoring * jmkasunich3 would be content to limit himself to working on HAL so ebo, as a matter of amusement, how did you like the "C++" in emc then? emc1 or emc2 either, both, whatever emc1 .. although much of it lives on in emc2 at the moment right libnml has been massivly improved, but the rest is pretty much copied ummm... to be kind, it needs work IMHO, but on the other hand much of my stuff needs to be refactored too. hmmm ... Actually, I have not crawled around in emc2/libnml at all. My comment was on emc1 "it needs work" is one way of putting it ;) I'll write that down for future reference ;) well... I am an EMC gift horse and I am NOT GOINT TO LOOK IT IN THE MOUTH! well, true ... I think some people have been put off C++ because theyve looked at hows its been used and not understood it oh... that is an american expression, I hope our international guests get it robin_z: If YOU want to recode the C++ stuff, go right ahaed. I did/do ... and indeed I started but it was too much for one man ... Use haskell, perl, or ython if you want... after a few weeks of hacking, I decided a ground up re-write was needed sadly, time does not permit, and my need for emc has sortf of gone away ... certainly for plasmas anyway I have the stuff I started throwing together over a year ago (C++, spline based geometry, motion control using a totally hacked 2.5.8+ preemptive kernel driver)... But I cannot offord to even *consider* redoing that without getting paid. yeah, earning a living comes first I guess speaking of which, back to solidworks for me in a minute .. Well, not always first, but I have to juggle for SURE! * robin_z nods * ebo winks I am howvere truly and utterly fed up trying to do things on windows .... even simple scripts become a pain poxy system doesnt even respect shebang in scripts ... no tab-completion of path names ... etc etc etc etc * robin_z calms down here robin_z... take this pill ;-) is it red or blue? 8-) You choose ah, fsck it I'll take both smells of almonds... hahahaha I was looking at a big plastic bucket of that the other day ... did any one ask for a wafer thin mint? not exactly ... good. though my mate did demostrate how it was safe to eat it ... Brovo. I have done this too in the safty of a desert no mess to clean ;-)\ anyway, what with the bucket? apparently in sub-lethal doses it just doesnt do anyting much ... a tiny bit on the end of his finger ... I give up give up on what? getting emc1 and rcslib to compile well, in a way then , the test farm is working ... understand how you feel. The only reason I continued to beat on it for over a week to git the original compiled and working was some one was austensibly paying me to do so. wow ... good point RZ wow? you managed it in only a week ? having said that .. once you do get it working, its a cinch ... week linear time on a new distro using a different shell that had a low level shell incompatibility problem with the build scripts... the important thing is NOT to tweak the compile farm to make it work ... or the build test becomes meaningless re: chinch after the first time. True for me, but not for any other user. And what happens the next time I move to a different distro or CPU architecture? * robin_z nods thats where the compile farm comes in ... exactly agreed. the problem is that there is no ONE compile command that is intended to work on all plats and really, failing to compile is a "good" result .. its an answer that we didnt have before for emc2, it is "./configure; make" my emc2 build script does just that, identical on all slots * robin_z ndos (adds a few comments, echos the commands so you can see them in the log, etc) right .. must return to the horror of windows .... lots to do. but the build scripts for emc1 and rcslib are different on each slot at a minimum, the PLAT=foo with additional weirdness on BDI-Live and there's no make clean (at least not one that works) JohnK, if I email you a tarball would you uncompress and try building it on one of the RTL slots? I am not asking you do do any more than that... I am just curious RTL or RTAI? how much work would this entail? * paul_c is starting to tolerate trolling less and less... RTL, I do not have RTAI put back into the emc1 yet. Paul, do you consider that I am trolling ? No... robin_z if you literally mean "gunzup foo.tgz ; tar -xvf foo.tar ; cd foo ; ./configure ; make", then sure - I can capture a typescript and mail it back yup. there might need to be a --with-rtlinux-free, but that is what I have in mind ok... maining it over in a moment. I need to finish the email I am in the middle of writing first so I do not confuse my mailer... you want slot 2, right? (That is BDI-2.xx, uname -r says "2.2.18-rtl3.0") take your time I do not know if it will build out of the box for several reasons... namely that I used 2.4.19-rtl-3.2_pre2 + patches for the base system. but slot 2 sounds like the most appropriate I've just punched the send... 3 and 4 are both based on RTAI - 2 is the only RTL system I have this is emc1 with autotools? Well, if you can try that. Please do not wast any time beyond that. Yes. emc1 with autotools. * jmkasunich watches the mailbox * ebo watching the status wheel on the mailer go round and round and not done yet... ahhh... give it about another min, and it should be there I sent it to the ... att ... address let me know how it goes. still in the pipeline well my attempt at a crude "make clean" for rcslib failed miserably I tried rm -rf plat/linux_rtai thinking that all the .o etc were in there but apparently not oh... when you get it, please try running ./configure without any args first to see if it will properly autosence will do I forget where everything gets placed. I just removed all the plat/* in rcslib and emc then did a find-destroy on all \*.o and .dep\* as I recall jmkasunich: Add "cean headers all" to the makes didn't someone just say that make clean doesn't work? * jmkasunich3 tries it anyway 8-) depends on which source base we are talking about [cvs]emc, or emc as ported to BDI. I have no idea what the difference are,only given the impression that there are there are differences, correct? in the build system? the premise behind the compile farm is that the CVS should build on all BDI's as a minimum... If we can't build cleanly on the systems we control, how can we build on an arbitrary one? I do not understand the issue here besides BDI is considered to be the canonical system? I agree that it needs to build on these, I simply did not put a lot of effort into to making sure (yet anyway) that it builds on systems that I consider ancient. by linux kernel standards (ie. 2.2.18-rtl-3.0) 2.4.27-adeos on the latest the other BDIs are newer and 2.6.7 in the wings after the RTL patent, focus for the newer ones moved to RTAI, so the oldest one is the only one with RTL understand. I just started with 2.4.19 for a stable standard, and rtl-pro is 2.4.25 understand focus shift. On the 2.6.*, will that be adeos, rtai, or preemptive? RTAI uses adeos anyone else thinking about the new preemptive release? No. I was about to make a comment that the silence was defening ;-) Ok. that is my personal interest John, did you get the tarball yet? problems? preemptive does not mean hard realtime capability still messing with emc1 build file - last email check was a while ago, it wasn't here then paul_c: I have not seen an analysis of the hard/soft realtime for the new patches. I thought they were looking into providing hard-RT for preemption. When I was hacking my own preemptive drivers I did not trust the hardness of them but then again once I clean them up the first pass on the timing tests never violated the latency requirements. I should also note that my driver did not hace a POSIX complient interface because I realized that I could take advantage of a particular insite in the the timing. I was able to get sub 10us on flipping switches. It depends on the timing intervals and how strngent your requirements are on meeting the deadlines. Agreed. When I left that prototype, I had not stressed tested it sufficiently. tarball is here... gotta d/l it onto slot 2 now Right - throw in some DMA activity, flood ping, and run some heavy X app, and see what happens to the timings Just for fun... do some funky hot-plugging on the USB port... I also have not developed proper requirements for the preempt application yet. I was wondering if it would work at all first, then go into looking how fast I have to talk to the motor controlers, etc., etc. That would give me a sence for how precise and accurate I have to be ;-) agreed with all the tests. If I go that way I will set up a bunch of scripts to do scriptable things then proceedures for "beating the H*LL" out of it -- ie ding things like USB plugging, unplugging the motors and controllers while running (***if*** I first determine that that can be done safely at all). someone is bound to trip over a wire while the machine is running. another test that hammers some hardware is simply putting a CD in the tray 8-/ personally I like the RTL/RTAI way - my code runs closer to the hardware than the Linux kernel, and that's about as good as it can get I like RTAI for it's clean abstraction for sure. how are things on you end with the build? having fits with my email client hmm... what's the problem? (web based, usually works fine, but I've had problems the last half hour or so, both on this box and slot 2 logins "sort of" fail, strange stuff huh. I wonder if my ISP is seeing some sort of DOS attack or something could be. There has been some odd thing in the bitstream lately. Should I try putting thins in the linuxcnc dropbox? dunno... let me try again ok. (it doesn't help that these boxes are so slow - they're ok for cmd line stuff, but browsers really suck as a note, all the FTP sites I have access to require admin's to manually check and place them in... slow machines... yep, what a pain. But do remember the days when you had to wait 3 hours for a compile to go through on a 386? I've always worked on projects that were small enough to fit in a single brain... so compile times were usually manageable however I used to do a lot with the POV-Ray raytracer... that can consume as many CPU cycles as you can send it 8-) doing event driven simulation on home computers was not very realistic ;-) that is what motivated my best friend and I do go half'zies on a sun workstation; sun had just started coming out with the IPC's MUCH better than the 386 looks like I can't effectively use email on slot 2 web based email + old netscape + slow PC = not usable I'm downloadind the tarball to my main PC... dunno how I'll transfer it over tho scp how big was that tarball... I'm not sure I got it all .... assuming you have an ssh link to slot 2 3299970 I don't each slot has a ssh client but no ssh server The main box running ssh ? client only nfs mount ? all wonderfull ideas, none of which I'm up for right now my late night is catching up to me wget -c ? splitting it onto three floppies I might be able to handle it's not on the web (the mailer is on the web, but it's some complex mess of php or cgi or javascript or lord knows what... not amenable to a simple wget ebo: Want me to stick it on a web server short term ? hold off a bit, let my slow brain ponder my options hmmm... sshd is running on this box... does that mean I should be able to ssh into it from slot 2? sorry, I went out of the room for a few.... let me catch up. 3299970 is the reported size here (but that probably also includes the dosc that I think I will remove. I am fine with you sticking it on the server short term yes scp from slot 2 to the other machine should work wtf well it's on slot 2 now ummm... that was not clear Oh... good. I don't know how it got there - the browser never indicated even a partial download, but the file is there hahaha... ummm. It is just trying to behelpful ;-) maybe even tho the browser was fubared, there was a separate process doing the download with no visible signs, and it survived and finished anyway, off I go to try it thanks ok, untarred, etc... anything special before I do "./configure" ? guess not no. looks ok. ? configure is running, script capturing output... seems normal enough so far good. thanks. a couple ls commands weren't happy looking for /opt/rtldk-* it said "checking for RTLinux-Pro... no" "checking for RTLinux-Free... no" ahh... yes. I have corrected that in my unpacked code. there should be "'s around it but a few lines later it said "RTLinux-Pro found" Ok. Try running ./configure --with-rtlinux-free no arguments it finished the first attempt, should I try a make, or do the --with? that is a problem in the autosence code. Rerun with the explicit no. it will not make try running config with --with The make will expect the rtl-pro structure. this time it said "checking for RTLinux-Pro... no" "checking for RTLinux-Free... yes" good. as a note, the porper fix for the config is RT_DIR="`ls -d /opt/rtldk-*`" you want me to cat any of the makefile.inc or anything so they'll be in the typescript? or just try make it is fixed in the emc1-auto code that I stopped working on until we hash out the placement and CVS issues re: make/cat. not at the moment just try make ok if it does not work then I'll have you email me the post mortum so far so good if it dies, I expect that it will be versioning issues good. thanks well rcslib and emc1 build OK on slot 3 finally (after adding make clean to the build script) oh... this will take some time good to hear on slot 3! I think I'll copy that script over to slot 4 and see what happens cool! luck! sneakernet without the sneakers... all slots share one floppy drive, so I don't even have to move the disk ;-) probably not good to mount it from more than one slot at a time tho Does anyone have a feel for the current difference between emc2 and emc1 from a users perspective? What's not yet supported in emc2 that is in emc1? Hardware, IO drivers Is that really all? Wow. Cool! estop is commented out right now ;-) Haha.. well, estop is over-rated anyways. teleop mode error reporting (things like following error get logged in /var/log/messages, but not properly passed up and displayed to the user) lots and lots of small things that's not a very long list. Pretty cool. Lots of progress in a year! Should be some interesting new bugs to hunt down and there are about a thousand "#if 0 oops Yeah, well... that's always the fun... hunting down bugs "#if 0" and "FIXME" things in the code - stuff that is commented out for now, but needs to be re-instated and made to work config issues.... config is making great progress today! Alex has done some good work there. I mean emc config not build config oh, right... build config is making great progres * paul_c will do some testing on a 2.2.18-rtl-3.0 box later in the week.. the make is still going - I guess that's a good sign John, how is the compile coming along? ;-) 8-) Thanks, and yes I do consider that a good sign ;-) BTW, my alpha site is running on an K6. This has caused the module to have a couple of udedfined symbols. I expect that it is a lon long arithmatic issues with how the clock_add_ns (POSIX standard function) deals with the clocks. I'm running on a PIII, the alpha site is in Germany slot 2 is slogging thru the emcmot dir... encoder.c, pid.c, etc I'll leave you guys to it... jmkasunich: Do you want the logs for today ? not really... I wonder if we can get someone else to do that job... censoring email addys, general neatening, and posting a summary logger_jmk been playing ball today then I just can't face reading/editing thru all that again... not enough energy it is likely that the compile in on the modules. This is a good thing since they are close to the end of the compiles maybe a cron job to automate the task ? automate stripping email addys is easy automate a one paragraph summary of the day's discussions, not so easy Perhaps time for someone else to take on the task ? yes slot 2 still slogging onward * jmkasunich is running out of steam email me the results when you are done. I guess I will catch you later. Thanks for checking this. ok you leaving? no, I though you ere ;-) make that were no... watching a compile is about what I can handle right now just don't ask me to think 8-) I've had days like that more soup then, back in a couple hmmm... you still there john? yeah just shut down X on slot 3 I'm gonna leave the farm running tho the compile finished, but there was an error ok. what was the error? in the process of sending you the typescript Thanks. some symbol defined twice ahhh...