*robin_sz prods picnet
<robin_sz>bah
*robin_sz has already started thinking about his next product
<robin_sz>CNC plasma cutters produce 3 things ...
<robin_sz>parts
<robin_sz>scrap
<robin_sz>dust
<robin_sz>parts and scrap are easy to deal with
<robin_sz>dust is the biggy though ... so, its filter time :) ... I'm not so sure how to approach this though ... cyclone first or metal mesh pre-filter then conventional pleated filters and finally an electrostic filter ...
<robin_sz>plasma dust will be real fine, Im not sure a cylone will drop enough out
<asdfqwega>Woo!
<jmkasunich>pretty quiet this morning
<stevestallings2>Yea, I keep thinking it died. Then it did at least once.
<jmkasunich>cradek: are you here?
*paul_c prods the assembled masses...
<jmkasunich>not very ""assembled"" I guess
*paul_c is reading some of the logs from the 10th.
<jmkasunich>yesterday?
<jmkasunich>was pretty quiet, I thought
<paul_c>a bit of crap about what GPL does for a project...
<jmkasunich>oh.. the 10th was friday... didn't see that, can you send me a copy?
<paul_c>most of it was idle chat from the usual faces.
<paul_c>jmkasunich: http://81.100.211.99
<paul_c>Dec-10.log
<jmkasunich>thanks
*jmkasunich skims for the good stuff
<paul_c>BTW... We have someone working on a ""dual screw/servo"" at the realtime code level.
<jmkasunich>you mean martin?
<paul_c>Nope.
<jmkasunich>who?
<paul_c>ISW
<jmkasunich>'oosat?
<jmkasunich>reading the log... I must say in part I agree with robin... certainl critical bits should be LGPL, IMO
<cradek>jmkasunich: yes
<cradek>jmkasunich: but not for long
<jmkasunich>in a mail on Fri or Sat you wrote:
<jmkasunich>EMC2 does not update motion.traj.position when jogging and this causes AXIS to behave differently during jogs
<cradek>right
<jmkasunich>I was trying to hunt that down
<jmkasunich>can't seem to find it - I don't know the user space side too well
<cradek>so it's a bug?
<jmkasunich>dunno yet
<cradek>someone (I forget who) told me it was on purpose
<paul_c>but GPL does not mean having to hand your competetors the code.
<jmkasunich>maybe it was, maybe it wasn't... I can't even find the darned structure right now
<jmkasunich>is it emcStatus->motion.traj.position?
<cradek>ummmm
<jmkasunich>jogs _do_ update with tkemc, so emc2 is updating whatever tkemc uses to drive the display
<jmkasunich>AXIS must be using something else
<cradek>yes, that is probably actual_position
<jmkasunich>to be honest, tracing stuff thru the maze of C++ once it enters user space is beyond me
<jmkasunich>the motion controller updates fields in the emcmotStatus struct
<jmkasunich>how they get to the emcStatus struct is somewhat of a mystery
<jmkasunich>emcmotStatus is the RT/user comms struct, in shared memory
<cradek>err, actualPosition
<cradek>it an EMC_STAT object
<cradek>call it status
<jmkasunich>source file?
<cradek>emc.hh
<cradek>line 2893
<cradek>it contains EMC_MOTION_STAT motion and EMC_IO_STAT io
<cradek>I am talking about status.motion.traj.position and status.motion.traj.actualPosition
<jmkasunich>still looking for it
<cradek>my understanding is this: traj.position is the requested ideal position, and traj.actualPosition is where the machine actually is (this is the one that shows jitter)
<jmkasunich>(I was looking in emc2/.../emc.hh, now trying emc1
<cradek>oops
<cradek>yeah my tree is emc1
<cradek>can you ask tkemc to display the commanded instead of actual position?
<jmkasunich>class EMC_STAT is what you are talking about?
<cradek>yes
*jmkasunich starts up emc
<jmkasunich>2
<cradek>see inside it there is a EMC_MOTION_STAT
<jmkasunich>hmmm... commanded doesn't change during jogs
<cradek>aha!!
<jmkasunich>what I'm trying to do is trace that backwards, back into kernel space (where I actually understand what is going on)
<jmkasunich>and where most of the changes are located
<cradek>I'm glad you can reproduce it without axis
<jmkasunich>the code at emc.hh:2893 is complete gibberish to me - I don't speak C++
<jmkasunich>I have a suspicion about what is going on
<cradek>think of them as structs
<jmkasunich>emc2 does _not_ use the ""trajectory planner"" for jogs (or any other ""free mode"" motion)
<cradek>the EMC_STAT struct contains an EMC_MOTION_STAT struct
<jmkasunich>where are these structs defined?
<cradek>right there where it says class EMC_STAT
<cradek>pretend ""class"" says ""struct""
<jmkasunich>ok, so EMC_STAT contains a TASK_STAT, MOTION_STAT, IO_STAT, and some logging ints...
<cradek>right
*jmkasunich looks for the definition of MOTION_STAT
<jmkasunich>extern.... where?
<cradek>line 1856
<cradek>class EMC_MOTION_STAT
<jmkasunich>got it... that contains a TRAJ_STAT and several AXIS_STAT, plus int debug
<cradek>and class EMC_TRAJ_STAT is line 1732
<jmkasunich>right
<cradek>it contains EmcPose position
<jmkasunich>that actually contains something real (as opposed to nested defs)
<cradek>""current commanded position""
<cradek>haha
<jmkasunich>here is where I did something that IMO simplified the motion controller, but is causing you greif
<jmkasunich>TRAJ is the _coordinated_ mode planner
<jmkasunich>in ""free"" mode (""manual"" for the GUI), the coord mode planner is completely unused
<jmkasunich>so of course the traj structures don't get updated - because the traj planner isn't planning anything
<cradek>but motion.traj.actualPosition *does* get updated
<cradek>otherwise the numbers wouldn't change in the gui
<jmkasunich>we need to map these struct members to members of emcmotStatus (as defined in emc2/src/motion/motion.h)
<jmkasunich>emcmotStatus is the feedback from realtime code
<jmkasunich>I don't know what code copies from emcmotStatus to emcStatus (I think in emc2 it is either usermotintf.c, or taskintf.c)
<cradek>so maybe just another copy is needed?
<jmkasunich>dunno yet
<cradek>arg, I have to run
<jmkasunich>dammit
<jmkasunich>I _hate_ C++
<cradek>me too, and I think even C++ programmers hate it (I am NOT one)
<jmkasunich>I grepped for ""actualPosition"" but can't find where it is copied from the shared memory structure (emcmotStatus)
<jmkasunich>line 2770 of emc.cc?
<jmkasunich>actually 2788 is the line that _might_ be doing the copy, 2770 is the function it is in
<cradek>*       Automatically generated by NML CodeGen Java Applet.
<cradek>whee, java generating c++
<jmkasunich>right
<jmkasunich>WTF is CMS anyway
<jmkasunich>NEFS
<paul_c>Communication Management System
<jmkasunich>so is the function at emc.cc:2770 the one that copies actualPosition from emcmotStatus to emcStatus?  damned if I can figure it out
<cradek>I *think* so
<jmkasunich>but where is it copying _from_? (I think &actualPosition is where it is copying _to_)
<paul_c>jmkasunich: Which version you looking at ?
<jmkasunich>emc1
<paul_c>EMC_TRAJ_STAT::update(*cms) ?
<jmkasunich>yes
<jmkasunich>line 2788 seems to be the line that updates actualPosition, 2787 updates position
<paul_c>That function (and all the others in emc.cc) are purely for NML messaging.
<jmkasunich>well isn't NML messaging how information gets to a GUI?
<paul_c>i.e. any data listed is copied to NML buffers that EMC can not access directly.
*jmkasunich must be thickheaded
<jmkasunich>code in the GUI displays position
<jmkasunich>code in emcmot sets position
<jmkasunich>how does it get from A to B
<jmkasunich>what field in emcmotStatus (shmem) eventually appears on the display
<jmkasunich>I'll be damned if I can trace it
<paul_c>At it's most basic level... NML just copies structFoo from A to B
<jmkasunich>exact same structure layout in both places?
<paul_c>It cares not what the data is, or how it is arranged.
<jmkasunich>but I know for a fact that the struct used by the GUI isn't the same as the shmem struct
<jmkasunich>the shmem one is defined at lines 340-394 of emc1/src/emcmot/emcmot.h
<jmkasunich>it has fields
<jmkasunich>oops
<jmkasunich>it has fields ""EmcPose pos;"" and ""EmcPos actualPos""
<jmkasunich>which I _think_ eventually become emcStatus->motion.traj.position, and emcStatus->motion.traj.actualPosition
<jmkasunich>but it's not a one-to-one structure copy
<jmkasunich>hmmm... I think the emc2 counterparts are:
<jmkasunich>EmcPose pos;  --> EmcPos carte_pos_cmd; /* commanded Cartesean position */
<jmkasunich>EmcPose actualPos;  --> EmcPos carte_pos_fb; /* actual Cartesean position */
<cradek>in emc2/src/emc/tas/taskintf.cc:1299  they are both copied
<jmkasunich>and the emc1 copies as are done at src/emctask/minimilltaskintf.cc:1471-3
<cradek>yay, we found them
<jmkasunich>ok, so now I know what fields in emcmot we're interested in
<jmkasunich>open emc2/src/emc/motion/control.c
<paul_c>emcTrajUpdate is copying data to an EMC_TRAJ_STAT object
<paul_c>which happens to be the same object that the GUI accesses.
<jmkasunich>ok.... that is a later point in the path
<jmkasunich>taskintf copies from the shmem struct to a user space status struct... then the NML stuff moves it to another copy of the same struct for use bye the GUI
<jmkasunich>(I think)
<paul_c>the data structure is all in the EMC_TRAJ_STAT::update(*cms) class
<jmkasunich>the key was discovering that carte_pos_cmd and carte_pos_fb are the fields displayed by the GUI as commanded and actual respectively
<jmkasunich>cradek: emc2/src/emc/motion/control.c:1484 explains how carte_pos_cmd is generated
<jmkasunich>(or should be... maybe I'm not updating it in free mode)
*paul_c disappears for a bit.
<jmkasunich>maybe cradek did too...
<cradek>I'm back now
<jmkasunich>take a look at the comment block at emc2/src/emc/motion/control.c:1484
<cradek>   In free mode, it is either copied from actualPos, or generated
<cradek>     by applying forward kins to (2) or (3).
<cradek>in AXIS it's important to have the jitter-free commanded position for updating the live plot
<cradek>so you can't just copy from actualPos (I think)
<jmkasunich>I need to inspect the code more carefully
<jmkasunich>the preferred approach would be to apply forward kins to 2 or 3
<jmkasunich>but for some machine geometries, there are no forward kins (or no closed form ones - they require iteration to converge on the right answer)
<jmkasunich>for those machines, the ""copy from actual (7)"" would be used
<jmkasunich>for the standard x,y,z machine, the kins should be used
<jmkasunich>anyway, the code that needs checked is in get_pos_cmds... the old code is below the comment block, if 0'ed out
<cradek>well, I'm glad you understand this
<jmkasunich>why does one count of jitter screw up your plot?
<cradek>when stationary, the live plot will add a segment every time it jitters
<jmkasunich>I see
<cradek>(because it's reversing direction)
<jmkasunich>I need to put in some calls to print_pose() to see if carte_pos_cmd is indeed not getting updated during jogs (sure looks that way) and if so, fix it
<cradek>cool
<jmkasunich>would you mind submitting a bug tracker saying that?
<cradek>thanks for digging into this one
<cradek>sure, I'll do it now
<cradek>in tkemc is it called ""commanded position""?
<cradek>(the one that doesn't update)
<jmkasunich>just ""commanded""
<jmkasunich>(there are 6 buttons in a row:
<jmkasunich>relative
<jmkasunich>machine
<jmkasunich>actual
<jmkasunich>commanded
<jmkasunich>joint
<jmkasunich>world
<jmkasunich>at startup, relative, actual, and world are active
<jmkasunich>if you change from world to joint, then the others are forced to machine and actual
<jmkasunich>but in world, you can freely select between actual/comanded and relative/machine
<cradek>ok, done
<jmkasunich>I have some errands to run soon, but I'll try to look into it later today
<cradek>great
<cradek>I might be around (but I doubt I'll be able to help you)
<jmkasunich>s'ok... by getting it down to carte_pos_cmd, we've moved it into an area that I understand
<robin_sz>'ello happy coders
<a70camaro>anybody home?
<robin_sz>sadly not
<a70camaro>quiet today
<robin_sz>the channel is deserted.
<robin_sz>I need another project for christmas
<a70camaro>ive been wiring my project today
<robin_sz>with Big Volts?
<a70camaro>yea , 180 vdc servo amps
<robin_sz>kewl
<robin_sz>how man amps are these beasts?
<a70camaro>low amps , peak is 10 amp each motor
<robin_sz>1.8 kw
<a70camaro>well the motor are only rated to 120v
<robin_sz>so .. 2.2hp max
<robin_sz>1.8hp peak
<robin_sz>then
<robin_sz>big enough though
<a70camaro>1/3 hp each motor
*robin_sz tries that again ...
<robin_sz>120V * 10A
<robin_sz>1200w ...
<robin_sz>1200/746 = ?
<a70camaro>i have it running through a 1500 kva toroidal trnasformer to the servo power supply
<robin_sz>1.6hp
<a70camaro>ive got more than enough power :-)
<robin_sz>yeah :)
<robin_sz>probably more than 1/3hp though ...
<robin_sz>you can get more than that out of a nema 34 stepper
<a70camaro>ive got it all going into a 30X36 enclosure ,if you have ever seen the inside of a Haas controller it is pretty much laid out the same way
<robin_sz>the only Haas stuff ive seen is the PSU on my laser
<robin_sz>and thats very neat
<a70camaro>the computer , the amps , transformer ,I/O boards , vfd and the computer all fit insdide but it is tight
<robin_sz>this is for your mill right?
*robin_sz forgets whose building what these days
<a70camaro>i will be running a lathe and a mill from this controller (not at the same time) :-)
<robin_sz>coo
<robin_sz>running emc for the lathe?
<a70camaro>the lathe is a grizzlt 12X36  and I replaced the single phase motor with a 3 phase so i can have constant feed rates
<robin_sz>vfds are handy
<a70camaro>no i am not runing EMC at the moment , I am using a Galil motion card and Camsoft CNC
<robin_sz>right
<robin_sz>mach2 has some good stuff for lathe work
<robin_sz>the threading stuff is quite qorkable now from what I understand
<robin_sz>workable
<a70camaro>I would have liked to use MAch2 but I cant get over the fact that it still isnt a truley closed loop system
<robin_sz>shrug
<a70camaro>yea I know
<robin_sz>90% of emc installs arent either
<robin_sz>I'd say most people end up using stppers, only about 10% use servos, from my random guess anyway
<a70camaro>I worked with a open loop stepepr mill at work , a old Bridgeport Series 2 , and we lost a bunch of parts
<robin_sz>it happens
<a70camaro>over the year due to loosing steps
<robin_sz>mainly in the Z axis, right?
<a70camaro>nah this machine has problems its all over
<robin_sz>the old bridgeports had a weakness in Z ... if the lube ran a bit low, it just stuck
<a70camaro>probably wouldnt have been a big deal with part loss but we are machining castings
<robin_sz>right
<a70camaro>bar stock no big deal just cut another
<robin_sz>servos are much better in almost all respects
<robin_sz>but, homebuilders usually do them stepper thing.
<robin_sz>back in 10, teatime
<a70camaro>well I got great deals on everything I have ,mainly all Ebay  , probalby saved 50%
<a70camaro>cya
<robin_sz>damn ... I think I have the urge to buy a CNC lathe ...
<robin_sz>dont you just hate it when that happens?
<cradek>if you did, maybe you would put threading in emc
<robin_sz>nah
<robin_sz>I;d buy a working cnc lathe with a controller
*robin_sz looks at a nice tasty Mazak ...
*paul_c is away: making chips
*paul_c is back
<tbl>hey paul
<paul_c>Yo Mike
<paul_c>Yo Ray.
<rayh>Hi Paul
<paul_c>got the mount points in BDI-4 fixed...
<rayh>Good.  Matt said that he had a problem installing on his older computers.
<paul_c>How old ?
<rayh>What directory structure are you using for supermount?
<rayh>These were the boxes that they are shipping now.
<paul_c>Not enabled supermount just yet...
<paul_c>and what problems is Matt having ?
<rayh>Remember that box with the lcd on the side.  That's the one.
<paul_c>ye gads... Vintage hardware !
<rayh>Thought you like that.
*paul_c runs through an install with BDI-4.03 (on a 433MHz board)
<tbl>heys guys
<paul_c>you're back...
<tbl>busy coding
<tbl>been neglecting irc
<tbl>which is nothing new =)
<tbl>asked a few non biased linux dev's about 2.6
<tbl>got some interesting feedback
<tbl><spam>
<tbl>There's a large amount of discussion on this right now.
<tbl>It's my take currently that the 2.4 kernel series is antiquated and a
<tbl>patch disaster. In order to get normal features that you would expect in a
<tbl>2004 OS, and an advanced compile system, you must either patch the shit
<tbl>out of 2.4 (and probably make it unstable) or you can go with 2.6.
<tbl>Right now, no kernel devs want to maintain a stable kernel because ""it's
<tbl>boring."" So they are saying that the distributions should be responsible
<tbl>for a stable kernel. I think this is the worst idea ever. I believe that
<tbl>they will realize this in another month and force a kernel dev to maintain
<tbl>the stable branch.
<tbl>What's happening right now is that 2.6 is being maintained more like an
<tbl>unstable kernel branch, but that doesn't mean that it's not stable. Since
<tbl>2.6.7, the VM has been worked on extensibly. I personally, have had a
<tbl>couple stability issues with 2.6.7. They are extremely rare: I'm running
<tbl>it on 12 machines, 2 crash once a month, the rest run perfectly.
<tbl>I believe the 2.6.10 kernel to be in excellent condition. The only reason
<tbl>I'm not using it is because the grsecurity patch is not available for that
<tbl>version. But you don't need that, right?
<tbl>Basically, I highly recommend the 2.6 kernel, and encourage you to use it.
<tbl>Are the realtime patches available for it?
<tbl>im going to get booted for that haha
<tbl>http://obstinate.org/t/linux.txt for those who don't like the sizing
<tbl>also the 2.6 FS is really really cool
<tbl>its about time that a x86 mainstream unix has REAL journaling
<rayh>Hi Mike.
<rayh>Thanks for that update on kernels.
<rayh>I ran SuSE a bit here with 2.6.7 and it crashed twice.
<sxpert>my fedora core 2 server only crashed because the breakers went live
<tbl>bleh @ those bloated OS's though
<tbl>the only linux's that i would run ""off the iso"" would be like debian or slackware
<tbl>i would just assume do a linux from scratch
<sxpert>gentoo is pretty cool too
<sxpert>(basilcly an automated LFS)
<tbl>what boggles my mind
<tbl>is gentoo has no automated installer
<tbl>to keep the ""un-skilled"" people out
<sxpert>tbl: you have to admit that it works ;D
<tbl>now, i am not exactly unskilled when it comes to linux / unix os's but i don't think i should have to read 50 pages of docs to get an os installed
<tbl>i will never install gentoo
<tbl>i have shells on boxes with it, and it seems neat
<cradek>I installed it once and it was tedious.  I think it's for linux wankers with neon computers.  I don't see any problem with binary packages and they are faster when I have to get on to doing actual work.