NOTE: This is from Saturday 9/4, but the conversation continued on Sunday, so here it is: You have HAL to get sorted first. you mean a better selection of drivers? Two things with the HAL code that are an annoyance as opposed to a show stopper... * jmkasunich listens defining HAL data types when standard C types will serve just as well. and the excessive use of _t suffix on everything I see _t, and think "Ah.. A single value" not a struct... Comments ? just a sec while I look something up * jmkasunich has a red face I used _t because of things like time_t... which I mistakenly thought was a struct an annoyance... and not a practice I see in kernel code is there any commonly accepted way to say "this identifier is a structure typedef, not an instance of the structure itself"? because that's what I thought _t did... I used it incorrectly and will fix it but what is the fix? or isn't there one? The fact that you use a struct name as the cast, shows that it is not a single data value read_foo(command* bar) tells me that bar is a pointer to a struct currently I can write a declaration like so: joint_t joint; and I know that joint is an instance of a joint structure if joint becomes the typedef, then the variable needs to be called something else joint is used only within a single function ? depends... most cases, yes and the function is one, perhaps two, pages long ? joint_t joint_array[MAX_AXIS]; might be global joint_t *joint; is usually local to a function globals are bad. period. the data needs to be declared somewhere emcmotStruct, emcmotStatus, etc, are all global pointers OK... On the whole, globals are a bad idea. agreed... a few are needed, like the above, but minimal I suppose I could change joint_t *joint to joint *jointptr or joint *j, depending on how it's used, how long the function is, etc *j would work as long as the function is less than 5 lines.. OK, on the issue of _t, I stand corrected, and will change the code (might take a little while, I'll log it as a bug and assign it to me) jointptr is preferred over j noted although ptr smacks of hungarian notation... joint->position += joint->vel * dT; is better than jointptr->position += jointptr->vel * dt; the -> implies a pointer... right maybe instead of changing joint_t *joint to joint *jointptr, I should change the name of the typdef: joint_struct *joint; NIST style ? I'm not crazy about joint_struct either.... that's why I asked if there was a commonly accepted syntax for "this identifier is a typedef name, not an instance of the type" where is joint struct defined ? motion.h line 457 (and above, that's the last line) joint_model ? actually, I just realized that in the case of joint, the struct name is emcmot_joint, so the _t can be dropped with no problems emc_joint would be shorter and still be unlikely to cause namespace conflicts emcmot is a nist thing, they distinguish between data used by the motion controller and similar but not identical structs in user space OK... re: hal types vs. C types hal.h line 244 those types avoid the driver or module programmer forgetting the volatile, or worrying about actual size in memory also C has no type for bits (unless we use "bool") bool is OK as long as you have C99 when I was but a newbie on this project, I mentioned "bool" and Will said he didn't like it back then, when Will talked, I listened Will also doesn't like dynamic memory allocation, yet he uses C++ and java... as I said, back then I listened.... now however ;-) gotta go for a while, my wife and I are going out to dinner NOTE: This is the beginning of the Sunday meeting (paul_c) Afternoon Steve. (emctest) morning Paul (emctest) Just did an update, configure, clean, make and am getting errors on the make. (paul_c) just waiting for John to join us so that I can continue with bending his lug. (emctest) Is EMC code in a stable state with respect to RC46? (paul_c) As in "Should it compile cleanly" ? (emctest) Steve worries how "bending his lug" translates into merican. (paul_c) you familiar with the term lug ? (paul_c) or lug'ole (emctest) Lug == bolt or stud, OR person without a brain - merican usage (emctest) We refer to the mounting studs for auto wheels as lugs. (paul_c) lug or lughole - English vernacular for ear (emctest) interisting... *paul_c notes emctest could also do with a spell checker on his irc client. (emctest) need more coffee AND a spell checker.. (paul_c) So what errors are you getting with make ? (emctest) First, a "make clean" resulted in "make: [clean] Error 1 (ignored)" immediately after the line "(rm -f include/* lib/* rtlib/* bin/* 2>/dev/null)" (emctest) suspect this does not matter (paul_c) this is with emc2 ? (emctest) yes *paul_c does a cvs up (paul_c) make: [clean] Error 1 (ignored) (paul_c) non-fatal (paul_c) so ignore it.. (paul_c) Ooops... inifile barfs out *paul_c was the last to mess around in there... (emctest) I get same inifile errors (danfalck) Good morning guys. *paul_c is just checking a small correction... (danfalck) So, what's happening this morning? (danfalck) Or this afternoon? (paul_c) minor ballsup on a commit to emc2 (paul_c) nearly there.. (paul_c) compiles cleanly now.. (paul_c) changes committed. (paul_c) Your turn Steve. (emctest) fresh update, clean, make..... all goes well, but I am on the road and cannot test with mill (paul_c) waddya mean - You left the toys at home ! (paul_c) Going to have some more commits over the next few weeks that will probably break stuff... (paul_c) Morning Ray. (danfalck) Hi Ray. (rayh) Hi guys. *paul_c rephrases the last comment... Going to have some more commits over the next few weeks that *will* break stuff... (rayh) What you working on? (paul_c) messing up^^with the interpreter (rayh) Ah. (emctest) So, if I want something EMC2 that runs, stick with current checkout? (rayh) paul_c: What do you think of the get and give functions in rs274ngc_pre.cc (paul_c) can you point me to a line number - Don't have any refs to hand... (rayh) I'm thinking of the big concept. If another executable needs info from the interp it can "get" the info it needs. (paul_c) pass a block of G codes and get back canonical instructions (emctest) Gotta run guys, Paul, thanks for fixup. (paul_c) the interp already handles single blocks (paul_c) catch you later Steve. (paul_c) Or did you have something else in mind Ray ? (rayh) I guess that I was thinking about world modeling. (rayh) 1. interface functions to call to tell the interpreter what to do. (rayh) Tom says, "These all return a status value. (rayh) 2. interface functions to call to get information from the interpreter. (rayh) Messed that up a bit. (rayh) But the idea is that the interface to the interpreter is a pair of functions. Get and Give. (rayh) My thinking is that these functions allow the interpreter to use local variables rather than global. Am I wrong? (paul_c) As I understand it, you pass the interp either a file name or a single block of G/M codes (paul_c) and it spits out canonical commands at the other end and passes an error code back (paul_c) to indicate success or failre (rayh) Right. That is the forward direction. Commanding it to do something. (paul_c) However, there is also an rs274ngc_sync() * paul_c checks the docs... (rayh) Right. We use that as a reset. (paul_c) there is a seperate call for reset (rayh) Okay. (rayh) There are a whole bunch of commands that affect the way that the interpreter works. (rayh) There are a whole bunch of commands that allow other programs to poll the interpreter for info (rayh) rs274ngc_active_g_codes comes to mind as an opposite function. It sends rather than receives. (paul_c) the sync call udates the interp's internal model wrt current tool, feedrate, and a couple of other arams. (rayh) From other programs rs274ngc_active_g_codes will get the current state of the interp. (paul_c) These won't change (paul_c) Evening bytecolor hi paul (rayh) bytecolor: Saw your commit the other day. You're in. great (paul_c) The first commit must now be followed by a ritual (paul_c) of more commits lol I still need to get back up to speed with Doxygen, is't been a year or so since I used it (paul_c) If you do a checkout of the lathe_fork you'll see how I've done the tags for the interp I've been squaring this laptop away, updated the kernel, installed RTLinux ok (paul_c) in src/emc/rs274ngc/ (paul_c) Boy, we need to break rs274ngc_pre.cc in to smaller chunks (paul_c) 12,000 lines is hard work. (paul_c) lathe_fork version is at 10422 lines (paul_c) but that is purely down to reformatting. (paul_c) Sorry Ray - You were heading towards a bigger question... (rayh) There are a bunch of these kinds of give info functions near the end of that pre file. (paul_c) Yes - The public interface (paul_c) (public in the C++ sense) (rayh) I'm wondering if this sort of "ask and ye shall receive" would allow us to use local variables throughout the EMC but at the same time allow for the kind of world model that we run now through global variables. If that is the way it's done. (paul_c) therein lies a small problem... * rayh is all eyes. (paul_c) As I understand the concepts behind the EMC design (paul_c) it is built up in layers (paul_c) from the HMI at the top, down to te servos at the bottom (paul_c) at each layer, the "world view" shrinks to cover smaller amounts of data in a shorter timeframe (paul_c) the upper levels pass commands down to the layer immediately below it (paul_c) and get back status information in return (paul_c) It is on the basis of this status data that the next set of commands are basrd. (rayh) Yep. (rayh) That's what my coffee cup says. (paul_c) At the GUI<=>Task level, the interface is quite clearly defined by the use of NML messages (paul_c) However, at the lower levels (in realtime space) (paul_c) NML doesn't operate (paul_c) so the data tends to accumilate in the shared memory (rayh) It was planned to but doesn't? (rayh) NML that is. (paul_c) NML (in it's present form) can not operate in RT space (paul_c) At the lower levels, the data is much more narrowly defined (paul_c) so we can use conventional C methods to pass "commands" (paul_c) do_this(x, y, z, f) (paul_c) and get back an OK or bogoff response (rayh) The scope of a servo loop is very narrow. I see that. (rayh) There are a set of variables associated with an individual servo loop. (paul_c) meanwhile, much of the data in shared memory is only there to allow debugging & performance testing (paul_c) when it should be in private local arrays (rayh) In addition to the c ommand for postition and feedrate for the delta. (rayh) I agree at one level. (rayh) We set pidff from an ini and they remain global. Do they reside as variables on the shmem? (paul_c) yes... (rayh) What I'm looking at is the tickle widget that allow configuration of a single axis's configuration. (rayh) Unless that tickle widget is active, or a similar one, or an autotune, there is no need for those variables to persist. (paul_c) and there are commands built in that set the pidff gains (rayh) And in fact, I would think that we would lock in the values of those kinds of "parameters." (rayh) Or lock out the set/reset function (rayh) What we are looking at is an HMI <-> servo communication channel. (paul_c) disable when the machine is active ? (rayh) You bet. (rayh) The HMI might want to know what the beep a servo axis is doing or set to. (paul_c) quite a few of the usr<=>RT commands do respond with an error if the machine is on and running (rayh) And it might even suggest changes to the settings. (rayh) True, And I use these as messages on the scratch pad. (rayh) What I'm thinking if the servo loop had a get/give like the interpreter has, we would not need the specific axis settings available all the time. (rayh) A command like get_axis0_p might satisfy the need for a world model. (paul_c) A watchyaDoin command to get fine grained info about the world model... (rayh) You got it! Once the system had been tuned, that command might sit idle for months. (paul_c) Heisenberg would kick in * rayh needs a refresher (paul_c) not with the pidff settings, but certainly with some of the other data that could be passed... (paul_c) http://zebu.uoregon.edu/~imamura/208/jan27/hup.html (rayh) Certainly there will be different intervals of request. * rayh went to school at uoregon (paul_c) A series of low level calls to compliment the existing SET_foo commands are certainly doable (rayh) Down at the servo level itself, it must have all the info it needs for it's work on velocity commands and delta from commanded position.. (rayh) Most of the time, the HMI needs to know little of it. (paul_c) 'cept for fine tuning and diagnostics (rayh) I guess I was thinking of actual position or distance to go as things I'd always like to know at the HMI. (rayh) The tuning set we need to know when we want to do tuning. (paul_c) commanded pos - current pos (rayh) Then there is that damnable list of g and m codes that the interp spits out. (rayh) Yes (rayh) But doesn't commanded update each loop around the motion planner? (paul_c) John's HalScope could provide most of the low level diagnostics such as current v commanded pos (rayh) Yes. Within the HAL I see some evidence of the ability to see these things. (paul_c) and task provides a current pos (within a little) (paul_c) and it knows what the last commanded pos was. (rayh) I see where your thinking about Heisenberg comes in. (paul_c) Task would be updating every 100mSec (for example) (rayh) If we employ a "give/get" model between higher and lower levels, and try to act on that information, from the higher to the lower, we will need some way to account for changes since the last get returned it's info. (paul_c) Whilst I'm messing with the Interp, should I be looking at changing the way current M & G codes are returned ? (rayh) "Right turn clyde" (rayh) I'd hope so. I'd like to see it display the settings of the currently executing line rather than the world model at the read ahead line. (paul_c) "give/get", "command/status" - Both have the same meaning and purpose... (rayh) True if you expand the meaning of status beyond xx or ok. (paul_c) So, current active codes should be comming from Task, not interp. (rayh) Does task know g-code. (paul_c) not as such. (paul_c) all task knows is canonical commands (rayh) I was thinking of a stack of modal info. each row would be a line number. (rayh) The columns would be the world model codes. (rayh) Such a matrix would allow us to back up and restart as well. (paul_c) already ahead of you on that... (rayh) Great. * rayh has a off line committment in a few minutes. (paul_c) When processing a G-code file, fork a sub-process that scans the input for (paul_c) markers identifying jump points and entry points. Use this sub-process to (paul_c) build a linked list of pointers to the entry & jump points for the main (paul_c) interp process to use. (paul_c) A second list could also be generated for points where modal codes are (paul_c) executed - Allowing for the possibility to run at an arbitrary point after a (paul_c) halt/restart. (paul_c) Posted yesterday on emc-dev ;-) ray said "I'd hope so. I'd like to see it display the settings of the currently executing line rather than the world model at the read ahead line." there is a RT skew too the TP queues about 200 commands (rayh) Yes it does. I see that with debug. (rayh) paul_c: How much trouble would it be to build in the pointers for a specific line and the active codes? (paul_c) Not too much work - It just depends on how you wanted to do it, and what you will do with the pointers.. (rayh) It would not have to be different in kind from the current listing. Only it would be changing based on current executing line. (paul_c) Strikes me that we need greater detail in the world model from RT and Task. (rayh) This would simplify backplot and several other parts of HMI. (rayh) At least better focussed detail. (paul_c) I'll tell you what I will do... (paul_c) Concentrate on getting existing plans for G33 completed, spot areas were the lists can be generated (paul_c) and do them later. (paul_c) To build up a huge list of features (aka,. feature creep) will kill it dead (paul_c) if it gets out of hand. (rayh) Great. That way we have the broad outline of an attack. (paul_c) And we have some realistic targets that can be reached. re the world model... how do we decide what info should be public (part of the model) and what should not be... seems right now the philosophy is "when in doubt, make it global" (rayh) What do you think of asking Tom to outline his thinking. (paul_c) Much of Tom's thinking is in the Interp code and his assortment of papers. (rayh) True but he did not extend it into the loops, jumps and such. (rayh) Just said that some changes would have to be made to accomodate those things. (paul_c) probably because there was no clear definition in the "standards" he was using (rayh) WM vs. command/status variables and values should be chosen on the basis of the processor power demanded to accomodate the next levels above the one that we are looking at. (rayh) For example as we do it now, we need position updated each loop of the HMI. (rayh) We do this in tickle by a command to emcsh which asks ?? then returns the value. which position do you need? cartesean position command, cartesean feedback, joint command, joint feedback, etc.... (paul_c) emcsh sends an NML request to task which responds with another NML (rayh) Most of the time I'm asking for xyz. (rayh) I'd also like to see last commanded position right up there as well. from emcsh<->task, it's NML, _not_ global, correct? (paul_c) yup but to service the emcsh request, task needs to get it from RT I think (rayh) Okay. So NML is acting as command/status for us at that level. (paul_c) yup that is shmem, aka "global" unless we switch the tast<->rt interface to a ask/get kind of thing right now task->rt is done by commands but task<-rt is shmem (rayh) Does task->rt act on shmem so that rt sees the change. (paul_c) Yes (paul_c) and increments a counter in shmem (paul_c) so that RT knows a new command is there (rayh) Okay. That's where we get the command numbers from. And perhaps the notion that NML might be able to reach over to rt. task->rt is passed thru shmem, but as a command, like "SET_LINE" for task->rt, I think the user side of the shmem is almost a straightforward mapping of NML messages to motion controller commands usrmotintf.c and taskintf.cc kind of act as a NML to RT translator I think? (rayh) I read some test stuff from NIST on that. there are some limitations tho... I expect that NML in user space can process many, many messages very quickly but the RT command handler will only handle one command per servo cycle (paul_c) emctask.cc does the NML translation, usrmotintf does the grunt of the low level comms and taskintf.cc? (rayh) Oh. One command per cycle. I'm beginning to see the choke point. rayh: right, that's why for task<-rt, task pulls the info more or less directly out of shmem, rather then sending a message asking for it and waiting for a response (rayh) Good. Then we need to consider the range of info that exists on shmem. (paul_c) jmkasunich: Yes, you were correct. (paul_c) memory playing tricks over here. i can only stay shortly today but I have a few things to report * jmkasunich listens 1. I did have to change the name of the registered component from tiro to hal_tiro in order to get it unloaded automatically when emc shuts down * rayh has to drop out. Great stuff guys. Thanks the module name was different from the registered name, so when emc.run tried to unload the module it searched by halcmd show comp and didn't find the module 2. I tried to add hal_tiro to emc.ini as RTMOD6 but I cannot (don't know how) to supply more than one cfg param I think you can just put multiples on one line, but I need to test that if I just write them (e.g. base=300 num_chan=2) inivar discoveres them correctly but in emc.run the return value from inivar is placed inside of "" and the insmod complains that it cannot find the module param "base=300 num_chan=2" hmmm... need to fix that I kept looking for other examples, but all had only one param or it was a string with more values' may have to change how emc.run loads hal modules as for 1. It should be clear to everybody that the hal registered name should be equal to the module name good point 3. just for jmk: I got those graphics for homing I think they are great, just a quick proposal I think it would be a little bit more clear if the home switch is not a point but an interval and inside this interval the zero pulse from the encoder occurs that's about it .... gotta run... I'm out of power I'm not sure I understand... :( I'll mail you about it ok? ok * paul_c grabs a coffee and fag before starting on Hal_Issues pt2 ok (paul_c) 10 mins. * paul_c is back on the _t thing... what do you think of _s to indicate that "this identifier is a struct typedef" joint_s *joint; * paul_c views it with pretty much the same as _t ok (paul_c) joint_status is more descriptive did some searching last night... there are 96 _t identifiers in the emc2 tree (paul_c) eeuww I probably am responsible for somewhat more than half, others are things like size_t and time_t (paul_c) and time_t is what ? man ctime time_t is the thing that led me astray... I think I confused it with struct tm (also in man ctime) and that's why I used _t as I did (paul_c) Well... It is just an annoyance rather than a show stopper. right, we covered that one yesterday next? (paul_c) forcing emcmot to be a subserviant task of HAL some hal drivers (inputs) must run before emcmot, others (outputs) must run after (paul_c) being able to remove driver modules whilst emc is running - Really BAD. how is that different than what we have now? rmmod emcmot (paul_c) having to pass a string at load time for (some) hal modules one issue at a time, please today, somebody can do rmmod steppermod (or whatever the motion module is called) (paul_c) Yes - and it kills emc dead. whereas doing rmmod encoder might lead to servos running away... (paul_c) yes (paul_c) or even worse, it could crash the whole box hal modules should _not_ crash the box when removed, if they do there is a bug that needs fixed everything in hal_lib is designed to cleanly disconnect a module when it is removed the "remove encoder causes runaway" thing is a valid point (paul_c) so what is there to stop a null or invalid pointer from being used as HAL runs down the list of function calls ? mutexes that protect the list from simultaneous modification by two processes, and a list insert/remove algorithm that (I believe) will work correctly even if it is interrupted. I will walk thru the algorithm to make sure (paul_c) So you have a mutex that prevents the function list from being run if an insmod/rmmod is in process ? no I have a mutex that prevents two insmod/rmmods from trying to access the list at the same time the rt code that runs the list is never blocked the code that modifies the list does so in such a way that the rt code will not call an invalid pointer (paul_c) which line(s) I need to double check it the code that runs thru the list is at hal_lib.c:1910 the code that unlinks functions when a module is rmmoded is at hal_lib.c:2382 actually that calls list_remove_entry(), need to look there line 1554 prev->next and next->prev are set to point to the entries before/after the one being removed, _before_ the current one is unlinked if list_remove_entry() is interrupted before "prev->next = entry->next", the rt code will run the list as normal if interrupted after that line, it will skip the entry that is being removed only after that line, when it is known that the entry will not be used by RT code, _then_ other data associated with that entry starts to get erased or invalidated (paul_c) can you be assured that the two lines are run atomically and without interuption ? don't need to the only line that matters is prev->next = entry->next the following line manipulates links that are only used when traversing the list backwards, the RT code doesn't do that even if it did, it wouldn't matter unless a RT interrupt wanted to traverse the list both ways in one interrupt, and needed the list to be exactly the same both times (paul_c) In thread_task() I see two calls that are not RT safe. which ones? (paul_c) the get_time calls rtapt_get_time? that damn well better be thread safe, that function was created for the sole purpose of timing RT code well crap ifdef CONFIG_X86_HAS_TSC it works if not.... (paul_c) Excactly hmmmm.... I see a "whilst"... methinks a Brit put that non-rt compatible call to do_gettimeofday in there ;-) in rtapi.h, referring to rtapi_get_time(): "May be called from init/cleanup code, and from within realtime tasks. " I think rtapi.h need to be altered to also say "depending on the CPU and kernel, this function may always return zero" and the call to the non-threadsafe call in that ifdef should be replaced with "return 0;" better to have non-functional time displays than non-threadsafe code if rtapi_get_time isn't thread safe, then it serves no purpose I just read your email about _t it brings up a more general issue - the reason I have the "joint" struct is so that _all_ information about a joint is in one place a small subset of that is actually "status", things that should be shared with the higher level code having part of a joint's data in a "joint_config" struct, part in a "joint_status" struct, and part in a "joint_internal" or "joint_debug" struct makes it very hard to do object oriented things like "do_homing(&joint_array[n])" (paul_c) I was just putting across some of the reasoning behind the original design. understood and I agree with much of it... I do have a smaller "joint_status" struct that lives in shmem and gets copies of those items in the main joint struct that "should" be shared with higher level code the list of items that should be shared is open to debate I haven't had time to look at the docs you referenced in the second email (paul_c) in usr space, the only data that *is* required is current position on cartesian coords. not entirely true tkemc has buttons that let you display actual or command, and joint or cartesean so it needs at least those four (paul_c) does it ? ( well _if_ you want the gui to display commanded joint position instead of actual cartesean position, it does nope, usr space doesn't know commanded, it only knows the endpoint of the last SET_LINE or SET_CIRCLE command it sent to RT. It has no idea where the TP is in the RT queue, nor whether it is at the end of a certain LINE command or somewhere in the middle (paul_c) aside from diagnostics and a few limited applications, cartesian is all that *is* needed. then talk to Ray about those buttons on the GUI (paul_c) side issue. right - as I said, exactly what is "status" is open to discussion (paul_c) Re: HAL getting back to the "rmmod encoder" issue that is bad... (paul_c) Three things that I find disturbing about the general implimentation of HAL. (paul_c) That modules can be loaded/unloaded at any time (paul_c) that emcmot is subservient to HAL (paul_c) and the whole system can be reconfigured on the fly whilst the motion is running #2 first... that is a side effect of the need to run some drivers before and some after the emcmot core code (paul_c) so get the emc core to call the function list then you can't use the drivers without the core.... I consider the ability to connect siggen to stepgen and make motors turn far more than a gimmick, it's a way to test things and isolate problems (paul_c) that is just a smoke screen... (paul_c) You can still "connect" modules if you need to. how? (paul_c) run your hal core module when you need to test them.. (paul_c) Having looked at the "annoyances" and the "disturbing" (paul_c) the show stoppers. we haven't even begun to discuss this last one ok, show stoppers (paul_c) WTF can't I connect a bit to an int or whatever *I* want to. (paul_c) WTH MUST I give the parport driver a string before it loads. (paul_c) and why the hell do I need all that extra cruft in the ini files. (paul_c) Way too many hoops to jump through just to get a simple system running. 1) typing... I've already said I'm willing to implement typeless signals that would let you connect anything to anything at your own risk (paul_c) yes. I strongly believe that typechecking is a good thing and am not going to make the default be no typechecking typeless signals let you do it your way and I do it mine (typeless signals would be an addition to the typed ones, not a replacement) (paul_c) just a sop imo well yes... I think I'm right, you're unhappy, I'm trying to meet your objections #2 - parport string (or is there more to discuss on #1?) (paul_c) no the parport driver must know how many ports it must support and whether they are input or output at insmod time, so that it can allocate shmem and create pins, signals, etc it doesn't really need to know the addresses, but you'd have to tell it the address sooner or later, and insmod seems like the best time, where it can be combined with other info that is needed at insmod time (paul_c) so give it some defaults what port? (paul_c) or use the kernel to find out what ports are available the kernel doesn't know which ones are running motors and which ones are running printers (paul_c) nor would any parport driver (in the emc world) the user knows, and AFIAK, in emc1 he puts it in the ini file IO_BASE_ADDRESS (paul_c) and if EMC doesn't get passed a base address, it defaults to (currently) 0x278 and that is preferred, even tho you don't actually know what's at 0x278? (paul_c) there will either be a parport at 0x278, or there won't be anyting - Unless you have some *very* non-standard hardware. very well, the default for parport can be one port, output, at 0x278 (paul_c) assuming x86 hardware of course. on to #3? (paul_c) yes - That... "and why the hell do I need all that extra cruft in the ini files." (paul_c) That is what I said. the upside - hal is much more configurable (at runtime, without linking or modifying the makfile)... the downside, hal is more configurable, and you have to specify the configuration you want I'm not fond of the way it is right now (RTMODn, USRMODn, etc) but that's the best I could come up with at the time (paul_c) right... (paul_c) It is far from being simple and easy to use. is your gripe with the specifics of RTMOD, etc, or just the increase in config info in general? (paul_c) No, that is only part of the whole configuration process. simple and easy to use compared to what? On saturday you responded to a guy who wanted to swap Z and A pins telling him to mess with a series of left shift instructions around line 4000 of emcmot.c. Is that simple and easy? (paul_c) No it wasn't - But EMC is a bloody mess when it comes to that side of things no matter what the mechanism, if things like pinswapping are to be done without recompiling, then the info about what pins are used for which signals _must_ be in a config file somewhere.... (paul_c) It would have been far simpler if it was a case of giving an INDEX number for each step & dir signal. that gives you _some_ more flexibility... enough to let the guy swap A and Z certainly hal gives you more flexibility, you could put Z on another port if you want.... perhaps that's too much flexibility (paul_c) too much flexability leads to a whole new mess of user problems (paul_c) I sure as hell don't want to be spending my time trying to sort out someone else's problems with a miss-configured HAL IMO, limiting people's flexibility isn't the right way to go about it... I'd rather give them an infinitely flexible system with a good default configuration. (paul_c) and when they mess up the file ? copy from known good and try again side issue - IMHO the run script should not use emc.ini by default... they should copy emc.ini to mymachine.ini and have at it, running mymachine.ini and keeping the original untouched (paul_c) Doesn't always work like that. and speaking of cruft in the ini, why the heck are the simulated servo parameters in ini files used by folks with stepper machines? (paul_c) That should have been deleted a long while ago. at least we agree about something ;-) (paul_c) Right - Now can I bung some general thoughts your way... sure but first, to summarize issue 1: I will add typeless signals (should do a tracker item to keep me honest) issue 2: default for parport, 1 port, 0x278, input issue 3: no real resolution, but we both agree that the present way of managing hal config is bad (paul_c) drivers are loaded in the order they are listed in the ini file - and if any additional params are on the same line(s), these get passed on that would be nice, but the existing ini file reader won't do that (or I don't know how to use it)... AFAIK, the ini file reader knows nothing about ordering, it looks for keyword/value pairs I would _love_ to be able to do things in the order in which the lines are found * paul_c has done some work on that for libnml (paul_c) the IniFile class is prett small and can be quite easily expanded. good...give me a way to read ini file lines in order, and I'll get rid of RTMODn - I hated that when I did it, just couldn't think of anything better (paul_c) At the moment, you can pass IniFile::array_fill() a pointer to a dynamically allocated array (paul_c) we can extend taht to take a section and entry tag and a max line parameter * jmkasunich suddenly realizes we aren't talking about the same thing (paul_c) Once you have your list, you can do what ever you like (paul_c) extend inivar to find a section/entry pair (paul_c) then keep asking it for next line, next line.. the RTMODn cruft is in the emc.run bash script and calls a the program "inivar" we need to change the actual program inivar, not just the C++ class or make another program ("inilines"?) that does this new stuff anyway, that's details to be worked out... let's continue (paul_c) or convert the bash script to C/C++ you mean emc.run? that's a thought.... might (would) be diffcult (paul_c) right - Back to ideas... (paul_c) when a module is loaded, it registers it IO with emcmot, not par.pin.foo_whatever (paul_c) just 8 bits of output, and sixteen inputs or whatever, might be 12 and 5 (paul_c) The numbers are not important just making the point that they are not multiples of 8 (paul_c) you might have 1 bit out and 197 in right (paul_c) There are cards out there that have massive amounts of IO (paul_c) 24 and 48 are common place (paul_c) I have one here that does 72 pins (paul_c) and another that has options for 256 ok, I get your point... and most of those will indeed be x8, but parports are not, so we need to deal with that (paul_c) What I'm trying to get across is the volume of IO that *could* be installed. (paul_c) that has a direct impact on the size of your memory usage yes, because I keep the pin names in memory, instead of using an index tradeoff... how does the user know what physical pin matches what index? HAL embedds that knowledge in the driver, and from there into the pin names, using index along would force the user to refer to the card docs I would not use pin names like "digio.0.pin-120-out" more like "digio.0.tb1-pin4-out (paul_c) credit the user with the ability to read the docs that came with his card one minute you complain about clueless users altering config files and getting confused, the next you want them to understand pin/register mapping on a servo to go card? (paul_c) If the user is wiring up his control to a port, he _will_ know what pins relate to physical connectors I could use the same arguement to say if he's "wiring" up things inside the HAL, he will know what he's doing especially with parports, where a couple bits are inverted, and the control and status ports don't map to contiguous physical pins, why should he be expected to know that... hiding things like that is what drivers were invented for (paul_c) was going to get to that bit later on... I still think "digio.0.tb3-pin2-out" is better than "port 0x349 index 3" * jmkasunich shuts up (for a moment anyway) (paul_c) When the IO is registered, it is mapped to INDEX bits from 0 to 199 (or whatever)? (paul_c) any IO pin that does inversion internally gets converted so that there is a direct corrolation of POLARITY and input (or output) (paul_c) When the user configures the ini file, STEP_INDEX and DIR_INDEX get a simple number beside them (paul_c) and optionally a POLARITY (paul_c) Same system for analogue IO and encoder inputs - simulated or real. (paul_c) Note - No halcmd foo involved - clean and simple if you have both an stg and a parport, stg gets indexes 0-47 and parport gets 48-64? (paul_c) yes (paul_c) if the stg is loaded first so the mapping between indexes and physical pins depends not only on the driver itself, but also what other drivers are loaded and in what order the user will definitely need a personalized list mapping indexes to physical pins (paul_c) The alternative would be to pad out the 5 bit ports... that only helps a little then parport is 48-71, and some indexes go nowhere also, some indexes are input, some are output do you bother checking to see that they are actually sending step and dir to outputs? (paul_c) we may have missed a small point... separate indexes for in and out? (paul_c) INPUTS 0-5 and OUTPUTS 0-12 and the stg, where each is configurable? (paul_c) the STG isn't that configureable... if you change one stg port (group of eight) from in to out, the index<->pin mapping for the parport changes (paul_c) If the user has an STG card or any other non-parport IO card, he(or she) ain't going to be your average fukwit ability has nothing to do with it stg has 48 IO, right? suppose he initially sets them up as 24 and 24 uses about half of each then wants to add a toolchanger, so changes one port from in to out (or vice-versa) that will change the index<->pin mappings of multiple pins both on the stg and on any other drivers loaded after the stg result, he has to change multiple lines in the ini file that are totally unrelated to the toolchanger that he's trying to add (paul_c) assuming that he has multiple IO cards, and the STG driver is the first in the list right... both valid assumptions if you're allowing flexibility emc1 only allows one I/O device, and the motion module is linked to that driver... if we wanted to keep that "one device" limit and simply allow the ability to swap pins, I agree that HAL is overkill but I don't want to keep the one card limit (paul_c) Nor do I (paul_c) But I want a system that is easy to use then you should be able to load different drivers and change the list of drivers you load without needing to change I/O routings (INDEX) for boards you haven't changed if you load A, then B, then C, and the indexes are all set up, changing the size of A, or the in/out selection, or simply deleting A, will change the mappings of all IO on B and C as well and force you to go thru the ini fixing things (paul_c) and if you change a driver in the HAL model ? (paul_c) e.g. replace parport with PCI272 that driver's hal pins disappear or change names, and the IO routed thru _that one driver_ needs to be reconfiged, all other IO is unaffected (paul_c) you still have to piss about editing a file well you did change the driver, you didn't expect it to be totally transparent did you? my problem with the index method is that it affects drivers that weren't changed (paul_c) what are the most common set ups ? numerically? probably sw step/dir out a single parport aka sherline (paul_c) and how many STG setups ? really don't know (paul_c) not that many. face it - the bulk of the users neither want nor need to change anything, and no matter how complex the config is, if the program ships with a config file that makes it work just like emc1, they're happy (paul_c) so, with the few STG installs and the large number of single parport systems, how many are going to be chopping and changing ? but those who _do_ need to change things, every one of them is gonna want to do different things (Imperator_) Stupid question: what is the advantage of indexing the IOs ?? I think the way they are named at the moment is very good. You can see easyly where the Io's are located (parport ore special card,..) (paul_c) simplicity is the key flexibility is the key and there is the heart of our disagreement (Imperator_) is that realy simple, if you do not know where the Io Pin is at the moment ? (Imperator_) both is reqired (Imperator_) simplicity and flexibility (Imperator_) I think for standard users with one parport or one STG card someone can write setups, and that users don't have to think about that (paul_c) Moving inward to the code for a bit.. (paul_c) having written several EMC drivers (paul_c) and being presented with all that string handling to declare a set of io pins... (paul_c) My initial reaction was - This sucks (paul_c) Short simple names for pin designations - Not something that is prone to typos how short? example? (paul_c) port.3.in6 (paul_c) Spot the mistake ? (Imperator_) parport.3.in6 is better (paul_c) not if it should have been port.3.in.6 (Imperator_) then you know where you will find the pin that comes down to two things: 1) consistent naming conventions across drivers and 2) when you do it wrong, you will get an error message and can fix it... just like typos in source code and compiler messages (paul_c) right - But keep the bloody names short and simple I feel strongly that names should identify the physical pin - the user has no need to know things like bytes and bits that's why the word "pin" appears in many names (paul_c) Like the mapping of parport pins to a DB25 connector ? right the pin numbers exported by hal_parport are the DB25 pin numbers (paul_c) and if the cable has a centronics plug on the end ? then the names will be wrong (paul_c) or you might have a ppc box with a DB37 for parport? (paul_c) yes I'd be willing to modify the driver to export pin names that match the connector (but it would have to know at insmod time which connecter you have) the alternative is that _nobody_ will have correct pin names unless they refer to paper documents (paul_c) Don't assume that everyone uses x86 and all parports map to DB25 connectors I'm not the first to make that assumption - there is a DB-25 pinout in the handbook, and if you took it out people would scream (paul_c) The final HAL implimentation issue (paul_c) Way too much use of shared memory and mutex (paul_c) Had some Debian developers comment on the code... (paul_c) the general reaction was one of shock and horror. care to be a little more specific? (paul_c) is shared memory and mutex locks not specific enough ? no (paul_c) any mutex that is used by both kernel and usr space is a really bad idea because? (paul_c) what happens when kernel space preempts usr space whilst the latter holds a lock ? the mutexes are in init_module and cleanup_module, not in true "kernel" code (paul_c) init and cleanup is kernel space init and cleanup can call "schedule()" with impunity (paul_c) suggestion: write a small usr space app that holds a mutex, run it, and see what happens when you try to insmod a module that expects to use the same mutex the insmod will hang until the usr module returns the mutex but it will not hang the machine, the kernel will continue to schedule other tasks, including user processes, and eventually including the one holding the mutex (paul_c) which it can't do because usr space can not run until kernel space finishes wrong - the mutex in init_module calls either schedule() or sched_yield() (one is user, one kernel, don't recall which is which) been there, done that, tested it (paul_c) Are you absolutely sure ? I did have problems when the user space code segfaulted while holding the mutex ;-) but I intentionally made a user prog hold the mutex for 10 seconds, and did an insmod while it was holding the insmod hung until the 10 seconds expired then ran to completion normally (paul_c) OK. a half point to you on that. if the debian developers had specific issues, I'd love to hear about them, and address them one way or another but "shock and horror" doesn't help (paul_c) I will have to pin them down again for half an hour. (paul_c) You can not assume that all kernels on all hardware will respond in the same way. the mutex implementation is based on the LDD book... the behavior of schedule() is well defined (paul_c) That covers most of it. (paul_c) Note: Not a single mention about thread creation or run order. (paul_c) That is a really mad idea. the goal was to allow loadtime/runtime configuration instead of linktime if you disagree about the goal, then you're not gonna like the methods used to achieve it it's clear that you'd rather have emcmot call drivers (paul_c) allow the driver to "register" with emc, certainly. (paul_c) but not config stuff. allow emcmot to call the registered drivers if and when it needs the things they supply? (paul_c) Yes. that works if and only if you want a single layer - emcmot calls hardware driver (paul_c) read data -> process data -> decision -> write data [sleep] (paul_c) hardware calls only occur at the lowest level. run input drivers -> run emcmot -> run output drivers -> sleep what about step generation? below emcmot proper, above the hardware driver (paul_c) seperate and independant task. how implemented? separate loadable module? called by who? does it in turn call output drivers? (paul_c) so where does "run input drivers -> run emcmot -> run output drivers -> sleep" differ ? (paul_c) no mention of stepper drives there ? run input drivers -> run emcmot -> run stepgen -> run output drivers -> sleep depending on you're point of view, stepgen is an output device (paul_c) so you would run stepgen at the same speed as emcmot ? stepgen has three functions, two run at the servo rate, one runs at PERIOD (paul_c) lemme see if I get that... (paul_c) One realtime task running at PERIOD and two function calls that run when emcmot calls them ? big picture: two realtime tasks, one at PERIOD, one at SERVO_PERIOD PERIOD: run parport input driver ; run stepgen step pulse maker ; run parport output driver SERVO PERIOD: run stepgen position feedback capture ; run emcmot ; run stepgen frequency command output stepgen position capture is equivalent to reading encoders frequency output is equivalent to writing dacs the pulse maker looks at the "DAC" value and generates pulses at that rate (paul_c) At no point does the order of the function calls change. (paul_c) Read->process->output right, but "read" can be read from stg encoder counters, read from sw encoder counters, read "fake" encoder counts from step generator, etc likewise output can be to stg dac, stepgen, etc (paul_c) matters not, how many functions are called from assorted drivers what I'm getting at is the idea of calling a single function per driver, after emcmot is all done, vs calling an ext function per output port, multiple times as emcmot runs (paul_c) where did I mention multiple ext function type reads (or writes) ? if STEPX is at INDEX1 and STEPY is at INDEX2, I don't want to make two calls that read the port, and/or the appropriate bits in and write back to the port we may not be communicating well if emcmot calls drivers, I assume it would call once to write STEPX, once for STEPY, etc, based on reading the INDEX vars (paul_c) I have to go and feed the wrinkly OK (paul_c) While I'm gone, ponder this one... (paul_c) I haven't said anything about data types in a simple hal model. (Imperator_) Another thing, there was a discussion about safety. Special about not unloading drivers while the machine is running. Was there a solution ??? no - so far that's the strongest issue (Imperator_) I had the idea that for every driver that is loaded HAL creates a softwarewatchdog, and the driver has to trigger these watchdog. Then the machine goes to estop if the driver is unloaded or if the driver has crached. I think that is also good for other parts of EMC for example to be sure that the GUI is still alive (Imperator_) for the drivers that watchdog can be implementated in the hal_lib for the log (since paul is gone) HAL as it is exists, and is GPL... anyone who wishes can use as little or much of it as they wish There are specific problems with it, which I will address as bugs and try to find a workaround the general philosophy of HAL is what I thought was best I might be wrong, but so far I'm not convinced that the basic philosophy is flawed if there is a general concensus that the philosophy is not appropriate, that's fine - any or all parts can be hacked, chopped, or re-used, or for that matter discarded completely but in the meantime, I'm not gonna do work that deviates from the philosophy of complete modularity and flexibility end rant there, got that off my chest (Imperator_) I think HAL is a very good idea, john i second that (Imperator_) ok it is not so easy to use well.. not yet that is Paul's complaint... some items are "bugs" and can be corrected without changing everything without a gui (at least for gui people) others are differences in attitude or opinion, and Paul and I are both very stubborn when we think we're right (Imperator_) but for standard users there must be a brain dead install with a menu at the beginning, asking questions like : steppers ? parport ? limit switches ? btw. there was another thing I just remembered I've been looking through emc.ini and I think values for the 3 axes should be corrected (PID values, etc) I know no one uses emc2 yet... but the day shall come Imperator_: good idea... my plan all along was that emc2 would ship with multiple ini files... for some of the common configurations menus could select from the predefined configs, and perhaps make modifications to them alex_joni: do you mean removing unused values?> jmk: maybe we could put up a webpage for users to submit theyr configs I mean putting in sensible ones Axis 0 has all 0 values for PID well, that touches on another thing Paul doesn't like... in emc1, PID is build into emcmot and it can't get easily replaced about those graphics for homing... do you have time now? or should I mail you about it Imperator_: any luck with those boards? re: graphics... I made some mods last night to show the switch on and off points separated (hystersis) the latest drawing is at http://www.linuxcnc.org/EMC2_Code_Notes.pdf well.. what I think would make the graphics more clear is not to represent the home limit switch as a point in the graphic but rather as a signal low when not tripped, and high when tripped like this it can be shown that there is no single impulse from the home switch like from a zero pulse from an encoder let me take a peek I think I know what you mean (ascii art alert): :)) i love ascii art ___________________ __________/___/ where the two / are the turn on and off points? lining up with the lines/dots on the existing drawing? more like this: ___________ _____________| |_____________ Home switch | | | | Zero encoder impulse but the switch doesn't neccessarily turn off after one turn of the screw, in fact most do not if the switch doesn't turn off, then you can home from either side of it well then maybe more but if it turns off, then attempting to home when you are already past the switch will just run you further to the right and into the limie all I wanted to point out is that the home switch should be tripped when the zero pulse comes not always though at least this is the way it is done at robots ;) the zero pulse is the main homing thing inside a rotation the case where search_vel is positive and latch_vel is negative, the index pulse that is captured is where the switch is not tripped and the home limit switch is just to specify which motor rotation it is i know that this homing is more general ;) do your robots allow a complete rotation? such that they can start moving in one direction and be sure they will hit the switch no matter where they start? (Imperator_) alex_joni: I'm still writing the driver. At the moment the weather in germany is to good to sit on a computer. The summer was so bad here. I must use every day the sun is shining to go out these robots we talk about are a few years old before the 90's so ... ;) but anyways... at homing they start moving in one direction and after a while they change the direction if the home signal doesn't come or maybe they hit the limit switch usually they do go in the right direction (I did wonder how they know... I still wonder ,) maybe they remember where they were the last time? don't think so to dumb for that ;) (Imperator_) i had the same thing with a adept robot (Imperator_) the thing was the position was behind the limit switch, then it searches for the switch, and was driving against the wires which where drilled in the axis tying itself in knots? ;=_ ;-) :)) fishing knots particularly bad if trailing welding cables like I said... this is for very old robots newer ones don't have a home limit switch instead they remember which motor rotation they were in (Imperator_) or they have absolute encoders jmk: I don't think robots can tie knots in welding cables welding cables can stall robots, eh? welding cables tend to be thick ;) yes... we use thick cables in our lab at work 600-1200A at 480V three phase nice ;) you see how I doubt that a robot with 10-15 kg payload can take such a cable a knot it any chance of looking into that emc.ini issue? with more than one CFG param? oops, almost forgot about that btw. almost forgot there is a small typo in encoder.c and was in my file too MODULE_PARAM and MODULE_PARAM_DESC? are not consistent I'm remembering things ... so don't be too harsh ;) I see... DESC says cfg, should be num_chan thanks yes fixed so I remembered correctly I'm not sure, but check the other components on this one think I saw another one too... :-? but I could be wrong btw. I found the perfect (4 me at least) software for CAM sheetcam for now it's free, as it is not a final release yep, three other components with the same mistake fixed and committed I _like_ easy ones! btw alex, feel free to make fixes like that yourself and commit them I would like too... but right now I'm on another laptop (not mine ;) no cvs here no linux just boring windows ;) bummer yep I couldn't remember the pass for my ISP... didn't use in a while so I took my dad's laptop, he has it stored ;) anyways.. I was planing this week to start commiting to emc, emc2 great! haven't used cvs much, so I gotta figure things out... I know it should be a lot easier than I expect but I kept posponing it :( once you do the initial checkout (that long command line) and login it's usually just 'cvs up' or 'cvs commit -m "added some great new code" ' no need to log in to sourceforge (except maybe the first time) cvs commit -m "" filename ? it looks in the current dir (and subdirs) for modified files, and commits anything you've changed i see but the comment doesn't get into the file.. right? not in the file, but in the commit email I see can you read your email from that computer? sure webmail the commit message from the change I just made should be there, you can see the comment should be... and my net connection should be quicker :(( modem? yes :( I'm not used to this anymore been on a WLAN connection at work... dsl here 384K finally got to read the commit coment ;) I have around 400 kB at work that's 5000 kbit. only 100 times faster than now :(( nice * jmkasunich has been staring at the computer for over 5 hours need to get a life ;-) well.. here it's also past midnight guess I'll call it a short day goodnight thanks... bye everybody LOG GAP (paul_c) no. (paul_c) nor Jon paul_c: re extintf, there would have still been issues with getting drivers to run in the proper order (paul_c) There is only one order the things can run in hindsight, it would have been better if "hook emcmot to HAL" and "clean up and rewrite emcmot" were two distinct projects (paul_c) Yes. (paul_c) I could do testing with the drivers I have now. but which first? (paul_c) emcmot re-work is a "now" project yes, they both got combined, and we're in the thick of it right now (paul_c) to the detriment of both camps... I don't think it's that bad (paul_c) I want to get stuck in on threading in emc2 ( that means coming to grips with tp.c and tc.c, neither of which has been touched what hardware? (paul_c) a mix of kaluga, vital, stg, vigilant (x2) and some other stuff in the wings. all on one machine!? ;-) (paul_c) not all at once. lol Scuse the butt in. I thought a hal hardware driver was nothing more than a bunch of pins to which you could hook signals. (paul_c) but certainly a mix of one encoder board and stepgen one goal of the extreme (anal if you wish) drive for modularity is so that if threading works with one card, it works with all stg uses a LS7166, doesn't it? (paul_c) yes alex's "tiro" driver would probably work with minimal mods he's talking about committing it this week that brings me to a "boardish" issue (but we can discuss it here) the board is supposed to set priorities... should I start working on drivers? (stg first, I printed docs friday) (paul_c) The index pulses need some funky setting up * rayh runs for his flack jacket followed by jon's usc board, because I have one (I think matt has offered the loan of an stg for driver development) (paul_c) can you get Vigilant cards ? I've got a vital. I have a USC only, beyond that I need to buy or borrow This brings me to a question regarding priorities. Sure we need drivers in order to test the code on hardware but are "we" responsible to build a driver for any old card that someone comes up with. I hope that hal drivers are relatively straightforward to write - both alex joni and martin (imperator) have made drivers for hardware they have I want to write some guidelines (paul_c) We need to have a set of "core" drivers yes, I expect to do stg and usc myself for sure others if available for testing, or if somebody will work with me for testing and I will help folks who want to do their own, like for jon's pwm amp IMO in a perfect world, the guy making the money from the hardware should provide the drivers to run that board. and for new hw that is probably what will happen but for stuff that emc1 already supports, we kinda have to catch up to where we were I hope that we don't fall into the same compile everything trap that we did with EMC. (paul_c) With autotools, we can get round that I'd like to be able to compile only for a board set that I want to run it on and not worry whether some other driver is going to trash my compile. (paul_c) although a basic set would get compiled, and any extras can be selected on the command line (paul_c) maybe something along the lines of: (paul_c) configure --build-all (paul_c) or: (paul_c) configure --build-vital --build-stg For a BDI, you'd need to build a wide range but that should be different from an individual compile. That sounds about like what I'm thinking. (paul_c) Oh, emc2 won't be going into a BDI for some time yet... --build comedi It will someday. (paul_c) IF these issues can be resolved, true. I've got confidence that it will make it's way to a release. if emc2 (all of it) doesn't compile cleanly on a BDI, that is a high priority bug we may never be able to support a combination of arbitrary Linux distro and arbitrary rtos, but we damn well better support the combination we ship on the bdi But I still think that there is a separation between the running code and the driver for a specific hardware platform. (paul_c) and who do you think will be doing most of the support on the front line ? I'd like to see the manufacturer bear a part of the burden. I've no doubt but that John and Paul will write the bulk of the code for these things. At least for a bit. But a maker like JonE is trying. So is Abdul at vital. comes back to the compile farm... once manufacturers start committing drivers to the cvs codebase, they should compile on all BDIs, or the manuf should fix them if they want to supply drivers seperately, that's different Seems to me that it is a bit unfair to expect us to write stg and abdul vital -- if you catch my drift. (paul_c) Whilst Jon's ppmc may compile now, it doesn't load on a BDI-2.xx box Right and that is a reflection of the issue that I've got here. Who do we blame for that when someone begins to whine on list? * paul_c points the finger at Jon * rayh points another finger into the air when I can't compile! my thoughts on hal drivers... I will have to write the first few, those in turn will serve as templates for others... eventually I hope to simply help (comments, suggestions) the manufacturers write their own drivers exactly which drivers are the "first few" is determined more by what I have on hand, rather than anything logical That is probably the best position to take here. We do have to provide first for our own testing and machines. Beyond that initial testing, we need to pull in the makers. To do that we will need the spec and samples. I'm adding some drivers to the feature request trackers, assigning them to me (at least for now) and putting the priority fairly high - I think it's time do that At that point, it has to become a makers job to confirm that their drivers work as promised. It can't continue to be the communities task forever. * rayh gotta run. Fun as always. (paul_c) continue down the path of modularising everything with a damned ugly config and it won't get anywhere near a BDI release.