hi john hi alex what's new? not much with me I'm afraid busy with a manual machining job i see.. :) is the compile farm up? I think so * jmkasunich KVM's away to check it seems stuck to me (last build on 23.11) all three slots are up when was the last commit? last night hmmmm * jmkasunich looks at logs but also yesterday too the autoconf has been merged to the trunk and I was eager to see that it completes on the farm ooops sorry... seems that I was still looking at the autoconf tree instead of looking at the trunk ... silly me ;-) the logs show two compiles on the trunk, yesterday and about 01:00 today (GMT) yeah... I saw that it fails on Live the GTK stuff doesn't get compiled guess GTK is not figured out corectly can you take a look at what's happening? but it passed before the merge (I think?) yeah... on the last ./configure it worked in the build log: checking for GTK version... 2.0 ./configure: line 1: gtk-config: command not found ./configure: line 1: gtk-config: command not found yup is it really 2.0 GTK? don't know about Live... I think so * jmkasunich looks at the 11/22 autoconf branch build log hmmm - same message in that one the code is taken from the old ./configure so the error is the same les has quit and same errors when compiling ""meter.c"" - but for some reason the autoconf branch was logged as ""passed"", but the trunk one logged as ""failed"" yeah... i think default rule is different make continued after gtk failures picnet has quit I think I'd rather have make fail after the first error anyway, let's dig into it... I'll have to KVM over to that box let me commit some changes it seems I forgot to add some code the code is only for GTK1.1 1.2 give me 5 mins ok, I'll start the compile when I see the CIA message * alex_joni forgot to do a cvs up sorry it takes so long, but my connection is crap that's OK (I'm catching up on my email) Zathras have sad life, probably have sad death, but at least there is symmetry ;-) compile started on slot 4 is cradek here? No. Oh. No, noo. No no. You did not meet Zathras. You met Zathras. ;-) I was suspicious when Garibaldi showed up - but Zathras clinched it lol how does the configure look? hey les hello alex appears to be working - configure found 2.0, no warning message and meter.c compiled OK nice the make succeeded, results should be online in a minute or so like right now I do have an request for you ... if you got 5 mins OK the farm script for autoconf tree outputs Makefile.inc if my memory serves me right... could the same be done for the trunk now? if / when we'll get into trouble it makes it a lot easier to debug ok, I can do that are you happy with ./configure? ? * alex_joni thinks about closing the tracker at SF Oh... sure, close it... IMO, the goal has been reached - any future glitches can be addressed by bug reports question: should the farm continue to build the autoconf branch? note - it doesn't build the install branch - that could be done, but it's a bit of a pain good morning folks ""Good. Good. Zathras knew you would come. This way."" jmk: we need to talk about make install... best if we get a discussion going on the dev-mailing list OK if you have the time, you could take a look at make install (from the autoconf_install_0_1 branch) I am actually pretty happy with how it works but that's just me ;) jmkasunich: I don jmkasunich: don't think you'll see cradek up this early on a weekend, but maybe I'm wrong. alex - the old build script for autoconf logged Makefile.inc if ./configure succeeded, if it failed, it logged the config.log instead is that what you want for emc2head now? yeah that'll do it ok copy'n'paste the code to emc2head easier than that - I'll just make emc2head use the same script one line change in the update script, then run the script on all slots * jmkasunich goes to do that cool btw, thanks jepler, I saw his name, but no idea if he was really there BDI-2.18 has no GTK? dunno, let me check (btw, revised scripts uploaded to all slots - and I kicked off compiles on emc2head to test it great looks like BDI-2.18 has gtk, but not gtk-devel so for purposes of compiling, it doesn't have GTK i see ok.. then it's ok to fail the gtk stuff anyways but it's good that the overall build is not failing right - just skip the GTK stuff what's using gtk nowadays? yup the halmeter halscope HAL utilities, like meter and scope nice gimmiks ;) usefull for debug.. but you can live without them why do you say ""nowadays""? is GTK considered old? I hadn't seen anything more modern than Tk and athena in EMC, that's all. Compared to those, GTK is modern. most of emc was originally created 5 years ago I started the HAL stuff last year I wanted a GUI toolkit that was usable from plain C jepler: do you think there is a better toolkit out there? morning Ray! hi ray Hi John. Wow lots of folk. lurkers :-) and duplicates.... Heavy wet snow over night. Knocked out the power for 3 hours this morning. don't think I need this one anymore and loggers Almost missed us. snow is great... alex_joni: I really liked the pic of your yard with the meter of snow. yeah... can't wait to get there I'm using the SuSE box today. Got the firewall and apache running. using yast? Yes. I need help with routing though. can you be more specific? * alex_joni liked the yast-firewall up to a point the stuff yast does is pretty ok, but when you need to add/modify something.. it's a nightmare I'm on a dialup. Got it connected to ppp0. What's Suse like? Works fine on this box but the other network boxes can't reach through. ok... and you want the rest of the LAN to be able to use the connection? if you want I can send you a custom iptables-script I like quite a bit of it. There are a few differences that tend to confuse me. alex_joni: That weould be very nice. asdfqweg2: yast is nice, you have almost everything in one place * asdfqweg2 is using Mandrake, and is hitting limits of usefulness at the time I started (back at RH5.2) SuSE seemed like a very nice alternative I stuck with it still now now I'm thinking of giving deb a spin... probably the next one I install will be debian based I try doing something like compile a new kernel, and it futz' stuff up Paul has a deb that installs with anaconda. asdfqweg2: I had the same problem with Mandrake. asdfqweg2: the next BDI will be probably deb based I'm going to try debian, next I even tried patching their own kernel using hand patching. It would work for a while and then the whole system went away. Although I might try and see if I can use Knoppix to sidestep the installation tedium A central configuration tool is the thing I miss most about deb. Install knoppix, apt-get 2.4.27-adeos rayh: you can use the deb stuff on suse apt-tools never tried it thou... I need to look for deb Sarge on cd Yast sounds like Webmin on Mandrake The major difference is that YaST also handles things like install/remove and hardware config as well. All of my deb installs have been from Morphix or Knoppix. I've tried doing it with Knoppix, and it doesn't let me separate things into different partitions I don't know if it's really necessary, but from my experience so far, it's a good idea like /home /boot & such? yes not that nice.. ;) alex: ? not that nice that you can't separate things into different partitions my /home is on two hdb's Well, that was with Knoppix 3.3 - I've ordered 3.6 on cd I downloaded a Knoppix some time ago (over a year or so...) and if it still won't let me do it...well, there's gonna be some recoding but I didn't try a newer one You might like the next BDI... paul: I'm pretty sure I will...both the 2.20b and the Live rc46 are good same here although, I like the Live better ;) My main gripe with Mandrake is that they're very 'release' oriented Installation is nigh painless, but upgrading never works perfectly I just put kernel 2.6.9 on here - and I can't use my USB flashdrive anymore :( Which ticks me off, because now my PCMCIA is working correctly again :/ Makes me wish I could switch to Studly OS asdfqweg2: On my knoppix install I made a new user and that /home/xx dir is a separate partition. alex_joni: I don't have enough experience in many toolkits to say what the better or best toolkit is. I see... well there is a need for a halgui and I was wondering if there is better a simpler way than GTK... alex_joni: I have way too much experience with Tk (from tcl and Python) and it is just fine for a lot of purposes. This morning I've been struggling to reproduce a Tk window layout in glade as an exercise.. * alex_joni has no experience with toolkits but I'm pretty certain that if my first real GUI experience hadn't been Tk that I'd be singing the praises of something else. I know how you feel... The biggest problem with Tk is that there seem to be two choices of tree or multicolumn widgets: One, BLT, is written in C, seems to be unmaintained, and is prone to segfaulting. The other, bwidget, is written in Tcl and is *ahem* not speedy. I'm not sure how actively bwidget is maintained, either. jmkasunich: about your questions: I would get the rough sound from the steppers on most jogs at any speed. It does also happen while running a program. good morning cradek! hello good morning cradek * jepler goes to have breakfast. it's pretty early for us USAian night-owl folks jmkasunich: some jogs sounded right, but it's hard to tell from just sound. Some jogs would sound rough, smooth, rough, smooth, in a pattern like that so is emc2 working smoothly for anyone? It seems like this is a very apparent problem that everyone would notice immediately if they have it. (hope I didn't miss jmk) nope.. he should be back soon Might be worth doing a build on an RTAI patched kernel. paul_c: so is the answer to my question yes? you (or someone) is using it with rtai and it works right with steppers? since there are probably few people who have tried running EMC2 on a real machine, I'll comment. It seemed to run reasonably will on my BDI-live, AMD 1.3 GHz machine with steppers driving a ""mini-mill"". I've not hooked emc2 up to a mill. ... that should be ""reasonably well"" and the BDI was RC-46 SteveStallings: could you expand on ""reasonably well""? here's how I think anybody can reproduce it without a mill: build emc2 from cvs, run it, move the jog speed slider up to about 7, jog, look at the step pin with a scope. It looks terrible. I did not notice anything out of the ordinary with a program running, on the other hand I have always been less than impressed with EMC's response to the jog keys. SteveStallings: so your steppers sounded ""right"", just like they do with emc1? They did sound right to my ear. EMC1 has never been run on the same setup. My point of comparison has been TurboCNC and Mach2 on the same hardware. ok, maybe it does have something to do with rtlinux but we only have 2 datapoints... no, Paul Fox got this jitter behavior with rtai i'm running emc2, from cvs. i'm on debian (sarge), just installed late last week. i'm using an rtai dpkg that i got from paul (aka bdi-emc). it's a 2.4.27 kernel. the machine is a (this is from his email 22 Nov) I think what we need is some of you guys with o'scopes to try this I'll try next week. Machine is at the office. I will do more rigorous testing - note all the settings so you guys can reproduce it has anyone tried to reproduce the bug in my second email (unwanted jog after ESC)? you can even see it using sim.run I also planned to try that one. great SteveStallings: The lag between pressing or releasing the jog keys is a tickle update thing. cradek: sorry, I was away for a bit (wife got home, doing chores) I have run steppers (not on a mill) with emc2, no audible jitter well - no jitter that I wasn't expecting anyway ok, that's good (?) to know I will write up exact steps to reproduce this the stepgen module ""rounds off"" the ideal step time to the nearest actual interrupt but like I said, it was very apparent, so I bet yours won't do it if it seemed to be working right I understand there is a tiny bit of jitter when it's working right (the pulses shake around a tiny bit when looking at the triggered scope) but for me it was much more than that as you can see in my email pic. what was the scope time/div setting in that pic? cradek: so canned cycles weren't required for the ""hit ESC"" bug? jepler: nope jmkasunich: I don't know, sorry jmkasunich: I will reply later with the information you asked for in the mail. ok I have both halscope and a real scope, but I don't know if I can reproduce the problem ray - keyboard access vs. the effective buffering of jog moves is a tough problem to solve. Mach2 cheats, jog is a special case and it causes some problems with tuning because people tend to tune by listening to jog, then find that the regular motion engine behaves differently my main system is running RTAI (BDI-TNG) I have a compile farm slot running RTLinux (BDI-2.xx), but that has no parport jmkasunich: we can be fairly sure that at least one person is getting this behavior with rtai right - paul fox that makes me happy because I don't want to mess up my perfectly good emc1 setup there are diagnostic tools in HAL, such as the function execution time parameters, and of course halscope you would have to walk me through using those We could do with some CPU details and base period values SteveStallings: Interesting. I didn't know that. cradek: exactly - if you're not familiar with the workings that you are trying to debug, the tools are of limited use... I wish I could reproduce it here I have tried a separate loop time with jog and it works better. There is just to much to be done each loop to speed the whole of tkemc or mini up to where the jog response is good. jmkasunich: ok I am at the machine with scope and steppers at the ready is the speed problem related to the tkemc being interpeted? go ahead and start emc2 dave-e: Yes it is, in part. and open a couple spare shells A compiled gui might work quite a bit faster although there is still a lot to be done each time interval. jmkasunich: ready ray--can you link C to tk for time critical parts? Tickle has a very fast running event loop. If many of the display update things could be transfered to it, then the whole thing would work much quicker. Yes there is a rather well developed c interface. cradek: One quick question - What are the PERIOD & SERVO times ? How does the speed of the GUI relate to jitter while jogging? That is all happening async from the GUI there might be percived lag starting and stopping the jog, but that's a separate issue paul_c: the default from cvs, 0.000050 and 0.001000 ray--so it could be done with a lot of painful work. ;-) jepler: I think this is two separate issues If we could link tickle variables like the widget configuration stuff to C variables... jepler: there are two conversations going on at once - ray and steve are indeed talking about starting and stoping (which is common to emc1 and 2) and then register that variable with the event loop we would gain a lot of speed. cradek and I are talking about jitter, unique to emc2 perhaps cradek and I should /msg to another window? It would be more of a state machine. oh wow jmkasunich: Only if you log it... I am seeing DIR change while jogging! wtf? we'll stay here * jmkasunich studies ""core_stepper.hal"" cradek: With emc1 that would be bad tuning of feedforward. dir changes during the jog, or only at the end? during sorry for delays... I'm making the latest emc2 in one of your shells, cd to the emc2 dir then do ""bin/halmeter &"" I got a good capture of dir changing give me a minute to photograph it OK I'm expecting a guest in about 5-10 mins - they'll only be here for about 15 mins (just some paperwork) - just so you don't wonder if I suddenly dissappear ok I got a pic of it I don't have bin/halmeter halcmd, hal_parport, hal_skeleton you must be missing either GTK or gtk-devel bummer - that means you don't have halmeter or halscope - two usefull tools let me install them and rebuild installed, rebuilding... ok, I have halmeter/halscope now drat - my build of the latest CVS won't run damn that was fast fast machine ok, halmeter running, it shows --- and ----- click on select (or something like that) ok you should see three tabs click on params look for ones named xxx.time and xxx.tmax click on one this is killing me - I need to get my own emc2 running those aren't there OK, go to a shell type ""bin/halcmd show param"" that will give you the same list try ""bin/halcmd show param | grep time"" if that comes up blank, something is really wrong ok there are lots of them but they don't show up in halmeter? aha my fault did you take my ""xxx"" literally ;-) no, but I missed them somehow anyway I have motion-*time paroprt*time stepgen*time which family do you want? ok, the time ones show how long the last execution of each function took the tmax ones show the longest recorded execution time we want to look at all of them, look for tmax >= 25uS or so (25000nS) motion*time will probably be large, it is the servo loop parport and stepgen should be only a few microseconds because they run in the fast thread argh, I have to do them one at a time?? you could also to ""bin/halcmd show param | grep tmax"" to see all the tmax ones but for the time ones, meter gives you more of a ""dynamic"" look at what is happening for the tmax: they are all 6000-10000 except motion-controller.tmax which is 20096 ok, that's good still trying to get mine going dammit..... the math module isn't there that was working fine before, I'm afraid the autoconfig stuff must have broken it crap - that means I don't have a working emc2 here check out the tree from a few days ago I need to figure out how to do that or whenever you think it was working for you * jmkasunich digs out the cvs book it's snowing (well, just a tiny bit) cvs up -D ""2 days ago"" cvs co -D ""a fortnight ago"" jepler: get used to it! sounds like we're going to get nailed cradek: yeah, see you at work as soon as it thaws updated, and making how much snow? I have ""axis speed"" set at 6. sometimes I get a nice even jog. but usually it sounds very rough and I see it randomly reversing the DIR bit on the scope. 5"" tonight ok, let's try to capture it using halscope ok, tell me how guest just arrived, back in 10-15 mins see hal_introduction.pdf on linuxcnc.org if you want to try yourself ok I captured parport.0.pin-04-out and pin-05-out during a rough jog they don't look at all reasonable cool, I caught one when it switched from a good jog to bad jepler: now I hear 8"" tonight away for a while, will remain logging.... Where are we expecting snow? NE We got our's last night. it usually doesn't bother us, we're used to it, but this is the first of the year and it will be relatively big where? ray is in Michigan, right? I kinda hope snow stays up near Ray, and doesn't come down to Ohio for a little while :) Yep. The UP. Near Marquette. * alex_joni completed his civic duties I'm about 130 miles north of Green Bay, Wisconsin. ray: got that email? No I didn't. I tested with an email from dave-e and got his. hmmm.. didn't come back either got a skiff of snow in Muncie the other day.... now I'm back trying to adjust for the 3 hr shift. no snow here....had been some on the pass (Snoqualamie) and a few remodeled cars but we made it home OK. nice warm 20 degrees and sunshine here. gotta go ... seeya! dave-e has quit I am also getting ""one step forward one step back"" regularly at about every 4.5 seconds when sitting idle cradek: that's normal it's the hunt for the zero position * alex_joni was just reading through the logs... math is broken??? jmk said he will be right back I'll have a look at the farm Hi all hello Martin Hi Alex darn, I have to go jmkasunich: we'll have to finish working on this later I'll try to fix the math stuff till you're back jmk: say when back... acemi has quit I'm back - sorry it took longer than expected I'm here for about 5 mins... so no problem only problem cradek had to leave... yeah, I saw you said math support is broken? yeah the old config did the following: Testing for a suitable libm... Some symbols may be printed. __errno_location __isnan fputs stderr can you paste me the Makefile.inc ? Using glibc libm with mathstubs. maybe in a sep. window? from the latest one, or the older one that works? * alex_joni wonders why libm is needed on rtai ? the module doesn't work? the Makefile.inc from the old ./configure (not autoconf) ok pinging paul_c... jmk: what's failing when running? modules fail to load because symbols like sin, cos, etc are undefined does rtai_libm get loaded? dunno, let me check I changed my emc2head tree to 5 days ago to get it to work maybe the order in rtapi.conf is not right? just did a make in my emc2auto tree, I'll try there ok not really ok... that's the make test one :( try checking out in a different dir ok - that will take a moment * alex_joni is reading configure Sounds like the math test is failing... Got the Makefile.inc to hand ? old one or new? both paul: seems that on the old configure libm is used with mathstubs on the new only rtlibm is assumed I will email both Makefile.inc files to both of you should it work on rtai.24.1.x ? (only with rtai_libm.o ?) mail is on the way I might be wrong, but I think rtai_math.o is for RTAI3.x and rtai_libm.o is for RTAI24.1.x can you paste me the rtapi.conf from scripts/ ? should only have a few lines can do there should be a rtai_libm at the end there is, on both yeah.. but on the old version it wasn't used I can paste if you want, but there are no differences, except that one doesn't set MAN_DIR, and of course they have different EMC2_HOME directories ok... thing is I have RTAI3 here, and there's rtai_math not rtai_libm * jmkasunich is trying to test the old one, and do a lsmod do a scripts/realtime start and check if rtai_libm gets loaded nope but I was able to successfully do ""bin/halcmd loadrt siggen"" (siggen uses sin and cos) and confirmed that the same process (realtime start, loadrt siggen) fails with the current version well... it fails because the configure assumes that rtai_libm gets loaded and siggen finds sin and cos from there methinks that on this box at least, the modules themselves should have been linked with standard libm - I'm not sure there is a rtai_libm one has been found please check if it really is there where? in /lib/modules/$KVER/rtai/ e.g. /lib/modules/2.4.18-rtai/rtai modprobe rtai_libm modprobe can't find it how about insmod ? there is no rtai_libm on this box - the old configure _correctly_ decided to use libm instead please check also: /usr/src/rtai-24.1.10/modules/rtai_libm.o or insmod /usr/src/rtai-24.1.10/modules/rtai_libm.o ls /usr/src/rtai-24.1.10/modules gives: rtaisyms schedpref this is the test that successes: if (test -r $RTDIR/modules/rtai_libm.o ) || (test USE_RTLIBM) || (test -r /lib/modules/${KERNEL_VERS}/rtai/rtai_libm.o) ; then $RTDIR = /usr/src/rtai-24.1.10 ${KERNEL_VERS} = 2.4.18-rtai * jmkasunich wonders about USE_RTLIBM that gets et only for RTAI-3.x s/et/set/ I'll add some echos to ./configure around that test (break the three way OR into three individual tests) if (test ${RTS##*/} = rtai-config ) ; then" if (test -r $($RTS --module-dir)/rtai_math.o ) ; then" USE_RTLIBM=1 fi fi any more info from the ./configure output? hmmmm.... in that three way OR.... the second one passed (even tho USE_RTLIBM is blank) methinks perhaps ( test USE_RTLIBM ) isn't right, perhaps it should be ( test -n USE_RTLIBM )? * jmkasunich tries it I'll change it to test USE_RTLIBM=1 -n didn't work place a echo $USE_RTLIBM before the test did that, that's how I know it's blank hmmm * jmkasunich double checks it test shouldn't be can't seem to get that behavior on test here found it yes? need a $ in front of USE_RTLIBM ?? :(( now that's emberassing... we've all done it make in progress, we'll see how it works ok much better the real fix needs to be applied in configure.in, right? (I was editing configure) yeah then you need to run autoconf and commit configure.in and configure I don't have a working autoconf here can you change and commit? sure working now? doing the cvs up configure looks better, make in progress * paul_c is off to feed the animals... paul_c: you have a farm too? so jmk is not alone with his farm... ok, emc2 is running here now (from latest CVS) * jmkasunich has to empty the clothes dryer, then I'll try to duplicate cradeks jitter problem nice to hear that... I think I'll leave for a while, get a byte myself... jmkasunich: im reading at the moment a bit how the motion controller is working there is a lot of stuff commended out when do you want to remove that stuff and about screw error compensation, there is up to now no code for that, or ? the commented out stuff can be removed once we're convinced we don't need it some could probably go now, some should stay for a while the screw error stuff consists of two parts: user space code to build a table, and motion controller code to interpolate the table and generate the compensation I can do the latter rather easily the former already exists somewhere, but the table format is very poorly documented it needs a chapter in Code_Notes describing how it works, and then needs coded to match on my ""to do"" list, but not real high right now ok the motion code is writen a bit like code for PLCs what do you mean? every function is executed and the funktion itself has to decide if it has to be execuded for example homing, that function is executed in every cycle that is a common way of doing realtime coding the code runs every mS, whether it has something to do or not ok a homing sequence may take many seconds, but other stuff must continue to be updated then i do it the same with the gantry stuff so the homing code maintains it's own internal state information. When it gets called every 1mS, it does whatever it has to do, then returns so that other things can be done jep, i see i was just wondering about that Ah-HA! I've duplicated cradek's problem... now to investigate yay well... if you don't specify stepgen.x.maxaccel, then you get the jitter that he saw if you do specify an appropriate value, it works fine (and the CVS versions of the ini file don' don't specify a value - not his fault) that gets back to one of HAL's weaknesses - config info People are always asking about USB devices, mostly parallel port devices to drive steppers with. There are these chips, such as ft252 which have a ""clock data out at this rate"" mode, and a small buffer (128 bytes). It seems like you could have one of these drive a 4-stepper system as long as you do the USB output in real-time" 128 byte buffer is over 1/8 of a second - that is hardly hardly ""real time"" wouldn't it be a lot less than 1/8 second? But anyway, you don't need real-time feedback from the steppers, so if you could queue up the motions a half hour in advance it would be just fine. emc writes new data to the parport on every period of the step generation thread - that is every 50uS using the default config those USB abortions that they call "parallel ports" are nothing of the sort they should really be called ""printer ports"", because that is all they are they add a _huge_ pile of bloat and protocols between the code and the real world Yeah, it would not be fun to write a USB stack again a real ""parallel port"" is accessed with an IN or OUT assembly instruction (possibley contained in a C inb() or outb() function), and the actual output changes ""instantly"" - ie less than a microsecond later, sometimes much less - 10s to 100s of nanoseconds but ft252 does have a mode where it could clock out a byte every 50uS as long as its FIFO is kept full how about home switches, and estop, and etc The toy I use doesn't have home switches. still - you are talking about using a non-realtime driver to buffer realtime outputs, send them over a comm link, and have them unbuffered at the other end The ft252 ""bit bang"" mode can designate certain bits as inputs, when you read it you would know exactly when the edge of the home switch went up compared to the stepper commands all I can say (as someone who likes embedded and realtime programming) is YUCK! of course, I also like the ISA bus instead of PCI ;-) can't get many computers like that anymore ISA you mean? yeah true enough and PCI isn't so bad once you get past the discovery stage anyway, isn't the ISA all on the wrong side of a PCI bridge from the CPU, even on Pentium II-era PCI/ISA machines? yes, but the ""wrong side"" of the bridge is still a sub-microsecond delay 33MHz PCI to 8MHz ISA translation probalby only takes 125-250nS if you are thinking about optimizing the performance of a 2GHz CPU, 125nS is an eternity (250 instructions), but compared to the latency in something like USB, it's really fast the problem is that the PC has been optimized out the wazoo for fast ""average"" performance - pipelines, cache, etc but those things hurt latency a 33MHz 80386 can have better latency, because it isn't hurt so bad by things like flushing cache lines and pipelines on every interrupt Well, the design is perfectly appropriate for stuff like word processing & games (where your worst problems are keeping input, video, and audio in good-enough synch that humans don't notice any problems) exactly - the PC has been optimized for PC type tasks, not for realtime control the same is true of USB there are two reasone why PC based controls beat dedicated controls: 1) very low cost because of mass production 2) processing power 10-100 times more than is needed, making some inefficiency for the task tolerable because of massive overkill Yes, now with the other 90 to 99% of the processing power you need to add real-time CSG preview of the work the mill is doing. not me no, not you specifically ""someone needs to add"" I know but my point was partly that the 90-99% is not available - because the PC architecure isn't optimized for low latency, etc, significant cycles are lost, and it takes a lot more CPU to do things than it would if the hardware was designed specifically for machine control A dedicated Z-80 can do some things better than a 2GHz P4 simply because it is dedicated and of course dedicated hardware can do even more example - LS7166 - encoder counter chip, costs around $10 (I think) it can count encoder pulses faster and more reliably than software running on a $2000 state of the art PC hi alex hello found the cause of the jitter * alex_joni is watching election results... that's GREAT news what is it? the existing config files (specifically core_stepper.hal) do not set the stepgen.x.maxaccel parameter aha.. " the stepgen module contains a ""pre-tuned"" PID loop, but it gets its ""tuning"" from maxaccel...." and because that was not set... the internal PID went berzerk emc.ini contains a max accel parameter, but that is in inches per second squared, and the HAL stepgen module is unaware of it - the stepgen maxaccel parameter is in steps/sec^2 so maxaccel should get calculated from the value in emc.in ini but first it needs converting right? steps/inch should be known in emc.ini INPUT_SCALE / OUTPUT_SCALE more complicated than that, unfortunately right now, emc2 doesn't actually use either INPUT_SCALE or OUTPUT_SCALE I know that... we've been discussing that a few weeks ago * jmkasunich commits a quick and dirty fix for now When does jitter become a problem? always ;) jitter is wrong ... it's not really jitter here - that is a red herring it was actually PID instability I've been kinda following what's been going on, and I think I had possibly something similar happen to me with emc1 But that was because I hadn't done the tuning on a per axis basis [but I digress] I've read about the timing jitter in emc, and seen the charts Like I was asking...at what point does jitter become a problem? Never mind that question...I'm tired and not thinking straight jmk: busy? I'm here what's up? was wondering if you got time to talk a little bit about what could/should get done I suppose I added a tracker on SF but I think I should remove it, I managed to get make install work without that one I was wondering what else on a to-do list is HW drivers make install config issues, I think documentation, documentation, documentation is there documentation on the autoconf stuff needed? I tried to document the file itself I haven't read thru the file in detail, but what I've seen so far seems pretty good configure.in seems _very_ well documented well thank you ;) I tried ... is Makefile.inc still stored on CVS, or is it now always created locally when you do ./configure? jmk: a LS7166 is a little more expensive ;) Makefile.inc is generated by configure so the original one has been deleted from CVS? before configure is run, there is no way a clean checkout can be compiled but it's not created from scratch anymore like it was first (using echo > Makefile.inc) now it is created from Makefile.inc.in by replacing the proper values duh - I forgot about the echo > Makefile.inc stuff - it never was in CVS yup that's why we (me & paul) asked you for both files because both were created on your machine * alex_joni bought some LS7166 with 16 squid / piece * jmkasunich was just using it as an example - still lots cheaper than a P4 ;-) yeah.. and a thousand time more reliable I used at first some simple counters (24 bit) also HW but the LS just works more reliable (does a lot of filtering & such) perhaps some comments in README about how we used autoconf, explaining the relationship between configure.in and configure, and between Makefile.inc.in and Makefile.inc? that sounds resonable maybe it's time for an INSTALL in the top level directory? neah... I disagree to go with README and COPYING, etc? INSTALL is far from decided well INSTALL is usually the file where you read installation instructions yeah (avoids cluttering up README with such details) well right now you have no installation right? but I agree a INSTALL file should get eventually added but most programs I've downloaded have building and installing instructions both in INSTALL right now it could only say: install issues are not decided yet building too? yeah hmmm.. that could be... * jmkasunich checks how is the message at the end of ./configure? does it sound ok to you? seems OK to me... some purists won't like it - some folks really don't like boxed comments well... it's easy to read like that and to separate it from the normal ./configure output I like them myself, have used them a lot in my code I just checked a couple of packages here (IIRC, modutils, etc), and the INSTALL file contains all instructions for building and installing I'll mail you a couple samples I opened my devel box ... having a look at some sample apps * alex_joni agrees on INSTALL I am reading about make distclean re: the message at the end of configure... that should get added to Makefile yes? I'd recommend telling them to do make, followed by a separate line to run it (or install it) instead of ""make && scripts/run"" ok compiling: make they'll likely have to be root to run it running: scripts/emc.run those details could be in INSTALL anyway emc.run will tell them that they need to be root * alex_joni is starting INSTALL lol... I love this... ""If I were you, I would not trust a make install. If you feel courageous, just do make install. It may even do the right thing."" taken from INSTALL (wireless-tools) lol that's so ... appropriate * jmkasunich has to work on some actual metalworking now ;-) finishing up the Z-axis ballscrew mechanism for my CNC conversion which I haven't touched since over a year ago :-( ouch need to use the machine... the old Z axis mechanism (rack and pinion, like a drill press) has been removed, and the new one isn't finished yet seems that standard is like this: Additionally, the INSTALL, NEWS, README, COPYING, AUTHORS and ./ChangeLog files need to be created I've been using my Van Norman mill for all milling since then, but it doesn't do small mills will (like 3mm) cause the spindle is too slow README and COPYING are there already (I think) the others can wait a while probably yup a GPL-info should be placed at the begining of configure.in... right? probably maybe just a one liner: ""this file is released under the GPL, see COPYING for more details"" ok.. will add that too Most of the files are already in docs - No need to clutter up the root dir with duplicates ahhh... they are (including an empty INSTALL) then the top level README should be changed to point the user to the files in /docs (there is some build info in README that should be moved to INSTALL * alex_joni moves the INSTALL to /docs and COPYING can be deleted from the root - It is just duplicate there is a README in docs/ should README from the root be removed aswell? remove the one in root.... ok or reduce it to one sentence ""Please see docs/README"" ok IMO, README in root is the first place folks will look - don't remove it I'll go with the see docs/README approach you can reduce it to one line, but why not eliminate the one in docs instead because all other files are there INSTALL, COPYING, AUTHORS well.. actually I'm ok with either one either /README or docs/README many programs have all of those files in the root dir hi I just requested to join the emc user group ,but I have received an automatic answer saying there are problems .Can you clear them? thanks Mario Zito It reduces the cruft in the top level dir. what problems? true - but don't reduce it to the point that the newbie can't find it paul: what do you think of ""If I were you, I would not trust a make install. If you feel courageous, just do make install. It may even do the right thing."" Ignore the previous lines - cut'n'pasted the wrong bit.... I already replied to Mario, asking him to send the error message he got * paul_c added his name to the list and blamed any probs on the SF servers.. I saw that - paul_c is kinder than me ""if you can't do it yourself, I'll be damned if I'm gonna do it for you"" alex_joni: If ""make install"" is unpredictable, then it should NOT be enabled paul: that was a quote from another software he's was quoting from the INSTALL file of another package (wireless-tools) I'd never put such a statement in a file... I'd rather remove the broken functionality ok.. so README in root or in docs/ ? or both for now? docs/ with a one-liner in root The only need for a README & INSTALL in the top level dir is to keep automake happy. but there is no automake... so ... we can skip this step But that can be done by the configure script IF it is needed. I disagree - they are there to help HUMANS at least the first README is So point them to the docs/ newbie software install process: download, untar, read README, read INSTALL, install.... once they're no longer newbies, they might skip the README and INSTALL steps, but it is at their peril, especially for stuff like EMC that needs a realtime kernel ok I added some info, and changed some.. I'll commit now does INSTALL sound ok? copied it from another package? some parts it is a standard INSTALL for autoconf-enabled packages 3) to run the software issue: scripts/emc.run should tell them they need to be root (and maybe why: ""because EMC installs kernel modules to handle it's realtime functions"") changed * jmkasunich seems to have misplaced a set of 6"" dial calipers I hate it when that happens - they're probably right in front of my face, but I can't seem to find them * alex_joni hands over a locating device * jmkasunich lost the locating device found 'em probably it's just next to the caliper * alex_joni wonders who will take a look at make install... in the box, where they belong - I could of sworn that box was empty 5 minutes ago * jmkasunich needs to get this ballscrew finished this weekend THEY must have put it there yeah... and paul is busy on the BDI (which is more important than make install right now) jmkasunich: thanks for fixing my bug, I'm going to go test it soon jmkasunich: I submitted the unwanted-jog-after-ESC to the tracker.