morning Good morning all hello sawyour post about steppersegmot good you are working on it .good evening les: it appears to be working for me now any forst impressions? first les: it seems "the same" so far les: maybe I have my max accelerations set too low Same is good, that means it is at least working. that's a good way of looking at it I ran a sign at higher speeds for pocketing and had some problems... at lower speeds it was fine I have traked it down to some issues blending circular moves at high speeds.acel I will shoot a report to Rogier it's a planner math thing I noticed it may not have been as smooth where the backlash kicks in when cutting a spiral freqmod with G61 did it perfectly - I will try steppersegmot with G61 too I am not sure of the effects with backlash comp I don't use it...my system is all mechanically preloaded I've been working on a way to do that with my machine, but haven't actually built anything yet just $$$ haha was the spiral g2 or g3 moves? no, it was very small g1 hmmm and it ran in g64 choppy? I only did a bad test: freqmod/g61 and seg/g64 seg/g64 had some glitches at the "quadrants" freq/g61 was perfect I need to try the other four combinations for a real test err, other two If you see a pattern with later tests I will try to duplicate it ok If it was G1 segments, how can quadrants matter? that's where the backlash has to kick in when the axes reverse dir It should not matter unless it is backlash comp OH :-) open loop backlash comp only works with systems with high friction or very small cutting pressure compared to the table mass, I assume well if friction is low compared to inertia the thing will unpredictably bounce all over the place galil has a good multimedia presentation on the subject on their site but you have to register cradek - Is it safe to assume you have looked around the SourceForge site enough to be aware of the EMC2 development fork? yes Great, the guys can use all the help they can get with build processes as the amount of cleanup is massive. yeah, I've noticed it's not an easy build. Truely intimidating to us novices. I would like to fuss with some low level driver stuff, but don't have the nerve to try until EMC2 can be used as a test platform. so is anyone using emc2? what's the status of it? EMC2 is still in its infancy. It started as an effort to clean up and simplify the code. John K. jumped in with a great concept for hardware abstraction and has it mostly done. Paul Corner had a go at simplifying some of the libraries. Now John K. and Matt Shaver are trying to get it all stitched back together. The organization of the code will be much improved, but still fairly complex. EMC2 has been run as a whole, but with lots of stuff stubbed out. I looked briefly at the hal and it looks very nice (configurable) John K. comes from the world of real time on small micros (as do I). I hadn't done anything with it until now I am hoping that EMC2 gets up and running so that we can focus development there and leave the original EMC in some sort of stable state. I think rtlinux is slick. You can run whatever on the machine in nonrt and the mill never hiccups SteveStallings: How long will it take? SteveStallings: it's hard to have two branches, because everyone is still using the old one and so they want their features there cradek - Yes two branches are tough, but there are VERY few people willing or able to work on the EMC code in its current state. It is hoped that EMC2 will modular enough to make many more people willing to contribute. erdizz - How long? We will not know really until we get there. My guess that the truly adventuresome could be running a system by the end of the summer. can someone tell me about what percentage of people using emc are using steppers? I'd say the vast majority really. I got the impression I was one of the very few to have a simple machine with steppers I found another servo user from that post to the developer list yesterday with the big mill in belgium EMC does not have a good way to "discover" the users, they just have to announce themselves. At the last conference we batted this one around and figured that 90 to 95 percent were steppers. The developers tend to be more advanced users interested in servos. the homing behavior without switches was only very recently fixed, and it still requires a define and recompile I mailed them and asked if they wanted to test the new planner they are using ac servos huge machine The homing behavior was one of the things tackled at the conference. It was great to get several developers in the same room with a running machine and just bash it out. I watched in wonder as Matt and John hacked at the code. Finally I went out into the lobby and curled up on the sofa at 2 AM. If emc had an affordable interface servo would be used a lot more J elson claims $250 now url? Note, when I said 90 to 95 percent steppers, I was including step/servo systems like the Gecko and Rutex as steppers. have to dig I looked into STG and couldn't believe the price at nearly $1000 and, of course, that it requires ISA which is practically extinct http://pico-systems.com/motion.html bookmarked! My interest in low level drivers was precisely because of the servo cost issue. I am using stg My hope is to come up with a USB or Ethernet solution at a reasonable cost. really not happy with the isa steve: USB 2.0 would be plenty fast enough SteveStallings: won't USB have big latency issues? old usb would have servo update 500 hz max I think USB 2.0 is faster for bulk data, but has the same packet rate as the original. Remember me quizzing you about impact on feedback loop? usb 2 would be 2kHz 4 kHz packet rate right? Sub-packets..... turn around time is the same. The question is still, is 500Hz fast enough to be useful to most people? Well one servo cycle would need one communication to the device and then one read 500Hz is too slow And can Ethernet do better than 500Hz reliably? The old Allen Bradley systems were only 25 Hz, but expectations were much lower then. I don't really understand sub packets... but if old usb has a 1 khz frame rate... For us router guys 2000 to 10,000 servo updates/sec is the norm these days SteveStallings: the prob I see with both ethernet and usb is realtime compatible drivers (on the pc side) for a bridgeport 1000 works fine I just agree with jmkasunich There is an Ethernet packet driver for rtlinux. Work on USB was being done but dead ended when the grad student moved on, trail went dead. re: the rt ethernet driver - does that work for any NIC, or only the chipset he wrote it for? ethernet is CSMACD so you cannot have full control over latency no matter what software you write nic and usb chipsets are moving targets - if we can't leverage the "normal" linux drivers, we'll always be playing catchup I think it was derived from the Clarkson drivers and would be available for things that emulate the NE2000 or 3COM chip sets. cradek: not true, IFF you dedicate a NIC to machine control and have a point to point cable then you in effect have a master slave half-duplex line cradek - Latency issues would require a point to point Ethernet link. CNC users will just have to accept that as the cost of a dedicated machine. I think right now emc can do about 10kHz update on a fast machine jmkasunich: ok, point taken, I didn't know that was the plan there is no plan ;-) just lots if ideas Chip sets as moving targets are indeed a major problem. For that reason the USB may never happen in real time. Ethernet seems to have lots of support for legacy chip interfaces. Well..a bunch of timing jitter would muck things up for sure are you guys wanting to move away from parallel ports because you think they may become extinct? Or is it just the small number of available bits? there are those who believe parports are becoming extinct well they certainly are on laptops I'm afraid they may be right, and it sucks because the parport is an ideal interface (not plain parport, but EPP mode) cradek - Mostly because they are going away. Jon's boards already get past the number of pins issue by treating the bi-directional port as a data bus. EPP mode is beautiful - just like a simplified ISA bus but a cheap pci digital i/o only board could be made to work do those pci parallel port cards work with linux? not sure how fast les: also not an option on laptops - not that I would encourage laptops for machine control Pretty soon most PC's will not even have a PCI slot. ugh no pci? ..so they'll provide another way and the question will fall Trend for consumer PC's is to connect everything with serial ATA and USB. erdizz: everything will be usb Les - USB 2.0 is still 1KHz frame rate, with 8 "micro-frames". I see so it would still be linited to 500 duplex communications/sec? Correct. well scratch that then Not so fast.... it could still serve a significant percentage of users. that's off the list! Ethernet does seem more promising still. awfully slow steve Remember, most users will be comparing performance to stepper systems of the slap together kind. Steve:What could be done with ethernet with minimal timing jitter? minimal=<10% Not sure about ethernet. Probably in the 2KHz range. Jitter would be controlled by having the servo interface be the "master". same speed regardless of axes? I'd be more inclined to make the PC the master Probably, packet size is still relatively small for any reasonable number of axes. as long as all the axis are in one box, thus one packet Sampling jitter would be better controlled at the servo interface. if you start thinking of one box per amp, gets more complicated Yes, I was assuming all axes in one packet/box. That would be best with emc (PC) as the master, even one box per amp works I know this flies in the face of extensibility, but I like practical simplicity. most of us do... haha The beauty of the HAL is both could be supported. EMC2 relies on hal/rtapi, which at this time doesn't allow for syncing tasks to an external event, only to time so servo as master is problematic but PC as master would be fairly straightforward Yes, timing is an issue. That is why I keep bringing up the topic of bottom up timing at the conferences. in the real world, jitter is the same for both cases (IMHO) Jitter would be the same only if all latency was constant. case 1: timer interrupts CPU, unknown latency, then code executes and delivers new data to HW case 2: servo amp causes interrupt, unknown latency, then code executes and delivers new data to HW unless in case 2 you buffer the new data and apply it to the HW on the NEXT interrupt Jitter is minimized when the data sample and the control output are in lock step with a fixed frequency clock. when PC is master, that clock is the timer interrupt There are many variable latencies between the timer interrupt on the PC and the actual I/O events at the servo interface. fortunately an encoder is not jitter prone true - but most of them would also apply in case 2, _unless_ you buffer the resulting jittery outputs and apply them to the HW on the next interrupt what are the pros/cons of delay vs jitter? Interrupt in the PC and interrupt in the servo interface are not the same event. delay causes instability lower gain bandwidth product SteveStallings: right... with the PC interrupt, delaying to de-jitter isn't an option but if delaying causes more trouble than jitter, then why bother? it's a matter of degree I guess The servo interface needs a constant interrupt rate so that the sample interval is constant. Variable latency between the PC interrupt and the events in the servo interface will cause the sample interval to vary. We generally run servo bandwidths much much higher than mechanical bandwidth a concrete example - assume 1mS servo period... in case 1, the interrupt happens every 1mS, encoders are read 10-20uS later (10uS jitter), and DACs are written 80-120uS after the interrupt (40uS jitter) les - How much sample interval jitter is acceptable on a percentage basis? compare that to case 2, where encoders are read at interrupt + 0us (no jitter) and DACs are written at interrupt +1000uS (also no jitter) I would guess 10% if it is random time jitter is position jitter Sound like PID is much more tolerant of jitter than signal processing that I am used to. d/dt for velocity jitter and another d/dt for acel jitter I think hence the use of low pass filters in servo controllers emc has one not documented too well les - Any guesses as to John's proposition? That is (as I understand it) a fast sample/result cycle with jitter versus a slower, but very stable sample/result cycle. you mean on the D term in pid.c? "smooth d" i think? it's a short FIR low pass I think But there is very little I know about it other than a few rems in the code #define SMOOTH_D_FACTOR turns it on, seems to be a moving window average (so yes, a short FIR) right rectangular convolution if you say so... Morning Ray - Just to help you catch up, we have a new participant, cradek, who has tackled code changes to stepper drivers to merge segment queue updates. wassat convolution stuff? ;-) I can say this...a configurable low pas and notch in a pid system is a good thing les will be writing pid2.c for hal soon ;-) haha well I do have my digital filter design guide on the shelf here I hope - that's what HAL is all about - allowing plug in replacements for standard modules Hi Steve. I'm reading the make paper right now that Chris suggested. cradek: yes, that's a good paper - I ran across it right before NAMES (jmkasunich/#emc) originally a discussion of autotools was on the agenda for fest, but we ran out of time (rayh/#emc) I do see a lot of makefile twiddling both in emc and emc2. (jmkasunich/#emc) emc2 is trying to use the ./configure approach, but to date has not used autotools to generate ./configure, instead it's handcrafted bash script (jmkasunich/#emc) Paul was studying autotools, and when he gets back from his vacation, we'll probably look closer at them (jmkasunich/#emc) IIRC that paper said that you can use autotools even if you want a non-recursive make (jmkasunich/#emc) one thing we (emc2) are adament(sp?) about - no PLAT! (jmkasunich/#emc) ./configure should figure out the platform (rayh/#emc) Paul did not present his thoughts on an auto make system at fest. He did say that he was having a great deal of trouble with the applications. (jmkasunich/#emc) rayh: my impression from emails and IRC was that he thought it was the way we need to go, although the way may not be easy (jmkasunich/#emc) from my limited study of the subject, I'm inclined to agree with him (jmkasunich/#emc) not looking forward to it, but I think it's the right thing to do, and will do what it takes to pull it off (jmkasunich/#emc) I would like to hear cradek's take on it though - he has done make systems before professionally, which is more than I can say (rayh/#emc) Chris mentioned in his recent mail that he had developed a different approach for his company. I wonder if his thinking while doing that would help us? (cradek/#emc) In my opinion autotools are good for figuring out the peculiars of many platforms. Because we're tied to rtlinux we don't need that. (cradek/#emc) we only have one platform, linux (cradek/#emc) (or am I wrong?) (rayh/#emc) cradek: What about the many kernel and rt versions? (jmkasunich/#emc) actually we have many platforms... kernels 2.2, 2.4 and soon 2.6, and using both RTLinux and RTAI for realtime (cradek/#emc) ok, scratch that then (rayh/#emc) And at least two versions of rtai. (jmkasunich/#emc) we also need to verify the presence of dependencies like Tcl/TK and GTK (jmkasunich/#emc) cradek: when you get the chance, take a look at the existing emc2 build system (cradek/#emc) I wonder if anyone is using the configure that generates a non-recursive build (jmkasunich/#emc) I'd like to hear what you think about it (don't hold back - I know it's far from perfect, and am quite willing to change it) (cradek/#emc) jmkasunich: I will (jmkasunich/#emc) after reading that paper, I like the idea of non-recursive build. But before NAMES I was in the throes of writing a HAL doc, and now I'm in the middle of trying to get emc2 to work (jmkasunich/#emc) hopefully build process work can proceed in parallel tho (cradek/#emc) jmkasunich: my real-world experience is that converting from recursive to non-recursive changed our build times from hours (overnight usually) to around 10 minutes (jmkasunich/#emc) wow (cradek/#emc) jmkasunich: it also has eliminated the bad builds we had (we sent out broken releases because things were compiled wrong) (jmkasunich/#emc) stuff that didn't get re-compiled even though it should have been? (cradek/#emc) right (cradek/#emc) wrong dependencies (jmkasunich/#emc) I've seen that with emc2, fixed one makefile bug that cleaned up most of it, but the risk is still there (cradek/#emc) jmkasunich: as that paper shows, it's nearly impossible to get it right (jmkasunich/#emc) you _must_ run make depend if you have changed any #include lines (cradek/#emc) jmkasunich: make should figure that out, there's no need for the programmer to do it (cradek/#emc) jmkasunich: you use the .d files and have simple make rules for generating them (jmkasunich/#emc) one advantage we have is that we're not so huge - make clean ; make depend ; make takes about 10mins here (600MHz PIII) (cradek/#emc) jmkasunich: gnu make checks for any included Makefiles being out-of-date, and if so, it generates them and then restarts (cradek/#emc) jmkasunich: yeah, at work that used to take around 24 hours for all platforms! (cradek/#emc) jmkasunich: **with a compile farm** (jmkasunich/#emc) and I thought emc2 was too big (cradek/#emc) we had "planning to change an include file at 5pm" emails (jmkasunich/#emc) btw, I have something resembling a compile farm here, that I want to get set up one of these days (cradek/#emc) jmkasunich: look into distcc (cradek/#emc) once your Makefile is right (nonrecursive) it's trivial to use (jmkasunich/#emc) I want to use the farm to do parallel makes on different installs (RTLinux, RTAI, 2.2, 2.4, 2.6 kernels, etc) (jmkasunich/#emc) with reports to the commit list if one of them breaks, so the guilty party can fix it (cradek/#emc) oh, I thought you meant parallel build of files all on the same architecture (cradek/#emc) that's what distcc does (cradek/#emc) (actually I use it with cross-compilers but that's a different story) (jmkasunich/#emc) we're small enough that we don't need that speedup (cradek/#emc) right (rayh/#emc) I'm on page six of that paper, lost as usual, but absolutely convinced that some of the issues it demonstrates are problems that have rather regularly occurred with emc. (jmkasunich/#emc) rayh: definitely - I recall saying to myself "yup, seen that before" several times while reading that (jmkasunich/#emc) need to re-read it one of these days (cradek/#emc) I have to run, guys - I'll read the rest of the meeting later. (jmkasunich/#emc) bye (rayh/#emc) I'm aware that we have narrowed the focus of emc2 a lot. Linux, rthal, adeos, rtlinux. (rayh/#emc) In that narrowed focus, have or will we have any provision for expanding it to other possible systems without a complete rebuild from the ground up. (jmkasunich/#emc) depends (jmkasunich/#emc) IF you can write a version of RTAPI for the new system, you should be all set (jmkasunich/#emc) in theory (jmkasunich/#emc) however some things are assumed throughout the project - for instance kernel modules. We assume that realtime code is in kernel modules, and that they are installed using insmod (jmkasunich/#emc) if you have a RTOS that uses some other method, you will have a _lot_ of changes to make (rayh/#emc) I can see that. (jmkasunich/#emc) and those changes will make things vastly harder to understand for the 99% of the world that _is_ using kernel modules (rayh/#emc) Was all of that done in ifdefs in emc? (jmkasunich/#emc) my philosophy is that making things harder to understand for the sake of portability is a bad tradeoff (jmkasunich/#emc) I don't know how emc dealt with non-kernel module OS's (jmkasunich/#emc) all the RTLinux vs RTAI stuff was done with ifdefs (jmkasunich/#emc) that part is now hidden in RTAPI (jmkasunich/#emc) there is rtai_rtapi.c and rtl_rtapi.c, the make process decides which one to compile (jmkasunich/#emc) emc2 proper simply makes rtapi calls (rayh/#emc) Is emc2 compiling in insmod or modprobe or are these done at startup? (jmkasunich/#emc) insmod is called from the run script (rayh/#emc) but the modules that are compiled for emc2 are specific to the rtapi? (jmkasunich/#emc) don't understand the question, can you rephrase? (rayh/#emc) I can try. (jmkasunich/#emc) emc2 source files don't call RTAI or RTLinux directly, they call RTAPI (rayh/#emc) You said, "however some things are assumed throughout the project - for instance kernel modules. We assume that realtime code is in kernel modules, and that they are installed using insmod (rayh/#emc) I am content with the notion of realtime code being in modules. (jmkasunich/#emc) so "compiling realtime code" means "creating kernel modules" (rayh/#emc) I am worried about insmod being assumed as the method used for connecting these modules into a running os. (jmkasunich/#emc) the two are tied together... (jmkasunich/#emc) the term "kernel module" is very specific - not the same as the term "module" (jmkasunich/#emc) if you have a "kernel module", you load it using insmod and friends (modprobe, etc) (jmkasunich/#emc) other OS's may not use kernel modules (jmkasunich/#emc) for instance win NT uses device drivers to do the same thing, but the methods for loading (and compiling) them are probably completely different (jmkasunich/#emc) as far as I know, you can't load a win device driver after boot (unlike kernel modules), but I really don't know and don't care (rayh/#emc) And the way that we handled this in EMC so that we could run the same code on a sparc or alpha was to build a single module, frequod or steppermod, that was specific to the device it was to run on? (jmkasunich/#emc) if it is Linux on sparc or alpha, it still uses kernel modules (jmkasunich/#emc) if it is solaris or something, I have no idea (jmkasunich/#emc) that stuff depends more on the OS than the CPU (jmkasunich/#emc) I _think_ emc2 would work under Linux/RTAI or Linux/RTLinux on either a sparc or alpha CPU, but I can't test that (and probably never will) (rayh/#emc) Am I safe to conclude that there is no acceptable way to build emc2 for bsd or one of the new MAC os's? (jmkasunich/#emc) I dunno (jmkasunich/#emc) I don't know enough about those OS's to tell. I do know that there is no equivalent to RTAI or RTLinux for BSD (I actually looked into that - BSD sounds interesting) (jmkasunich/#emc) without the RTOS, it is pointless (rayh/#emc) I have seen references to rtai and MAC10. (jmkasunich/#emc) can't rule it out then (jmkasunich/#emc) but I have a 500+ page book here called Linux Device Drivers... without similar sources of knowledge for other OS's, porting will be a challenge - we don't know what is similar to Linux and what is completely different (rayh/#emc) Ok. But we can assume that even if adeos were available for a version of the MAC os, it would not be able to run emc2's code. (rayh/#emc) Your work on emc2 is based on Linux Device Drivers. (jmkasunich/#emc) not without some work. But we don't know whether that work is a day or a six months (rayh/#emc) I'm getting the picture, here. (jmkasunich/#emc) I have tried to avoid making assumptions that would drive it toward six months, but only if they don't hurt code readibility (jmkasunich/#emc) I consider code clarity to be goal #1 (rayh/#emc) What I'm seeing is that the lowest level stuff, the HAL kernel modules are specific. (jmkasunich/#emc) probably... again, the HAL modules use RTAPI to interact with the OS, so _some_ OS changes might only involve changes to RTAPI, then the HAL and EMC2 would compile and work without changes (rayh/#emc) Okay. That sounds good. (rayh/#emc) Thanks for updating me on this. (jmkasunich/#emc) RTAPI is similar to Tcl/TK in that _if_ a platform has Tcl, then Tcl programs work there... but getting Tcl on a particular platform may be easy, hard, or impossible (jmkasunich/#emc) since RTAPI interacts with the hardware and OS at a lower level than something like Tcl, porting it to other platforms is harder (rayh/#emc) Even at the tickle level, platforms can cause real problems. (jmkasunich/#emc) as far as platforms go, my priorities are: (jmkasunich/#emc) emc2 MUST compile and run on BDI-2.xx, BDI-TNG, and BDI-Live (rayh/#emc) I'm with you on all of those. (jmkasunich/#emc) it SHOULD compile and run on any 2.2 or later Linux kernel, with RTLinux or RTAI (jmkasunich/#emc) it WOULD BE NICE to easily port to non-Linux OS's, but the burden is on the porter (rayh/#emc) Sherpa might be a closer descriptive. (jmkasunich/#emc) the would-be-nice part CANNOT come at the expense of either performance, usability, or ease of understanding the code (rayh/#emc) If the major burdens are in the rtapi, I'm content. (jmkasunich/#emc) depending on the platform, porting might only involve changes to stuff in the rtapi tree, but that's not guaranteed (jmkasunich/#emc) for instance, porting to a machine without floating point would be hard ;-) (rayh/#emc) I remember Terry working on the code a while back to make it compile for his alpha and there were 600+ commits. (jmkasunich/#emc) porting to a machine without 32 bit ints would be hard (jmkasunich/#emc) porting to a 64 bit machine _shouldn't_ be bad, but it will be interesting if the machine can't manipulate things smaller than 64 bits (like writing a single byte of a 64 bit word) (rayh/#emc) I'm guessing that this was the reason for the "plat" directories. (jmkasunich/#emc) perhaps (rayh/#emc) And with the byte v 64 bit we have a intel v amd issue (jmkasunich/#emc) but having to run make twice, one with PLAT=foo and once with PLAT=bar_rt sucks (jmkasunich/#emc) to be honest, I haven't been following the 64 bit thing... once it seems likely that I will actually own such a beast, then I'll spend brain cycles on it (rayh/#emc) I know the feeling but at the same time fear for the future. (jmkasunich/#emc) I'm sure changes to HAL/RTAPI for 64 bit won't be too bad - the worst case is just wasted memory, and those boxes will have craploads of memory (jmkasunich/#emc) (might need to alocate 64 bits for 8 bit HAL variables) (jmkasunich/#emc) time for lunch, I'll catch up with the discussion when I get back (rayh/#emc) Catch yo later, Thanks again, John (rayh/#emc) I'd like to type one summary thought from the make paper into the record here. "Building your project needs to be so simple the newest recruit can do it immediately with only a single page of instructions." (thalx/#emc) I have a question for Ray... (thalx/#emc) I have been killing trees, and printing out all EMC documentation that I've managed to get my hands on. (thalx/#emc) However... the NGC version 1 and 2 are in PDF form, but you sent me NGC version 3 as a bunch of HTML files. (thalx/#emc) Is that the only form it's in? Is it 'finished docs', or still a rather live document? (rayh/#emc) Yes. (thalx/#emc) 20 HTML files being... a bit less straightforward to dump to the printer. (rayh/#emc) I believe that the html was the only way that Tom built that document. (rayh/#emc) It was prepared with some "proprietary" writer that had been made available to NIST. (thalx/#emc) Of course, I know that I shouldn't be killing trees this way. But... works better for me. I will be binding the stack of stuff. Currently at 1.5 reams. (rayh/#emc) "Quadralay WebWorks Publisher Standard Edition 6.0.0" it says in the header. (thalx/#emc) Somewhere, I think in the PDF User guide, I found answers to a bunch of questions I had... wished I'd read thru it before NAMES/EMCfest! (Namely, the spelling-out of BDI OS versions, etc.) (rayh/#emc) I tried transferring it to Lyx but the product was a lot less than good. (rayh/#emc) I'll look at it again when I get the medical stuff sorted out. (thalx/#emc) But ok, so it will be less straightforward for NGC v3. My other question... what's using what? Is everything using v3 now? (rayh/#emc) Yes. Much of the earlier stuff was interesting to see how it developed but the HTML is the definitive guide. (thalx/#emc) Take your time! I have weeks of reading ;-) (thalx/#emc) Ok, great. At least there's only 1 place to look. (thalx/#emc) I also got the Rogier Bloem paper on the trajectory planner, which looks fascinating to me. (rayh/#emc) Good. (rayh/#emc) Beyond all the reading, where are you heading with EMC? (thalx/#emc) However, in one of the PDF guides, I found about 10-20 pages that didn't print correctly. (thalx/#emc) Heading? As in, pie-in-the-sky, down-the-road heading? Or nearer-term achievable goals? ;-) (rayh/#emc) Both. (rayh/#emc) Remember where that print error was. Probably a chapter with the wrong definitions. (thalx/#emc) Near term goal - Understand 'everything'. (thalx/#emc) 1) Understand what NGC is interpreting, so I can start playing with the G-codes it understands. (as opposed to the Tom Hubin method of playing with EMC! ;) (thalx/#emc) 2) Understand every major block, and part of EMC - at least in what its trying to do. I *JUST* last week learned that freqmod and steppermod are CHOICES - all along I thought they were both involved. Duh. Makes more sense now. I don't know *why* the choices are there, but will handwave that to "historical reasons"... (rayh/#emc) Understand 'everything' may be a difficult near term task. (thalx/#emc) 3) Understand it to a point where I can start understanding data flow between routines - JohnK bitterly complained about a huge shared memory chunk that everything uses to share data - I wanna whiteboard actual data flow between the modules. (rayh/#emc) If you have a running emc, you could set debug so that you saw all of the interpreter cannonical commands in a terminal. (rayh/#emc) I find this kind of stuff fascinating. (thalx/#emc) Yes, I do have a running one. (rayh/#emc) Run a very simple part-program and watch the interpreter output. (thalx/#emc) But, end-goal wise... I want EMC to run on non-Linux boxes. While I know I'll never get there, the GUI can certainly run on Macs. (thalx/#emc) And *maybe* the task controller. (rayh/#emc) Set debug to DEBUG = 0x7FFFFFFF and you'll see all of the non-realtime talking to each other. (thalx/#emc) Well, think of this as the goal I would love - The computer that runs the real-time stuff should NOT have a head (monitor/keyboard) on it. (thalx/#emc) (And yes, debug is currently at that level....) (rayh/#emc) We have demonstrated a "black box" system a couple times at NAMES. (thalx/#emc) Think of the "terminal vs. mainframe", paradigm... or, say, on a Cray computer ... you don't sit down and log directly into the cray, you use an intermediate computer to deal with those humans. (thalx/#emc) Yea, I really really wish I had come to NAMES before this year! (rayh/#emc) One of those was MS-2000 (tm) for the interface and BDI 2.18 or so for the motion and IO controller. (thalx/#emc) But playing with RT optimization... that computer should NOT be the same computer doing keyboard handling. (thalx/#emc) I've heard a reference *somewhere* to the Tcl interface being run on a Mac before. (rayh/#emc) I believe that you can boot Linux headless. (rayh/#emc) Right. Dan Falck had four or five tickle front ends to his machines routed to a MAC cube. (thalx/#emc) Imagine this Tcl interface being capable of starting up the processes on "the RT computer", so that the user doesn't have to log in and manually startup. (thalx/#emc) (dangit, gotta find a notepad now!) (rayh/#emc) I was talking with him yesterday and he plans to rebuild that system when he gets set up in Portland, or. (thalx/#emc) he just moved? (rayh/#emc) In machine shop terms, you are talking about a work cell. (rayh/#emc) With a single terminal for all of the various machines. (rayh/#emc) He is moving with his company. (rayh/#emc) But plans to get back into guitar parts. (thalx/#emc) I have a friend here that moved to Portland a year ago.. (rayh/#emc) A place to stay while you visit one of the EMC early adopters. (thalx/#emc) Another concept... running a sherline open-loop. Zero feedback to the computer. (rayh/#emc) Detail? (thalx/#emc) Can you hang, say, 3 machines off of that thar parallel port? Demo some mass-production at a show? ;-) (rayh/#emc) All doing exactly the same thing! (thalx/#emc) Yup. I'm waiting to see if Steve cringes. (thalx/#emc) So that if one were to design a hand-out freebie widget, it takes less computers, more mills. (rayh/#emc) The only issue should be loading on the parport pins. (thalx/#emc) And, if you had, say, one INCH machine, and one METRIC machine... maybe you get different sizes, too. (thalx/#emc) Initial setup, I think, would be exceedingly fussy and nervewracking. (rayh/#emc) The way that emc is now, the metric would be 1/25.4 of the other. (rayh/#emc) You'd need a way to disable power to each while setting home location on an other. (rayh/#emc) The computer is, however, a minor cost of the price of a mill. (thalx/#emc) Yeah, that's very true these days. (thalx/#emc) So was Don Falck doing this Mac cube thing, at work, or at NAMES for a demo? (rayh/#emc) He was running all of his home shop production machines from it. (thalx/#emc) Oh! (rayh/#emc) Don't remember all the details but there were mills, routers, and a lathe on it at the same time. (thalx/#emc) So, did he use your default Tcl GUI, write his own, customize yours, or ?? (rayh/#emc) I believe that the gui's were customized tkemcs. (rayh/#emc) Tickle makes it easy to pass stuff like start and stop between. (rayh/#emc) It would be rather easy to integrate robot part changers, pallets, and such between machines. (thalx/#emc) Interesting. (thalx/#emc) Oh, back to "what do I want to learn" ... something that is mildly distressing, at the back of my mind, is the idea that the A, B, and C axes MUST be parallel with the X, Y, and Z machine axes. (thalx/#emc) I want my "twisty" axis to be parallel to none of them. (thalx/#emc) So long as I can do what I wanna do, and handle it all in g-code... that's fine, but I don't know what sort of assumptions the EMC may be making. (rayh/#emc) That's doable with kinematics. (thalx/#emc) Here's another random question.... EMC... how many different code modules? How many separate *.c files are there, all in all? (rayh/#emc) G-code can still be written with cartesian (world) and joints handle the mechanical relationships. (thalx/#emc) Some files are thousands of lines of code... but I dunno if there are dozens or hundreds of *.c files.. (rayh/#emc) 1000+ (thalx/#emc) Oh, my. So I definitely need bigger whiteboards! ;-) (SteveStallings/#emc) thalx - No just make your "whiteboard" electronic. That way you can distribute it to all. (rayh/#emc) My thinking is that no single person should be expected to get around it all. (thalx/#emc) I don't want electronics in my bathroom, where I do my best thinking. (SteveStallings/#emc) OK, put a porta-potty in the computer room. 8-( (rayh/#emc) Gotta take care of things. Good talking to you. (thalx/#emc) I just hate computer screens and their limited resolutions. When they come out with a 3' x 7' computer screen, at 300 dpi, I'll be happy. (thalx/#emc) Later, Ray! Be Well! (SteveStallings/#emc) OK, time for me to get something done too. Later. (thalx/#emc) Steve - you don't wanna see the intermediate work... just the end result. (thalx/#emc) Yup.. later! (jmkasunich/#emc) thalx: you still here? (thalx/#emc) I'm here now! (jmkasunich/#emc) and there was something in there I wanted to talk to you about (thalx/#emc) Sure... my guess would be the big shared memory thing. (jmkasunich/#emc) actually it was the black box and porting to mac (thalx/#emc) Ah, ok! I'm all ears! (jmkasunich/#emc) ray and I were discussing porting earlier, and I said porting to mac would be tough (jmkasunich/#emc) but I was specifically thinking of the realtime stuff (jmkasunich/#emc) if you keep the realtime in a Linux based black box, porting GUIs isn't so bad (thalx/#emc) Right. I envision the RT stuff as belonging on a singleboard computer, dedicated to the mill, along with its driver electronics. (jmkasunich/#emc) that would be the pro approach (since SBCs are usually more $ than a standard box) (thalx/#emc) I believe Steve has sent you one! (jmkasunich/#emc) yes he did (jmkasunich/#emc) nice little thing (jmkasunich/#emc) but it has onboard video, and I was anticipating using it as a headed computer, only small (thalx/#emc) There are pallet-loads of those collecting dust in a warehouse. (jmkasunich/#emc) why? (thalx/#emc) ... I thought it had no video... (jmkasunich/#emc) video, key & mouse ports, IDE controller, parport, 2 serial, and ethernet (jmkasunich/#emc) its a computer! (thalx/#emc) There was an internet company, designed a big product, had a mini production line set up. (thalx/#emc) 2 CPU/blade, 12 blades/chassis. (thalx/#emc) The whole shebang was sent out for UL and CE ratings. (thalx/#emc) 40 units were produced, then the dot-bomb happened. (jmkasunich/#emc) (aside - I actually have visions of using that SBC in a robotics project, where the whole thing is mobile - in that case it would be headless) (thalx/#emc) The former CEO has all the components (and the 40 production units) warehoused, in the hopes that there will be some future project for that box. (jmkasunich/#emc) wow (thalx/#emc) I, however, gloat over some of the components. Some day, push WILL come to shove, and I'll be there with an empty vehicle. (jmkasunich/#emc) haha yikes almost a full house. (jmkasunich/#emc) back to black boxen... if the realtime is in a headless box, (jmkasunich/#emc) where are the g-code programs stored, and where does emctask run? (jmkasunich/#emc) (emctask includes the interpreter) (thalx/#emc) I dunno. Still coming up to speed on how it all works. (thalx/#emc) I've only seen the diagram w/ the 4 main modules - MOT, IO, Task, Gui. (jmkasunich/#emc) the folks who have done remote GUIs (including windoze GUIs) run task on the realtime box, and IIRC the g-code progs are stored there too, the only thing remoted is GUI i export the display from my headless CNC box, and control it from another linux box (in the same room) but with a monitor ... (thalx/#emc) I do not know how much stuff flows in between all these, i.e. bandwidth requirements, what is passed arguements vs. shared in that heap of shared memory, etc. (jmkasunich/#emc) that's the problem, almost nobody knows that stuff (thalx/#emc) I've still got 2 months of understanding EMC as it sits. Ray was asking for my blue-sky desires. (jmkasunich/#emc) my view is that emc2 is evolving, and knowing peoples blue sky desires will help guide it's evolution (thalx/#emc) Sounds like its following the plug-n-play path, anyway! (jmkasunich/#emc) I have very little (perhaps too little) attachment to the past, and IMO if a blue sky redesign is the way to go, so be it (jmkasunich/#emc) OTOH, don't want to re-invent the wheel (jmkasunich/#emc) so we need to keep the good, smooth running wheels from emc1 (like the interp) and dump the squeaky square ones (like rcslib?) hello hi les * jmkasunich is failing algebra really haha trying to define a function that takes in a stream of position commands and spits out a stream that tracks the input, except that it complies with accel and velocity limits well let's see I am a math guy but not a programmer (much) this is all math... so far I'm just simulating it in a spreadsheet to check the equations keep running into gotchas because of discrete time I have closed form solutions for cubic and quintic curve fitting it is possible to give it data that cannot be planned something has to give with emc it is velocity what I'm doing is single axis only should not be so fscking hard yes... a single axis is about a 4x4 matrix but it does not have to be solved each point let me check the book here.. I'm looking for something that is basically a non-linear filter if I have a velocity limit only it's trivial... but add accel limit and it gets messy is this trap, cubic or quintic you want to do? the end result is a trap velocity profile for an input position step but I want it to accept an arbitrary position input for instance ramps if ramp vel < vel limit, should simply track the input if ramp vel > vel limit, will fall behind, then catch up when input stops (or slows down, or reverses) ok trapzoidal with blending is 8 equations 8 unkowns a bit much to type with blending = jerk limit? jerk is bounded but not continuous IOW accel can go from +limit to -limit in one sample time possible yes the 8x8 covers initial and final vel, position, and acel is this for discrete time? and matching no, it is continuous but can be sampled it always is in a computer haha and how does it behave when sampled? I've done a dozen flavors in the last couple days, all are correct for continuous, all tend to get squirrly as dT increases what you end up with is a power series with coeff that change each segment as accel/decel times become only a few samples, they get _very_ squirrly I think I need to send you a scan...calculations really kind of "self synchronize" with the data no sampling problems you have well defined calculated ramp phase, cruise phase, and blend phase each phase has times that can be just in a buffer what happens when a phase time != integer multiple of sample rate? a sample rate need to always be at least twice of course twice what? twice the trajectory change rate but if you had these in a memory table you could pick them off at sum microsecond precision right? no everything runs at the servo rate that's why I called it a filter it is _not_ a traj planner oh I see but it seems close... a planner is given a series of moves, each move takes >>1 servo period, planner spits out a series of pos commands until that move is done, then does the next one (ignore blending for now) this filter accepts a series of pos commands (possibly from a planner) and spits out the same thing if the commands describe a path that complies with accel and vel limits to me all a tp does is take data and operate on it to conform to machine dynamic limits anyway if the commands describe a path that doesn't comply, the filter spits out positions that _do_ comply right yes, but I think of planners as taking move commands at a non-constant rate << than servo rate some moves may take mS to complete, others take seconds a filter takes position commands, at a constant rate ok I see what you want however, if you feed this filter a step function that goes from 0.0 to 1.0, its output is indeed a trap move from 0.0 to 1.0, just like a planner... the diff is that when the output is half way there, you can change the input if you want and it simply starts going toward the new input value and you want vel and acel limits? right - without limits, the filter is easy - pos_out = pos_in with vel limit, it's almost as easy: vel_cmd = ( pos_in - old_pos_out ) / dT; if vel_cmd > vel_limit then vel_cmd = vel_limit; if vel_cmd < -vel_limit then vel_cmd = -vel_limit pos_out = old_pos_out + vel_cmd * dT; done anyway, the vel limit one is easy - calc vel needed to reach goal in one dT, limit it, then move at that vel if you don't hit the limit, output = input if you do hit limit, output moves toward input at limit vel and it's stable when it gets there but when you add accel limit, things get hairy but then do the differece equation twice just doing it twice results in oscillations this implies you need 3 points and two segments hmmm.... to meet both acel and vel constraints that's the group delay! this is where my head starts hurting I have my present pos and velocity, and I have desired pos (and desired vel, = pos_cmd - prev_pos_cmd) so I can calc pos_err and vel_err my goal is to drive both to zero so I have two equations there ok...but data may result in no solution no immediate solution anyway haha I can always drive towards zero, but it may take many servo periods right I was taking an approach where I ignore the limits at first given actual and desired vel and pos ( or pos and vel errors ), may I ask....what is this filter for? emc2 ;-) hey...go all the way and do a planner... put it right before a stepper for instance, to ensure that you don't ask it to do things that cause skipped steps oh ok like turn it on... haha actually I was sort of gonna use it as a planner, for homing and jogs... that way the real planner would only be used for coordinated moves I see I will try to work that out for you better chance of decoupling the real planner from the motion controller that way, so we can understand it and eventually replace/repair it I started to 'splain my latest approach, let me run it past you... given pos and vel errors, and ignoring limits I want to calc a triangular move - accel at A1 for time T1, then decel at A2 for T2 for a step input, A1 = -A2, and T1 = T2 ok got it that's four unknowns, but I only have two eqns eq1: vel_end = vel_start + A1 * T1 + A2 * T2 eq2: pos_end = pos_start + vel_start * ( T1 + T2 ) + 1/2 * A1 * T1^2 + A1 * T1 * T2 + 1/2 * A2 * T2^2 ok 1/2at^2 so I was making some assumptions to reduce the unknowns first assumption: T1 = T2 = dT ok IOW, what accels will get me to my goal in two samples (probably very large accels if large errors, but...) then I was going to make a different assumption: A1 = -A2 = +/- accel limit, and solve for T1 & T2 two STEPS= three time instants IOW, what times will it take to get to goal observing accel limits yeah I was thinking about a third assumption: T1 + T2 = dT, A1 = -A2 I will think about that.... that would give me accels/times needed to get there in one dT OK John - take a look here... http://www.mech.ubc.ca/~sonja/research.html