#emc | Logs for 2005-02-20

Back
[00:02:16] <alan_01> anyone have problems getting axis or emc2 to connect to xserver
[00:03:06] <alan_01> nevermind
[01:33:08] <roel1> im off to sleep see yah
[01:43:26] <Jymmm> * Jymmm secretly installs XP on K`zan machines.... ALL OF THEM!
[01:45:21] <paul_c> * paul_c kicks Jymmm
[01:46:20] <Jymmm> * Jymmm epoxies a "XP installer" network boot rom into paul_c systems!
[01:46:44] <paul_c> paul_c has kicked Jymmm from #emc
[01:47:01] <paul_c> Ooo... autojoin hey...
[01:47:03] <Jymmm> Win95?
[01:47:29] <Jymmm> pre USB support =)
[01:47:56] <paul_c> don't use USB anyway
[01:48:30] <Jymmm> ok.... Win95a with shitty networking!
[01:49:18] <Jymmm> paul_c: so, is this your baby (#emc) ?
[01:49:36] <paul_c> yup
[01:49:44] <Jymmm> emc itself too?
[01:49:58] <paul_c> nope - See the guys at NIST for that.
[01:50:07] <Jymmm> ah, ok.
[01:50:18] <paul_c> my only other claim to fame is the BDI disks
[01:50:31] <Jymmm> well that's cool.
[01:51:11] <Jymmm> I'm still in the "need to figure out hardware" stage
[01:51:43] <paul_c> as in "computer" or "mill" ?
[01:52:02] <Jymmm> mill/router/LASER
[01:52:07] <Jymmm> I want laser
[01:52:36] <paul_c> that will cost..
[01:53:02] <Jymmm> I was/am seriously shopping for a laser engraver. 12x24" @ 35W, been quoted $14K USD
[01:53:29] <Jymmm> I'm this close ---->|<---- to buying it.
[01:53:54] <Jymmm> but I have a ahrd time dealing with only 12x24"
[01:54:00] <Jymmm> much less the wattage
[01:54:41] <Jymmm> robin suggested china for the laser, as a 10W here would be $1800
[01:54:53] <Jymmm> 100Watt would be $15000
[01:55:45] <Jymmm> paul_c: is this hobby or business for you?
[01:55:53] <Jymmm> cnc mill that is
[01:56:35] <paul_c> don't do metal cutting for a living.
[01:58:37] <Jymmm> ah... I'm trying to do this as a new venture myself.
[02:02:33] <paul_c> * paul_c is trying to reconcile the differences in the emc2 src tree to the local 2.6 build tree
[02:02:58] <Jymmm> * Jymmm don't do CVS
[02:06:46] <paul_c> you should have made yourself known three weeks ago
[02:07:00] <Jymmm> why is that?
[02:07:10] <paul_c> I was over in SoCal up until Wednesday
[02:07:28] <Jymmm> Ah, I'm in NoCal
[02:07:51] <paul_c> drove the full length of I5
[02:08:05] <paul_c> (as far as Portland)
[02:08:16] <Jymmm> Oh, you in OR.
[02:08:21] <Jymmm> I'm in San Jose
[02:08:24] <paul_c> was for a few days
[02:08:50] <paul_c> San Jose is just south of S.F. ?
[02:09:02] <Jymmm> yep, about 40 minutes
[02:09:20] <paul_c> did some shopping in Sunnyvale
[02:09:34] <Jymmm> Weird Stuff or Halstead
[02:09:53] <Jymmm> ?
[02:09:58] <paul_c> former
[02:10:14] <Jymmm> Heh.... everyone goes there =)
[02:39:13] <Jymmm> they used to be a LOT better... lots and lots of really cool stuff.
[02:54:39] <danfalck> paul_c: just emailed Feb logs of irc
[02:55:55] <paul_c> Thanks Dan
[03:14:26] <paul_c> Just missing Feb 3rd to Feb 5th now.
[03:29:50] <danfalck> paul_c: yes, for some reason I don't have any logged text from Dec 31 to Feb 6
[03:30:21] <danfalck> might have been the cat changing my settings :)
[03:30:40] <paul_c> Not to worry
[03:30:44] <paul_c> new cat, new logs...
[03:39:06] <CIA-4> 03paul_c 07bdi-4 * 10emc2/ (107 files in 11 dirs): Created another branch for the sources used for BDI-4.xx. Currently, this is a 2.6.xx-rtai only build derived from the main emc code base and using libnml.
[03:39:12] <CIA-4> 03paul_c 07bdi-4 * 10emc2/src/emc/ (103 files in 5 dirs): Created another branch for the sources used for BDI-4.xx. Currently, this is a 2.6.xx-rtai only build derived from the main emc code base and using libnml.
[03:39:19] <CIA-4> 03paul_c 07bdi-4 * 10emc2/tcl/tkemc.tcl: Created another branch for the sources used for BDI-4.xx. Currently, this is a 2.6.xx-rtai only build derived from the main emc code base and using libnml.
[03:42:36] <CIA-4> 03paul_c 07bdi-4 * 10emc2/ (7 files): Created another branch for the sources used for BDI-4.xx. Currently, this is a 2.6.xx-rtai only build derived from the main emc code base and using libnml.
[05:26:54] <asdfqwega> * asdfqwega enters state of altered consciousness to understand Synergy CAD/CAM
[05:31:21] <CIA-4> 03paul_c 07bdi-4 * 10emc2/src/ (67 files in 15 dirs): The last remaining files for the 2.6.xx build - *may* be some bugs to fix...
[05:31:26] <CIA-4> 03paul_c 07bdi-4 * 10emc2/src/libnml/ (44 files in 4 dirs): The last remaining files for the 2.6.xx build - *may* be some bugs to fix...
[05:49:36] <CIA-4> 03paul_c 07bdi-4 * 10emc2/src/ (5 files in 2 dirs): Tidy up a few loose ends with the 'make clean' rule.
[06:04:27] <CIA-4> 03paul_c 07pc_2_6_test * 10emc2/README: Note branch status - Now retired.
[06:24:23] <CIA-4> 03paul_c 07bdi-4 * 10emc2/src/ (configure configure.in): Fix the first error - RTAI math module not correctly identified.
[08:08:27] <K`zan> Night all
[08:08:34] <Jymmm> G'Night
[08:11:16] <Jymmm> asdfqwega: Whats so hard about it... It's just like MS-Paint!
[08:15:17] <Jymmm> =)
[08:51:33] <Jymmm> Jymmm is now known as Red70sShow
[08:51:33] <Red70sShow> Red70sShow is now known as Jymmm
[09:03:58] <Jymmm> Jymmm is now known as CodesWithIdiots
[11:17:54] <frankiemc> test
[11:18:12] <alex_joni> hello frankiemc
[11:20:58] <frankiemc> Oooppps ... already somebody here ... I just was testing to see if my knowlege of irc is still sufficient to operate chatzilla :-)
[11:21:17] <frankiemc> last time I used irc is may years in the past ...
[11:21:18] <alex_joni> you can ask away if you got questions
[11:21:52] <alex_joni> the main goal is to use emc around here, so limited knowledge of irc is acceptable ;-)
[11:23:19] <frankiemc> btw, frankiemc is the guy with the question regarding emc on kernel -2.6 and rtai-3.1 :-) maybe I should change this nick to my realname ...
[11:23:46] <alex_joni> use /nick newnick
[11:24:03] <alex_joni> for changing the nick ;)
[11:24:49] <alex_joni> seems paul_c got busy last night, and put the sources for emc (2.6 & rtai-3.1 compileable) on CVS
[11:26:38] <frankiemc> frankiemc is now known as frank
[11:27:02] <frank> frank is now known as frank_j
[11:29:17] <frank_j> Yes, I've already seen that. I checked out with the given tag and tried to compile. But it stops with an error in a very early stage (make headers for libnml). Due to some family buisiness today I was not yet able to take a deeper look at this problem
[11:31:10] <frank_j> But for exactly this family buisiness I've to leave now. IRC is under control (for me) ... AFAIR emc-chat was inbetween 14 and 18 utc, right?
[11:31:37] <alex_joni> it's whenever you got time
[11:31:39] <alex_joni> ;)
[11:32:02] <alex_joni> usually it gets busier later
[11:32:02] <alex_joni> around 18-20 GMT
[11:32:52] <frank_j> Is it possible to password-protect a nick name?
[11:32:59] <alex_joni> sure
[11:33:04] <alex_joni> you need to register it
[11:33:37] <frank_j> Ok, 18-20 is much better (to not become stress with my family :-)))
[11:33:54] <frank_j> And how to register?
[11:33:54] <alex_joni> use /msg NickServ REGISTER
[11:34:01] <alex_joni> catch you then
[11:34:11] <alex_joni> type the above command
[11:34:17] <alex_joni> or use /msg NickServ help
[11:34:24] <alex_joni> to read more about it
[11:34:37] <alex_joni> and /msg NickServ help REGISTER
[12:32:45] <Imperator_> Morming all
[12:58:05] <les> morning
[13:14:36] <anonimasu> hello everyone
[13:16:05] <alex_joni> hello
[13:16:16] <alex_joni> * alex_joni just finished eating ;)
[13:16:23] <anonimasu> nice
[13:16:25] <anonimasu> :)
[13:16:56] <anonimasu> I am working
[13:17:29] <alex_joni> what?
[13:17:47] <alex_joni> I finished downloading 2.6.10 ;)
[13:17:57] <anonimasu> nice
[13:30:23] <anonimasu> :)
[13:33:02] <alex_joni> hello SWPadnos
[13:33:44] <Imperator_> Hey Alex alive again ?
[13:33:51] <anonimasu> I am just going to finish this then i am going to go back home
[13:33:59] <anonimasu> and look for the error on the Z axis..
[13:34:05] <alex_joni> hey Martin.. looks like it
[13:34:25] <Imperator_> :-)
[13:35:12] <SWPadnos> Has anyone else tried to compile the new bdi-4 CVS branch?
[13:35:23] <SWPadnos> (I only ask because it doesn't work for me)
[13:35:38] <anonimasu> how much is different from emc2?
[13:35:57] <SWPadnos> It's supposed to compile on kernel 2.6 systems
[13:36:05] <anonimasu> oh ok
[13:36:15] <alex_joni> an0n: working on the PWM again?
[13:36:47] <anonimasu> not today the people in germany tried replicating the bug but it didnt appear..
[13:36:53] <alex_joni> it's an emc1 with libnml
[13:36:53] <alex_joni> SWPadnos: what breaks?
[13:36:58] <anonimasu> they were running a newer os.. on the plc they tested it on..
[13:38:35] <anonimasu> so I was on my way to germany to kill em all at friday.. had a pretty bad day, nothnig worked as it were supposed to
[13:38:54] <anonimasu> just kidding..
[13:39:44] <anonimasu> but nothing went the way it should.. heh I decreased the accel on the Z axis later on the afternoon but I ended up with the same problem with it anyway just way more noticeable..
[13:40:15] <alex_joni> strange
[13:40:26] <alex_joni> an0n: maybe the reading you did is wrong
[13:40:38] <alex_joni> to tune your scale
[13:40:49] <anonimasu> hm, it's exact I checked it with a micrometer..
[13:40:54] <anonimasu> err dial indicator..
[13:41:08] <alex_joni> check it on a larger move
[13:41:13] <alex_joni> move 1'' or so
[13:41:29] <anonimasu> the problem is that it goes down into the workpiece.. and when it's going up it dosent come up al the way it's moved down
[13:42:09] <SWPadnos> Missing files are nml_mod.{cc,hh} in libnml/nml
[13:43:01] <alex_joni> from what files included?
[13:43:03] <alex_joni> nml_mod is found in rcslib (not the new libnml)
[13:44:12] <SWPadnos> It may just need to be removed. I did try that, and was held up by the various includes
[13:44:22] <SWPadnos> iotask/emcio.hh. task/bridgeporttaskintf.cc, task/emcpanel.cc, task/emctaskmain.cc (...)
[13:45:19] <SWPadnos> I thought they might not be necessary, so I just made empty files, which is when I found out about inb/outb in parport.c
[13:47:10] <alex_joni> * alex_joni is looking at parport.c
[13:47:43] <SWPadnos> incidentally, the nml_mod files may not be necessary, I just haven't gotten through a make yet.
[13:47:48] <anonimasu> I am wondering what the error might be..
[13:48:15] <anonimasu> alex_joni: the axis is spring loaded so it should come back up
[13:49:47] <alex_joni> I think nml_mod is not used anymore
[13:49:57] <alex_joni> SWPadnos: inb and outb should be in <asm/io.h>
[13:49:58] <SWPadnos> sorry - red herring on parport.c
[13:50:01] <alex_joni> can you check there?
[13:54:53] <SWPadnos> Well - parport.c doesn't include asm/io.h
[13:55:06] <SWPadnos> it does include asm/bitops though
[13:55:06] <alex_joni> how come?
[13:55:18] <SWPadnos> good question! :)
[13:55:52] <alex_joni> hmmm.... I'm looking at the wrong file ;)
[13:55:52] <alex_joni> I can see bitops.h
[13:56:03] <alex_joni> but further in the file there's a #ifdef realtime
[13:56:18] <alex_joni> #include <asm/io.h>
[13:56:18] <alex_joni> perhaps realtime is not defined?
[13:56:53] <alex_joni> * alex_joni is looking at the Makefile
[13:56:55] <SWPadnos> oops - I didn't look far enough.
[13:57:40] <SWPadnos> does this build need the PLAT=REALTIME / NONREALTIME stuff?
[13:57:52] <SWPadnos> ls
[13:58:00] <alex_joni> nope.. shouldn't
[13:58:01] <SWPadnos> (damn - two keybaords)
[13:59:33] <SWPadnos> well - for some reason my make log shows the compile as using the non-realtime rule.
[13:59:50] <alex_joni> parport gets compiled twice
[13:59:56] <alex_joni> once as nonrealtime
[13:59:59] <alex_joni> once as realtime
[14:00:17] <SWPadnos> Right - I'll look for inb/outb in the nonrealtime part
[14:01:17] <SWPadnos> actually, the nonrealtime section uses sys/io.h, which (according to a comment) is supposed to provide inb/outb as well.
[14:01:43] <alex_joni> maybe that's where it's failing?
[14:04:48] <SWPadnos> hmmm... inb and outb are defined in sys/io.h
[14:18:54] <Imperator_> SWPadnos: what exactly do you want to do ?? Maybe I can help
[14:18:56] <alex_joni> Imperator_: any luck with that NML last night?
[14:19:16] <Jymmm> ok, what is 'NML' ?
[14:19:20] <Imperator_> I have stoped half an hour later.
[14:19:22] <alex_joni> Imperator_: SWPadnos is trying to compile emc on 2.6
[14:19:24] <SWPadnos> I'm just trying to get a clean compile at this point.
[14:19:32] <alex_joni> it's the Neutral Message Language
[14:19:38] <Imperator_> oh, ok then I cant help
[14:19:45] <SWPadnos> Later, I'll be working on several things, including the pico-systems driver for emc2/kernel2.6
[14:20:01] <Jymmm> * Jymmm <---- Deer w/ headlight look on face
[14:20:22] <Imperator_> I will go on with that NML stuff in half an hour
[14:20:38] <alex_joni> part of RCSLIB
[14:20:38] <alex_joni> SWPadnos: first we need a compile-able emc2 on 2.6
[14:20:38] <alex_joni> Jymmm: don't feel bad ;) most don't get this stuff anyways
[14:20:45] <alex_joni> including most of us ;)
[14:20:57] <Imperator_> hehe
[14:20:58] <Jymmm> lol
[14:21:16] <alex_joni> there are some docs at NIST, if you are curious though
[14:21:23] <Jymmm> * Jymmm is like.... "Neutral Message Language" WTF is that?!
[14:21:40] <Jymmm> is it a scripting lang of some sort?
[14:21:49] <alex_joni> it's a collection of classes
[14:21:56] <alex_joni> to push messages around
[14:22:06] <alex_joni> between various emc-components
[14:22:23] <les> hello
[14:22:26] <alex_joni> it makes the messages language and hardware independent
[14:22:26] <SWPadnos> The version I have is an EMC2 version specifically meant for compiling on 2.6
[14:22:42] <Jymmm> alex_joni: Wouldn't a crack dealer be easier?
[14:22:51] <SWPadnos> (That's why I'm trying to get it to work :) )
[14:23:06] <alex_joni> thus beeing able to be ported on c,c++,ada, etc (linux, doze, sunos, etc.)
[14:23:11] <alex_joni> hey les
[14:23:16] <les> I was wondering if inverse kinematics are written for a typical 5 axis setup
[14:23:33] <alex_joni> not that I know of.. ;)
[14:23:41] <les> x,y,z, vertical rotation and tilt on the end of that
[14:23:43] <alex_joni> you mean 3-carthesian + 2 rotatory?
[14:23:48] <les> yeah
[14:24:06] <alex_joni> hmmm... don't think so
[14:24:10] <les> might take the plunge to 5 axis
[14:24:21] <alex_joni> cool
[14:24:26] <les> perhaps I could write them
[14:24:44] <Jymmm> alex_joni: HW independant... that I understand =)
[14:25:12] <les> I made the huge z axis travel in part to make an easy 5 axis conversion
[14:25:40] <alex_joni> darn
[14:25:45] <alex_joni> I gotta leave
[14:25:50] <alex_joni> I'll be back later :(
[14:26:30] <anonimasu> ok
[14:26:31] <anonimasu> laters
[14:28:01] <les> I was planning on a head setup like this:
[14:28:07] <les> http://www.pdscolombo.com/fiveaxis_wood.htm
[14:28:23] <les> that goes on the end of z
[14:29:40] <les> I don't think the inverse kinematics would be very complicated for that
[14:32:04] <SWPadnos> I'd think it would be mostly dependent on whether the head has a slipring or not.
[14:32:20] <SWPadnos> If so, it should be fairly easy.
[14:33:11] <alex_joni> bye guys
[14:33:27] <SWPadnos> nevermind - I just actually read the specs :) It has a limited tilt/rotation range.
[14:35:25] <les> yes it only needs one revolution I guess in one axis and 180 in the other
[14:35:48] <les> I am looking at code like scarakins.c
[14:36:15] <SWPadnos> where is that?
[14:36:42] <les> it's in the disribution tarball
[14:37:10] <les> puma560kins.c has a lot of functions....Jacobeans, etc
[14:37:31] <les> looks like it would eat up some serious processor time
[14:41:46] <les> anyway even with the 3 axis now we are doing faily well
[14:42:13] <les> hi paul
[14:42:20] <Jymmm> les : Heh.... That looks like something off some alien robot sent to destroy Earth!
[14:42:41] <les> yeah
[14:42:55] <les> If I did it I would make my own
[14:43:11] <les> those things prob cost as much as a house...
[14:43:22] <Imperator_> Hi Paul
[14:44:11] <anonimasu> les: they do..
[14:44:12] <paul_c> Afternoon all.
[14:44:32] <Jymmm> les: Um... why does it reference power as 12Kw??????
[14:44:40] <les> yup
[14:45:00] <Jymmm> les: is this a laser?
[14:45:10] <anonimasu> I havent seen ones like that exactly but they cost over $50k
[14:45:11] <les> no just a router motor
[14:45:25] <Imperator_> paul_c: Alex has left 5 min before. He has modified his board and is asking if you can take a look
[14:45:34] <Jymmm> les: WTF?! a router motor needing 12KW ?!
[14:45:38] <paul_c> url ?
[14:45:48] <anonimasu> that was http://www.pdscolombo.com/fiveaxis_wood.htm
[14:45:56] <les> haha yes....
[14:46:03] <Jymmm> DAMN
[14:46:04] <anonimasu> i dont know about that one though, but I saw some on cnczone..
[14:46:11] <anonimasu> some good 5axis mill head..
[14:46:22] <les> It's like my jobs now....twice the power...twice the money
[14:46:29] <Imperator_> http://www.robcon.ro/emc/
[14:47:12] <les> I think I am about ready to buy a Colombo router
[14:47:28] <les> 7.5 kW
[14:48:04] <les> That is about as much as I can run without serious electrics rewiring in the shop
[14:49:25] <les> oonly running 2 kW now and it makes my day a lot longer than it needs to be
[14:49:48] <Jymmm> les: Come on... you don't have any high voltage lines around you could just run "jumper cables" to?
[14:49:59] <les> haha
[14:50:09] <SWPadnos> You must use a lot of coolant :)
[14:50:14] <les> just 240 100 amp
[14:50:30] <les> coolant is a supersonic blast of air
[14:50:39] <Jymmm> les: What, you can't climb a telephone pole?
[14:51:00] <les> ha yeah
[14:51:35] <Jymmm> les ; Fine.... Just get an old finish reel and a small sinker......
[14:51:39] <Jymmm> fishing
[14:52:07] <les> with a well insulated handle
[14:52:18] <SWPadnos> paul_c: I've been having some trouble with the bdi-4 cvs branch (are you the correct Paul? :) )
[14:52:35] <anonimasu> hehe
[14:52:47] <Jymmm> les: handle? what handle?
[14:53:02] <SWPadnos> just hold one wire at a time, and you should be fine.
[14:53:09] <SWPadnos> (insulated shoes)
[14:53:12] <anonimasu> heh
[14:53:17] <anonimasu> somehow I think that's suicide..
[14:53:33] <SWPadnos> I haven't tested it, but the theory is sound :)
[14:53:38] <Jymmm> SWPadnos: 12K Volts has a tendancy to hop =)
[14:53:52] <SWPadnos> Oh - THOSE lines :)
[14:54:01] <paul_c> SWPadnos: yes, no, looking at it now.
[14:54:03] <SWPadnos> You just need taller shoes - 1.5 inches or so
[14:54:14] <Jymmm> s/inches/feet/
[14:54:20] <anonimasu> yeah
[14:54:26] <anonimasu> agreed
[14:54:35] <les> I think I have a 400 amp transformer
[14:54:40] <les> but shared
[14:54:43] <SWPadnos> (arcing voltage in air is roughly 8KV/inch)
[14:55:19] <SWPadnos> paul_c: he problem is in parport.c - for some reason, he nonrealtime compile doesn't pick up inb/outb from sys/io.c
[14:55:22] <Jymmm> SWPadnos: so what would 4ft arc be then?
[14:56:09] <SWPadnos> 4*12*8kV = 384kV, unless there's humidity or something
[14:56:31] <les> actually I need only 18 amps or so to run the motor I am looking at
[14:56:32] <Jymmm> SWPadnos: hold that thought....
[14:56:39] <les> I have enough for that
[14:58:16] <paul_c> What kernel are you using ?
[14:58:46] <SWPadnos> 2.6.9 with Adeos / RTAI fusion.
[14:59:00] <SWPadnos> I have checked sys/io.c, and inb/outb are there
[14:59:16] <SWPadnos> I'm not sure it's getting found correctly
[15:00:51] <SWPadnos> (though I would expect a "missing include file" error, rather than "implicit declaration of inb"
[15:01:00] <Jymmm> SWPadnos: Here ya go!!! http://www.maintenance-news.com/cgi-script/CSUpload/CSUpload.cgi?database=vibetalk.db&command=viewupload&id=29
[15:01:33] <Jymmm> turn volume up too!!!!
[15:01:39] <SWPadnos> cool, man!!!
[15:01:40] <paul_c> "implicit delaration" is the standard warning - gcc doesn't know if a header is missing..
[15:02:29] <SWPadnos> Wouldn't it complain if an included filedoesn't exist???
[15:02:56] <paul_c> if the header had been declared, yes.
[15:05:15] <SWPadnos> huh? I just added "gobbledygook.h" to the includes in parport.c, and I get an error "no such file or directory" - so I guess sys/io.h is getting found OK. (since I don't get that error for it)
[15:08:33] <paul_c> Give me a few mins to work on it - It looks like I might have gotten a makefile or two mixed up.
[15:09:31] <les> I'm going to go out and sharpen carbide end mills for a bit
[15:09:33] <les> later
[15:09:38] <SWPadnos> OK. Actually, I'm going to have to leave for a couple of hours. I'll be back around 1:00 EST
[15:24:08] <SWPadnos> paul_c: one last thing before I leave - the files nml_mod.{cc,hh} are missing in the libnml/nml subdir - It's probably a makefile problem (plus removing an include or two).
[15:24:18] <SWPadnos> on that note
[15:24:25] <SWPadnos> * SWPadnos leaves for a while
[15:45:56] <SteveStallings> morning John
[15:46:02] <jmkasunich> morning
[15:48:13] <CIA-4> 03paul_c 07bdi-4 * 10emc2/src/ (12 files in 4 dirs): Missed a couple of files and also used the wrong Makefile.inc template..
[15:51:22] <Imperator_> Morning John
[15:51:48] <jmkasunich> hi martin
[15:52:47] <Imperator_> Alex teached me about NML last night, but I still prefer to kick it :-)
[15:55:07] <Imperator_> about support for gantry axis:
[15:55:50] <Imperator_> I will insert a function in control.c before "output_to_hal(void);" that will do all that gantry stuff
[15:56:44] <Imperator_> so if it is not needed it is only one "if" command more
[15:56:52] <jmkasunich> ok
[15:57:47] <Imperator_> maybe I add also some code to homing, but maybe it is not nesessary
[15:57:54] <Imperator_> not shure at the moment
[15:58:18] <Imperator_> and some NML messages :-(
[16:00:06] <CIA-4> 03paul_c 07bdi-4 * 10emc2/src/emc/drivers/ppmc/ (6 files): Remove a few errant object files that shouldn't be in the repository.
[16:03:48] <CIA-4> 03paul_c 07bdi-4 * 10emc2/src/libnml/Makefile.lib: clean rule was removed in error...
[16:16:38] <jmkasunich> pretty quiet today.....
[16:17:29] <SteveStallings> has been all week
[16:17:42] <rayh> Hi John -- Matt Sh said to put his name on the code list.
[16:18:00] <jmkasunich> for the fest? will do
[16:19:18] <jmkasunich> Fest info (for those who don't know): http://www.linuxcnc.org/EMC_news_history/Programmers-Fest2005.html
[16:19:26] <rayh> Thanks.
[16:19:36] <SteveStallings> anyone besides Ray planning to get to Rolands seminar?
[16:20:04] <SteveStallings> I am hoping to go, but it is a long drive.
[16:20:28] <rayh> Dave and Frau
[16:20:34] <rayh> Matt S maybe
[16:20:53] <SteveStallings> Frau?
[16:21:01] <rayh> 2-3 guys from LaCrosse WI.
[16:21:08] <rayh> SWIMBO
[16:21:11] <SteveStallings> k
[16:21:26] <rayh> Typing is entropic today.
[16:21:36] <SteveStallings> nien speiken Deutsch
[16:21:39] <rayh> Bob S from Weber systems
[16:21:54] <rayh> ich auch
[16:22:27] <rayh> Synergy will have CAD/CAM demos for 2 days.
[16:22:58] <SteveStallings> neat, do you know which days? If I go it will be the weekend
[16:23:16] <rayh> I'm planning sacraficial installs of EMC all week.
[16:23:29] <rayh> Start on monday end the next sunday.
[16:23:37] <jmkasunich> wow
[16:23:52] <SteveStallings> oops, I was asking about Weber demo days....
[16:24:05] <rayh> Synergy was talking about Friday, Sat, and perhaps Sunday morning.
[16:24:10] <SteveStallings> great
[16:24:13] <CIA-4> 03paul_c 07bdi-4 * 10emc2/src/ (Make.rules Makefile Makefile.inc.in): Reduce cruft in the Makefile.inc template - We ca always put it back if/when required..
[16:25:26] <rayh> Roland plans a stepper desktop conversion and a bridgeport stepper conversion.
[16:25:50] <SteveStallings> hope Roland firms things up and announces soon. I would like to put something on LinuxCNC, but hesitate to do so until he has info on his site
[16:25:51] <rayh> Dave and I are thinking Bridgeport servo conversion with some sort of tool changer.
[16:26:20] <rayh> Talked with him a bit ago. Plans on a page in a few days. We can link to it.
[16:27:02] <rayh> He's got a URL -- cant remember the name. CNC???
[16:27:23] <SteveStallings> www.cardinaleng.com
[16:27:32] <jmkasunich> strange.... I had no prob connecting to linuxcnc.org with GFTP 10 mins ago, but now it won't connect (retried multiple times)
[16:27:37] <rayh> JonS is not far away from Roland's
[16:27:53] <rayh> Would like to use him and pico for conversion.
[16:28:05] <jmkasunich> you mean JonE?
[16:28:11] <rayh> Would also like to get Abdul there for Vital
[16:28:12] <SteveStallings> could have been connection saturation, looks OK at the moment
[16:28:21] <rayh> Yep Jon E
[16:29:09] <rayh> I'd like to run IO workshops with a wide variety of boards.
[16:30:14] <paul_c> Got a new board to write a driver for...
[16:30:29] <rayh> If I can find a pic programmer that can attend I'd like some serial stuff as well.
[16:30:36] <rayh> What is it?
[16:30:56] <paul_c> Sensoray 526
[16:31:09] <rayh> Got a link?
[16:31:20] <paul_c> one mo.
[16:31:32] <SteveStallings> www.sensoray.com
[16:31:38] <rayh> I've got an ethernut here connected to my linux box.
[16:31:43] <jmkasunich> Matt's been added to the list, we now have 5 confirmed attendees
[16:31:53] <jmkasunich> I made my motel reservations this week
[16:31:54] <rayh> www.ethernut.de
[16:32:06] <paul_c> http://www.sensoray.com/html/526data.htm
[16:32:09] <rayh> You getting there on Sunday or Saturday.
[16:32:16] <jmkasunich> sunday evening
[16:32:38] <jmkasunich> probably leave home around 4-5 and get there 10-11pm
[16:32:59] <jmkasunich> leaving for home Thursday night (don't want to pay for one more night)
[16:33:13] <rayh> So it starts Monday.
[16:33:16] <jmkasunich> yep
[16:33:25] <rayh> And ends thursday.
[16:33:38] <jmkasunich> yep
[16:33:49] <rayh> Got any evening things planned at the motel or nearby.
[16:34:13] <jmkasunich> dates are on the page, but could be a little more obvious
[16:35:09] <jmkasunich> nothing specific planned, I figured most folks would wind up eating dinner together and then retire to a room for talking, etc
[16:35:16] <rayh> I guess I was wondering if the NIST reservation was bracketing the activity or if there might be other things scheduled around it.
[16:35:22] <jmkasunich> open to suggestions
[16:37:31] <rayh> I'm working with Matt the week before
[16:37:34] <paul_c> can we play with the hexapod ??
[16:37:44] <rayh> And delivering a machine the week after.
[16:37:56] <rayh> Which one?
[16:38:01] <jmkasunich> dunno, Fred said a Sherline and a B'port would be available, nothing about a hexapod
[16:38:23] <paul_c> darn - They have a biggie down in the workshop
[16:38:24] <rayh> We could probably play with the cable versions.
[16:38:27] <SteveStallings> I will be at NAMES through Sunday afternoon, then overnight in Columbus or possibly catching a ride Sunday with someone.
[16:38:34] <rayh> Ingersol
[16:38:47] <paul_c> that's the one
[16:38:57] <SteveStallings> Is it still there?
[16:39:10] <rayh> The big hex has laser strut length.
[16:39:54] <jmkasunich> I may have a 2 axis mini-servo testbed by then
[16:39:57] <rayh> Don't know if they have applied EMC to it?
[16:40:02] <paul_c> back in ten...
[16:40:12] <rayh> Wouldn't hurt to ask.
[16:40:27] <jmkasunich> salvaged the mechanics from an automated tape backup machine (dumpster)
[16:40:50] <jmkasunich> two linear rails, two leadscrews, and a pair of small servomotors (1"dia x 2" long) with encoders
[16:41:17] <SteveStallings> nifty stuff 8-)
[16:41:37] <SteveStallings> wish we had dumpsters like that around here
[16:42:00] <rayh> Nice, John.
[16:42:09] <jmkasunich> the data security folks got a little upset when I pointed out that they had scrapped it without removing the 10 tapes in the magazine
[16:42:47] <jmkasunich> hmmm... I guess that thing was basically a "toolchanger" for a tape drive ;-)
[16:43:47] <SteveStallings> gee, I have a couple of old Exabyte changers, planned to acutally use, but capacity is marginal, perhaps more useful for parts
[16:44:28] <jmkasunich> these are too small/weak for machining, but handy for testing/demos
[16:45:23] <SteveStallings> think small, RC model car motor with collet adapter directly on motor shaft
[16:45:44] <jmkasunich> I'd have to come up with something for a Z axis too
[16:45:56] <jmkasunich> the travels are about 10" and about 4"
[16:46:20] <SteveStallings> pretty useful for small engraving
[16:46:20] <jmkasunich> each axis uses only one rail, so they're overhung quite a bit, not very rigid at all
[16:47:56] <SteveStallings> how about a baby version of the CNC punch like the one at NAMES last year, use a hand punch, no Z axix, no side loads
[16:48:07] <rayh> How about the 10 being y, the 4 being z and make a gantry or bridge.
[16:48:49] <jmkasunich> any of those suggestions will take more time than I'll be able to give it before the fest
[16:49:14] <jmkasunich> I'll be happy if I can come up with some simple amps and use it to test servo homing and such
[16:49:22] <SteveStallings> true, and your time is better spent on software issues
[16:49:58] <jmkasunich> I need to take a closer look at the hardware, the screws are pretty high pitch, I bet one encoder count is 0.001 or greater, maybe much greater
[16:50:07] <paul_c> I have some spare Copley servo amps
[16:50:12] <jmkasunich> stuffing a tape into a drive doesn't need 0.0001 accuracy
[16:50:28] <jmkasunich> overkill for this - these motors are probably 24V 1A tops
[16:56:55] <jmkasunich> hopefully this is a little more clear: http://www.linuxcnc.org/EMC_news_history/Programmers-Fest2005.html
[16:57:04] <SteveStallings> will running these small motors without tach feedback be a challange?
[16:57:19] <jmkasunich> they have encoders (but not analog tachs)
[16:57:59] <SteveStallings> right, so will you need encoder to velocity derivation in the servo amp?
[16:58:15] <jmkasunich> not neccssarily
[16:58:22] <SteveStallings> or run torque mode?
[16:58:26] <rayh> Didn't JonE test his pwm stuff without tach feedback
[16:58:26] <les> just use some I and D with current mode
[16:58:30] <jmkasunich> right
[16:58:52] <les> I don't use tach feedback
[16:58:54] <jmkasunich> lurking in the back of my mind I have an idea for ultra-cheap servo - an H bridge connected to a parport
[16:59:08] <jmkasunich> probably won't work, but I want to try it some day
[16:59:31] <rayh> If you wanted to build the bridge with your table, I'd build the x
[16:59:38] <rayh> To slide under it.
[16:59:40] <SteveStallings> that is close to what MaxNC does with their closed loop system
[17:00:13] <SteveStallings> MaxNC put encoders on steppers and runs them like 50 pole PM servos
[17:00:33] <rayh> Got 2 59 inch thompson rails with four cars. Kerk backlash compensation rail
[17:00:34] <jmkasunich> I need to bring it home (it's currently under a table in the lab) and examine it closer to see what can be done with it
[17:00:43] <les> If anyone ever wants to use my shop for making machines they are welcome to
[17:00:46] <jmkasunich> that's massive overkill
[17:00:55] <jmkasunich> this thing doesn't even have ballscrews
[17:00:58] <rayh> Pittman 36 volt motor with 500 line encoder and index.\
[17:01:06] <les> We usually have plenty of spare time on the metalworking stuff
[17:01:11] <jmkasunich> they're teflon coated multi-start screws running in plastic nuts
[17:01:21] <jmkasunich> very nice cheap stuff, but still, cheap stuff
[17:01:36] <rayh> Sound like kerk.
[17:01:56] <jmkasunich> dunno... wish it was here right now
[17:02:13] <jmkasunich> actually, I was planning on going in there later today to work on a government job
[17:02:20] <rayh> Is there a spring around a split nut? If yes, then it's antibacklash.
[17:02:21] <jmkasunich> I'll bring it home then
[17:02:44] <rayh> k
[17:02:47] <jmkasunich> more details will be available in about 6 hrs
[17:03:34] <jmkasunich> any ideas for a more detailed Fest agenda?
[17:04:32] <rayh> Developer?
[17:04:43] <jmkasunich> ?
[17:05:02] <jmkasunich> yeah, the april one
[17:05:04] <rayh> The time at NIST?
[17:05:12] <rayh> okay.
[17:05:32] <jmkasunich> sorry, I've been thinking of that one a "the Fest" and the roland thing as "the Roland thing"
[17:05:48] <rayh> I've got a Hardinge lathe there that needs threading?
[17:06:56] <rayh> Are you thinking of concentrating on emc2 during that time?
[17:07:11] <jmkasunich> I will be focused on emc2, but others will not
[17:07:51] <rayh> Paul said a while back that he would be concentrating on the emc2 part of sf.
[17:08:14] <dave-e> maybe work on the interface to classicladder
[17:08:29] <jmkasunich> yeah... alex has made a start on that
[17:08:40] <dave-e> 1 or2?
[17:08:44] <jmkasunich> I want to work on more HAL drivers
[17:08:46] <jmkasunich> 2
[17:09:11] <jmkasunich> Pete V did a lot of work on a HAL driver for the Vital card this weekend
[17:09:24] <jmkasunich> still needs tested, but lots of progress
[17:10:59] <rayh> How about a general purpose serial driver for EMC2
[17:11:08] <jmkasunich> driver for what?
[17:11:24] <rayh> rs232 to start.
[17:11:40] <jmkasunich> I mean what is on the other end? drives, io, ?
[17:11:51] <rayh> Anything.
[17:11:57] <jmkasunich> pretty tall order
[17:12:13] <rayh> How about IO to start.
[17:12:28] <dave-e> nml link?
[17:12:34] <dave-e> to a plc
[17:12:41] <Imperator_> what about USB ???
[17:12:41] <rayh> No IO in rt.
[17:12:42] <jmkasunich> like StarTrek - it doesn't matter if it's an alien technology with completely unknown protocol, they can interface to it in 5 minutes
[17:13:18] <rayh> How is rtai coming along with rt drivers for USB?
[17:13:29] <jmkasunich> no idea
[17:14:04] <paul_c> As far as I know, there is no RTAI+USB drivers
[17:14:56] <jmkasunich> you thinking about serial pendants and such, Ray?
[17:16:00] <rayh> I'm thinking of a module that takes parallel data in and sends serial out.
[17:16:28] <jmkasunich> "module" as in a bit of hardware, or a software module?
[17:16:36] <rayh> software.
[17:17:22] <jmkasunich> so it would have say 16 HAL pins, and whatever the value of those pins is would be packed up and sent serially?
[17:17:23] <rayh> The big guys do it with can or sircos but I'm thinking less structured than that.
[17:17:46] <rayh> Right.
[17:17:59] <rayh> And a serial return would get put onto those pins.
[17:18:02] <paul_c> to do a 'bit banging' serial driver is easy enough (along the lines of an I2C bus)
[17:18:28] <jmkasunich> well the return would go to other pins, not the same ones
[17:18:29] <rayh> yea yea 'bit banging'
[17:18:42] <jmkasunich> IOW, 16 outputs and 16 inputs, or whatever mix you need
[17:18:45] <rayh> That's the word(s) I couldn't find.
[17:19:22] <jmkasunich> but what is on the other end of the link? another PC running the same SW module? or some kind of IO device?
[17:19:23] <paul_c> 'pends if you need any handshaking in there...
[17:20:02] <rayh> Let's say for now that it's intelligent and knows the same protocol.
[17:20:51] <jmkasunich> now you're getting to the heart of it... what is the protocol... do we define it (and thus we get to design/build the HW) or is it something out there that is a standard
[17:21:13] <rayh> What if it were I2C
[17:21:58] <jmkasunich> I'm no I2C expert, but I don't think that is something you can implement over RS-232 with a standard UART
[17:22:14] <SteveStallings> ModBus is popular for industrial I/O
[17:22:25] <jmkasunich> and DeviceNet
[17:23:34] <rayh> IMO the simpler the protocol the easier to implement on both ends.
[17:23:43] <jmkasunich> agreed
[17:23:56] <rayh> How about pure bit bang as a mod
[17:24:05] <jmkasunich> ?
[17:24:14] <rayh> And then a bunch of filters
[17:24:21] <SteveStallings> on the other hand hardware like you wanted is likely off the shelf in ModBus or DeviceNET form
[17:24:38] <rayh> Like modbus
[17:24:40] <jmkasunich> like these: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&rd=1&item=3873626418
[17:25:15] <rayh> But if I wanted to dedicate an rs232 to a single device
[17:25:23] <rayh> I don't need any of that overhead.
[17:25:39] <jmkasunich> there are several issues - 1) physical layer compatibility (DeviceNet is NOT RS-32 compatible) and 2) Protocol
[17:26:30] <rayh> Let's take an imaginary example
[17:26:32] <SteveStallings> ModBus is usually 485 multidrop, but can be run RS-232 if there is only a single ModBus device present
[17:26:47] <rayh> One axis connected to a singe 232.
[17:26:50] <dave-e> <http://rt-com.sourceforge.net/>
[17:26:51] <jmkasunich> you can see that we're already looking at many different paths, but the basic split is between using existing stuff, with possibley complex protocols, and using stuff that we need to build ourselves, but can use a simple protocol
[17:27:16] <rayh> we need a vel out and a position back
[17:27:27] <rayh> And we need em each servo loop.
[17:27:56] <jmkasunich> oh, so you're going beyond simple bits and transferring ints or floats
[17:28:04] <SteveStallings> yikes, you had not mentioned real time!
[17:28:13] <Imperator_> for a IO-Module i siggest to programm a ATMEL or PIC Controller, then a easy protocol with ECC error correction, for comunication
[17:28:16] <rayh> Yes i did. HAL.
[17:28:31] <SteveStallings> sorry, I didn't get that
[17:28:33] <rayh> Imperator_: has it.
[17:28:52] <jmkasunich> so you _DO_ intend to build, not buy the hardware
[17:29:00] <rayh> The pic does pwm and drives a motor.
[17:29:14] <rayh> Or step and direction and drives a motor.
[17:29:55] <SteveStallings> standard PC serial port will not support data rates fast enough to servo control comparable to the existing Servo-To-Go implementation
[17:30:10] <rayh> Granted. Single axis.
[17:30:11] <jmkasunich> 115K is only 11 bytes per servo cycle
[17:30:56] <jmkasunich> that's plenty if you are talking about limit and home switches
[17:31:07] <jmkasunich> but not much for encoder counts or "DAC" values
[17:31:10] <SteveStallings> I did a lot of fussing with compressed protocols running 115K and could only manage 2mS updates with 8 bit DACs
[17:31:15] <Imperator_> only for IO it is ok, because the stepper folks is using the parallel port for the steppers, a serial io-module is for thos people maybe interesting
[17:31:59] <rayh> Isn't 11 bytes enough for a single motor?
[17:32:11] <jmkasunich> perhaps
[17:32:17] <Imperator_> yes Steve for thos stuff it is easyer to use a cheap ISA card or a parallel connection
[17:32:43] <jmkasunich> but 11 is the theoritical maximum you can get, reality might be 6 bytes, or 3 or ...
[17:32:44] <SteveStallings> yes, but now you need one serial port per axis, and real time drives that support multiple serial ports
[17:33:26] <SteveStallings> character by character interrupts are really rough on real time environments
[17:33:36] <jmkasunich> I wouldn't use interrupts at all
[17:33:39] <rayh> Let's concentrate on the software required not the business value of the product.
[17:33:47] <jmkasunich> modern UARTs have 16 byte buffers
[17:34:03] <jmkasunich> so you should be able to dump 16 bytes of outgoing into the buffer
[17:34:15] <dave-e> have you looked at RT-Net?
[17:34:16] <SteveStallings> now your serial driver needs knowledge of your packet structure
[17:34:34] <jmkasunich> wait till the next servo cycle, read up to 16 bytes of incoming, and write 16 bytes of new outgoinh
[17:35:14] <jmkasunich> of course my method assumes you talk direct to the UART, not thru a Linux driver
[17:35:50] <jmkasunich> dave-e: you mean that rt-com URL that you gave>
[17:35:54] <jmkasunich> gave?
[17:36:17] <dave-e> that one is for serial from rt
[17:36:33] <dave-e> there is also a group working on IP/UDP
[17:36:46] <jmkasunich> RT ethernet would be cool
[17:37:33] <dave-e> <http://www.rts.uni-hannover.de/rtnet/>
[17:38:35] <jmkasunich> nice - bookmarked
[17:38:48] <jmkasunich> but getting back to Ray's goals...
[17:39:16] <jmkasunich> you basically want to send and receive one packet per servo cycle, using RS-232?
[17:39:26] <dave-e> ray are you thinking of separate serial ports or using one port to talk to multiple devices?
[17:41:01] <dave-e> y'know EPP aka jon's ppmc might be a better way to go and has demostrated adequate bandwidth
[17:41:11] <rayh> * rayh is on the phone for a bit
[17:42:51] <jmkasunich> I've always liked EPP - simple and fast. but serial is better if you need to go more than a short distance
[17:43:52] <dave-e> but if you want fast and reliable then build your own fiber driver...and protocol
[17:44:02] <SteveStallings> EPP was a great idea, but the implementations in chipsets and BIOS code never got ironed out well
[17:44:24] <SteveStallings> Jon Elson nearly pulled his hair out getting it to work
[17:44:44] <dave-e> but is does work...
[17:44:55] <dave-e> it does
[17:45:04] <jmkasunich> the chipsets don't actually do what the EPP specs say they should do?
[17:45:12] <SteveStallings> yes, but Jon now HIGHLY recommend one particular Dell motherboard to his customers
[17:45:18] <dave-e> ie...cheat a little
[17:45:45] <dave-e> I thought he said that all the dell MB worked
[17:46:23] <SteveStallings> probably all Dells with same chipset, but he found one Dell commonly available used and recommends it
[17:46:34] <jmkasunich> I hate PCs
[17:46:51] <paul_c> Now what have I done ??
[17:47:12] <dave-e> life was much simpler when DEC made all the decent hardware available.
[17:47:14] <jmkasunich> note the plural - there's only one of you (I hope)
[17:47:39] <SteveStallings> or any attempt to utilize cheap consumer products in industrial settings that require well defined operation and long term support
[17:47:44] <dave-e> multiple PC's ... now thats a scary thought
[17:48:08] <jmkasunich> oh, I have so many old PC around here it _is_ scary
[17:49:00] <jmkasunich> Steve - you hit it on the head... consumer grade products are shipped when they expect it will satisfy most customers, not when everything works
[17:49:09] <jmkasunich> (for some value of "most")
[17:49:35] <dave-e> from my viewpoint if rs-232 is marginal then 485 is really too slow
[17:49:40] <jmkasunich> if the EPP interface doesn't meet the published specs, who cares
[17:49:50] <jmkasunich> yeah, 485 has turnaround overhead
[17:49:57] <dave-e> those that need it for serious purposes
[17:50:01] <jmkasunich> at least 232 is full duplex
[17:50:22] <SteveStallings> but if you use point to point (yes, that is really 422) it can be quite fast
[17:50:57] <jmkasunich> true, but a moot point if we're talking plain vanilla hardware - PCs have 232 and that's all folks
[17:51:06] <SteveStallings> yep
[17:51:12] <dave-e> I suspect rayh intends to talk to several devices in the same servo loop...at least 3 axes
[17:51:36] <jmkasunich> for what ray wants I'd consider RT ethernet rather than serial
[17:51:40] <SteveStallings> and standard PC hardware only supports 2 ports
[17:53:13] <SteveStallings> somewhere I have seen turn around specs for RTnet, but cannot seem to find them now. My recollection was that its performance was not any faster than USB
[17:53:38] <jmkasunich> * jmkasunich has an instinctive revulsion to USB
[17:54:03] <rayh> sorry bout that.
[17:54:17] <SteveStallings> understood, but I can relate to what can be acheived by using the speed comparison
[17:54:18] <rayh> I've got some old multiple 232 boards here.
[17:54:48] <rayh> The ethernet is a really desirable system for this stuff.
[17:54:55] <jmkasunich> so you can afford to dedicate a port per axis
[17:54:59] <rayh> It is more than fast enough at 10 to handle 6 axes.
[17:55:12] <SteveStallings> USB frame rate will allow 2mS updates on 8 axes with high resolution DACs and encoders
[17:55:13] <dave-e> if rayh didn't need to pass the encoder info down the same lines then pwm would drive the servo side
[17:55:17] <jmkasunich> question becomes turnaround time
[17:55:47] <rayh> A device like ethernut or nutos should be able to handle a lot of info.
[17:56:20] <jmkasunich> you could send a broadcast packet that has info for all axis... each axis would capture it, and extract the relavant info
[17:56:25] <jmkasunich> but the return info is harder
[17:56:37] <jmkasunich> each axis must send a packet, and you need to avoid collisions between them
[17:56:55] <rayh> Yes it is. You would almost need a round robin thing
[17:57:00] <SteveStallings> RTnet replaces collision detection with TDMA
[17:57:11] <dave-e> polling on another line for input?
[17:57:27] <jmkasunich> each axis gets a timeslot
[17:57:30] <rayh> nutos has a bitch of a time on a general network.
[17:57:43] <jmkasunich> outgoing broadcast packet hits all axis modules
[17:57:44] <rayh> but works rather well in a specialized lan.
[17:58:08] <jmkasunich> axis 1 replies 20uS later, axis 2 replies 40us later, axis3 replies 60uS later, etc, etc
[17:58:16] <rayh> And ethernet connections are cheaper than 232.
[17:58:33] <jmkasunich> travel further, and have electrical isolation to btto
[17:58:35] <jmkasunich> boot
[17:58:42] <jmkasunich> got a URL for ethernuts?
[17:59:02] <rayh> www.ethernut.de/en I think
[17:59:10] <paul_c> and several digital drives now come with ehthernet interfaces
[18:00:21] <jmkasunich> but that gets you back into matching an existing protocol
[18:00:22] <rayh> And you ca get ethernet interfaces to many plc's.
[18:00:51] <rayh> That's why I favor a two part HAL.
[18:01:25] <rayh> One that does the parallel/serial conversion and another that presses that data into a protocol.
[18:01:37] <rayh> Think of the second as a wrapper.
[18:01:39] <jmkasunich> its not that simple
[18:02:05] <rayh> k
[18:02:07] <jmkasunich> parallel/serial is about 2% of the protocol
[18:02:31] <jmkasunich> and different protocols may want the parallel/serial packing and unpacking done differently anyway
[18:03:02] <dave-e> so you build a standard packet and let the driver format it for the media/protocol
[18:03:20] <jmkasunich> the "standard packet" _is_ the protocol
[18:03:38] <rayh> Uh. I think that is overstating the case.
[18:03:59] <jmkasunich> a packet that suits one protocol won't likely suit another protocol
[18:04:14] <rayh> That is FUD put out by the folk that try to get you to use their proprietary solution.
[18:04:31] <rayh> How's that for devils advocate
[18:04:59] <rayh> In the simplist case, where we started, 232. It's a set of pins.
[18:04:59] <jmkasunich> tell me, what is the format of a ModBus packet/message?
[18:05:25] <rayh> You can define stop bits and data bits and handshaking.
[18:05:41] <rayh> and speed.
[18:05:50] <jmkasunich> stop bits are part of the UART physical layer, as is speed
[18:05:57] <rayh> Anything more than that is overhead or protocol
[18:06:26] <jmkasunich> ethernet is one physical layer, RS-232 is another, RS-485 another, etc, etc
[18:06:52] <jmkasunich> all deal in streams of bytes, in some cases broken up into packets
[18:07:32] <rayh> And that is the nature of the HAL. It abstracts physical layers from data layers.
[18:07:37] <jmkasunich> next level up (simplified) is things like TCP/IP, UDP/IP, PPP, PPPoE, SLIP, etc
[18:07:45] <rayh> So I need a 232 HAL.
[18:07:58] <rayh> Am I not stating the case simply enough.'
[18:08:09] <jmkasunich> I dunno what you're doing...
[18:08:30] <rayh> And that is the question that we need to ignore.
[18:08:32] <SteveStallings> OK, found the turn around references I remembered. They are for PowerLink which is similar to RTnet. Best case 400uS cycle on dedicated net, greater than 1mS typical on open Ethernet backbone.
[18:08:52] <jmkasunich> what do you mean we need to ignore
[18:08:56] <rayh> serial on 232 does not carry the nature of it's data.
[18:09:22] <jmkasunich> right - it's just a stream of bytes - the higher level protocol determines what the bytes mean
[18:09:52] <alex_joni> greetings
[18:09:53] <rayh> Right. So the 232 hal mod takes some data in and turns it into a stream od data out.
[18:10:02] <rayh> Hi alex.
[18:10:07] <alex_joni> hey rayh
[18:10:13] <alex_joni> some crowd around here ;)
[18:10:14] <jmkasunich> to do that you need to define the "higher level protocol"
[18:10:26] <rayh> why
[18:10:34] <alex_joni> hello jmk
[18:10:55] <jmkasunich> if the sender is sending one 8 bit number, one float, and 6 bits, the receiver needs to know that
[18:10:59] <jmkasunich> hi alex
[18:11:08] <alex_joni> * alex_joni agrees
[18:11:12] <rayh> Can't a hal pin connect to some variable and turn that variable into serial and take a serial return and turn it into a variable.
[18:11:16] <alex_joni> *grin
[18:11:34] <alex_joni> rayh: you need a header then
[18:11:35] <rayh> Let the end user worry about that end of the wire.
[18:11:37] <jmkasunich> but both ends of the link need to agree on what kind of variable(s) are being transmitted
[18:11:38] <SteveStallings> yes as long as HAL and the external device agree on the packet structure
[18:11:42] <alex_joni> to describe what variable you send
[18:11:49] <rayh> That is my problem not HAL's
[18:12:02] <jmkasunich> that is the protocol's problem
[18:12:10] <alex_joni> but.. the hal 232 module connects to the rs232 port
[18:12:14] <rayh> F6543 the protocol
[18:12:22] <jmkasunich> huh?
[18:12:25] <alex_joni> not to your app wrapping the data into the protocol
[18:12:31] <rayh> Let me do that. Give me a HAL mod that I can connect a var to
[18:12:44] <alex_joni> and outputs it how?
[18:12:48] <rayh> and the the value of that var on the other end of a wire.
[18:12:51] <SteveStallings> OK, so maybe there could be a serial HAL that allows user to construct packets from variables to define packets like we now define other HAL interconnects
[18:12:59] <jmkasunich> just one variable? what kind, a bit, word, float?
[18:13:01] <rayh> yes there is a dog.
[18:13:07] <rayh> Any kind.
[18:13:20] <jmkasunich> doesn't work that way
[18:13:28] <alex_joni> any kind... then the other end needs to distinguish between the kinds that arrive
[18:13:33] <alex_joni> right?
[18:13:47] <rayh> Forget the other end of the line for the minute.
[18:14:14] <rayh> There is a bit bucket out there.
[18:14:18] <jmkasunich> ok
[18:14:47] <alex_joni> ok.. say you send 8 bits of data at a time
[18:14:56] <alex_joni> that can be a bit
[18:14:58] <rayh> If we connect the hal pin to a float, it's a float that gets sent.
[18:15:02] <alex_joni> an char
[18:15:09] <anonimasu> * anonimasu stabs somthing through samba
[18:15:16] <alex_joni> if it's float, then 4 chars need to be sent
[18:15:22] <anonimasu> I think I just experienced a bug.
[18:15:54] <rayh> anonimasu: is it named "rayh"?
[18:16:05] <alex_joni> lol
[18:16:20] <anonimasu> rayh: no
[18:16:52] <rayh> Would that HAL mod need to know what kind of variable it is at the input pin?
[18:17:02] <alex_joni> sure
[18:17:05] <jmkasunich> HAL pins are typed
[18:17:11] <rayh> So that it knows how many bytes to send.
[18:17:20] <jmkasunich> you can only connect a float pin to another float pin
[18:17:43] <rayh> So in this case we would need a pin for each data type.
[18:17:44] <alex_joni> yup.. but the module might have all the types as pins (one bit, one float, etc...)
[18:18:08] <rayh> And only one can be used per instance of the module?
[18:18:15] <alex_joni> and if you need two variables typed float.. you need 2 hal modules? or perhaps configure the pins at startup
[18:18:17] <jmkasunich> you tell me, you're inventing this module
[18:18:38] <rayh> ?
[18:18:39] <SteveStallings> so I could build a HAL module that presents many pins, 4 floats, 8 bits, and the it builds the packet
[18:18:55] <jmkasunich> SteveStallings: exactly
[18:19:11] <jmkasunich> rayh: you're describing what you want - hence you're inventing it
[18:19:54] <rayh> Would what steve's saying work?
[18:20:05] <jmkasunich> steve has the idea.. if you want to send 3 ints, a float, and 4 bits, you can design a module that will export those pins, and assemble the data from them into a packet
[18:20:13] <SteveStallings> now the next step is to help Ray by making it possible to automate the process by having a configurable HAL module
[18:20:24] <rayh> If yes, we have gotten quite a ways toward a serial data generator for emc.
[18:20:24] <alex_joni> you could pass it some params at insmod time (if it's RT), or at load time (nonRT), to specify what pins it should export
[18:20:28] <jmkasunich> if you want 1 int, 2 floats, and 1 bit, you could reconfigure the module
[18:20:34] <jmkasunich> and the packet format would change
[18:20:46] <jmkasunich> the guy on the other end needs to know the packet format
[18:20:54] <alex_joni> jmk: how about sending each variable in it's own packet?
[18:21:01] <alex_joni> with a small header with checksum and data type?
[18:21:17] <SteveStallings> too much overhead for RS232
[18:21:17] <alex_joni> checksum could be parity
[18:21:18] <jmkasunich> given the speeds we want that would be too costly I think
[18:21:37] <alex_joni> ok.. then maybe at startup (during configure)
[18:21:38] <jmkasunich> but in any case, things like headers and checksums are exactly the protocol that we;re talking about
[18:21:47] <rayh> The far end needs to know what the info it's getting is but that is not the concern of the hal mod.
[18:21:54] <alex_joni> at the begining a handshake between the two
[18:22:06] <alex_joni> rayh: then you really should send the hal-module bits
[18:22:13] <jmkasunich> rayh: the two need to be on the same page... it has to be done somehow
[18:22:13] <alex_joni> and serialize it yourself
[18:22:32] <jmkasunich> maybe the far end sends a message telling the HAL mod what it wants, and then the HAL mod exports the appropriate pins
[18:22:47] <rayh> It would be possible to send a protocol def at the beginning of the connection but I don't see that as the problem where.
[18:22:50] <SteveStallings> any new RS232 module for HAL would still need a way to supply headers and checking, things that are not reasonably defined as pins
[18:23:15] <rayh> I would like to concentrate on the HAL end of it and HAL end only right now.
[18:23:22] <jmkasunich> basically, the config info for the HAL module is the packet format
[18:24:03] <jmkasunich> maybe a config string like "ffbbbi" means "the packet should contain two floats, 3 bits and an int, in that order"
[18:24:09] <rayh> jmkasunich: right.
[18:24:18] <jmkasunich> so the HAL module would export 2 float pins, 2 bit pins, and an int pin
[18:24:44] <rayh> as a serial data string?
[18:24:52] <jmkasunich> there are still ugly details to work out, but we're getting to something workable
[18:25:09] <jmkasunich> the packet would be a serial data string
[18:25:13] <jmkasunich> the pins would just be pins
[18:25:34] <alex_joni> jmk: how about an sync-signal?
[18:25:35] <rayh> I guess the export confused me.
[18:25:48] <alex_joni> for hal-module to know when to get the data from the pins?
[18:25:48] <jmkasunich> "export pins" means make pins available in the HAL
[18:25:55] <rayh> I really like the "ffbbbi" notion.
[18:26:00] <rayh> Okay.
[18:26:15] <alex_joni> or that is done by the update_function?
[18:26:19] <alex_joni> or smthg like that?
[18:26:24] <jmkasunich> alex_joni: by the update funct
[18:26:40] <jmkasunich> we would want two strings - one describes outgoing packets, one describes incoming packets
[18:26:50] <rayh> Yes we will.
[18:27:02] <alex_joni> hmm.. don't know if you won't get sync problems, if the variables are outside of emc
[18:27:24] <alex_joni> even if within emc, not so sure the two rates don't drift
[18:27:28] <SteveStallings> will the cycle time of the HAL serial time pose issues, it seems it will have to be slow enough to allow transmission of a complete packet
[18:27:38] <alex_joni> don't know if I make myself clear on this one
[18:27:49] <rayh> I think that this is a real problem with things that run at their own rate out there.
[18:28:15] <rayh> I even think that it might be a problem with an programmable device like fpga and such.
[18:28:22] <jmkasunich> yes, you could get skew
[18:28:25] <alex_joni> rayh: just seen you run an ethernut??? NICE ;)
[18:28:34] <alex_joni> I've built a few myself
[18:28:41] <jmkasunich> btw, ray, how $$ is an ethernut?
[18:28:43] <rayh> It's blinking at me now.
[18:28:46] <alex_joni> cheap
[18:28:58] <alex_joni> jmk: you can built it yourself
[18:29:15] <alex_joni> I think around 50-100$ depending on what you want on it
[18:29:31] <jmkasunich> moderatly cheap then, not really cheap
[18:29:45] <rayh> We would certainly want an outboard interrupt that signals that the device is ready.
[18:30:05] <jmkasunich> waitaminnit
[18:30:11] <jmkasunich> who is interrupting who?
[18:30:17] <rayh> or a signal we send that says get your stuff together and send it to EMC.
[18:30:30] <SteveStallings> that should be part of the protocol
[18:30:51] <rayh> We had both possibilities available in some of the early HAL work.
[18:30:54] <jmkasunich> depends on whether you are running master/slave or peer-to-peer
[18:30:57] <alex_joni> I think we should start talking about an concrete example
[18:31:09] <jmkasunich> masterslave: the HAL module sends an outgoing packet
[18:31:10] <alex_joni> * alex_joni means actual example
[18:31:11] <rayh> EMC driven from a device or a device driven from EMC.
[18:31:33] <jmkasunich> on receipt of the outgoing packet, the remote device responds, and HAL gets the incoming packet the next time the thread runs
[18:32:11] <rayh> In this the EMC is in charge.
[18:32:48] <jmkasunich> rayh: as it stands, HAL timing comes strictly from the RTAI or RTLINUX tasks, there is no provision for syncing to external interrupts
[18:33:02] <rayh> Right.
[18:33:03] <jmkasunich> can't completely rule it out, but it would be complex
[18:33:55] <rayh> I seem to remember that outboard sync was a part of the rtapi.
[18:34:05] <jmkasunich> nope
[18:34:39] <jmkasunich> rtapi is very low level, just a wrapper for the RTOS so we don't have bunches of ifdefs for RTAI and RTLINUX
[18:36:30] <alex_joni> but there's a rtai-com
[18:36:33] <alex_joni> for rs232
[18:36:44] <alex_joni> so you don't need to reinvent that again ;)
[18:38:11] <rayh> * rayh has duties in about 4 mins.
[18:38:25] <alex_joni> ok.. do we have a conclusion?
[18:38:30] <jmkasunich> to summarize
[18:38:48] <jmkasunich> I think we can handle the packet format issue, with "ffbbbi" or something like that
[18:38:57] <jmkasunich> sync issues could get compilcated
[18:39:16] <alex_joni> 1. hal-module exports pins (based on config)
[18:39:37] <rayh> How about outboard returning a "ffbbbiii" asap after the HAL send.
[18:39:39] <alex_joni> 2. hal-module gets data on those pins (based on rate update() runs)
[18:40:07] <alex_joni> 3. hal-module sends that data serial out (through rs232)
[18:40:19] <alex_joni> 4. where does the protocol fit into this picture?
[18:40:26] <Jymmm> ROTF... "Dear Customer, We promised your order to be shipped today, but all of our Bridgport Mills were under a DOS-Attack as well as being hacked (defacing all billets with 'casting rules!')"
[18:40:38] <jmkasunich> protocol defines how things are packed into a packet
[18:41:00] <alex_joni> yup, I think that needs to be packed into the module actually sending the stuff serially
[18:41:10] <alex_joni> thus the hal-232 module
[18:41:37] <SWPadnos> * SWPadnos is back
[18:41:45] <rayh> Couldn't a higher level protocol be packed as vars at the front and back of the packet?
[18:41:52] <jmkasunich> for instance, "fbbi" - do you send 4 bytes for the float, then pack the 2 bits into one byte, with 6 unused bits, then send the int as 4 bytes? do you checksum the packet?
[18:41:53] <alex_joni> SWPadnos: tried paul's fixes?
[18:42:24] <rayh> Could someone email this serial discussion to me?
[18:42:28] <alex_joni> rayh: usual rs232 protocols are very different
[18:42:47] <alex_joni> one sends a byte at a time, other send bulks
[18:42:54] <alex_joni> header differ
[18:43:15] <rayh> Only if we want it to differ.
[18:43:32] <rayh> I'm still thinking simple case here 1 dev ice 1 232.
[18:44:16] <jmkasunich> a robust protocol must also be able to recover if part of a packet is lost
[18:44:35] <alex_joni> jmk: depends what we want on this rs232 module
[18:44:45] <alex_joni> does it have to talk to existing devices?
[18:44:52] <alex_joni> like servos/plcs?
[18:45:05] <jmkasunich> this whole thing is ray's idea
[18:45:20] <SWPadnos> talking about RS232 (/485/422) - the drivers should be split into hardware and protocol layers
[18:45:35] <jmkasunich> I think he wants to talk to new devices that would speak the protocol that we are discussing nwo
[18:45:38] <jmkasunich> nwo
[18:45:42] <jmkasunich> now
[18:45:47] <jmkasunich> damn I can't type today
[18:45:47] <SWPadnos> low level driver takes a port to talk to (can be done in RT if it's taken over, like JonE's syuff)
[18:45:51] <alex_joni> I agree...
[18:46:07] <SWPadnos> higher level decides what to say, once the lower level knows how to make the connection.
[18:46:42] <SWPadnos> this allows multipl protocols to be eg. shared over a single RS-485 or ethernet connection
[18:47:05] <jmkasunich> given the performance Ray is looking for, some generality is gonna need to be sacrificed
[18:47:10] <SWPadnos> Or, for that matter, a single higher level protocol could talk over any available channel to the same hardware
[18:47:19] <jmkasunich> he wants to send and reply one packet every 1mS
[18:47:41] <jmkasunich> at 115Kbaud, that packet will be less than 11 bytes
[18:47:48] <SWPadnos> Yeah - that's hard at 115.2k, but a lot of devices can get as high as 921.6k these days (given appropriate cable lengths)
[18:48:30] <SWPadnos> Talking about ethernet - that's a lot faster, but non-deterministic (unless you control every device on the network)
[18:48:43] <jmkasunich> dedicated net
[18:48:45] <SWPadnos> (sorry - catching up on the last couple of hours :) )
[18:49:05] <alex_joni> SWPadnos: I agree on 921.6k, as long as it's not a PC ;)
[18:49:06] <SWPadnos> a dedicated net with only well-known devices attached
[18:49:29] <alex_joni> how about CAN?
[18:49:31] <alex_joni> PROFIBUS?
[18:49:42] <SWPadnos> Why not on PC? Probably not any chipset serial port, but plug-in cards are OK.
[18:49:51] <alex_joni> there are a lot of busses out there
[18:49:52] <jmkasunich> right now we're focusing on RS-232 as the physical layer
[18:49:57] <SWPadnos> CAN is OK, but requires specialized hardware.
[18:50:01] <alex_joni> jmk: right
[18:50:05] <alex_joni> rs232 it is
[18:50:11] <alex_joni> and standard serial port too
[18:50:12] <jmkasunich> ethernet is another interesting physical layer
[18:50:23] <jmkasunich> others tend to require special hardware
[18:50:30] <SteveStallings> and 115K is highest speed to be found in generic motherboard chipsets
[18:50:40] <SWPadnos> Ethernet is great for bulk, but unlerss there's a network time sync, things may get askew
[18:50:45] <SWPadnos> unless
[18:50:59] <SWPadnos> (not unlerss)
[18:50:59] <jmkasunich> if you work at the packet level, ethernet would be fine
[18:51:16] <jmkasunich> master sends packet to slave, slave replies, then master sends packet to another slave, etc
[18:51:21] <jmkasunich> no collisions that way
[18:51:22] <SWPadnos> true, but you still have to deal with collisions which make the response non-deterministic
[18:51:53] <SWPadnos> OK - as long as the port is dedicated to EMC (ie, two eth ports in the machine)
[18:52:13] <SWPadnos> Otherwise, a different task can screw something up
[18:52:24] <jmkasunich> right - that's pretty much a given, there would be a RT driver on the emc port
[18:52:36] <SWPadnos> OK - I'm happy then :)
[18:53:07] <jmkasunich> but we're really talking about the RS-232 case right now
[18:53:29] <SWPadnos> OK - what about RS232 is the current question?
[18:53:37] <Jymmm> I2C
[18:53:42] <jmkasunich> ray wants to be able to make an arbitrary (configurable) set of HAL pins available to a remote device over RS-232
[18:54:03] <SteveStallings> and expects it to be fast enough for servo control 8-)
[18:54:20] <SWPadnos> I2C is not so good for that, neither is SPI. They're both meant for chip to chip communication, not so much "long distance".
[18:54:43] <SWPadnos> (though they're used for a lot of stuff they shouldn't be)
[18:54:47] <jmkasunich> nor are they available on ordinary PCs
[18:55:05] <SWPadnos> Pins are easy with RS232 - it's floats that suck.
[18:55:17] <jmkasunich> cause of the size?
[18:55:31] <Jymmm> So, you want the pc remote from the mill?
[18:55:35] <SWPadnos> Fortunately, the resolution of most devices will be 16-bit or less (except encoders, which might be 24)
[18:55:49] <SWPadnos> More remote than 6-12 inches :)
[18:56:17] <jmkasunich> I dunno what ray has in mind... I think he wants to talk to a servodrive
[18:56:22] <SWPadnos> so float conversions should be done on the PC side, to save bandwidth
[18:56:41] <SWPadnos> Right - but the PWM/A-D will be 8-16 bits
[18:56:47] <jmkasunich> I disagree - if he configs it to send a float HAL pin, it should send a float HAL pin
[18:56:49] <Jymmm> SWPadnos: What am I missing here?
[18:56:51] <SWPadnos> so 2 bytes/channel for velocity
[18:57:14] <Jymmm> * Jymmm walked in half way during the conversation.
[18:57:45] <jmkasunich> ray started asking for a totally generic HAL<->RS-232 module
[18:58:05] <SWPadnos> The module should be a low-level RT RS232 driver
[18:58:13] <Jymmm> ah
[18:58:17] <SWPadnos> to which configuration data can be added to create HAL pins
[18:59:09] <jmkasunich> right - we came up with the idea of a pair of config strings, like "ffbbbii" to tell it to send 2 floats, 3 bits, 2 ints... there would be one string to describe outgoing packets, one for incoming packets
[18:59:25] <jmkasunich> the module would export HAL pins based on the config
[18:59:50] <jmkasunich> the sender and receiver better have the same config, or all heck breaks loose
[18:59:53] <SWPadnos> Going XML-ish, something like <RS232><HALPin>type=Float; resolution=16; order=LE Name=SpindlePWMOnWackyBoard</HALPin></RS232>
[19:00:07] <jmkasunich> aack
[19:00:11] <SWPadnos> heh
[19:00:20] <SWPadnos> (better in multiline format)
[19:00:36] <Jymmm> * Jymmm smacks SWPadnos for the ExVmIlL
[19:00:37] <jmkasunich> better in not-XML format
[19:00:52] <SWPadnos> Hey - Alex did it last week :)
[19:01:08] <paul_c> what the **** is the desire for XML for ??
[19:01:28] <SteveStallings> yum, bloat
[19:01:36] <SWPadnos> I don't care about XML, but it may be nice to be able to name signals
[19:01:38] <Jymmm> paul_c: it's like "multimedia" of the 80's
[19:01:55] <SWPadnos> or "genuine plastic" of the '70s
[19:02:13] <alex_joni> * alex_joni hides
[19:02:31] <alex_joni> it was as an example, not thought to be used ...
[19:02:41] <SWPadnos> <RS232>
[19:02:42] <SWPadnos> <HALPin>
[19:02:43] <jmkasunich> yeah, it might be nice if the config specified the HAL pin name instead of letting it be arbitrarily assigned "RS-232.1.float.1" but that's a detail
[19:02:44] <SWPadnos> Type=Float;
[19:02:45] <SWPadnos> resolution=16;
[19:02:47] <SWPadnos> order=LE
[19:02:49] <SWPadnos> Name="SpindlePWMOnWackyBoard"
[19:02:50] <SWPadnos> </HALPin>
[19:02:51] <SWPadnos> </RS232>
[19:03:48] <jmkasunich> Type is the HAL pin type, and Name is the HAL pin name, got that much
[19:04:02] <jmkasunich> resolution and order describe the format on the serial link?
[19:04:30] <Imperator_> alex_joni: have you tested how fast the ethernut modules are ???
[19:04:36] <SWPadnos> resolution is for conversion between HAL_type (float) and the probably fixed type on the other end (16-bit fraction)
[19:04:50] <SWPadnos> order is big/little-endian (or whatever)
[19:05:06] <jmkasunich> so both are describing the format on the wire then?
[19:05:21] <SWPadnos> Yes. Those just came off the top of my head. There may be more things to think about for a generic driver
[19:05:21] <alex_joni> Imperator_: not really... but serial over ethernet works up to 115kbps iirc
[19:05:40] <alex_joni> the ethernut I built is with RTL8019AS (10MBit only)
[19:05:55] <SWPadnos> I have the Digi and Lantronix ethernet<->serial adapters, and they're pretty fast.
[19:06:15] <SWPadnos> I think one of them does 460.8k, but I'd have to move to check which one :)
[19:06:16] <jmkasunich> translation from float to integer for the wire is an extra feature that might be desireable, but not core to the module
[19:06:28] <SWPadnos> It may be necessary.
[19:06:40] <jmkasunich> 'depends on what is on the other end
[19:06:54] <SWPadnos> A microcontroller doing spindle PWM won't have floating point (probably), and will have a fixed resolution.
[19:06:58] <jmkasunich> one possibility for the other end is another PC with another HAL
[19:07:15] <jmkasunich> and this module bridges the two together
[19:07:16] <SWPadnos> doing the conversion on the PC is way better than including clib on a tinyAVR
[19:07:19] <SWPadnos> libc
[19:07:34] <SWPadnos> right - so "no conversion" has to be an option as well
[19:07:53] <SWPadnos> (or ascii, for fast links with possible binary format troubles)
[19:08:17] <Jymmm> ZMODEM Rules!
[19:08:26] <jmkasunich> so we agree that there has to be a "packet format spec" that establishes two things:
[19:08:28] <SWPadnos> Y not Xmodem?
[19:08:33] <jmkasunich> 1) what HAL pins are sent
[19:08:35] <Jymmm> lol
[19:08:41] <jmkasunich> 2) how they are formatted
[19:09:01] <SWPadnos> 3) in what order (unless that's implicit in 1)
[19:09:03] <Jymmm> Z why didn't I think of that
[19:09:22] <Jymmm> SWPadnos: That was pretty good =)
[19:09:33] <jmkasunich> 2) how they are formatted and packed into a packet
[19:09:35] <jmkasunich> how's that
[19:09:48] <SWPadnos> OK by me
[19:10:00] <SWPadnos> (but those are different questions)
[19:10:09] <SWPadnos> format to me is "encoding"
[19:10:23] <SWPadnos> packet packing is "formatting"
[19:10:27] <Jymmm> I don't mean to be a smartass... why reinvent the wheel...?
[19:10:36] <jmkasunich> good question
[19:10:40] <SWPadnos> because this wheel hasn't been invented yet.
[19:10:46] <Jymmm> bullshit
[19:10:48] <SWPadnos> (unless it has)
[19:10:52] <Jymmm> lol
[19:10:54] <jmkasunich> all these format options are certainly far beyond what Ray was thinking of
[19:11:39] <SWPadnos> True - but it would be better to not to have to write a completely new serial driver to support each new serial device out there.
[19:11:50] <Jymmm> Well, leaving room for growth is a good thing, but I suspect the basics has already been established somewhere. Not like RS-232 is new or anything.
[19:11:54] <jmkasunich> when you start dealing with LE vs BE, and adding an ASCII option, it starts sounding like NML
[19:12:16] <Jymmm> all this talke make me think of BBS days...
[19:12:20] <SWPadnos> I can whip out a PIC or AVR serial device to do something simple (like spindle speed or cooland control), but writing a new driver would be a pain
[19:13:05] <SWPadnos> It's pretty easy to implement - you have a set of converter functions (which may be inlines) that take a data type, and convert to something else.
[19:13:28] <SWPadnos> call them from an array (of the data types being sent, for this configuration)
[19:13:33] <jmkasunich> they can't be inlines
[19:13:50] <jmkasunich> sorry, nitpicking
[19:13:57] <SWPadnos> true enough
[19:14:06] <SWPadnos> (please - pick away - that's how things get better)
[19:14:43] <jmkasunich> given that packet size is somewhere less than 12 bytes...
[19:14:56] <SWPadnos> unless faster serial ports are supported
[19:15:16] <SWPadnos> that's also 12 in each direction - it's full duplex.
[19:15:33] <jmkasunich> they're not... we're talking about plain vanilla PC serial ports, 115KB by definition
[19:15:43] <jmkasunich> true, and we want packets going both ways
[19:16:13] <Jymmm> why not use X.25 protocol?
[19:16:20] <jmkasunich> wtf is that
[19:16:25] <SWPadnos> I'm not sure how much extra work it is to support higher speeds. Some of the chips just need extra clock setup, then they act like regular 8255s
[19:16:40] <Jymmm> http://www2.rad.com/networks/1996/x25/x25.htm
[19:16:41] <SWPadnos> Isn't X.25 a video or voice protocol?
[19:16:57] <alex_joni> any protocol adds too much overhead for RT
[19:16:58] <Jymmm> SWPadnos: no that's video your thinking. Even my radio has X.25
[19:17:16] <Jymmm> alex_joni: I use it live on my radio for RC
[19:17:36] <alex_joni> you need to establish an handshake at the beginning
[19:17:41] <alex_joni> then feed a lot of data, fast
[19:17:49] <alex_joni> darn
[19:17:53] <SWPadnos> it's realtime as long as the channel has way higher bandwidth than the application needs, which isn't the case here
[19:18:15] <alex_joni> I downloaded 2.6.10, but there seems to be no rtai-patch for it :(
[19:18:47] <jmkasunich> we simply need to estaqblish a packet format, then send one packet every thread period, and expect to receive one packet every thread period
[19:19:06] <SWPadnos> with serial, it's error handling that almost always gets you.
[19:19:17] <jmkasunich> yes, exactly
[19:19:33] <jmkasunich> what if you get a busted packet, or miss the beginning of the packet
[19:19:33] <SWPadnos> a 115.2k link would give 11.52 bytes per interrupt, so 11 is the real maximum
[19:19:44] <jmkasunich> I said less than 12 ;-)
[19:19:59] <jmkasunich> realistically it could be less than that
[19:19:59] <alex_joni> SWPadnos: no interrupt ;)
[19:20:00] <SWPadnos> it's hard to get a broken backet with 82C455 chips - they have a 16-byte FIFO
[19:20:10] <SWPadnos> packet
[19:20:49] <jmkasunich> noise can garble a byte or something...
[19:21:02] <SWPadnos> since the FIFO is more than we can use in one cycle, we should be OK there.
[19:21:04] <jmkasunich> gets to packet formatting again... headers, checksums?
[19:21:19] <Jymmm> alex_joni: http://www.farsite.co.uk/news/press_releases/020628_win_x.25_release.htm
[19:21:20] <SWPadnos> noise can be an issue, but CRC is pretty fast (if you precompute a 512-byte table)
[19:21:21] <alex_joni> jmk: shouldn't
[19:21:37] <alex_joni> SWPadnos: how about parity?
[19:21:44] <Jymmm> "...allows all X.25 lines to be monitored in real-time..."
[19:21:45] <alex_joni> rs232-parity?
[19:22:03] <SWPadnos> parity is only guaranteed to detect single bit errors
[19:22:15] <alex_joni> Jymmm: there is real-time and there is real-time ;)
[19:22:23] <SWPadnos> checksum will detect certain groups of errors
[19:22:24] <alex_joni> usually it's bull they refer as real-time
[19:22:28] <jmkasunich> back up a sec guy and look at the big picture
[19:22:55] <jmkasunich> suppose we're sending one float and 4 bits and we're sending the float unformatted
[19:23:04] <Jymmm> alex_joni =) I don't have any issues controlling a transmitter 2 miles away real-time =)
[19:23:10] <SWPadnos> (as an IEEE 32-bit float)
[19:23:16] <alex_joni> Jymmm: anything windows based can NOT (NEVER EVER) be realtime
[19:23:21] <alex_joni> what's realtime to you?
[19:23:29] <jmkasunich> the data part of the packet is 5 bytes, 4 for the float, and one containing the 4 bits
[19:23:35] <alex_joni> < 10 usecs
[19:23:39] <Jymmm> alex_joni: MS-DOS
[19:23:46] <alex_joni> MS-DOS is not realtime
[19:24:05] <jmkasunich> alex_joni: can be, just don't call the OS
[19:24:10] <jmkasunich> but we digress
[19:24:17] <alex_joni> even RTAI & RTLINUX are only to some extent realtime
[19:24:21] <alex_joni> sw-realtime
[19:24:25] <SWPadnos> (and don't allow any programs to disable interrupts)
[19:24:33] <alex_joni> there is HW-realtime (used in fly-by-wire for example)
[19:25:02] <alex_joni> realtime doesn't have interrupts
[19:25:12] <jmkasunich> * jmkasunich waits for us to get back on topic
[19:25:20] <alex_joni> * alex_joni drifts back
[19:25:25] <SWPadnos> Hi there - I'm on topic :)
[19:25:25] <jmkasunich> ;-)
[19:25:35] <jmkasunich> ok, so we have 5 bytes of data
[19:25:46] <jmkasunich> do we just send a 5 byte packet?
[19:26:07] <jmkasunich> how do we know when one ends and the next begins?
[19:26:09] <SWPadnos> right - then add in one header byte, and a CRC / checksum
[19:26:20] <jmkasunich> what is the header byte for?
[19:26:29] <alex_joni> sync
[19:26:35] <dave-e> start of packet
[19:26:40] <SWPadnos> sync, device selection, etc.
[19:26:49] <jmkasunich> then it needs to be a value that can't appear in the data, doesn't it?
[19:26:52] <SWPadnos> (RS-485 would need a device ID)
[19:27:14] <dave-e> well you might want to use another byte for channel /device
[19:27:15] <alex_joni> it could appear in the data too
[19:27:44] <jmkasunich> if it can appear in the data, then it's not a foolproof sync method
[19:27:48] <alex_joni> usually it's done by escaping the magic number
[19:27:59] <SWPadnos> it depends on whether there is a fixed format on a given RS232 link
[19:28:04] <alex_joni> but that increases the packet size
[19:28:09] <jmkasunich> which changes the packet length whenever the magic number appears in the data... bad for RT
[19:28:11] <SWPadnos> that's wher ethe error timeouts start to bite you
[19:28:41] <jmkasunich> agreed that we need checksum or CRC
[19:29:00] <alex_joni> how about this...
[19:29:04] <jmkasunich> could sync be handled by assuming that any 6 sequential bytes with a good CRC are a packet?
[19:29:06] <alex_joni> you have a header/checksum
[19:29:12] <SWPadnos> yes.
[19:29:25] <alex_joni> and aditional bytes
[19:29:27] <alex_joni> = packet
[19:30:08] <SWPadnos> but then you have to compute the CRC on the entire packet for each received byte (you have a rolling buffer of bytes, which gets cleared after some timeout)
[19:30:25] <SWPadnos> any time the CRC matches, it's a valid packet
[19:30:29] <SWPadnos> (unless it's all zeroes)
[19:30:33] <jmkasunich> right
[19:30:41] <SWPadnos> (the protocol has to insure that all zero never happens)
[19:30:57] <jmkasunich> dunno how expensive computing the rolling CRC is, rolling checksum is trivial
[19:31:22] <SWPadnos> on an AVR, with a precomputed CRC table, it's about 12 cycles per byte
[19:31:37] <jmkasunich> header isn't strictly needed, unless you have multiple drops or other addressing needs
[19:31:59] <alex_joni> that can be handled as data too
[19:32:05] <alex_joni> addressing ...
[19:32:09] <jmkasunich> rught
[19:32:11] <jmkasunich> right
[19:32:34] <jmkasunich> you need a prior agreement on packet length
[19:32:46] <jmkasunich> then the receiver has a buffer
[19:32:57] <alex_joni> of that length
[19:33:03] <jmkasunich> if there are less than one packets worth of chars in the buffer, do nothing
[19:33:22] <jmkasunich> once the buffer contains at least a packets worth of chars, do the CRC
[19:33:35] <jmkasunich> if it matches, you have a packet, move it elsewhere and clear the buffer
[19:33:45] <jmkasunich> if not, dump the oldest char and wait for another one
[19:33:55] <alex_joni> yup
[19:33:57] <jmkasunich> I think that will sync up pretty well
[19:34:13] <alex_joni> now... the CRC
[19:34:29] <alex_joni> say we have to send 5 bytes
[19:34:37] <alex_joni> the 6th byte is the CRC
[19:34:59] <SWPadnos> (6th + 7th, probably)
[19:35:05] <alex_joni> yeah...
[19:35:12] <jmkasunich> are there 8 bit CRCs?
[19:35:14] <alex_joni> think it's 1.5 for 5 bytes?
[19:35:24] <jmkasunich> seems a shame to have 2 bytes to CRC 5
[19:35:26] <SWPadnos> I think the 16-bit CRC is WAY better than 8-bit
[19:35:36] <alex_joni> the CRC depends on the bits you want to check
[19:35:47] <SWPadnos> the 2 bytes could be used for up to 32k or something
[19:35:52] <alex_joni> you can have 8-bit CRC, but that might only do testing of fault
[19:36:03] <SWPadnos> are you talking about CRC or FEC?
[19:36:16] <alex_joni> FEC? refresh my memory
[19:36:24] <SWPadnos> Forward Error Correction
[19:36:30] <alex_joni> right
[19:36:38] <SteveStallings> FEC similar to ECC used in disk drives
[19:36:50] <alex_joni> I think I confused the two.. it's been a while ;)
[19:36:56] <SWPadnos> you add extra bits that are carefully chosen XOR of various bit groups, and you can reconstruct bytes even if they contain errors
[19:37:01] <jmkasunich> anyway, that's a detail... could be CRC8, CRC16, checksum, FEC (whatever that is), the point is that it handles sync for us since packet length is known and fixed
[19:37:06] <alex_joni> FEC would be nice, but that would rule out the packet sync
[19:37:08] <jmkasunich> error correction is overkill here
[19:37:09] <SWPadnos> NO!
[19:37:18] <SWPadnos> wait - FEC won't do that
[19:37:29] <alex_joni> it would repair any packet
[19:37:43] <alex_joni> even wrong ones
[19:37:46] <SWPadnos> with FEC, every code means something, so you can tell if there were errors, but not wher ethe packet begins / ends
[19:37:54] <SWPadnos> (sorry about the yell :) )
[19:38:13] <jmkasunich> I think sync is more important
[19:38:21] <jmkasunich> remember, we're resending the data 1000 times per second
[19:38:23] <SWPadnos> FEC is a re-coding of the data for robustness.
[19:38:25] <alex_joni> I agree
[19:38:33] <SWPadnos> I agree - sync / error checking is probably more important here
[19:38:35] <alex_joni> crc for now
[19:38:39] <jmkasunich> as long as we reject bad packets, we're OK
[19:38:58] <SWPadnos> (also, FEC nearly doubles the number of bits transmitted for every byte of data)
[19:39:07] <jmkasunich> totally unacceptable then
[19:39:15] <SWPadnos> we would just have to define some error condition on X refused packets in a row
[19:39:33] <alex_joni> do we have a ACK/NACK ?
[19:39:39] <alex_joni> from the receiver?
[19:39:40] <SWPadnos> could be acceptable for non-RS232, so having a model for it may be useful
[19:39:42] <jmkasunich> watchdog - good packet resets the watchgdog
[19:39:51] <SWPadnos> right
[19:40:15] <jmkasunich> no need for NACK - that is usually used to request a re-send
[19:40:21] <SWPadnos> Actually, different watchdog timeouts for "bad packet" vs. "no response"
[19:40:27] <jmkasunich> we'll be resending anyway in 1ms
[19:40:39] <jmkasunich> and the ACK will be a return packet
[19:41:13] <jmkasunich> we might be sending 2 floats, 3 bits, and and int, and receiving 1 float, 6 bits and no ints in return
[19:41:36] <SWPadnos> yeah - a "byte dispatcher" sould be a good thing here
[19:41:44] <SWPadnos> s/sould/would/
[19:42:13] <jmkasunich> SWPadnos: there is no such thing as a "bad packet", the algor described above (with the buffer, etc) simply rejects a byte at a time until a good packet shows up
[19:43:09] <jmkasunich> this is a master/slave protocol
[19:43:21] <jmkasunich> master sends a packet every 1mS, whether the slave is alive or not
[19:43:45] <SWPadnos> master may need to shut the machine down if the slave isn't listening
[19:43:58] <jmkasunich> slave replies with a packet whenever it gets a valid packet
[19:44:01] <SWPadnos> (or providing up to date feedback, for instance)
[19:44:40] <jmkasunich> master and slave both have watchdogs... 5mS without a packet from master, slave shuts down... 5mS without a reply from slave, master shuts down
[19:44:52] <SWPadnos> yes.
[19:45:03] <alex_joni> sounds sane
[19:45:20] <alex_joni> but you need to make sure the 5ms is actually longer on the initial handshake
[19:45:21] <SWPadnos> in fact, the same C code might be usable on both ends (with a bit set for "send always" vs. "send in response only"
[19:45:27] <alex_joni> start emc, start slave
[19:45:58] <alex_joni> maybe master keeps sending the handshake byte, over and over again, till it gets an alive slave
[19:46:02] <jmkasunich> initial handshake will be interesting - packet length might be unknown at that point
[19:46:07] <alex_joni> then it starts the 1 ms stuff
[19:46:12] <SWPadnos> What provisions are there for detecting problems with attached (or non-attached) hardware now?
[19:46:34] <jmkasunich> very little
[19:46:37] <SWPadnos> I would define a handshake protocol that's cast in stone
[19:46:57] <SWPadnos> possibly a shorter / longer packet than would normally be usable (like 20 bytes)
[19:47:18] <SWPadnos> let that have bitfields to tell data types and lengths
[19:47:27] <jmkasunich> ray's initial request didn't need any handshake... the user was responsible for ensuring that both ends were speaking the same format
[19:47:34] <SWPadnos> use that as sanity that you're talking to what you think you're talking to
[19:48:05] <alex_joni> who am I talking to?
[19:48:08] <alex_joni> lol
[19:48:27] <jmkasunich> assuming that the slave is some kind of hardware periphial, it should probably tell the master how many and what kind of data there is
[19:48:29] <SWPadnos> I suppose the device would never respond if you get the number of bytes wrong, but otherwise, it would be a Bad Thing to send bitfield data where the target is expecting a float
[19:49:07] <SWPadnos> (send 32 output bits, and the target thinks it's a 32-bit number, or the converse - whoops!
[19:49:39] <SteveStallings> dare I suggest that RS-232 handshake lines could be used to signal config/run mode or other state information?
[19:49:54] <SWPadnos> right - that "telling the master what it wants" is what I'm suggesting as a stone chisel handshake.
[19:49:55] <alex_joni> Steve: those are not always available
[19:50:01] <jmkasunich> SteveStallings: rather not, 3 wire is simplest
[19:50:22] <SWPadnos> and also the only guarantee with other wire-level protocols (such as RS485)
[19:50:32] <jmkasunich> the initial handshake would be done when the module is initialized, before the RT stuff starts running
[19:50:45] <jmkasunich> at insmod time, basically
[19:50:56] <SWPadnos> that would require the machine (or at least the controls) to be running at that time
[19:51:06] <SteveStallings> have fun syncing modes with external hardware 8-(
[19:51:08] <alex_joni> you mean the slave
[19:51:13] <SWPadnos> yes
[19:51:26] <alex_joni> how about this...
[19:51:31] <jmkasunich> you guys lost me
[19:51:36] <alex_joni> when the master starts... it enters the sync-mode
[19:51:45] <alex_joni> sending out "fbbbi"
[19:51:56] <alex_joni> and waits for the slave to agree on that
[19:52:17] <jmkasunich> I would do it the other way
[19:52:19] <alex_joni> maybe 0xFF 'f' 'b' 'b' 'i' 0xFF
[19:52:24] <alex_joni> or something
[19:52:32] <jmkasunich> the slave will never agree if that isn't the mix it is expecting
[19:52:37] <alex_joni> then (when the slave is switched on)
[19:52:45] <alex_joni> it reads the string
[19:52:57] <alex_joni> and replies with the same string (because it's supposed to)
[19:53:14] <SWPadnos> this may be bringing up a higher level question: how can we best deal with devices appearing / disapperaring during EMC execution (not actual machining, but just while EMC is running)?
[19:53:29] <alex_joni> or it doesn't .. because it expects something else.... then the sync doesn't get done
[19:53:36] <alex_joni> and the hal232 module won't output data
[19:53:41] <jmkasunich> if they're non-critical, ignore it... if critical, watchdog would trip
[19:53:50] <jmkasunich> how bout this:
[19:53:52] <alex_joni> it would sit in a loop and wait for a sync on fbbbi
[19:54:06] <alex_joni> same should happen when a comm-trouble is experienced,
[19:54:16] <alex_joni> it should retry syncing
[19:54:30] <SWPadnos> It can't be a loop - maybe a "poll interval"
[19:54:47] <alex_joni> a cyclic thing ;)
[19:54:56] <jmkasunich> the way I see it, the connection is established when the HAL module is loaded
[19:55:06] <SWPadnos> Right - you don't want the whole system waiting for DoohickeyX to be plugged in and turned on
[19:55:16] <alex_joni> loaded/configured
[19:55:16] <SWPadnos> What happens if you're using a USC, and the board isn't powered when you start EMC?
[19:55:19] <jmkasunich> if the hardware isn't there at that time, the module load will fail
[19:55:23] <SWPadnos> OK,.
[19:55:30] <alex_joni> fine with me ...
[19:55:43] <alex_joni> how about when you link 2 hal modules?
[19:55:43] <SWPadnos> (it's not pretty, but it works)
[19:55:48] <jmkasunich> so the handshake is done at module load time, NOT realtime
[19:56:02] <jmkasunich> init_module sends a "hello, anybody out there" message
[19:56:12] <SWPadnos> yes - the devices/protocols/modules should be initialized in non-RT
[19:56:12] <alex_joni> gets nothing.. BOOM ;)
[19:56:24] <alex_joni> there is no non-RT :P
[19:56:24] <jmkasunich> if no reply after a few retries, it reports failure and exits
[19:56:35] <alex_joni> jmk: I'm good with that
[19:56:38] <SWPadnos> (OK. non-time-critical :) )
[19:56:45] <jmkasunich> alex_joni: yes there is non-rt, the init_module part of a HAL module is non-RT
[19:56:58] <alex_joni> ahhh.. sorry ;)
[19:57:04] <SWPadnos> (nyah nyah)
[19:57:14] <alex_joni> btw.. I need to talk to you about init_module
[19:57:20] <jmkasunich> anyway, if it does get an answer, that answer tells it what the external device is, and what pins it should export to the HAL (IOW, the config comes from the _device_)
[19:57:47] <jmkasunich> then it exports the pins, and only after doing that does init_module end and realtime stuff start
[19:58:03] <alex_joni> but then somebody needs to link the pins
[19:58:06] <SWPadnos> That sounds good - config from device, and the module checks to see if it matches something in the EMC config
[19:58:20] <alex_joni> SWPadnos: no need ;)
[19:58:22] <SWPadnos> (hence the "schematic editing" you were talking about)
[19:58:31] <alex_joni> the linking of the pins won't match
[19:58:33] <alex_joni> and it will fail
[19:58:49] <alex_joni> so the check is done automatically
[19:59:06] <SWPadnos> well - what if I have three serial servo drives (on 3 serial ports), and I want to make sure the right one is used for Z?
[19:59:23] <SWPadnos> there should be some assignment of "hardware pins" to "HAL pins"
[19:59:26] <alex_joni> you can manually insmod the module
[19:59:30] <SWPadnos> (in the EMC / HAL config)
[19:59:39] <jmkasunich> good point... if the device sets the pin names, all three channels would be the same
[19:59:41] <alex_joni> and check if it's ol
[19:59:45] <alex_joni> ok
[19:59:55] <jmkasunich> you'll have three instances of the driver in that case, right....
[20:00:06] <alex_joni> 3 times...
[20:00:13] <alex_joni> and you'll have hal232.0.xxxx
[20:00:18] <alex_joni> hal232.1.yyyy
[20:00:24] <SWPadnos> possibly - a single driver could work, depending on the way the protocols are layered
[20:00:25] <alex_joni> hal232.2.zzzzz
[20:00:42] <alex_joni> it would be one module
[20:00:49] <alex_joni> but 3 HAL-instances
[20:00:55] <jmkasunich> so the device says "I need a pin called 'speed_ref'", and the module exports "hal232.1.speed_ref"
[20:01:02] <SWPadnos> There needs to be a way of sharing a "channel" driver, because that's the only way ethernet will work, I think
[20:01:28] <jmkasunich> right now we're assuming one master, one slavce
[20:01:30] <SWPadnos> the device should say "I have an analog output, and 3 digital outputs, plus 3 digital inputs"
[20:01:31] <jmkasunich> right now we're assuming one master, one slave
[20:01:42] <jmkasunich> right SWP
[20:01:46] <alex_joni> the device on ttyS1 (or RT-equivalent) says it needs an int...
[20:02:06] <SWPadnos> the EMC config should say "I'm expecting a device with these things, and I want to assign the analog output to "X Velocity output", and Digital input 1 to "X axis limit"
[20:02:11] <jmkasunich> but it might also supply (or suggest) names for the corresponding HAL pins
[20:02:26] <alex_joni> jmk: I think that's a must
[20:02:43] <alex_joni> how about telling emc where to link it too?
[20:02:45] <SWPadnos> yes - we could even have the handshake be capable of setting and retrieving names from a device
[20:02:50] <alex_joni> errr.. telling hal
[20:03:06] <jmkasunich> not linking... that may differ
[20:03:20] <alex_joni> ok.. then names only
[20:03:21] <jmkasunich> a device might be nothing more than a serially accessed version of an 8255
[20:03:38] <jmkasunich> one guy uses input 1 for one thing, another guy uses it for something else
[20:03:48] <jmkasunich> so the linking must still be done from the .hal file
[20:03:53] <SWPadnos> then, a manufacturer of a device could pre-configure the device (with "SpindleSpeed" as "analogOut1", for instance), and provide a piece of a config file that assigns the HAL Spindle Speed to "SpindleSpeed.CustomRS232Device1"
[20:04:39] <alex_joni> SwP: close (rs232.1.SpindleSpeed)
[20:04:52] <SWPadnos> OK - I'm digesting :)
[20:04:52] <alex_joni> or something in that format
[20:05:05] <alex_joni> that's the current HAL-way
[20:05:15] <alex_joni> like : iocontrol.0.spindle-on
[20:05:26] <SWPadnos> actually, it would be more like "SpindleSpeed=rs232.1.analogOut.1"
[20:05:28] <alex_joni> or: parport.0.pin14-out
[20:05:38] <jmkasunich> yeah SWP, the general HAL format is "<deviceclass>.<deviceinstance>.<devicespecificpinname>"
[20:05:40] <SWPadnos> yeah - what you said
[20:05:59] <SWPadnos> (I suppose I'll see that once I actually start looking :) )
[20:06:07] <alex_joni> SWP: ;)
[20:06:32] <jmkasunich> if a device provides "analogout.1", the assignment of that to SpindleSpeed should _NOT_ be embedded in the device
[20:06:38] <SWPadnos> hopefully I'll learn enough to be of some use at the Fest
[20:06:44] <jmkasunich> it is a generic analog out
[20:07:08] <SWPadnos> absolutely
[20:07:13] <alex_joni> ok.. then we have some basic types which can appear?
[20:07:20] <jmkasunich> but if the device is a servo amp, and that pin is the speed command then it shouldn't be called analogout.1, it should be called speedcommand
[20:07:54] <SWPadnos> but the manufacturer should be able to set up names that are a little more descriptive, for the purpose of preconfiguration for customers.
[20:07:54] <jmkasunich> so you might have "rs232.1.speedcommand" or "rs232.2.analogout1" depending on what the device is
[20:08:14] <alex_joni> jmk: right
[20:08:34] <jmkasunich> if you make a servo amp, you don't know when you make it whether it will run the X axis, or Y axis, or spindle, or maybe it just turns the toolchanger turret
[20:08:39] <alex_joni> both (speedcommand and analogout1) come from the device in the initial handshake
[20:08:45] <jmkasunich> but you do know that it has a speed command input
[20:09:08] <jmkasunich> right - one or the other comes from the device, based what kind of device it is
[20:09:20] <SWPadnos> you may have an RS232 device that outputs an analog voltage to a servo drive, which would make it highly bebeficial to have the ability to "rename" functions on a device, and/or to have the devices be capable of communicating some intent
[20:09:45] <SWPadnos> (I suppose that has little to do wiht EMC though)
[20:09:46] <jmkasunich> but if that device is connected to the servo by the end user using wires....
[20:09:50] <alex_joni> ok.. so the device will say: output, analog, named: speedcommand, datafromhal: float
[20:09:58] <jmkasunich> how would the device know that
[20:10:19] <SWPadnos> the manufacturer / integrator might know that.
[20:10:24] <SWPadnos> and want to make it easier for the end user
[20:10:41] <jmkasunich> I'd rather keep it generic
[20:10:41] <alex_joni> also: input, pin, named: estop-in, datatohal: bit
[20:10:55] <jmkasunich> HAL works that way already, using signal vs. pin names
[20:11:29] <SWPadnos> right. I realized that a manufacturer could always have some way of programming the "effective name" of any I/Os on their devices
[20:11:33] <jmkasunich> parport.1.pin-03-out is a HAL pin, totally generic because the parport "manufacturer" has no idea what you are gonna use pin 3 for
[20:12:03] <jmkasunich> when you hook it up, you can define a hal signal X_Step and link that signal to the pin
[20:14:21] <alex_joni> jmk: before this meeting ends...
[20:14:24] <SWPadnos> As a device vendor (which I'm not at this point), I would want to be able to take my serial AxisInterface, which might just encapsulate all of the I/Os you might want for a single axis (speed, feedback, limit, home, estop), and preconfigure 3 of them for a Bridgeport retrofit
[20:14:25] <jmkasunich> in addition to whatever pins the device wants, the driver should export one more, "hal232.1.deviceOK"
[20:14:26] <alex_joni> we need to talk about 2.6
[20:15:15] <SWPadnos> I would want to assign one input on one device as "XAxisLimit", and the same input on a different device as "YAxisLimit",and have HAL find them regardless of which serial port the end user plugs them into.
[20:15:48] <jmkasunich> if you want to... I sure wouldn't do it that way
[20:16:03] <SWPadnos> So it might be good to have a "discovery" protocol as well. though this could be vendor-specific, and a separate utility to rewrite EMC-configs
[20:16:12] <jmkasunich> that means you can't just have one spare servo amp, you need one for each axis
[20:16:36] <SWPadnos> ?
[20:16:40] <alex_joni> jmk: you "could" have a dip-switch on the device to select X/Y/Z
[20:16:49] <alex_joni> but it's not generic enough for me
[20:17:04] <SWPadnos> it could be U, V, W, A, B, or C as well.
[20:17:20] <jmkasunich> if amp A is preconfigured for axis X and amp B is preconfigured for Y
[20:17:47] <SWPadnos> then HAL can find it, as long as the serial channel protocol is good enough :)
[20:17:47] <jmkasunich> then what happens when one of them breaks and you want to substiture amp F from the shelf
[20:17:59] <jmkasunich> substitute
[20:18:25] <jmkasunich> I'd rather have EMC configure the amp than vice-versa
[20:18:28] <SWPadnos> you reassign the names, using a utility program or the HAL configuration
[20:18:51] <jmkasunich> I supplose
[20:18:52] <alex_joni> jmk: anyways... this is just a matter of philosophy ;)
[20:18:56] <jmkasunich> * jmkasunich remains skeptical
[20:19:00] <jmkasunich> agreed
[20:19:07] <alex_joni> the amp tells hal the pin-name
[20:19:10] <alex_joni> fullstop
[20:19:24] <jmkasunich> the amp tells hal _part_ of the pinnamee
[20:19:27] <alex_joni> that pin-name is supposed to exist in the .hal config
[20:19:28] <SWPadnos> yes - there are a number of things that would need to be in place for my idea to be useful
[20:19:33] <alex_joni> part, right
[20:19:38] <jmkasunich> and HAL prepends the module name
[20:20:09] <jmkasunich> btw, instead of "HAL232.1.pinname"...
[20:20:25] <jmkasunich> we might want "HAL232.1.dev01.pinname"
[20:20:40] <jmkasunich> to support RS-485 or other multidrop stuff
[20:21:18] <SWPadnos> now you're talking like USB: USB Host0:Bus0:Device01:endpoint01
[20:21:38] <SWPadnos> this type of thing would also be necessary for ethernet
[20:21:46] <jmkasunich> yeah
[20:21:47] <Jymmm> SWPadnos: Heh, that made me think of SCSI for some reason.
[20:22:06] <SWPadnos> in fact, "named autodiscovery" would be way more useful on ethernet or USB than RS232/485/422
[20:22:25] <jmkasunich> now let me throw one other possibility into the mix before we go deep into the autodiscovery
[20:22:33] <jmkasunich> peer-to-peer (or partially so)
[20:23:09] <jmkasunich> instead of "PC running HAL" talking to "device", how about "PC running HAL" talking to "PC running HAL"
[20:23:18] <jmkasunich> to connect hal variables from one PC to another
[20:23:40] <SWPadnos> yep - you'd have to have some flexible initialization/handshake to allow for that
[20:24:02] <SWPadnos> but anything that works for peers would be more than sufficient for master/slave
[20:24:09] <jmkasunich> and you'd have to allow for the fact that one PC's 1mS thread seems like 1.01mS to the other
[20:24:41] <SWPadnos> or 0.99
[20:24:50] <jmkasunich> one would still have to be a master and the other a slave
[20:25:09] <jmkasunich> I think
[20:25:23] <SWPadnos> true enough -but more "peer-ish" in processing capability
[20:25:56] <jmkasunich> right - I was just talking about the handshake and protocol
[20:26:16] <jmkasunich> with master/slave, slave replies when it gets a message, master knows it is well
[20:26:45] <jmkasunich> slave only knows that master is talking to it, not it master is hearing it's replies
[20:27:41] <jmkasunich> not _IF_ master is hearing
[20:27:59] <SWPadnos> right
[20:28:38] <jmkasunich> one approach for peer-to-peer would be to admit that it is master/slave
[20:28:45] <SWPadnos> you then get into interesting things with what types of information can be passed to a slave
[20:28:52] <jmkasunich> the master would use the same driver as for any other device
[20:29:07] <SWPadnos> for instance, an EMC machine that is master to another EMC machine could potentially just send G-code on the wire
[20:29:12] <jmkasunich> the slave would use a completely different HAL module, that acts like a "device"
[20:29:28] <jmkasunich> you wouldn't send G-code thru HAL
[20:29:43] <SWPadnos> true - you'd want to separate that at a higher level.
[20:30:26] <jmkasunich> I'm thinking one PC running the machine, another running a toolchanger or something, with a half dozen bits and an int or two connecting them
[20:30:37] <SWPadnos> right
[20:31:17] <SWPadnos> or even multiple A/B/Z heads doing different manufacturing steps on the same machine
[20:31:23] <jmkasunich> anyway, the HAL module for the slave side would read config info to tell it what pins will be crossing the "bridge" to the other side, and it would appear as a device with those pins to the master
[20:31:25] <SWPadnos> or a pick/place robot with multiple arms
[20:33:33] <alex_joni> SWP: a shiva-type?
[20:33:48] <SWPadnos> maybe - what's that?
[20:34:01] <alex_joni> shiva is an indian goddess with 8 arms ;)
[20:34:04] <jmkasunich> I hope somebody's been logging this
[20:34:07] <SWPadnos> duh
[20:34:09] <SWPadnos> :)
[20:34:27] <SWPadnos> I thought you meant some machine :)
[20:34:35] <Jymmm> oh gawd... that's a name I haven't heard in years.... shiva serial cards...
[20:34:38] <SWPadnos> (like the Pumas mentioned earlier)
[20:34:40] <alex_joni> nah.. just fooling around
[20:34:44] <SWPadnos> shivamodem
[20:35:01] <jmkasunich> I have to leave for a few hours
[20:35:03] <SWPadnos> What's a Puma - a big cat!
[20:35:13] <Jymmm> SWPadnos: sneaker
[20:35:19] <alex_joni> Kali, Tripura, Shiva, Ganesha, Cchinnamasta, Durga
[20:36:11] <jmkasunich> jmkasunich is now known as jmk_away
[20:38:07] <Jymmm> wow... he leaves and you can hear a pin drop in here =)
[20:38:31] <alex_joni> ...... ping .....
[20:38:37] <SWPadnos> piong
[20:38:39] <dave-e> pong
[20:38:39] <Jymmm> lol
[20:38:46] <SWPadnos> dong
[20:38:51] <alex_joni> Jymmm: see what you have done?
[20:39:02] <alex_joni> now there are a lot of pins on the floor
[20:39:27] <Jymmm> alex_joni Got Magnet?
[20:39:35] <dave-e> I thought pins belonged to HAL
[20:39:39] <alex_joni> electromagnet ;)
[20:39:42] <alex_joni> he dropped them
[20:39:47] <dave-e> some pins are brass
[20:40:05] <SWPadnos> I have stainless
[20:40:15] <Jymmm> Got Plasma?
[20:40:17] <dave-e> oh, classy
[20:40:22] <Jymmm> floor art!
[20:40:34] <alex_joni> got a plasma at work ;)
[20:40:44] <dave-e> ray?
[20:41:11] <alex_joni> cutter
[20:41:29] <SWPadnos> So Alex - you wanted to talk about 2.6
[20:41:37] <dave-e> bye guys
[20:41:38] <SWPadnos> but probably with someone who knows something
[20:41:41] <alex_joni> yeah...
[20:43:41] <alex_joni> SWP: familiar with kbuild?
[20:43:48] <SWPadnos> peripherally
[20:43:51] <SWPadnos> (no pun intended)
[20:44:07] <SWPadnos> I'd love it if EMC could work with KBuild
[20:44:16] <SWPadnos> (as I'll even help, if I can)
[20:44:20] <SWPadnos> (and)
[20:44:33] <alex_joni> it works on emc1 (bdi-4 tag)
[20:46:18] <SWPadnos> Ther eis no emc1 BDI-4 tag - that's on ENC2
[20:46:24] <SWPadnos> EMC (I need more caffeiene)
[20:46:32] <alex_joni> emc2 .. right
[20:46:36] <alex_joni> but the code is emc1 ;)
[20:46:47] <alex_joni> awkward.. isn't it
[20:46:55] <SWPadnos> sort of - it has HAL and NML, so it looks fairly EMC2-ish
[20:47:01] <alex_joni> yup
[20:47:03] <Jymmm> Dumbass question that's always bugged me... How do you cut a square hole in a solid block of material on a mill? (no inside radius corners)
[20:47:18] <SWPadnos> you don't - there is always the radius of your cutter
[20:47:26] <alex_joni> there are square drills
[20:47:47] <SWPadnos> like a mortising jig? for metal?
[20:47:51] <Jymmm> alex_joni: like a boring jig?
[20:47:58] <Jymmm> what SWPadnos said
[20:48:33] <alex_joni> http://upper.us.edu/faculty/smith/reuleaux.htm
[20:48:38] <alex_joni> some radius on the edges
[20:49:08] <roel1> hi
[20:49:15] <alex_joni> hello
[20:50:21] <SWPadnos> hi
[20:51:12] <Jymmm> alex_joni: I'll be damn... thanks!
[20:51:41] <alex_joni> Jymmm: helps?
[20:51:53] <SWPadnos> me damned too
[20:52:41] <Jymmm> alex_joni: It's always been a curiosity to me. I coulda sworn I saw a finished milled piece once with no radius, but I couuld never figure out how it was done.
[20:52:58] <alex_joni> it has some radius...
[20:53:07] <Jymmm> alex_joni (aerospace machine shop)
[20:53:11] <SWPadnos> a rectangular punch does a nice job :)
[20:53:20] <alex_joni> SWP: laser does too
[20:53:41] <alex_joni> Jymmm: making space-station parts again?
[20:53:44] <SWPadnos> or making 2 halves with square end mills - but that's a different story :
[20:53:45] <Jymmm> oh dont get me started on lasers today please
[20:53:45] <alex_joni> lol
[20:53:48] <SWPadnos> :)
[20:54:10] <alex_joni> how about waterjet?
[20:54:20] <paul_c> Take a tapered cutter (like a countersink tool) and tilt the head over at an angle...
[20:54:39] <ottos> good day gents...
[20:54:45] <alex_joni> greetings
[20:55:17] <Jymmm> I found a 60W laser engraver for $6500, but they didn't have a PDF of the manual available.
[20:55:26] <Jymmm> makes me iffy
[20:58:14] <asdfqwega> Does anyone know what kind of .dxf Synergy will import?
[20:58:48] <asdfqwega> I've just tried importing some from Qcad - doesn't work, or I've missed something
[20:59:20] <asdfqwega> Bloody compatibility mess...
[21:00:22] <ottos> would anyone know of any high speed spindle (liquid cooled ) for a resonable price ?
[21:00:35] <ottos> I knwo DFX has many flavors...might be tricky...
[21:01:59] <asdfqwega> ottos: I've got a couple used (< 10K rpm) ceramic ball-bearing units sitting on a shelf
[21:02:13] <asdfqwega> Mixture of air-oil lubed/cooled
[21:02:26] <ottos> hmm...what kind? how much...
[21:02:29] <SWPadnos> Well - that's cheap :)
[21:02:48] <Jymmm> SWPadnos mine?
[21:03:31] <ottos> 10k is the max...I was hoping for 20k , ceramics grinding...
[21:03:55] <asdfqwega> Oh, if you want that high, those really cost
[21:04:32] <asdfqwega> I got these used from someplace that uses them in Huffman/Walter multi-axis grinders
[21:04:54] <ottos> wattage?
[21:05:23] <asdfqwega> No idea
[21:05:41] <ottos> physicaly how big?
[21:06:01] <asdfqwega> spindle is Boneham, type gs2826ap, max 6500rpm
[21:07:07] <asdfqwega> Most their machines were 12'x12' to 20'x20'
[21:07:21] <ottos> ya 6.5k is slow for the app i'm running...
[21:07:26] <asdfqwega> Floor footprint
[21:08:15] <ottos> well maybe my next machine..:D
[21:09:11] <asdfqwega> How many times have we all said that?
[21:09:41] <Jymmm> 99,999,999,999,999,999,999,999,999,999,999,999,999,999,999,999,999,999,999,999,999,999,999,999,999,999,999,999,999,999,999,999,999,999,999, Today alone.
[21:10:48] <alex_joni> * alex_joni thinks Jymmm has lost it ;)
[21:11:03] <Jymmm> * Jymmm KNOWS Jymmm has lost it!
[21:12:09] <SWPadnos> do you need something big, or would something like this do http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3875571342
[21:12:31] <SWPadnos> nevermind - you said liquid cooled
[21:12:35] <SWPadnos> * SWPadnos slaps myself
[21:12:45] <alex_joni> anyone know what module-init-tools is required for 2.6? (would the one from http://www.kernel.org/pub/linux/utils/kernel/module-init-tools/ do it?)
[21:13:17] <SWPadnos> if it says module-init-tools, you['re most of the way there. the old one was modutils
[21:13:25] <ottos> nice unit but kinda skiddish...I was thinking like a used precise or colombo spindle...
[21:13:56] <alex_joni> I have module-init-tools 0.9.8
[21:15:08] <ottos> well time to go...will catch you next weekend at the same emc time at the same emc chanell...:D
[21:15:19] <SWPadnos> that's probably a little old.
[21:15:32] <SWPadnos> using ver_linux on my machine, I come up with 3.0 :)
[21:15:43] <SWPadnos> emerge search module-init
[21:15:51] <SWPadnos> (damn - two keyboards)
[21:16:03] <alex_joni> what's emerge?
[21:16:15] <SWPadnos> the Gentoo linux package manager
[21:16:29] <alex_joni> ahh
[21:16:30] <alex_joni> ok
[21:20:14] <Jymmm> anyone know the name of this extruded aluminum piece or a url? http://www.data-cut.com/Supporting%20Image/x-leadpos.jpg
[21:20:40] <SWPadnos> 80-20, available at www.80-20.net
[21:21:05] <SWPadnos> oops - wrong URL - wait a minute
[21:21:21] <SWPadnos> http://www.8020.net
[21:21:37] <Jymmm> ty =)
[21:21:43] <SWPadnos> np
[21:22:05] <Jymmm> SWPadnos you played with it yet?
[21:22:18] <alex_joni> hmmm.. I wonder if I need an recent e2fsprogs
[21:22:54] <alex_joni> I have ReiserFS on my /dev/hda
[21:25:06] <SWPadnos> well - you''d probably wans reiserprogs for that :)
[21:25:14] <SWPadnos> want
[21:35:55] <alex_joni> pretty quiet ;)
[21:36:14] <Jymmm> * Jymmm fixes that....
[21:36:51] <SWPadnos> lalala
[21:37:13] <alex_joni> SWP: you said you know kbuild ?
[21:37:29] <Jymmm> I hate to sound like a cheap bastard, but as I'm looking to find cnc router plans I'm leery about buying them... Mostly for things like this... 7th photo down... http://www.data-cut.com/page5mv.html
[21:37:54] <SWPadnos> um - well - I know what it is :)
[21:38:04] <SWPadnos> I know a little about it, but I'm no expert
[21:38:21] <alex_joni> I can't figure out a makefile... too tired to rtfm ;)
[21:38:33] <SWPadnos> which one?
[21:39:06] <alex_joni> emc2(bdi-4)/src/Makefile
[21:39:32] <SWPadnos> * SWPadnos takes a look
[21:40:19] <SWPadnos> what's causing you trouble?
[21:40:35] <CIA-4> 03paul_c 07bdi-4 * 10emc2/src/ (Makefile Makefile.inc.in): Use the module flags that configure found rather than relying on rtai-config being in /usr/bin - Removed LD & LDFLAGS from the Makefile.inc template as they *really* screw up kbuild (not needed anyway).
[21:41:24] <SWPadnos> (are those CIA-4 messages auto-generated by SourceForge?)
[21:41:48] <paul_c> nope - By a bot
[21:42:12] <SWPadnos> OK - they looked a bit colorful for a person :)
[21:42:47] <SWPadnos> so - I just tried compiling, and I don't have all the errors in my console scrollback buffer (there were so many)
[21:43:22] <paul_c> there is a script at SF that sends the bot an email on each commit.
[21:43:22] <alex_joni> use script
[21:43:29] <paul_c> mak2 2>&1 | tee error.log
[21:44:28] <paul_c> make 2>&1 | tee error.log
[21:44:28] <SWPadnos> yeha - doing that
[21:44:28] <SWPadnos> yeah
[21:44:28] <paul_c> SWPadnos: http://cia.navi.cx/stats/project/emc
[21:44:28] <SWPadnos> (I *really* need more caffeiene)
[21:44:36] <paul_c> alex_joni: What is confusing about the makefile for 2.6 ?
[21:49:52] <SWPadnos> Well - it doesn't like the EMC_TOOL_MODULE class declaration in emcio.hh
[21:50:07] <SWPadnos> (Gcc 3.3.4 on Gentoo Linux)
[21:50:14] <alex_joni_> darn.. got disconnected
[21:50:57] <SWPadnos> hi agan. So - what's causing confusion in the makefile?
[21:51:19] <paul_c> paul_c has kicked alex_joni from #emc
[21:52:18] <alex_joni_> thx
[21:55:06] <SWPadnos> in fact, I think it's choking on classes in general (and all the things that go wrong when you don't understand the start of a class)
[21:55:06] <SWPadnos> though gcc is knowledgeable of constructors/destructors, so it is sompiling in C__ mode
[21:55:06] <SWPadnos> compiling, that is
[21:55:06] <paul_c> can you cut'n'paste the start of the errors
[21:55:45] <SWPadnos> sort of - I'm working on 2 machines right now.
[21:55:47] <SWPadnos> maybe I'll join from the Linux box
[21:57:14] <SWPLinux> well - here I am on the Linux box.
[21:57:20] <alex_joni_> what OS is adnos?
[21:57:28] <paul_c> as root
[21:57:32] <SWPLinux> It's my own ;)
[21:57:55] <alex_joni_> root's just fine...
[21:57:58] <SWPLinux> of course - I'm prophylactically challenged
[21:58:22] <alex_joni_> maybe he changed the name of the superuser.. and root is just a normal user?
[21:58:31] <alex_joni_> now that would be something :))
[21:58:33] <SWPLinux> make[2]: Entering directory `/Project/EMC/emc2/src/emc/iotask'
[21:58:34] <SWPLinux> Compile 'bridgeportaux.cc' to tmp dir using default C++ rule
[21:58:34] <SWPLinux> g++ -c -Wall -g -I/Project/EMC/emc2/src/include -I/usr/realtime/include -I. -Dnonrealtime -O2 -I/usr/include -I/
[21:58:35] <SWPLinux> usr/X11R6/include bridgeportaux.cc -o /Project/EMC/emc2/src/.tmp/bridgeportaux.o
[21:59:17] <SWPLinux> In file included from bridgeportaux.cc:24:
[21:59:17] <SWPLinux> emcio.hh:35: error: parse error before `{' token
[21:59:17] <SWPLinux> emcio.hh:39: error: destructors must be member functions
[21:59:17] <SWPLinux> emcio.hh:114: error: parse error before `}' token
[21:59:17] <SWPLinux> emcio.hh:118: error: parse error before `{' token
[21:59:18] <SWPLinux> yeah - that's my super-secure plan :)
[22:01:30] <alex_joni_> sounds like NML_MODULE is not known
[22:01:54] <SWPLinux> yes, it does.
[22:01:59] <alex_joni_> right.. nml_mod.hh is not available
[22:02:14] <SWPLinux> it is now - Paul fixed that
[22:02:22] <alex_joni_> it is?
[22:02:42] <paul_c> hang on a sec...
[22:03:00] <SWPLinux> KN - maybe not.
[22:03:00] <SWPLinux> OK, that is
[22:03:28] <SWPLinux> I noticed a message about nml_mod.{cc,hh} when I re-checked out this branch
[22:04:00] <SWPLinux> I guess it didn't update them, since they're still the blank files I created earlier
[22:04:00] <alex_joni_> ahh.. you had those blank files
[22:04:08] <SWPLinux> right
[22:04:16] <paul_c> rm -fR src/
[22:05:00] <paul_c> cvs up -dP
[22:05:00] <SWPLinux> did I screw up the repository? (I'm no expert with CVS)
[22:05:00] <alex_joni_> nope
[22:05:00] <paul_c> just your local copy
[22:05:00] <alex_joni_> you need to commit to screw up the repository
[22:05:02] <SWPLinux> well - that's a relief. (I wouldn't have thought so with a checkout...)
[22:05:11] <alex_joni_> that would have printed a message from CIA
[22:05:19] <SWPLinux> Ah - so I should be committed, then. Got it :)
[22:05:20] <alex_joni_> next people would have screamed ;)
[22:05:27] <SWPLinux> yes!
[22:05:28] <paul_c> SWPLinux: Do you have a SF account registered ?
[22:05:41] <anonimasu> dosent sf keep backups before the changes?
[22:05:45] <SWPLinux> yes - I'm on the developer list for EMC
[22:05:50] <paul_c> * paul_c goes to delete a few names...
[22:05:55] <SWPLinux> (bastid)
[22:06:06] <alex_joni_> an0n: all the versions are in CVS
[22:06:13] <alex_joni_> from 0 to latest
[22:06:43] <alex_joni_> you can checkout any version any time
[22:06:43] <alex_joni_> co -time yesterday
[22:06:43] <alex_joni_> or smthg like that ;)
[22:06:43] <paul_c> and even mix'n'match
[22:07:10] <paul_c> cvs co -D"three days ago"
[22:07:10] <anonimasu> ah, so if you kill the tree accidentally you still have the changes made before
[22:07:10] <SWPLinux> if you know what you're doing :)
[22:07:27] <alex_joni_> * alex_joni_ is baffled that paul_c didn't throw the famous "read the Red book" phrase
[22:07:34] <alex_joni_> alex_joni_ is now known as alex_joni
[22:07:45] <paul_c> and read the Read Bean CVS book
[22:08:00] <SWPLinux> I looked for that - it's now a SubVersion book.
[22:08:03] <alex_joni> that's the one ;)
[22:08:30] <alex_joni> an0n: once in CVS it won't go away
[22:08:42] <anonimasu> I have no desire to learn more about cvs :).. I'd rather get a book on algorithm optimization or somthing like that..
[22:09:00] <anonimasu> alex_joni: eternal bugs ^_^
[22:09:00] <alex_joni> you cannot delete it, cannot make it disappear
[22:09:00] <alex_joni> it's there ;)
[22:09:00] <SWPLinux> how embarrassing
[22:09:00] <alex_joni> or in the Attic
[22:09:11] <alex_joni> but it gets forgotten after a while...
[22:09:19] <alex_joni> so .. shouldn't care ;)
[22:10:13] <alex_joni> * alex_joni has got to go...
[22:10:17] <anonimasu> ok
[22:10:24] <alex_joni> picking up my dad at the airport
[22:12:13] <anonimasu> ok
[22:12:15] <anonimasu> * anonimasu yawns
[22:12:24] <anonimasu> I'll be heading for bed in a couple of minutes
[22:12:57] <anonimasu> goodnight
[22:14:18] <SWPLinux> OK - it loks better now. It's missing rtai_shm.h (included from usrmotintf.c)
[22:14:22] <SWPLinux> looks
[22:14:44] <SWPLinux> make[2]: Entering directory `/Project/EMC/emc2/src/emc/iotask'
[22:14:44] <SWPLinux> Compile 'usrmotintf.c' to tmp dir using non-realtime C rule
[22:14:44] <SWPLinux> gcc -c -Wall -g -I/Project/EMC/emc2/src/include -I/usr/realtime/include -I. -Dnonrealtime -O2 usrmotintf.c -o /Project/EMC/emc2/src/.tmp/usrmotintf.o
[22:14:44] <paul_c> did you re-run configure ?
[22:14:44] <SWPLinux> usrmotintf.c:129:22: rtai_shm.h: No such file or directory
[22:14:44] <SWPLinux> usrmotintf.c: In function `usrmotInit':
[22:14:44] <SWPLinux> usrmotintf.c:1069: warning: implicit declaration of function `rtai_malloc'
[22:15:01] <SWPLinux> yes
[22:15:56] <alex_joni_> paul_c: are you going to programmers_fest this year?
[22:16:14] <paul_c> undecided at the moment
[22:16:37] <SWPLinux> Awww - come on. I know a good Thai restaurant :)
[22:16:50] <alex_joni_> I see.. maybe a wiki page for the goals would be nice
[22:17:41] <SWPLinux> Good idea. Developing goals may be a bit more conversational, though.
[22:18:45] <alex_joni_> developing goals is what I meant
[22:18:50] <alex_joni_> * alex_joni_ leaves now
[22:19:21] <asdfqwega> A wiki page for Synergy would be nice, too
[22:20:26] <asdfqwega> * asdfqwega is wrestling with Synergy - quite a learning curve
[22:20:50] <SWPLinux> most CAD is a learning cliff.
[22:21:31] <asdfqwega> Yeah, but Weber seems to have gone off on it's own tangent (no pun intended)
[22:23:29] <Imperator_> * Imperator_ is searching behind which of the prosesses listet in emc.nml hides the motion controller ???????
[22:28:48] <paul_c> process name: emc
[22:29:55] <Imperator_> and all that ini stuff (iniaxis.c ...) is that the same process ???
[22:32:21] <paul_c> the ini configs get passed to the realtime kernel module (where the motion is handled)
[22:33:23] <paul_c> in my opinion, most of the ini NML messages are not needed.
[22:34:14] <Imperator_> hmm
[22:35:11] <Imperator_> I try to follow the way of the AxisType parameter which is read from iniaxis.cc from the inifile
[22:36:09] <Imperator_> it will be send by taskintf.cc through the Status channel
[22:36:22] <Imperator_> then I lost it
[22:38:20] <Imperator_> the only writer to the status channel is emc
[22:38:25] <SWPLinux> OK - I think I'll need to install RTAI 3.1 - I have the experimental Fusion branch right now, and that has no rtai_shm.h
[22:39:14] <Imperator_> but then the motion controller and the inistuff is in the same process ?????
[22:40:06] <paul_c> no - Motion is in kernel space, and the ini parser is usr space
[22:40:22] <Imperator_> ok
[22:41:42] <Imperator_> but for NML they are both "emc" ?
[22:42:11] <paul_c> axisType is not actually fed to the motion control - It is just a string used by the GUI...
[22:43:11] <Imperator_> aha
[22:43:35] <Imperator_> then i can search forever in the motion controller for it :-)
[22:43:59] <paul_c> you could ;}
[22:44:15] <Imperator_> thanks for stopping me
[22:45:10] <paul_c> the clue is in the functions (in taskintf) that call usrmotWriteEmcmotCommand
[22:45:34] <paul_c> If it is called, then data is passed to the motion control
[22:49:33] <Imperator_> ok
[22:50:53] <paul_c> the motion controller does nt use NML directly.
[22:54:06] <Imperator_> only trough the userspace part
[22:54:24] <paul_c> yup
[22:56:28] <Imperator_> I still think we have to kick NML in EMC2
[22:57:00] <paul_c> how do you mean ??
[22:57:38] <Imperator_> we replace it with some pointers
[23:00:27] <paul_c> you mean get rid of NML all together ?
[23:03:49] <Imperator_> jep
[23:04:20] <Imperator_> don't know if that is possible/usefull
[23:05:15] <Imperator_> but then EMc loses his right to exist
[23:06:38] <Imperator_> because I think the only reason that EMC exists is that NIST was searching for something to use NML/RCS
[23:07:21] <paul_c> It would be possible to get rid of NML, but we would lose the ability to run a distributed system
[23:07:40] <Imperator_> jep I know
[23:08:10] <Imperator_> but then it would be easy to understand EMC
[23:08:23] <SWPLinux> you still need a means of communicating between the RT and non-RT systems
[23:09:00] <paul_c> agreed, but NL isn't used there anyway.
[23:09:00] <Imperator_> that can be done by pointers
[23:09:13] <SWPLinux> Well - in that case - give it the axe :)
[23:09:18] <Imperator_> ->is done by pointers
[23:09:23] <paul_c> usr space<=>realtime comms uses shared memory
[23:09:39] <SWPLinux> right
[23:09:40] <Imperator_> that means pointers, right ?
[23:10:05] <SWPLinux> which brings me back to my compile issues
[23:10:05] <paul_c> pointer to shared memory...
[23:10:24] <SWPLinux> I have installed RTAI 3.1 instead of RTAI-Fusion
[23:10:56] <SWPLinux> I now get errors regarding rtai-config (usr/bin/rtai-config, not /usr/realtime/bin/rtai-config)
[23:11:31] <SWPLinux> also, the following problem: /usr/src/linux-2.6.9/scripts/gcc-version.sh: line 1: -E: command not found
[23:11:39] <Imperator_> is it used for the communication between userspace<->realtime in EMC1 ???
[23:12:21] <paul_c> SWPLinux: which one is the correct one to call
[23:12:21] <paul_c> Imperator_: EMC1 still uses shared memory
[23:12:21] <Imperator_> ok
[23:12:26] <SWPLinux> for rtai-config, I found it in usr/realtime/bin
[23:13:28] <paul_c> configure --with-rtai=/usr/realtime
[23:13:28] <SWPLinux> I'll try that, but ./configure seemed to pick that up.
[23:14:30] <SWPLinux> nope - didn't help.
[23:14:49] <SWPLinux> I may have a problem with RTAI now - I can't run the tests
[23:16:24] <SWPLinux> OK - that's working (PEBCAK)
[23:16:49] <paul_c> re: /usr/src/linux-2.6.9/scripts/gcc-version.sh: line 1: -E: command not found - That shell script prints the gcc version number..
[23:17:13] <SWPLinux> OK - so `gcc --version` should work also
[23:17:23] <paul_c> if that is failing, I would suspect the system is borked
[23:17:45] <paul_c> # Prints the gcc version of `gcc-command' in a canonical 4-digit form
[23:17:45] <paul_c> # such as `0295' for gcc-2.95, `0303' for gcc-3.3, etc.
[23:18:01] <SWPLinux> could be
[23:19:38] <SWPLinux> well - sh reports itself as "GNU bash, version 2.05b.0(1)-release (i686-pc-linux-gnu)"
[23:20:53] <paul_c> echo __GNUC__ | $compiler -E -xc - | tail -n 1
[23:21:04] <paul_c> echo __GNUC__ | gcc -E -xc - | tail -n 1
[23:21:17] <paul_c> should print "3"
[23:22:11] <SWPLinux> nope - "bash: -E: command not found"
[23:23:18] <paul_c> gcc -dumpversion
[23:24:18] <SWPLinux> yields 3.3.4
[23:24:18] <paul_c> try the second incantation
[23:24:23] <SWPLinux> gives 3
[23:24:40] <SWPLinux> right - I have no compiler variable
[23:25:06] <SWPLinux> (at least, not in my terminal shell)
[23:25:06] <paul_c> $compiler should be set by kbuild
[23:25:07] <SWPLinux> yep
[23:28:53] <Imperator_> Ok, late here
[23:28:58] <Imperator_> by
[23:29:08] <SWPLinux> see ya
[23:31:55] <Jymmm> 30k holes / minute!
[23:42:17] <SWPLinux> OK - I found the build problem!
[23:42:33] <paul_c> and it was ?
[23:42:42] <SWPLinux> The primary Makefile has two locations where rtai-config is called
[23:42:52] <SWPLinux> the first is on line 4, the second on line 84
[23:43:36] <SWPLinux> neither of these are set to the detected rtai-config location
[23:43:36] <SWPLinux> the first was set to /usr/bin/rtai-config (vs. /usr/realtime/bin)
[23:43:41] <SWPLinux> the second was just a bare rtai-config, with no path
[23:44:50] <SWPLinux> changed both of those to /usr/realtime..., and the make finished (with warnings)
[23:44:50] <paul_c> do a cvs up - I've committed a change there.
[23:44:50] <SWPLinux> OK
[23:49:34] <SWPLinux> that worked fine (unless I didn't actually get your changes :) )
[23:50:00] <SWPLinux> I assume an M before a filename means that the file was modified
[23:50:07] <paul_c> yup
[23:50:15] <SWPLinux> does that mean it was left alone, or that the modifications were downloaded
[23:50:23] <SWPLinux> ?
[23:50:34] <paul_c> look at line 8
[23:51:09] <paul_c> EXTRA_FLAGS := $(RTFLAGS) -I/usr/include -D__MODULE__
[23:51:31] <paul_c> You'll probably need to re-run configure too.
[23:51:57] <SWPLinux> nope - that's not what I have. what is the exact cvs command to update my code from the repository?
[23:52:51] <SWPLinux> (my copy)
[23:52:51] <paul_c> cvs up
[23:52:51] <paul_c> or:
[23:52:51] <paul_c> cvs update
[23:52:56] <paul_c> but if you have edited makefile, it may not update correctly
[23:54:18] <paul_c> In which case, delete the file and do an update again.
[23:54:18] <SWPLinux> hmmm. what about various configure files - would those get left alone or updated?
[23:54:25] <SWPLinux> I can always delete src/ and update then, but that would be tedious after a while
[23:57:37] <jmk_away> jmk_away is now known as jmkasunich
[23:57:54] <jmkasunich> * jmkasunich is back
[23:59:04] <SWPLinux> Hi there, JMK