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