Back
[00:01:02] <paul_c> cradek: Running your little func. here - No NaN to report.
[00:14:53] <paul_c> jepler cradek: The NaN bug would have cropped up when any usr space app did FP calculations.
[00:55:32] <anna_emc> hello
[00:55:43] <anonimasu> hello
[01:07:42] <robin_sz> hmm ...
[01:07:47] <robin_sz> she didnt stay long
[01:21:05] <Jacky^> G nighttt
[03:27:38] <A-L-P-H-A> Time: 22:05:02 -0500 GMT, Windows XP Professional, Service Pack 2 (5.1 - 2600), AMD XP 2800+ running at (1-AMD , 2123MHz, 512KB (0% Load)), DDR400 RAM Usage: 555/1024MB (54.20%), C: 43.97gb of 75.42gb free, D: 0gb of 0gb free, N: 1.67gb of 372.62gb free, Current Uptime: 6hrs 32mins 9secs, Record Uptime: 3wks 12hrs 48mins 50secs, 3 Samsung 19" flat monitors (1 Trinitron, 2 CRT).
[07:06:57] <LawrenceG> # lpg - axis (emc display) likes glx loaded and hates dri loaded
[07:06:57] <LawrenceG> # This loads the GLX module
[07:06:57] <LawrenceG> Load "glx"
[07:06:57] <LawrenceG> # This loads the DRI module
[07:06:59] <LawrenceG> # Load "dri"
[07:31:42] <LawrenceG> * LawrenceG going to bed... goodnight all
[07:31:51] <Jymmm> gnight
[07:50:45] <A-L-P-H-A> let there be speaking, at some point in time
[14:23:20] <bosone> hello :)
[14:25:03] <bosone> using video ram as swap:
http://hedera.linuxnews.pl/_news/2002/09/03/_long/1445.html
[14:53:22] <dmess> hi all
[14:55:46] <anonimasu> hi dmess
[14:56:31] <dmess> whats up anon
[14:57:24] <anonimasu> working on this drawing
[14:58:44] <dmess> of what??
[14:59:32] <anonimasu> a slide throttle body..
[15:00:34] <dmess> for what??
[15:00:56] <anonimasu> a car :)
[15:01:30] <dmess> cool
[15:02:31] <anonimasu> like they use in racing..
[15:02:36] <anonimasu> but this design is a bit special
[15:04:39] <anonimasu> I have the cam generated in a bit
[15:04:39] <anonimasu> :)
[15:04:48] <anonimasu> so I am going to machine a prototype of it later tonight
[15:04:50] <anonimasu> maybe
[15:05:10] <dmess> right on... ; )
[15:06:01] <anonimasu> I've yet to decide on some stuff related to it
[15:06:28] <dmess> what are you going to try it on.. your car??
[15:06:44] <anonimasu> I am building a new engine soon..
[15:06:54] <anonimasu> ;)
[15:06:57] <dmess> ahh i see
[15:07:09] <anonimasu> slide/roller throttle bodies are like 1000$.. ;)
[15:07:37] <anonimasu> http://motorsport.bdg.com.au/roller.html
[15:08:56] <anonimasu> going to modify the design later when I have access to cfd software :)
[15:11:40] <anonimasu> might be a bit overkill though
[15:31:41] <dmess> think it through.. there's possibly a good reason for them to be 1000$
[15:32:53] <dmess> pre machine of alloy steel components... heat treat.. grinding.. possibly lapping
[15:33:33] <dmess> fuel injection components are not easy parts to mfg
[18:38:40] <cradek> hi paul_c
[18:38:46] <cradek> that's great news about fp on bdi being fixed
[18:39:42] <paul_c> twas a compare with a stupid bloody float...
[18:39:51] <cradek> eh?
[18:40:48] <cradek> I didn't see a checkin go by ... are you saying it was a simple bug in emc?
[18:41:21] <paul_c> I haven't got as far as doing a commit.
[18:41:42] <cradek> I'm anxious to see what it was. Does it need to be fixed in several trees?
[18:41:49] <paul_c> but, yes. It was just a couple of lines that were probably the cause.
[18:42:17] <cradek> it was good to get some more data points from Oscar Dalem
[18:42:23] <cradek> I hadn't seen him around before
[18:43:38] <paul_c> It won't affect the EMC1 tree as that has FP enabled in all RT threads.
[18:44:14] <cradek> ok, that's good.
[18:44:31] <cradek> and emc2/cvs works correctly
[18:44:58] <paul_c> If something of a similar nature exists in the emc2 head, then it will be something for JMK to fix.
[18:45:06] <cradek> it doesn't
[18:45:14] <cradek> at least, not that we could find
[18:45:19] <cradek> we tried last night
[18:46:10] <paul_c> there are other bugs in HEAD that JMK needs to fix.
[18:50:34] <cradek> oh I'm sure there are bugs in all the trees!
[18:51:05] <cradek> but I think this is exciting - people will finally be able to use axis without jumping through flaming hoops
[18:51:40] <cradek> now I hope *we* don't have any important bugs left
[18:51:52] <paul_c> The next BDI build will use the cvs snapshot from the 16th
[18:53:09] <cradek> I will do some testing now
[18:53:19] <paul_c> made yet another (minor) change to setup.py so that a deb-packaging warning disappeared.
[18:53:43] <cradek> someone reported a problem with offset handling
[18:54:01] <cradek> ok, just send one of us a patch if you want it committed
[18:55:41] <cradek> unfortunately I can't test emc-bdi4 here, only emc1 and emc2
[18:59:24] <paul_c> Much of the user space & build system is identical to that of emc2
[18:59:43] <paul_c> despite JMK's claims to the contrary.
[19:00:07] <cradek> do you have sim on bdi now?
[19:00:41] <paul_c> nope.
[19:00:44] <cradek> (I have a new hard drive now and I may have room to install bdi soon)
[19:01:01] <cradek> (it sucks to not be able to effectively test)
[19:02:31] <cradek> well, I will try emc2 for now then
[19:05:36] <cradek> paul_c: which python version does axis use on bdi?
[19:05:46] <paul_c> 2.3
[19:06:12] <cradek> darn, I have 2.2 and 2.4
[19:06:14] <cradek> oh well
[19:06:40] <cradek> I will use 2.2
[19:06:52] <cradek> and the 20050916 snapshot
[19:07:34] <cradek> /home/chris/emc2/rtlib/motmod.o: unresolved symbol emcmotLogAdd
[19:07:34] <cradek> /home/chris/emc2/rtlib/motmod.o: unresolved symbol emcmotLogInit
[19:07:45] <cradek> is this a known problem (emc2 head)?
[19:07:46] <paul_c> patch sent.
[19:08:15] <paul_c> cd
[19:08:34] <cradek> got your patch
[19:11:50] <cradek> committed
[19:12:15] <CIA-8> 03paul_c * 10emc2/src/emc/motion/command.c: halscope makes emcmotlog redundant - ..
[19:12:59] <cradek> that got rid of one of my errors
[19:13:02] <cradek> /home/chris/emc2/rtlib/motmod.o: unresolved symbol emcmotLogAdd
[19:13:05] <cradek> still have this one
[19:15:09] <CIA-8> 03paul_c * 10emc2/src/emc/motion/command.c: Another ToDo for someone to take a look at - Are the emcmotlog functions still required ?
[19:15:19] <robin_sz> meep?
[19:16:14] <cradek> hello
[19:16:21] <robin_sz> hi ...
[19:16:45] <robin_sz> anytihng new or exciting happen today?
[19:17:04] <cradek> just the stuff on the mailing list
[19:17:11] <robin_sz> oh, I learnt how to spot-weld with a mig torch ...
[19:17:19] <cradek> jeff and I found (and pual fixed) an important bug in bdi
[19:17:24] <cradek> pual?
[19:17:29] <cradek> paul even
[19:17:36] <robin_sz> oh, I dont get the mailing list anymore, perhaps I should view the archive
[19:17:48] <paul_c> cradek: That's with a 'P'
[19:17:48] <robin_sz> the NaN bug?
[19:17:59] <cradek> robin_sz: yes
[19:18:16] <cradek> paul_c: according to my irc client, it's lowercase-p
[19:18:31] <paul_c> paul_c is now known as Paul_C
[19:19:04] <cradek> * cradek has to research how to type those big letters
[19:19:04] <robin_sz> cradek: I presume this was related to how undefined values being hung on an NML message?
[19:19:34] <cradek> robin_sz: nope, some rt code was porking up the fp stack
[19:19:47] <robin_sz> yeuw
[19:19:51] <Paul_C> had sodall to do with NML
[19:20:06] <robin_sz> that could have had alsorts of nasty consequences I guess
[19:20:15] <cradek> it did... all userland was affected
[19:20:21] <robin_sz> icky
[19:20:28] <cradek> showed up worst when using axis (lots of fp)
[19:20:32] <robin_sz> right
[19:20:42] <cradek> but at least one other person reported fp-heavy software crashing when emc was started
[19:20:57] <robin_sz> so it may improve stability of the whole thing then
[19:21:06] <cradek> and jeff's test program was an excellent way to show this behavior
[19:21:11] <cradek> yes, it's a very important fix
[19:21:23] <robin_sz> kewl. thats two important fixes this year then
[19:22:23] <robin_sz> the long-pursued trajectory planner bug being the other I guess
[19:24:09] <cradek> http://cvs.sourceforge.net/viewcvs.py/emc/emc/src/rs274ngc_new/rs274ngc_pre.cc?r1=1.10&r2=1.10.4.1&only_with_tag=cradek_stable
[19:24:10] <robin_sz> the next can of worms will be Les and his toolchanger .. where the little used EMC1 toolchanger code gets a thrashing ... shold be interesting, as JMK will be thrashing out the EMC2 toolchanger code around the same time on his Mazak refit
[19:24:25] <cradek> Paul_C: you have this change, right? I am trying to figure out how to put it in emc2
[19:25:35] <Paul_C> cradek: Yes. That will move in to emc2 HEAD on the next merge.
[19:26:00] <cradek> oh so I don't have to put it in there now?
[19:26:47] <Paul_C> nah - I also have a couple of other minor bug fixes in the interp to merge in to head.
[19:28:51] <cradek> ok, I'm hacking it in for the sake of testing, but I won't commit it
[19:29:16] <Paul_C> No you need the altered file ?
[19:29:27] <robin_sz> toolchange will be an interesting bit of the code, theres quite a lot of "stubs" there waiting to hang real code on
[19:29:39] <cradek> if you want me to test it, I will, but I hacked that change into mine already
[19:31:29] <cradek> darn, emc2 still has a bug with the offsets in the stat buffer not being updated
[19:31:34] <cradek> I bet bdi has this bug too
[19:31:47] <cradek> err, I bet emc-bdi4 has this bug too
[19:32:24] <cradek> it's not necessarily a show-stopper - when you load a file, it works right
[19:32:50] <robin_sz> in other news .. I got my forst little servo amp this week
[19:33:12] <Paul_C> cradek: Tool offsets ?
[19:33:20] <cradek> yeah
[19:33:23] <cradek> g10 l2 ...
[19:33:28] <robin_sz> seems to have more adjustments than I expected ...
[19:33:31] <cradek> axis uses these
[19:34:02] <Paul_C> tool offsets are read in by the tool module...
[19:34:16] <cradek> sorry, I'm talking about coord system offsets
[19:34:34] <Paul_C> Did the cradek_stable branch get a fix for that ?
[19:34:41] <cradek> no, it has always worked in emc1
[19:34:50] <cradek> can you test it for me in emc-bdi4
[19:35:03] <cradek> start emc with axis
[19:35:05] <cradek> machine on
[19:35:10] <cradek> jog over a bit in X
[19:35:17] <cradek> push "zero offset"
[19:35:54] <Paul_C> one sec.
[19:35:55] <cradek> you should see the axes move to the cone (relative origin), and a cyan origin symbol appears at the absolute origin
[19:36:44] <Paul_C> just need to apt-get axis.
[19:40:38] <cradek> Paul_C: jepler reports that he gets joint errors and following errors running 3D_Chips.ngc with the sherline ini on bdi
[19:42:18] <Paul_C> Sherline does not have "joints"
[19:43:01] <cradek> well, even with that in mind, jepler still reports he gets joint errors!
[19:43:16] <jepler> this is on the same bdi 4.25+updates machine by the way
[19:43:19] <cradek> unfortunately I can't try it here.
[19:44:37] <jepler> uh, how do I even load a file in mini?
[19:44:50] <jepler> (turning axis off in the config, even though that seems an unlikely cause of a following error)
[19:44:53] <cradek> try pushing those check boxes on the top
[19:46:12] <jepler> ./generic.run mill_mm_freq.ini
[19:46:16] <jepler> open 3d_chips and run
[19:46:29] <jepler> mini says "axis 0 following error"
[19:46:34] <cradek> is it just with the mm ini?
[19:46:39] <jepler> red bar points at line N80
[19:47:20] <jepler> I was using the inch setup before. I have axis in the inch .ini and mini in the mm .ini so I can easily switch between them
[19:48:43] <jepler> didn't get it that time on the inch config
[19:48:55] <jepler> just forget I said anything
[19:49:12] <cradek> ?
[19:49:21] <cradek> wonder if this is a case of the scale values being too small in mm mode
[19:49:52] <Paul_C> Oh FFS... PID is getting trashed.
[19:50:18] <cradek> Paul_C: what do you mean? in what case?
[19:51:06] <jepler> cradek: you put the fast run-from-line support in emc1/cradek_stable yet?
[19:51:08] <Paul_C> I'm getting several parameters on AXIS_0 being reset.
[19:51:31] <jepler> I just did a 'run from line' on 3D_Chips in axis on bdi and it was fast
[19:52:01] <cradek> Paul_C: ouch
[19:52:07] <cradek> jepler: I don't remember - I don't think so
[19:52:58] <jepler> well you should
[19:53:17] <cradek> can you point me to the right diff?
[19:54:15] <jepler> me? no.
[19:54:49] <cradek> heh
[19:55:17] <jepler> "my" axis does start with a somewhat larger window than the bdi one
[19:55:26] <cradek> so does mine
[19:55:42] <cradek> it's probably just the kde window manager or something
[19:56:10] <jepler> no, that can't be it -- I've been doing all this testing doing a remote display to a nice sane icewm-managed desktop
[19:56:44] <cradek> well paul said he's using last night's snapshot of axis for this next release
[19:56:48] <cradek> I built that snapshot and it's fine
[19:57:02] <cradek> the only problem I see with emc2/head and last night's axis is this offset thing when no file is loaded.
[19:58:15] <jepler> I don't see where we set a larger-than-minimum size for that window
[19:58:42] <cradek> huh
[19:58:48] <cradek> well I don't care too much - the toolbar does fit
[19:59:43] <jepler> ah, wait -- axis.nf has a 'wm minsize' line, and that seems to correspond to the geometry the window actually takes
[20:02:14] <cradek> ok, the offsets are written into the .var correctly, but the stat buffer isn't updated
[20:02:24] <jepler> right, that's what was happening with emc1+simulator
[20:02:38] <cradek> oh really? emc1?
[20:03:18] <jepler> yeah, what you're describing is what happens on my machine
[20:03:26] <cradek> well wtf
[20:03:51] <jepler> when I load a file, the buffer is updated
[20:04:00] <jepler> we could make axis load an empty file when it starts. ugh.
[20:04:06] <cradek> yep, same here
[20:09:28] <jepler> but that'll mess up things like the state of the 'run' and 'reload' buttons...
[20:09:43] <cradek> yeah, we really don't want that
[20:11:02] <cradek> other than stat being wrong, it does work right (mdi g0 and g0g53 do the right things)
[20:11:35] <cradek> I wonder if I can figure out how to use tkemc well enough to check this
[20:22:58] <cradek> when I mdi g10 l2 p1 x... in tkemc, displaying relative coords, it changes
[20:24:33] <cradek> it is using emcStatus->taks.origin.tran just like we are (emcsh.cc:2702)
[20:24:36] <cradek> task
[20:28:53] <cradek> oh god. to set an offset, tkemc writes out the var file and then tells the interpreter to read it.
[20:37:03] <jepler> ugh
[20:37:38] <cradek> worse, it does it with TASK_PLAN_INIT which "unloads" your file
[20:38:15] <cradek> sometimes the more I work on emc, the worse it smells
[20:39:36] <jepler> Can you change the offsets by instead MDI'ing a #nnnn=oooo ?
[20:40:00] <jepler> (not that I think that would be a good way to do it)
[20:40:04] <cradek> yeah, but that makes me ill
[20:40:09] <cradek> but only a little
[20:40:12] <cradek> I'll try it
[20:41:01] <jepler> http://www.linuxcnc.org/handbook/RS274NGC_3/RS274NGC_33a.html#1008243
[20:50:09] <cradek> no, that still works the same way
[20:53:18] <cradek> well, until someone (jmk?) can help me find the problem in the interpreter, this problem isn't going to get fixed
[20:53:42] <cradek> I refuse to set offsets the tkemc way - I think it sucks.
[20:55:56] <Paul_C> damit... My earlier fix will piss off JE again - It breaks his damned drivers.
[20:56:33] <cradek> Paul_C: if we were closer I'd say we should go get a drink.
[20:56:54] <Paul_C> You're out in the mid-west ?
[20:57:01] <cradek> yep
[20:57:13] <Paul_C> be there in, say... nine hours ?
[20:57:17] <cradek> ha
[20:57:22] <cradek> you're in the US today?
[20:57:48] <Paul_C> Still in England.
[20:57:57] <cradek> bring some Newcastle with you then
[20:58:25] <Paul_C> you can get that stuff from Wall Mart
[20:58:43] <cradek> ok then, bring plenty
[21:00:39] <Paul_C> Fursty Ferret be OK ?
[21:00:58] <cradek> no idea about that
[21:01:14] <cradek> bring whatever you like.
[21:01:17] <icee> are there any facilities in EMC to allow you to build external button panels easily?
[21:01:46] <icee> I'm designing a stepper control board now that I'd like to use with EMC, and would like to know what facilities there are internally so I can naturally integrate against that
[21:01:56] <cradek> icee: nothing's easy in emc.
[21:01:56] <Paul_C> You can use Tk, Python or Qt
[21:02:10] <icee> cradek: I kinda got that feeling ;)
[21:02:28] <cradek> icee: sorry, you probably caught me on a bad day.
[21:02:37] <cradek> icee: so I retract that statement
[21:02:58] <icee> you know tho, i want like start and stop and jog buttons without having to use the UI
[21:03:08] <icee> do you know of anyone who's done that before, or am I going to have to ghetto it up myself?
[21:03:10] <cradek> icee: the python emc interface module that axis uses is very clean and easy to use.
[21:03:35] <cradek> icee: what are the buttons? do they look like a keyboard to X?
[21:03:44] <cradek> icee: if so, it's a simple matter of key bindings
[21:03:50] <icee> hmm. I suppose I could make them look like a keyboard to X
[21:03:56] <icee> i could put a USB interface on my board
[21:04:42] <cradek> icee: jepler wrote a linux-joystick to python-emc-module program for jogging
[21:04:53] <cradek> icee: it all depends on your hardware
[21:05:10] <icee> cradek: do you know where that's available? I'd prefer to put the button presses back over RS-232, all being equal
[21:05:41] <icee> but I could make it look like a keyboard, if it's substantially easier to integrate
[21:05:45] <cradek> digging...
[21:06:04] <cradek> http://craie.unpy.net/aether/index.cgi/software/01119021973
[21:07:24] <icee> if self.s.task_state == emc.STATE_ESTOP:
[21:07:24] <icee> self.c.state(emc.STATE_ESTOP_RESET)
[21:07:24] <icee> else:
[21:07:24] <icee> self.c.state(emc.STATE_ESTOP)
[21:07:26] <cradek> usb is much better for nearly any new hardware design than rs232.
[21:07:27] <icee> neat! looks very easy
[21:07:30] <icee> thank you
[21:07:40] <cradek> yeah the interface is very easy to use
[21:07:58] <cradek> the only hairy part in this project is the joystick interface
[21:08:14] <icee> cradek: yah, but writing code to cause your USB thingy to enumerate as HID, and then marshall packets, etc, is substantially more of a pain than just shuffling characters over rs-232
[21:08:27] <cradek> oh, definitely
[21:08:49] <cradek> but, imagine all the whining from your users about not having a serial port available
[21:08:58] <icee> oh, this is purely for my own use
[21:09:06] <cradek> oh, forget it then
[21:09:15] <cradek> use serial!
[21:09:30] <icee> i may put the schematic, gerbers, and BOM up on the web, but otherwise..
[21:09:31] <cradek> I have a few old serial numpads around somewhere
[21:09:43] <cradek> it would be a simple matter of programming to use one of those.
[21:10:21] <icee> yah, just an infinite loop and dispatching EMC events
[21:10:35] <icee> i was hoping to find something like this
[21:10:48] <icee> thanks :) it'll make things really easy
[21:10:54] <cradek> welcome
[21:19:45] <Paul_C> cradek: Want to try and work through the offset prob then ?
[21:20:05] <cradek> Paul_C: I tried to find it, but failed
[21:20:22] <cradek> Paul_C: I would like to know if you have the problem on emc-bdi4 I guess
[21:20:27] <cradek> Paul_C: I bet you do
[21:20:48] <Paul_C> Let's start from the top - What var are you reading ?
[21:21:02] <cradek> none, I'm reading the stat buffer
[21:21:13] <cradek> and I change the offset with g10 l2 p1 or whatever it is
[21:21:41] <Paul_C> one sec while I build axis
[21:21:52] <cradek> in emc1, the stat buffer updates - in emc2, it updates but only if you have previously loaded a file
[21:29:03] <Paul_C> G10 L2 P1 X1 Y1 Z0
[21:29:06] <Paul_C> G54
[21:29:30] <cradek> yeah that should do it
[21:29:39] <cradek> but easier is to use shift-home (or push the "zero offset" button)
[21:29:40] <Paul_C> Origin jumps, and the display shows an offset applied
[21:29:48] <cradek> before you load a file?
[21:30:46] <cradek> do it with me: start emc, machine on, jog in some axis, hit shift-home
[21:30:48] <Paul_C> no file loaded.
[21:30:54] <cradek> origin should jump
[21:31:04] <cradek> maybe this is only an emc2 problem then
[21:31:13] <Paul_C> one sec - shutting down & reloading the var
[21:31:59] <Paul_C> f1, f2...
[21:32:09] <cradek> right arrow for a while
[21:32:17] <cradek> shift-home
[21:32:28] <cradek> does the origin move to the cone?
[21:32:38] <Paul_C> shift-Home....
[21:32:41] <Paul_C> zip.
[21:32:45] <cradek> now load a file
[21:32:52] <cradek> only then will it jump to the cone
[21:32:55] <cradek> that's the bug
[21:32:55] <Paul_C> zero offset - also zip.
[21:33:24] <cradek> the offset IS set
[21:33:34] <cradek> try g0x0 and g0g53x0 for instance
[21:33:40] <Paul_C> load a file, and offset is there...
[21:33:42] <cradek> it's just not reflected in the stat buffer, so the origin doesn't move
[21:33:51] <cradek> ok, right
[21:33:54] <cradek> so you have it too in emc-bdi4
[21:34:18] <cradek> now that a file is loaded, jog and shift-home
[21:34:22] <cradek> you will see the origin (and program) jump
[21:34:27] <cradek> this is how it's supposed to work
[21:37:29] <Paul_C> So status is only being updated with offsets once a file is loaded.
[21:37:34] <cradek> yes
[21:37:52] <cradek> HERE is another interesting point
[21:37:56] <cradek> emc1 sim DOES have this bug
[21:38:05] <cradek> emc1 non-sim does NOT (only version that works right)
[21:39:04] <Paul_C> what NML var are you reading for the offset ?
[21:40:05] <Paul_C> task->origin ?
[21:40:30] <cradek> yes
[21:42:01] <cradek> yeah status.task.origin.tran.[xyz]
[21:54:39] <Paul_C> what NML command do you have the zero button bound to ?
[21:54:57] <cradek> it sends that G10 L2 P1 command via MDI
[22:02:20] <Paul_C> the interp isn't processing the MDI line...
[22:03:35] <Paul_C> Hrmmm.... Back in five.
[22:05:19] <cradek> the offset DOES get set
[22:05:32] <cradek> after you set it, run g0x0 and g0g53x0 and you will see the offset works
[22:05:39] <cradek> I have to go for a while - be back in a few hours
[22:29:48] <anonimasu> hm
[22:30:22] <Paul_C> I see what the prob is, and where it needs fixing...
[23:23:14] <zwelch> emc hasn't given me any serious problems since i got it working for me; i mention this as I have been able to trivially segfault the latest version of Varkon
[23:25:03] <zwelch> (i.e. kudos to the EMC developers and maintainers ;) )
[23:31:43] <Paul_C> Don't worry - When EMC segfaults, boy, you know about it....
[23:31:55] <Paul_C> The system crashes out BIG time !
[23:32:08] <zwelch> heh, that's reassuring :)
[23:32:25] <zwelch> * zwelch just can't wait to get a mill to hook up to EMC after hearing that ;)
[23:32:27] <Paul_C> You ever seen a null pointer in kernel space ?
[23:32:32] <zwelch> yup
[23:32:37] <zwelch> * zwelch has contributed kernel code
[23:32:51] <zwelch> written a couple o' device drivers, etc.
[23:32:53] <Paul_C> It's not so bad with 2.6 kernels...
[23:33:03] <zwelch> it's still ugly ;)
[23:33:20] <zwelch> i.e. the effects are usually highly undesirable
[23:33:41] <Paul_C> with realtime, there's a bunch of other gotchas waiting to kick your butt
[23:34:21] <Paul_C> rt_task_create with zero period...
[23:36:32] <zwelch> * zwelch didn't want to install RT just to try EMC for that very reason
[23:36:59] <zwelch> i'll use dedicated boxen for RT systems
[23:40:24] <Paul_C> There is the BDI-Live disk if you just want to take EMC for a spin.
[23:41:08] <zwelch> is that the same as the BDI iso i've downloaded and burned?
[23:42:27] <zwelch> i was going to pop that in and look at it, but the only system i can afford for that at the moment is PPC ;)
[23:43:12] <Paul_C> EMC hasn't been compiled to run on ppc yet.
[23:43:27] <zwelch> i could port it, if there's any interest
[23:44:16] <anonimasu> :)
[23:44:32] <zwelch> as for my needs, i'll set up one of my spare x86 sometime this weekend
[23:44:56] <Paul_C> If there is an RT patch, it should be fairly trivial - There are no x86 specific code.
[23:45:03] <AchiestDragon> wonders if emc would complie for this
http://www.embeddedx86.com/epc/ts7200-spec-p.php
[23:45:28] <anonimasu> AchiestDragon: I think it's a bit slow
[23:46:03] <zwelch> Paul_C: is EMC being run on other big endian platforms than PPC?
[23:46:35] <Paul_C> 200MHz is faster than the original platforms EMC as compile for.
[23:47:15] <Paul_C> zwelch: I don't know of any non-x86 platforms running EMC
[23:47:16] <zwelch> the only concern there would be size constraints, which are irrelevant if you are willing to use something like a 1GB CF card :)
[23:47:42] <zwelch> (and of course, the issues of getting the ARM RT kernel bits working)
[23:47:49] <Paul_C> but the NML library is used on a number of other architectures.
[23:48:22] <Paul_C> AchiestDragon: You get me one of those boards, and I'll have a little play.
[23:48:23] <zwelch> does "the NML library" == "the NIST librcs"?
[23:48:40] <Paul_C> rcslib/libnml
[23:49:02] <AchiestDragon> was just thinking that i could build on of those into the controls then just feed it the gcode file by ethernet
[23:50:09] <Paul_C> I'd want a 16bit PC104 connector on there.
[23:50:41] <zwelch> it says it has a PC104 bus
[23:51:00] <Paul_C> 8bit standard, not 16bit
[23:51:03] <zwelch> ah
[23:51:12] <AchiestDragon> therea a onboard i/o port on there 20bits so should be able to wire the controls directly from that
[23:51:45] <zwelch> Paul_C: actually, the hardware says 8/16 bit
[23:51:49] <zwelch> erm... hardware page
[23:52:30] <jepler> this x86 (geode) board has a dozen TTL I/Os.
http://www.soekris.com/net4801.htm It's $213 qty 1 though
[23:52:57] <Paul_C> I've looked at those ARM boards in the past...
[23:53:06] <zwelch> there are a ton of options :)
[23:53:48] <Paul_C> cradek: Bug FIXED !
[23:57:13] <Paul_C> * Paul_C tests again just to be sure....
[23:58:12] <Paul_C> sodit.
[23:58:22] <AchiestDragon> almost finished my cnc
http://www.whipy.demon.co.uk/