Say. The MatPLC folk had a couple of excellent links in the last digest. Rant but better than that about using open software packages. I unsub'ed that list a while back... have the URL(s) handy? http://www.catb.org/~esr/writings/cups-horror.html That'll get you to the first the second is linked at the bottom. This a language I don't know yet? rayh: very interesting reading.... I need to revisit halscope with this in mind. * jmkasunich goes on to the second link... The note, " Is there any screen in my GUI that is a dead end, without giving guidance further into the system?" made me think, is there any that isn't? a key line: unlike a command tool for techies that should give them lots of choices, the goal of a GUI is to present the user with as few decision points as possible that drops us straight into the user/integrator thing... paul_c: remember my comments earlier this week about defaults on the parport? I dunno whether that is appropriate or not now... "Aunt Tillie's CNC!" CNC operaters, at least, could be considered "Aunt Tillie" actually, everyone is Aunt Tillie in some areas "Aunt Tillie's CNC!" To quote Hollywood Montrose in the old movie Mannequin, "Doesn't it just sing!" I may be Mr. Hacker when writing a kernel module to generate step pulses, but I'm Aunt Tillie when it comes to setting up a printer... I don't want to know how it works, I just want it to work. (BTW, I had similar problems with printing, and gave up after spending literally _hours_ on it Tell me. There are a thousand things with OS software that drive me nuts. printing is my bigest headache with systems also If you want an OS with plug'n'pray suitable for the average Dummie (dare I say, moron) - Use MS that's exactly what they'll do... and that's exactly the attitude ESR is arguing against besides, I'm no moron.. but I would rather spend my time developing emc code than fighting to set up printing on my machine esr is no moron either, but he was _forced_ to use his computer know-how to do what _should_ be a simple task for Joe User IMHO, Linux should be the system where the hacker _can_, if he wants to, delve into the details but if he doesn't want to, (or isn't a hacker), then he shouldn't _have_ to delve into the details not for "conventional" tasks like setting up printing Ive found just | lpr seems to answer all my printing woes jmkasunich: Right! We bill it as a system that lets you do anything that you want. But you must know how to do what you want. I believe that this may be the heart of the backlash against EMC. Paul's work with BDI made EMC accessable with very little foreknowledge. right - a key step But just the task of configuring emc to a machine is huge for some. yeah... and I'm afraid HAL isn't neccessarily going to make it easier. more flexible, yes Then running the obscure interfaces is daunting in the face of the fact of a cutter spinning at 3k and an axis moving at 100 ipm. one could have a little conversational .ini file writer program I've got to say that I live for HAL. Don't know much about it but my belief is that it will simplify the integration task by a factor of ??? easier said than done rayh: I believe it will, _IFF_ the integrator has the HAL model (components/pins/signals) in his head There is an ini file writer on the dropbox. Been there 5 years now. really But it fails the aunt tillie test. the task of building/integrating a machine is not aunt tillie work Oh. I think that it is. heh, i built a machine, thats the easy part I know several commercial machine integrators and without fail they think our stuff is great. But fitting it to a machine is a nightmare. wb0yrq: Tell me more?? about my machine? getting my machine to do anything is the part that sucks Yep and the experience of making it go. well, my machine is at http://www.acsnet.com/~al/cnc mostly old printer parts took many months to figure out all the steps needed to make it work driver boards, controller boards, software confusions i just knew i wanted to make things, cad to g-code to machine software was never clear to me it is now of course well, kinda clear I guess I need to clarify what I meant by building machines - that means mounting motors, hooking up drivers, wiring limit switches, etc. I was _not_ referring to physically building the machine itself - in fact many (most) emc installations are on conventional iron, not homemade machines seems like there isn't any clear standard (g-code) or nice writeups on the pieces that need to be put togehter Right. And there are many folk who start with hardware. Making it run, even thinking about making it run with the EMC is the more difficult task. making it run with anything was daunting to me I had the original BDI pretty much work right out of the box Yep. First motion can be a real steep wall to climb. Oh, tell me about it ;-) i am not a writer, but hope someone puts together a more complete site with info, not a site with links, omg, i followed links for weeks, got so lost gave up for 2 years before i went back to is wb0yrq: Yep and links get stale. yeah, that is a problem... i haven't looked, but an 'beginners guide to emc' would be great, assuming 2 things, 1 you have a machine, 2 you have emc and howto stuff using explicit versions of software can also get out of date very quickly then go into what electronics is needed, how to wire the motors, switches very true, but you can use emc as an example paul_c: the version specific stuff can/should be in the emc release - README or whatever... jmkasunich: I was thinking kernel/RT patching aunt tillie reads readmes? bet she reads beginners guides Yuch!!! aunt tillie does NOT! NOT! do kernel patches no joke heh, i don't even do kernel patches wb0yrq: so we call it beginners guide, not readme, my point is that it is _part_ if the emc package, and is specific to that version, so it doesn't go out of date been a sysadmin for 10 years, and quit patching kernels about 5 years ago I used to when that was the ONLY path to emc. BDI was a quantum jump that would work the exact same document posted on the web would be a disaster, cause 3 years later people are reading it and wondering why it doesn't work with their newer emc some of the info in it, will be timeless, (like how to rig up your motors, get a simple interface (electronics) going using a pic and some darlintons wb0yrq: the problem with wiring info is that there are as many designs as there are users emc covers everyone from somebody with unipolar steppers and darlingtons, thru geckos, thru high end servo drives I've had lots of discussions with myself over how much hardware to put into the User_Handbook. Very much and you loose the guy who just wants to run one. there are enormous amounts of such info out on the web already, yes it is hard to find the specifics, but writing it all up an putting it in one place would literelly take years Ballendo??? a thought: put just enough hardware to get a homebuilder running that is still a real span. what kind of homebuilder? unipolar steppers are the extreme low end - the only excuse for using them is poverty (sorry to be so blunt) I thought I knew servos pretty well after getting the BP going, but bigger motors on the Mazak are a different challange xylotex is the low end IMO * wb0yrq is in poverty gecko is midrange wb0yrq: building your own drivers then? i spent $90.00 us on my machine, and it was tough to dig that up (the spindle motor cost 75) yes i can afford a couple bucks for chips that i most likely have * paul_c uses big DC servos * wb0yrq drools i would like to control the servos' i tore out of these printers how is your electronics-fu? are they servos or steppers? mine? yes well, i know enough to know how little i know cause controlling servos with a few chips is not easy well on the really low end there are some nice 25 v 10a op amps...straight dc but... small low voltage servos can be done with a handfull of op amps and an H bridge assuming you know what you are doing... And herein lies the issue for the EMC. We need to tell, first that EMC has the power to control a servo with a simple H-Bridge. but it doesn't Jon E didn't believe it could until he tried it. he's not using a simple H-bridge, he has his USC board too I think building a controller with tacho feedback is not the hardest thing for position you need an encoder, no way around that... make one from a mouse, buy one from US digital, whatever the servos i have already have encoders on them (old high speed dotmatrix printers use the +-10V interface like all the older machines Imperator_: that assumes you have servo amps with +/-10 inputs yes ! which is were this all started - everybody's situation is different Simodrive 611 and Simodrive 610 it is tough to tune servos without a tach loop, not impossible but very difficult but I want to build my own one for normal DC Servos wb0yrq has naked motors and a pile of darlingtons or mosfets and no cash - he wants/needs to build a servo amp unfortunatly, emc cannot be the source for "how to build a servo amp" info J.E. has a schematic for servo amps so we start machine integrations at the component level , encoder/dac board, servos, motors and work up? i guess what i was getting at was: a person wants to do cnc stuff, they find emc first, a bit of direction where to go next, and where emc fits in the whole scheme Back to JonE for a sec. It wasn't the fact of his pulse generator board that led him to conclude that EMC could run H-Bridge only servo devices. yeah - unfortunately for wb0yrq, the vast majority of "integration" consists of interconnecting black boxes like amps, encoders, PIC/ISA cards and the software. that we need to address... we can't address how to build an amp IIRC Jon's amps are not cheap....in the $200 range to build He believed that for good servo you had to have a servo amp with full tach feedback. And all the sig filtering that he built into his boards. found some new Copley amps @ $150 each Now he has seen that EMC has the ability to reach out and control an H-Bridge without all the hardware. rayh: I think he's still using the USC to generate PWM (that's too fast for SW), but you're right, he no longer needs analog tach feedback and the analog current/torque loop But I was using JonE as an example. Not for his hardware. that is still interesting info A simple H-Bridge is inexpensive to build. example of what? That emc can control motors with _just_ an H-bridge and encoder? I say it cant Put a $10 pic out there to make the pwm and you're half way home. perhaps but that still means external hardware (ok, so I'm nitpicking) as wb0 pointed out, we still need to read the encoders or some sort of positioning. out of emc what do i get? step/direction? or is there some kind of output for servos? emc can do step/dir, or analog outs (with the appropriate PCI or ISA card, which you can't afford) This is exactly the point. What can EMC do? i hate being broke, hehe, but, i still haveing alot of fun with my machine i have startet sone weeks ago to draw with eagle a Schematic of an amp with tache feedback and a current controller, it needs +-10V input generatet from emc with an DAC so you need a DAC... This is where I thought that the Integrators_Handbook ought to shine. it took me about 5 years to get the amps, etc accumulated to get the BP going...piece at a time It would be the "hardware guys" guide to EMC. also where HAL comes in... the "core" of emc2 has only one kind of output, position commands... then HAL can be used to convert that to analog velocity commands->DAC->servo amp, or to step/dir->parport->stepper driver, or to whatever somebody writes a HAL driver for its an interface issue really... you can have a 20W servo amp, and a 20kW servo amp, that both take +/-10V, and both will work, cause the interface is the same so who is going to write the machine integration part of the handbook? It is rather easy to see the hardware problems from this brief excursion. the handbook needs to make some assumptions... for one, the integrator isn't building his own amps I think that one is safe (if he is, he needs to look elsewhere for that info, and come back when the amps are done) It needs two sections ... servo and stepper don't forget step/dir servo ala gecko 320... they are treatet like steppers perhaps the first section should be an intro to motor control approaches yep, assuming the user understands that... hence the first section I got a kick out of the Boeing engineer talking about servos systems....."it is pretty easy once you get passed the Laplace transforms." ;-) I'll see what I can bring to NAMES Integrators_Handbook is in sourceforge -- a lyx file set. what are we going to do when emc2 comes out... it will want it's own handbook I think (at least certain chapters) other chapters will be the same for both the basic concepts remain the same about the handbook, i think it will be a good idea to make a wiki out of it, mybe then it will grow much faster Nope! Sorry to be so certain but the Developers_Handbook ought to have HAL stuff now. I started one chapter on RTAPI and it got nixed. how close is the hal to working? HAL only exists in emc2, and would confuse people using emc1 Developers ought to be state of the art. Not at all. so you fork the writing A developer should know the difference. it is much easier to edit than write!!! I don't think we need a fork for HAL. We need a first hal chapter. this is a matter of opinion, but I think emc2 is a significant break with emc1... I don't want emc2 docs mixed with emc1 docs There are no docs for emc2 Yes you've got one man page but it doesn't say anything. I know I did a doxygen of emc2 a week ago and that was a bit more enlightening. * jmkasunich opens his TODO file and add "write HAL doc" but it ran to 18 Meg. 17.5meg was probably emc1 carryovers, 0.5M rtapi/hal new stuff jmk but in that todo that it ought to be in LyX. what version of lyx Doesn't matter whether new or old. It needs to be! Any lyx. lyx2lyx should be able to handle the update. how does lyx handle pictures... I _must_ have pictures! pngs work well. I have lyx-1.1.6fix4-1 installed on this box Right. I built a 1.3.2 for TNG here and that was okay. how about postscript? (scales well, low res for inet, high res for printing) I like the qt version better. should I try to upgrade to 1.3.2? Have 1.3.3 on Knoppixbox. convert will handle the fitting of an image into postscript or pdf or whatever now. That's why I went through and threw out the eps stuff. I can generate them in PS (and prefer to do that) I'm talking about line drawings with text (block diagrams, data structures, etc)... bitmaps get the jaggies if low res, and bulky if high res... PS works for both Most any vector could do the job. I'd think that we could build these for EMC-Monday and then press them into a handbook. Doxygen built some rather nice data structure diagrams. I know nothing of what they mean to a programmer. some of them were pretty convoluted when I tried it the inheritance trees where the most usefull. I don't think it wise to build a handbook based on the Doxygen output... inheritance trees implies they were documenting C++ stuff yup paul_c: agreed 100%, a computer can't replace a human writer wb0yrq: Beautiful job on your router. thank you, i learned alot from it, and my next one will be much better wb0yrq: Your experience is what i imagine is needed in the integrators book. Just as John and Paul's is needed in the developers book. well, i am not a writer, but i will write something up if anyone wants to 'beautify' it I'm not much of a beautifier but, if you write it, I'll try. changing the subject a bit, I'm finishing up a tickle editor to put into mini. I've got two screens going, lyx document and kwrite with the code. rayh: not to lessen the importance of wb0yrq's experience, but IMO the handbook should not be about "here's how I managed to fight my way thru this task" as about "here's the right way to do this task" where "right" means what the designers had in mind when they wrote it I understand your point, John. of course that would carry more weight if I had indeed written such a thing... ;-) Experience needs a place to express itself, hence his web pages. well, i will write up my experiences and your welcome to strip just the good points exactly (I'v not seen the page yet, Mozilla just kills this box) or take things i have encountered and put the right way to do it and also take the problems you encountered and fix them! And that experience needs to be shaped into the integration book as a valid way. as I said, I don't want to minimize the importance of your experience heh, don't worry about that, Oh. Back to the point I was making about having both the documentation and the code side by side. I've found several things in the code, tickle, that were convoluted when I wrote about them in the document. But then I always have employed the brute force method of code writing. When I transfer these things to plain english, I see many ways to simplify the code. Now a real code writers experiece may be very different. rayh: right - I do the same, but my "english" is usually in the .h file (cause I do low level stuff, APIs and such, so the .h is the doc) but I always write a paragraph or several describing what a public function does before I write the function. The way that I see the handbooks moving forward is through evolution. the best place for a developer to learn about my code is to read hal.h and rtapi.h Stuff gets written into the developer version. Migrates into the integrators and then as users get to it the config gets into the users book. jmkasunich: I'm with you that your documentation needs to be right in the code. That's why I was looking at it with doxygen. But there needs to be a higher level of documentation that allows a would be developer to read about the code rather than read the code itself (my dyslexia gets worse when I get enthusiastic.) rayh: open rtapi.h and take a look... that is _about_ the code ray..at least you can still spell The higher level reading needs to tell where to approach the code. Just like you (jmk) just did. Add to it what rtapi.h does and you've got a document that works for me. Fred P did that old thing describing each file in EMC1. It just started us talking about how those files fit togehter. That's what we need for emc2. but I think that we have to start with the rtapi then the hal then the emc on top of hal slowly working through the code documenting bits So can one generate a flow diagram with the description in ...and what it calls? Matt tried to explain how hal fit with shmem and I was really lost. flow charts are good. paul_c: You are right on when you say that the code itself needs to be commented first. is the idea here to freeze docs for emc1 and work on better docs for emc2? I don't think, and John has said this, emc is not documented. Fragments are. so you flesh out 1 and use as a springboard to 2? dave_: That's the way that I've been heading. and much of the code is so damned convoluted, documenting it is a pain paul_c: you are right there. is there a cure? emc2 emc2 with cleaner code and better docs! even now, you still don't want to look at much of the code I've dragged across. Then our documentation might want to be fiction. For a while, until we conform the code to what our fiction says that it ought to be. I'm of the opinion that we should copy over from emc1 the docs that apply, but they should be cleaned up _as_ we copy them, not later... with code, sometimes we have no choice - you need so much code to have a working, testable system that you need to bring much of it over wholesale, with no cleaning and no real understanding of how it works. Docs don't have that excuse on a micro scale, everything I do is like that - write the doc or .h file comment, then code to match everything needed for a running system has been moved over already. code yes, docs no just the low level drivers are missing ...were missing. Are you suggesting that we create a new directory documents/lyx2? And nothing gets in there without a vote. we already have emc2/docs (and I'd rather keep it that way) all emc2 stuff in one CVS tree No lyx? sorry, I wasn't clear So lay persons documents! Okay we can put lyx, whatever under emc2/docs Why duplicate all of the images. gets back to that opinion thing - I see emc2 a a break with the past, and am willing to have some duplication to make it stand alone Okay it will stand alone. there will be much that is new, not duplicated apart from configuration, is there much difference in the usr guides ? user guide, and especially the _very_ good g-code stuff no.... I forgot about that I agree we don't want to duplicate that I don't see much point in duplicating the docs.. Use the existing Documents directory for the master lyx src and have the final PDF in emc2/docs works for me as long as Joe user can d/l emc2 only and have what he needs but the pdf in emc2/docs should include only that which is relavent to emc2 Rational: The packages required to use LyX docs are large and have one task. is there an equivalent of make for lyx? ie make all makes emc1user.pdf and emc2user.pdf (nearly identical, but not quite), emc1integrator.pdf and emc2integrator.pdf (quite different) You can rather easily build a master document in Lyx. probably find a CLI for LyX.... Look at the lyx directory now there are three Masters in there. each master pulls in the needed chapters? perfect! You just include those units that you want. It does the numbering and all and can even pass references from one chapter to another. I've thought about making a Programming_Manual and all that it would take would be to make a master for it. can even generate Indexes with LyX Then we'd have to fix some of my poor writing and flesh it out a bit. looking for a moment at emc2/directory.map... seems like the emc2/docs dir will be for man pages and other simple docs only, the main lyx docs would stay in documents/... I can live with that paul_c: Indexing was one of my weak points. You did this far better than I. We also need to go through the LyX files stripping out any oddball white spaces Yes we do. Those d*&^% things are a real pain when you put them to pdf. noticed several screwey characters printed out in the final PDF Programming Manual - As in G code or C/C++ ? ray...back to the programming manual.....g-code | C/c++ ? * rayh jumps up and down cause he got buttons that save and spit back highlighted text It isn't a macro but in a way it works better for g-code editing. dave_: I'll wait for better coding minds for an answer on that one. I prefer the fiction notion. Write what we think it ought to work like and then conform the code to that. rayh: huh? you said you thought about writing a programming manual... a g-code prog manual and a C one are completely different projects, which were you thinking of? methinks source code docs are best left as comments in the sources I was thinking of dave's | C/c++. the "fiction" can be in the form of comments, either in the source or .h files I guess that I was thinking of an overview or big picture fiction. * jmkasunich is confused: ray doesn't program in C or C++ (I think) but he considers writing a manual about how to do so? Interp does this --> task does this --> mot or io does this --> shmem holds this --> shmemtask does this to HAL -- hal does this to pins. It's not a C/C++ thing it's a how the individual tasks fit together. that _is_ the Developers handbook in a nutshell, as least as I see it I don't think that's right -- How can we agree? that's where I was when I started my block diagrams a year ago :) what do you think the developer's handbook is? Yep. I'd like to see those blocks work for the hal, the shmem, the task ... some people are command-line others are gui command lines rule! I'm guessing here but I think that all developers will be text based. They may well see the big pic in graphical or block diagrams but text is their tool. wb0yrq: You and Paul. no lyx for the dev? and me! Yes I think LyX is the handbook tool. this is a sucky method of communication... you just said: "I think that all developers will be text based. They may well see the big pic in graphical or block diagrams but text is their tool." so is the dev handbook lyx or text?> got to be lyx based ok, so we all agree on that... I just got confused by ray's statement I guess that I was thinking of people entering text into a widget rather than as a format for the text that they enter. I can be a confusing kind of guy;) all I'm trying to do is figure out what the dev handbook will contain... I've been trying to write a "manifesto" or philosophy for the introduction. seems like it should have a high level overview of how emc works, then dig down into the major blocks, and point out which files are involved in each part... then it should point to the individual files for details - if too many details are in the book itself it will rapidly go obsolete That is what I'd like us to argue about for a bit on monday. Yep exactly right john. block diagrams and over-views work for me. gory details found in the src for instance, a part I understand. rtapi.. the book should explain the goals of rtapi, the "why it exists", then reference rtapi.h for the API. it will certainly go obsolete quickly unless maintained...if there is much detail... paul_c: I can almost see a big org chart. likewise for libnml - with the warning "Here be dragons" the book would also cover the concepts we used for the configure and rtapi.conf scripts, and the realtime script jmkasunich: a bit more detail would help me. rayh: more than rtapi.h you mean? or including detail from rtapi.h in the book? warning "Here be dragons" could be the front page of www.linuxcnc. Some detail about each file. How it relates to others. I'm thinking of the pipe notion of unix. I think a directory overview rather than a per file What it gets, what it does, what it sends. I think almost every file is worthy of at least a paragraph before that happens, might I make a suggestion ? I will say, that after all the work a coder goes through, it should be worthy of much more. in the case of HAL and RTAPI, which are both APIs, I really want to see man pages for each function each public function paul_c: shoot the hal dir needs a clean up with hal_meter & scope moved into sub dirs yes we have hal/drivers and hal/components, should add hal/utilities or something like that (suggestions?) hal/util scope and meter in seperate dirs utils for halcmd and lib for the hal_lib ? hal_lib is a single file - if we get the utilities out of there, it can stay in src/hal IMO that works for me... added to my todo list... This is a mistake that we made with emc. We thought that somehow we had to preserve the run nature of directories in the repository. huh? likewise - Huh ? For the longest time we had a whole bunch of directories and files that created diretories spread out around the rep. ;-) Why should we require that the emc directory contain the configuration or run stuff. When we build a working system from the source, put those files where we need them. emc2 has a scripts dir and a configs dir you mean "make install" - putting stuff in /usr/bin, or wherever it belongs? Yea, and why? When the stuff in them is code. you think it belongs in src/scripts or something? I don't know. That's for the code gurus. I know that tickle stuff is spread all over in emc1. I must admit I don't understand tickle Is it script, or code, or does it deserve it's own place. it messes with my neat little C view of the world in emc2, all the tcl/tk files are in one tree - Even tkemc I confess that I may have created part of the problem for the rep. so do the ini files go in their own dir when I committed a emc/scripts directory and put my tickle scripts there. paul_c: rayh has a point tho... we have emcsh.cc under the src tree, because it is C++ then interfaces to tcl... but all the actual tcl source (the guis, etc) are _not_ in the src tree... why not, they are source? 'cos they are scripts. Then Will grabbed it and put generic bash scripts there. rayh: open emc2/directory.map and take a look anything under scr/ is compiled well those scripts are essentially executable! Not in emc1 they are not. Makefile moves several tickle scripts and changes a line in them. dave_: ini files - It has been suggested that configs are grouped in directories. One dir for each machine. look at what make changes in the *.tcl That sounds like a waste of directories, unless we start running riser. pc sounds logical to me one line - the PLAT path back to tcl... if make touches a file, then I think the original should be under emc2/src/something, and the result be installed in emc2/tcl paul_c: But if make doesn't do it who will? if it needs done, make should do it Or would we have a Makefile in src/tcl as well. use plat/realtime instead of plat/linux_foo_bar_glbc_2_9_64 rayh: yes - every subdir under src has a Makefile in emc2, it is even easier. Although I must admit, it would be easier if we did away with plat and just used a generic name for real and nonrealtime binaries. see emc2/bin & emc2/rtlib one make, builds both RT and user binaries and sticks them in those two dirs * jmkasunich thinks the emc2 make system is _far_ better than emc1 so how come you guys are having to commit new versions of makefiles so often;) because when we add a new driver, or module, or whatever, we need to add it to the makefiles and because the makefiles (and configure script) are what deals with platform dependencies most of the platform deps are delt with in configure frequent changes to configure and makefiles is a good thing - it means we are testing make on many platforms, and _fixing_ it when we find a problem as opposed to creating a work-round Seems to this outsider, that we are simply building our way back into the same make hell that we had before. have you tried compiling emc2 ? i suggest to make a sub folder for every new driver, with his own makefile, because i startet to write a driver fore emc1 and i give it up after two weeks because of the makefile make hell? the goal for emc2 is that anyone can do "./configure" followed by "make" and have a working emc customized to their box Ipm: take a look at the makefile in emc2/src/hal/drivers paul_c: Nope. Have not had a spare moment. and the only people needing config options are the ones with multiple kernel/libs jmkasunich: This sounds fantastic. try it, you'll like it.... and it compiles with rtai-3 do "./configure silent" so it's easier to see any warnings during the make btw, I noticed a couple unused symbol warnings in my last build, one of the files matt is working on I think emc/control.c ? other than that it's clean here... if it's not clean there, let us know. we want to fix it the problem is, if you have more and more drivers, than the makefile will look like the one in emc1 in the emcmot folder. Um;) As much as I'd like to get on the emc2 wagon, I'm stuck integrating to real machines real quick. Imperator_: Not if we keep seperate dirs for each driver rayh: you can do "cd emc2" "cvs up -d" "./configure silent" "make" in under ten minutes while we talk here... try it I know it won't run your machines, but you can see what we are trying to do Sorry. No time. I'm an aunt tillie on that one. paul_c: that is exactly hat i mean, but at the moment there is only one drivers folder someone going to do a show and tell for emc2 at emc-mon? In that case, not to be rude, I suggest that you not criticize the approach we're taking... I'm very busy with an editor that no one here cares about but is way overdue for my audience ok Right, John. You got it. Imperator_: with just one driver in it :-) Must run, guy's. i'm writing on the next one ok, take care ray As always it has been a joy. Imperator_: what are you writing a driver for? I'm out here too...enjoy! ship, sinking, rats ? * jmkasunich bails madly I'm startin step by step, first i wan't to trigger some LED's on an ISA card i made, then i want to do the same on that PCI prototype board laing next to me, and then this has to be a encoder reading card, and maybe a DAC card they must think we're all loons here. start with the parport driver jmkasunich: is emc2/src/hal/drivers/parport going too deep ? you mean a dir for each driver? yes I think most drivers will be one source file... I'd rather not, but I'll keep an open mind about it well.... Imperator_ suggested it jmkasunich: yes i have copyd it, and i try to understand it at the moment right Imperator_: that's where I owe you guys an intro to hal that explains the concepts of pins, signals, functions, etc perhaps split common code out... If there is any. certainly as we move to PCI based cards there will be plenty of common code that would be what i need, an skeleton driver or something with good coments parport is a fairly good skeleton... once we finish any other general discussions, I'd be happy to walk thru parport.c with you explaining it... I'll log the explanations, maybe they'll be the start of the intro doc I need to write not sur a PCI driver would have too much common code beyond what is already in parport. paul_c: the init parts of a driver certainly lend themselves to common code what about the code to discover the port address? trivial two to three lines oh, thought it was more init code would be card dependent you need code for finding the card, that is everytime the same code to export pins, etc, could be generalized and driven by a table or something instead of hardcoded for example, all pin names should be of the form ".." for example: parport.1.pin-1-out stg.2.dac-1-out usc.1.encoder-1-in those last two are silly why? dac by definition is an output true and encoder, input so just dac1 or maybe dac-1-value (to distinguish it from stg.2.dac-1-scale - a parameter) which points out the very first step in writing a driver... define the HAL interface to it in parport, each physical output pin has a correspinding HAL pin, and a parameter the pin is parport.1.pin-1-out, and the parameter is parport.1.pin-1-invert... if the param is set to 1, the output is inverted, else it is not stg.dac then configs stg.dac.scale, stg.dac.offset yes, exactly... so when you sit down to write the stg driver, you need to decide what pins and params you will export hopefully we will have some conventions for that, for instance _all_ single bit digital outputs should have an invert parameter and all single bit digital ins should have two hal pins. xxx.1.pin-1-in, and .pin-1-in-not all analog outs should have scale and offset (or maybe span and offset, but all should use the same names) so first step, decide what pins/params you will export. second step - document them, in the comments at the head of the driver source file *** paul_c is now known as paul_AWOL Imperator_: you want to look at parport.c? yes * jmkasunich opens an editor window ok, first is a general comment about what it is... i think the last sentences you can directly copy to the handbook I have been logging all day, I will do that anyway, next paragraph describes device specific config stuff... in this case, the address of the parport this driver can be compiled as both a user and realtime module (we would like all drivers to work that way, may be complicated for some) in any case, this gives the command lines to load both versions of the driver you have to know the address.... PCI might make this much simpler (but the code would be more complicated) then we have the list of pins and parameters that are exported... thats for the shared memory comunication ! if you aren't familiar with the hal concepts of pins and parameters, this is probably the first stumbling block yes. i have yust startet to read the hal.h shared memory is how data from one device is accessed by other modules yes the text under "general notes and documentation" in hal.h is the best intro so far... I need to do better if it is compiled as a user space program, then it is loaded as a normal program, is that right ?? right - for example "parport 378" But will then the init and exit code executed ?? not really that is then the biggest difference betwen user space and realtime ore ?? there are two sets of init/exit code, one is rtapi_app_main() and rtapi_app_exit(), and is used only for realtime the other is main() and is used only for user space the symbol RTAPI is defined when compiling for realtime, and ULAPI is defined when compiling for user space, so #ifdef RTAPI is used to decide which block of code is compiled the user space one is probably easier to understand if you aren't into writing linux kernel modules, so look at that one one moment i have to read ok main is around line 290 (aprox... I'm adding comments as we talk, so numbers may change a little) BTW, this is very usefull - I'm seeing where I need to document better, and trying to do it as we go along yes I'm here for a little while, but I don't know that I'll be abe to contribute much, having missed the bulk of the meeting... mshaver: ray posted a couple links that are worth reading, then we talked alot about docs I'm going to get the log & read it right now imperator and I are walking thru parport.c, he wants to write a driver for some hardware he has. That's probably the best use of the irc time now! I think you might want to participate in what we're doing - I'm logging, and will try to use it to do better description of the HAL okie dokie, I'll comment as I think necessary! ok, i see the main, it takes the args, reserves some memory, well the very first thing it does is calls pins_and_params() then it asks for the io space yeah, but we should look at pins_and_params first ok line 520 or so jep first part is parsing - every driver will do that differently but by the time we get to /* OK, now we've parsed... we know how many ports the user wants, what their addresses are, and whether they are in or out jey yes so the first HAL API call is hal_init(), this registers your program as a driver, and gets you access to the hal shared memory area for details look in hal.h later, but for now lets move on the next thing we do is allocate a chunk of shared memory to hold an array of parport_t structures, one for each port the parport_t struc definition is at the top of the file, around line 140 yes i have seen note that once we have called hal_init, if we want to exit, we have to call hal_exit() to release shared memory access and then it exports the pins and returns right, now were back in main user space progs will segfault if they access I/O ports withoug permission, so the next thing we do is ask for permission if we're not root, that will fail... when i was reading i don't notised teh pins_and_parms function if it fails, we print the message and call hal_exit(), hal_exit will take care of undoing all the stuff that pins_and_params() exported, so we don't have to clean up after ourselves I did read some this morning, and I think that both jmk & ray have valid points: 1. The docs HAVE TO be current with the code, &, 2. We need to have docs, that is, mode docs than we have now. Which means we will probably have to import some of the emc1 stuff to fill the gap. mshaver: yes - but the things we import from emc1 need to be carefully checked, and stuff that doesn't apply to emc2 ruthlessly deleted jmkasunich: Yes, agree 100%. In fact, there are probably things in the emc1 docs that are out of date with emc1. In the grand scheme of things, I think that if emc development continues for another couple years it will be deserving of an O'Reilly book. mshaver: I dunno if that's good or bad ;-) jmkasunich: Oh, it's good. I'm sure of it ;) It's a big subject, plus an O'Reilly book would confer upon the emc project a sort of geek imprimatur. I'll get the log now & shut up a bit so you guys can continue... I think if you have to buy a book to understand it, it's not so good anyway, back to parport.c before we get into the guts of main, lets look at the functions that actually interact with the hardware that would be read_port() and write_port() they are the reason for the whole thing... i have them ok... read_port gets called when it's time to read data from the port... for now, don't worry about how that happens (it is different for user and realtime) 'arg' is a pointer to the parport_t structure for the particular port 'period' is the period (time between calls) when called from realtime - parport doesn't use it, other driver might read_port() needs to be realtime capable code, so it can't make normal C library calls, no file I/O, and nothing that can block... it uses _only_ information in the parport_t struct the details obviously depend on the device and will change from driver to driver but what it basically does is read the hardware port and write the data to members of the parport_t struct (which is in shared memory) it splits only the data into the individual pins right ok and since the members of the struct were exported as HAL pins, other hal modules can access that data this is very usefull... I was thinking parport was a good skeleton, but it has too much specific stuff in it.. I should write a real skeleton that does nothing buts is _very_ well commented getting back to the code... you can see that read_port makes no calls except to rtapi_inb yes i think so lots of pointer and bit manipulation going on there, doesn't make it easy to read I used bits of encoder.c & stepgen.c as a skeleton for supply.c. A real skeleton.c would be a good idea. yes you have to yump through the code and the layout of the parport_t struct was also done with speed, not clarity in mind but it looks good remember that read_port and write_port can be called in realtime, sometimes 50,000 times or more a second... so for these functions (and only these functions) speed is critical the rest of the code is init and config, and usually only runs once yes write_port() is similar to read_port, but it gathers data from the individual struct members and assembles it into a byte, then writes the byte to hardware with rtapi_outb() i have seen this ok and write_all ansd read_all is easy ok, so the question now is how does read_port and write_port get called? that's the point, i wantet to ask a long time before originally this was designed for realtime only, and that is what you have to think about to understand it... in realtime, you have a task, that runs at a specific rate. for instance, maybe 1mS... in realtime it is done by the OS when you create a 1mS task, the RTOS starts a hardware timer that interrupts the CPU every 1mS... when the interrupt happens, the CPU drops whatever user processing it was doing, and runs the realtime code realtime code must take less than 1mS, or you have a problem ;-) but normally, a RT task gets done in less than 1mS, and the CPU returns to user processing next 1mS interrupt happens, CPU runs realtime task again... HAL has something called "threads", which are basically a wrapper around realtime tasks so something (probably an emc module) creates a thread, that runs every 1mS to use parport with emc, you want to call read_port() at the beginning of that thread, to read the inputs. then the realtime part of emc itself runs, using the inputs. It gets them from the HAL pins. once emc runs, it writes its outputs to other HAL pins, and finally you want to run write_port to copy from the hal pins to the hardware when emc is compiled, you don't know whether you are gonna use parport or some other driver... so you can't connect read_port directly to the emc thread instead we "export" read_port. that makes it available to be linked to a thread have I got you confused yet? I'm not sure if I should have started talking about realtime or not...\ one moment i thought it was nonrealtime the tread is the kernel modul parport, ore ?? yeah, I shouldn't have started talking about realtime... sorry lets forget about threads and such for now we have pins and paremeters, and we have read_port and write_port that copy data between the HAL shared mem and the physical I/O port this threads you mean are the userspace version oder threads are realtime and every thread is a kernel_module no - every thread is a task... a kernal module can have more than one thread/task, it can also have zero threads/tasks I definetly shouldn't have started talking about realtime :-) ok let's go on lets go back to user space, and back to main() jep we have pins and paremeters, and we have read_port and write_port that copy data between the HAL shared mem and the physical I/O port but so far we have no way to run those functions yes lets skip the code that exports "function parameters", and move to the line that says /* main loop */ around line 360 or so done is 0, so the loop will run forever don't worry about how it stops, we'll get back to that ok i think you have to make here a big line with stars read_funct_flags[] is an array of hal parameters, they were exported just like the pins and params (by the code we skipped) assume that read_funct_flags[0] is -1 so every time thru the loop, we call read_all()... that's how the functions get called... ok since read_funct_flags[0] is a parameter, the user can change it... if it is 0, the function is not called... if it is positive, the function gets called once, and the parameter is reset to zero we do the same for each individual port (read_funct_flags[n]) and for the write functions and sched_yield() controls the speed of the loop yes!, but not very well something like sleep() would be better, but sleep yields the CPU for a minimum of 1 second I'd really like to yield it for about 0.01 to 0.1 seconds remember that this is not realtime - sched_yield() or sleep() might not return for a long time (longer than several seconds) if the CPU is busy. yes and if there are no other processes, sched_yield() returns immediately so we might call read_port thousands of times per second ok, but normaly it is used in realtime, then you don't have this problem, i think i think you have to make a bigger comment for this main loop, because it is nearly invissible in the code yes, doing that now now, as for how it ends... the two lines just before main loop install handlers for SIGINT (ctrl-C) and SIGTERM (kill) the handler is function quit(), which simply sets 'done' to 1 once 'done' = 1, the loop exits, call hal_exit() to clean up everything we exported, and done! then Linux interrupts the loop well SIGINT is sort of an interrupt... when you hit ctrl-c, the function quit() runs line 284 or so... you can think of quit() as an interrupt routine, triggered by the SIGINT or SIGTERM ahhh as soon as quit returns, the SIGINT is over... and the main loop resumes wherever it was eventually it gets to the bottom of the loop, jumps back to the top, and guess what? "while (!done)" is no longer true, so the loop ends yes any questions? ;-) and where is definded which functions have to be called in every period when it runs in realtime ? that was the first :-) in realtime, the functions "read_port(), write_port(), read_all(), write_all()" are exported to the HAL shared memory area that's where threads come into it oops - I was gonna recommend that you run the demo script "hal_demo parport1" to see how the realtime version works, but... it doesn't work anymore. ?? originally the RT version of parport could also create a RT thread - handy for testing, but not used for anything else... last week when I added the user space part of parport, I removed the ability to create a RT thread the demo relied on that ability, need to re-do the demo * paul_c has been fed & watered it is humbling to see my code thru the eyes of someone else... what I thought was clear is only clear because I already understood all the concepts behind it yes if you do it by yourself it is always clear but if you make a skeleton, than i think it will not get so much smaller maybe not smaller, but hopefully clearer easier to understand, because irrelevant details can be removed the code that processes individual bits of a byte read from the parport can be deleted for example yes can we make that now ! too many details makes it hard to see the overall structure ore bginn with that skeleton driver is now at the top of my todo list ok the driver looks now much smaller than a houre before, thank you very much jmkasunich: comment on iopl(3) check it before allocating memory or registering with HAL then you can avoid any cleanup if not root paul_c: good point but I thought I had a reason for doing it in that order... * jmkasunich tries to remember ah... now I remember... I was going to use iperm, and for that one you need to know the specific ports you want permission for, hence need to have parsed the command line but ioperm doesn't work for ports above 3ff true so now that I'm using iopl, I should indeed move it to the beginning done but if you're using a PCI parport @ 0xd800, more problems afoot. assuming you use manual methods to discover the port addy, does the existing driver work? (no PCI parport to test with) "parport d800"? PCI parports work with EMC, so they *should* work with emc2 one would hope... but since the HAL parport driver is completely new, who knows? my guess is the driver works, but finding the address manually will be a pain if parport_pc has been loaded, it will be listed in /proc/ioports and if not, it will still be listed in /proc/pci what is parport_pc? I have reservations about loading any _other_ modules that might "compete" with hal_parport for the port parport.o and parport_pc are the basic kernel drivers do they treat the parport as raw I/O, or do they think of it as a printer? and if raw I/O, what benefit do they provide? this is where things get to be fun.... not loaded here the modules provide basic printer control as well as a "gateway" for parport storage devices /proc/ioports here shows neither parport (I have 2, one on MB and one on an ISA card) do a "modprobe parport_pc" /proc/ioports now says: 0278-027a : parport1 027b-027f : parport1 (didn't expect that) 0378-037a : parport0 037b-037f : parport0 (didn't expect that either) maybe the extra ports above xx7a are for EPP and ECP? the thing that bugs me about loading that module... what if somebody does cat somefile >/dev/parport0 will that module result in the file shooting out the parport? not good (can you say uncommanded motor motion!) it dumps raw data to the parport. right - a _very_ bad thing... (or would that happen even if the module isn't loaded, just because /dev/parport0 does it? /dev/parport0 is the access point to the parport if the driver isn't loaded, nothing happens ok, that explains why I have dev/parport0 thru 7, even though there are only two parports in my box the parport_pc module is the driver... I think? one of three ways round the problem 1) don't load parport_pc (not good if one port really does have a printer on it) 1) claim the parport before parport.o is loaded 2) try to claim the port after parport.o has been loaded - High risk. 3) ignore the problem (as EMC does) ;-\ what does "claim the port" mean? is that ioperm()? nope - There is a kernel call to register IO ports and which module is using them. ok, so _only_ available to realtime driver I guess hal_parport.c is ignoring the problem too - it should really make that call shouldn't it? it will fail if parport.o has claimed the port as it should - there should only be one driver for the port but that means our parport driver would have to load first or modules.conf set to ignore the port in question. btw, we talked about the name conflict between hal's parport and Linux's parport module... yes should we change our source file to hal_parport.c, or just change the makefile so module hal_parport.o is made from parport.c perhaps the default link rule in the /src/hal/drivers/Makefile should prepend hal to every module it links paul_c: the kernel call you mean for to register IO ports you mean is that "request_region" ?? change the src file name use an explicit rule to change the name but don't use a generic rule to prepend hal_ why not? hal_stg, hal_usc, hal_parport, hal_vigilant hal_hal_foo_driver.o that's a mistake on the part of the driver writer if the convention is to name the source file for the device and let the makefile prepend hal_, then they follow the convention and all is well. trust the programmer to choose the right name - Don't force policy on them. I see where you are coming from... but sometimes a little "policy" goes a long way toward eliminating confusion put it in a read.me and tag it as a guideline or a note in the makefile. fair enough - so what should be the guideline? I favor renaming the source file - I want default rules to do as much as possible... right now adding a new driver means only adding the name of the module to SRCS, RT_SRCS, etc, _not_ adding another rule renaming the file is fine by me. explicit rules will come in handy for complex drivers built from multiple sources. yes from a CVS perspective - if we rename a file, we have to do "cvs add " "cvs rm ", right? cvs add & remove - No single command. so we loose a little revision history (or at least obfuscate it) I can live with that. do non-driver HAL things like encoder or stepgen need to be renamed? I don't think so... the rename is to avoid conflicts with existing kernel modules. I guess that comes back to - do we recommend that all hal driver be prefixed with hal_, or do we wait for conflicts to occur and then rename only those drivers or modules? "suggest" using a hal_ prefix - Avoids conflicts with EMC drivers (not that it would be a problem) just added to src/hal/drivers/Makefile: # NOTE: To avoid possible confusion or contention with # normal Linux drivers, all HAL drivers should begin with # the string "hal_" that works for me. but _not_ planning to do the same note in src/hal/components (unless you think I should) could take it to it's conclusion and apply the same naming rules to _all_ modules.... the things we are planning to move to src/hal/utils already begin with hal_ emc2_hal_foo.o a bit extreme... tongue in cheek. only a concern if they wind up in some shared namespace... scope, meter, and cmd instead of halscope, halmeter, and halcmd might or might not be a problem hal's pid is about the only other one that might cause probs.... so conclusion is that we prefix _only_ the drivers, no need to go crazy with it? only drivers that will cause conflicts with names. but hal_drivers is a reasonable compromise as far as we know, that is only parport? so I should _not_ have that note I just added to the makefile? how can the simplest things get be so difficult ;-) ok, the note stays... In the long run hal_drivers may be the best solution right - that's settled - finally ;-) there may come a time when an alternative to hal_lib becomes available maybe from the kernel authors now another thing on my to-do moving halscope, etc to hal/utils because the move involves cvs remove cvs add, we can change names if we want... yup how do you feel about scope and meter instead of halscope and halmeter? not bothered by a name change to scope & meter my only concern about meter and scope is they are not exactly "rare" words, and future conflicts aren't out of the question but I certainly would rather type the short form On balance, halscope is probably a better choice - There is another project Xscope but then, it is your pet - Your choice. I'll stick with halscope might rename some of the source files though, their namespace is limited to the source directory I'm also less than thrilled with "halscope_rt" as the name of the RT module that does the sampling but fresh out of creative names for that one rt modules are segregated by virtue of rtlib and lib or bin