For a full rt kernel update with modules and all, you'd be looking at 10 Meg. I guess we are discussing different problems here - I'm talking about getting users up and running with RT... after that, getting the latest EMC is relatively trivial... d/l the source tarball, ./configure, make, and done True, John, but after the install, apt-get does all of the updating for you whenever there are updates to any installed package. That would allow us to bring forward things like tix or tclx or tcl along with updates to the emc. And the end user need only start a single program like synaptic. And they have a graphical environment that reports new packages and asks if the user wants to install them. so you are not just talking about getting the latest emc - your also talking about getting the latest of whatever pile of packages emc depends on.... well.... There would zero chance of getting an rt kernel and/or emc in the Debian archive..... The packages could reside at the sourceforge site or sherline or smithy. So we would have to run our own repository for those parts Right. then you are right back to BDI again, where paul or some other poor soul has to put together a "distro" not quite... Debian is a little easier to build packages for. /etc/apt/sources.list can house multiple resources in ftp or html. I guess I just don't understand what we're talking about We would just have to set up a few mirrors, like we have now in Finland and Germany. it's a pity Debian is such a bitch to install from scratch. if I'm joe user with a dumpster PC with a wiped hard drive (or an old winxx box, with a hard drive that needs wiped), I need to install a RT kernel, and many many megs of "stuff" to have a working system - none of which is really emc related The sources.list file resides in each deb install and lists available mirrors. right now the BDI does that Right and you could do that from LIVE. how does deb and apt get do it? They are the path to upgrade. upgrade from what? remember, blank HD From a HD install of LIve * paul_c sees where jmk is coming from.... what do you get with Live - enough to make a "working" PC - with basic networking, gcc, etc? Yes. You can even get that with a boot from Live. with -rc23, yes (sorry for my dumbness about Live - I'm not really set up to d/l and burn CDs) No problem, John. I'm seeing your questions as a chance to clarify what I'm seeing as a real advantage for BDI. but in that way, I'm a lot like Joe New User Absolutely. And that is the customer that we need to keep in mind. the $10 (or was it $20) I gave Ray last year for the 2.18 and TNG CDs was some of the best money I ever spent The advantage of Live is you can try out new hardware without having to do an install first. So they find a disk. And install it. Sounds like I need to get Live and play with it... Then a quick trip to the deb sites available. and they will know how far behind they are in the packages just installed. will it run on a 200MHz box with 96M ram and 2G disk? 2.5 gig disk min for knoppix. Less for Live. smallest I've tried it on is a 400MHz with 128M why so much? is it all GUI? The files are compressed, and you need the memory to expand stuff... I've seen 64 Meg RAM. Bitch during install but once there it's okay. paul_c: you mean in the run-from-CD mode? yes what about the install mode? and to install, you'd need to run from CD But. The pressure on those old computers from new 1.2 GHz motherboards for 4.99 at tiger... dumster spec is now 400-800MHZ with 128M ram & 6Gig HDD not my dumpster my best ever is 600MHz PIII but most are still <300MHz PII besides, I was asking specifically because I want to install it on a farm slot starting to see 800MHz Duron/Celeron boxes over here those are 200M PI, 96 or 112M anyway, EMC doesn't require a fast box - it's the GUI stuff that does... rc23 should just about run. although the installer has a bug in it.... The point is that once the base system is installed, the upgrade path is nearly trivial. my 233 MHz box does everything I need to both run _and_ develop emc2 just fine - the only time it bogs down is when I use a web browser rayh: we both agree on that the same applies with BDI-2.xx or TNG - once the base is installed, upgrade is easy Disagree. upgrade for EMC, yes. Upgrade for the OS, no. The upgrade of 2xx is much more difficult. I meant upgrade EMC - if the OS works, why upgrade it? read "virtually impossible" hmmm... maybe my M$ experience is showing... I never upgraded M$ OS just replace them (wipe disk, start over) I understand where you are comming from, John. The big advantage of a deb is that you can upgrade across whole distributions. And you can do it from a net download, or from disks. So it would be possible for folk like me, with slow downloads to procure disks when we need a large upgrade. I guess we're looking at philosophical(sp?) differences here - I look at large scale one click upgrades with great distrust and apt looks after the package dependencies. Then as new emc's come along we can just connect and do it. looks like I'm outnumbered, and being dragged kicking and screaming into the 21st century I'm still with you, John. An emc user would only need to ask if anyone has gone from rc23 to a full blown debian sarge with rt and emc. I'd rather keep emc light and dependency free than have dependencies and use fancy tools to manage them don't think Debian does a version for Babage's engine.. I said 21st ;-) or Vic-20 I'm quite willing to abandon 8088s, and even 80386's and 486's... Okay, now that that's out of the way, I believe that Live is the way of the future. but _any_ pentuim has enough power to run emc * jmkasunich needs to get with the program, but Live pretty much obsoletes 10 of the 11 CPUs I have available to me I had to bring knoppix from 386 to 586 in order to get the rtai to build. Sounds like it might be time for me to apply live or knoppix to an older box here and see what the problems are. 8x 200M in the farm, 1x 200M in the AB industrial PC, 1x 233 in my main box, and a 600M in the latest acquisition if EMC itself needed that kind of power, I wouldn't mind so much... but it doesn't - it's only the baggage (aka the distro) that does rc23 is really light on it's demand for resources. The window manager is the resource hog My demands are greater because I'm writing code and really like the way kate works for me. I use kate too me passes rayh & jmk vi yuch! and slips emacs in too and mc gets the same reaction. nedit ? vi: ancient and cryptic (you complain about me being old fashioned) emacs: huge I've been using mc quite a lot lately when in text mode But picnet did some interesting coloration of g-code with vim. then there is the aptly named vile I need to become more proficient with mc - can it handle multiple open files at once, and copy/paste between files? (I really like kate's handling of multiple files) We may be missing a part of the point here. Our end user needs some good editing as well as xxx for their work. xxx might include wine or other emulators. right - and if they are coming from M$ (as they almost certainly are), they aren't gonna be doing vi I've tried getting wine going several times and failed. So either I'm dumber than the average former M$ user, or they ain't gonna have much luck either Long ago, when I worked genedit into tkemc and the other interfaces, there was a problem with the clipboard and emc. kate is close enough to notepad, etc, that former M$ers can pick it up quickly It seems the interpreter wrote a copy of each of it's block reads. So I had to build a separate variable to hold clips. It's still there. Even though the problem that caused it is long gone. Back then 5.2 you couldn't even run vi and cut and paste. If the interpreter was running. Now, I'd be all for trashing genedit. what linux editor(s) are most suitable for the M$ masses? pen'n'paper ? no - they forgot how to use that But I've got two customers that insist they want x without a desktop. you can run tkemc in X without a WM what does X w/o a desktop give you? just Xterm windows? We need to be able to build a "full featured" editor like kate into an EMC gui. !huh! eeuw gtk perhaps ? Without a window manager, the screen is flat. You get one display. don't like it - don't like it at all. I've got eddi running in an EMC gui. Not well, but it's in there. emc should control machines - editors should edit files, and never the twain should meet what do you edit with the built in editor? g-code programs? ini files? it should be possible to embed an editor in the GUI though... why? Without a full featured editor, the emc operator is really crippled. to edit G code files pop open another window and edit your files why are those two people opposed to a window manager? or have a widget that opens up the current file in an editor My genedit cut and paste is trivial compared to the needs for macros and multiple cut and pastes like modern clipboards allow for. The idea is that the machine operator is faces with a single known environment if there is no desktop. That is what I tried to build with Sherline's mini. if you must have an "edit this file" button on the GUI, then I like paul's idea of a (configureable) button that launches your editor of choice Make it possible to do full machine operation within a flat screen. The problem comes in when you need to get back to the machine in a hurry. now you know why I stick with the low level code clean and elegant design is completely incompatible with an "everything in one package" interface Not completely. As long as the outer edges of the set can be defined, the innerds can be known. Paul mentioned gtk. That sort of environment would work. But tickle works also. I like gtk for gui's cause it's C and I grok C... but I don't want a gtk based editor in emc either... what's wrong with exec()'ing an editor when we need one? It still needs to play nicely with EMC. define play nicely? you open editor, edit file, save file, run emc to cut part the point of interface is the file But often, the jeweler will be cutting one ring while designing or editing the file for the next. Rather than requiring two cpu's, the idea of mini is to allow both activities to coexist. that's exactly the time when you _don't_ want integration... designing and cutting are completely different tasks and shouldn't interact at all that's why windowing systems were invented I don't think so. When I look at a guy running a Mazak or any modern machine, it's working and so is he. if it is cutting part N and he's editing part N+1, part N+1 should be in a different window He's checking tollerances and editing tool files, or building what he can of the next program. and if he manages to crash the editor, it should have _no_ effect on the part I understand that but the operator still needs access to some parts of the run window. right - both windows can be open on the same screen at the same time I know you have folks who don't want a windowing system, but why not? and why re-invent a windowing system inside emc to accomadate them? But the ms(tm) focus model doesn't work. you mean the KDE focus model that I'm using right now? how does it not work? I have kate with 5 open files, 2 shells, calculator, and ksirc (and that's just desktop 3) With Linux we really can multitask, so I split the keyboard and focus parts of it on one task while other parts get another. scary That's the kind of guy I am. Wolf teeth and all. you mean the arrow keys move the cursor in the editor, or jog the machine? What really happens now, is that some of the function keys are always focused on the motion. The keyboard bindings change from auto to manual to mdi. that means "you" ie mini, owns the keyboard? what if they switch to a different desktop and activate an email client? do you still own those keys? That's the issue that causes me to think in terms of flat screen. you are saying that mini is _not_ "just another app", if it holds certain keys even when you switch away That way I can keep the outer boundaries known. IMO, if any key is so important that you need to hold it while they run another app, then it's too important to trust to a keyboard that's why real machine controls have buttons on pendants I don't think that calling us unreal is fair at all. semantics non-PC based CNC mazak, etc anyway, if we want to be real, we should also support buttons on pendants I have read about the nature of the keyboard communication and agree that it is a bit fragile. More so that I like. And dedicated buttons is the reason that I've got at least five different boards for other paths into the emc. a lot of this is perspective... I'm thinking of emc as just another app (hence windowing, etc), and you are thinking of emc as the only app (hence flat screens, and internalizing features such as editors) You got it. we need to support both views and maybe that means two (or more) completely different approaches to the GUI Yep and probably a few others that we have not thought of yet. I would not throw out tkemc in favor of mini. question: if you are running a flat screen, can/will you build in a CAD package too? cause that's what I would be using for part N+1 while part N is cutting if emc is just another app, I can do that But to always use tkemc can cause operator frustration. Yes. I have allowed for building cp1 into the right side of mini. cp1? If I can install cp1 there then I could also install tkcad there. cp1 is a little g-code writer, based on some xml work done at nist and also JonE's c routines. It's on the bdi's. It will write pockets, bolt circles and such. I yield to your experience with GUIs... but it doesn't fit my mental model (do one thing and do it well), so it will always annoy me... such is life I understand. I wish that I could do one thing well. you do several things well - as do all humans... I was talking about programs My family has my epitaph picked out, "The only thing he ever finished is life." IMO, emc should control the machine, period... you want to edit g-code, open pico or vi or emacs or kate or whatever you want. want cad, open QCAD, or tkcad, or whatever... etc And viewing it from the HAL, that is exactly what I want it to do. The closer we can get that part of the emc to a state machine the better we will do. but this talk of integrated editors, of picking one editor and hooking it to emc, sounds like the opposite State is important clear up in the interpreter. Tom knew this when he designed the world view. Anyone can write a g-code parser -- several have -- but a g-code parser that knows where the machine really is -- now that takes skill. Several have asked me why I wrote the first backplotter using the actual position displays for a running emc. I did it because I wanted to see corner rounding caused by accel/decel. that reminds me of something les mentioned (I talked to him on the phone this week - started out work related, moved to emc pretty quickly) It's the same sort of state thing. Now your question about editors and such. Yes they are alongside the machine but without it the machines is just a single state. Idle. he said that traj planning (and g-code interpretation) are causal - IOW, they do _not_ need to know the state of the machine... you can interpret a g-code file and pregenerate the entire path a week before you make the part if you want to Not if you care whether a tool is broken or not. his approach is that you only break tools if you trajectory is bad (overloads them, etc)... Not if you care to pause it right before the start of a cut and watch for a moment. State makes the interpreter smarter. actually, that touches on a larger design issue... think about the g2003 in smart mode (have you been following that?) No but I understand the issue. those folks believe you can send what is in essence a precomputed path to the box, which acts like a buffer and spits it out.. but that doesn't allow for pausing, or changing feed based on load, or other things like that Matt and I have talked about 2003 a bit. There was an attempt to set position and velocity in different threads and give velocity higher priority. IMO, g2003 will run in dumb mode for emc... it will look kinda like an STG, just an I/O device Right. If you don't mind the price of the software and running it on an ms(tm) machine or under wine. you mean position and velocity control loops, where velocity is updated faster? NO! g2003 is a piece of hardware only! Mariss specifically made the schematics available Where a change in velocity (estop) is immediately interpreted and applied. I intend to write a HAL driver for it Right but even in dumb mode, you needed a processor out there. a rabbit - a Z-80 clone all it does is takes apart USB messages and writes to the hardware Yes but in order to do that, it had to be programmed. it has onboard flash memory... which can be written from the USB port There are a couple sf projects that purport to aim in that direction, but the result is limited. or purchased from Mariss with dumb mode code already in it believe me, M$ is _not_ needed to run the G2003 a RT capable USB driver in your linux box is, which is probably the main stumbling block I agree, that someone could write the base code for the rabbid processor one time and distribute it. If I ever get the time, that could be me... I can write Z-80, in fact that kind of embedded work is the kind of stuff I love but Mariss already wrote some dumb mode rabbit code anyway But Rabbit does not use ordinary z code. z code? z-80 It has some of it's own variations. oh, you mean the development of the Z-80 code requires M$? And now we are way beyond my understanding of it. so what... I can live with that in dumb mode, the rabbit does very little - write it once using M$ if needed, then just ship it out in binary... So could I if I had to. at that point, the rabbit is just another piece of hardware, no different than JonE's or Abdul's FGPAs... But the same dumb mode could be done with an PIC yeah, it could, if you want to design it, lay out the board, build it, etc. it could also be done with an FPGA... it's just a packet assembler/disassembler in dumb mode Yep. But we'd have an open source advantage with a generic pic. We could all write our own versions of the assembler/disassembler to take advantage of the buttons that we put on the outboard end. the buttons on the far end are just I/O, you would most certainly _not_ have to change the pic/rabbit code to use them... they would be hal pins in the PC and you could use them just like any other hal IO jmk: It's a quantity v speed issue. in dumb mode, _all_ inputs and outputs are updated every 1mS It's still a quantity v speed issue. how so? Cause you limited in advance the number of bytes you could send to it. you have a limited set of hardware out there anyway... there are 6 pulse generators, and 16 bits of digital I/O... in dumb mode, the g2003 is just an I/O device, and that is the I/O mix - that's what is on the board, there's no expanding it jmkasunich: With a pic like mentioned, you'd get 40 lines that you could do whatever you wanted with. rayh: so you aren't talking about replacing the G2003 rabbit with a pic... you are talking about a whole 'nother product that is a pic based I/O device there's certainly room for that Well certainly we could "jeep" the Rabbit cause it's a lot more capable than 4 axes of motion. to me the core of the G2003 isn't the rabbit, it's the hardware based pulse generators and the I/O All available in Jon's board at less cost. we need to support both And ready for emc without any proprietary bottleneck. from my perspective, Mariss has done it better than Jon Could well be. and I don't see Jon releasing his FPGA schematic, so who is more proprietary? We are entitled to our beliefs. (btw, I bought one of Jon's boards and will be writing a driver for it) I support both of them Good. but Mariss has a better hardware design and better (more cost effective) production facilities The wider the range of available hardware, the wider the acceptance of EMC. we both agree 110% there and Abdul has released pricing for his card... how much? $750 ouch for an eight axis card... not bad That's the lowest price for the capability. Mariss is $300 or so for six axis and not quite as much I/O open loop v closed? http://www.vitalsystem.com/motion/index.htm Abdul has an interface problem... does the $750 get you cables and breakout boards that turn those 50 pin headers into screw terminals outside the PC enclosure? or is that extra $$ extra... not with G2003....there is room for both, and we need to support both this is where hal comes into its own moving on for a sec... just what have *we* been co-opted for at the emcfest/NAMES ? co-opted? volunteered for ? I think paul is referring to the HAL "presentation" at NAMES that you emailed about Friday and worried about any extras... paul_c: I'm still dangling here about Monday and Fest. what do you think is needed... I'm all for a presentation from John & MAtt about HAL "how to write a HAL driver" or "how to use HAL as an integrator" or "how to use HAL as an emc developer" or ??? the first & last are the same... yes and no... abdul wants to write a driver for his board but not connect something complex like motion.c to hal Jon E might want to do both I agree there is much overlap while the second stands alone what integrators have to do will also depend heavily upon what we supply for a plc eg: emcio vs. classicladder I'd prefer CL, but I'd also prefer to get done eventually... emcio isn't a plc... it's just an lc (unless you write C code) semantically true & customizing emcio is outside the abilities of most integrators emcio is a hook between nml and i/o pins like estop, lube, and spindle it has some logic in bridgeprottask to control the spindle brake delay but that's about it I think I suggest we write something like minimillio and bridgeportio that use hal pins... keep the existing logics, delays, etc Right. I'm with you now. _then_ port CL? then later we go more general, with something that lets us replace (or augment) bridgeportio with ladder logic And I really dislike the distribution of logic between many of the different processes. I'd suggest using the file in iotask as a basis for an IO controller functional encapsulation is one of our, perhaps unspoken, but generally acknowledged, design goals That sounds like a terrible duplication for the few logics available with bridgeportio. functional encapsulation? rayh: folks who are happy with the logic in bridgeportio can simply use it (the halified version) "all the logic for a function in one place, not spread out everywhere in the code" no need for them to mess with CL at all rayh: this is the same philosophy we were talking about before - do one thing and do it well a question about the drivers, i thought it is possible with emc2 to use "normal" realtime linux drivers !! Like from the comedy projekt ??? there are no "normal" rt linux drivers there are "comedi" drivers, but they are no more normal than anything else comedii drivers are aimed at data capture we may choose to write a hal interface for comedi devices and comedii is more an API than anyting else... I'm not personally inclined to - I find comedi rather overly complex and also meant to be incoporated into specific code, not as user configurable as what emc users will need but it would certainly be possible, and if a comedi fan wants to do it, I'll help jmk: I guess I don't understand why we write a bridgeportio for hal at all. Why not write a ladder that folk can use just like it. If we took the time to lop off the bottom of cl and write a general IO module we'd have it all in the same place. in answer to your question: cause it's easy... halbridgeportio would be made from the existing code it would also be easier for users who don't need custom logic - no ladder programs to write I know that. But easy isn't always the best criterion to apply. please don't bring bridgeportio in in it's entirety must admit I don't know what 'its entirety' contains is it ugly? I'd be pleased to write the "ladders" for bridgeportio and minimillio. bridgeportXXX.cc its in C++? why? oh, needs to interface with NML... BTW -- I noticed, that on the German site, someone was adding namespace io to ini. the code in bridgeportio is tortious and convoluted. just looking at it now.... should we pass all the io data through usrmotintf? jonE already does for his boards no you end up calling half a dozen functions before writing to IO hal doesn't care where the data comes from, and is specifically designed to allow you to merge I/O from user and RT processes re: usrmotintf - Yes well.... maybe. I disagree... CL should simply read/write hal pins, as should motion, and anything else that wants to access hardware ok, so we have yes, no & maybe... I'm on record as favoring cl direct. cl direct to harware, bypassing hal? Nope nml interface to cl? If we don't enable nml in cl, we write nml io messages to hal pins. * mshaver is just trying to clarify "direct" oh, ok Right I understand. I was imagining CL to both read and write hal bits no NML to CL at all If all we did to cl was replace the parport pins with hal pins, it could run as is. some of those hal bits would come from inside emc, some would come from hardware rayh: yes Then we would just need to write a HAL driver for cl. That done, we have a world of IO logic available to us. right CL is currently "mostly" a user process, right (I think Paul RTified it tho?) not me... you helped? CL has a rt component in it for parport. I just did an rtai port for CL in any case, the "mainstream" CL is user space, right? It seems to me that the speed at which cl runs or where it runs is irrelevant. it determines what can and cannot be done in CL CL can run in RT space What is relevant is how the HAL driver to it triggers it to work. I'd hate to see all of the logic run in rt. it is a free-running 100ms task. user space CL would have a userspace HAL driver. the driver would update the hal pins when CL tells it to That works for me. the RT version could do the same - let CL's task call the driver to update pins that would work for 100mS stuff There are only a few signals that need rt. Estop, limits. But if we are running two cl's the user could choose any set of signals and space they want. why would CL need to know about limit switches ? I'd like to see all logic in one place. Matt called it functional encapsulation. it wouldn't - I would expect those critical bits would go straight to hal pins on the emc side (emcio / iotask) Nope IOtask is gone. huh? Or it is simply the nml to hal connector. yes - a connector No logic there at all. things like estop are connected directly to NML messages, or directly to the RT motion code... no logic needed Wrong. What are you doing with estop if it isn't logic. (directly still means thru hal, but not thru CL) Different countries have different standards for the use of estop. That is where the logic comes in. where is that logic now? bridgeportio? Doing anything with an IO signal ought to require a rung in cl. so CL is required for emc2, not an optional add on Say. I hate to run just when things are getting fun. can somebody tell me where estop logic is done now? jmkasunich: In my thinking that is true. If the user wants more than motion. I need a link to this discussion. Can someone email it to me? I was hoping basic hobby level systems wouldn't need CL but they still want estop estop should have (at most) one pin config and no pathways to interrupt it. I think motion.c should export an estop pin and an estop signal, and automatically connect the pin to the sig the config just has to connect one hardware input pin to the signal that would mean that the action on an estop is always the same (whatever motion.c defines it to be) ray has a point that some environments have different rules about estops... we'd either have to include those rules as options in motion.c (yuck) or make provisions for external logic (CL or other) between the HW hal pin and the motion.c one Estop is a global disable signal easy to say that, but does it apply to all machines in all jurisdictions? if it floats or evaluates to TRUE then the whole system halts. define halts - all motion stops, yes... but what if there are large inertias... is a coast stop (3 seconds, several feet) better/safer than active braking to a stop (0.5 seconds, several inches)? the safest might be active braking to a stop, followed by _hardware_ removal of power after a small hardware delay for the active braking to work estop would activate any braking systems. to activate braking systems you need "logic", either in SW or HW that may be so - But it does not break the estop signal. IOW, estop goes directly thru HAL to motion.c, and branches to CL or whatever else is needed to apply the brakes? HAL connects estop to an IO pin and exports the signal to ALL modules at no time does the estop signal "go through" another module so every module has an estop pin, all are connected to the external estop hardware pin... got that I'm sure we had this discussion a while back.... but what does each module do when its sees it's estop pin go true? ray's argument is that the "correct" action for a module isn't always the same - depends on the machine paul_c: it isn't really a hal issue - I agree we already solved that... it's a module coding issue. if a module doesn't always do the same thing on estop, we need to be able to configure what it does. Ray would like to use CL for that Some modules would either ignore the signal or go into a paused state motion and spindle IO must go to a halt state motion is pretty easy - override the PID outputs and force the velocity commands to zero but then... most tool builders would impliment a hard wired estop. yes, they should never, never, never trust software... and don't trust hardware either unless it is two pieces of metal with an air gap between them which turns the whole question in to an academic debate. maybe though I have seen systems where there is a software path that stops the machine quickly (reverse torque, etc) and a fail-safe path that isn't as fast but serves as a backup estop is a big issue with drives at work... been there and back again in anycase.... HAL should export an estop signal hal as in hal_lib? or each individual module that makes up emc, like motion.c? and is the only signal that can have multiple writers hal_lib... any particular reason to put it in the lib? only because it is the first HAL thing to be loaded. I suppose... I'm in favor of keeping the lib generic, but estop is certainly important paul_c: did you get my email about realtime and hal_lib? yes thoughts? if the last module unregisters from hal_lib, all memory should be freed duh... why didn't I think of that? hal_exit can check for any other hal modules freeing meta data and pin vars right there are still potential gotchas... you use the emc run script to load emc, then manually start halmeter... then finish with emc, and restart it without stopping halmeter.... memory won't get freed but that is much less likely same for rtapi - Once the timer owning module unregisters... timer isn't owned by any module... it's a global resource that times _all_ tasks but when all tasks are deleted, it can be shut down jmkasunich: yep, that was in my test script hal_lib itself doesn't create any tasks, so it can stay resident after all other hal modules are unloaded. I should be able to implement both of those fixes this evening hmmm... we just decided that hal_lib should export the estop signal... so that one won't get removed, hence we won't be able to free all the memory let me ponder that one, I think I can handle it estop is a special case... I hate special cases - they are what turns clean code ugly john: did you do any more thinking about whether thread creation should be taken out of components & drivers, and only be allowed from halcmd, or a special "thread" component? I like the idea, but hung up on the implementation... halcmd is a user space prog, can't create a task (which is what a thread is) only init_module() (of any module) can create threads a "threads" component could do it... something like "insmod threads threadname1 period1 threadname2 period2" yep, even _I_ could write that ine ;) another thing for John: I just read you e-mail re: timer... it would be _really_ nice if you didn't have to be root to create a thread halcmd is where we _want_ to do it for my part, I would favor loading & unloading all the modules (even rt-base) each time the emc is run. mshaver: we were leaning toward loading the RTOS stuff at boot (or at least allowing the user to choose that path) are we talking about the taig electronics ? jmkasunich:To save time? to avoid being root what he said Ahh, ok though we still need to insmod stuff when emc starts unless motion could be loaded in an idle state at boot motion, and parport, and stepgen, and encoder, and ..... my reasoning is that reloading everything cleans up shmem, in case we've made a blunder in malloc/free somewhere blunders? us? never! ;-) yes, my point exactly... ;) if you've screwed up on malloc/free, unloading will just soak up more memory depends - if you unload hal_lib, the entire hal shmem block is freed and if you unload rtapi, that entire block is freed too true. Maybe one of our tests should be a script that loads & unloads a hundred times to see if we lose any memory well we do have that leak that I mentioned in the email at least we know the cause of that one though hal uses it's own (crude) allocator and a fix has been suggested crude but completely predictable, so I am 99.9999% certain that is the only leak it is fortunate that memory allocation can only be done outside an RT thread. I will implement the fix, then take matt's suggesstion and load/unload a lot and see what happens so memory leaks are not really an issue right - if we loose to much shmem, then an insmod will fail... if all the modules insmod, then we are safe - can't run out while running RT code because kmalloc can only be used in the module_init, it is easy to check for a matching kfree in module_cleanup Since I have missed the last couple of sessions and the notice on LinuxCNC is not specific, what is the expected ending for the EMC Fest? Time to start planning travel. I'm not really sure when it ends I'll be there until wednesday night Has Paul mentioned when he is flying back? paul is planning several weeks of vacation travel in the US after NAMES - maybe even a month or more going out west I think Interesting... I was going to look into giving him a lift from Dulles to the show and was concerned about how long I would have to stay. If he is continuing elsewhere that becomes a moot issue. he has changed his plane tickets - IIRC last week he said he would be landing in detroit OK, that simplifies things for me. John, Matt.. I see lots of stuff getting committed to the Source Forge. Am I crazy to think you guys may have something that sort of works by NAMES? not crazy... a little touched perhaps depends on how you define "sort of works" Well, just having anything that compiles and gets motion connected enough to tinker with. I think he's just about there... I'm lagging behind myself Great news! EMC Fest should make great progress if there is enough to get that far.