#emc | Logs for 2005-01-16

Back
[00:00:14] <robin_sz> until the enumerator releases it
[00:00:18] <robin_sz> sure ...
[00:00:49] <jmkasunich> question - how does linux handle directories... same problem... someone may delete or add a file while in another shell they're ls'ing the same directory
[00:00:58] <robin_sz> what other languages do is have each 'thing' hold a referecne counter
[00:01:14] <zwisk> seems nifty... I have recently worked some with tcl, which converts everything to strings, and unfortunately that's left a bad taste in my mouth for strings... but... I'll try to get over that ;)
[00:01:36] <jmkasunich> zwisk - the only strings are object names
[00:01:55] <jmkasunich> like stepgen.0.step
[00:02:04] <jmkasunich> we want human readable names for those things anyway
[00:02:06] <robin_sz> so, thing A is created and a referecne is held in a list, thing A knows that one thing holds a reference to it
[00:02:43] <robin_sz> when the array deletes that ref, it shoudl inform A that its no longer holding a reference
[00:02:55] <robin_sz> when A's reference counter hits zero, it deletes itself
[00:03:11] <jmkasunich> ewwww
[00:03:25] <robin_sz> otherwise, you could be about to do someting to A, and soemthing else could delete it
[00:03:59] <robin_sz> many languages work this way internally
[00:04:05] <jmkasunich> my plan is that you say "do foo to A"
[00:04:21] <jmkasunich> the code will get a mutex, look up A, do foo to it, and release the mutex
[00:04:24] <jmkasunich> atomic operation
[00:04:57] <jmkasunich> if someone else says "do delete to A", then either you get there first, and your op succeeds, or they get their first, and your op says "A not found"
[00:05:07] <jmkasunich> no chance for lockup or crash in either case
[00:05:21] <robin_sz> get me a list of things in A
[00:05:26] <robin_sz> how many things are there?
[00:05:28] <robin_sz> 15
[00:05:34] <robin_sz> ok lets do stuff to these 15
[00:05:40] <robin_sz> oh theres only 14 now
[00:05:43] <jmkasunich> but if you were able to do "get me a pointer to A" and then later "modify the thing pointed to by this pointer", you can have trouble
[00:06:08] <robin_sz> sure
[00:06:24] <robin_sz> as I say, many languages do the reference counter thing
[00:06:59] <jmkasunich> so you're saying that if somebody had said "get me a pointer to A", then until they say "I no longer need this pointer to A", that A would be locked?
[00:06:59] <robin_sz> but mutexs are another way
[00:07:10] <robin_sz> not locked no
[00:07:15] <robin_sz> but not deleteable
[00:07:20] <jmkasunich> well you wouldn't be allowed to delete it
[00:07:30] <robin_sz> correct
[00:08:16] <robin_sz> if the thing is an integer or a float, then deleting it is simple
[00:08:33] <robin_sz> if its a more complex tihng, then it will likely have its own delete routines
[00:08:37] <jmkasunich> in this case, the thing is a struct containing everything the HAL knows about a module
[00:08:59] <robin_sz> (which may write stuff back to a file or a db before it hits the bit bucket)
[00:09:35] <jmkasunich> no need for that here
[00:09:39] <robin_sz> quite
[00:09:57] <jmkasunich> but there is much cross coupling
[00:10:01] <jmkasunich> there is a list of components
[00:10:02] <robin_sz> but delete routines or destructors are there if you need them in many languages
[00:10:21] <robin_sz> well, if theres lots of cross coupling
[00:10:31] <jmkasunich> there is only one language relevant here - C
[00:10:41] <robin_sz> isnt the risk of someting wanted by one thingm being deleted by another thing there?
[00:11:05] <jmkasunich> at least until you can reliably write kernel modules in Python, or Java, or such, at which point I quit programming again
[00:11:16] <robin_sz> well, you are trying to build waht is effectively a language .. HAL, on top of C
[00:11:23] <jmkasunich> yes, in a way
[00:11:30] <robin_sz> so ...
[00:11:57] <robin_sz> you can either say "there is nothing out there that is relevant or similar .. all the problems here are unique"
[00:12:11] <robin_sz> or you pick bits that work from hopw other people have solved stuff
[00:12:21] <jmkasunich> miscommunication
[00:12:32] <robin_sz> the trick is to pick the tight bits :)))
[00:13:13] <jmkasunich> I'm trying to figure out _how_ to implemnet such things in the language I have
[00:13:47] <jmkasunich> I thought you were telling me that "they are already implemented in language J" which isn't usefull to me
[00:13:57] <robin_sz> right, but these same problems have been solved before
[00:14:02] <jmkasunich> agree
[00:14:08] <robin_sz> quite,
[00:14:17] <robin_sz> I wasnt suggesting you USE the other random language
[00:14:36] <robin_sz> but the implementation may be useful
[00:14:54] <jmkasunich> true enough... for example, today I don't use reference counting
[00:14:57] <robin_sz> or at least worth looking at so you can say "yuck" :)
[00:15:30] <jmkasunich> when someone says "delete signal foo", I must traverse the pin list to see if any pin is connected to signal foo, and if so disconnect it before deleting foo
[00:15:58] <jmkasunich> although a ref count wouldn;t really help there, I need to know _which_ pins are linked to foo, not just how many
[00:16:11] <robin_sz> sort of
[00:16:19] <robin_sz> you could just never say delete_foo
[00:16:36] <jmkasunich> what do you mean?
[00:16:54] <robin_sz> reference counting just says, "well, theres pins connectoed to it still, I guess its still neeeded
[00:17:08] <robin_sz> when you disconnnect the last pin, it deletes itself
[00:17:16] <jmkasunich> but I don't want it to
[00:17:29] <robin_sz> well, thats fine, its an architecture decision
[00:17:41] <jmkasunich> as a user, I want to declare the signal, then connect as few or many pins as I wish to it
[00:18:01] <jmkasunich> if I disconnect them all, the signal should stay around, so I can connect more things to it later
[00:18:09] <robin_sz> ok
[00:18:22] <robin_sz> imagine you create a timer, and connect someting to it
[00:18:26] <jmkasunich> OTOH, if I delete the signal, all the pins connected to it need to disconnect automatically, the user shouldn't have to do that
[00:18:38] <jmkasunich> as you say, architecture issues
[00:18:46] <robin_sz> some other ting also conencts someting to the timer
[00:19:07] <robin_sz> the thing that created the timer beleives its now no longer needed and dleltes it
[00:19:22] <robin_sz> leaving the second thing now broken and timerless
[00:19:34] <jmkasunich> so it goes
[00:19:44] <robin_sz> indeed
[00:19:50] <jmkasunich> in HAL, the tings doing the creating and deleting are humans who are designing a system
[00:20:18] <robin_sz> tings wont get added, modified or deleted in realtime?
[00:20:24] <jmkasunich> if I have an emc running and I choose to delete the step generator, it's gonna get deleted
[00:20:38] <jmkasunich> actually, you might have something there
[00:21:09] <jmkasunich> I still insist that if I truly want to delete a step generator even tho its got stuff connected to it, I should be able to
[00:21:22] <jmkasunich> however, there might be benefit to warning the user that stuff is connected to it
[00:21:38] <robin_sz> indeed
[00:21:56] <robin_sz> if you did have that ...
[00:21:58] <jmkasunich> the warnings could become a PITA very quickly
[00:22:16] <robin_sz> you could implement what many languages call a 'garbage collector'
[00:22:30] <robin_sz> walk the tree, find tihngs with no connections and bin them
[00:22:30] <jmkasunich> no, never, no way
[00:22:45] <robin_sz> or, even as a user thing ?
[00:22:58] <robin_sz> 'find me spare stuff ive forgeotten to connect'?
[00:23:20] <jmkasunich> maybe a "delete unused" command or something, but certainly not as the primary method of freeing stuff
[00:23:50] <robin_sz> as seeen in a million an one pcb layou packages "wanirng: resitor R34 has no connections"
[00:24:03] <jmkasunich> right
[00:24:43] <jmkasunich> but again we're drifting away from the details that I was focused on
[00:24:49] <robin_sz> true
[00:25:19] <jmkasunich> ref counts alone won't work because you almost certainly need to know _which_ things are referencing you, not just how many
[00:25:21] <robin_sz> mutex or reference count .. just dofferent answers to the same problem
[00:25:31] <jmkasunich> nope - different problems
[00:25:57] <robin_sz> most languages just ahve an integer count
[00:26:03] <jmkasunich> mutex is used to prevent simultaneous access while you are making changes
[00:26:10] <robin_sz> true
[00:26:12] <jmkasunich> the changes may in turn change a reference count
[00:26:33] <jmkasunich> for instance the linksp command links a signal to a pin
[00:26:54] <jmkasunich> the command must verify that both signal and pin exist, then establish the linkage... in the process, the pin
[00:26:57] <jmkasunich> oops
[00:27:14] <jmkasunich> the pin's refcount and the signal's refcount will increase
[00:27:58] <jmkasunich> but the entire process of verifying pin exists, verifying sig exists, verifying that they're compatibla, and connecting them, must be protected so somebody can't come in and delete the pin in the middle
[00:28:10] <robin_sz> quite
[00:28:33] <robin_sz> threads, 'synchronized' etc
[00:28:45] <jmkasunich> the binary tree scheme is just a way to make the "verify pin exists" a little faster
[00:29:22] <robin_sz> you are going to ahve a fun time with all this you know :)
[00:30:25] <jmkasunich> why do you say that?
[00:31:20] <robin_sz> you are going to go through pretty much all of writing your own high-level languiage ...
[00:31:23] <robin_sz> no mean feat
[00:32:01] <jmkasunich> already did it once.. this is the HAL "refactor", remember
[00:32:10] <robin_sz> indeed
[00:32:43] <robin_sz> 'plan to throw at least one away' :)
[00:33:32] <robin_sz> woner haow les is getting on with segmot
[00:33:50] <robin_sz> wonder how his mexican is getting on with sanding?
[00:33:57] <jmkasunich> dunno
[00:34:26] <jmkasunich> you have a terrible way of distracting me... I barely remember what zwisk and I were discussing ;-)
[00:34:38] <anonimasu> hm..
[00:35:00] <robin_sz> you were traversing a changing list :)
[00:35:18] <jmkasunich> right... changing from linear lists to binary trees
[00:35:19] <gezr> wata
[00:35:33] <jmkasunich> * jmkasunich digs out his ancient balanced binary tree code
[00:35:38] <gezr> I think I got my self into to much stuff
[00:35:39] <gezr> again
[00:35:45] <anonimasu> :)
[00:35:49] <robin_sz> gezr: you are in a maze of twistign opassages, all different
[00:36:30] <gezr> hu?
[00:37:03] <robin_sz> old game on early mainframes
[00:37:14] <gezr> yeah, my prusit of C I think is going to have to go onto the back burner, I should work just on the bike and the emc ploter
[00:37:31] <gezr> this past week seems to have flown by
[00:37:36] <robin_sz> is that good?
[00:37:52] <gezr> and Im not sure I got anything done, I know I forgot to pay some bills, thats not a good thing
[00:38:04] <gezr> I did manage to clean up 1/2 my shop
[00:38:39] <gezr> Ide love to learn how to program, but I cant stay simple, im not ready for it yet
[00:39:32] <robin_sz> emc is proably not hte thing to cut your teeth on anyway
[00:39:42] <gezr> no and im not using it to do that
[00:39:52] <robin_sz> heh:)
[00:39:56] <gezr> its eventually a goal but not part of the learning
[00:40:18] <robin_sz> so ... how is the EMC powered plaotter going?
[00:40:21] <gezr> its like mastering the stroke but all were after is the grand fanal
[00:40:45] <gezr> I bought a 2x2 foot 1/2 thick plywood sheet to mount it to today
[00:40:51] <robin_sz> good call
[00:41:00] <gezr> Y is finished
[00:41:01] <robin_sz> I used 40mm MDF for my router
[00:41:05] <gezr> or its X
[00:41:13] <robin_sz> kew;
[00:41:20] <robin_sz> got a motor and a drive?
[00:41:28] <gezr> maybe tonight while im watching cartoons ill make the other slide
[00:41:35] <anonimasu> :)
[00:41:52] <gezr> yeah, drive is just my good ole ucn8054b chips
[00:42:02] <gezr> motors are just oh that should work,
[00:42:06] <gezr> nema23's
[00:42:30] <gezr> powersupply is computer standard, at style with a switch
[00:42:47] <gezr> lighting provided by 2 special light bars out of an old scanner
[00:42:48] <anonimasu> hm, could I just put in the pin definitions into the generic.ini and run?
[00:43:19] <anonimasu> since when I use the emc.ini the computer freezes..
[00:43:33] <gezr> and im thinking I can use mr dremell as a fixed Z
[00:44:24] <zwisk> whelp... I hit my kernel oops and had to reboot :)
[00:44:41] <robin_sz> gezr: are you going to hook it up and drive that first axis soon then?
[00:44:42] <jmkasunich> how come you keep having oopses?
[00:44:54] <zwisk> first one this project! :)
[00:45:18] <zwisk> This time it's because I goofed up a return value and ended up in an endless loop inside the kernel.
[00:45:20] <gezr> robin_sz : yeah ive done that already
[00:45:26] <robin_sz> kewl :)
[00:45:34] <jmkasunich> oh, I thought you said something earlier about expecting them
[00:45:49] <jmkasunich> as if they were a regular occurance
[00:45:50] <robin_sz> thats a great ting to do .. once you see one move, you just ned two now to doa circle :)
[00:46:34] <anonimasu> hm..
[00:46:40] <zwisk> well... yeah, when you develop in the kernel, sooner or later you get the equivelent of a segfault in the kernel. If it's during module initialization, I haven't found a way to gracefully recover...
[00:46:59] <gezr> robin_sz : a circle, with an A in the middle
[00:47:03] <anonimasu> :)
[00:47:13] <gezr> cause once I get that taste my finacial situation may fall to anarchy
[00:47:19] <anonimasu> 3d shapes are cool :)
[00:47:37] <jmkasunich> zwisk: been there, done that
[00:47:53] <robin_sz> gezr: worry not, somehting will turn up
[00:48:05] <jmkasunich> especially when I was working on RTAPI
[00:48:51] <anonimasu> hm, how far away is the vital cards from being usable?
[00:49:09] <robin_sz> * robin_sz passes anonimasu a piece of string
[00:49:09] <jmkasunich> emc1 or emc2?
[00:49:27] <anonimasu> robin_sz: I meant with the interference issues..
[00:49:43] <robin_sz> no eyed deer
[00:49:48] <anonimasu> jmkasunich: the default BDI one..
[00:50:58] <jmkasunich> emc1 then... I thought it already did work with emc1
[00:51:06] <robin_sz> * robin_sz nods
[00:51:15] <robin_sz> I thought it was 'testing' still ...
[00:51:30] <jmkasunich> dunno - Paul and Abdul are involved in that
[00:51:42] <robin_sz> as in 'it appears to work, lets check to be sure'
[00:52:11] <anonimasu> ah ok
[00:52:32] <anonimasu> as soon as it's confirmed to be working good for a while I'll order one..
[00:55:07] <robin_sz> it may have progressed since then, check with paul_c to be sure
[00:55:56] <anonimasu> ok
[00:58:41] <robin_sz> tired now, spent several hours assembling pallet racking and stacking stuff on it
[01:01:06] <gezr> if your going to bed goodnight
[01:02:31] <anonimasu> I'll be heading out for the shop in na bit
[01:03:01] <gezr> I think im gonna boot the emc box to win and watch some cartoons and play clean up some more
[01:03:21] <anonimasu> I need to get emc running if I am going to try this stuff out tomorrow..
[01:03:25] <gezr> and then if I get that done I may do something else
[01:03:53] <gezr> Like work on getting the bike finished up
[01:12:15] <anonimasu> :)
[01:13:46] <A-L-P-H-A> gezr, remember those pictures... spent all day making a application/php script to gallery them for me. http://www.lloydleung.com/EMC
[01:14:13] <gezr> apt-get install gallery :)
[01:14:24] <A-L-P-H-A> Not what I watned.
[01:14:36] <A-L-P-H-A> gallery _can't_ just look at a directory and display thumbnials.
[01:14:42] <gezr> ah
[01:14:47] <A-L-P-H-A> I have to go through a whole process to enter them into the database.
[01:14:58] <A-L-P-H-A> I want something _simple_, thumbnails generation...
[01:15:13] <A-L-P-H-A> so I can just upload pictures, and wham done.
[01:15:18] <A-L-P-H-A> evreything is automated.
[01:15:24] <gezr> its cool
[01:43:34] <gezr> ive got at least 100 feet of this stuff
[01:44:59] <gezr> 18awg 300v 7pair with one coated, and one uncoated, I could call it 8 pair with a free ground I guess
[01:45:16] <gezr> good stuf?
[01:50:08] <A-L-P-H-A> what do you need it for?
[01:50:09] <A-L-P-H-A> :)
[01:50:27] <A-L-P-H-A> I hate when I have to maching small stuff... I have to go sooooo slow.
[01:50:40] <gezr> I wont need all of it :)
[01:50:47] <gezr> so Ill give whoever may need some some
[01:50:58] <A-L-P-H-A> machining O1 drill rod... with the diamter now down to 4.8mm... I'm going like 2000rpm or so, at 10mm/min
[01:51:10] <gezr> hmm
[01:51:18] <A-L-P-H-A> it's coming out very shiney. :)
[01:51:21] <A-L-P-H-A> if I don't... it chatters.
[01:51:34] <A-L-P-H-A> I have a live center supporting it already to.
[01:51:39] <gezr> thats good
[01:51:43] <gezr> whats your depth of cut?
[01:51:48] <A-L-P-H-A> 0.05mm righ tnow.
[01:51:49] <gezr> and are you using an insert?
[01:52:00] <gezr> are you getting a stringy chip?
[01:52:02] <A-L-P-H-A> when it was larger I was doing 0.1mm
[01:52:07] <A-L-P-H-A> very stringy.
[01:52:15] <gezr> you need to take at least 1mm doc
[01:52:16] <A-L-P-H-A> I had a big clump of steelwool.
[01:52:27] <A-L-P-H-A> 1mm??
[01:52:29] <A-L-P-H-A> ONE!?
[01:52:31] <gezr> what sort of tool are you cutting with?
[01:52:51] <gezr> just a ground hss bit?
[01:52:52] <A-L-P-H-A> I'm using an carbide insert, that was originally good for ALuminium.
[01:53:05] <A-L-P-H-A> the stock was only 1/2" to begin with.
[01:53:06] <gezr> okay, whats the corner radius of the insert?
[01:53:11] <A-L-P-H-A> sec.
[01:53:18] <A-L-P-H-A> let me find the designation for the bit
[01:53:52] <A-L-P-H-A> toshiba tungaloy... DCGT 11T304
[01:54:02] <A-L-P-H-A> these puppies were $10USD a bit.
[01:54:08] <gezr> oh man
[01:54:18] <A-L-P-H-A> looking it up.
[01:54:37] <gezr> I cant tell the raidus for that, the 4 would be it, but thats like .063inch radius
[01:54:59] <A-L-P-H-A> http://www.carbidedepot.com/detail.asp?product_id=TT%20DCGT11T304PPH10T
[01:55:11] <A-L-P-H-A> err... maybe I paid 12.53 for them.
[01:55:16] <A-L-P-H-A> I bought them from that place.
[01:56:12] <gezr> yeah, you need to get your doc up there, so that you break your chip
[01:56:13] <A-L-P-H-A> radius maybe ~0.5mm... I'm comparing it to pencil lead.
[01:56:31] <gezr> the stringy stuff is okay for a finish pass, but those chips are deadly
[01:56:37] <A-L-P-H-A> gezr, does it matter?
[01:56:44] <A-L-P-H-A> I'm just curious as to why?
[01:56:52] <A-L-P-H-A> I've always machined stuff to be stringy...
[01:57:00] <gezr> we had a tech almost get his foot cut off by a stringy chip
[01:57:07] <gezr> it only stopped when it hit bone
[01:57:24] <A-L-P-H-A> this is string, not ribbons.
[01:57:29] <A-L-P-H-A> it's really soft.
[01:57:45] <gezr> I hate strings
[01:57:51] <A-L-P-H-A> and I have an encloser for my lathe as well.
[01:57:54] <gezr> they are razor blades that never end
[01:58:21] <A-L-P-H-A> I guess I could put pauses in my code to stop this kinda stuff. But they don't bother me so much.
[01:58:23] <gezr> that stuff should be chipping
[01:58:29] <A-L-P-H-A> chips get stuck to the bottom of my slippers.
[01:58:39] <gezr> yeah
[01:58:53] <A-L-P-H-A> strings don't... they just get smooshed.
[01:59:06] <gezr> im not saying its wrong to have them, but you really want to be maching,
[01:59:22] <gezr> limitations are one thing, that is the first thing to be addressed
[01:59:40] <gezr> the little chips suck, I get them everywhere
[02:00:16] <gezr> but you can increase your machining time greatly
[02:00:16] <A-L-P-H-A> well... I was maching at these specs... 6 to 4mm radius, I was going at .2. 3-4mm I was going .15, 3-2.5mm I was going at .1. now I'm finishing at 0.05mm DOC.
[02:00:30] <A-L-P-H-A> gezr, I probably could...
[02:00:44] <A-L-P-H-A> realize that my spindle is 1:1 geared, and my spindle HP is rated at 1hp.
[02:00:55] <gezr> yeah limitations :)
[02:01:16] <A-L-P-H-A> if I had american iron, I'd definitely be maching with a higher DOC.
[02:01:21] <gezr> hahahaha
[02:01:33] <A-L-P-H-A> but hey... it's only my lathes time... and I can watch TV in the other room, or chat in here. :)
[02:01:38] <gezr> just work at a depth at least the radius of your tool
[02:01:46] <A-L-P-H-A> this is a swiss watch lathe... only so much abuse I can dish to it.
[02:02:11] <gezr> at lighter depths of cut, the part tends to want to push away from the insert
[02:02:50] <gezr> even when doing very light work
[02:02:58] <A-L-P-H-A> 1/64 is the radius
[02:03:21] <A-L-P-H-A> 0.016mm,
[02:03:27] <gezr> so .016inch
[02:03:29] <A-L-P-H-A> err. 0.016".
[02:03:30] <A-L-P-H-A> :)
[02:03:49] <A-L-P-H-A> I could do .4 DOC.
[02:03:53] <A-L-P-H-A> .4mm DOC
[02:04:03] <gezr> yeah
[02:04:42] <gezr> and you could feed at .4mm/rev
[02:05:22] <gezr> I cant remember the calculation right off the top of my head
[02:05:39] <gezr> rpm * mpm * .262 maybe it
[02:06:21] <gezr> I cant really remember, its been a while
[02:08:31] <A-L-P-H-A> well... I'm right now making a shaft for my wormgear... dang it is time consuming... I'm getting it close to size, and using sandpaper in an 1" strip, to grind it down to size...
[02:08:43] <gezr> thats the best way :)
[02:08:55] <A-L-P-H-A> getting within 0.02mm and then grind.
[02:09:21] <A-L-P-H-A> press fit the worm on... and use a #53 drillbit on the shaft... stick a spring pin in.
[02:14:32] <gezr> I dont like stringy chips
[02:14:54] <gezr> then again, ive had a few #9's or sixes stuck in the bottom of my foot ouch
[02:15:47] <A-L-P-H-A> #9's or sixes?
[02:16:02] <A-L-P-H-A> this stuff I have is like steelwool...
[02:16:05] <A-L-P-H-A> very very fine.
[02:16:36] <gezr> oh cool
[02:23:09] <CIA-5> 03zwisk 07halrefactor-0-1 * 10emc2/src/hal/ (hal_lib.c hal_priv.h hal_procfs.c components/blocks.c): (log message trimmed)
[02:23:09] <CIA-5> [root hal]# insmod hal_lib.o
[02:23:09] <CIA-5> [root hal]# insmod blocks.o
[02:23:09] <CIA-5> [root hal]# echo "blocks mux2" > /proc/hal/create
[02:23:09] <CIA-5> [root hal]# cat /proc/hal/show_blocks
[02:23:11] <CIA-5> 0: blocks mux2
[02:23:13] <CIA-5> [root@vader hal]# cat /proc/hal/show_components
[02:36:00] <A-L-P-H-A> hmm... stupid spring pin is 1mm too long on either ends... looks like I'm gonna have to get the dremel out and grind the spring pin just a tad.
[02:52:17] <A-L-P-H-A> dremel is my friend. :)
[03:05:23] <A-L-P-H-A> http://lloydleung.com/EMC/Worm_Spindle/ <click on the thumbs>
[03:05:52] <gezr> thats cool
[03:08:30] <zwisk> jmt, are you still about?
[03:08:37] <zwisk> urr... jmk I mean...
[03:08:38] <jmkasunich> yeah
[03:08:51] <jmkasunich> was away for a while, just got back
[03:09:00] <zwisk> I've either wrapped my brain in a knot or found somethin' interesting... (to me anyway...)
[03:09:17] <A-L-P-H-A> I should probably have it change cursors when mouseover...
[03:09:18] <zwisk> comp_t corresponds to things that call hal_init, not to individual 'parts'. Is that right?
[03:10:22] <jmkasunich> right
[03:10:28] <zwisk> hmm.. ok.
[03:10:57] <zwisk> I think we want to change it such that comp_t (or block_t or part_t) corresponds to the specific part....
[03:11:09] <jmkasunich> we'll need both
[03:11:42] <jmkasunich> one for the module (or library, or collection, or whatever we call the thing that makes multiple part types available)
[03:11:50] <jmkasunich> and another for the individual parts
[03:11:55] <zwisk> ok. What's the limitations on shared memory? How much can we get, and what's a good policy? Does severy part get it's own block? Every 'library' ?
[03:12:20] <jmkasunich> right now all HAL shmem data is in one big block of shmem
[03:12:34] <jmkasunich> we really don't want to be getting lots of different blocks
[03:12:45] <jmkasunich> the block size can be pretty big
[03:12:45] <zwisk> hmm.. ok. cool.
[03:13:00] <jmkasunich> at one time I thought there was a 64K limit, but I don't think that's actually true
[03:13:26] <jmkasunich> (though you'll notice that HAL uses a block that is just under 64K)
[03:13:42] <zwisk> ok... that all seems good...
[03:14:03] <jmkasunich> the only thing in HAL that uses a separate shmem block is halscope
[03:14:27] <jmkasunich> the RT part of halscope captures data and sticks it in a shmem block, the user space part reads that data and displays it
[03:14:42] <zwisk> ok...
[03:15:16] <jmkasunich> doing another cvs up right now
[03:15:41] <jmkasunich> fargle
[03:15:59] <zwisk> fargle?
[03:16:13] <jmkasunich> "rcsmerge: warning: conflicts during merge "
[03:16:23] <zwisk> doh..
[03:18:06] <jmkasunich> found it - remember I said I fixed the declarations in the middle of the code... you did two, and we didn't use exactly the same whitespace, etc
[03:18:20] <zwisk> ahh...
[03:18:28] <jmkasunich> just deleted my copy, and cvs up again to get the official one
[03:41:01] <jmkasunich> yuck
[03:41:24] <jmkasunich> looks like kmalloc allocates memory in binary chunks, the smallest is 32 bytes
[03:42:04] <jmkasunich> I'm gonna be allocating lots of 14 byte structs, with 18 bytes of waste in each one
[03:45:05] <jmkasunich> unless I use kernel lookaside caches....
[04:31:54] <zwisk> 32 bytes minimum?? Ugh.... Tjat
[04:31:57] <zwisk> isn't good...
[04:32:39] <jmkasunich> this old code I'm reformatting and updating actually used some even older code that implemented a primitive "slab cache"
[04:32:50] <jmkasunich> although I didn't call it that at the time
[04:33:07] <jmkasunich> but I don't know if I want to port that stuff over
[04:33:16] <jmkasunich> for now I'll just let it waste memory
[04:34:05] <jmkasunich> I wrote the old code back in the days when you had to deal with near and far pointers and all that fun segment stuff
[04:35:06] <zwisk> hmm.. sounds mac-like ... Didn't the 68k do some bank switching or something?
[04:35:17] <jmkasunich> this was X86
[04:35:30] <jmkasunich> 16 bit X86 that is
[04:35:44] <jmkasunich> Turbo-C originally, later ported to watcom
[04:35:59] <zwisk> ahh... ok... then my comparison point is the 65816 with a bank register... :)
[04:36:11] <jmkasunich> near pointers were stored as 16 bit, and could only address 64K
[04:36:29] <zwisk> same thing on the 65816
[04:36:30] <jmkasunich> far pointers were stored as segment:offset (32 bits) and could address 1 Meg
[04:36:43] <jmkasunich> and beyond 1Meg wasn't available
[04:37:28] <jmkasunich> that's one part of the old days that I _don't_ miss at all! ;-)
[04:37:45] <zwisk> hmm... the 65816 had a higher limit... I had 4megs in mine...
[04:39:07] <jmkasunich> what system was that? mac or something?
[04:39:38] <zwisk> apple //gs
[04:39:46] <jmkasunich> wow
[04:40:03] <jmkasunich> for some reason I thought you were a young feller
[04:40:17] <zwisk> haha... so, that dates me? ;)
[04:40:35] <jmkasunich> somewhat... I can't pin it down too tightly cause I don't know apples
[04:40:47] <jmkasunich> but it had to be pre-1990, right?
[04:41:01] <zwisk> yup...
[04:41:16] <zwisk> I was tinkering on the apple ][ in '81...
[04:41:27] <jmkasunich> first computer I ever programmed on was a TRS-80, circa 78-80
[04:41:39] <zwisk> I still have one of those :)
[04:41:53] <jmkasunich> first one I ever owned was a Kaypro2 (Z-80, 64K) in 84-85
[04:41:56] <zwisk> It's in Illinois, and I'm in California now, but ... it's fun to look at.
[04:42:08] <jmkasunich> I still have the kaypro
[04:42:30] <zwisk> Hmm... we may be about the same age then?
[04:42:33] <jmkasunich> 42
[04:42:49] <zwisk> or not :) 30...
[04:42:51] <jmkasunich> (the answer to life, the universe and everything)
[04:43:29] <jmkasunich> you were 7-8 when you started appleing? cool
[04:43:58] <zwisk> yup. dad told me I couldn't play "little brick out" (like breakout) until after I learned to write code in basic.
[04:44:06] <jmkasunich> lol
[04:44:28] <jmkasunich> I wanted to program... my parents didn't know anything bout puters
[04:45:11] <zwisk> dad taught at an elementary school and was able to bring a computer home one summer; that's how I got my start.
[04:45:17] <jmkasunich> cool
[04:45:46] <jmkasunich> yeah, I was already in HS before I laid hands on a computer
[04:45:55] <jmkasunich> got the Kaypro after graduating college
[04:46:06] <jmkasunich> learned C in college, on a PDP-11
[04:46:54] <zwisk> The high school in dad's district had a pdp 11/44 that I played with when Igot the chance. Always in basic on that thing though.
[04:51:02] <zwisk> oh boy... I'm makin' a mess out of your little hal... :)
[04:51:47] <jmkasunich> gotta make it worse before you can make it better
[04:52:02] <zwisk> glad you understand that! :)
[04:52:10] <jmkasunich> that's the definition of refactoring... if you can just incrementally improve things, it's not a refactor
[04:52:28] <jmkasunich> when you tear it down to the bare bones and rebuild it, that's a refactor
[04:53:12] <jmkasunich> I hope you aren't writing too much code that traverses the linked lists...
[04:53:43] <jmkasunich> my goal for tonight is to get the btree library cleaned up and tested
[04:53:51] <zwisk> nope. not a lot. And most of that code ends up being a 2 line for statement that's easy enough to replace with the btree...
[04:54:10] <jmkasunich> then I'll start moving those lists to kernel memory and accessing them with the tree stuff
[04:54:31] <zwisk> I am moving a lot of stuff into the kernel though...
[04:55:08] <jmkasunich> so then halcmd is broken (at least for now)
[04:55:28] <jmkasunich> since it can't access the stuff you've moved
[04:55:34] <zwisk> oh yeah... In my branch that I haven't checked in, I've disabled building the non-kernel stuff..
[04:55:48] <jmkasunich> ok
[04:56:00] <jmkasunich> "branch that I haven't checked in"?
[04:56:14] <zwisk> uh.. sorry. my bad. Sine my latest cvs commit ...
[04:56:19] <zwisk> s/Sine/Since/
[04:56:20] <jmkasunich> ok
[04:56:31] <jmkasunich> I want to avoid lots of uncommitted work
[04:56:54] <zwisk> me too... but I always want things to at least compile when I check in.
[04:57:12] <jmkasunich> good plan... and for those things that won
[04:57:15] <jmkasunich> dammit
[04:57:25] <jmkasunich> that won't, comment them out in the makefile
[04:57:30] <zwisk> yup.
[04:57:38] <jmkasunich> I always tend to hit enter instead of '
[04:57:44] <zwisk> I do that too.
[04:57:50] <zwisk> it must be a keyboard design problem.
[04:58:06] <zwisk> So, am I right to be thinking we want to minimize what goes in shared memory?
[04:58:11] <jmkasunich> yes
[04:58:41] <jmkasunich> take a look at hal_priv.h
[04:58:55] <zwisk> AT the moment, it seems like only the signal's "data_ptr" needs to go in shared memory...
[04:59:26] <jmkasunich> yes
[04:59:34] <zwisk> Everything else seems to just point to it. If the kernel is always doing the configuring of where things point, it can be in kernel space...
[04:59:48] <jmkasunich> for a pin, it would be data_ptr_addr _and_ dummysig
[05:00:16] <zwisk> right... ok...
[05:00:57] <jmkasunich> actually, even data_ptr would go in kernel memory, but data_ptr would point to a location in shmem
[05:01:20] <zwisk> right... Is there a 'generic' way to deal with dummysig?
[05:01:23] <zwisk> it's not settable, right?
[05:01:45] <zwisk> Can 1 dummysig per type be created and shared across all things of that type?
[05:01:49] <jmkasunich> nope
[05:02:00] <jmkasunich> that would work for pins that are inputs to parts
[05:02:14] <jmkasunich> but for pins that are outputs to parts, dummysig gets written on a regular basis
[05:02:25] <jmkasunich> (if the pin isn't linked to a real signal)
[05:02:33] <zwisk> Oh... so 1 for input and 1 for output ?
[05:02:42] <jmkasunich> hmmmmm
[05:02:46] <jmkasunich> didn't think about that
[05:02:58] <jmkasunich> there are also bidirectional pins
[05:02:59] <zwisk> the input would never be written, and the output would never be read...
[05:03:27] <jmkasunich> and nothing prohibits a part from reading it's own outputs
[05:04:11] <zwisk> hmm.. ok. Well, is a pin that's not hooked to anything 'floating' or is it guaranteed to keep the state it wrote?
[05:04:39] <jmkasunich> for example, a counter "part" might do something like "(*output)++" to increment the counter (although it would be more robust to increment an internal value and copy it to *output
[05:05:02] <jmkasunich> with the existing scheme, it will keep the state it wrote
[05:05:33] <jmkasunich> I agree that getting rid of dummysig would be nice, cuts shmem usage in half
[05:06:50] <jmkasunich> have to look closer at that... maybe for read only and write only pins we can use global dummysigs
[05:06:55] <zwisk> yup. There is something a bit elegant about having it there too, though... I dunno... not a big deal either way I guess. Is dummysig always a long? Any thoughts of any sort of larger pin type?
[05:07:05] <jmkasunich> read/write pins would still need individual dummysigs, but they are rare
[05:07:27] <jmkasunich> so far all HAL types fit in 32 bits
[05:08:14] <jmkasunich> because on X86 machines (and most other modern machines) a 32 bit value can be read or written atomically
[05:08:47] <jmkasunich> I'd like to have double instead of float signals, but I'm not sure if doubles are read and written atomically
[05:09:10] <jmkasunich> if they're not, it can cause the kind of rare and intermittent problems that drive you crazy
[05:09:14] <zwisk> oh yeah... hmm...
[05:11:58] <zwisk> Are your btree implementations generic such that you just put a "void *left; void *right;" at the top of a struct and it'll arrange them with some typecasting, or a macro or two?
[05:12:29] <jmkasunich> here's the API in a nutshell:
[05:12:40] <jmkasunich> bbtree *bbtree_create(int(*cmp_func)(void *data1, void *data2));
[05:13:15] <jmkasunich> creates a tree... cmp_func must compare data1 and data2 and return positive, 0, or negative (like strcmp)
[05:13:24] <jmkasunich> void *bbtree_insert(bbtree *tree, void *data);
[05:13:29] <jmkasunich> puts 'datqa
[05:13:30] <jmkasunich> oops
[05:13:37] <jmkasunich> puts 'data' into the tree
[05:13:45] <zwisk> spiffy.
[05:13:48] <jmkasunich> void *bbtree_delete(bbtree *tree, void *data);
[05:13:58] <jmkasunich> removes an item matching 'data' from the tree
[05:14:05] <jmkasunich> void *bbtree_find(bbtree *tree, void *data);
[05:14:11] <jmkasunich> finds an item matching 'data'
[05:14:19] <jmkasunich> void *bbtree_first(bbtree *tree);
[05:14:24] <jmkasunich> finds first item
[05:14:32] <jmkasunich> void *bbtree_next(bbtree *tree, void *data);
[05:14:47] <jmkasunich> finds item that follows 'data' (even if 'data' itself isn't in the tree)
[05:15:01] <jmkasunich> there is also last and prev counterparts to the last two
[05:15:03] <jmkasunich> and finally
[05:15:11] <jmkasunich> void bbtree_destroy(bbtree *tree);
[05:15:24] <zwisk> I don't suppose their's any super slick way to get type casting somehow?
[05:15:35] <jmkasunich> insert and delete functions automatically balance the tree if it gets unbalanced
[05:15:52] <jmkasunich> not if you want to be generic at the same time
[05:16:02] <zwisk> Very nice and complete sounding.
[05:16:08] <zwisk> Yeah... generic and type casting... hmm.
[05:16:13] <jmkasunich> we'll have one tree with comp_t structs, one with pin_t structs, etc
[05:16:26] <zwisk> very cool.
[05:16:36] <jmkasunich> we could have wrappers like find_pin(pin_t *pin) that call the generic ones
[05:16:39] <zwisk> What do you think about putting the pin_t structs inside the comp_t structs?
[05:16:53] <jmkasunich> one comp can have any number of pins
[05:17:04] <zwisk> yup...
[05:17:13] <jmkasunich> so how do you put em inside
[05:17:40] <zwisk> uhh... I guess inside comp_t would be a "bbtree *pins;"
[05:18:11] <jmkasunich> * jmkasunich looks at hal_priv again
[05:19:01] <jmkasunich> hal_pin_t has a pointer to the component that owns the pin
[05:19:18] <zwisk> I'm really digging your bbtree concept... I'm off and running about how useful that would be in a lot of places...
[05:19:19] <jmkasunich> the hal_comp_t struct does _not_ have a pointer to the pin(s) it owns
[05:19:31] <jmkasunich> cause there can be more than one
[05:19:47] <jmkasunich> I'll be committing bbtree.h and bbtree.c sometime tonight
[05:19:51] <zwisk> one pin can be owned by more than one hal_comp_t ?
[05:19:55] <jmkasunich> nope
[05:20:08] <zwisk> ok.. so it makes sense that the pins are inside the hal_comp_t.
[05:20:18] <jmkasunich> each pin has only one owner, so a ptr to the owner is easy
[05:20:20] <zwisk> ugh... we need to resolve our terminology too.. :)
[05:20:31] <jmkasunich> but a comp can have many pins, so it can't point to all of them
[05:20:47] <zwisk> Yes, but with your b-tree, no pointer is required if the 'component/part" owns it's pins.
[05:21:03] <jmkasunich> currently the only way to find all of a comps pins is to traverse the list and look at the "owner" pointer
[05:21:04] <zwisk> your b-tree is a collection of n objects.
[05:21:34] <jmkasunich> * jmkasunich sees the light
[05:21:36] <jmkasunich> (I think)
[05:21:40] <zwisk> right... and I'm asserting that the way it is currently is backwards. You want to go from a component down to it's pins.
[05:22:18] <jmkasunich> I had been thinking of using a btree _only_ to maintain the list of _all_ pins in the system (analogus to the "next_ptr" linked list now)
[05:22:23] <zwisk> The only time you ever care about the pins and their relationship to parts (or 'libraries') is when connecting things up
[05:22:56] <jmkasunich> but we could have one btree to do that, and another one listing only the pins that belong to a the component (one btree per comp)
[05:23:20] <zwisk> I see using your btree generically for a list of all of the "modules", a list of all of the "objects/parts", a list of all the "signals", and a list of all of the pins for a specific part.
[05:23:25] <jmkasunich> well the existing way is only half backwards... sometimes you want to go one way, sometimes the other way
[05:24:08] <zwisk> true, but I'm changing the way things are named :)
[05:24:27] <jmkasunich> yeah, I was planning to use it for multiple things, but I didn't think of having one btree per comp... that's a good idea
[05:24:34] <zwisk> Instead of having fixed length strings, I'm allowing the system to enforce the hierarchy...
[05:24:51] <zwisk> so, help me out... "comp" = library, or part? I keep flipping it back in forth in my head...
[05:25:08] <jmkasunich> I'm using it in the present sense, where there is really no distinction
[05:25:43] <zwisk> Today it's a library... I guess... A big library with an arbitrary number of legs (pins)! :)
[05:25:51] <jmkasunich> we still don't know what we're gonna call them when talking with others, but for our own purposes, lets start using library and part, and drop comp
[05:26:05] <zwisk> ok. I'm good with that.
[05:26:07] <jmkasunich> library contains parts
[05:26:14] <jmkasunich> parts contain pins and params
[05:26:25] <jmkasunich> and functs
[05:27:28] <zwisk> So... libraries register with hal. The libraries register their part types with hal. Hal instructs them to create parts. Parts create pins. Pins belong to parts. Parts belong to libraries. Signals belong to hal. Parameters are like pins; created by parts. functs belong to ... libraries??
[05:27:43] <jmkasunich> functs belong to parts
[05:28:15] <jmkasunich> if you have an instance of an summer, there is a line of code somewhere like:
[05:28:21] <zwisk> right.... functs belong to parts. Is that true? Can a part of the same type have different functions for the same think? Yeah... I guess so... ok..
[05:28:37] <jmkasunich> *(part->out) = *(part->in1) + *(part->in2);
[05:28:44] <jmkasunich> gotta execute that at the proper time
[05:28:52] <jmkasunich> that line of code is the funct for the summer
[05:29:21] <jmkasunich> there can be more than one funct for one part
[05:29:24] <jmkasunich> for instance, a parport
[05:29:50] <jmkasunich> one funct reads the input bits, you would execute that near the beginning of the thread... the other funct writes the outputs, and would execute near the end of the thread
[05:30:25] <zwisk> sure... But can part "parport1" and part "parport2" which are both parallel ports of the same type from the same module have different functions?
[05:30:39] <jmkasunich> they will have different instances of the same function
[05:30:59] <jmkasunich> calling parport.1.read will read port 1, parport.2.read will read port 2
[05:31:14] <jmkasunich> same code, but it gets passed different args so it reads different ports
[05:31:14] <zwisk> OK. If it's different instances, then the functions belong in the definition of the "part type" and belong to the library, not the individual part itself...
[05:31:39] <jmkasunich> ummmm... I'm not sure I understand you
[05:31:54] <jmkasunich> the "create" function is called for each instance,
[05:31:59] <jmkasunich> and will export pins for that instance
[05:32:10] <jmkasunich> it will also export a funct(s) for that instance
[05:32:31] <jmkasunich> both pins and funct(s) will belong to the instance, not the library or parttype
[05:33:09] <zwisk> yes... create is called for each instance. But the instance that is created doesn't need to have functions associated directly with it. It only needs to know that it's of type "summer" and a "summer" takes these 5 functions... the functions themselves are not different like the pins are. The pins are data, which are unique per part, but the functions are the same for any 2 parts of the same type.
[05:33:33] <jmkasunich> the _code_ is the same
[05:33:51] <jmkasunich> but suppose you have one summer adding two signals that are updated in the servo thread at 1mS
[05:34:05] <zwisk> ok...
[05:34:07] <jmkasunich> and another summer adding two signals that are updated every 10mS in the traj thread
[05:34:18] <jmkasunich> and a third that adds the outputs of the other two
[05:34:39] <jmkasunich> you need to execute the first and third ones in the 1mS thread
[05:34:45] <jmkasunich> and the second one in the 10mS thread
[05:34:48] <zwisk> sure... but now you're talking about threads, right? The threads need to work on a specific part, but they'll call the functions for the part's type, not the part itself. (We do need pictures.)
[05:34:57] <jmkasunich> and you need to make sure the third one runs after the first one
[05:35:25] <jmkasunich> yeah, we need pictures
[05:35:29] <zwisk> yup. (Is the concept of a function and a thread bound into one unit in rtai? maybe that's the concept I'm abusing.)
[05:35:48] <jmkasunich> a function is just a normal C function
[05:36:19] <zwisk> ok... so the library will have code that implements the functions for each of iut
[05:36:24] <jmkasunich> a HAL thread contains (and executes) any number of functions, in a user specified order, and at a specific repetition rate
[05:36:25] <zwisk> doh... ' vs return ...
[05:37:43] <zwisk> the library has functions for each type of part it knows how to create. When it registers it's ability to create those parts, it can register the functions that it has available for each type of part. When it creates a specific part (of a particular type) it need not associate functions directly with that part, as the system already knows the functions to use for that part type.
[05:37:49] <jmkasunich> hal_parport.c:440
[05:38:21] <zwisk> Threads need to be set up to call those functions for the specific part in the right order and with the right arguments, but that's seperate...
[05:38:39] <zwisk> read_port (440) ... ok ...
[05:38:50] <jmkasunich> that's the execution part of the HAL (functs & threads) where pins and signals are the data part
[05:39:31] <jmkasunich> read_port is called with arg pointing to a parport_t struct that is unique to a specific instance
[05:39:53] <jmkasunich> which results it it reading only _that_ parport
[05:39:53] <zwisk> yes...
[05:40:03] <zwisk> sure.
[05:40:48] <jmkasunich> if you have two parports, then "show funct" will show two read functions, one for each port
[05:40:54] <zwisk> but that *arg is standard. *Every* function takes an *arg* which is standardized across all hal, right? *arg is just the part structure that was created when hal told the library to create a part.
[05:41:25] <jmkasunich> line 240
[05:41:56] <jmkasunich> the third arg passed to export_funct is what is later passed to read_port as "arg"
[05:41:57] <zwisk> yes, but we'll never say register "read_port_usb" to the object "pport" and register "read_port_serial" to "pport2" without pport and pport2 being different types.
[05:42:47] <zwisk> hmmm. so you really do have functions bound to the instance. Hmmm..
[05:42:53] <jmkasunich> agreed, I think... the C function that is passed as the second arg of export_funct() will be the same for all instances of a part
[05:43:01] <jmkasunich> but the third arg will be different
[05:43:38] <zwisk> sure. But if a particular part has 10 functions, all 10 functions for that part will take the same argument as well,right? (They don't have to the way thing are, but I can't imagine them not all being the same.)
[05:44:03] <jmkasunich> right
[05:44:19] <zwisk> So all we have to keep for each part is the argument.
[05:44:21] <jmkasunich> ultimately it's up to the writer of the module/library/part
[05:44:33] <zwisk> Each part_type can have the list of functions to call with that argument.
[05:44:58] <jmkasunich> look at the hal_funct_t struct in hal_priv.h
[05:45:06] <zwisk> yeah... ok ... Your way uses more memory, but is more flexible.
[05:45:39] <zwisk> ok... hal_funct_t
[05:45:50] <zwisk> change owner_ptr right away to point to the part, not the library.
[05:45:59] <jmkasunich> right
[05:46:11] <jmkasunich> there is one of these for each instance of a function
[05:46:22] <jmkasunich> an instance of a function is bound to an instance of a part
[05:46:54] <jmkasunich> probalby the only fields needed on a per instance basis are:
[05:46:56] <jmkasunich> owner
[05:46:59] <jmkasunich> arg
[05:47:03] <jmkasunich> funct
[05:47:09] <zwisk> yes... It is now. But that's because the thread is also wrapped in hal_funct_t as well, right? (runtime and maxtime define thread attributes)
[05:47:29] <jmkasunich> actually runtime and maxtime apply to this function instance only
[05:47:47] <jmkasunich> waitaminnit
[05:47:48] <zwisk> yes. absolutely.
[05:47:53] <jmkasunich> I'm forgetting my own code
[05:48:09] <zwisk> (I do that all the time... forget my code...)
[05:48:21] <jmkasunich> the structure can be improved...
[05:48:35] <zwisk> excellent thing to hear when doing a refactor! :)
[05:48:55] <jmkasunich> one "feature" of the existing design is that a function can be called from more than one thread, or multiple times from the same thread
[05:49:10] <jmkasunich> I know of no reason why somebody would actually want to do that
[05:49:28] <zwisk> there may be some insane ordering situations where that could be beneficial.
[05:49:35] <jmkasunich> I have my doubts
[05:49:48] <zwisk> (me too, actually, but ... who are we?! :) )
[05:50:01] <jmkasunich> anyway... each call to export_funct() creates one funct_t struct
[05:50:16] <jmkasunich> creating a thread creates one thread_t struct
[05:50:43] <jmkasunich> when you do an "addf <function> <thread>", you create a funct_entry_t struct
[05:51:09] <zwisk> ooh... hal_list_t funct_list can be your btree again..
[05:51:24] <jmkasunich> all functions in the thread are linked thru the links field of the funct_entry_t, and the funct_list field of the thread_t
[05:51:49] <jmkasunich> meanwhile the funct_entry is linked back to the exported function thru the funct_ptr field of the funct_entry struct
[05:52:05] <jmkasunich> there is also some reduncancy for speed reasons
[05:52:21] <jmkasunich> when executing the thread, the code starts at thread_t->funct_list
[05:52:32] <jmkasunich> traverses the list of funct_entry_t's
[05:53:11] <jmkasunich> the code could execute *(list->funct_ptr->funct)
[05:53:33] <jmkasunich> but list->funct_ptr is one of those annoying offset things
[05:53:34] <jmkasunich> slow
[05:53:43] <jmkasunich> so instead it does list->funct
[05:54:11] <zwisk> right.. but with the kernel doing all that, it doesn't need to be in shared memory, right?
[05:54:11] <jmkasunich> a funct_entry_t->funct is exactly the same as the corresponding funct_t->funct
[05:54:36] <jmkasunich> right... so we make reduce funct_entry_t smaller
[05:55:05] <jmkasunich> arg and funct can go away
[05:55:16] <jmkasunich> and funct_ptr can become a real pointer instead of an offset
[05:55:29] <zwisk> woohoo!
[05:56:26] <jmkasunich> now that I think about it - NOTHING in the funct/thread API needs to be in shared memory (except possibly the performance monitoring stuff (runtime and maxtime)
[05:56:42] <zwisk> woohoo again!
[05:57:46] <jmkasunich> right now, runtime and maxtime are params, just like any other... I like that cause you can use halscope or halmeter to monitor them, but they will also clutter up listings
[05:58:34] <jmkasunich> I wonder if they should be a different kind of object
[05:58:51] <jmkasunich> we can worry about that later
[06:00:13] <zwisk> I'm about to call it a night I think...
[06:00:30] <jmkasunich> ok
[06:00:38] <jmkasunich> isn't it only around 10pm there?
[06:00:50] <zwisk> yup... but I got a hot tub with my name on it :)
[06:00:58] <jmkasunich> and a girl in it?
[06:01:14] <zwisk> (ANd while I do have a waterproof keyboard now, I haven't quite figured out how to get the monitor out there...)
[06:01:32] <zwisk> well, yeah, probably a girl too... but tonight the girl is married, so ... no go there. :) Tomorow night may be more interesting :)
[06:01:52] <jmkasunich> well enjoy...
[06:02:19] <jmkasunich> tonight's probably the only night I'll get to stay up for the next few days
[06:02:34] <jmkasunich> I'm gonna get this btree thing converted and hopefully tested tonight
[06:02:38] <zwisk> ok... I'll look for the btree! :)
[06:02:41] <zwisk> cool
[06:02:49] <jmkasunich> question
[06:03:02] <jmkasunich> back when I wrote it I called it BTREE
[06:03:09] <jmkasunich> (used upper case alot then)
[06:03:19] <jmkasunich> now I'm calling it bbtree (balanced binary)
[06:03:26] <jmkasunich> should I drop one b?
[06:04:00] <zwisk> I dunno... I'm horrible with names, and even self-referentially inconsistent! :) bbtree seems fine. Not likely to collide with anything someone else has written.
[06:04:13] <jmkasunich> right
[06:04:15] <jmkasunich> bb it is
[06:05:30] <zwisk> g'night!
[06:05:34] <jmkasunich> goodnight
[06:06:33] <gezr> night zwisk
[06:06:43] <gezr> or jmkasunich
[06:06:49] <gezr> ive been cleaning
[06:06:55] <gezr> you guys have been busy as well :)
[06:07:11] <jmkasunich> yep, coding away
[06:07:30] <gezr> I wish I was on that level, in time :)
[06:11:21] <gezr> im pretty sure im 90% finished with the cleaning
[06:19:15] <A-L-P-H-A> gezr, what are you cleaning?
[06:19:34] <gezr> my whole shop
[06:19:41] <gezr> been tossing out ould stuff
[06:19:51] <gezr> moving stuff around
[06:20:44] <gezr> I made room on my shelves so I can more readly work with the bike
[06:21:37] <gezr> i have maybe 40lbs of stuff on a few chairs, and then some odds and ends to sort through
[06:22:58] <gezr> im going to rest the rest of the night I think, ill finish the rest of stuff I can do in the morning, and then I can start working with the head, gonna try my hand at lapping valves in
[06:23:56] <gezr> then I dont really have to much to do I dont guess, more blasting and assembly
[06:26:42] <A-L-P-H-A> sounds like fun
[06:26:46] <A-L-P-H-A> what kind of bike?
[06:29:00] <gezr> bmw k100
[06:33:58] <A-L-P-H-A> I only see a picture from 1985 model.
[06:36:12] <gezr> good, then you know what mine looks like :)
[06:37:36] <gezr> mine was an rt then after an accident it became an rs sorta, then after the fire and neglect it became a dust magnet
[06:37:51] <gezr> now its being reborn
[06:39:00] <gezr> im pretty sure its comming up on its 20th birthday
[06:39:20] <gezr> not exactly sure what month my dad purchased it in,
[06:41:18] <gezr> any of you guys watch adult swim on cartoon network?
[07:03:34] <gezr> ill catch you guys later
[08:40:44] <zwisk> jmk, how goes that bbtree code? :)
[08:49:04] <jmkasunich> seems to be working
[08:49:28] <jmkasunich> the balancing isn't as good as I expected (but still far better than an unbalanced list)
[08:49:45] <jmkasunich> a list with 10000 items will be a maximum of 18 levels deep
[08:50:10] <jmkasunich> which would happen only with a particular rather pathalogical insertion order
[08:50:19] <jmkasunich> if perfectly balanced, it would be 12 levels deep
[08:50:37] <jmkasunich> inserting the items in sorted order would give 13 levels
[08:50:45] <zwisk> how do you mean balancing isn't as good as you expected? You are doing the rotations and... oy... it's been a while... red/back balanced trees?
[08:50:58] <jmkasunich> inserting the items in sorted order into an unbalanced tree would give you a tree 10000 levels deep
[08:51:25] <jmkasunich> it's beem a while for me too - I derived this stuff back in 1994
[08:51:57] <jmkasunich> but yes, I'm doing "rotations" if that's what they're called
[08:52:32] <jmkasunich> if the max depth on one side of a node is more than +/- 1 from the max depth on the other side of the node, re-organize things so they are the same
[08:53:24] <jmkasunich> did you mean "red/black" balanced trees?
[08:53:43] <zwisk> Yeah, I think I did...
[08:53:48] <zwisk> but it may be avl tree's I'm thinking of...
[08:53:50] <zwisk> http://www.cs.oberlin.edu/classes/dragn/labs/avl/avl5.html
[08:55:11] <jmkasunich> well I'll be damned
[08:55:21] <jmkasunich> those AVL trees are exactly what I did
[08:55:44] <jmkasunich> but I never heard or read about them before... I derived it on my own in 1994
[08:56:04] <zwisk> very nice! :) You've recreated a lab from... I dunno ... some undergraduate cs class?
[08:56:11] <jmkasunich> probably
[08:56:49] <jmkasunich> I wonder if my method is as efficient as theirs
[08:56:55] <zwisk> Yeah, I think there's an optimal algorithm for 'rotating' left and right to get a balanced tree.
[08:57:32] <zwisk> There's probably a good number of AVL implementations out there to check your against as well.
[08:58:05] <jmkasunich> in other words, theres probably an implementation out there that I could have used instead of doing it from scratch
[08:58:17] <jmkasunich> of course, in 1994 finding it was alot harder - no google
[08:58:47] <zwisk> absolutely.
[08:58:55] <jmkasunich> their algorithm is probably better than mine - they perform only one rotation per insertion or deletion
[08:59:07] <zwisk> There was a "structures" book I had once that covered these extensively. I don't know who wrote it off hand.
[08:59:15] <jmkasunich> I traverse the tree from top to bottom, and can potentially make a rotation at each level
[08:59:34] <jmkasunich> don't know if it actually does more than rotation though
[09:00:02] <zwisk> in theory, a properly balanced avl tree is (iirc) optimal.
[09:01:09] <jmkasunich> a perfectly balanced tree is 1.00*log(n), an AVL tree is worst cast 1.44*log(n) (best case 1.0*log(n))
[09:01:16] <jmkasunich> same order, just the constant changes
[09:01:50] <zwisk> ok...
[09:03:01] <jmkasunich> I wonder if I should rename bbtrees to avltrees?
[09:04:19] <zwisk> it's still balanced binary ;)
[09:04:43] <jmkasunich> yep, but if the rest of the world calls 'em avl...
[09:04:52] <jmkasunich> search and replace would make quick work of it
[09:05:24] <jmkasunich> once I commit then the filenames are frozen - the contents could be changed, but it's awkward to rename a file in CVS
[09:06:12] <zwisk> indeed.
[09:06:18] <zwisk> I wish we were using subversion ;)
[09:17:59] <CIA-5> 03jmkasunich 07halrefactor-0-1 * 10emc2/src/hal/ (avltree.c avltree.h Makefile): added an implementation of AVL balanced binary trees, to be used to manage object lists in the refactored HAL
[09:21:42] <jmkasunich> on that note... I'm off to bed (4:30 here)
[09:21:51] <zwisk> wow... 'gnight!
[09:23:11] <jmkasunich> oops - one small mistake to fix first
[09:31:15] <CIA-5> 03jmkasunich 07halrefactor-0-1 * 10emc2/src/hal/avltree.c: corrected an error in setting the tree depth, renamed some defined and enum symbols
[09:31:23] <jmkasunich> goodnight'
[10:25:35] <Imperator_> Imperator_ is now known as Imperator_away
[11:40:14] <alex_joni> * alex_joni waves
[11:47:37] <alex_joni> no one around?
[11:48:01] <jf353> here I am
[11:51:25] <alex_joni> hello... don't think we've met before
[11:53:04] <jf353> yes
[11:53:47] <alex_joni> I'm from Romania, and I plan to use EMC for a plasma cutter (god knows when that's gonna happen)
[11:54:21] <jf353> I am from Germany and I am looking for a stable kernel/distribution
[11:54:34] <alex_joni> RT-enabled?
[11:54:43] <jf353> with RTAI
[11:54:53] <alex_joni> did you try the latest BDI ?
[11:55:11] <jf353> just reading: IRC-chat-2004-12-05.txt
[11:55:16] <jf353> no
[11:56:44] <alex_joni> well.. the BDI is the way to go if you want a fast install
[11:56:47] <alex_joni> with support ;)
[11:57:11] <alex_joni> other than that... you can choose your favorite distribution, patch a kernel, compile, install
[11:57:20] <alex_joni> and everything _should_ work...
[11:57:33] <alex_joni> but most of the time you run into smaller/greater problems
[11:57:59] <alex_joni> my EMC runs on SuSE 8.2 (2.4.21 & RTAI-3.0r4)
[11:58:12] <jf353> Thats interesting
[11:58:40] <jf353> because I use suse
[11:59:24] <jf353> maybe we can email: [email protected]
[12:00:02] <alex_joni> [email protected]
[12:00:13] <alex_joni> you can write in german if that suits your need better
[12:00:15] <alex_joni> ;-)
[12:01:00] <jf353> thanks very much
[12:01:50] <alex_joni> * alex_joni remembers the whole fuss it was to get EMC going the first time...
[12:02:04] <alex_joni> but once you did it... it's getting easier each time
[12:02:55] <jf353> jf353 away from keybord for a break
[12:07:44] <alex_joni> * alex_joni 'll be back later
[14:56:14] <alex_joni> jf353: say when around...
[14:57:35] <jf353> Hello
[14:59:10] <alex_joni> I just wanted to respond to your mail.. but it's easier like this
[14:59:15] <alex_joni> with feedback ;)
[14:59:51] <alex_joni> I'm sorry but I can't seem to find the documentation I wrote to document the whole process.. but I'll tell you what I remember
[15:00:05] <jf353> Yes that would be nice
[15:00:20] <alex_joni> ok... so, what SuSE do you have installed?
[15:01:00] <jf353> different: suse82 on my server, other pc's with 9.0 and 9.2
[15:01:21] <alex_joni> * alex_joni knows 8.2, didn't try 9.x yet
[15:01:36] <alex_joni> on 8.2 there is 2.4.21 (or 20) don't remember exactly
[15:01:37] <jf353> suse82 is ok for me
[15:01:56] <alex_joni> 9.2 should have 2.6... I think
[15:02:09] <alex_joni> anyways.. you could install any kernel on any of those
[15:02:30] <alex_joni> but _might_ get into trouble if modutils or other kernel-utilities are incompatible
[15:02:50] <alex_joni> 2.6 and 2.4 have different type modules and loading options..
[15:03:09] <alex_joni> my advise: download the same kernel your SuSE is running (same version)
[15:03:15] <jf353> I do not need really a a 2.6 kernel, but something stable!
[15:03:23] <alex_joni> make sure you download it from www.kernel.org
[15:03:31] <alex_joni> not the SuSE kernel included on the CD's
[15:04:19] <jf353> yes I know, on 9.0 the scheduler is exchanged and the rtai patches dont not fit
[15:04:20] <alex_joni> the main reason for that is that the kernel on the CD includes some patches by SuSE, and you'll get in trouble later when patching with RTAI
[15:04:30] <alex_joni> yes
[15:05:01] <alex_joni> you would want to get the same version (or similar) in order to use the SuSE config file for the kernel (if you don't want to manually configure all your kernel)
[15:05:18] <alex_joni> although that would be a somehow better solution...
[15:05:33] <jf353> Do you remember some of the difficulties with suse80?
[15:05:42] <alex_joni> 8.2 is what I have
[15:05:48] <alex_joni> some I remember:
[15:06:20] <alex_joni> the main problem I had was to figure out how to make the initrd image (had never done that before)
[15:06:43] <alex_joni> that image is used to contain some kernel modules that need to be loaded before the complete boot
[15:06:58] <alex_joni> one driver I had to include there was the reiserFS module
[15:07:27] <alex_joni> if I didn't put it in the ramdisk the kernel could not mount the HDD, and the booting stopped...
[15:07:50] <alex_joni> but I figured that out after a while...
[15:08:08] <alex_joni> another solution is to build reiserFS support into the kernel (not module)
[15:08:25] <alex_joni> but this more or less depends on your hardware, and what you need...
[15:09:00] <anonimasu> hello
[15:09:00] <jf353> I use reiserfs with good experiences.
[15:09:32] <alex_joni> I agree, I also like reiserfs
[15:09:45] <alex_joni> but you need to make sure that the kernel can access your harddisk
[15:09:56] <anonimasu> hm, redefining your pinouts should work as supposed to in the config.. right?
[15:10:38] <alex_joni> if you build reiserfs as a module (located in /lib/modules/.../reiser.o) the kernel needs to read it from there
[15:10:58] <alex_joni> in order to read it, the kernel has to have some reiserFS capabilities.. right?
[15:11:12] <anonimasu> yes
[15:11:17] <alex_joni> so you either include the reiserfs on an ramdisk (initrd), or compile it into the kernel
[15:11:29] <alex_joni> anonimasu: what do you mean?
[15:11:51] <alex_joni> about the pinouts?
[15:11:54] <anonimasu> alex_joni: I didn STEP_INDEX=1 in my config file, but it seems that emc wont use that pin for step..
[15:12:04] <alex_joni> emc1 ?
[15:12:10] <anonimasu> the one on the bdi cd..
[15:12:26] <anonimasu> most likely emc1
[15:12:27] <alex_joni> bdi-4.08 ?
[15:12:49] <alex_joni> I mean this last BDI?
[15:12:49] <anonimasu> yeahyes
[15:12:52] <anonimasu> yes
[15:12:58] <anonimasu> downloaded it yesterday
[15:13:01] <alex_joni> oh.. ok... don't really know
[15:13:04] <anonimasu> :/
[15:13:09] <alex_joni> * alex_joni didn't get a chance to try it out
[15:13:27] <alex_joni> I know that paul_c added support for the pin configuration from the INI-file
[15:13:33] <alex_joni> but I haven't seen the code so far
[15:13:36] <alex_joni> :(
[15:13:40] <alex_joni> hi ray
[15:13:54] <anonimasu> they are in the emc.ini atleasy.. however it dosent seem like it works...
[15:14:05] <alex_joni> I think they should work
[15:15:11] <anonimasu> hm, I'll be back in a bit going to mess some more with it..
[15:15:24] <alex_joni> I'll look over it while you're gone
[15:15:31] <alex_joni> any luck with the feedback?
[15:16:48] <anonimasu> I still havent got the machine running due to this :/ so I havent had any chance to look at it while cutting
[15:19:02] <alex_joni> ahh.. ok ;)
[15:21:33] <rayh> Hi Alex. Sorry phone interuption.
[15:25:38] <rayh> Have we started conversations yet?
[15:33:05] <anonimasu> hm.. still wont work..
[15:33:36] <anonimasu> I'll be further away from testing it out then, since I need to order new connectord and make another cable..
[15:36:07] <alex_joni> rayh: did you try pin asignment from emc.ini ?
[15:37:07] <alex_joni> not much discussion yet...
[15:39:47] <rayh> I haven't tried it yet.
[15:40:15] <rayh> I've not compiled in a couple weeks. Is it in 4.08?
[15:42:42] <alex_joni> I think so, it's not in the emc1 CVS
[15:43:48] <alex_joni> it is in emc2 CVS, under pc_2_6_test (I think)
[15:43:55] <alex_joni> because it's an libnml based emc1 ;)
[15:44:49] <alex_joni> nope ... can't seem to see it there either .. anyways
[15:45:16] <rayh> I didn't see any references to it in the ini's in 4.08.
[15:46:56] <alex_joni> anonimasu said something about STEP_INDEX=1
[15:48:09] <alex_joni> * alex_joni has seen a lot of work from zwisk and jmk
[15:48:14] <alex_joni> on the HAL-refactor
[15:48:19] <rayh> Would this be in each axis definition.
[15:48:25] <alex_joni> don't know
[15:48:37] <alex_joni> * alex_joni defers the question to anonimasu
[15:49:39] <alex_joni> I talked a little to jf353
[15:49:54] <alex_joni> he's a german user, interested in patching a SuSE for realtime...
[15:50:14] <rayh> Certainly that should be possible.
[15:50:22] <alex_joni> * alex_joni has done it a few times ;)
[15:50:33] <alex_joni> but there are some small issues on the way...
[15:50:39] <rayh> The newer SuSE uses the 2.6 kernel.
[15:50:52] <alex_joni> didn't touch 2.6 yet
[15:51:35] <alex_joni> but it seems it becomes more and more neccessary ;)
[15:54:52] <alex_joni> * alex_joni thinks about IO-control for EMC2
[15:56:35] <alex_joni> I think that's a part that's still missing in EMC2
[15:56:40] <rayh> Something like classicladder?
[15:58:13] <alex_joni> I'm just looking into it
[15:58:36] <alex_joni> on emc1 there's minimill and bridgeport
[15:58:53] <alex_joni> was this left out in order to build in a PLC-controller?
[16:00:04] <rayh> The first PLC was written in C for a test.
[16:00:19] <rayh> It was never generalized.
[16:00:45] <rayh> So when Matt needed to run a bridgeport, they wrote bridgeport io.
[16:01:01] <anonimasu> yes
[16:01:04] <anonimasu> it's for each axis..
[16:01:08] <alex_joni> I see... so what would be the way to go?
[16:01:18] <rayh> The minimill to fit the little mill they had at NIST.
[16:01:33] <rayh> We need a general io program system.
[16:01:53] <rayh> I thought classicladder could do a lot of it,
[16:02:10] <anonimasu> I defined step and dir for each axis, as done in emc.ini
[16:02:28] <anonimasu> I even tried using emc.ini and just changing the pins.. to match mine..
[16:03:57] <anonimasu> alex_joni: if that's missing from emc2 I am running emc1
[16:04:02] <alex_joni> rayh: I agree on the long term
[16:04:13] <alex_joni> anonimasu: the stuff in BDI-4.08 is emc1
[16:04:32] <alex_joni> and I can see the emc.ini containing that parts you say
[16:04:43] <alex_joni> what pins did you use?
[16:04:45] <cradek> rayh: I hacked bridgeportio for my machine to allow you to select an emulated IO pin or actual parport IO pin for each bit in the ini
[16:05:09] <alex_joni> rayh: but for startes a minimill connected to hal would be ok
[16:05:20] <alex_joni> even bridgeport connected to hal
[16:05:29] <cradek> rayh: my machine has estop and spindle-forward as actual bits (above the step/dir outputs) but emulated bits for everything else
[16:05:50] <alex_joni> and the stuff you don't use (the user does not use) simply don't get connected, or get connected to default values
[16:06:00] <rayh> cradek: Matt and I did a similar thing for Smithy.
[16:06:30] <cradek> rayh: I can't decide whether I should check it in.
[16:07:08] <cradek> it's very simple. bits -n..-1 are emulated, bits 0..n are the parport
[16:07:42] <rayh> * rayh needs to work on food for a bit. Back in a few.
[16:07:59] <anonimasu> alex_joni: dont have the paper here right now
[16:08:12] <anonimasu> but it's the same pins i've been running when I ran turbocnc..
[16:08:36] <anonimasu> wait..
[16:09:04] <anonimasu> 2 & 8 and 7 & 5 and 3 & 6
[16:09:06] <alex_joni> cradek: what does bridgeportio do besides setting a few pins on/off ?
[16:09:21] <alex_joni> anon: make sure those aren't used elsewhere
[16:09:55] <alex_joni> one single problem
[16:09:57] <anonimasu> alex_joni: they arent used elsewhere.. and still changing the values in the config should make a difference..
[16:09:59] <alex_joni> looking at emc.ini
[16:10:01] <anonimasu> .)
[16:10:06] <alex_joni> for X there are used 0&1
[16:10:20] <alex_joni> that means D0 & D1 (pin 2 & 3 on the parport)
[16:10:41] <alex_joni> so you'll need 0 & 6 (for pin 2 & 8)
[16:11:08] <anonimasu> ah that might be the problem then
[16:11:14] <alex_joni> 0&6, 5&3, 1&4
[16:11:42] <anonimasu> I need to run, going to look at it when I get back..
[16:11:44] <anonimasu> thanks :)
[16:12:32] <alex_joni> you're welcome
[16:12:38] <alex_joni> cradek: around?
[16:19:45] <anonimasu> I'll be testing it as soon as I get back :)
[16:22:12] <alex_joni> cradek: when you'll be back, maybe we can talk about it...
[16:26:36] <alex_joni> meep?
[16:26:38] <robin_sz> meep?
[16:26:43] <robin_sz> :)
[16:26:45] <alex_joni> * alex_joni was faster
[16:26:45] <alex_joni> :D
[16:26:52] <alex_joni> hi robin
[16:27:21] <gezr> morning yall
[16:27:46] <robin_sz> hi
[16:30:24] <alex_joni> what's up robin?
[16:34:05] <cradek> alex_joni: I'm back now
[16:34:20] <alex_joni> got time/nerve to talk about IO control?
[16:34:34] <cradek> you're assuming I know something about it
[16:34:41] <cradek> I have a little time
[16:34:49] <alex_joni> well.. I don't know much myself
[16:35:02] <alex_joni> but I don't think it can be too tough
[16:35:12] <cradek> I don't think it is
[16:35:55] <alex_joni> anyways... I was wondering if I started (and I just did) to make a miniIoControl
[16:36:04] <alex_joni> which only exports some HAL-pins
[16:36:13] <alex_joni> and sets those accordingly to NML-messages
[16:36:20] <alex_joni> I think that would be enough to be used
[16:36:38] <cradek> sounds like
[16:36:45] <robin_sz> for IO to be 'adaptable' ...
[16:37:10] <robin_sz> you need to be able to assign an arbitary command to a IO pin
[16:37:18] <cradek> can you link a HAL pin to a C variable?
[16:37:23] <robin_sz> (via some intermediate hal logic)
[16:37:37] <alex_joni> you have a function which sets the pin
[16:37:49] <alex_joni> and that function read the variable and sets the value
[16:37:58] <alex_joni> s/read/reads/
[16:38:13] <cradek> sounds pretty simple
[16:38:30] <alex_joni> it should be
[16:38:31] <robin_sz> almost ... but we;re screwed by the nml messages
[16:38:40] <alex_joni> why is that robin?
[16:38:44] <robin_sz> because ...
[16:38:49] <cradek> they're fixed
[16:39:19] <robin_sz> if I want to add a new message ... how can I, *without* recompiling emc and a weeks worth of hacking?
[16:39:33] <cradek> but the g-code is fixed too
[16:39:40] <cradek> we're only as screwed by NML as we are by g-code
[16:39:53] <robin_sz> NML is the core problem,
[16:40:00] <alex_joni> what message would you wanna add?
[16:40:08] <robin_sz> spindle wibble
[16:40:19] <alex_joni> and a GUI button for it?
[16:40:34] <robin_sz> possibly, and a Gcode to drive it
[16:40:46] <alex_joni> seems you still have to hack a few places
[16:40:47] <cradek> and you want to do that without hacking and recompiling?
[16:40:53] <robin_sz> lots of places
[16:40:58] <alex_joni> Interpreter, GUI, NML, etc
[16:41:01] <robin_sz> cradek: absolutely
[16:41:14] <cradek> sorry, but I don't think that's reasonable
[16:41:23] <alex_joni> robin: too good to be ever true ;)
[16:41:33] <robin_sz> oh, I'll stick with mach2 then
[16:41:37] <alex_joni> * alex_joni favors executable GUIs
[16:41:51] <alex_joni> and you need to recompile those when you add a button
[16:42:12] <robin_sz> so ... how come others manage it then?
[16:42:32] <alex_joni> don't know ;)
[16:42:42] <alex_joni> but.. how often do you do that?
[16:43:02] <robin_sz> lets try "everytime you install a new machine"
[16:43:02] <alex_joni> does it really pay off to reimplement the way of things, only to make it more flexible
[16:43:12] <alex_joni> and then use it once or twice?
[16:43:28] <robin_sz> once or twice?
[16:43:30] <alex_joni> not that sure robin, that every machine needs custom buttons
[16:43:48] <robin_sz> ok, perhaps Im unlucky in all of mine needing that
[16:43:57] <gezr> mine do
[16:44:01] <alex_joni> can you give me some examples?
[16:44:16] <gezr> every comercial machine ive been involved with has had a customization added
[16:44:21] <robin_sz> perhaps we should rename it to "enhanced bridgeport look-alike controller" :?
[16:44:46] <gezr> robin_sz : what are you talking about?
[16:44:59] <robin_sz> alex_joni: sure,. plasma on, torch up, torch tip touch? any more
[16:45:15] <robin_sz> alex_joni: and what about if I want to cnc a press brake?
[16:45:20] <alex_joni> plasma on you can do with G43 (if I remember it right)
[16:45:27] <robin_sz> alex_joni: does emc have ANY signals for that? no.
[16:45:29] <gezr> robin_sz : I get it, yeah your right
[16:45:39] <alex_joni> I agree on the CNC brake...
[16:45:49] <robin_sz> so ...
[16:45:50] <alex_joni> but only because I don't know what signals are needed there
[16:45:51] <alex_joni> :D
[16:45:55] <robin_sz> so ...
[16:46:01] <alex_joni> so... ;)
[16:46:11] <robin_sz> have a file that links integers to IO functions
[16:46:24] <robin_sz> 01 spindleOn
[16:46:31] <robin_sz> 02 spindleOff
[16:46:33] <alex_joni> integers as in G-variables?
[16:46:40] <robin_sz> 03 coolantOn
[16:46:43] <A-L-P-H-A> robin_sz, there are m-codes for those.
[16:47:02] <robin_sz> A-L-P-H-A: no there iarent
[16:47:03] <gezr> m-codes are machine codes defined by the manufacture
[16:47:17] <A-L-P-H-A> oh.
[16:47:25] <gezr> they tend to always be the same but do not have to follow any particular standard
[16:47:28] <A-L-P-H-A> well... there are m-codes in turbocnc that does all those...
[16:47:37] <robin_sz> A-L-P-H-A: probably
[16:47:47] <A-L-P-H-A> spindle-on-CCW, spindle-on-CW, coolant A, coolantB, coolantsOFF
[16:47:52] <A-L-P-H-A> spindle off.
[16:48:01] <cradek> emc has those too, of course
[16:48:04] <robin_sz> no use to me at all on a am,chine without a spindle
[16:48:20] <A-L-P-H-A> cradek, if there are, then why is robin_sz tellming there isn't?
[16:48:23] <robin_sz> cradek: does it have laserGasReflowControlHigh?
[16:48:34] <cradek> A-L-P-H-A: no idea.
[16:48:43] <robin_sz> cradek: does it have laserGasReflowControlLow
[16:48:46] <gezr> robin_sz : does mach5?
[16:48:50] <cradek> robin_sz: what use to me is that on my mill?
[16:49:03] <gezr> i dont know much about mach5
[16:49:08] <cradek> robin_sz: is it necessary to have this argument before alex_joni works on spindle-forward and estop in emc2?
[16:49:10] <robin_sz> cradek: sorrry, is this thing a mill controller or a generic CNC?
[16:49:17] <alex_joni> cradek: robin talks about a way to be able to add those simply
[16:49:20] <cradek> surely we all agree estop is useful and it would be nice if it worked.
[16:49:31] <cradek> and, there should be a framework for digital IO
[16:49:37] <cradek> in case one of you wants to work on extending it.
[16:49:38] <alex_joni> cradek: I'll limit myself to estop for now...
[16:49:43] <alex_joni> how about that?
[16:49:43] <alex_joni> :D
[16:49:46] <A-L-P-H-A> * A-L-P-H-A is it just me... or does some members of this conversation seem very passionate about the debate.
[16:49:55] <gezr> robin_sz : what your talking about is a "base" that a face could be put on top pending configuration
[16:49:58] <alex_joni> passionate is good
[16:50:09] <gezr> A-L-P-H-A
[16:50:10] <gezr> oops
[16:50:19] <gezr> A-L-P-H-A : to some emc puts food on the table
[16:50:23] <robin_sz> what is needed is to link a button to a message
[16:50:46] <alex_joni> robin: what if you'd have say 20 unused messages
[16:50:51] <A-L-P-H-A> gezr. true. I've got no issue with EMC. just that I haven't used it to my machine yet.
[16:50:52] <alex_joni> build already into emc
[16:50:57] <alex_joni> all going to HAL
[16:51:06] <alex_joni> and you simply link a button to usermsg01
[16:51:08] <robin_sz> why twenty?
[16:51:21] <alex_joni> and usrmsg01 to a HAL->parport.0.15
[16:51:22] <robin_sz> why not 255 and by defualt none of them assigned to anyting?
[16:51:24] <A-L-P-H-A> turbocnc CNC still does all that I need... and probably could for all intended purposes.
[16:51:31] <alex_joni> 20 as an example
[16:51:32] <A-L-P-H-A> all future
[16:51:35] <alex_joni> 255 also ok
[16:51:46] <alex_joni> 255 NML messages (not used by default)
[16:51:46] <robin_sz> soemwhere you have a spec file ...
[16:51:52] <gezr> robin_sz : so whats needed then is a fully generic startup, that when the thing is first ran, all parameters of the machine are set up via a fancy graphics, and the machine is then set at that point right?
[16:51:57] <A-L-P-H-A> though learning and using EMC would be just fun.
[16:52:02] <robin_sz> allocates message names to a integer say
[16:52:13] <alex_joni> besides those that are used normaly (estop, spindel, coolant, lube, etc)
[16:52:26] <A-L-P-H-A> gezr, did you said you don't have a CNC machine _yet_? [meaning you are retrofitting one soon?]
[16:52:39] <gezr> A-L-P-H-A : im going to build one from scratch
[16:52:40] <robin_sz> alex_joni: spindle coolant and lube? surely not .. thsoe are rarely used
[16:52:50] <robin_sz> why make special cases?
[16:53:03] <alex_joni> well.. maybe some special cases would be usefull
[16:53:08] <robin_sz> why?
[16:53:09] <alex_joni> say: special case=mill
[16:53:17] <robin_sz> why have two ways of implemtning stuff?
[16:53:22] <robin_sz> it makes programming harder
[16:53:26] <A-L-P-H-A> gezr, cool... a CNC mill? overhead gantry type? or with the part moving or with the head?
[16:53:43] <gezr> A-L-P-H-A : multi axis mill
[16:53:50] <gezr> flying head
[16:53:56] <robin_sz> implement some way of linking a button an gcode or m code to a signal
[16:53:57] <gezr> flying table
[16:54:12] <robin_sz> implenent a way of linkign that (via logic) to a IO pin
[16:54:23] <gezr> gcodes are a fixed standard robin_sz
[16:54:25] <alex_joni> well.. once you have a signal HAL does the rest
[16:54:34] <alex_joni> gezr: yes and no ;)
[16:54:39] <robin_sz> then implement you spindle, lube, coolant etc etc etc using that framework
[16:54:39] <alex_joni> yes as in RS274
[16:54:45] <alex_joni> no as in a LOT of dialects
[16:54:52] <A-L-P-H-A> how are you gonna designing the 5th axis? the tiling head?
[16:55:06] <alex_joni> M_codes could be usefull
[16:55:16] <gezr> A-L-P-H-A : it probably wont have the 5th
[16:55:18] <robin_sz> this is the way ALL commercial controlers work
[16:55:27] <alex_joni> say M_01 - M_255 linked to NML_01 - NML_255
[16:55:47] <A-L-P-H-A> gezr, oh, so XYZ, and a rotary axis for the part?
[16:55:51] <alex_joni> and NML_01 - NML_255 output iocontrol.0.1 - iocontrol.0.255
[16:55:52] <robin_sz> why not have a table :
[16:55:56] <gezr> A-L-P-H-A yeah
[16:55:59] <alex_joni> jmk: just the man was missing
[16:56:10] <jmkasunich> I was up late last night
[16:56:12] <alex_joni> we are in heavy debate over IO control
[16:56:13] <A-L-P-H-A> rotary axis probably being a rotary table mounted vertically.
[16:56:16] <A-L-P-H-A> ?
[16:56:22] <alex_joni> seen that, and I really applaude the rework ;)
[16:56:31] <gezr> A-L-P-H-A : horizontally
[16:56:34] <robin_sz> a table to link varouis Mcodes to signal names
[16:56:36] <gezr> wait yeah vertically
[16:56:36] <alex_joni> I am thinking about some basic IO-control in EMC2
[16:56:42] <robin_sz> signal names are then linked to logic
[16:56:43] <jmkasunich> it's gonna get ugly before it gets better
[16:56:44] <alex_joni> but it seems it got out of hand ;)
[16:56:46] <robin_sz> logioc to pins
[16:56:52] <robin_sz> but ALL that is configurabe
[16:57:07] <A-L-P-H-A> gezr, horizontally? why? are you intenting to make more circles, which the CNC machine could do already?
[16:57:30] <alex_joni> think we need to split up the discussions.. I'm not really following anymore ;)
[16:57:37] <A-L-P-H-A> I _need_ lunch...
[16:57:41] <robin_sz> alex_joni: I maintain that while the core of emc is full of switch statemnts based on indivdual message, were screwed
[16:57:42] <jmkasunich> I should have started my logger last night so I could catch up
[16:57:44] <A-L-P-H-A> I'll be back after I hit the pizzeria.
[16:58:02] <alex_joni> ok A-L-P-H-A
[16:58:08] <jmkasunich> robin_sz: maybe so, but it'll take a better man than me to fix that
[16:58:18] <alex_joni> jmk: shortly what has been discussed
[16:58:35] <alex_joni> I wanted to make IO work in emc2
[16:58:48] <jmkasunich> good plan
[16:58:53] <alex_joni> so I thought an easy way would be to add some HAL pins to a minimillio
[16:58:58] <robin_sz> jmkasunich: sigh, yeah, me too .. I did try and start a long time ago, but gave up because it was too much for one man, and no one else seemed to be wanting to go in that direction
[16:59:01] <alex_joni> or even bridgeport..
[16:59:02] <jmkasunich> yep
[16:59:12] <alex_joni> I hope this is the way to go
[16:59:24] <alex_joni> but
[16:59:30] <alex_joni> there are a few issues
[16:59:39] <alex_joni> 1. everything is pretty fixed in EMC
[16:59:55] <alex_joni> you need to change a lot of places (hardcode) in order to add/change signals
[17:00:01] <jmkasunich> right now the emc2 io controller is simioControl.cc, I think
[17:00:14] <alex_joni> say you need some special signals for Plasma (or laser)
[17:00:21] <alex_joni> jmk: yes, only sim, and no output
[17:00:24] <robin_sz> jmkasunich: I just rememerb the mess I got into trying to add the plasma stuff using existing signals and trying to rememerb that spindle on is plasma start, coolant on is the arc_is_on signal back etc etc
[17:00:42] <jmkasunich> robin_sz: ick
[17:00:47] <robin_sz> quite
[17:00:53] <alex_joni> so robin suggest a way to have it modular
[17:01:07] <robin_sz> what id like is to assing M06 => "plasmaOn"
[17:01:18] <robin_sz> have a gui button I attach text to "plasmaOn"
[17:01:20] <alex_joni> something like HAL (in a far way...) to link G/M-codes to functions/NML_messages
[17:01:34] <alex_joni> and the NML_message to a HAL_pin (from the IO controller)
[17:01:38] <robin_sz> and then send either the string or a integer lookup of "plasmaOn" into emc core ...
[17:01:39] <jmkasunich> that would be done in the interp, right?
[17:01:52] <alex_joni> and the HAL_pin later to a hardware pin (either parport or whatever)
[17:02:04] <alex_joni> jmk: yes and no
[17:02:06] <robin_sz> if someting understands that, then "stuff happens" .. if nothing uderstands then it just drifts through and drops into the bit bucket
[17:02:18] <alex_joni> you need code in the interp, and in the IOcontoller
[17:02:39] <jmkasunich> interp reads M code, and sends NML message
[17:02:44] <robin_sz> HAL answers a big part of that problem already
[17:03:00] <jmkasunich> IO controller gets NML message and sets a HAL pin
[17:03:05] <alex_joni> the quick fix (but very ugly) would be to add 255 (or any number) custom messages to NML
[17:03:14] <alex_joni> jmk: yes
[17:03:24] <robin_sz> alex_joni: I suspect EMC has had enough "quick fixes" applied already :)
[17:03:34] <alex_joni> robin: I agree...
[17:03:43] <jmkasunich> today, I think the interp already understands some M codes, and sends some specific NML messages
[17:03:44] <robin_sz> alex_joni: what we need is architecture :)
[17:03:46] <alex_joni> but I don't think you could do it better without a NML rework
[17:03:53] <jmkasunich> you are talking about making it more generic?
[17:03:56] <robin_sz> I agree
[17:03:58] <alex_joni> robin is
[17:04:11] <cradek> why does each custom function need its own message?
[17:04:18] <robin_sz> quite
[17:04:25] <alex_joni> good question cradek
[17:04:38] <jmkasunich> cause that's how NML works... the C++ idea of methods
[17:04:38] <alex_joni> how about an M-code message
[17:04:50] <alex_joni> that tells the IO-controller M-code x was called
[17:04:59] <cradek> alex_joni: that's the ticket
[17:05:00] <alex_joni> and the IO-controller knows what to do
[17:05:05] <alex_joni> configurable
[17:05:06] <cradek> suddenly there's no C++ mess to write
[17:05:21] <alex_joni> I'd be able to live with that
[17:05:23] <robin_sz> alex_joni: how about a NML_IO_message
[17:05:25] <jmkasunich> well you just move some of the mess from the interp to the iocontroller
[17:05:27] <cradek> there's just the M-handler
[17:05:28] <robin_sz> cradek: well spotted
[17:05:38] <alex_joni> sounds great
[17:05:50] <cradek> jmkasunich: I think it would simplify both
[17:05:55] <alex_joni> I do have some specific questions for jmk, before I start to code
[17:06:04] <robin_sz> I dotn think there would be a mess
[17:06:07] <jmkasunich> I don't think you want to generic-ize the ones that are already there
[17:06:19] <alex_joni> I'd leave those as they are
[17:06:27] <alex_joni> don't think a double message would hurt
[17:06:47] <cradek> so use M over 100 for custom or something
[17:06:48] <jmkasunich> cause some might have preconditions, postconditions, all that other stuff that task handles
[17:06:54] <alex_joni> say M1 comes (don't really know what M1 is, but assuming it's NML_SPINDLE_FORWARD)
[17:07:12] <robin_sz> jmkasunich: why not genericize them all? what do you see as the advantage in having two ways to implemnent a lot of things
[17:07:21] <robin_sz> * robin_sz must go soon
[17:07:23] <gezr> g-codes must remain the same, but an m-code .ini type file would basically define the machine type, mplasma.ini mlathe.ini mmill.ini
[17:07:29] <jmkasunich> say M1 is spindle forward
[17:07:35] <cradek> it would be nice to maintain NML compatibility for the old messages
[17:07:44] <jmkasunich> if all you want it to do is turn on a single bit, thats no prob
[17:07:55] <robin_sz> why? the old ,messages are for EMC1 surely?
[17:08:02] <jmkasunich> but suppose the motion controller needs to pause until the spindle is up to speed
[17:08:14] <robin_sz> then thats a HAL task right?
[17:08:18] <jmkasunich> isn't there already code that handles that?
[17:08:23] <gezr> thats a g-code function jmkasunich
[17:08:32] <alex_joni> you sure gezr?
[17:08:34] <cradek> jmkasunich: there is a hard-coded pause between brake-off and spindle-forward
[17:08:41] <cradek> jmkasunich: it's specified in the ini file
[17:08:46] <gezr> alex_joni : acording to what i know about g-codes
[17:08:53] <jmkasunich> coded where? in the io controller, or in task, or in the interp?
[17:08:54] <cradek> jmkasunich: I don't think there's a built-in pause AFTER spindle-forward
[17:09:11] <robin_sz> cradek: you wanna know how much trouble that caused when I used the various brake and spindle message to try and control a plasma?
[17:09:16] <cradek> don't know, I haven't looked for it
[17:09:19] <jmkasunich> my point is that there is "stuff" other than just turning on a HAL bit
[17:09:21] <cradek> robin_sz: no
[17:09:32] <robin_sz> I got into a REAL mess
[17:09:33] <alex_joni> ok.. let's settle
[17:09:45] <alex_joni> for a turn-bi-on/off it's easy
[17:09:46] <alex_joni> right?
[17:09:50] <alex_joni> just set a bit
[17:09:53] <alex_joni> to HAL
[17:09:58] <robin_sz> ended up adding my own messages, which meant I was stuck with my version of emc, no upgrades
[17:10:00] <alex_joni> and ack the NML
[17:10:02] <robin_sz> * robin_sz shuts up
[17:10:18] <cradek> alex_joni: yes, sounds like
[17:10:30] <jmkasunich> I'd start with simioControl
[17:10:49] <jmkasunich> the skeleton is there, just modify it so it tweaks some HAL pins
[17:10:52] <alex_joni> I just want to add estop first to simioControl
[17:11:01] <alex_joni> and we'll see after that
[17:11:05] <jmkasunich> right - add an estop pin
[17:11:10] <alex_joni> but the debate is right...
[17:11:16] <alex_joni> it should get discussed
[17:11:25] <alex_joni> one quick question:
[17:11:26] <gezr> emc should be fully configurable
[17:11:29] <jmkasunich> did you see my "FIXME FIXME FIXME", I think its in emctaskmain?
[17:11:41] <alex_joni> I've never played with HAL in non-rt mode
[17:11:49] <alex_joni> does it work the same?
[17:11:55] <jmkasunich> pretty much
[17:12:01] <jmkasunich> no functs or threads tho
[17:12:04] <alex_joni> register pin & such?
[17:12:07] <jmkasunich> yes
[17:12:12] <alex_joni> ok..
[17:12:20] <alex_joni> then it should be pretty simple
[17:12:38] <jmkasunich> you can take a look at the parport driver (or Martin's skeleton driver, I think)
[17:12:39] <alex_joni> so you can then link a signal from a non-rt HAL pin to a rt HAL-pin
[17:12:48] <jmkasunich> it can be built for user or RT
[17:12:51] <alex_joni> * alex_joni kinda remembers
[17:12:52] <alex_joni> ;)
[17:13:01] <jmkasunich> damn it;s hard to type with a cat on the keyboard
[17:13:17] <cradek> jmkasunich: use a sunbeam to lure the cat away
[17:13:19] <alex_joni> it's ok.. I have a cat-filter
[17:13:50] <jmkasunich> cradek: I'm in cleveland and it's between november and may - we don't have sunbeams
[17:13:53] <alex_joni> that filters out unusual keystrokes
[17:14:10] <cradek> jmkasunich: surprisingly I have one today, which has immobilized my cat.
[17:14:21] <jmkasunich> she's not stepping on the keys, just standing between me and the keys/screen
[17:14:39] <alex_joni> jmk: no FIXME in simIoControl.. ;)
[17:14:40] <jmkasunich> I'm not a true touch typist - need to be able to at least glance at the keys
[17:15:03] <cradek> I'm off to "breakfast" (that's what you call the first meal of the day, right?)
[17:15:13] <alex_joni> cradek: I call mine lunch
[17:15:24] <alex_joni> because it's usually around 12 am ;)
[17:15:27] <jmkasunich> emctaskmain line 2607
[17:15:34] <A-L-P-H-A> I call this, Pizza. :) yummmy.
[17:16:00] <A-L-P-H-A> 12am is midnight
[17:16:10] <alex_joni> jmk: I would have looked for that ;)
[17:16:20] <alex_joni> but thanks for pointing it out
[17:17:01] <alex_joni> you saved me some debugging
[17:18:28] <alex_joni> what's iotaskintf.cc ?
[17:19:18] <jmkasunich> damned if I know ;-)
[17:19:50] <alex_joni> I think it's the NML to IO-controller interface
[17:20:07] <jmkasunich> then what is simioControl.cc?
[17:20:37] <alex_joni> same thing.. but simulated
[17:20:50] <alex_joni> the iotaksintf.cc is just some framework?
[17:21:02] <alex_joni> not connected to an actual io-control task
[17:21:49] <jmkasunich> simioControl is the big honkin switch statement that decides what to do with a message
[17:22:00] <alex_joni> hmmm... milltaks is built from iotaskinf.cc
[17:22:04] <alex_joni> milltask
[17:22:14] <jmkasunich> iotaskintf is a bunch of little functions that actually do stuff (I think)
[17:22:44] <jmkasunich> waitaminnit - I think I've got it ;-)
[17:23:07] <jmkasunich> iotaskintf is a bunch of functions that are called by task to SEND the NML messages
[17:23:20] <jmkasunich> simiocontrol is the one that gets the messages
[17:24:03] <alex_joni> yeah.. sound likely
[17:24:32] <alex_joni> sounds
[17:25:57] <alex_joni> * alex_joni starts adding HAL-pins to miniIoControl.cc
[17:26:35] <jmkasunich> miniIoControl.cc?
[17:26:50] <jmkasunich> where'd that come from, copied over from emc1?
[17:26:56] <alex_joni> nope
[17:27:03] <alex_joni> that's the one I'm writing
[17:27:09] <alex_joni> copied from simIoCOntrol.cc
[17:27:19] <jmkasunich> do we really need a mini and a bridgeport io?
[17:27:22] <alex_joni> think a different name would be more explicit?
[17:27:37] <alex_joni> ioControl.cc ?
[17:27:39] <jmkasunich> I'm hoping that we can have just one (or at least just one for all mills, another for lathes)
[17:27:57] <jmkasunich> it can export a whole bunch of pins, if you need the mini version, just don't hook them up
[17:28:08] <alex_joni> I agree
[17:28:18] <alex_joni> then without the mini
[17:28:22] <alex_joni> ioControl.cc
[17:28:28] <alex_joni> IoControl.cc ?
[17:28:33] <jmkasunich> sure
[17:28:43] <alex_joni> io or Io
[17:29:01] <alex_joni> * alex_joni chooses io
[17:29:16] <jmkasunich> oh hell, I dunno... I'm not to fond of mixed case in names
[17:29:39] <jmkasunich> maKes me fEEl like some wAreZ d00D
[17:29:58] <alex_joni> lOl
[17:33:58] <alex_joni> jmk: can you give me a crash-course what I need to do?
[17:34:34] <alex_joni> I'm not sure about the shared-memory
[17:35:06] <jmkasunich> lemme take a look at simiocontrol.cc
[17:36:18] <jmkasunich> probably want to define a struct that contains hal_bit pointers for each HAL pin you intend to have
[17:37:32] <jmkasunich> you'll need a funct that does init on the hal side and one for cleanup
[17:37:57] <jmkasunich> call the init one from somewhere around simiocontrol.253
[17:38:29] <jmkasunich> and the exit one from about line 509
[17:38:32] <alex_joni> ok.. thx
[17:38:46] <jmkasunich> the init one needs to call hal_init("iocontrol"),
[17:38:56] <alex_joni> yup
[17:39:09] <jmkasunich> then hal_malloc(sizeof(the_struct_with_all_the_pins)
[17:39:17] <jmkasunich> then do all the pin export calls
[17:40:22] <jmkasunich> once the init is done, and you get into the while loop at line 267, each case needs to modify whatever pins are appropriate
[17:43:18] <jmkasunich> time for lunch
[17:43:22] <jmkasunich> jmkasunich is now known as jmk_away
[17:43:24] <alex_joni> enjoy
[18:15:44] <alex_joni> anyone still around?
[18:21:04] <A-L-P-H-A> http://slashdot.org/article.pl?sid=05/01/14/1815251&tid=222&tid=149 _ and _ http://www.makezine.com/ I think alot of thepeople in here would be interested in this magazine/book subscription.
[18:27:23] <asdfqwega> I'm not around, I'm a square
[18:27:45] <alex_joni> lol
[18:28:00] <alex_joni> * alex_joni wonders if anybody tried to use HAL with c++
[18:34:52] <alex_joni> A-L-P-H-A: pretty expensive ;)
[18:38:03] <jmk_away> jmk_away is now known as jmkasunich
[18:38:11] <alex_joni> hello back ;)
[18:38:20] <alex_joni> me had a small problem but fixed it
[18:38:27] <alex_joni> I had to link hal to the .cc
[18:38:47] <jmkasunich> never thought about that
[18:38:48] <alex_joni> and the linker didn't see the functions because of a missing extern "C" ;)
[18:38:58] <alex_joni> I added that to hal.h
[18:39:02] <jmkasunich> cool
[18:39:07] <alex_joni> #ifdef __cplusplus
[18:39:13] <alex_joni> extern "C" {
[18:39:15] <alex_joni> #endif
[18:39:38] <alex_joni> but it didn't work ;) (because I forgot to cp hal.h to emc2/include :D)
[18:39:45] <alex_joni> silly me.. :-))
[18:39:58] <jmkasunich> ? you shouldn't have to, the make should do that
[18:41:00] <alex_joni> not the make inside src/emc/iotask/
[18:41:15] <jmkasunich> oh
[18:41:30] <jmkasunich> I tend to always work from the top level emc2 dir, and use the make there
[18:42:30] <alex_joni> should I commit?
[18:42:34] <alex_joni> when it's done?
[18:42:34] <jmkasunich> sure
[18:44:11] <A-L-P-H-A> alex_joni, yeah... but you're paying for content... it's a quarterly publication that's a small book... not just a mag...
[18:47:14] <alex_joni> jmk: to actually write to the HAL pin, I only need to change the value of iocontrol_data_array->estop_pin .. right?
[18:47:45] <alex_joni> where iocontrol_data_array = (iocontrol_t *)hal_malloc (size_of(iocontrol_t));
[18:48:31] <jmkasunich> pretty much
[18:49:01] <jmkasunich> if it's a pin, you do "*(iocontrol_data_array->estop_pin) = newvalue;"
[18:49:14] <jmkasunich> cause pins are actually pointers to the linked signal
[18:49:48] <jmkasunich> if it's a param you skip the *... "iocontrol_data_array->some_param = newvalue;"
[18:53:51] <alex_joni> seems some bits are still missing
[18:54:00] <alex_joni> for example the aux-channels
[18:54:05] <jmkasunich> what's missing
[18:54:17] <alex_joni> aux-command and aux-status
[18:54:30] <jmkasunich> I'm afraid I don't know anything about them
[18:54:51] <alex_joni> well.. it's not that complicated
[18:55:08] <alex_joni> there are 5 things involved in IO-control
[18:55:20] <alex_joni> tool (is implemented in simIoControl)
[18:55:21] <alex_joni> lube
[18:55:28] <alex_joni> spin
[18:55:33] <jmkasunich> cool
[18:55:34] <alex_joni> cool
[18:55:36] <alex_joni> and aux
[18:55:41] <alex_joni> aux handles estop
[18:55:54] <jmkasunich> ok... I was looking at emc1, and saw bridgeportcool, etc
[18:56:11] <jmkasunich> didn't understand the connection, or why simiocontrol only had one file
[18:57:14] <alex_joni> well because simiocontrol only takes care of tool right now
[18:59:54] <alex_joni> although the NML types are all defined in the main loop
[19:00:18] <alex_joni> but the feedback channel for ESTOP I don't seem to find
[19:02:43] <jmkasunich> feedback channel?
[19:04:31] <alex_joni> yes.. a channel to send ESTOP is on to EMC
[19:04:42] <alex_joni> but I'll figure that out in a second
[19:04:45] <alex_joni> anyways...
[19:04:56] <alex_joni> I was thinking about one thing I wanted to discuss with you
[19:05:00] <alex_joni> involving HAL
[19:05:06] <jmkasunich> ok
[19:05:15] <alex_joni> I think there are components which can't have floating pins
[19:05:21] <alex_joni> like in hardware
[19:05:34] <alex_joni> you need to tie those pins to a certain value
[19:05:40] <alex_joni> like tie them to 1 or 0
[19:05:52] <alex_joni> which results in different behaviour
[19:05:57] <jmkasunich> when a component is first created, all it's pins are ties to dummy signals
[19:06:06] <jmkasunich> the dummy signals are normally set to zero
[19:06:18] <alex_joni> but can you define the value to be different from zero?
[19:06:32] <alex_joni> * alex_joni was thinking about a hal component named constant
[19:06:39] <jmkasunich> who is "you"? the guy writing the component, or the user?
[19:06:49] <alex_joni> the user
[19:07:09] <alex_joni> a component constant (with one pin output), and a parameter (to set it's value)
[19:07:27] <alex_joni> but I'm not sure it's needed (e.g. you can get the same behaviour somehow else)
[19:07:38] <alex_joni> e.g. ESTOP
[19:07:56] <alex_joni> let's say I don't want to edit emc.ini (to alter ESTOP_POLARITY)
[19:08:07] <jmkasunich> I think halcmd has a "sets" command that lets you set a signal
[19:08:35] <alex_joni> or maybe there is a case where I can't do this (alter polarity)
[19:08:46] <alex_joni> now I want a machine without actual ESTOP HW
[19:08:56] <alex_joni> and I might need the default value for ESTOP
[19:09:11] <jmkasunich> once things are HALified, there shouldn't be polarity associated with things like ESTOP
[19:09:41] <jmkasunich> instead, ESTOP should always be active HI, and if the external signal is active low, you set the polarity at the hardware driver
[19:09:49] <alex_joni> I agree
[19:09:51] <jmkasunich> parport.0.pin-01-out.invert
[19:09:54] <jmkasunich> or whatever
[19:09:55] <alex_joni> yup
[19:10:06] <alex_joni> * alex_joni saw that sets exists
[19:10:12] <alex_joni> that would do the trick
[19:10:16] <alex_joni> even if it's needed
[19:10:22] <jmkasunich> but sets won't let you set a pin unless it is connected to a signal
[19:10:30] <alex_joni> sets (set signal)
[19:10:39] <alex_joni> create a dummy signal (just for value)
[19:10:50] <alex_joni> and connect it to thepin you need to tie (high or low)
[19:10:52] <alex_joni> then sets
[19:10:58] <alex_joni> to set the value
[19:11:02] <jmkasunich> yes, but kind of messy
[19:11:38] <jmkasunich> being able to set an unconnected pin directly would be nice (it would modify the dummysig that an unconnected pin is connected to)
[19:13:09] <anonimasu> iab
[19:13:24] <jmkasunich> "setp" is already used for set parameter, but perhaps "setpin"?
[19:13:44] <alex_joni> setpinvalue?
[19:13:52] <alex_joni> setpin is too generic IMO
[19:14:02] <jmkasunich> shorter is better, people type these things
[19:14:47] <jmkasunich> (I'm talking about halcmd commands, not API function names)
[19:15:21] <anonimasu> I'll be back in a bit, going to try theese other pins on the mill
[19:15:26] <alex_joni> hmmm.. halmeter doesn't see the HAL pin I just created
[19:15:44] <jmkasunich> strance
[19:15:49] <jmkasunich> strange
[19:15:49] <alex_joni> does halmeter connect to non-rt pins?
[19:15:54] <jmkasunich> should
[19:16:02] <jmkasunich> try "halcmd show pin"
[19:16:59] <jmkasunich> I often use "halmeter show pin (or whatever) | grep <something>" to filter the long list
[19:17:11] <alex_joni> I did halcmd show comp
[19:17:13] <jmkasunich> for instance, to see all pins associates with axis.0, but not the rest
[19:17:17] <alex_joni> and iocontrol doesn't appear
[19:17:21] <alex_joni> gotta dig into it
[19:17:44] <jmkasunich> you checking the return values of hal_init(), etc?
[19:17:51] <alex_joni> yup
[19:17:55] <jmkasunich> strange
[19:17:58] <alex_joni> it aborts without hal_init
[19:29:58] <alex_joni> what do you know...
[19:30:02] <alex_joni> it seems to work ;)
[19:30:07] <alex_joni> at least one way :D
[19:30:20] <jmkasunich> what was wrong?
[19:30:34] <alex_joni> didn't compile last version *g*
[19:30:44] <jmkasunich> ;-)
[19:30:49] <alex_joni> the one that actually called hal_init
[19:36:10] <CIA-5> 03alex_joni * 10emc2/src/hal/hal.h:
[19:36:11] <CIA-5> added some initial support for HAL-based IO. right now a new iotask called io
[19:36:11] <CIA-5> (not simio) exports HAL-pins for estop and sets those when a NML-estop message
[19:36:11] <CIA-5> arrives. work needs to be done to get an estop through NML to EMC, and to
[19:36:11] <CIA-5> implement other signals as well (coolant, lubrication, etc.)
[19:36:18] <CIA-5> 03alex_joni * 10emc2/ (3 files in 2 dirs):
[19:36:18] <CIA-5> added some initial support for HAL-based IO. right now a new iotask called io
[19:36:18] <CIA-5> (not simio) exports HAL-pins for estop and sets those when a NML-estop message
[19:36:18] <CIA-5> arrives. work needs to be done to get an estop through NML to EMC, and to
[19:36:19] <CIA-5> implement other signals as well (coolant, lubrication, etc.)
[19:42:33] <cradek> yay!
[19:43:44] <jmkasunich> hmmmm...
[19:43:48] <jmkasunich> a dilemma
[19:43:50] <alex_joni> well.. it only gets estop out to hal
[19:43:56] <alex_joni> jmk: shoot
[19:44:05] <jmkasunich> I have this little avltree library
[19:44:22] <jmkasunich> and inside the .c there is also a main() that can be used to test it
[19:44:34] <jmkasunich> with a #ifdef to turn it on or off
[19:44:48] <jmkasunich> but to build the test prog, the makefile also needs to be changed
[19:45:06] <jmkasunich> the dillemma is do I leave such cruft in the makefile, or should it just build the lib
[19:45:27] <jmkasunich> and I build the test binary manually when needed
[19:45:56] <alex_joni> this sounds resonable
[19:46:27] <alex_joni> bummer
[19:46:28] <jmkasunich> which one?
[19:46:42] <alex_joni> build the test binary manually
[19:46:46] <jmkasunich> ok
[19:46:53] <alex_joni> * alex_joni forgot to clean up emc.run :(
[19:47:04] <alex_joni> I changed the values for DEBUG_FILE & PRINT_FILE
[20:00:56] <alex_joni> I _really_ like this NML stuff :(
[20:07:50] <CIA-5> 03jmkasunich 07halrefactor-0-1 * 10emc2/src/hal/ (Makefile avltree.c): improved test program for AVL trees, fixed a bug in the first() and last() functions, added an avltest target to the HAL makefile to build the test program
[20:09:59] <Imperator_away> Imperator_away is now known as Imperator_
[20:10:03] <Imperator_> Hi all
[20:11:00] <alex_joni> hey Martin
[20:12:52] <Imperator_> Alex it seams that you know how to handel NML ??
[20:13:27] <alex_joni> sortoff... but only a little
[20:13:43] <alex_joni> right now I'm not doing anything NML
[20:15:46] <Imperator_> you have added a estop output, right
[20:15:53] <alex_joni> yup
[20:19:40] <alex_joni> still some weird things ;)
[20:19:48] <alex_joni> * alex_joni is missing for half an hour
[20:55:02] <anonimasu> * anonimasu sighs
[21:04:15] <alex_joni> * alex_joni is back
[21:05:47] <anonimasu> wb
[21:05:51] <anonimasu> my machine refused to work
[21:05:52] <anonimasu> :9
[21:06:00] <alex_joni> :(
[21:06:56] <alex_joni> so, no luck?
[21:08:16] <anonimasu> nope
[21:08:47] <alex_joni> what's wrong?
[21:08:50] <alex_joni> any idea?
[21:09:29] <anonimasu> no
[21:09:30] <anonimasu> :/
[21:09:40] <anonimasu> I tried moving the pins aswell on the amps..
[21:09:53] <alex_joni> does EMC start?
[21:10:00] <anonimasu> yeah
[21:10:05] <anonimasu> it starts and moves my Z axis..
[21:10:12] <anonimasu> when I try running my X axis..
[21:10:13] <anonimasu> :)
[21:10:22] <anonimasu> and only in one direction
[21:10:25] <anonimasu> I moved the direction pin..
[21:10:39] <anonimasu> but it still wont change which way the axis goes..
[21:12:02] <alex_joni> it could be that my calculations were wrong
[21:12:18] <alex_joni> the direction you can easily measure
[21:12:20] <alex_joni> 0/5V
[21:12:24] <anonimasu> I tried running with the generic.ini unmodified..
[21:12:26] <alex_joni> doesn't change too often
[21:12:30] <anonimasu> yeah, I did that..
[21:12:35] <alex_joni> and?
[21:12:44] <anonimasu> I find the direction pins..
[21:12:59] <anonimasu> but the axis dosent move in the other direction..
[21:16:27] <alex_joni> does the polarity change on the parport?
[21:16:41] <anonimasu> no
[21:16:44] <anonimasu> just 0-5v
[21:17:04] <alex_joni> what do you mean 0-5V ?
[21:17:17] <alex_joni> it should be 0 if you go one way
[21:17:20] <anonimasu> logic 0 and 1
[21:17:20] <anonimasu> yeah
[21:17:24] <alex_joni> and 5Vif you go the other way
[21:17:28] <anonimasu> I know
[21:17:34] <alex_joni> is it like this?
[21:17:39] <anonimasu> that does work, but emc only outputs pulses when I go one way..
[21:17:42] <alex_joni> or does it always stay the same?
[21:17:52] <alex_joni> ohh... and no pulses theother way?
[21:17:56] <anonimasu> yeah
[21:18:04] <alex_joni> you sure there are no pulses?
[21:18:31] <anonimasu> well, if the axis moves in one way, and I push the other key, isnt emc supposed to output the same pulses..
[21:18:47] <anonimasu> with the dir pin 0 or 5v...
[21:18:57] <anonimasu> depending on which way I try to move..
[21:18:58] <anonimasu> :)
[21:21:12] <anonimasu> err to put it simply, the dir pin works, but I only get movement when I run the axis one way..
[21:23:40] <anonimasu> cant really measure it though
[21:23:48] <gezr> what pins ar eyou using?
[21:23:57] <anonimasu> the default ones
[21:24:05] <gezr> 123456?
[21:24:05] <anonimasu> right now
[21:24:13] <anonimasu> I have no idea what they are..
[21:24:18] <anonimasu> I just tried running with generic.ini
[21:24:24] <anonimasu> and measuring the pins..
[21:24:41] <gezr> yeah, 1dirx 2stepx 3diry 4stepy
[21:24:44] <gezr> i believe
[21:24:47] <anonimasu> yeah probably
[21:26:02] <anonimasu> I'll grab the scope off work and measure it tomorrow
[21:26:35] <gezr> use headphones
[21:26:42] <gezr> if you have an old set you can sacrifice
[21:27:05] <alex_joni> you can even measure with an voltmeter
[21:27:22] <alex_joni> if it's between 0 and 5 (around 1-4V) you're stepping
[21:27:29] <cradek> an analog one is best
[21:27:33] <slomo> just joined, so what driver board are you using
[21:27:35] <gezr> yeah, and you can hear the stepps
[21:27:37] <alex_joni> if you have one ;)
[21:27:37] <anonimasu> yeah, but why's it stepping in one direction..
[21:27:41] <anonimasu> geckodrives..
[21:27:51] <anonimasu> I've been running the same setup with turbocnc for long while now :9
[21:28:10] <gezr> you will need to change your cable I believe
[21:28:20] <gezr> turbo uses a different pin out
[21:28:37] <anonimasu> it uses a user defined pinout..
[21:28:56] <anonimasu> the weird thing is that I get steps when I move X+ but not X-
[21:29:40] <cradek> do the other axes work?
[21:29:50] <anonimasu> I can get z to move in one direction..
[21:29:55] <anonimasu> and y
[21:30:05] <cradek> so each one only moves in one direction?
[21:30:08] <anonimasu> yeah..
[21:30:17] <cradek> that is very bizarre
[21:30:25] <anonimasu> when I try moving the axis in the other direction I dont get any motion at all...
[21:30:26] <anonimasu> :)
[21:30:41] <anonimasu> I thought so too..
[21:31:01] <anonimasu> it might be the case of emc + my cable but still where do the pulses go ;)
[21:31:05] <cradek> but it works with your other software? and you are SURE it's set up for the same pinout?
[21:31:27] <anonimasu> i measured to make sure the direction pins would be on the right driver..
[21:31:48] <gezr> there is no pin 0 on a printer port
[21:31:49] <slomo> for use with xylotex board, i had to swap 1-2 3-4 5-6 dont know about gecko
[21:31:53] <gezr> just a side note
[21:32:16] <cradek> slomo: you mean 2-3 4-5 6-7
[21:32:18] <slomo> oopps 2-3 4-5 6-7
[21:32:36] <slomo> the # 1 pin goes straight thru
[21:32:45] <anonimasu> oh, I can use whatever pins I like as long as I get step / dir out
[21:32:45] <alex_joni> * alex_joni is lost...
[21:32:46] <anonimasu> :)
[21:33:10] <cradek> alex_joni: xylotex has the step pins and dir pins reversed from the normal emc way
[21:34:23] <alex_joni> I wasn't following the pins stuff
[21:34:35] <alex_joni> * alex_joni dived deep into rcslib
[21:34:45] <alex_joni> iocontroller
[21:34:47] <anonimasu> well, I'll measure it tomorrow and see if I get any luck..
[21:34:52] <anonimasu> I am kind of tired :)
[21:35:05] <alex_joni> I am kind of annoyed :)
[21:35:15] <anonimasu> * anonimasu too
[21:35:27] <anonimasu> been messing for 6 hours with some stupid problem :9
[21:35:38] <anonimasu> I'll order new stuff and make a real cable.
[21:37:29] <anonimasu> that might help a bit..
[21:37:49] <anonimasu> and take the scope home..
[21:38:06] <slomo> anonimasu: so are you currently using pins 2,3,4,5,6,7 ?
[21:38:40] <anonimasu> yes
[21:38:53] <anonimasu> whatever the defaults are :)
[21:38:59] <gezr> 123456
[21:39:49] <cradek> gezr: pin 1 isn't part of the step/dir output
[21:39:54] <cradek> gezr: it starts at pin 2
[21:39:59] <alex_joni> which is D0
[21:40:14] <gezr> i guess im on crack, your right
[21:40:22] <slomo> anonimasu: i think emc is for the signals on 2,3,4,5,67
[21:40:42] <gezr> ive been looking at valve #1 for the past 2 hours,
[21:40:52] <gezr> thats probably where im geting my thinking
[21:41:32] <anonimasu> :)
[21:41:35] <anonimasu> * anonimasu yawns
[21:41:45] <anonimasu> I'll be off now going to rest for a bit
[21:42:11] <anonimasu> laters everyone
[21:42:52] <alex_joni> * alex_joni found the problem
[21:43:00] <alex_joni> cradek: care to discuss it with me?
[21:43:06] <alex_joni> promise I'll not talk about NML
[21:43:18] <alex_joni> only about estop ;)
[21:44:13] <cradek> I'll try to help
[21:44:23] <alex_joni> well.. it's like this
[21:44:31] <alex_joni> there is an EMC_AUX_thingy
[21:44:38] <alex_joni> which takes care of ESTOP
[21:44:49] <alex_joni> and it has 2 variables
[21:44:56] <alex_joni> aux.estop
[21:45:00] <alex_joni> and auc.estop-in
[21:45:03] <alex_joni> aux
[21:45:10] <alex_joni> the first one is for output
[21:45:16] <alex_joni> and the second is the input
[21:46:21] <alex_joni> in emc1 the aux-thingy is a class
[21:46:26] <alex_joni> derived from NML_MODULE
[21:46:39] <alex_joni> that's a class with some state_machine in it
[21:47:19] <alex_joni> anyways... it goes through some states, and it returns the whole aux structure (including estop & estop_in)
[21:47:24] <alex_joni> is it clear so far?
[21:47:49] <cradek> yes, but I'm afraid you're going to start asking questions I don't know the answers to
[21:48:24] <alex_joni> we'll see ;)
[21:48:29] <alex_joni> in emc2 there aren
[21:48:35] <alex_joni> aren't any classes any more
[21:48:55] <alex_joni> it's a simple loop which gets a command (NML) and executes it
[21:49:14] <alex_joni> at the end it returns the whole status-struct (like emc1)
[21:49:35] <alex_joni> now... the problem I am facing now is that estop_in gets set (from HAL)
[21:49:48] <alex_joni> but the task controller only checks estop
[21:50:01] <alex_joni> I have 2 ways of doing things:
[21:50:29] <alex_joni> 1. update estop from estop_in (if not set, and estop_in is set then estop=1)
[21:51:00] <alex_joni> 2. modify the task controller to check estop_in (this way to run the machine a hal-loopback needs to be made from estop to estop-in)
[21:53:29] <alex_joni> I'd go with 2
[21:53:36] <alex_joni> what do you think?
[21:55:26] <cradek> isn't estop_in supposed to come from the hardware?
[21:55:49] <alex_joni> that's what I assume
[21:56:17] <cradek> ok, I see why you're saying use hal-loopback
[21:57:50] <cradek> I think you're asking the wrong guy, but having said that, I'm with you on using #2
[21:58:21] <cradek> part of the normal estop is hardware, so if you want to emulate the out->in you should do it at the hal level
[21:59:58] <alex_joni> bummer
[22:00:05] <alex_joni> wrong approach :(
[22:00:12] <cradek> ?
[22:00:23] <alex_joni> there is a while inside simIoControl
[22:00:45] <alex_joni> but in it there's a blocking read to NML_command
[22:00:58] <alex_joni> so that while can't be used for status output...
[22:01:14] <alex_joni> because the status outputs only when there's a new command
[22:01:17] <alex_joni> :(
[22:03:17] <alex_joni> and that's not the way to go...
[22:43:25] <alex_joni> cradek: do you know how I could debug the app?
[22:44:10] <cradek> alex_joni: what do you mean?
[22:44:23] <alex_joni> set a breakpoint, check some values... etc
[22:44:30] <alex_joni> I think gdb does the job
[22:44:37] <alex_joni> but I've never used it though
[22:44:40] <cradek> sure I know how to use gdb
[22:45:04] <cradek> basic operation is this:
[22:45:08] <cradek> start the program
[22:45:15] <cradek> attach to it with gdb, program operation stops
[22:45:19] <cradek> set breakpoints, etc
[22:45:25] <cradek> tell program to continue
[22:45:48] <cradek> now, do something that causes the breakpoints to be hit, debug
[22:46:12] <alex_joni> I see
[22:46:25] <cradek> so you want to debug simio?
[22:46:35] <alex_joni> minimilltask
[22:46:42] <cradek> ok, start everything up
[22:46:53] <alex_joni> milltask
[22:47:00] <alex_joni> running
[22:47:01] <cradek> then run `gdb /path/to/milltask 12345' where 12345 is the PID of the running milltask
[22:47:46] <alex_joni> ok it attached
[22:48:03] <cradek> (gdb) break some_function_name
[22:48:11] <alex_joni> I see that it stopped (heartbeat not increasing)
[22:48:17] <cradek> (gdb) continue
[22:49:09] <alex_joni> it said Continuing.
[22:49:32] <cradek> so now, do whatever in emc to make it call that function, and it will freeze there and give you back the (gdb) prompt
[22:49:36] <alex_joni> right after that it said Breakpoint 1, some_function_name (that means the breakpoint has been reached?)
[22:49:41] <cradek> yes
[22:49:53] <alex_joni> ok, what can I do now?
[22:49:54] <cradek> now you can use "next" to run one line
[22:50:02] <cradek> "step" to follow into called functions
[22:50:11] <cradek> "print" to examine variables
[22:50:30] <cradek> just hitting return repeats the last command (handy for step, next)
[22:50:43] <cradek> "continue" will let it continue running (until the next breakpoint)
[22:52:20] <cradek> "finish" finishes this function and stops at the caller
[22:52:37] <cradek> "bt" show backtrace (who called who?)
[22:52:45] <cradek> and a million other things...
[22:53:06] <alex_joni> oh.. ok
[22:53:16] <alex_joni> can I set a breakpoint on a variable?
[22:53:27] <cradek> (gdb) watch variable_name
[22:53:33] <cradek> will tell you when it changes
[22:53:54] <cradek> you can set a breakpoint at a certain line of a file by file.c:1234
[22:54:00] <cradek> (gdb) break file.c:1234
[23:05:41] <alex_joni> I really hate this ...
[23:05:46] <cradek> what?
[23:06:08] <alex_joni> I don't know how to send a NML message with the status
[23:06:21] <alex_joni> it just doesn't arrive where it should
[23:06:23] <cradek> ask me a gdb question instead
[23:06:30] <cradek> :-)
[23:06:32] <alex_joni> and I am convinced it's something I did ;)
[23:08:22] <alex_joni> btw.. you could add some debug info to axis
[23:08:27] <alex_joni> like heartbeat & such
[23:09:50] <cradek> yeah it doesn't have any of that stuff
[23:10:12] <cradek> I don't know if we should try to replicate everything tkemc has. It would be a lot of work and I'm not sure about the payoff.
[23:10:16] <alex_joni> that's why I switched back to tkEmc
[23:10:21] <alex_joni> for nwo
[23:10:22] <alex_joni> now
[23:11:54] <cradek> that's what I would do too
[23:15:57] <robin_sz> meep?
[23:16:27] <acemi> can i use emc with rtai without adeos patch?
[23:18:10] <alex_joni> you need some patch
[23:18:28] <alex_joni> adeos or the older rthal
[23:18:43] <alex_joni> meep robin
[23:18:49] <acemi> hmm
[23:19:01] <alex_joni> * alex_joni is near to going crazy bc of this NML stuff ;)
[23:28:38] <alex_joni> robin: you still know a bit about RCS?
[23:38:02] <gezr> sup robin_sz , I may need a bit of your knowldge later,
[23:38:27] <gezr> robin_sz : reguarding cvs
[23:39:28] <gezr> and I think I can win the valve seat battle
[23:39:34] <alex_joni> gezr: maybe I can help?
[23:40:09] <gezr> alex_joni : anyone can assist me, doesnt really matter, im just setting it up locally, and I want to wack at it a bit from howtos and such first
[23:40:25] <alex_joni> ask away
[23:40:33] <alex_joni> * alex_joni will be around for at least half an hour
[23:40:57] <gezr> I havent ran into enough problems just yet to ask a good question, I could fire off from the hip and get further lost :)
[23:47:10] <alex_joni> I'll think I'll commit what I have so far, and go to bed after that
[23:47:41] <gezr> alex_joni : youll be on tommrow wont you?
[23:49:14] <alex_joni> I hope so
[23:49:24] <alex_joni> depends on how I'll have time at work
[23:49:37] <alex_joni> but you could mail me if you get into trouble
[23:49:49] <alex_joni> although all CVS I did I was able to google out ;)
[23:49:56] <gezr> this isnt a pressing issue for me, it seems like just a permision type issue, I havent searched it out
[23:51:36] <gezr> I devoted 4 hours at least to the bike today :)
[23:51:41] <gezr> that makes me fell good
[23:52:52] <CIA-5> 03alex_joni * 10emc2/ (3 files in 3 dirs): added some first support for HW-ESTOP. I'm not happy with the way to pass this to EMC through NML, this needs to be fixed.
[23:55:20] <alex_joni> gnight
[23:55:27] <gezr> take it easy
[23:55:41] <alex_joni> * alex_joni was beaten by RCSLIB ;)