#emc | Logs for 2005-07-17

Back
[00:00:32] <anonimasu_> :)
[00:08:41] <Jacky^> umpf
[00:08:49] <Jacky^> videolan won't work :\
[01:51:35] <Jacky^> GNight
[07:12:48] <sxpert__> sxpert__ is now known as sxper
[07:12:51] <sxper> sxper is now known as sxpert
[10:38:16] <anonimasu_> morning everyone
[11:12:17] <Jacky^> morning
[11:35:49] <anonimasu_> what's up?
[11:35:51] <anonimasu_> err morning
[11:37:23] <anonimasu_> * anonimasu_ found inspiration for writing code again
[11:38:41] <Jacky^> hi anonimasu_ :)
[11:38:54] <Jacky^> i'm tryng to get videolan working
[11:39:12] <Jacky^> i'm asking on #videolan for help..
[11:42:46] <anonimasu_> isnt there a deb
[11:46:28] <Jacky^> yes,
[11:46:37] <Jacky^> the apps are installed
[11:46:51] <Jacky^> just can't send the video to another pc on lan
[11:47:12] <Jacky^> get error : main private error: cannot add this stream
[11:47:33] <Jacky^> I tried with avi file, tv out /dev/video0 , same thing..
[11:47:50] <Jacky^> I'm missing something
[11:49:09] <anonimasu_> :/
[11:49:18] <Jacky^> uh
[11:49:24] <Jacky^> seem work now
[11:49:34] <Jacky^> but the video quality is poor..
[11:49:44] <Jacky^> and i can't see the local video
[11:49:55] <anonimasu_> hm, you can configure it lots..
[12:45:42] <anonimasu_> :)
[14:23:02] <alex_joni> kinda quiet today :(
[14:23:44] <ValarQ> yeah
[14:23:48] <ValarQ> probably my fault
[14:25:42] <alex_joni> why's that?
[14:25:48] <anonimasu_> hello
[14:26:02] <anonimasu_> I am in a bad mood & doing dishes
[14:26:05] <anonimasu_> :D
[14:26:33] <alex_joni> ouch ;)
[14:26:56] <anonimasu_> I cant find the mop
[14:27:01] <anonimasu_> so I cant finish my cleaning
[14:27:14] <ValarQ> alex_joni: i was the one that was quiet, didn't you notice? ;)
[14:27:26] <alex_joni> ahh.. right
[14:27:39] <anonimasu_> what's up with you guys today
[14:27:49] <alex_joni> nuttin
[14:32:13] <anonimasu_> ok
[14:32:14] <anonimasu_> me neither
[14:32:16] <anonimasu_> just cleaning
[14:42:22] <alex_joni> hey steve
[14:43:57] <steve_stallings> morning Alex
[14:44:24] <alex_joni> afternoon ;)
[14:44:36] <steve_stallings> phase lag....
[14:44:50] <steve_stallings> hangover too....
[14:44:50] <alex_joni> kinda ;)
[14:45:05] <alex_joni> ouch :)
[14:45:57] <fenn> well damn, i love to be contrary.. i feel great this morning!
[14:46:55] <steve_stallings> you will get over it, as will I...
[14:47:06] <alex_joni> heh
[14:47:09] <alex_joni> :D
[14:47:19] <steve_stallings> a bit of coffee and I will be fine
[14:47:33] <fenn> yes just wait for those four waffles i just ate to kick in, and i'll be moaning like the rest of you
[14:47:48] <fenn> * fenn bellyaches
[14:49:56] <fenn> there is a bird that comes to my window every morning and peck peck PECKs every five minutes
[14:50:07] <fenn> i hate that bird
[14:50:45] <steve_stallings> get a cat
[14:51:12] <fenn> the cat is so clumsy it falls off the kitchen table.. no way it'll get a quick little bird like that
[14:51:28] <fenn> i hate that cat
[14:54:08] <alex_joni> feed it to the bird
[14:58:00] <steve_stallings> constructive crew aren't we?
[14:58:09] <alex_joni> lol
[14:59:28] <fenn> http://www.somafm.com/groovesalad.pls
[15:00:48] <anonimasu_> heh
[15:00:56] <steve_stallings> what is a .pls file?
[15:01:09] <alex_joni> a playlist file
[15:01:10] <fenn> internet radio station.. a .pls file is a playlist file
[15:01:19] <alex_joni> opens in doze players
[15:01:29] <fenn> i'm using xmms
[15:01:52] <steve_stallings> sorry, I keep my doze box locked down too tight, no auto execute, play or whatever
[15:02:02] <ValarQ> fenn: ever tried musicpd?
[15:02:12] <fenn> ValarQ: nope, why, should I?
[15:02:36] <fenn> i seem to have misplaced all my mp3s
[15:02:40] <ValarQ> fenn: because it works better than xmms
[15:03:13] <ValarQ> fenn: it works much better for me anyway
[15:03:26] <fenn> but xmms is easier to type than musicpd :)
[15:04:01] <ValarQ> you never type musicpd
[15:04:05] <ValarQ> the programs name is mpd
[15:04:14] <fenn> well that's a little better
[15:04:20] <ValarQ> and that is a daemon which you only start once :)
[15:04:39] <ValarQ> then you can control it from a great range of different clients
[15:04:54] <alex_joni> * alex_joni goes away
[15:04:59] <alex_joni> back later guys
[15:05:37] <ValarQ> http://musicpd.org/
[15:06:27] <fenn> if i ever do more than just listen to mp3's, like if i set up a radio station for my house, i'll probably use something like that
[15:06:57] <fenn> but it's one more daemon i have to look at every time i type ps -ef
[15:07:06] <thalx> EMC gets a quick blurb in a trade rag... Cutting Tool Engineering. Pics at http://aquila.aldor.com/ebay/emc/
[15:09:26] <ValarQ> fenn: why look?
[15:09:27] <steve_stallings> thanks, I can even read the text
[15:10:51] <fenn> hmmm i thought emc did more than 6 axes.. i wonder if they got it wrong or if I've got it wrong
[15:12:55] <fenn> thanks for sharing that thalx
[15:13:45] <steve_stallings> current motion planner only handles 6 axes
[15:15:20] <fenn> i wonder why.. seems like an arbitrary thing
[15:15:51] <fenn> all the functions are coded like for( i=0l i<MAX_AXES
[15:17:02] <fenn> actually that's emc2, but i thought it re-used the code from emc1
[15:17:31] <anonimasu_> the planner does not support that many axes I think..
[15:17:46] <anonimasu_> * anonimasu_ is curious about rotary interpolated axis:es
[15:18:10] <fenn> rotary interpolated? like g2? or like a rotary table?
[15:18:19] <steve_stallings> I am not sure why not more than 6. The move from 4 to 6 was to support hexapods. Fun starts with anything greater than 3 as feed rate becomes undefined.
[15:18:48] <anonimasu_> like a rotary table
[15:18:51] <fenn> you have to specify which axis is being fed at that rate
[15:18:57] <fenn> that's one of the limitations of rs274
[15:19:02] <anonimasu_> like g1 x10 f300 r40
[15:19:05] <fenn> (you cant specify which axis)
[15:19:14] <anonimasu_> the rotary axis should be interpolated..
[15:19:25] <anonimasu_> so when x is at 10 the rotary axis should be at 40
[15:19:35] <steve_stallings> Limits of Cartiesan geometry. Beyond that you must know the kinematics of the machine.
[15:19:44] <anonimasu_> nothing fancy about that really
[15:19:53] <fenn> anonimasu: that was just brought up on the developrs list yesterday.. it works just as you would expect
[15:20:01] <anonimasu_> yeah I saw that..
[15:20:08] <anonimasu_> although I didnt have time to read it too much
[15:22:32] <fenn> steve_stallings: could you explain further? cant understand what you mean by limits of cartesian geometry
[15:22:59] <fenn> like, cartesian has xyz, rpw
[15:23:17] <steve_stallings> Rate of travel is the square-root of the sum of the squares of three Cartisian axes.
[15:23:56] <steve_stallings> This equation does not work for more than three axes.
[15:24:02] <fenn> isnt the issue that the motion planner is only capable of moving one object?
[15:24:24] <anonimasu_> the issue on the list?
[15:24:33] <fenn> no, why emc only supports up to 6 axes
[15:24:42] <anonimasu_> you cant move one axis independently though
[15:24:45] <anonimasu_> while moving the rest..
[15:24:57] <steve_stallings> So you must now take into account how axis 4, 5, etc. alter the effect of axis 1, 2, and 3 on feed rate.
[15:25:16] <anonimasu_> yeah, or write a function to disconnect your rotary axis..
[15:25:22] <anonimasu_> or some axis, for continous motion
[15:25:23] <fenn> you should be able to move them independently
[15:25:32] <anonimasu_> fenn: how do you do that in gcode?
[15:25:37] <fenn> like, axes 1,2,3 are synchronized, axes 4,5,6 are synchronized
[15:25:41] <anonimasu_> fasd &
[15:25:47] <fenn> anonimasu: you cant? i dont know.. i hate gcode
[15:25:49] <steve_stallings> To do this, the planner must understand the specifics of the kinematics of the machine and thus cannot be generalized into the planner.
[15:25:52] <anonimasu_> fenn: you cant..
[15:26:07] <fenn> emc shouldn't be designed around the limitations of gcode language
[15:26:28] <steve_stallings> NO - all 6 axes are interpolated at the same time without problem. Feedrate is the issue.
[15:26:37] <anonimasu_> not really the problem
[15:26:44] <anonimasu_> or is it?
[15:27:28] <steve_stallings> Morning Dave
[15:27:39] <dave-e> morning Steve
[15:27:42] <anonimasu_> the trouble is more that there's no code to run a axis continously
[15:27:46] <dave-e> small group thismorning
[15:27:55] <steve_stallings> summer
[15:27:57] <fenn> dave-e: lively discussion
[15:28:02] <dave-e> good
[15:28:57] <fenn> anonimasu: i think if the motion planner had a separate thread for each separate object in 3d space, you could do so much more
[15:28:59] <steve_stallings> The 6 axis limitation could probably be removed without too much difficulty, as long as you decide how to control feed rate.
[15:29:22] <fenn> ini file variables?
[15:29:34] <fenn> specify which axes are synchronized to which other axes
[15:29:36] <anonimasu_> fenn: define what you mean...
[15:29:51] <fenn> anonimasu: one object is the table, another object is the spindle, another is the tool carousel
[15:30:02] <steve_stallings> EMC doesn
[15:30:08] <anonimasu_> that's not parts of the tp.
[15:30:16] <steve_stallings> EMC doesn't know or care about objects.
[15:30:19] <fenn> huh?
[15:30:24] <fenn> well it should
[15:30:30] <anonimasu_> it should not..
[15:30:50] <fenn> well if you cant keep your spindle spinning unless the table is moving, you have a problem
[15:30:56] <anonimasu_> maybe have the tp threaded and have the functionality to remove interpolation from one axis
[15:30:57] <steve_stallings> all axes are part of the same "world view" as Ray likes to say
[15:31:06] <dave-e> ah but you can
[15:31:12] <dave-e> spindle is independent
[15:31:17] <fenn> dave-e: only because it's hard-coded
[15:31:22] <dave-e> yep
[15:31:47] <fenn> dave-e: look at the latest thread onthe developer list.. some guy has a rotary "spindle" axis on a cylindrical grinder machine
[15:31:55] <fenn> he wants to move it at a constant rate, independant from the other axes
[15:31:58] <dave-e> S2000 M3 will get you a spindle until you do an m5
[15:32:32] <dave-e> roughly constant rate could come from a reference supply and a switch
[15:32:42] <fenn> unless you put load on the motor
[15:32:44] <steve_stallings> EMC is concerned with co-ordinated motion. If the motion is constant or not co-ordinated, then it is a PLC or speed controller function the EMC need only turn on and off.
[15:32:52] <fenn> or if you want to coordinate two separate sets of motion
[15:32:54] <anonimasu_> * anonimasu_ nods
[15:33:01] <dave-e> if all he needs it to turn ...
[15:33:06] <anonimasu_> fenn: that means interpolatedmotion..
[15:33:10] <dave-e> coordination is a different matter
[15:33:11] <fenn> like say i want to do threading at the same time as turning
[15:33:17] <steve_stallings> Two sets are just more axes, EMC need not be concerned with sets.
[15:33:28] <anonimasu_> fenn: multi tool machines?
[15:33:40] <fenn> yeah, but there are many more applications
[15:33:49] <anonimasu_> well, that wouldnt still be a big deal..
[15:34:10] <anonimasu_> how are you going to control it from one interpreter..
[15:34:36] <dave-e> so many of these things are simply in concept but quite difficult to implement
[15:34:43] <dave-e> simple in
[15:34:55] <anonimasu_> oh, the trouble I see is how to control it..
[15:34:58] <fenn> i think it might be easier just because everything would be generalized
[15:35:11] <fenn> so there's less code overall
[15:35:30] <steve_stallings> One classic example- my Hardinge Superslant has two turrets. They run two Fanuc 6T controllers. They use sync-events/handoff to stay co-ordinated.
[15:35:37] <dave-e> generalization is difficult to implement and keep it simple
[15:35:43] <anonimasu_> that's how I'd do it..
[15:36:01] <anonimasu_> run 2 emc's with some form of coordination..
[15:36:07] <fenn> that's insane!
[15:36:24] <dave-e> maybe n ot might be the easy way
[15:36:27] <anonimasu_> fenn: running 2 controllers?
[15:36:33] <fenn> yeah
[15:36:42] <fenn> controller 1 says "go" controller 2 says "stop"
[15:36:48] <fenn> pow!
[15:36:51] <dave-e> against days of coding
[15:37:10] <anonimasu_> fenn: one master one slave..
[15:37:22] <fenn> well, i wouldn't want to use it
[15:37:30] <anonimasu_> * anonimasu_ sighs
[15:37:43] <steve_stallings> Controller two runs whatever until it needs to be in sync. Then it waits for an event from controller one.
[15:37:43] <anonimasu_> fenn: so you would spawn up multiple tp threads? threads
[15:37:52] <anonimasu_> instead..
[15:38:25] <dan_falck> hi guys
[15:38:39] <dan_falck> I know a little about two turret lathes
[15:38:40] <steve_stallings> The two controller concept does not require two computer, but it would take some planning of threads.
[15:38:57] <anonimasu_> yep
[15:39:05] <anonimasu_> the trouble I can see is how you write your code.. for it
[15:39:09] <dan_falck> the computers for the two turrets hand control off to each other with M codes
[15:39:33] <fenn> dan_falck: how do you do stuff at the same time then? like prep the tool carousel and cut a part
[15:39:51] <dave-e> nml?
[15:39:52] <dan_falck> you don't do stuff at exactly the same time
[15:39:56] <anonimasu_> the tool carousel isnt inside the tp..
[15:39:58] <dan_falck> with these machines
[15:40:04] <anonimasu_> it's aux stuff..
[15:40:12] <anonimasu_> plc's/sub threads of the controller
[15:40:24] <fenn> but what if you had two sets of NC motion
[15:40:36] <dan_falck> they just need to avoid hitting turrets together
[15:40:38] <fenn> like a robot arm and a milling machine working together
[15:40:40] <anonimasu_> that does not mean that a toolchanger is interpolated..
[15:40:51] <dan_falck> or creating vibration problems while doing finish cuts
[15:41:07] <anonimasu_> dan_falck: exactly
[15:41:08] <steve_stallings> The G code programmer must know if it is safe for the two controllers to run at the same time. They can and frequently do on a lathe, just stopping where inteference would occur.
[15:41:20] <fenn> anonimasu: ok a toolchanger was a bad example
[15:41:40] <anonimasu_> fenn: as bad as anything..
[15:41:47] <dan_falck> so the guy doing the programming has to do the syncing
[15:41:55] <dave-e> oh fun
[15:41:59] <anonimasu_> fenn: it's STOP/WAIT/GO signals
[15:42:10] <anonimasu_> the robot waits for the mill to finish..
[15:42:15] <dan_falck> yea, it's hair raising to proof out a new program
[15:42:17] <fenn> what's so bad about the tp knowing the kinematics, anyway?
[15:42:24] <anonimasu_> kinematics?
[15:42:34] <fenn> so it knows if the robot arm is gonna crash into the milling spindle
[15:42:52] <fenn> actually that's not what the tp does
[15:43:01] <anonimasu_> the tp plans the motion..
[15:43:02] <fenn> it needs to know if the robot arm is within its acceleration limits
[15:43:33] <anonimasu_> that's dependent on the robot arm controller..
[15:43:49] <steve_stallings> nothing wrong with TP knowing kinematics, that is the basis of how a hexapod works, it is just more complicated than a plain 3 axis machine
[15:43:50] <anonimasu_> fenn: it's also aux stuff..
[15:43:59] <fenn> acceleration in meters/s/s at the tip of the robot arm
[15:44:15] <fenn> anonimasu: i'm talking about using emc to control both a robot arm and a milling machine simultaneously
[15:44:42] <steve_stallings> robot arm, even two axis, may need kinematics if the motion axes are not Cartesian
[15:44:53] <fenn> all machines need kinematics
[15:45:22] <steve_stallings> yes, but the case of a three axis mill uses what EMC calls trivial kinematics
[15:45:26] <fenn> some machines, like most of them, use identity kinematics, where it's practically the same
[15:45:32] <fenn> yeah, identity=trivial
[15:46:04] <fenn> it's not a big deal to go from cartesian to machine space.. just multiply it by a 6x6 matrix
[15:46:15] <fenn> at least its not a big deal in non-realtime
[15:48:37] <dave-e> treat this as a cell...with multiple emc's?
[15:48:41] <fenn> re: feedrate, I see feedrate as similar to threaded cutting, but the axis that everything is synchronized to (the controller axis if you will) is no longer the spindle, but a linear axis
[15:50:24] <fenn> dave-e: you can't synchronize motion in realtime between two different emc's
[15:50:54] <dave-e> but you can do the state machine thing
[15:51:12] <fenn> how's that work?
[15:51:13] <steve_stallings> feedrate is not max velocity (as in axes limited) but rather based on process, vector sum may exceed recommeded cutting rate
[15:51:21] <dave-e> pause, go, etc
[15:51:35] <anonimasu_> dave-e: right
[15:51:37] <dave-e> more like a robot as a tool changer
[15:52:22] <dave-e> or part mover
[15:52:30] <fenn> steve_stallings: yes, that's what i'm saying.. but "recommended cutting rate" is in feet/s instead of surface feet/s
[15:52:43] <fenn> for feedrate vs threading
[15:54:00] <fenn> dammit.. people throw extra axes on mills all the time and dont worry about it
[15:54:14] <fenn> i just wanna throw more axes on a hexapod and not worry about it
[15:55:26] <anonimasu_> fenn: extra axis:es isnt the same as a separate machine
[15:55:38] <anonimasu_> can you really consider a robot a separate axis?
[15:55:44] <steve_stallings> feedrate control for 4 or more axis machines is usually handled by the CAM software, which is made aware of the machine and tool kinematics, then machine runs in inverse time mode (this move should take xx time to complete)
[15:55:52] <fenn> anonimasu: yeah if it's holding the workpiece!
[15:56:59] <fenn> steve_stallings: just wondering, does emc do inverse time mode?
[15:57:09] <dave-e> i believe so
[15:58:43] <fenn> i dont see the need for the separation of CAM and CNC controllers any more, in the era of PC-based CNC controllers
[15:58:59] <fenn> that's what STEP is all about
[15:59:22] <anonimasu_> the cam programs are highly specialized on what they do..
[15:59:23] <anonimasu_> :)
[15:59:49] <fenn> the problem is CAD programs can't seem to use a standard file format like the rest of the software world
[16:00:10] <fenn> so a CAM program is really just a specialized CAD file interpreter
[16:00:17] <Jacky^> hello
[16:00:35] <fenn> the actual toolpath algorithms are sorta an afterthought
[16:00:46] <steve_stallings> Yes, EMC supports G93 inverse time mode for feed rate, G94 is regular mode.
[16:00:50] <anonimasu_> it's not all that simple
[16:00:54] <fenn> it really should be the cad program's job to output a standard format
[16:01:17] <fenn> STL was a good idea but not for CNC machines
[16:01:40] <fenn> only geometry, no process definition like "is this hole drilled? or bored"
[16:02:24] <fenn> not to mention feedrates and such
[16:02:52] <fenn> but it's stupid to have the cam program try to guess at what feedrates to use, since that depends on your machine tool
[16:03:02] <anonimasu_> guess?
[16:03:14] <steve_stallings> STEP still does not solve the multi-axis problems since it is intended to be generalized and does not know the machine kinematics.
[16:03:31] <anonimasu_> I dont belive in step..
[16:03:33] <fenn> right, you should only have to program in the kinematics in one place
[16:03:40] <anonimasu_> really, what happens when you want to do HSM with it..
[16:03:47] <anonimasu_> and special cases..
[16:04:13] <fenn> i dont think step is the solution, but that's where things are going for some reason
[16:04:35] <anonimasu_> hsm machines can have special scenarios for a piece of a part with delicate detail..
[16:05:30] <anonimasu_> or well, any part for that matter
[16:05:46] <fenn> i'd rather there be a standard "cad" format that contains part geometry and design data like material type, tolerances etc
[16:06:04] <steve_stallings> Funny that we are accepting of CAM needing to know machine/process limits in order to set feed rate, but find CAM handling kinematics strange.
[16:06:06] <anonimasu_> yeah, that would be good
[16:06:10] <fenn> and the cnc controller uses that data to generate a toolpath, based on the kinematics and "machine tool info"
[16:06:34] <dave-e> I think step does have to tolerance data
[16:06:40] <fenn> yeah CAM should be a part of the cnc controller
[16:07:21] <fenn> not part of the cad package
[16:07:28] <dave-e> but there is a reason for having custom posts for cam programs
[16:07:39] <dave-e> just to hande a controller/machine
[16:08:00] <anonimasu_> fenn: have you heard the the saying "let the professionals take care of it"
[16:08:06] <anonimasu_> as far as I can see this issue is the same
[16:08:16] <fenn> anonimasu: have you heard the saying "trust us, we're from the government"
[16:08:44] <anonimasu_> fenn: well, I've yet to see any opensouce algorithms for making toolpaths
[16:08:52] <fenn> i know it sucks
[16:09:03] <fenn> i'm gonna write one for brlcad
[16:09:16] <anonimasu_> fenn: there are people investing lots of money to make cam programs good at making toolpaths..
[16:09:26] <fenn> so they say
[16:09:39] <fenn> i've seen lots of university research too
[16:09:46] <anonimasu_> fenn: why is there no opensource algorithms?
[16:09:48] <fenn> but for some reason the uni's never publish any fucking source code!!!
[16:10:02] <fenn> who's ass are they kissing?
[16:10:27] <dave-e> no...it is very much who is going to fund my next grant?
[16:10:36] <fenn> this whole world is gonna blow up soon anyway
[16:10:59] <fenn> everyone's in bed with each other, and if you're not in the loop you've got nothing
[16:11:06] <fenn> metaphorically speaking
[16:11:18] <steve_stallings> If the universities are funded by US government grants, the code is public domain. You just have to fight to get them to obey the law.
[16:11:36] <anonimasu_> fenn: the reason is that it's not that easy is because generating toolpaths isnt that simple..
[16:12:00] <dave-e> well, easy in 2D but not in 3D
[16:12:05] <anonimasu_> true
[16:12:38] <fenn> no it's just as hard in 2d or 3d
[16:12:47] <fenn> but we have really low expectations for 2d toolpaths
[16:15:26] <steve_stallings> There are a couple of relatively cheap ($150) programs for CAM that have been developed for Windows and targeted at hobby/home shop use. Sheetcam is 2.5D and MeshCAM is 3D, but both drive only 3 axis machines.
[16:16:08] <dave-e> how well do they work?
[16:17:19] <steve_stallings> Both have active user communities on Yahoo and the comments are fairly positive. The programmers listen to bugs and update regularly for free.
[16:19:21] <dave-e> 'course they are Windoze
[16:19:39] <dave-e> and I'm trying to go Windoze free
[16:19:42] <fenn> i'm not going to taint the purity of my system :)
[16:20:09] <fenn> so now i gotta write a cam program :(
[16:20:17] <dave-e> do it
[16:20:22] <anonimasu_> * anonimasu_ nods
[16:20:26] <fenn> i gotta learn how to use brlcad first
[16:20:50] <fenn> its got a lot of quirks
[16:21:04] <fenn> openGL shading is still experimental!
[16:21:07] <dave-e> designed by programmers for programmers
[16:21:07] <steve_stallings> why, CAM program should be free standing and import common data formats
[16:21:26] <fenn> steve_stallings: CAM has to know machine parameters somehow
[16:21:39] <dave-e> config file?
[16:21:40] <fenn> steve_stallings: where better to get that data than from the CNC controller?
[16:22:07] <steve_stallings> BRLCAD supplies machine parameters, or am I crossing messages in my mind?
[16:22:25] <fenn> brlcad is mainly for simulating nuclear bomb effects on tanks, stuff like that
[16:22:46] <fenn> neutron penetration, ballistic simulations, radar reflection
[16:22:50] <dave-e> ballistics research labs.
[16:22:57] <fenn> but it's got a good suite of modeling tools and imports a wide variety of formats
[16:23:00] <steve_stallings> OK, tying to be clearer now, how is BRLCAD related to your CAM proposal
[16:23:16] <fenn> brlcad is a good open-source CAD platform that runs on linux (and windows too?)
[16:23:24] <fenn> there is no open source CAM program
[16:23:51] <fenn> so.. in order to avoid having to write code to understand/manipulate 3d geometry and lots of file formats, i'm going to use BRLCAD as the base
[16:24:21] <steve_stallings> so you only have to learn the BRLCAD internal data format?
[16:24:23] <fenn> it's a short term solution.. not in any way related to how things ought to be
[16:24:29] <fenn> right
[16:25:03] <fenn> but right now its either do that or set up a new computer and waste hundreds of hours dealing with windows
[16:25:17] <anonimasu_> hundreds?
[16:25:24] <fenn> exaggeration :)
[16:25:29] <anonimasu_> yeah quite..
[16:25:40] <anonimasu_> :D
[16:25:41] <fenn> i really hate windows
[16:26:28] <dave-e> actually XP works pretty well if you keep it isolated f rom the net
[16:26:40] <anonimasu_> well, w2k is good..
[16:26:47] <fenn> actually there are some open source CAM programs but none that do more advanced stuff like waterline or >3 axis
[16:26:54] <steve_stallings> fair enough, I would like to love Linux, but WHICH Linux? (not seeking answer about favorites, just exasperated at variety)
[16:27:04] <dave-e> I'm fighting Debian right now...
[16:27:05] <anonimasu_> I like linux, but I cant say I love it..
[16:27:13] <fenn> steve_stallings: they are all the same once you get the hang of apt-get
[16:27:16] <anonimasu_> it's a messy operating system..
[16:27:17] <anonimasu_> :)
[16:27:21] <dave-e> downloaded the net install. 180 Mb and installed...
[16:27:48] <dave-e> nice and fast but it doesn't come with X windows component
[16:28:01] <fenn> thats odd
[16:28:09] <dave-e> so I get to ftp X windows and try and install.
[16:28:22] <fenn> can't you apt-get install xorg ?
[16:28:26] <dave-e> not fun ... 4.5.0 doesn't know my optical mouse
[16:28:38] <anonimasu_> um, what kind of optical?
[16:28:42] <dave-e> ms
[16:28:48] <anonimasu_> usb/pci?
[16:28:48] <anonimasu_> err
[16:28:50] <anonimasu_> ps2
[16:29:00] <dave-e> tried it both din and usb
[16:29:10] <dave-e> ps/2 and usb
[16:29:10] <anonimasu_> set the input to /dev/input/mouse
[16:29:21] <anonimasu_> usb mouses should end up there :)
[16:29:21] <dave-e> dev/mouse
[16:29:42] <dave-e> meece?
[16:29:47] <fenn> meeces
[16:29:48] <anonimasu_> dave-e: dosent exist if you dont make it first :)
[16:30:12] <anonimasu_> or if the dist comes with the symlink in place
[16:30:12] <fenn> that's one good thing about udev
[16:30:13] <dave-e> I'll try dev/input/mouse
[16:30:24] <anonimasu_> look in /dev/input first
[16:30:32] <dave-e> can do....
[16:30:32] <anonimasu_> I can have a look in a hour if you want what I am using
[16:30:41] <anonimasu_> need to sleep a bit
[16:30:42] <anonimasu_> :)
[16:30:44] <dave-e> only have to swap disks
[16:31:14] <dave-e> course it on this machine
[16:32:01] <dave-e> off debian.org...well the se mirror ... I did a desktop install...and thought that would be me an X windows...apparently not
[16:32:35] <dave-e> get me
[16:32:37] <fenn> did you try "startx" ?
[16:32:41] <dave-e> yep
[16:32:45] <fenn> ok :)
[16:33:20] <dave-e> and X86Free -autoconfig
[16:33:36] <dave-e> and XF86Free -configure
[16:33:49] <fenn> if that's there it means you have X installed
[16:34:18] <fenn> look in /var/log/messages and see if there's any messages about X messing up
[16:34:18] <dave-e> it tries...but stalls on the window with the X and one has to kill it and look at the log file
[16:34:36] <dave-e> mouse is one problem...
[16:34:49] <fenn> that sux
[16:34:56] <dave-e> but it also looks for dev/hb0 which doesn't exist
[16:35:14] <dave-e> cannot find anything in the config file to change to fix that
[16:35:18] <fenn> sounds like someone did a poor job packaging X
[16:36:53] <dave-e> I tried the straight bdi-4.20 install but the display was awful....jerky mouse... at 1280 x 1024 which my 64 Mb card should handle easily
[16:38:24] <dave-e> I'll sort it out somehow...it just isn't easy
[16:40:04] <dave-e> enough complaining ... back to work
[16:40:14] <dave-e> thanks for the try :-)
[16:50:48] <fenn> some day, i'm going to fly a spaceship with a general-purpose piece of machine control software similar to emc
[16:51:29] <fenn> (but emc isn't all that general purpose enough yet)
[17:26:25] <staggerlyTom> * staggerlyTom sez Hiya Hiya Hiya
[17:34:39] <fenn> right now i'm writing to some uni professors whose research is developing CAM algorithms
[17:35:05] <fenn> asking them to "do the right thing" and release their source and pre-proofs of the papers under the gpl
[17:35:16] <fenn> it will be interesting to see what happens
[17:36:12] <jmkasunich> has anybody seen alex_joni today?
[17:38:11] <fenn> 2 hours ago.. said he'd be back
[17:38:17] <jmkasunich> thanks
[17:51:48] <dan_falck> I have a set up question
[17:52:11] <dan_falck> Is there any way to set up EMC to skew an axis that isn't square to another axis?
[17:52:43] <SWPadnos> you're looking for "trapezoidal" kins? :)
[17:53:04] <dan_falck> I have a mill with a big problem. Y is not square to X
[17:53:34] <dan_falck> I will ultimately get a better mill, but wonder if there's a way of faking it
[17:53:56] <SWPadnos> I think the only answer is to write a kinematics module that corrects for the geometry errors
[17:54:02] <dan_falck> ok
[17:54:12] <SWPadnos> since you need X motion to get linear Y motion
[17:54:56] <SWPadnos> it might be possible to do evil things with HAL to get a similar effect, but I don't want to think about them :)
[17:55:10] <fenn> i thought emc had some sort of axis compensation built in already
[17:55:16] <fenn> for calibrating leadscrews
[17:55:19] <dan_falck> maybe I can do some screwy stuff in CAM
[17:55:30] <SWPadnos> that's non-uniformity along a single axis, not having one axis dependent on another
[17:55:36] <fenn> yeah
[17:55:49] <fenn> where is that done?
[17:56:05] <SWPadnos> you could just use corel draw to shift the envelope of a DXF file, for 2-D stuff
[17:56:27] <SWPadnos> there's a linearity file - I don't remember what it's called
[17:56:35] <dan_falck> I've got some CAD/CAM software that will probably help me a bit
[17:56:51] <dan_falck> or re scrape the ways :(
[17:57:03] <Jymmm> ewwwwwwwww
[17:57:04] <SWPadnos> Option 2 will likely provide the best results
[17:57:23] <jmkasunich> depends on how out of square it is
[17:57:53] <SWPadnos> well - of course it was bound to happen. I start talking on IRC, and my wife decides it's time to do some activity together
[17:58:02] <jmkasunich> LOL
[17:58:05] <jmkasunich> BTDT
[17:58:06] <fenn> damn reality
[17:58:13] <dan_falck> It's a pos mill/drill and this morning I checked it with a square that had been surface ground true -.020" in 6"
[17:58:17] <SWPadnos> at least it's not a "Honey-Do" thing
[17:58:24] <dan_falck> I had never checked it before...
[17:58:30] <jmkasunich> you aren't gonna be able to scrap 0.020
[17:58:38] <dan_falck> no
[17:58:45] <jmkasunich> scrape anyway
[17:58:46] <Jymmm> SWPadnos Suggest that she get on IRC too! LOL
[17:58:50] <dan_falck> I need to scrap it
[17:58:51] <jmkasunich> you could scrap it ;-)
[17:58:57] <dan_falck> use it as a drill press
[17:59:03] <SWPadnos> hmmm - I think I'll pass on that - thanks anyway :D
[17:59:08] <dan_falck> I need a real knee mill anyway
[17:59:12] <fenn> you could give it to me
[17:59:19] <fenn> eh?
[17:59:29] <jmkasunich> fenn: you got the lathe together and running yet?
[17:59:34] <fenn> almost
[17:59:37] <dan_falck> I'll use it as a drill press
[17:59:58] <fenn> i'm slow :(
[18:00:04] <dan_falck> does Roland have any Boss mills left?
[18:00:49] <SWPadnos> SWPadnos is now known as SWP_Away
[18:01:11] <Jymmm> SWPadnos is now known as SWP_Ball_and_Chain
[18:01:12] <jmkasunich> fenn: not as slow as me.. I bought a South Bend 13" lathe about 2 yrs ago
[18:01:16] <jmkasunich> still haven't run it
[18:01:37] <jmkasunich> SWP is living dangerously, better hope SWMBO doesn't look at the screen
[18:01:40] <Jymmm> Anyone run steppers by chance?
[18:02:01] <fenn> steppers? what's that?
[18:02:13] <dan_falck> Jymmm: what kind of couplers does that router table have?
[18:02:31] <Imperator_> does anybody know what i can do when the emc.run script can't find the tcl module msgcat ??
[18:03:05] <fenn> find msgcat?
[18:03:16] <Imperator_> when i search on the debian homepage for msgcat it says that its includet in tclx8.3 that is installed on my system
[18:03:20] <fenn> /usr/bin/msgcat on my page
[18:03:23] <Jymmm> dan_falck it's hard to explain... an aluminum tube with slots cut in it
[18:03:35] <dan_falck> ok. helical coupler
[18:03:50] <fenn> those are nice
[18:04:26] <Jymmm> If I spin the steppers sitting on the bench - no problem. Pick em up off the becnh - they stall. Tight grip in my hand - no problem, loosen my grip - they stall.
[18:04:45] <Imperator_> fenn: /usr/bin/msgcat is a file, right ?
[18:04:47] <dan_falck> resonance- your hand is dampening them
[18:05:16] <Jymmm> Jeff (from cylotex) says this is resonance, but this happens on MotorA when slow, and on MotorB when fast.
[18:05:20] <Jymmm> Xylotex
[18:05:33] <fenn> Imperator_: yes it's a binary16KB
[18:05:37] <jmkasunich> both motors are the same?
[18:05:43] <Jymmm> jmkasunich Yes
[18:05:49] <Imperator_> hm, i have that file but it don't find it
[18:05:54] <Jymmm> I bought everything as a kit from Xylotex
[18:05:58] <jmkasunich> power down, swap motors (where they connect to the driver board)
[18:06:10] <jmkasunich> see if the problem remains with the motor, or with the driver channel
[18:06:18] <Jymmm> Well, no good now. I think the board got fried.
[18:06:19] <fenn> Imperator_: tcl is a GUI thing i think, try switching display to keystick in the ini file and see if it still does it
[18:06:21] <Imperator_> do i have to tel tcl which modules it has
[18:07:12] <dan_falck> bbl. going to look at POS mill again...
[18:07:53] <fenn> dan_falck: use a bigger hammer next time
[18:08:15] <Jymmm> What I need to know is this common with steppers? Would the RPM make a difference? How would you compare a good/bad stepper in respect to resonance?
[18:08:49] <Imperator_> fenn: keystick ?? don't know what this should be
[18:09:07] <fenn> DISPLAY=keystick
[18:09:09] <Imperator_> I#m on emc2
[18:09:15] <fenn> oh, maybe it's not in emc2
[18:09:22] <Imperator_> is that a emc1 thing ?
[18:09:26] <Imperator_> ah
[18:09:45] <Imperator_> it is definatly a tcl problem
[18:09:47] <fenn> try DISPLAY=dummy
[18:10:08] <fenn> then we will know if it is in the emc.run script or in the gui
[18:10:43] <fenn> i need to fix my own emc2 install before i try to do debugging
[18:12:25] <Imperator_> it stops when starting the display now !! DUMMY DISPLAY module, press enter to continue
[18:12:34] <fenn> right that's what dummy is supposed to do
[18:12:42] <Imperator_> ok
[18:13:11] <fenn> so i guess that means the problem is in the gui.. were you using tkemc?
[18:13:51] <Imperator_> i have manualy installed tcl because after the installiation of BDI2.18 it was broken or not there or something
[18:14:11] <Imperator_> jep tkemc
[18:14:31] <Imperator_> do i have to configure tcl ?
[18:15:50] <fenn> * fenn is getting out of his range of knowledge
[18:16:06] <Imperator_> hm
[18:16:08] <Imperator_> thanks
[18:21:30] <fenn> ah! and another thing about feedrate and synchronized axes, is EDM
[18:21:55] <fenn> you synch the feedrate to the voltage across the spark gap, not to the position of any axis
[18:22:21] <jmkasunich> I would use feedrate override, modify it based on voltage
[18:22:33] <jmkasunich> that will slow down or speed up all axes together
[18:22:43] <fenn> what, by hand? a hundred times a second?
[18:22:51] <fenn> sometimes you have to back up, too
[18:23:30] <jmkasunich> a) not by hand... feedrate override can be set by a NML msg, so write code that reads voltage and sends the NML
[18:23:40] <jmkasunich> b) yeah, that;s a problem
[18:23:49] <Imperator_> on a EDM you have to go all the time backwards and forewards
[18:24:19] <fenn> can that be programmed in to the part program?
[18:24:30] <fenn> or does the machine have to sense when it needs to back up?
[18:24:58] <Imperator_> the machine have to sense it
[18:25:26] <Imperator_> it depends on the current, i think
[18:26:34] <Imperator_> we have a lot of wire EDMs and normal EDMs is the cellar at my new job, i can ask if you want to know something
[18:27:04] <fenn> i'll fall off that bridge when I come to it :)
[18:27:11] <staggerlyTom> How often could EMC2 via Ha
[18:27:49] <jmkasunich> ?
[18:27:50] <staggerlyTom> gawd.. How often could EMC2 via HAL , ipdate the analog Feedrate Override? 10ms? 5ms?
[18:28:20] <staggerlyTom> sorry, update..
[18:28:22] <jmkasunich> the HAL part could read an analog input (gap volts) and act on it in realtime, 1mS or better
[18:28:25] <fenn> think it was something like 1 ms
[18:28:34] <jmkasunich> but if you go thru NML, that is user space and slower
[18:29:04] <staggerlyTom> wow, thats fast, roundtrip sound like possible 5mS
[18:29:21] <jmkasunich> the problem with NML is that in user space there are no guarantees
[18:29:33] <jmkasunich> could be mostly under 2mS, but sometimes 100mS
[18:29:36] <fenn> why would you do that in userspace though?
[18:29:48] <jmkasunich> for the EDM thing I would try to keep it entirely in realtime
[18:29:58] <staggerlyTom> there's 3 basic forms of edm control .. for hole, sink, and wire, each needs more sophistacted control
[18:30:28] <staggerlyTom> and sink only needs to modify fwd velocity from programmed rate to 0 THEN able to runaway on interrupt
[18:30:40] <jmkasunich> that would require modifying the motion controller to allow access to the feedrate override value from realtime, but the ability to back up would require significant changes to the motion controller anyway
[18:31:09] <staggerlyTom> so sink does not need to reverse ( just run away , sky blue safe haven not on path)
[18:31:21] <fenn> there's no easy solution to backing up with the current interpreter
[18:31:34] <jmkasunich> is "run away" always just "pull up on Z"?
[18:32:32] <staggerlyTom> run away for sink is... return to top of pyramid, and path is base of pyramid
[18:33:10] <jmkasunich> pyramid?
[18:33:32] <fenn> sink needs side clearance so the electrode is smaller than the cavity, right?
[18:33:40] <fenn> and it moves around in a little circle?
[18:33:41] <jmkasunich> oh, you start at top (point) and move down in increasing orbits as you get deeper?
[18:33:47] <staggerlyTom> yep, pyramid.. you begin work to cut a cubical hole..
[18:34:07] <staggerlyTom> your position is like being at top of an egytian pyramid,
[18:34:28] <staggerlyTom> your approach is anyweay you like towards base of pyramid
[18:34:45] <staggerlyTom> your safe retreat is anyway back to peak, away from stock
[18:34:59] <staggerlyTom> this is ONE orbit only
[18:35:46] <staggerlyTom> I call the top of pyramid the 'roughing point', where the heavy power cut ends
[18:36:03] <staggerlyTom> from the 'roughin point' all excursions take place
[18:36:07] <fenn> what's it called when you do undercuts, like a t slot?
[18:36:33] <fenn> or is that "not done"
[18:36:33] <jmkasunich> you don't do undercuts with a sink EDM
[18:36:37] <jmkasunich> I think
[18:37:19] <staggerlyTom> I do, the path is still triangular in section, with safe place at ctr of bore
[18:37:45] <staggerlyTom> I cut the top face, side wall, bottom face, running away to bore center
[18:38:14] <staggerlyTom> the tool is a flange smaller than the bore to be 'grooved'
[18:38:35] <staggerlyTom> where can pix be sent?
[18:38:59] <fenn> steve can post them for you.. i don't know how to use the dropbox
[18:39:12] <staggerlyTom> Mr Stallings?
[18:39:13] <fenn> or i can put them on my page.. but it's not very permanent
[18:39:16] <fenn> yes
[18:39:24] <staggerlyTom> thanx
[18:39:47] <fenn> i need to get that new wiki up so we can post pictures there
[18:39:59] <fenn> but nobody else seems very thrilled about it :)
[18:40:21] <staggerlyTom> I'd like it, I just glommed your whole site :-)
[18:40:59] <fenn> fenn.freeshell.org has a 50mb/day limit, which is pretty low when you think about it
[18:41:28] <fenn> fenn.dyndns.org is a dsl line, i'm typing on it right now
[18:41:53] <staggerlyTom> Didnt mean to steal all your wind, but I wanted the photos of the 'encoder'
[18:42:11] <fenn> the magnet thingy?
[18:43:14] <staggerlyTom> yeah, just ran to your new site, kewl! how can we dog ear dead old misleading docs?
[18:43:43] <staggerlyTom> I really get po'd when i find the stuff I'm doggedly following is outofdate
[18:43:54] <fenn> the wiki on fenn.dyndns.org is not "official" yet
[18:44:06] <fenn> it's mostly just a mirror of the other one, running different wiki software
[18:44:35] <staggerlyTom> oh, there really is a 'them' huh. who blesses it?
[18:44:43] <fenn> i tried to organize the docs into EMC1 and EMC2, but it's not working so well
[18:45:02] <staggerlyTom> yeak, symlinks with annotaion... neccesary
[18:45:02] <fenn> well, the "them" is people who have a stable server to put the wiki on
[18:45:39] <fenn> also its kinda dumb to have two wikis for one project
[18:46:03] <staggerlyTom> and... you could work on the original wiki??
[18:46:15] <fenn> no, it's a pain in the ass
[18:46:19] <fenn> i'm not going to work on it
[18:46:28] <staggerlyTom> ok, nuf sed
[18:47:05] <staggerlyTom> i need to ask a Q about HAL, but need a bit to compose it..
[18:47:22] <fenn> i've got an inadequate answer, after some hemming and hawing
[18:49:02] <jmkasunich> Tom: ask when ready
[18:49:54] <anonimasu_> iab
[18:52:30] <staggerlyTom> i get: unresolved symbol adeos_get_sysinfo when I su, then cd /usr/local/src/emc2, then 'scripts/realtime start'
[18:52:46] <jmkasunich> what distro are you running?
[18:53:36] <jmkasunich> the realtime script is tested on BDI-4.20 and some other BDIs
[18:54:28] <staggerlyTom> John, where do I check distro version #?
[18:54:45] <jmkasunich> did you intstall it?
[18:55:50] <staggerlyTom> now I have to guess cuz I cant just look it up. I Think I compiled it.
[18:56:12] <jmkasunich> you didn't compile the distro?!
[18:56:33] <staggerlyTom> not the linux distro, the emc2
[18:56:41] <Jacky^> hi
[18:56:44] <jmkasunich> are you using a BDI, or Redhat, or vanilla Debian, or Suse, etc?
[18:57:13] <staggerlyTom> Debian with emc1, (emc2 in sep dir according to some notes i found)
[18:57:39] <jmkasunich> Debian as in you got it from Debian and did the realtime OS install yourself?
[18:58:09] <jmkasunich> or Debian as in Pauls BDI-4.20, which is Debian with a custom installer and RTAI-3.1 already installed?
[18:58:34] <staggerlyTom> uh, the old Live BDI cd ( prior to fest), cuz ther'es a 'install to hd' icon on deb desktop
[18:58:40] <staggerlyTom> how do I identify it?
[18:58:45] <jmkasunich> ok, that is BDI-Live
[18:58:59] <staggerlyTom> thats the one
[18:59:03] <jmkasunich> probably BDI-Live rc46
[18:59:15] <jmkasunich> (dunno how to check that... stand by one sec)
[19:01:09] <staggerlyTom> i see user Morphix, so I guess Paul C's Deb based live bdi cd from Names 2004
[19:02:09] <jmkasunich> do "uname -r"
[19:02:22] <jmkasunich> BDI-Live rc46 will say "2.4.25-adeos"
[19:02:40] <staggerlyTom> 2.4.25-adeos, thats it
[19:04:53] <staggerlyTom> John, dont fix old stuff, I got a new partition waiting
[19:05:14] <staggerlyTom> what should I put on it to test the gcode/mcode/wait/ gcode idea?
[19:06:49] <jmkasunich> BDI-Live is only slighty old
[19:07:03] <jmkasunich> I can reproduce the problem here, need to investigate
[19:07:27] <jmkasunich> if you want to use a current setup (highly recommended) get BDI-4.20
[19:07:39] <jmkasunich> that is a nice Debian with pre-installed RTAI-3.1
[19:09:25] <alex_joni> greetings all
[19:10:02] <ValarQ> greetings you
[19:10:13] <alex_joni> anything interesting today?
[19:10:16] <staggerlyTom> BDI4-20 it is , thanks John
[19:12:05] <alex_joni> hey John, around?
[19:18:07] <alex_joni> jmkasunich: hi there
[19:19:16] <jmkasunich> hi alex
[19:19:29] <alex_joni> seen you were asking...
[19:19:47] <jmkasunich> yeah... still fighting with the 2.6.12 stuff
[19:19:57] <jmkasunich> just now I was looking into a different prog
[19:20:03] <alex_joni> any progress?
[19:20:11] <jmkasunich> the realtime script doesn't work on BDI-Live
[19:20:37] <jmkasunich> seems it can't find the adeos module, it's not in the same directory as all the other rtai modules
[19:20:49] <alex_joni> hmm..
[19:20:57] <alex_joni> maybe it's compiled into the kernel?
[19:21:07] <alex_joni> I used to have that configuration
[19:21:15] <alex_joni> adeos compiled in, the rest as modules
[19:21:15] <jmkasunich> if I manually load adeos, then there is another problem on unload... that damned rtai_ksched -> rtai_up symlink
[19:21:25] <alex_joni> ohh.. bugger that :(
[19:21:34] <jmkasunich> not on Live rc46, adeos is a module
[19:21:39] <alex_joni> right
[19:22:17] <alex_joni> tried anything on 2.6.12 ?
[19:22:24] <jmkasunich> the symlink prob... we have code in the script to find the true name of rtai_up, and load it using that... however for unload you need to use rtai_ksched cause that's how it's listed in lsmod
[19:22:37] <jmkasunich> yeah, 2.6.12 stuff in a minute
[19:23:14] <jmkasunich> anyway, I think on other systems rtai_up appears as rtai_up in lsmod, and that's how you delete it
[19:23:23] <alex_joni> hmm... I have a thought...
[19:23:29] <alex_joni> why not parse lsmod ?
[19:23:34] <jmkasunich> I'm tempted to modify the unload list to contain both names
[19:23:38] <alex_joni> and remove the modules are there
[19:23:49] <alex_joni> check for hal_lib for example
[19:24:19] <jmkasunich> only works if they are parsable (IOW, something that you can reliably parse on, like RTAI*)
[19:24:23] <jmkasunich> might work tho
[19:25:13] <jmkasunich> lemme check something on the farm 4.20 slot
[19:25:37] <jmkasunich> (this 2.6.12 stuff has my main box irreversibly fscked up)
[19:25:49] <alex_joni> you can always go back
[19:26:04] <alex_joni> apt-get remove the newly installed modules
[19:26:08] <alex_joni> and apt-cdrom add
[19:26:25] <alex_joni> apt-get install the 2.6.10 stuff from the cd
[19:27:00] <staggerlyTom> John, I know how to make realtime run
[19:27:16] <staggerlyTom> I have to run EMC from start menu ( as user)
[19:27:20] <staggerlyTom> then stop it
[19:27:47] <staggerlyTom> then su and cd to /usr/local/src/emc2, then 'scripts/raltime start' is ok
[19:28:00] <jmkasunich> yeah Tom, there are ways around it... but it's still busted as far as I'm concerned
[19:28:10] <staggerlyTom> ok
[19:28:31] <jmkasunich> alex: gotta find my cdrom
[19:29:09] <jmkasunich> btw, Pauls repository at 81.100.211.99 seems to be down...
[19:29:11] <alex_joni> jmkasunich: the debs are on the net aswell
[19:29:14] <alex_joni> check the wiki
[19:29:18] <alex_joni> installing on debian
[19:29:24] <alex_joni> they are listed there
[19:29:29] <jmkasunich> you can ping the box, but apt-get update hangs on that url
[19:30:02] <alex_joni> well the 2.6.10 are somewhere else, iirc
[19:30:12] <jmkasunich> anyway... just tried realtime start on the farm 4.20 slot (expecting no probs, just wanted to see how rtai_ksched appeared in lsmod), and I got a kernel panic
[19:30:24] <alex_joni> ouch
[19:30:29] <jmkasunich> things are just going to hell around here
[19:30:52] <alex_joni> probably smthg strange...
[19:31:06] <alex_joni> deb http://homepage.ntlworld.com/bdi-emc/debian ./
[19:31:07] <jmkasunich> rebooted the slot, gonna try again ;-)
[19:32:07] <jmkasunich> so I should put that url in my sources.list instead of the 81.100... one
[19:32:09] <jmkasunich> ?
[19:32:34] <alex_joni> yup.. if you want to go back to 2.6.10
[19:33:00] <jmkasunich> well I'm gonna want to switch back and forth for a while
[19:33:26] <jmkasunich> I guess since the 81.100 ones is down, if I switch back to 10, I won't be able to go to 12 again?
[19:33:26] <alex_joni> the weasiest might be swapping hdd's :)
[19:33:39] <jmkasunich> not that bad
[19:33:40] <alex_joni> jmkasunich: check /var/cache/apt
[19:33:55] <alex_joni> can't remember the exact path
[19:34:00] <jmkasunich> the modules and kernels coexist, and I can pick kernels at boot timne
[19:34:06] <alex_joni> but the debs should be somewhere around there
[19:34:10] <fenn> how do you specify which directory a kernel looks in for modules at boot time?
[19:34:11] <jmkasunich> its only the rtai-dev package that overrites things
[19:34:30] <jmkasunich> the kernel just knows
[19:34:32] <alex_joni> shouldn't
[19:34:42] <jmkasunich> probably uses uname or something
[19:34:50] <alex_joni> rtai-3.2 (that was on 2.6.10) was in /usr/lib/realtime iirc
[19:34:51] <fenn> but my uname is always buggered
[19:35:00] <alex_joni> and the magma is in /usr/realtime
[19:35:11] <alex_joni> so you should be able to make them coexist...
[19:35:16] <fenn> uname -r gives 2.6.10 but it shuold be 2.6.10-adeos, right?
[19:35:31] <alex_joni> but most easy.. (what I would do).. boot 2.6.10
[19:35:31] <jmkasunich> on bdi-4.20, it is 2.6.10-adeos
[19:35:45] <alex_joni> and get rtai-3.2-test2 (I tried that one, not sure about test3)
[19:35:58] <fenn> yeah.. i compiled 2.6.10 and added adeos patches and stuff.. i dont know why the uname didnt change
[19:36:06] <alex_joni> and compiles /install it to somewhere else than /usr/realtime
[19:36:16] <alex_joni> jmkasunich: follow me so far?
[19:36:17] <jmkasunich> did you change EXTRAVERSION in the kernel makefile?
[19:36:25] <fenn> no
[19:36:31] <jmkasunich> that's why uname is fscked
[19:36:34] <jmkasunich> ok, back to alex
[19:36:52] <alex_joni> jmkasunich: basicly .. you have a moer or less working 2.6.12 - magma combo
[19:36:55] <alex_joni> right?
[19:37:03] <alex_joni> more or less because of the shm bugs
[19:37:07] <alex_joni> or whatever...
[19:37:08] <jmkasunich> right now I'm running 2.6.10, and trying to get a RTAI version of hello.world to work
[19:37:22] <jmkasunich> then reboot to 2.6.12 and see the bug
[19:37:33] <alex_joni> still have the 2.6.10 rtai modules?
[19:37:45] <jmkasunich> spent 5 fscking hours last night fighting with kbuild tho, for a dumb typo
[19:37:47] <jmkasunich> yes
[19:37:48] <alex_joni> in /lib/modules/2.6.10-adeos/rtai ?
[19:37:52] <jmkasunich> yes
[19:37:54] <alex_joni> coo
[19:37:58] <alex_joni> then you should be set
[19:38:07] <jmkasunich> just don't have a 2.6.10 version of rtai-config
[19:38:22] <alex_joni> ahh.. and ./configure fails for emc2 .. right?
[19:38:27] <jmkasunich> (or if I do, it's hiding)
[19:38:38] <alex_joni> check /usr/lib/realtime
[19:38:42] <jmkasunich> ./configure finds the 2.6.12 one... so I can only compile for 2.6.12
[19:39:03] <alex_joni> you "may" tweak Makefile.inc
[19:39:08] <jmkasunich> /usr/lib/realtime was deleted
[19:39:22] <alex_joni> well. then it seems that rtai-config (for 2.6.10) is gone
[19:39:31] <jmkasunich> yeah
[19:39:38] <alex_joni> but you should be able to compile against magma includes
[19:39:44] <jmkasunich> I was afraid of this
[19:39:50] <alex_joni> and use the 2.6.10 modules during runtime
[19:40:45] <jmkasunich> * jmkasunich goes to retry scripts/realtime start on the farm 4.20 slot
[19:42:32] <jmkasunich> paniced again
[19:42:55] <jmkasunich> should do a make clean and make next time, just in case something is borked
[19:43:12] <alex_joni> realtime start only installs rtapi and hal_lib
[19:43:24] <jmkasunich> it loads all the rtai modules too
[19:43:31] <alex_joni> yeah..
[19:43:49] <alex_joni> what I was getting at.. it's code that hasn't been changedd in a while
[19:43:57] <alex_joni> btw.. I got the STG today
[19:43:59] <jmkasunich> you would think...
[19:44:03] <jmkasunich> cool
[19:44:10] <alex_joni> yeah. I woudl think..
[19:44:17] <alex_joni> isn't it true?
[19:44:44] <jmkasunich> yeah... and on top of that, I use realtime on this 4.20 box all the time (at least until 2.6.12 fscked it)
[19:45:51] <alex_joni> yeah.. 4.20 worked ok for me too
[19:47:51] <alex_joni> oh, and I got a copy of "The RCS Handbook"
[19:47:53] <alex_joni> ;)
[19:48:45] <alex_joni> * alex_joni goes home...
[19:48:52] <alex_joni> will be online in half an hour
[19:48:58] <anonimasu_> ok
[19:49:00] <anonimasu_> later
[20:17:13] <fenn> bleh.. multivariate, differential, parametric, n-manifold sweeps in n-space
[20:17:37] <jmkasunich> you should wash your mouth out with soap after saying things like that
[20:17:39] <fenn> gonna go chug some glucose
[20:17:45] <fenn> charge up my brain
[20:20:11] <staggerlyTom> if I make drawings for EMC group, what is useful format?
[20:20:22] <jmkasunich> depends on use
[20:20:35] <jmkasunich> if folks need to edit them, probably somethign like dxf
[20:20:51] <jmkasunich> but for veiwing, pdf or gif is much easier
[20:21:40] <jmkasunich> when I've done docs and wanted drawings, I used easycad (makes dxf files) for the masters, then printed them to pdf files and included the pdf in the final document
[20:22:07] <cradek> for simple drawings, xfig works fine
[20:22:55] <staggerlyTom> ok, looking at easycad & tools for dxf. These dwgs must be correct, not just look good ( cad vs art ) no offense.
[20:23:57] <jmkasunich> Tom: easycad is windows only (unfortunately) right now
[20:24:21] <jmkasunich> linux version is coming one of these days, but even then it's not free
[20:24:36] <jmkasunich> it's about $200, and I personally think it's money well spend
[20:24:47] <jmkasunich> but for fast and free, try qcad
[20:25:14] <jmkasunich> fast to get that is, I don't know how fast it runs
[20:26:34] <Jacky^> staggerlyTom: install vmware + vmtools and you'll find the piece..
[20:26:55] <staggerlyTom> well, are there useful viewers? I have Mech Desktop from AutoCad to create files (Win, but files can move)
[20:27:32] <jmkasunich> I don't post dxf files for others to view... too many complications
[20:27:43] <jmkasunich> I usually export as a pdf, anybody can view that
[20:28:48] <cradek> http://wildspark.com/dxfscope/
[20:28:54] <cradek> (I haven't tried it)
[20:30:57] <jmkasunich> note the comments about not all entities work, fonts, etc
[20:31:14] <cradek> yep
[20:31:27] <jmkasunich> so when you give somebody a dxf and they view it, they may not be seeing what you saw in your cad pkg when you created it
[20:31:40] <staggerlyTom> cradek, just grabbed, it, will try & report ( once shortcomings are know, avoid 'em :-)
[20:32:05] <cradek> jmkasunich: but that's *always* the case
[20:32:12] <cradek> jmkasunich: even between versions of autocad
[20:32:18] <staggerlyTom> I can use what you saw is what you had... preview in viewer before uploading
[20:32:24] <jmkasunich> hence my preference to send them a pdf ;-)
[20:32:42] <cradek> staggerlyTom: what do you want to draw and share?
[20:32:47] <staggerlyTom> yeah, pdf is good to look at but you cant get a dim of fit
[20:33:18] <staggerlyTom> I want to show parts for the MAZAK and how EDM motion works for Hole & Sink
[20:33:19] <A-L-P-H-A> Jymmm, so what's the plan now for you?
[20:33:37] <jmkasunich> ah, I see.. you wnat them to be able to click and read stuff that wouldn't be available from a paper print
[20:34:01] <staggerlyTom> yeah, often I dont put in the dims others need, bnut the math model has it.
[20:34:07] <jmkasunich> where I was aiming to give them a paper print that looks just like my copy
[20:34:17] <cradek> staggerlyTom: there's probably no good free solution.
[20:34:24] <jmkasunich> differet problems, differnet tools
[20:34:39] <cradek> staggerlyTom: (I use autocad but understand most people don't have it)
[20:35:13] <staggerlyTom> what about the WEBER on the new BDI 4-20 cd?
[20:35:22] <cradek> fwiw, xfig does let you draw to scale
[20:43:13] <staggerlyTom> Ok, so all wont pop for Weber's Synergy , so not a common ground, ok
[20:43:40] <anonimasu_> staggerlyTom: it works good/great :)
[20:44:13] <staggerlyTom> looks real nice, but the reason why ACAD isnt a common ground applies to WEBER.
[20:44:48] <staggerlyTom> All interested in a nice cad tho, should look at it. They were nice enuf to give us a 30 day trial.
[20:47:22] <alex_joni> back
[20:47:24] <staggerlyTom> Weber's Synergy system is on the BDI 4-20 cd.
[20:47:30] <jmkasunich> hi alex
[20:47:32] <anonimasu_> wb alex
[20:47:39] <alex_joni> hey John
[20:47:41] <alex_joni> any luck on your fights?
[20:48:04] <jmkasunich> well I'm making progress on my little shm test prog
[20:48:27] <jmkasunich> (basically building the rtapi shmem example, without rtapi, using raw rtai calls)
[20:48:34] <alex_joni> ahh... right
[20:48:49] <jmkasunich> note that the probs with rtapi may be because it's own internal shmem is getting messed up
[20:48:50] <alex_joni> was wondering.. did you try different methods of calls to rt_shm_alloc ?
[20:48:59] <jmkasunich> haven't got that far
[20:49:00] <alex_joni> it's own shm?
[20:49:05] <alex_joni> wot's that?
[20:49:29] <jmkasunich> yeah, there is a shmem inside rtapi, used to hold data about tasks, allocated shmem blocks, sems, etc
[20:49:42] <jmkasunich> its shared so ulapi (user mode) stuff can access it
[20:49:52] <alex_joni> I see..
[20:49:56] <alex_joni> will look at that
[20:50:01] <jmkasunich> the info you see when you do cat /proc/rtapi/* comes from there
[20:50:13] <alex_joni> well.. that's ok
[20:50:13] <alex_joni> always
[20:50:40] <jmkasunich> not from what I saw
[20:50:50] <alex_joni> really?
[20:51:01] <jmkasunich> don't recall the details now, and can't redo it right now
[20:51:13] <alex_joni> from looking at /proc/rtapi/shm I always saw all the modules there
[20:51:19] <alex_joni> but maybe the info should be more...
[20:51:28] <alex_joni> will parallel test today
[20:51:56] <jmkasunich> should list the shmem blocks, and how many kernel and userspace "users" have each block open
[20:52:21] <jmkasunich> I loaded the shmemtast, it showed 1 rt and 0 usr "users:
[20:52:25] <jmkasunich> I loaded the shmemtast, it showed 1 rt and 0 usr "users"
[20:52:40] <jmkasunich> then started shmusr, it showed 1/1
[20:52:58] <jmkasunich> then started another shmusr, it showed 1/2 (and both shmusrs worked)
[20:53:09] <jmkasunich> then I exited from one of the shmusr's
[20:53:53] <alex_joni> and?
[20:53:56] <jmkasunich> the other one kept working, but ISTR the 1/2 got messed up, it should have gone back to 1/1, but instead I think it looked as if the entire block was no longer in use
[20:54:36] <jmkasunich> starting another shmusr just printed zeros instead of the incrementing count (even tho the original shmusr was still inc'ing)
[20:54:44] <alex_joni> right..
[20:54:50] <alex_joni> so probably the rtapi_free call is borked
[20:54:58] <jmkasunich> prob
[20:55:02] <alex_joni> or whatever the mechanism at freeing the shm is involved
[20:55:24] <jmkasunich> I'm gonna give it a try with raw RTAI
[20:55:34] <jmkasunich> if that works, then serious debugging in rtai_rtapi.c
[20:55:43] <alex_joni> ok.. let me know
[20:55:55] <alex_joni> * alex_joni starts reading in rtai_rtapi a bit
[20:55:58] <alex_joni> and ulapi
[20:58:11] <alex_joni> hmm.. one thing jumps to my attention
[20:58:31] <alex_joni> jmkasunich: can you look briefly at smthg?
[20:59:57] <jmkasunich> ok
[21:00:24] <alex_joni> rtai_ulapi.c
[21:00:32] <alex_joni> int rtapi_exit(int module_id)
[21:00:42] <alex_joni> at the end of the function
[21:00:57] <anonimasu_> hm..
[21:00:59] <alex_joni> just before the next function (rtapi_snprintf)
[21:01:02] <anonimasu_> who asked of x.org was better then x-free?
[21:01:03] <alex_joni> hey anders
[21:01:06] <anonimasu_> err xf86
[21:01:12] <anonimasu_> xfree86..
[21:01:52] <alex_joni> there's a rtai_free after the release of the mutex
[21:01:52] <jmkasunich> ok alex, looking at it
[21:02:07] <jmkasunich> yeah
[21:02:14] <jmkasunich> the mutex is stored in the shmem block
[21:02:19] <alex_joni> oh.. silly me, you need to release the mutex too
[21:02:20] <alex_joni> right
[21:02:25] <jmkasunich> (that is the rtapi internal block)
[21:02:38] <alex_joni> right
[21:02:48] <alex_joni> hmm.. is there a mutex example in rtapi?
[21:03:04] <alex_joni> maybe the mutex is failing.. and the operations get screwed
[21:03:40] <jmkasunich> most likely mutex failure is lockup, somebody waiting for a mutex that never gets released
[21:04:14] <alex_joni> no.. what I mean.. maybe the mutex gets released to two modules
[21:04:48] <jmkasunich> not for the kind of testing we're doing... we aren't attempting simultaneous access to anything
[21:05:01] <jmkasunich> these tests would work even without mutexes
[21:05:23] <alex_joni> I know.. I was thinking at the whole problem
[21:05:29] <alex_joni> I know you're testing the shm now.
[21:05:37] <alex_joni> but the problem might not be shm, but mutex
[21:05:45] <jmkasunich> ok, good toi keep a bigger perspective
[21:05:55] <jmkasunich> but I seriously doubt the mutexes
[21:05:56] <alex_joni> I'm not saying you should abandon testing shm
[21:12:55] <fenn> .
[21:24:48] <jmkasunich> rebooting to 2.6.12
[21:34:17] <jmkasunich2> well... it appears to be rtai_free
[21:34:44] <alex_joni> so rt_shm_free might work better?
[21:35:02] <jmkasunich2> doubt it, rtai_free is #defined to call rt_shm_free
[21:35:09] <alex_joni> right
[21:35:10] <jmkasunich2> here's what happened:
[21:35:45] <jmkasunich2> I have a user program that simply rtai_malloc()'s sizeof(int), then spends 30 seconds incrementing that value once per second
[21:35:58] <jmkasunich2> I don't even need to have a kernel side program at all
[21:36:22] <jmkasunich2> if I have two instances of the user program, each one increments, so the number goes up by twos (as seen by each program)
[21:36:36] <jmkasunich2> start one copy of prog, number starts incing
[21:36:48] <jmkasunich2> wait 10 seconds, start second, number increments faster
[21:36:56] <jmkasunich2> when first program ends, number slows down
[21:37:26] <jmkasunich2> start a third, it begins counting from zero, while the 2nd one is still counting by 1, they're not accessing the same memory...
[21:37:35] <jmkasunich2> and when the 2nd one ends, complete lockup
[21:37:52] <jmkasunich2> so basically:
[21:38:30] <jmkasunich2> malloc(), malloc(), free(), malloc(), free() leads to the 3rd malloc not pointing to the same memory as the first two, and the 2nd free locking up
[21:39:00] <jmkasunich2> something tells me the first free is marking the block as completley unused, instead of remembering that there is another prog using it
[21:39:39] <alex_joni> I see
[21:41:00] <jmkasunich2> I think I'll re-write it to use rt_shm_alloc and _free, see if that does the same
[21:41:51] <jmkasunich2> should probably also try the exact same sequence under 2.6.10 again, I'm not sure I did same thing
[21:44:13] <alex_joni> if you change to rt_shm_alloc try fiddling with different alloc's
[21:45:02] <jmkasunich2> instead of USE_VMALLOC?
[21:45:29] <alex_joni> yup
[21:49:50] <robin_sz> meep?
[21:50:00] <alex_joni> indeep
[21:50:16] <jmkasunich2> bo-peep?
[21:50:56] <robin_sz> had her
[21:51:05] <robin_sz> and her persky lamb
[21:51:35] <jmkasunich2> you brits and your livestock... gotta wonder about that
[21:51:53] <robin_sz> so .. what goes on?
[21:52:04] <robin_sz> the TP fixed yet?
[21:52:09] <jmkasunich2> damn... the only shm functions that aren't labeled internal use only are the heap ones
[21:52:27] <jmkasunich2> no, your countryman keeps throwing spanners and disappearing
[21:52:40] <robin_sz> paul_c?
[21:52:43] <jmkasunich2> yep
[21:53:11] <robin_sz> when you say "throwing spanners" ?
[21:53:12] <jmkasunich2> he built a new kernel with 2.6.12 and the bleeding edge of rtai, then when HAL didn't work he posted a bug report at me and disappeared
[21:53:26] <robin_sz> oh. helpful huh?
[21:53:59] <jmkasunich2> a week later I finally have a copy of the kernel to work with (no help from him there), and the problem looks to be internal to RTAI, not even remotely related to HAL
[21:54:25] <robin_sz> why, exactly, did we need a new kernel again?
[21:54:35] <alex_joni> to rock ;)
[21:54:39] <jmkasunich2> livin' on the edge man!
[21:54:47] <robin_sz> err, right.
[21:55:05] <robin_sz> personally, id settle for a working tp, but hey, im weird
[21:56:09] <jmkasunich2> gonna reboot now, want to make sure it still works on the old kernel
[21:57:18] <robin_sz> today was a good day
[21:57:29] <robin_sz> I decided to move the chiller from on top of the offices
[21:57:35] <robin_sz> to near the back door
[21:57:52] <robin_sz> so all the hot air can blow straight out
[21:58:00] <robin_sz> works a treat :)
[21:58:21] <robin_sz> sucks cool air in the front door too
[21:58:22] <alex_joni> nice
[21:58:39] <robin_sz> moving a 1t chiller on your own is fun
[21:59:41] <robin_sz> and constructed a big air duct to catch the hot air from the fans and send it sideways
[22:00:23] <staggerlyTom> i just installed BDI 4-20, uname -r sez 2.6.10-adeos
[22:00:43] <robin_sz> how handy
[22:00:50] <staggerlyTom> and now theres a different problem with scripts/realtime, it doesnt exist
[22:01:19] <robin_sz> no point asking me ... i dont get involved with the BDI stuff
[22:01:21] <alex_joni> staggerlyTom: there's no scripts/realtime on emc1
[22:01:31] <alex_joni> and on the BDI there's a emc1 (kinda=
[22:01:37] <alex_joni> it's a bit modified though
[22:01:47] <staggerlyTom> emc1? why is it emc1, ithought this'd be 2
[22:02:04] <robin_sz> unlikely
[22:02:35] <staggerlyTom> I was just advised tro nstall this to solve the proble, I must've misunderstood. Do I need to load src & build?
[22:02:37] <alex_joni> staggerlyTom: in order to get emc2 follow, http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?BDI-4_Compile_EMC2
[22:02:43] <alex_joni> that should cover it
[22:08:57] <staggerlyTom> thanx alex, doin it now
[22:13:25] <alex_joni> * alex_joni prepares for bed
[22:19:51] <Imperator_> ciao Alex, see you in Stuttgart
[22:22:27] <fenn> take pictures for us! :)
[22:22:47] <fenn> i wanna see your 30 kw hexapod
[22:28:16] <jmkasunich> * jmkasunich is baaaack
[22:28:23] <jmkasunich> (several reboots later)
[22:35:19] <fenn> i'm having this issue with hal not loading into shm
[22:35:35] <jmkasunich> what distro?
[22:35:45] <fenn> i remember the fix has something to do with doing scripts/realtime start instead of just starting hal
[22:35:52] <Yuga> hi all
[22:35:53] <fenn> it's fedora 3
[22:35:57] <fenn> hello
[22:36:21] <jmkasunich> yeah, scripts/realtime loads the RTAI modules (there are about 6 of them - without them you don't have a RTOS)
[22:37:22] <jmkasunich> the chain of dependencies is: adeos which supports the RTOS stuff (rtai_xxx) which supports rtapi (our generic RTOS interface) which supports hal_lib
[22:37:43] <jmkasunich> if you are running rtlinux or something the first couple steps are different
[22:37:51] <fenn> i have these loaded in lsmod: rtai_math, motmod, hal_lib, rtapi, rtai_sem, rtai_shm, rtai_fifos, rtai_up, rtai_hal
[22:38:19] <jmkasunich> if rtapi and hal_lib are loaded, then you should be OK
[22:38:23] <fenn> but then i get RTAPI: ERROR: could not open shared memory
[22:38:28] <jmkasunich> you're not using RTAI-magma are you?
[22:38:35] <fenn> rtai-3.2
[22:38:47] <jmkasunich> hmmm...
[22:38:52] <fenn> it worked before, but now it doesn't
[22:38:56] <fenn> i dont know what happened
[22:39:11] <jmkasunich> 3.1 is known to work, that's on the BDI-4.20
[22:39:35] <jmkasunich> magma is known to not work, I'm writing a bug report for the rtai list now (shared memory problem)
[22:39:36] <fenn> jopingo is having the same problem
[22:39:39] <jmkasunich> 3.2 is unknown
[22:40:04] <jmkasunich> does realtime stop ; realtime start fix it?
[22:41:46] <fenn> emc2# scripts/realtime start
[22:41:47] <fenn> insmod: can't read 'adeos': No such file or directory
[22:41:59] <fenn> scripts/emc.run
[22:41:59] <fenn> Starting emc...
[22:41:59] <fenn> insmod: can't read 'adeos': No such file or directory
[22:41:59] <fenn> insmod: error inserting '/home/blipkowi/emc2/rtlib/rtapi.ko': -1 File exists
[22:41:59] <fenn> insmod: error inserting '/home/blipkowi/emc2/rtlib/hal_lib.ko': -1 File exists
[22:42:00] <fenn> RTAPI: ERROR: could not open shared memory
[22:42:01] <jmkasunich> do you have adeos built into your kernel?
[22:42:02] <fenn> HAL: ERROR: rtapi init failed
[22:42:17] <fenn> well, i thought i did
[22:42:25] <fenn> i dont know how to check
[22:42:26] <jmkasunich> ok, hang on
[22:42:36] <jmkasunich> you are running realtime, then you are running emc.run?
[22:42:43] <fenn> yes
[22:42:43] <jmkasunich> emc.run calls realtime
[22:42:55] <fenn> oh
[22:43:08] <jmkasunich> that explains the "file exists" messages, realtime already loaded the modules, then emc.run called it again to reload them
[22:44:06] <jmkasunich> run realtime stop to clean up whatever mess is laying around
[22:44:14] <jmkasunich> then run realtime start, followed by lsmod
[22:44:31] <fenn> is adeos a module? or is it suposed to be a module and i compiled it in non-standardly?
[22:44:32] <jmkasunich> if hal_lib and rtapi are loaded, then everything else (including adeos) must be there
[22:44:47] <jmkasunich> it can be compiled as a module or as a built-in
[22:44:56] <jmkasunich> the BDIs have it as a module
[22:45:34] <jmkasunich> if you have it built in, you'll get a message when the script attempts to load it, but that's ok,
[22:45:47] <jmkasunich> since it's already there, the other things that depend on it will still load
[22:46:34] <jmkasunich> OTOH, if it's not built in, and you are getting the message because the script can't find the module (maybe it's in a strange place) then nothing else will be able to load
[22:46:51] <fenn> all the rtai modules are loaded
[22:47:07] <jmkasunich> anyway, if everything loads, then just use halcmd and/or /proc/rtapi to take a look around
[22:47:14] <jmkasunich> cat /proc/rtapi/*
[22:47:23] <jmkasunich> bin/halcmd show all
[22:47:49] <fenn> halcmd errors out, could not open shared memory
[22:48:17] <jmkasunich> ok, something is fscked - it seems suspiciously similar to the problem I just found
[22:48:31] <fenn> i dont really know what to look for in /proc/rtapi
[22:48:46] <jmkasunich> it just prints some statistics...
[22:48:55] <fenn> HAL_LIB is the only module loaded
[22:49:02] <jmkasunich> thats expected
[22:49:10] <jmkasunich> there should be one shared memory block listed
[22:49:13] <fenn> shm size is 65500
[22:49:24] <jmkasunich> that;s HALs block
[22:49:45] <jmkasunich> halcmd should be able to connect to it, but it can't... something is busted
[22:49:51] <fenn> Timer status = Stopped
[22:49:51] <fenn> is that normal?
[22:50:07] <jmkasunich> yes, you haven't attemted to start a real time thread yet
[22:50:30] <fenn> how do i turn rtapi debug messages on?
[22:50:40] <jmkasunich> echo 4 >/proc/rtapi/debug
[22:50:55] <fenn> hey look at this
[22:50:55] <jmkasunich> note that the messages mostly go to the kernel log
[22:50:56] <fenn> Jul 17 17:03:32 snacker kernel: ***** WARNING: GLOBAL HEAP NEITHER SHARABLE NOR
[22:50:56] <fenn> USABLE FROM USER SPACE (use the vmalloc option for RTAI malloc) *****
[22:51:05] <jmkasunich> yeah, that happens normally
[22:51:21] <jmkasunich> including on my RTAI 3.1 / 2.6.10 system that works fine
[22:51:43] <jmkasunich> (the code does indeed use the vmalloc option that they are recommending)
[22:52:30] <jmkasunich> btw, a few lines up in the log is probably a line like "RTAI 3.2 over adeos.stuff.more"
[22:52:36] <jmkasunich> that tells you your rtai version
[22:52:51] <fenn> RTAI[hal]: 3.2 mounted over Adeos 2.6r9/x86
[22:53:11] <jmkasunich> 3.1 mounted over Adeos 2.6r9c5/x86. works here
[22:53:21] <jmkasunich> magma mounted over Adeos 2.6r11c2/x86. fails
[22:53:39] <fenn> magma is 3.3 right?
[22:53:54] <jmkasunich> Yours is closer to the working one than the busted one, so I don't know if theyre related or not
[22:54:05] <jmkasunich> I think so (3.3/magma)
[22:54:10] <fenn> i swear i had it working before
[22:54:25] <fenn> i dont remember if it was working after i rebooted though
[22:54:26] <jmkasunich> I wish I could help more
[22:54:40] <jmkasunich> but I have enough trouble keeping up with BDI related problems
[22:54:57] <jmkasunich> there's simply too many variables when you build your own RT kernel
[22:55:10] <jmkasunich> I can send you the test program for the problem I've found
[22:55:16] <Jymmm> jmkasunich come on... get REAL =)
[22:55:19] <jmkasunich> /msg me your email
[22:55:51] <Jymmm> SlickWilly@Whitehouse.gov
[22:56:04] <jmkasunich> * jmkasunich is not in the mood
[22:56:04] <fenn> this is the one with two rtai users, and it counts, removes one user, keeps counting
[22:59:13] <fenn> maybe i'll call it a day
[23:21:43] <robin_sz> heh, now heres a thing ...
[23:22:11] <robin_sz> my wifes sister just topped up the oil in her car ...
[23:22:49] <robin_sz> and it only needed a teeny weeny bit ...
[23:23:19] <robin_sz> seems she put it in the brake fluid resevoir :(
[23:24:55] <jmkasunich> oops
[23:29:32] <jmkasunich> dinner time
[23:29:35] <jmkasunich> jmkasunich is now known as jmk_away
[23:32:35] <Yuga> is any one here awake?
[23:32:40] <robin_sz> no
[23:33:06] <anonimasu_> no
[23:33:07] <anonimasu_> :)(
[23:33:09] <anonimasu_> we are all sleeping
[23:33:14] <Yuga> aaarrrg!
[23:33:15] <Yuga> :P
[23:33:38] <robin_sz> where is country code 0035?
[23:33:38] <Yuga> i am new to the whole cnc thing. and was wondering if u could just help me out with 1 or 2 q's?
[23:33:50] <robin_sz> sure
[23:34:00] <anonimasu_> :)
[23:34:12] <Yuga> i am wanting to cut wood. but i am needing angles cut into it
[23:34:17] <anonimasu_> robin_sz: what's up?
[23:34:20] <Yuga> ./ \
[23:34:30] <robin_sz> rigt ...
[23:34:35] <anonimasu_> I'd use a chamfered mill..
[23:34:36] <Yuga> need the wood cut something like that
[23:34:40] <anonimasu_> that's the quick solution
[23:34:49] <robin_sz> angled cutter
[23:34:53] <anonimasu_> yeah
[23:35:01] <Yuga> how many axces would the cnc machine need to cut that?
[23:35:08] <anonimasu_> 2
[23:35:16] <robin_sz> with an ang;ed cutter, 2
[23:35:16] <anonimasu_> with a manual z
[23:35:24] <anonimasu_> but 3 is perferred for any serious work
[23:35:32] <anonimasu_> I've had 2 and one manual on my machine a while back..
[23:35:38] <anonimasu_> it was so painfully slow to make stuff
[23:35:54] <Yuga> ok... now what exactly is a angled cutter?
[23:36:11] <anonimasu_> a cutter with the edges \/
[23:36:28] <robin_sz> a V cutter
[23:36:52] <Yuga> but what happens if it's a stupid angle like 22.5 degree's?
[23:37:08] <robin_sz> then you buy a stupid angled cutter :)
[23:37:11] <Yuga> i make speaker boxes... and some of the angles are totaly wierd
[23:37:32] <anonimasu_> you can always tilt the cutting area..
[23:37:35] <anonimasu_> and use a straight cutter
[23:37:43] <anonimasu_> or the spindle, but that's slower..
[23:37:56] <Yuga> what about another axis on the machine?
[23:38:03] <Yuga> or wouldnt that solve it?
[23:38:06] <anonimasu_> not really
[23:38:16] <anonimasu_> it's troublesome to generate the toolpaths
[23:38:19] <robin_sz> my friend makes speakers
[23:38:36] <anonimasu_> you are better off using space blocks to machine the angles..
[23:38:38] <robin_sz> its easiest to just hack out the panels on the CNC router
[23:38:51] <anonimasu_> instead of doing multiple passes with a ball cutter
[23:38:57] <robin_sz> weird angles are done on a standard router table
[23:39:23] <anonimasu_> you can make a fixture that allows you to adjust the height
[23:39:47] <Yuga> robin_sz.... how?
[23:40:06] <Yuga> i am guessing it just moves the z axis up while moving the y axis?
[23:40:50] <robin_sz> make a router table with a tilting router, or use an edge planer
[23:41:08] <anonimasu_> you can cut angles like that but it's painstakingly time consuming..
[23:41:21] <Yuga> tilting router <---- wouldnt that be a extra axis?
[23:41:29] <robin_sz> no .. not CNC
[23:41:38] <robin_sz> its not worth trying to CNC it
[23:41:55] <robin_sz> unless you go 5 axis ... and have say, 50K $ to spend
[23:42:19] <robin_sz> just make a standard router tabel witha tilting router
[23:42:24] <robin_sz> manual
[23:42:31] <robin_sz> let the CNC hack the panels out
[23:42:41] <anonimasu_> tilt and cut the angles
[23:42:58] <robin_sz> and then if you need on or two edges with crazy weird angles, pass them through the router table
[23:43:02] <Yuga> ok... so u recon 2 machines would be best for this?
[23:43:02] <robin_sz> * robin_sz nods
[23:43:06] <robin_sz> yeah
[23:43:11] <Yuga> cool
[23:43:14] <anonimasu_> nah, you can use one
[23:43:25] <robin_sz> well, one CNC, one manual router
[23:43:45] <anonimasu_> robin_sz: if hes on a budget that's not really a solution
[23:43:47] <Yuga> realy apresiate the input... so difficult to figure out what is needed when you have actualy never seen one :)
[23:44:16] <robin_sz> anonimasu: more useful and cheaper than trying tilting head on the cnc
[23:44:30] <robin_sz> a manual router table is always handy
[23:44:49] <anonimasu_> robin_sz: yeah, but the more usage on the cnc the better :)
[23:45:02] <robin_sz> shrug
[23:45:18] <robin_sz> well, my mate gearoge does it with a second op on a manual router table
[23:45:22] <anonimasu_> robin_sz: unless he's in production and wants to do it at the same time..
[23:45:23] <Yuga> well was hoping to have the whole thing automated... but hey... i goto do what i goto do :)
[23:45:38] <robin_sz> he makes .. oh I duno, 10,000 cabs a year maybe
[23:46:02] <anonimasu_> well, he probably would know >(
[23:46:06] <anonimasu_> :)
[23:46:10] <robin_sz> yeah
[23:46:26] <robin_sz> actually, hes moved the whole factory to Poland ...
[23:46:30] <robin_sz> cheap labor
[23:46:32] <anonimasu_> I'd use a V type cutter..
[23:46:35] <Yuga> lol
[23:46:44] <anonimasu_> and mill the edges in one setup.. directly..
[23:46:49] <Yuga> robin_sz... live in africa... dont get cheaper labor than here :)
[23:46:53] <anonimasu_> if it was in production..
[23:47:08] <robin_sz> if I had 2 or 3 known angles, and a toolchanger, then yes
[23:47:09] <Yuga> anonimasu... where can i find some v shaped cutters? know a site off hand?
[23:47:14] <anonimasu_> yep
[23:47:22] <anonimasu_> hm, not really I am not into wood routers
[23:47:37] <robin_sz> if I had many weird angles, then I'd get creative :)
[23:47:38] <Yuga> and u robin_sz?
[23:47:42] <robin_sz> UK
[23:47:45] <anonimasu_> yep
[23:48:00] <anonimasu_> he's a laser freak ;)
[23:48:08] <robin_sz> heh
[23:48:10] <Yuga> who? robin_sz?
[23:48:12] <anonimasu_> *grins*
[23:48:14] <anonimasu_> yeah
[23:48:41] <Yuga> i was also realy interested in that till some one told me i would need a 400watt laser to cut the wood :)
[23:49:06] <anonimasu_> :)
[23:49:09] <robin_sz> yeah, I have a ferranti laser that cuts 12mm plywood .. thats 450W
[23:49:14] <Yuga> i think my gf is going to be getting herself a small desktop laser cutter
[23:49:40] <Yuga> robin_sz... freek... so u are telling me i would need something over 450w to cut 18mm ply?
[23:50:39] <robin_sz> 18mm .. hmmm ... 400, 500 would do it I guess... 600 would be a sure thing
[23:50:50] <anonimasu_> * anonimasu_ wonders where les is when you need him
[23:50:59] <robin_sz> playing golf
[23:51:04] <anonimasu_> heh
[23:51:05] <Yuga> i am guessing every one's machines run off ballscrews?
[23:51:16] <anonimasu_> almost some use acme screws
[23:51:21] <robin_sz> and racks
[23:51:26] <anonimasu_> yep..
[23:51:29] <robin_sz> big machines always use racks
[23:51:34] <robin_sz> (almost)
[23:51:54] <Yuga> but dont u get alot of play using gears?
[23:51:58] <robin_sz> no
[23:52:02] <Yuga> i always thought gear's where evil
[23:52:33] <Yuga> robin_sz... so your's is using rack's?
[23:52:34] <robin_sz> helical racks and pinions .. almost zero backlash
[23:52:44] <robin_sz> my commercial machine does, yes
[23:53:06] <robin_sz> gets 0.1mm accuracy
[23:53:42] <Yuga> .1mm arent that great when u consider a ballscrew only has .001mm
[23:53:55] <robin_sz> sure they do
[23:53:59] <anonimasu_> oh, heh considering the size of the machine it's great
[23:54:00] <Yuga> but?
[23:54:02] <Jacky^> hi :)
[23:54:24] <anonimasu_> hello Jacky^
[23:54:35] <Yuga> what machine u ppl using? would just like to take a look at what u's are running
[23:54:36] <Jacky^> hey anonimasu_
[23:54:41] <robin_sz> ballscrews on big machines dont do 0.001mm .. thats tiny ballscrews in tiny actuators
[23:54:54] <robin_sz> and ballscrews wont move fast
[23:55:29] <Yuga> u get big ballscrews... 50mm dia
[23:55:35] <robin_sz> you cant get rapid motion out of ballscrews .. especially long ones .. as they start to flap around
[23:55:42] <anonimasu_> whipping
[23:55:44] <Yuga> cool
[23:55:48] <anonimasu_> whip & snap ;)
[23:55:57] <robin_sz> and wood routers dont need 0.001mm accuracy anyway
[23:56:16] <Yuga> guy's i am not trying to cause shit... i am just trying to find answers to my questions. hence the reason i am acguing abit
[23:56:17] <anonimasu_> Jacky^: how are things going?
[23:56:32] <anonimasu_> Yuga: oh, dont worry about it :9
[23:56:33] <anonimasu_> :)
[23:56:36] <robin_sz> Yuga: well, ballscrews cost about 5 times what rack and pinion costs
[23:56:51] <Yuga> robin_sz... ya.. that's probibly y i thought it was better :)
[23:57:01] <robin_sz> oh it is "better"
[23:57:16] <robin_sz> but ... it might be more accurate than you need
[23:57:29] <robin_sz> and it might have drawbacks that you dont need either
[23:57:33] <robin_sz> like rapid motion
[23:57:45] <anonimasu_> dust + ballscrews dosent work too well..
[23:57:49] <robin_sz> true
[23:57:53] <Yuga> robin_sz... what is considerd rapid motion? 200ipm?
[23:58:03] <robin_sz> no .. thats SLOOOOOOOW
[23:58:10] <robin_sz> 100m/min
[23:58:12] <dave_e> well les wants 1000 ipm
[23:58:24] <anonimasu_> yeah, but he's not like everyone else ;)
[23:58:29] <dave_e> true
[23:58:34] <anonimasu_> that
[23:58:37] <Yuga> ok... so what is the average?
[23:58:37] <anonimasu_> that's pretty insane :D
[23:58:43] <Jacky^> anonimasu_: i'm fighting to compile ffmpeg with x264 support :\
[23:58:46] <robin_sz> 600ipm on routers
[23:58:53] <anonimasu_> Jacky^: good luck
[23:58:59] <Yuga> 600ipm.. shit that's pretty fast
[23:59:00] <Jacky^> :)
[23:59:10] <Yuga> what's the diff's between a Helical Rack and just a plain old rack? and when i say "rack" i arent talking about your gf's :)
[23:59:25] <anonimasu_> helical gears are //// and normal ones are ||||
[23:59:25] <robin_sz> well, you know what helical gears are?
[23:59:38] <anonimasu_> more contact area
[23:59:43] <Yuga> robin_sz... not a clue :)
[23:59:52] <Yuga> ok... so one is ground at a angle?
[23:59:54] <anonimasu_> yeah