Back
[00:00:54] <JymmmEMC> cradek: is the driver for the mesa board done?
[00:01:15] <cradek> JymmmEMC: the new modular one isn't, but the old one works like it always has
[00:01:34] <cradek> the big new feature will be step generation, which Adam won't care about anyway
[00:01:33] <JymmmEMC> cradek: which is how? (the old one I mean)
[00:01:58] <cradek> JymmmEMC: just great for servo systems
[00:02:02] <JymmmEMC> ah
[00:02:49] <ds2> cradek: I am thinking for small stuff like #10's... problem is the existing spindle can't instantenously reverse
[00:03:03] <cradek> ds2: it doesn't have to, no spindle can
[00:03:24] <ds2> then what's the requirements to be able to rigid tap?
[00:03:34] <cradek> it should reverse "pretty responsively" when switched from say +300rpm to -300rpm
[00:04:01] <skunkworks_> and the slower you tap - the faster it will reverse ;)
[00:04:07] <cradek> i.e. it should neatly slow and reverse within a few turns
[00:04:12] <cradek> exactly
[00:04:34] <cradek> some machines would have to go pretty slow I think.
[00:04:38] <ds2> so you are saying I can do it with the normal DC brushed motor + SCR based controller?
[00:04:39] <cradek> we used 300 on the mazak.
[00:04:44] <cradek> ds2: yes
[00:04:48] <ds2> Ohhhhhhhhhhhh
[00:05:05] <ds2> if that's the case, then all I need is an encoder
[00:05:09] <cradek> I understand any VFD can do it, but may need a braking resistor
[00:05:23] <cradek> yeah if you can command S300M3, then M4 and get a nice reversal, you're entirely set
[00:05:28] <ds2> this is just plain old DC (threadmill motor)
[00:05:32] <Adam> I found a bit of info on my servos... max 2400rpm, volts 140, pulse-amps 30
[00:06:16] <Adam> tacho 9.5volts / 1000rpm
[00:07:21] <ds2> cradek: is the encoding the same as for single point threading, 1 pulse per rev?
[00:08:16] <cradek> ds2: your question is not right. An encoder (or many pulses per rev) are needed for threading. An encoder is need for tapping because it reverses.
[00:08:30] <cradek> an index is required for both threading and tapping.
[00:08:52] <cradek> you should have at least low hundreds of pulses per rev so an encoder is the obvious way to get it.
[00:10:07] <ds2> did you drop a word or a typo in the first line?
[00:10:37] <cradek> 'An encoder is needED for tapping' is the only typo I see
[00:10:50] <cradek> ask another question if it's still unclear
[00:11:16] <ds2> my understanding so far is -
[00:11:31] <ds2> an index is required for both threading on lathe and rigid tapping
[00:11:38] <cradek> right.
[00:11:44] <ds2> what I don't get is what is the difference between an encoder and an index
[00:11:54] <cradek> 'an encoder with an index channel'
[00:12:03] <cradek> many encoders don't have index, only AB/quadrature
[00:12:34] <ds2> okay so for threading, only an index is need but for rigid tapping both index + encoder is needed?
[00:12:42] <cradek> no
[00:12:50] <cradek> for both, an encoder is needed
[00:13:05] <cradek> for both, an index channel is needed in the encoder
[00:13:56] <cradek> (it's strictly true that for threading, on a spindle that never reverses, you can get by with only one channel plus index, as long as you have many pulses per revolution)
[00:14:15] <cradek> for rigid tapping you certainly need an encoder - how else could you tell when it reverses?
[00:14:44] <ds2> I am thoroughly confused...
[00:14:59] <cradek> arg
[00:15:01] <ds2> let's go back to a reference point - the lathe
[00:15:10] <cradek> well they are different issues
[00:15:24] <ds2> okay
[00:15:29] <cradek> when cutting threads on a lathe the spindle does not reverse, so you don't need a signal that tells you about reversal.
[00:15:37] <ds2> okay
[00:15:48] <ds2> so is that why it does not need more then 1 pulse per rev?
[00:16:05] <cradek> ARRGH
[00:16:16] <cradek> one pulse per rev is not enough. You need hundreds.
[00:16:43] <cradek> sorry
[00:16:57] <cradek> you can not adequately follow the spindle orientation with one pulse per rev.
[00:17:22] <ds2> I am almost I found a reference that says otherwise... looking for the page right now
[00:17:28] <cradek> so drive that notion entirely out of your head!
[00:17:56] <cradek> emc has never done that. other controls do.
[00:18:17] <ds2> Okay
[00:18:43] <ds2> then how much angular resolution is needed?
[00:19:01] <cradek> the other controls will cut "drunken" threads if the spindle speed varies AT ALL during a threading pass. That's no good for emc.
[00:19:28] <cradek> I would not want less than one pulse per degree or so
[00:20:05] <ds2> okay, I think this actually clears it up for both tapping and threading... cuz I was under the impression it was done with a single pulse
[00:20:16] <cradek> ok
[00:20:34] <cradek> for tapping that's clearly impossible
[00:20:48] <cradek> for threading it's possible but it would require a lot of "faith" or tolerance for bad threads
[00:21:06] <ds2> I suppose for threading if your speed control is rigid enough....
[00:21:29] <cradek> yeah if you have a very heavy spindle and very light cuts, it might possibly work tolerably
[00:21:46] <ds2> I am guessing for tapping, the angular resolution required would depend on the pitch as any error translates into stress on the tap
[00:22:01] <cradek> yeah that seems true
[00:22:32] <cradek> on the mazak we tapped entirely rigid (in a jacobs chuck) and there seemed to be a little stress when backing out
[00:22:49] <cradek> a holder that gives a few thousandths would be nice
[00:22:54] <ds2> but what pitch and size thread?
[00:23:04] <cradek> the spindle encoder on the mazak is 360 ppr I think
[00:23:13] <ds2> I mean the tap
[00:23:18] <cradek> it was 3/8-16 I think??
[00:23:38] <cradek> but we successfully tapped (a lot) in Al
[00:23:47] <ds2> that's pretty course... I am thinking of stuff like 6-40, 10-32, etc
[00:23:48] <cradek> we made something like a tooling plate
[00:24:20] <cradek> you probably want plenty of resolution and low speed - if you play with it, let me know how it goes
[00:25:03] <ds2> got to think of a good way of encoding it
[00:25:16] <cradek> yeah it can be a challenge
[00:25:24] <ds2> I wonder if the 400line US digital encoders would tolerate 10KRPM
[00:25:31] <cradek> on my BP there's the top hole where the drawbar would have gone - I can just stick it there
[00:25:42] <cradek> extremely simple
[00:25:57] <cradek> good question. 10k is very fast for an encoder.
[00:26:05] <ds2> but the bridge port spindle isn't capable of going very fast... the spindle I am thinking of can do 10K
[00:26:19] <cradek> if you get the kit type (no bearing or contact) you'd be fine as long as the wheel doesn't fly apart
[00:26:20] <ds2> bearings assemble is good to like 12K on it
[00:26:34] <ds2> hmm
[02:50:12] <jmkasunich__> jmkasunich__ is now known as jmkasunich
[03:08:03] <Jymmm> jmkasunich: Did you say you have an IEEE account?
[03:08:38] <jmkasunich> no
[03:08:54] <Jymmm> jmkasunich: know anyone that does?
[03:09:26] <jmkasunich> not really
[03:09:51] <Jymmm> jmkasunich: ok, thanks
[03:25:51] <SWPadnos> I do
[03:26:58] <Jymmm> SWPadnos: yeah? can you grab a doc or does tht cost more?
[03:27:06] <SWPadnos> dunno
[03:27:36] <SWPadnos> I wonder if I have a login for online docs. I should have one somewhere
[03:45:14] <Skullworks-PGAB> just wow - Hot wire foam cutting -
http://www.youtube.com/watch?v=nVCS2JX-Dww
[04:07:40] <tomp> the hektor robot in ecmascript and svg. pix
http://imagebin.org/10017 svg
http://pastebin.ca/666449 html
http://pastebin.ca/666452 runs in opera9
[04:08:11] <tomp> i havent figgered how to capture the little vectors yet, maybe java can do file io from a browser
[04:08:54] <tomp> if the html doesnt load, load the svg, then reload the html
[04:10:17] <tomp> the segments should be able to go into halstreamer, getting quadratic beziers into emc
[04:43:02] <ds2> okay, I think I am ready to try moving heavier machinery
[05:07:26] <fenn> why does one need an index channel to do rigid tapping?
[05:33:33] <ds2> fenn: figure it and tell me
[05:35:49] <Jymmm> Damn that took forever !!!!
[07:57:11] <fenn> "that the strength of programmers' opinions is inversely proportional to the amount of data they have"
[07:59:30] <alex_joni> huh?
[08:01:29] <Jymmm> alex_joni: your ego is way too biug is what fenn is saying
[08:05:20] <alex_joni> no it ain't
[08:05:51] <Jymmm> lol, yeah it is
[08:05:59] <Jymmm> and you know it ;)
[08:06:06] <alex_joni> ha :P
[08:06:16] <alex_joni> well.. then I'll hide for a while
[08:06:24] <alex_joni> actually going to france for 2 weeks+
[08:06:43] <Jymmm> why hide, it's publically know you have a ego the size of the goodyear blimp
[08:06:50] <Jymmm> have fun!
[08:07:22] <Jymmm> alex_joni: dont do anything I wouldn't do, and if you do, name it after me =)
[08:07:32] <alex_joni> I'll be back on the 10th of sept
[08:07:41] <Jymmm> 9/11 huh
[08:08:11] <alex_joni> 9/10 :)
[08:08:20] <Jymmm> depends on TZ
[08:08:28] <Jymmm> 9/10 there, 9/11 here
[08:12:09] <fenn> it's always 9/11 somewhere
[09:09:40] <archivist> Jymmm, waddyameean slumming in #mysql, I run the bot in there
[09:10:22] <Jymmm> Uh huh
[09:24:53] <Jymmm> archivist: Okey, then your slumming in here ;)
[09:28:29] <archivist> maybe
[09:28:35] <Jymmm> =)
[12:12:30] <cradek_> cradek_ is now known as cradek
[12:41:30] <skunkworks__> * skunkworks__ doesn't have any new videos - sorry
[12:41:49] <maddash> porno?
[12:41:57] <jepler> good morning skunkworks__
[12:41:58] <skunkworks__> machine porn
[12:42:01] <jepler> you have a tail
[12:42:01] <skunkworks__> Good morning
[12:42:46] <skunkworks__> yah - got busy last night and left a few computers on. I almost got trunk installed but a hole in the wifes tire derailed that project
[12:43:50] <maddash> skunkworks__: trying to be pythonic?
[12:44:04] <skunkworks__> heh
[12:45:27] <fenn> __sukunkworks
[12:52:42] <skunkworks__> maddash:
http://www.youtube.com/watch?v=Hdhn_j6PrCw
[12:53:08] <skunkworks__> I am sure everyone is getting sick of me posting the same video :) tough
[12:54:39] <maddash> skunkworks__: show off.
[12:55:08] <maddash> skunkworks__: i hope you g64'ed, because all those line segments are bad for the steppers
[12:55:37] <skunkworks__> heh - do they blow up?
[12:55:56] <skunkworks__> should I be wearing safety glasses?
[12:59:11] <skunkworks__> and the last question - does that look like it is running exact stop mode?
[12:59:11] <skunkworks__> ;)
[12:59:33] <anonimasu> heh, im not sure..
[12:59:35] <anonimasu> depends on your accels ;)
[12:59:51] <anonimasu> exact stop mode goes zip zip zip with a fast machine :p
[13:00:28] <skunkworks__> the machine is set to 25in/s/s
[13:02:02] <skunkworks__> or 635mm/s/s - I think
[13:03:26] <skunkworks__> for you metric people.
[13:05:38] <skunkworks__> how do convert to metric seconds?
[13:06:29] <archivist> what metric seconds
[13:06:34] <skunkworks__> ;0
[13:06:59] <skunkworks__> * skunkworks__ is feeling a bit goofy this morning. sorry
[13:13:39] <fenn> "(why are they called axes in HAL and in the ini file and joints in the manual ?)" <- he's got a point, but its a bit late to fix that now
[13:17:27] <anonimasu> fenn: s/axes/joint
[13:17:29] <anonimasu> :D
[13:17:34] <anonimasu> easy stuff ;)
[13:18:51] <cradek> fenn: for "peck tapping"
[13:21:24] <anonimasu> :)
[13:23:06] <fenn> cradek: i still dont really see the need.. it's not like you have to worry about counters overflowing or anything
[13:26:02] <cradek> actually a spindle can overflow pretty easily. but you're right it would be possible to do without index.
[13:26:37] <fenn> during the tapping operation
[13:27:36] <cradek> if it can overflow, it can overflow during tapping, you just have to be unlucky
[13:27:36] <jepler> counters overflow at 2^31 counts (signed 32-bit int), and resolution starts to be lost at 2^24 counts (float)
[13:28:35] <jepler> if the basic types of HAL were 64 bits I wouldn't worry about it
[13:28:38] <fenn> for a 32 bit int, a spindle with an 8000 line encoder at 6000 rpm will take 5000 years to overflow?
[13:28:40] <jepler> but unfortunately they're not
[13:29:25] <fenn> units '2^31/(6000/min*8000)' years
[13:29:58] <jepler> units '2^31/(8000*6000/min)'
[13:29:59] <jepler> Definition: 2684.3546 s
[13:30:03] <fenn> ah pesky order of operations
[13:30:04] <jepler> units '2^24/(8000*6000/min)'
[13:30:04] <jepler> Definition: 20.97152 s
[13:30:09] <SWPadnos> 2^31 ~= 2 billion. a 4000 count encoder at 500 RPM gives 2 million counts/minute, so only ~1000 minutes are needed for overflow
[13:30:32] <jepler> units does a/b*c differently from most programs you're familiar with ..
[13:30:57] <jepler> confusingly, 2/3/4 and 2/3*4 are the same in units ....
[13:31:01] <SWPadnos> if you were turning a long screw, you could easily have a program that lasts 16 hours
[13:31:43] <fenn> ok, so, it's not "required" but "suggested"
[13:31:45] <cradek> a much worse case is run at 10krpm for a while, then slow down to thread
[13:31:53] <cradek> fenn: the current implementation requires it.
[13:32:02] <SWPadnos> that's the "unwinding"" problem?
[13:32:20] <cradek> SWPadnos: ?
[13:32:40] <fenn> how about a "spindle position reset" signal from emc?
[13:32:42] <SWPadnos> err - I think I'm missing a piece of the puzzle for this conversation :)
[13:32:51] <SWPadnos> nevermind - gotta get to a meeting anyway
[13:32:56] <fenn> M9999
[13:33:01] <cradek> bah
[13:33:03] <fenn> i guess you could do that with halcmd
[13:33:09] <cradek> why make it more complicated than it needs to be?
[13:33:15] <jepler> if the internal types were signed 64-bit int and double, you'd get 356 years of 6000RPM before loss of precision, and 365ky before overflow
[13:33:35] <fenn> encoders without index are a lot more common around these parts
[13:34:10] <fenn> jepler what do you mean "loss of precision"?
[13:34:27] <fenn> is spindle position not an int?
[13:51:44] <alex_joni> it should be a double, not an int
[13:52:13] <jepler> spindle position is a hal "float"
[13:56:37] <jepler> for scale=8000, 16777216 and 16777217 counts convert to the same position. In C syntax, (float)(16777216/8000.) == (float)(16777217/8000.)
[13:57:54] <jepler> float was used instead of double because storing and loading double-precision numbers (64 bits) is done by nonatomic instruction sequences in at least some cases, but access to HAL types must always be atomic
[13:58:28] <lerman> Can semaphores be used within HAL?
[14:02:12] <jepler> rtapi includes semaphores (rtapi_sem_*)
[14:02:35] <jepler> they are not actually used in HAL
[14:04:00] <alex_joni> HAL only uses mutex'es from rtapi
[14:05:08] <lerman> So access to non-atomic variables could be controlled by mutex'es.
[14:05:14] <jepler> it would be a big change in HAL to make access to pin data require a mutex. If 'p' is a HAL pin then '*p' reads the pin and '*p=x' writes the pin (in "C"; comp dispenses with the "*")
[14:06:42] <jepler> you would also have to change the thread priority model: right now, the priority is simple: the fastest thread has priority. But if you use mutexes to control access to values in HAL, you have to let a slow thread preempt a fast one when it holds a mutex for some value to be read in the fast thread.
[14:07:08] <alex_joni> lerman: what's the goal?
[14:07:30] <lerman> To permit the use of doubles or long longs in HAL.
[14:07:31] <jepler> easier to wait for rtai or another realtime kernel to become stable on 64-bit machines; then 64 bit primitive types can become default without any changes to source code
[14:08:34] <alex_joni> bbl
[14:18:59] <cradek> Also, you can make pretty serviceable plastic nuts with a tap and some cutting boards.
[14:19:03] <cradek> ^^ what a great idea
[14:19:14] <fenn> * fenn hopes thats not sarcasm
[14:19:40] <cradek> no I'm serious, that's a good source for ... stock
[14:20:00] <fenn> yeah i used to use them before i discovered a plastic supplier's dumpster
[14:20:22] <fenn> now i've got more HDPE than i know what to do with
[14:20:46] <cradek> could be worse.
[14:20:53] <cradek> (wish I could fine Al that way)
[14:21:41] <jepler> find?
[14:21:48] <cradek> find.
[14:22:39] <fenn> i think emc.so is pretty much what i was talking about for "python bindings"
[14:23:18] <cradek> yeah, people keep insisting that we should have things we already have
[14:23:41] <cradek> loving/hating gcode is the other common thread
[14:23:48] <cradek> (I also love/hate gcode fwiw)
[14:23:53] <fenn> the /lib dir is always confusing
[14:24:07] <jepler> How do you identify the "live" connector on AC inlets that look like "A" on this page?
http://www.mouser.com/catalog/631/943.pdf
[14:24:10] <fenn> i'm usually grepping in src/ and i'm like "wtf i know its here somewhere"
[14:24:21] <jepler> (on the back / terminal side)
[14:24:42] <cradek> I always check how a power cable is wired
[14:25:00] <cradek> (the small prong on the outlet is the hot one)
[14:25:44] <fenn> use a meter on one of the cords, test for continuity between the plug and the other plug
[14:26:21] <fenn> i guess that's what cradek said
[14:26:48] <fenn> the other interpretation is "always check how a power cable is wired cause it might kill you if you're wrong"
[14:34:11] <cradek> power doesn't kill us here in low-volt land.
[14:34:48] <cradek> when it bites us, it just makes us mad
[14:36:14] <fenn> we should all switch to 10KV 10KHz AC immediately!
[14:36:58] <jepler> The router will ship today. I am sorry for the delay. I usually ship the next day, or at the latest,2-3 days after order, but I ran into some unforseen delays. I am going to send you some motor cables with the router. Thank you for your patience.
[14:37:25] <jepler> </email> well at least he wrote me back promptly after I asked him about it
[14:42:04] <anonimasu> hm
[14:42:13] <anonimasu> have anyone seen the limit of the new tp?
[14:43:36] <anonimasu> http://www.youtube.com/watch?v=Wr5GywChdd4&mode=related&search=
[14:43:36] <anonimasu> wtf
[14:43:38] <anonimasu> high speed milling
[14:44:37] <cradek> that doesn't look high speed to me
[14:44:38] <jepler> internet news flash: some videos on youtube may be boring or pointless
[14:44:41] <cradek> pretty lethargic actually
[14:45:22] <anonimasu> yeah
[14:45:24] <anonimasu> that was the point..
[14:45:34] <anonimasu> I watched a sodick machine..
[14:46:02] <anonimasu> zip zip zip
[14:46:47] <jepler> is it actually making any chips?
http://www.youtube.com/watch?v=matwPj6DKY4&mode=related&search=
[14:47:20] <anonimasu> it makes dust..
[14:47:22] <anonimasu> http://www.youtube.com/watch?v=JsWVTQy2rYg&mode=related&search=
[14:48:19] <cradek> air for coolant and chip clearing I think
[14:48:53] <anonimasu> yep
[14:49:07] <jepler> video title: "DATRON High speed milling machines" Related video title: "I pimped my dog" -- wtf?
[14:49:27] <anonimasu> http://www.youtube.com/watch?v=h5w3yGcEevw&mode=related&search=
[14:49:33] <anonimasu> there they actually make chips
[14:50:16] <skunkworks__> the speed that the penguin ran was as fast as it would go.. I think. for me
[14:50:29] <anonimasu> 600ipm
[14:50:56] <skunkworks__> with the constraint I had
[14:53:21] <anonimasu> http://www.youtube.com/watch?v=ITeRJCkMQ90
[14:53:24] <anonimasu> ^_^
[14:53:25] <anonimasu> nice
[14:53:26] <anonimasu> bbl
[14:54:00] <skunkworks__> I have not tried the g64 pX.XXX yet to see how much I can speed it up.
[15:12:13] <cradek> http://www.youtube.com/watch?v=nibzhPfOF1Q&NR=1
[15:12:22] <cradek> ^^ another emc2 spotting
[15:13:38] <cradek> wow he has his acceleration set low. I wonder if the machine really needs it that low
[15:17:02] <skunkworks__> Nice. Looks like a stout little mill.
[15:19:50] <cradek> I wonder what that part is. It looks like a marble holder
[15:21:20] <skunkworks__> no clue. He doesn't mention emc though - shame on him :)
[15:21:48] <cradek> that looks like a very big mill for steppers.
[15:22:04] <cradek> although it seems to work OK.
[15:24:01] <cradek> wow, not a good hole milling algorithm:
http://www.youtube.com/watch?v=uiyzDZhcqP8&mode=related&search=
[15:28:18] <cradek> I think people think end mills are drill bits. They'll plunge without thinking twice, but are afraid to cut much of anything with the side
[15:29:08] <cradek> looks like he could have done this in about three cuts if he'd use helixes instead of plunging
[15:30:32] <skunkworks__> depends on the mill - some are center cutting - but you still want to be carful with speed. S
[15:30:49] <cradek> sure, but even center cutting end mills don't plunge well
[15:30:56] <cradek> they only barely work
[15:31:30] <skunkworks__> well is reletive I guess. We have done it a lot. maybe it depends on the size of the machine. ;) try it on your bridgport now.
[15:31:31] <jepler> cradek: so you prefer a helical plunge to the maximum diameter, then a single spiral in to the middle?
[15:32:20] <cradek> true maybe I'm overly gentle with plunging.
[15:33:00] <cradek> jepler: for that hole I'd rough it without plunging (not quite full diameter) and then do a finishing pass around the outside
[15:33:13] <archivist> needs a solid machine, a plunge here on the old stuff vibrates a "little"
[15:50:25] <fenn> that is awallin's
[15:50:49] <fenn> hrm scrollback.. yeah.
[15:52:39] <fenn> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Videos
[15:57:49] <skunkworks__> hmm - I should probably add some links
[17:44:59] <Adam0> Hello
[17:45:15] <MichelG> Hello
[17:46:15] <skunkworks__> hello
[17:48:41] <MichelG> Is there a way to start an interactive emcsh from *another* xterm when emc2 is already running?
[18:00:17] <jepler> MichelG: yes -- give me a second to do it myself so I can give you the right directions
[18:01:35] <jepler> MichelG: in the shell, change to the same directory where your .ini file is
[18:01:43] <jepler> MichelG: then run it this way: emcsh -ini yourinifile.ini
[18:01:54] <MichelG> jepler:Thanks, I am trying to do that for a couple of hours without success.
[18:02:06] <jepler> MichelG: do you get an error message?
[18:03:44] <MichelG> jepler: I am doing that with inifile sherline-mm.ini, but I get libnml/cms/cms_cfg.cc 624: cms_config: can't open 'emc.nml'. Error = 2 -- No such file or directory
[18:03:44] <MichelG> libnml/nml/nml.cc 369: NML: cms_config returned -1.
[18:03:44] <MichelG> **********************************************************
[18:03:44] <MichelG> * BufferName = emcStatus
[18:03:44] <MichelG> * ProcessName = xemc
[18:03:44] <jepler> % emcsh -ini axis.ini
[18:03:44] <jepler> % emc_joint_homed 1
[18:03:44] <jepler> not
[18:03:44] <MichelG> * Config File = emc.nml
[18:03:46] <MichelG> * error_type = 0 (NML_NO_ERROR)
[18:04:45] <jepler> MichelG: are you sure you changed to the right directory and gave the right argument after "-ini"?
[18:06:08] <jepler> MichelG: I can get exactly that error *if* I am in the wrong directory or I give the wrong name for the inifile
[18:06:42] <MichelG> jepler: I am in emc2/bin, my command is: ./emcsh -- -ini ../configs/stepper-xyza/sherline_mm.ini
[18:07:22] <jepler> MichelG: change to the same directory where your .ini file is
[18:07:23] <MichelG> It is correctly loaded by emcsh, but trynml() gives an error
[18:07:27] <jepler> MichelG: then run it this way: emcsh -ini yourinifile.ini
[18:07:38] <jepler> the first step (change to the directory where your ini file is) is important
[18:07:57] <jepler> you may need to give a path to emcsh in this case .. e.g. ../../bin/emcsh -ini sherline_mm.ini
[18:09:11] <MichelG> jeppler: OK, that was the trick; THANKS!
[18:10:25] <jepler> MichelG: good, and you're welcome
[18:13:39] <jepler> MichelG: if you run into questions about python's 'emc' or 'hal' modules, feel free to ask them here too
[18:15:28] <MichelG> jeppler: thanks, I am experimenting for creating "druids" ...
[18:18:14] <skunkworks__> jepler: the only think I would say would be nice in your image to gcode is actual size of the output. So you don't have to do the math. ;)
[18:18:42] <jepler> skunkworks__: indeed
[18:18:49] <jepler> skunkworks__: I agree
[18:18:53] <jepler> (the only thing ?!)
[18:19:09] <skunkworks__> * skunkworks__ has only used it for a little bit so far..
[18:19:41] <skunkworks__> i should have added 'so far' ;)
[18:21:11] <jepler> skunkworks__: did you cut something from it yet, or just look at the gcode?
[18:21:35] <skunkworks__> just looked at the gcode - hopefully there will be another video tonight :)
[18:22:12] <skunkworks__> I know your excited
[18:22:47] <skunkworks__> it looks like arcs now also ;)
[18:23:16] <jepler> did you find a good image to work from?
[18:26:07] <skunkworks__> not really - do you have some that you would think would work good?
[18:26:24] <jepler> there's the torus which is in nc_files
[18:26:40] <skunkworks__> yes - I have actually dry run that one also.
[18:26:41] <jepler> it's not too interesting though
[18:26:46] <skunkworks__> in the installed version
[18:27:32] <skunkworks__> I am converting one of my car right now for the heck of it - but the computer here at work is a 500mhz celeron and it is running really slow
[18:27:44] <jepler> image-to-gcode is pretty inefficient / slow
[18:27:51] <jepler> here's another image I ran into on the internet:
http://emergent.unpy.net/index.cgi-files/sandbox/SampleDepthMap.gif
[18:28:30] <skunkworks__> oh - that is cool.
[18:28:59] <skunkworks__> thank you
[18:29:17] <skunkworks__> I thought a nice lithograph would be a good selling point
[18:29:19] <skunkworks__> also
[18:29:29] <skunkworks__> if it cuts it decent
[18:30:32] <skunkworks__> I looked at the bits I have - and the ends are differnt metal than the shafts.. They may be carbide. That would help with the circuit board demo.
[18:30:42] <skunkworks__> I was going to check them with a maganet tonight
[18:35:39] <jepler> skunkworks__: good news -- I have a tracking number for my cnc router
[18:35:57] <skunkworks__> Great
[18:36:05] <cradek> whee
[18:36:20] <jepler> " In FedEx possession " it says when I track it
[18:36:29] <jepler> in CA
[18:44:59] <skunkworks__> does it give an estimated delivery date?
[18:45:03] <skunkworks__> yet
[18:45:31] <jepler> nope
[18:55:33] <skunkworks__> Well - I hope you get it before the weekend.
[18:56:47] <jepler> that would be nice but I doubt it
[18:59:01] <skunkworks__> they normally deliver on saturday also (fedex) atleast they do around here.
[18:59:10] <cradek> just go get some cutting boards and we'll throw one together
[18:59:19] <skunkworks__> heh
[19:03:33] <skunkworks__> it takes a good 15 to 30 minutes to convert a image on this computer. :) painful (using mostly default settings - no roughing passes)
[19:03:47] <cradek> youch.
[19:04:05] <skunkworks__> the mouse moves every second or so.. I thing something may be horribly wrong ;)
[19:04:57] <skunkworks__> think
[19:05:13] <cradek> swapping maybe
[19:05:38] <skunkworks__> 256mb memory
[19:06:31] <jepler> how big's the image?
[19:06:52] <jepler> if the mouse is moving erratically that usually indicates inadequate RAM
[19:08:00] <skunkworks__> it get rt error instanly when emc starts. - this is the same model computer I use at home except it is a 500 celeron vs 1ghz pentium III.
[19:08:46] <jepler> could be BASE_PERIOD too low
[19:08:49] <skunkworks__> the torus takes a long time also
[19:09:03] <skunkworks__> it is the default 50us
[19:10:57] <CIA-24> 03cradek 07TRUNK * 10emc2/src/emc/motion/control.c: fix jog wheel velocity mode's interaction with feed scaling
[19:32:41] <Adam0> Does anyone know if anilam 5volt glass scales are compatible with the Mesa 7i33?
[19:33:14] <cradek> what's their output?
[19:34:03] <Adam0> i have no idea I cant find any info on them
[19:34:39] <cradek> you may have to get out the 'scope then
[19:37:28] <Adam0> well I believe that they output "Square-wave voltage signals, channels A and B, in 90° quadrature relationship"
[19:38:00] <jepler> if the signals are single-ended TTL compatible they are very likely to work with mesa.
[19:38:07] <cradek> or differential
[19:38:16] <Adam0> or they are "differential sinusoidal current or voltage output"
[19:38:27] <cradek> hmm, not so good then
[19:38:44] <cradek> with a scope you should easily be able to tell if they are sinusoidal or square
[19:38:45] <Adam0> I am not sure if they output digital or analog though
[19:38:59] <cradek> we're not going to know better than you are :-)
[19:39:11] <Adam0> yeah
[19:39:31] <Adam0> so were are good with square and not good with sinusoidal?
[19:39:43] <cradek> yes
[19:40:01] <alex_joni> actually you're way better with any of them vs. some digital serial protocol
[19:40:07] <cradek> true.
[19:40:12] <alex_joni> like on heidenhain
[19:40:18] <cradek> but if they're the only positional feedback, they won't be that will they?
[19:40:27] <cradek> heidy-hoo
[19:40:42] <jepler> with sinusoidal, you could add an analog comparator per signal to convert into a clean digital signal -- but this sacrifices resolution
[19:40:45] <alex_joni> the glass scales I've seen are absolute encoders basicly
[19:41:01] <alex_joni> and they transmit some packages with the absolute position
[19:41:08] <jepler> something designed to read a sinusoidal signal would get many different "position levels" during one rotation of the signal, while converting it into a square wave with a comparator will give you only 4 levels
[19:41:10] <alex_joni> and all other kind of strange stuff
[19:41:32] <alex_joni> jepler: maybe a resolver to quadrature converter might help there
[19:41:47] <Adam0> basically what I have right now is an old anilam crusader M with glass scales,and SEM servos with tacho's. I am just trying to figure out the hardware I need to purchase to convert.
[19:41:58] <alex_joni> the one I've seen are 1024 counts / sinusoide
[19:45:35] <skunkworks__> I would think glass scales would be digital.. but what do I know. ;)
[19:46:27] <alex_joni> I think they actually work with some magnetics on the glass
[19:47:01] <cradek> first record a sine wave on an 8-track tape, pry it open, stretch the tape out, hot-glue the tape head to the axis
[19:47:29] <alex_joni> feed the output into the line-in
[19:49:46] <Adam0> they are square wave ttl quadrature output afterall
[19:49:52] <jepler> that's really an interesting idea -- DS floppy disk as high resolution magnetic encoder
[19:50:10] <cradek> with index! (the hole)
[19:50:12] <jepler> phase A on the top, phase B on the bottom, and the index hole for index
[19:50:16] <archivist> hmm I like those ideas
[19:50:20] <cradek> oh I guess it was obvious.
[19:50:30] <jepler> did the 3.5" disk have an index hole?
[19:50:45] <cradek> I think it oriented one way
[19:50:57] <jepler> oh that's right, there's a notch thing in the center metal disk
[19:51:01] <cradek> yeah
[19:51:11] <archivist> can floppies handle the workload
[19:54:10] <jepler> 15 sector/track * 512 bytes per sector * 8 bits per byte / 2 bits per cycle = 30720 cycles per revolution (5.25 "HD" disk)
[19:54:11] <alex_joni> no, you'll probably have to change your encoder once per week
[19:55:49] <Adam0> anbody have any ideas on how to switch a bridgeport style induction spindle motor to a DC motor, and have it controlled with EMC? I will be getting the Mesa 5i20 and 7i33 and breakouts.
[19:56:23] <cradek> just run it with a VFD. if the VFD has +-10 input for speed control, wire it up to a spare 7i33 output
[19:56:32] <skunkworks__> Adam0: is it 3phase?
[19:57:04] <Adam0> yeah it is a 3 phase
[19:57:11] <cradek> what hp?
[19:57:14] <Adam0> 2hp
[19:57:25] <Adam0> 6amp
[19:57:49] <skunkworks__> vfd would be the way to go.
[19:58:14] <Adam0> ok what extra hardware do I need?
[19:58:24] <cradek> http://web6.automationdirect.com/adc/Shopping/Catalog/AC_Drives_-z-_Motors/GS1_(120_-z-_230_VAC_V-z-Hz_Control)
[19:58:54] <Adam0> right now the spindle is on a 3phase converter because I have no 3-phase in the shop
[19:59:24] <cradek> for 2hp you can get a single-phase 230v input vfd
[20:00:12] <cradek> http://web1.automationdirect.com/adc/Shopping/Catalog/AC_Drives_-z-_Motors/GS2_(115_-z-_230_-z-_460_-z-_575_VAC_V-z-Hz_Control)/GS2-22P0
[20:01:13] <cradek> the DC bus transformer will probably be 3 phase too, so this isn't the only work you have to do for single phase conversion
[20:02:58] <awallin> alex_joni: you around?
[20:03:32] <alex_joni> yup
[20:04:19] <Adam0> what do you mean by that cradek? I am not that good with the electronics side of things.
[20:04:30] <cradek> these look pretty nice. configurable IO like "at speed" output
[20:04:57] <cradek> Adam0: you can run the spindle motor, using a VFD like the second link I posted, using single phase power. But I bet other parts of the mill currently require 3 phase too.
[20:05:19] <cradek> but I'm just guessing of course.
[20:06:53] <awallin> alex_joni: I remembered your astro-photo from a few weeks back. I'm thinking about building or getting a tracking mount.
[20:07:36] <alex_joni> nice
[20:07:37] <Adam0> cradek the spindle 3 phase is on a different 3 phase system.
[20:07:56] <cradek> oh ok, then it's easy
[20:08:06] <cradek> you can run it with a vfd and emc can control it directly
[20:08:24] <awallin> alex_joni: how long was the exposure for the star-trails pic?
[20:08:46] <Adam0> cradek the vfd is wired to the 7i33 then?
[20:09:08] <cradek> yes the vfd has, among other inputs/outputs, a 0-10v analog input that can be used to set the speed
[20:09:28] <Adam0> ok well that makes the spindle mod easy
[20:11:22] <alex_joni> awallin: about 45 minutes iirc
[20:12:51] <fenn> wow 10 lathes on the poll
[20:13:05] <fenn> at this rate lathes might surpass "nothing"
[20:14:10] <alex_joni> heh
[20:17:32] <fenn> cradek: by "gcode works so
[20:17:51] <fenn> differently for different machine configurations" i think you mean "gcode is utter shite and has to be hacked to work properly in every instance"
[20:18:16] <cradek> well, I don't really want to talk about that
[20:18:50] <fenn> so, got any better ideas for how to do UVW in a universal sense?
[20:19:18] <cradek> it's not a problem of UVW, it's a problem of gcode dialects in general
[20:19:27] <SWPadnos> there is no universal sense for anything beyond XYZ, and there may not be for XYZ either
[20:19:47] <SWPadnos> at least, not for the machine controller
[20:19:55] <fenn> i'm sorta frumpity about W being ambiguous (could be yaw too)
[20:20:12] <cradek> everyone agrees on G0,G1 X,Y,Z. *anything* else is more or less variable.
[20:20:26] <SWPadnos> it's possible to decide that XYZABC means TOV, but there's no universal mapping of that to machine joints
[20:20:40] <fenn> T O V?
[20:20:43] <SWPadnos> (TOV=tool orientation vector)
[20:20:53] <SWPadnos> or is it tooltip orientation vector?
[20:21:02] <fenn> hm
[20:21:19] <fenn> rotary axes are not commutative anyway
[20:21:25] <SWPadnos> even XYZ is somewhat subject to debate, when you throw in lathes and front/back cutting
[20:22:05] <fenn> i think a right hand coordinate system is pretty standard, and Z parallel to the spindle
[20:22:13] <fenn> so lathes should all be the same?
[20:22:20] <SWPadnos> unless your cutter is on the back side of the stock
[20:22:24] <fenn> so?
[20:22:29] <cradek> what spindle?
[20:22:30] <cradek> which spindle?
[20:22:38] <fenn> the main spindle
[20:23:02] <cradek> and on a foam cutter?
[20:23:04] <fenn> if there's no main spindle it's not really a lathe is it
[20:23:11] <cradek> there are no (or barely any) universals
[20:23:18] <SWPadnos> is it that way on a lathe? (X=diameter/radius, Z=distance from chuck)
[20:23:23] <cradek> SWPadnos: yes
[20:23:30] <SWPadnos> ok - I keep forgetting that
[20:23:42] <fenn> well foam cutter would be XY because Z is generally considered depth
[20:23:42] <SWPadnos> maybe I should get a lathe and not retrofit it for a few years, like my mill :)
[20:24:07] <cradek> the guy I bought my mill from had a nice turning/milling center for sale too
[20:24:09] <fenn> SWPadnos: sounds like a plan
[20:24:13] <cradek> it was a little bigger.
[20:24:14] <fenn> get a cnc lathe though
[20:24:34] <cradek> cnc lathes are so much nicer than manual lathes.
[20:24:40] <SWPadnos> well, there's a nice one for sale here, I think. I just haven't been able to get the folks to sell it to me (though I haven't tried all that hard)
[20:24:56] <fenn> the extra 30-50 years of development since wwII helps a bit
[20:25:22] <cradek> it must not be very "for sale" then
[20:26:09] <SWPadnos> well, it's for sale, but I haven't pushed much to get them to sell it to me. they're still using it AFAIK
[20:26:38] <SWPadnos> I also had a typo/thinko in the last email I sent - I asked about a CHNC, and the unit I had looked at was an HNC
[20:26:55] <SWPadnos> but little did I know they also had some CHNCs for sale ...
[20:27:08] <SWPadnos> (= later, more expensive unit)
[20:34:05] <fenn> re: the floppy disk/tape idea, you could have a pseudorandom code to give absolute position
[20:36:05] <archivist> gray code
[20:37:03] <fenn> yeah you could have lots of channels on a floppy
[20:37:20] <fenn> i was thinking more for the tape, where you'd only have like 2 or 4 tracks
[20:37:36] <archivist> need the heads to read them though
[20:37:48] <fenn> 2 is plenty then
[20:38:55] <SWPadnos> I'm not sure a floppy read head could handle that - I think it needs rapid magnetic transitions, so slowing it down (liek an encoder) may not let the head detect any bit transitions
[20:38:57] <skunkworks__> all you need is some of these
http://www.electronicsam.com/images/KandT/conversion/accupins.JPG
[20:39:04] <archivist> but then there is modding a hard disk.....
[20:39:13] <fenn> swp slowing it down?
[20:39:45] <fenn> archivist: your hard disk is nothing compared to my holographic versatile disk!
[20:39:46] <SWPadnos> well, with encoders, you want to see how far something has moved, so you run the thing at some rate other than the 300 RPM of a floppy drive
[20:39:55] <SWPadnos> (or whatver a floppy runs at)
[20:40:01] <archivist> yes could not read the magnetic at slow/zero speed
[20:40:37] <archivist> soooo burn special cds
[20:40:48] <fenn> have you seen dvd-ram?
[20:40:54] <SWPadnos> also, the clock rate is probably somewhat fixed - trying to get data at any other rate might be difficult
[20:40:55] <archivist> no
[20:41:57] <fenn> bah now i cant find a decent picture
[20:42:35] <fenn> anyway, it has built-in sector markers
[20:42:50] <alex_joni> fenn: so does lightscribe DVD's
[20:43:01] <fenn> that's also a good idea
[20:43:12] <fenn> lightscribe gray code
[20:43:30] <alex_joni> http://dsplabs.cs.utt.ro/~juve/dropbox/lightscribe/IMG_9642.JPG
[20:43:32] <archivist> CD might object to sitting on a 30k rpm spindle
[20:43:37] <alex_joni> not quite
[20:43:47] <fenn> 52x is pretty fast
[20:43:54] <alex_joni> yeah, close to 10k or such
[20:44:02] <SWPadnos> 1x=300 RPM
[20:44:06] <fenn> 27.5krpm says google
[20:44:21] <fenn> or, 10krpm
[20:44:31] <fenn> i'd bet on the 10k
[20:44:34] <alex_joni> 1x = 200 rpm
[20:44:41] <SWPadnos> I'm pretty sure CDs are 300 RPM
[20:44:54] <alex_joni> http://hypertextbook.com/facts/2000/LawrenceFung.shtml
[20:45:28] <CIA-24> 03jepler 07TRUNK * 10emc2/src/hal/utils/comp.g:
[20:45:28] <CIA-24> 'modparam' declaration allows the documentation for the module parameter to be
[20:45:28] <CIA-24> automatically integrated in the generated manual page. 'modparam int' actually
[20:45:28] <CIA-24> generates the declaration, while 'modparam dummy' just inserts documentation.
[20:45:50] <fenn> swp maybe on those fancy 66khz lp's
[20:45:53] <alex_joni> any last feature requests for emc2?
[20:45:54] <CIA-24> 03jepler 07TRUNK * 10emc2/src/hal/drivers/pluto_servo.comp: use new 'modparam' to improve documentation
[20:46:05] <SWPadnos> it depends on whether it's CAV or CLV, I guess
[20:46:07] <alex_joni> * alex_joni goes away for 2 weeks with a laptop :)
[20:46:13] <jepler> alex_joni: have a good trip
[20:46:14] <jepler> don't use the computer too much
[20:46:26] <alex_joni> jepler: only when I finish my stock of books
[20:47:00] <SWPadnos> well, then you could add a lightweight SVGALIB/FB version of AXIS then :)
[20:47:09] <SWPadnos> oh, and HAL hardware interrupt threads
[20:47:17] <SWPadnos> (if you have time)
[20:47:24] <ds2> please fit the FB version in 640x480 =)
[20:47:37] <fenn> fix keystick so it doesnt need an x server
[20:47:49] <jepler> make an aalib port of axis so it runs on the terminal
[20:47:59] <SWPadnos> oooooh - that's a good one :)
[20:48:01] <SWPadnos> with 3D
[20:48:11] <alex_joni> lol
[20:48:11] <fenn> use libnethack for a nethack interface to emc
[20:48:17] <alex_joni> nethack?
[20:48:19] <SWPadnos> doom interface!
[20:48:29] <ds2> make EMC runnable on a 386 w/16M of RAM and 32M hard drive
[20:48:41] <SWPadnos> you shoot the part files you want to run, and when you have to change tools, the big boss monster comes out and yells at you
[20:48:42] <archivist> 286
[20:48:42] <jepler> no no -- the palm 100
[20:48:43] <fenn> ds2: i think it already does
[20:48:54] <ds2> fenn: I been told otherwise
[20:49:01] <jepler> ubuntu sure won't
[20:49:13] <alex_joni> ds2: emc runs on crappier hardware
[20:49:16] <SWPadnos> I think the timing bits in RTAI/RTAPI need a TSC
[20:49:20] <alex_joni> just not the latest distro
[20:49:23] <SWPadnos> which implies 486, no?
[20:49:25] <ds2> don't care. I just want to embedded into a system that fits in the original machine chasis!
[20:49:28] <alex_joni> yup
[20:49:31] <jepler> rtai probably bitrotted for pre-pentium CPUs
[20:49:32] <ds2> TSC implies 586
[20:49:44] <jepler> you'd have to hack out the bits that use TSC (they're only for statistical uses anyway)
[20:49:46] <SWPadnos> well in that case ...
[20:50:09] <jepler> reporting of thread / function invocation times, for instance
[20:50:10] <alex_joni> * alex_joni packs more books
[20:50:17] <jepler> primitive latency checking in task
[20:50:20] <jepler> and so on
[20:50:30] <fenn> alex_joni: rtai hacking for dummies? :)
[20:50:45] <SWPadnos> I don't suppose these super-duper processors actually allow you to use the TSC or some other register to generate interrupts, do they?
[20:50:47] <jepler> and you'll at least need 386+387, there's no FP emulation in kernel space
[20:51:07] <ds2> removing the TSC dependacy would be good anyways...then you can use WinChip's and other early pentium clones
[20:51:16] <ds2> okay, I'll settle for 486+
[20:51:26] <fenn> there are a lot of 486 laptops floating around
[20:51:28] <SWPadnos> Elan SC520 (though the interrupt controller really sucks)
[20:51:28] <jepler> ds2: patches gratefully accepted
[20:51:33] <ds2> jepler: =)
[20:51:49] <ds2> when winter comes, I'll do more code hacking
[20:52:07] <ds2> nothing major, just like last year...little bits here and there
[20:52:38] <jepler> don't sell yourself short just because you don't do anything "major"
[20:52:47] <alex_joni> well.. see you guys
[20:52:49] <SWPadnos> yeah - look at me ;)
[20:53:12] <jepler> almost any project will benefit from someone who sees an area that needs cleanup or tiny improvements, and then follows through with patches
[20:53:21] <jepler> because too often the developers are concentrating on the next big feature
[20:53:41] <ds2> what might help speed things up is if someone can set up UML images for compiling the RTAI stuff
[20:53:43] <jepler> if you are improving code quality and adding polish to the system .. that is really valuable
[20:54:14] <ds2> my biggest stumbling block to going deeper is no time to setup an RTAI build system
[20:54:29] <fenn> compiling rtai cant be that hard - even i can do it
[20:54:57] <ds2> it isn't that it is hard, it takes time and normally requires yet-another-machine which means another HD + Box + etc
[20:55:06] <ds2> UML gets around the last part
[20:55:23] <fenn> have you seen this?
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?RtaiSteps
[20:55:38] <ds2> yep
[20:55:57] <ds2> you assume people are using apt
[20:56:07] <fenn> i'm afraid i dont see how uml images would help. that's like flowchart diagrams right?
[20:56:13] <ds2> no no
[20:56:18] <ds2> User Mode Linux
[20:56:26] <jepler> they should have chosen a different acronym then
[20:56:27] <ds2> basically a Linux kernel + image virtualized as a user process
[20:56:36] <fenn> ds2: actually when i wrote those instructions i was using redhat
[20:56:52] <ds2> qemu/vmware is a bit heavy weight
[21:00:43] <fenn> i doubt rtai would work with UML anyway
[21:01:39] <fenn> or any virtualization technology
[21:02:11] <SWPadnos> but compiling it should work, I'd think
[21:02:43] <fenn> uh. but then why would you need UML?
[21:03:20] <fenn> i thought uml was to test the code you just compiled
[21:03:43] <ds2> didn't say work
[21:03:53] <ds2> just to let me compile as I understand it, wants special headers
[21:04:12] <fenn> no, it just wants linux kernel source
[21:04:14] <ds2> what I want is a cross build enviroment
[21:04:32] <ds2> Oh? so I can boot the Ubuntu EMC2 CD and steal the headers from tehre?
[21:04:34] <ds2> there
[21:04:44] <SWPadnos> you should be able to compile with some incantation like ./configure --with-realtime=/path/to/RTAI --with-kernel=/path/to/soem/kernel or similar
[21:04:53] <SWPadnos> then compile
[21:04:58] <fenn> maybe.. but the safe route is to get sources from kernel.org
[21:05:15] <ds2> I am trying to avoid the patching time sink =)
[21:05:29] <ds2> but I will look in that when things wind down later this year
[21:05:44] <SWPadnos> patching is pretty trivial - it takes like 30 seconds once you have RTAI
[21:05:55] <SWPadnos> plus download time ;)
[21:05:58] <ds2> it really goes in cleanly?
[21:06:02] <fenn> mv linux-2.6.10 linux-2.6.10-adeos
[21:06:04] <fenn> cd linux-2.6.10-adeos
[21:06:04] <fenn> patch -p1 < ../hal-linux-2.6.10-i386-r9.patch
[21:06:18] <ds2> most patches I deal with don't and it is hours if not days of resolving conflicts, etc
[21:06:32] <jepler> if you pick a matching vanilla kernel and rtai patch it will go in without conflicts
[21:06:44] <ds2> okay, even better
[21:06:48] <jepler> but if you choose anything but an exact match (and that may not always be obvious from the rtai patch naming) then you may get reams of conflicts
[21:07:05] <jepler> or if you choose a distro patched kernel as a starting point
[21:07:12] <fenn> yeah, dont do that
[21:07:40] <ds2> I like starting with K.O sources
[21:07:58] <ds2> it is just patches that go in cleanly have been rare lately
[21:08:36] <ds2> don't matter if this works cleanly, I'll just do a chroot and be set
[21:08:44] <fenn> the only other stumbling block is making sure you use the same gcc version to compile rtai as you use to compile emc/hal
[21:09:20] <ds2> are there explicit checks or will it fail in subtle ways?
[21:09:29] <fenn> i think there are checks now
[21:20:37] <fenn> looks like i'm going to be messing with openvz soon
[21:31:30] <fenn> "The unique feature of User Mode Linux is that you can run it under standard debuggers for studying Linux kernel in depth."
[21:37:24] <ds2> and it is lighter weight then full virtualization
[21:39:46] <CIA-24> 03jepler 07TRUNK * 10emc2/src/hal/utils/comp.g: make TRUE, FALSE appear in manpages
[21:56:50] <dmessier> High all
[21:59:56] <Adam0> hi
[22:00:31] <dmessier> whats new
[22:02:32] <Adam0> who knows
[22:02:47] <fenn> google knows
[22:03:33] <dmessier> im having a heck of a time d/loading an iso... 3rd try now...
[22:03:51] <fenn> use wget
[22:04:12] <dmessier> im on a win-blows box
[22:04:19] <fenn> http://gnuwin32.sourceforge.net/packages/wget.htm
[22:06:45] <dmessier> i'll pull it in and try to install IT
[22:35:57] <skunkworks> how come I get this running head with a 2.1.7 config? I don't see anyting on this page
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?UpdatingConfigurationsForDevelopmentVersions
[22:36:15] <skunkworks> emc/task/emctask.cc 312: interp_error: Required parameter missing
[22:36:15] <skunkworks> Required parameter missing
[22:36:15] <skunkworks> emc/task/emctaskmain.cc 2653: can't initialize interpreter
[22:36:30] <skunkworks> trunk I mean
[22:37:37] <skunkworks> wai t - that is the var file issue isn't it - the new axiss
[22:43:29] <skunkworks> yep
[23:01:08] <Degas> Hello All
[23:01:20] <Degas> i´m having problems on my EMC
[23:01:27] <Degas> it was running OK
[23:01:51] <Degas> today i turned on the PC-CNC machine and EMC turned off
[23:02:01] <Degas> anyone can help?
[23:09:59] <dmessier> very odd... how has EMC turned OFF
[23:11:21] <Degas> well, i shoosed the machine configuration (anyone) an then EMC goes out
[23:12:33] <dmessier> virtual machine>>
[23:13:45] <Degas> huh?
[23:13:48] <Degas> virtual machine?
[23:14:12] <dmessier> are you hooked up to a machine???
[23:14:27] <Degas> i run EMC, choose a Machine conf, and EMC close itself
[23:14:33] <Degas> yes
[23:14:44] <Degas> but i have my own machine conf
[23:15:05] <dmessier> ok.. emc or emc2 ??
[23:15:13] <Degas> EMC2 sorry
[23:15:24] <Degas> 2.0.5
[23:15:30] <Degas> running on debian 4
[23:15:49] <dmessier> any switches down... e-stops or such??
[23:16:00] <Degas> nope
[23:16:07] <Degas> not hardware problem
[23:16:28] <dmessier> have a back-up?? from when it worked??
[23:16:29] <Degas> EMC2 don´t work, XYZ screen don´t load
[23:17:04] <dmessier> im an old tape guy...
[23:17:14] <Degas> last words on lots of screens are:
[23:17:18] <Degas> libnml/os_intf/_shm.c 257: No shared memory buffer exists for this key and the I PC_CREAT was not given.
[23:17:51] <Degas> wanna see dmesg? I can put on a pastebin
[23:18:05] <dmessier> any storms in your area recently??
[23:18:45] <Degas> hm, PC crashed this week one time...
[23:18:59] <dmessier> sounds like corruption....
[23:19:04] <Degas> yep
[23:19:08] <Degas> what should i do ?
[23:19:30] <dmessier> do you grab an image once in a while??
[23:19:48] <Degas> look, my install is not ubuntu
[23:20:07] <dmessier> is you maschine config file still there and ok??
[23:20:10] <Degas> a have not fashio interface lol
[23:20:18] <Degas> yeah its still there
[23:20:26] <Degas> i have a very small install
[23:20:36] <dmessier> even better you can dou your own thing then
[23:20:50] <dmessier> PUPPY??
[23:21:09] <Degas> my graph interf is only: XVESA, AEWM++ , XTERM and EMC2
[23:21:19] <Degas> im using putty now yes
[23:21:37] <dmessier> cool.. you can fatten it.. LOL
[23:21:39] <Degas> i can put on pastebin all you need
[23:22:07] <dmessier> have you got a puppy cd??
[23:22:25] <Degas> nope, i got DEbian 4 netinst
[23:22:41] <Degas> then installed openssh-server just to sendo files
[23:22:48] <dmessier> hmm...
[23:22:57] <Degas> installed xvesa and basic fonts
[23:23:08] <Degas> then emc2
[23:23:19] <Degas> it worked great
[23:23:19] <dmessier> why?? .. hardware???
[23:23:26] <Degas> but today its not opning
[23:23:31] <Degas> yes
[23:23:36] <Degas> i´m from Brazil
[23:23:41] <Degas> 3rd world
[23:23:42] <dmessier> where are you??
[23:24:23] <dmessier> shite i'll packya a box a stuff.... ut i'll need a mailing addy...
[23:24:46] <Degas> huh?? Will ya send me what? lol !!!!
[23:24:50] <dmessier> what are you running??
[23:25:05] <Degas> on machine? or on this PC ?
[23:25:16] <dmessier> pc
[23:26:01] <Degas> well im on XP now
[23:26:03] <dmessier> spare parts... i have a storage unit of OLD machines..
[23:26:14] <dmessier> but what dont work??
[23:26:19] <Degas> using putty to send commands to mey R.I.Ppped emc2 lol
[23:27:20] <Degas> EMC2 dont work dude
[23:27:27] <Degas> linux is up
[23:27:38] <dmessier> oic
[23:27:48] <Degas> i command: xinit; emc2 runs automatically
[23:27:59] <Degas> opans upto 2nd penguin
[23:27:59] <dmessier> something nuked...
[23:28:01] <Degas> full screen
[23:28:34] <Degas> but then emc2 stops and crashes, X simply goes out, them text screen
[23:29:09] <dmessier> i hate when that happens..... i feel for ya...the BRAINS in here might help ya
[23:29:27] <Degas> yeah i hate it too
[23:29:41] <dmessier> the will.. wait for it... ;)
[23:30:02] <Degas> yep
[23:32:05] <dmessier> cradek or alex should be able to help...
[23:33:00] <JymmmEMC> If X crashes, sounds like it might be a video config issue
[23:33:38] <Degas> maybe, but i can see EMC screens , are you sure?
[23:33:59] <Degas> or, maybe not... i dunno
[23:34:27] <JymmmEMC> emc spalsh screen is just a single image
[23:34:44] <Degas> yeah a GIF
[23:34:58] <Degas> i will check the xorg.conf again
[23:35:13] <JymmmEMC> might try starting emc from shell and see what the log shows
[23:35:59] <dmessier> thx Jymmm... ; )
[23:36:32] <Degas> emc from shell? heare on putty ?
[23:36:43] <Degas> pls show me how, nice aproach
[23:38:35] <Degas> wow
[23:38:49] <Degas> i think its the problem
[23:39:27] <Degas> i mean, i´ts not
[23:39:34] <Degas> cos im seeing the VGZ config
[23:39:47] <robin_sz> * robin_sz bounces
[23:39:49] <Degas> i remember that it was working good
[23:39:55] <Degas> VGA sorry
[23:42:05] <Degas> Please check my DMESG on:
[23:42:05] <Degas> http://pastebin.ca/667414
[23:42:44] <Degas> I will try again oto run X from putty and pastebin it too, one sec
[23:43:31] <JymmmEMC> * JymmmEMC duct tape's robin_sz (in a non-sexual way)
[23:45:46] <Degas> Oh
[23:45:57] <Degas> Stepper_mm runs OK
[23:46:13] <Degas> i will try to re-send the config files...
[23:55:19] <dmessier> ok ... i'll believe that Jymmm..... need 911 robin_sz???
