have tried to install the new BDI on my P1 system
but the kernel is compiles for P2 and newer systems :-(
well, maybe paul_c will add a 586 kernel
my development system is a P1 it runs fine and if i burn it because of a wrong soldered ISA or PCI Card it's no problem, i have some boards more
you can test the board first in the P1 then move it to the final EMC-PC
build a simple non-rt app
jep, but i don't want to have so much computers in my room
I got the probe fitted to the mill now, and the plc program written..
does it work?
the only thing thats left is to write the part to talk to the plc..
and send the message to emc
not that hard... ;)
I just installed the box like 20 minutes ago
going to leave for a lan in a bit..
going to take the box with me and write the program :)
I am not that happy with the installation of the sensor, really but I'll re-do it. and mill myself a slotted disk and turn it so I wont get imbalance..
I'll be back in a bit..
EMC EMC is CNC software that takes Gcode and carves metal blocks into nuclear bomb parts or small carvings of Tux depending on your inclinations.
um any one here?
[19:27:51] <gezr> http://www.cadcam.co.at/freiter/gCAD3D.htm
what is that?
well its interesting at the least
I looked at version 0.77 sometime ago.
all this cad/cam stuff is huge
have I made a big enough mess outa things yet? :)
just logged in, gotta catch up on emails and do a cvs up
k. I think I'll be here a while...
* jmkasunich is caught up
well, partially caught up ;-)
my make failed... the fresh checkout doesn't have a /rtlib directory, and apparently the makefiles don't create it
hmm... that's ... very odd? I don't think I played there... At least not on purpose :)
I wonder how long that bug has been there - it only shows up with a fresh checkout
I doubt it was you
hmmm, bin, lib, rtlib, include - none of those directories was created
Hmm... you did make at in src, right?
argh... I mean... you did make in src, right?
(I checked out a fresh copy when I started and didn't run into that...)
I did the "standard" emc2 make - cvs checkout, then run ./configure and Make in the top level directory
are you maybe out of disk space?
nope, 3G free
the directory names in Makefile.inc are correct
but the directorys themselves don't exist
blimey no paul?
delrin 6.35mm hole, 10mm hole = solidish coupling?
hmm... went back into my regular EMC2 tree, deleted the contents of the include directory, deleted the directory, and the same thing happens - make fails to create the dir
wow... I haven't run into that, and I bet I've done pretty much the same process you're doing...
running "make headers" with no include directory results in each header being copied to the file "include", so after it's done, the "include" contains the final header
and of course the make crashes
zwisk: do "make clean", followed by "cvs up -dP" and see if you have an include directory afterwords
hmm... I'm almost afraid to... mine works :)
it's easily fixable if the directory disappears...
I think I know what happened
nope... no include directory ... (Was I supposed to do ./configure and make? )
it was the "cvs up -dP" that did it
hmm... ok. So what's the fix?
short term fix: mkdir include, mkdir bin, etc
but I'm gonna add code to the makefile that will make the dirs if they don't exist
-dP says "make any new directories that are needed (-d) and prune empty directories (-P)"
after the initial checkout, you have empty dirs from CVS
if you run a make, they get files in them, and aren't pruned by later cvs updates
in my case, I did the checkout, but no make yesterday
today I did an update to get the latest, that removed the empty dirs
I see.. so what's the best way to get your directories back now?
just to mkdir include, etc
just _do_ mkdir include
emc wouldnt run on my box..
it loads ok with the generic config..
although when I run emc.run it locks up
sorry anonimasu, I think I'm not much help to you there...
03jmkasunich 07halrefactor-0-1 * 10emc2/Makefile: fixed makefile so it will create include, bin, lib, and rtlib directories if needed
zwisk - do a "make clean", then "cvs up -dP", then try make - it should now recreate the missing directories
in which branch?
yup... seems happy..
03jmkasunich * 10emc2/Makefile: fixed makefile so it will create include, bin, lib, and rtlib directories if needed
applied the fix to the trunk as well - it will be a while before we merge the hal refactor stuff
the make in the branch still failed while compiling hal_lib, right?
that was to be expected I think
erm... shouldn't have... I've been trying to checkin only compileable things...
what error did you get?
In file included from hal_lib.c:70:
/usr/src/linux/include/linux/malloc.h:4: warning: #warning linux/malloc.h is deprecated, use linux/slab.h instead.
that's just a warning, right?
followed by a couple more warnings from hal_procfs.h
(I don't think I added that...)
yes... hal_procfs was unclean I think.
but it did make hal_lib.o, right?
I know that we're gonna break things pretty good before we fix them
doh... shoulda.. What was the fatal error?
In file included from hal_lib.c:46:
hal_procfs.c:19: `hal_data' undeclared (first use in this function)
In file included from hal_lib.c:92:
hal_priv.h:286: `hal_data' used prior to declaration
oh nuts... yeah... That's a mistake on my part. I'm about ready to checkin another that will fix that.
(maybe 5-10 minutes)
a terminology issue... I used "component" instead of "module" to avoid confusion with generic kernel modules (especially since user space components are _not_ kernel modules)
should hal_module_info be called hal_comp_info?
yeah... I'm grappling with how to deal with that, as much of the kernel stuff will be kernel modules...
I'm not sure... we should definitely continue our terminology discussion and then do a great big search and replace to get everything consistent when we get it all worked out.
I want to get the terminology straight as soon as possible tho, to avoid confusion
to date, we have "component" or "module" for a thing which can contain one or more types of blocks
and "block" for an instance of a block
I think I've also confused "component" and "block" on a few occasions. A component reminds me in EE terms of a specific instance of a chip on a board... I place components on the board...
agreed... now that we have the idea of more than one possible "thing" inside a single module, "component" seems a better fit to the thing, not the wrapper
if anything, "library" would be a good word for the module that makes multiple blocks available... but library already has meaning in programming
I hate overloading terms
we have things which you can "place", and we have larger things that can contain several different varieties of the former
and I don't know what to call either one of those things
yeah... I sort of start thinking about device families somewhere in there... but that doesn't seem to make sense.
there is no physical analogy for something that makes several types of components available
but there is an electronic CAD analogy - a component library
hmm.. definitely the cad analogy makes sense.
loading a library makes all the parts in it available
well, there are 'portfolios' of chips, 'families' of chips, 'brands' of chips, 'product groups', ... hmm... just braind storming...
brainstorming is good
what about "part" for the instances themselves (instead of block)
a "part" is an instance of a "part type", which is made available by a "???" that may be either a user space program or a kernel module
hmm... perhaps. Have I seen 'part' refer to a type a chip rather than a specific one though?
I think of R1, C23, U5, etc as "parts"
I think digikey and many other vendors have 'part selection guides' which help you find the chip within a spefic family that you want to use... Then you also order parts... hmmm... I dunno...
is "1K 1/4W" or "74LS04" a part or a part type?
it can be both
yeah... I'm afraid it can be both. There may not be a perfect solution...
if a bill of materials calls out qty 3 of 1K, and qty 4 of LS04, then there are 7 "parts" on the board
but you have to order two different kinds of parts
or are there 7 components? I guess part placement machines place individual parts...
the CAD package we use at work (PowerLogic/PowerPCB) calls the individual things "parts" and the different kinds "part types"
"1K 1/2W" is a parttype
R12 is a part
what are you discusssing?
refactoring of some of the HAL code
HAL is based on a component analogy, that is much like designing electronic hardware by placing and interconnecting integrated circuits
I could be ok with "part" and "parttype"...
* jmkasunich tries to remember what Orcad used for terminology
both Orcad and PowerLogic refer to collections of parttypes as "libraries", but that's a word with a very distinct meaning already for programmers
hmmm... we can always prepend things...
"hallibrary" or "partlibrary"
I could live with either "part" and "parttype" or "block" and "blocktype"
not hallibrary tho... sounds like halliburton
I could live with "module" as the thing that makes one or more parttypes/blocktypes available for use
even tho it might not actually be a kernel module, it might be a user process
I think you have a good point about modules meaning something in the kernel. I'm really good with the idea in the kernel, not as hot on it when it's in userspace...
there will definitely be some asymmetry between kernel and user space
in kernel, you _must_ be able to make more than one instance of a parttype without reloading the module, because you _can't_ load a module twice
however, in user space, if you want two of something you can just start two copies of it
in fact you probably would have to start to copies of it... each one probably needs its own process/thread of execution
I was thinking about this...
for symetry sake... I'm thinking the user space hal_lib should have main in it, and fork / create threads to use the same create mechanism we make for modules in kernel space...
I've also been thinking that we might consider shared objects for user space 'modules', so that a hal_main can load shared objects in (and link with them) in much the same way that the kernel doe sfor kernel modules.
(Again, mostly for symetry.)
I don't know how we would do that (never done anything with shared libraries, etc, under Linux)
we have time to ponder that...
I was assuming that user space components would be ordinary binaries... you just run them from the command line
(halcmd would be able to fork and run them, to have a "loadusr" command analogous to "loadrt", but it wouldn't strictly be needed
I'm open to other methods though...
I think we need some sample components for thinking this thru
we'll have "VLSI" realtime parts, like motmod - a complete motion controller
and MSI realtime parts like stepgen or PID
One of the unfortunate things (to me) about emc/emc2 is that it has a zillion different binaries all over that have to work together. In some ways, this is great, and the 'unix' way to do things. In other ways, it's a big old distributed mess where nothing knows about anything... I'm not sure where the right balance is.
and SSI ones like "AND", "SUM", etc
I like the unix way. I'm a strong believer in partitioning, with _very_ well defined interfaces
(hence the HAL concept ;-)
the problem is the interfaces are not well defined.
HAL is much much much cleaner (IMHO) than the unixy binaries every where that emc currently uses.
I don't think the problem is the number of binaries, I think it is that the comms between them aren't kept simple
normal "unixy" binaries only have stdin and stdout
emc binaries use NML messages and/or shared memory, so they can have much more complex interaction
could be... paths are a huge problem to me.... It's *very* hard to package emc in an arbitrary directory right now.
don't know the answer to that
you said: " it's a big old distributed mess where nothing knows about anything..."
in a way, that also describes HAL
a bunch of parts - a knowledgable person could build hundreds of different things with them
but a less knowledgable person doesn't even know where to start
as opposed to something like Mach2, where you can only build one thing, a CNC control, but it's already assembled
I think hal has a central hal_lib that managed what it needs to to keep it's sub-parts working.
generic.run doesn't do a good job of being that same thing for EMC.
generic.run merely parses the ini file and loads the pieces you asked for in the file
not to different from halcmd
"generic.run -ini mymachine.ini" and "halcmd -f mymachine.hal" are conceptually the same thing, just operating at different levels
mymachine.* tells it what things you want and how they are connected
I see those levels as being very important though.
halcmd has the chance of being able to help you put peices together... generic.run ... well.. I don't see that potential.
hal is low level, where things are simple
the pieces that halcmd assembles range from SSI to LSI
I think emc at higher levels could be made just as simple. It's all about assembling bricks that have compatible ins and outs...
but generic.run is hooking together VLSI stuff with much more complex functionality and interfaces
think lego mindstorms graphical programming.
NML is supposed to enable you to do exactly that
I don't think there is a fundamental problem with the way the higher level parts of emc are broken up
I do think there is a severe lack of documentation of the interfaces between the parts
and some sloppiness, where folks allowed more coupling between parts than they should have because it made things a little easier
well... perhaps that's all. I know I got scared off when I first starting diving into all of that in the original emc code. I haven't revisisted in emc2, though I know paul has done a LOT of cleanup.
it's still tough to understand. There is a lot of coupling
and a lot of asymmetry
some, but not all, commands that get sent to the motion controller have corresponding NML messags
the ones that do can be sent from anywhere. the ones that don't can only be sent from the main task controller
there's very little consistency in deciding which ones are which
Hopefully that changes one day.
yeah... but for now I'll stay with the HAL where I know what I'm doing
anyway, I was going somewhere with my SSI/MSI/LSI crap
in realtime, we can have all levels
I don't think the SSI type stuff will be as usefull in user space
here comes a new checkin...
I expect that most user space components will be VLSI (like an IO controller, not an AND gate)
03zwisk 07halrefactor-0-1 * 10emc2/src/hal/ (hal_lib.c hal_priv.h hal_procfs.c hal_procfs.h):
More changes, mostly allowing for dynamic registration of modules
and block_types in kernel space using kernel space structures.
Also some early work on the mechanism for creating blocks.
This should build hal_lib.o and blocks.o successfully for testing.
OK... I'm not into EE daily enough to have a good feel ...
LSI = Large Scale Integration... VLS = Very Large ... MSI? SSI? Small Scale? What differentiates all of those?
sorry about that... you got it... VLSI is very large scale, things like microprocessors and such. MSI is medium scale, things like counters... SSI is small, individual gates
for EMC, the motion controller and IO controllers would be VLSI or LSI (one in kernel space, one in user space)
things like a PLC would also be LSI, and could be realtime or user
something like stepgen or a stg or parport driver are MSI
and things like summers, AND gates and such are SSI
think about the relative sizes of the data sheets for SSI, MSI, and VLSI parts
and gate needs a pinout and that's about it
that just means more complicated types. No big deal.
a counter needs a page or so to describe counting modes and such
a microprocessor has a book
(We should talk about that sometime too... allowing hal to create new arbitrary types from previous primitive types...)
oooooohhhhh.... hiercharical design - I like it (even tho I can't spell it)
(Can you tell I have big plans for hal? :) )
one thing that will be almost a neccessity if we get into that kind of flexibility is automatic management of threads and functions
having to decide exactly where in a thread an AND gate's function must execute such that the blocks feeding its inputs execute before it does, and the blocks fed by it execute after, will get really nasty with many parts
I also have plans for HAL beyond EMC... in fact at one time I was considering spinning it off into it's own SF project
I remember talking to you in passing about that once before.
about thread/funct management, or about spinning off?
So, any feedback or course correction on the changes I'm making would be great :)
spinning off. Thread/funct management is still conceptually passed where I fully grok the system :)
I really don't know what to think about spinning off
some of the things I want to do for HAL are far beyond what EMC needs, and might simply make it harder for a novice to use EMC
Paul and I have had words about that... he's not convinced that things like PID should become HAL modules
and within the confines of EMC, maybe he has a point
well.. we know they should :)
That may be true, but PIDs can be used for more than just EMC.
the downside of spinning off is that (prior to today) I expected that I'd suddenly find myself working all by my lonesome
I have that problem too. I have lots of big ideas, and lots of started projects, but without someone to work with, I tend to get bored/stuck/unmotivated at some point.
anyway, we've managed to digress again
true... and eventually I'm gonna segfault in the kenrel and have to reboot... I'm just sure of it! :)
have you looked at all at the 2.6 kernel compile rules? I'd like as part of this refactor to get 2.6 in there as well...
I'm afraid I don't know anything about 2.6
it scares me ;-(
why? (Should I be scared too?)
03zwisk 07halrefactor-0-1 * 10emc2/src/hal/ (hal_lib.c hal_procfs.c): cat /proc/hal/show_components now lists the 'modules' registered
dang - you been busy
I'm havin' fun :)
make fails, hal_lib.c:324: parse error before *
hmm.. how come it works for me, I commit, and then it's broken. I must be doing something wrong in my process....
looks like you are declaring a variable right in the middle of the code?
That's legal in c99 and c++ -- do you have an old compiler?
yeah, that's old
I did do that in a few spots where I was doing new stuff...
gcc version 3.2.3 20030422 (Red Hat Linux 3.2.3-6)
old my ass
hmm... ok... I guess I need to be careful of that...
(This code is a bit loose, for sure!)
* jmkasunich moves the decls to the top of the function
zwisk: Maybe you can arrange to use -std=c90 locally?
Hmm... is that what I should do?
I guess I think we should make emc compile by default with whatever level of compiler we want to support... (If we can)
hal_lib compiles now... still a number of warnings
IMO, we need to support BDI-2.xx, which is based on RH6
I'm using BDI-TNG, based on RH7
hm, -std=c89 doesn't stop declarations-in-midblock from building, unless I messed something up in my test program
HAL in particular may be used on small, old systems, almost as an embedded thing
ok... so... gcc -std=89 will make most newever version honor that?
zwisk: on gcc 3.3.3 it took '-std=c89 -ansi -pedantic' to get even a warning
/tmp/decl.c:1: warning: ISO C90 forbids mixed declarations and code
hm, there's also "-Wdeclaration-after-statement" in gcc 3.3.3
I use -Wall
and strive for zero warnings
I don't know if -Wall includes decl after statement or not
jmkasunich: that -W didn't exist in your gcc
jmkasunich: the question is whether zwisk could find a compiler flag to use so he won't write declarations after statements anymore
hehe.. yeah. Basically if I do it, and my compiler compiles cleanly, I assume it's alright :)
I was wondering if -Wall includes that -W in _his_ version
wait, that doesn't work
I must admit I'm a dinosaur as far as C dialects go... I learned from the K&R book, and other than adopting newer style function prototypes, I haven't evolved much
-ansi -pedantic gives a warning
I did lots of programming on DOS in the mid '90s using Watcom C, then winblows took the fun out of it. I only started again on Linux a couple years ago
so I missed the adoption of C99
I keep seeing you about, but you seem to have been a bit busy lately
busy? as in busy coding, or busy with life and not coding much?
both from what I could tell?
yeah, last month it was the latter, this week the former
making progress? I saw the .ini was gettign a beating the other day
not enough time
thats a common problem
robin_sz has changed the topic to: Welcome to the Enhanced Machine Control forum | Regular Developer's meetings every Sunday between 14:00 & 18:00 GMTcould have some of mine, but im using it
ChanServ has changed the topic to: Welcome to the Enhanced Machine Control forum | Regular Developer's meetings every Sunday between 14:00 & 18:00 GMT
you could have some of mine, but im using it
zwisk, you there?
looking at hal_register_module
it looks like you have a second linked list to hold the mb struct contents
why didn't you just add them as new fields in the comp struct?
indeed. I may be getting myself into big trouble here on memory usage.
Well, my thought is that the comp structure is in shared memory, and that all of this config information is meta data which will be in kernel memory. (Is this flawed? :) )
the comp list is metadata that we want to move into kernel memory
So, IIRC, the comp data structure has int's which are offsets into the shared memory buffer rather than pointers... so I thought it best to do a kernel memory based one using pointers.... I hadn't though all of comp would be moved out of shared memory...
the int offset mess is something that will go away if the list is moved into kernel memory
right... so my new linked list structure is a functional replacement for comps. (Hopefully I'm not stepping on anything or anyones toes with that notion...)
the problem with my approach (moving it into kernel) is that it is all or nothing... making the move can't be done incrementally
there should be only _one_ list of components, regardless of where it lives.
hmm... ok. My confusion on that I guess is in that it's one big shared memory map with stuff stuck on the top of it. Maybe the whole comp structure needs to come out.
it is a mess... I _really_ wish I could include pictures in the comments
pdf in the docs folder is great for that...
highly cross-linked data structures are both very powerfull and very confusing
on my "to do" list is a coders level extension (appendix maybe) to the HAL_Introduction document
we probably need two pics, one showing the data structs as the are now, and one showing what we want when we're done
that'd be fab. Alas, I'm not very good with drawing.. :)
I have the ability and tools do make the drawings (see the block diagrams in the HAL_Intro doc)
just lack the time
yeah... I hear you there.
your interest in the HAL refactor is a double edged sword.
yup. helping (I hope) but also eating away at your time.
one the one hand, you are doing stuff, _and_ you are motivating me to get off my hump
on the other hand, you are getting ahead of me
one big change I want to make is converting the linear linked lists to binary trees
yep. Keep in mind, too, that I don't have a huge amount of pride in this. I'm making a lot of changes, but understand if we back lots of 'em out, rename tons of stuff, or rework it.
Hmm.. you'll have to tell me your thoughts on that at some time; especially with regards to the get root / get next concept.
no time like the present
wow... that's a little shorter than it used to be!
I guess I'm looking for hal_cmds.c now ;-)
haha... yeah :) Hope that's all good :)
that funct gets the mutex, then traverses the list while printing, then releases the mutex
_if_ it is running in user space and has direct access to the linked listthe user space code
that should have said:
_if_ it is running in user space and has direct access to the linked list
but the plan is to move the list (which is metadata) to kernel space
it is trivial to traverse the list in kernel space too,
however you can't print the results from kernel space
you need to pass the results back to the user space caller
choices: 1) pass the entire list back to user space
2) pass one entry at a time back, let the user call again for the next one
the problem with 1) is that it means passing an arbitrarly large amount of data back to user space
the problem with 2 is that you must release the mutex after each item... what if by the time the user space prog calls again for the next item, that item has been deleted?
I want to do 2, and get around the issue of list modifications by having the caller pass the _name_ of the previous entry
it would then return the entry that is after that name, even if that name is no longer present
Couldn't an index do the same thing?
if you have a list that contains "A", "B", "F", "G", and someone asks you
"what comes after "C", you can answer "F", even if "C" isn't there
but if someone passed you an index to a "C" that has since been deleted, you're up a creek with a bad pointer
am I making sense?
sort of ... do the bit about the million monkeys with typewriters again
But inserting is still an issue, right? You could miss an item if one is inserted.
I'm assuming that one instance of halcmd is running the "show comp" command, while another instance attempts to manipulate things - adding comps, deleting them, etc
go back to the A,B,E,F example
I'm traversing the list, just finished B
when I say "next(B)", if a C has been inserted, I'll get it
if not, I'll get E
if C is inserted after I've already made it to E, then I'll miss C, but that's life
But it's imperfect either way, right? Just a matter of where you don't get data... on insert of delete...
suppose the list was ABCDEF
better to miss someting than get a ref to soemthig thats gorn
I'm reading it, just finished C, and ask for next(C)
but C's been deleted
if the search is name based, it will still find D, but it will do it by starting at A and looking for name > "C"
if it was next(ptr_to_C), and C was deleted, I have a pointer to nothing (C may have been freed, even if not, it's next pointer likely doesn't point to D anymore
so "starting at A and looking for name > C" always works
cool... that works.
It assumes that your data is sortable, and unique.
the only problem is that to traverse a linear list of N items using that method results in searching the list N times, and if it's a linear search, I do N*N*0.5 accesses to the list
a binary tree lets you search the list with logN accesses
so traversing it will take N*logN accessses
note that _all_ access to the list will be by name... if you want to know any field in the comp/mb struct associated with "B", you will search for "B"
if you do the search only once, then remember a pointer to B, you risk problems if someone deletes B in the meantime - your pointer is no good
there is another solution
just about every API will take a name, and go something like this:
search for name
do whatever the API is supposed to do - get/set a field, etc
release the mutex
robin_sz: what is it?
well ... in Java, this problem is solved with an 'enumerator'
the lists is traveresed, a copy of references is made, and then you can always get the next item in the list from where you are by calling next
but . the key is that stuff cant be deleted
right - it assumes you are single threaded
but HAL can be modifed at any time