Back
[00:09:10] <robin_sz> * robin_sz prods picnet
[00:11:43] <robin_sz> bah
[00:17:14] <robin_sz> * robin_sz has already started thinking about his next product
[00:17:52] <robin_sz> CNC plasma cutters produce 3 things ...
[00:17:55] <robin_sz> parts
[00:17:58] <robin_sz> scrap
[00:18:00] <robin_sz> dust
[00:18:11] <robin_sz> parts and scrap are easy to deal with
[00:19:23] <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 ...
[00:20:21] <robin_sz> plasma dust will be real fine, Im not sure a cylone will drop enough out
[00:29:56] <CIA-6> 03Zathras 07BDI build system * 10Babylon Cluster/RELEASE-NOTES: File changed. New revision:1.33
[00:29:59] <CIA-6> 03Zathras 07BDI build system * 10Babylon Cluster/picax.xml: File changed. New revision:1.15
[01:36:14] <CIA-9> 03Zathras 07BDI build system * 10Babylon Cluster/comps.xml: File changed. New revision:1.20
[02:38:47] <asdfqwega> Woo!
[05:36:30] <mjoyce_> mjoyce_ is now known as tbl
[15:26:59] <jmkasunich> pretty quiet this morning
[15:27:41] <stevestallings2> Yea, I keep thinking it died. Then it did at least once.
[16:51:19] <jmkasunich> cradek: are you here?
[16:52:06] <paul_c> * paul_c prods the assembled masses...
[16:59:43] <jmkasunich> not very "assembled" I guess
[17:00:12] <paul_c> * paul_c is reading some of the logs from the 10th.
[17:00:27] <jmkasunich> yesterday?
[17:00:42] <jmkasunich> was pretty quiet, I thought
[17:03:15] <paul_c> a bit of crap about what GPL does for a project...
[17:04:14] <jmkasunich> oh.. the 10th was friday... didn't see that, can you send me a copy?
[17:05:10] <paul_c> most of it was idle chat from the usual faces.
[17:07:29] <paul_c> jmkasunich:
http://81.100.211.99
[17:07:41] <paul_c> Dec-10.log
[17:08:07] <jmkasunich> thanks
[17:08:18] <jmkasunich> * jmkasunich skims for the good stuff
[17:09:51] <paul_c> BTW... We have someone working on a "dual screw/servo" at the realtime code level.
[17:10:02] <jmkasunich> you mean martin?
[17:10:10] <paul_c> Nope.
[17:10:15] <jmkasunich> who?
[17:10:26] <paul_c> ISW
[17:10:37] <jmkasunich> 'oosat?
[17:13:31] <jmkasunich> reading the log... I must say in part I agree with robin... certainl critical bits should be LGPL, IMO
[17:14:02] <cradek> jmkasunich: yes
[17:14:06] <cradek> jmkasunich: but not for long
[17:14:24] <jmkasunich> in a mail on Fri or Sat you wrote:
[17:14:35] <jmkasunich> EMC2 does not update motion.traj.position when jogging and this causes AXIS to behave differently during jogs
[17:14:46] <cradek> right
[17:14:49] <jmkasunich> I was trying to hunt that down
[17:15:05] <jmkasunich> can't seem to find it - I don't know the user space side too well
[17:15:10] <cradek> so it's a bug?
[17:15:15] <jmkasunich> dunno yet
[17:15:16] <cradek> someone (I forget who) told me it was on purpose
[17:15:18] <paul_c> but GPL does not mean having to hand your competetors the code.
[17:16:00] <jmkasunich> maybe it was, maybe it wasn't... I can't even find the darned structure right now
[17:16:30] <jmkasunich> is it emcStatus->motion.traj.position?
[17:17:44] <cradek> ummmm
[17:17:55] <jmkasunich> jogs _do_ update with tkemc, so emc2 is updating whatever tkemc uses to drive the display
[17:18:01] <jmkasunich> AXIS must be using something else
[17:18:07] <cradek> yes, that is probably actual_position
[17:18:31] <jmkasunich> to be honest, tracing stuff thru the maze of C++ once it enters user space is beyond me
[17:18:54] <jmkasunich> the motion controller updates fields in the emcmotStatus struct
[17:19:05] <jmkasunich> how they get to the emcStatus struct is somewhat of a mystery
[17:19:22] <jmkasunich> emcmotStatus is the RT/user comms struct, in shared memory
[17:19:55] <cradek> err, actualPosition
[17:20:42] <cradek> it an EMC_STAT object
[17:20:45] <cradek> call it status
[17:20:55] <jmkasunich> source file?
[17:21:14] <cradek> emc.hh
[17:21:41] <cradek> line 2893
[17:21:59] <cradek> it contains EMC_MOTION_STAT motion and EMC_IO_STAT io
[17:22:37] <cradek> I am talking about status.motion.traj.position and status.motion.traj.actualPosition
[17:23:17] <jmkasunich> still looking for it
[17:23:19] <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)
[17:23:35] <jmkasunich> (I was looking in emc2/.../emc.hh, now trying emc1
[17:23:41] <cradek> oops
[17:23:49] <cradek> yeah my tree is emc1
[17:24:59] <cradek> can you ask tkemc to display the commanded instead of actual position?
[17:25:20] <jmkasunich> class EMC_STAT is what you are talking about?
[17:25:24] <cradek> yes
[17:25:35] <jmkasunich> * jmkasunich starts up emc
[17:25:37] <jmkasunich> 2
[17:25:37] <cradek> see inside it there is a EMC_MOTION_STAT
[17:27:09] <jmkasunich> hmmm... commanded doesn't change during jogs
[17:27:18] <cradek> aha!!
[17:27:47] <jmkasunich> what I'm trying to do is trace that backwards, back into kernel space (where I actually understand what is going on)
[17:28:01] <jmkasunich> and where most of the changes are located
[17:28:28] <cradek> I'm glad you can reproduce it without axis
[17:28:58] <jmkasunich> the code at emc.hh:2893 is complete gibberish to me - I don't speak C++
[17:29:18] <jmkasunich> I have a suspicion about what is going on
[17:29:27] <cradek> think of them as structs
[17:29:43] <jmkasunich> emc2 does _not_ use the "trajectory planner" for jogs (or any other "free mode" motion)
[17:29:44] <cradek> the EMC_STAT struct contains an EMC_MOTION_STAT struct
[17:30:00] <jmkasunich> where are these structs defined?
[17:30:14] <cradek> right there where it says class EMC_STAT
[17:30:24] <cradek> pretend "class" says "struct"
[17:31:09] <jmkasunich> ok, so EMC_STAT contains a TASK_STAT, MOTION_STAT, IO_STAT, and some logging ints...
[17:31:15] <cradek> right
[17:31:19] <jmkasunich> * jmkasunich looks for the definition of MOTION_STAT
[17:31:31] <jmkasunich> extern.... where?
[17:32:06] <cradek> line 1856
[17:32:20] <cradek> class EMC_MOTION_STAT
[17:32:53] <jmkasunich> got it... that contains a TRAJ_STAT and several AXIS_STAT, plus int debug
[17:33:26] <cradek> and class EMC_TRAJ_STAT is line 1732
[17:33:29] <jmkasunich> right
[17:33:42] <cradek> it contains EmcPose position
[17:33:45] <jmkasunich> that actually contains something real (as opposed to nested defs)
[17:33:47] <cradek> "current commanded position"
[17:33:51] <cradek> haha
[17:34:29] <jmkasunich> here is where I did something that IMO simplified the motion controller, but is causing you greif
[17:34:41] <jmkasunich> TRAJ is the _coordinated_ mode planner
[17:35:21] <jmkasunich> in "free" mode ("manual" for the GUI), the coord mode planner is completely unused
[17:35:54] <jmkasunich> so of course the traj structures don't get updated - because the traj planner isn't planning anything
[17:36:34] <cradek> but motion.traj.actualPosition *does* get updated
[17:36:44] <cradek> otherwise the numbers wouldn't change in the gui
[17:37:21] <jmkasunich> we need to map these struct members to members of emcmotStatus (as defined in emc2/src/motion/motion.h)
[17:37:41] <jmkasunich> emcmotStatus is the feedback from realtime code
[17:38:14] <jmkasunich> I don't know what code copies from emcmotStatus to emcStatus (I think in emc2 it is either usermotintf.c, or taskintf.c)
[17:38:47] <cradek> so maybe just another copy is needed?
[17:38:54] <jmkasunich> dunno yet
[17:39:19] <cradek> arg, I have to run
[17:39:26] <jmkasunich> dammit
[17:39:42] <jmkasunich> I _hate_ C++
[17:40:04] <cradek> me too, and I think even C++ programmers hate it (I am NOT one)
[17:41:29] <jmkasunich> I grepped for "actualPosition" but can't find where it is copied from the shared memory structure (emcmotStatus)
[17:42:09] <jmkasunich> line 2770 of emc.cc?
[17:42:51] <jmkasunich> actually 2788 is the line that _might_ be doing the copy, 2770 is the function it is in
[17:43:23] <cradek> * Automatically generated by NML CodeGen Java Applet.
[17:43:29] <cradek> whee, java generating c++
[17:43:30] <jmkasunich> right
[17:43:36] <jmkasunich> WTF is CMS anyway
[17:43:56] <jmkasunich> NEFS
[17:45:04] <paul_c> Communication Management System
[17:45:56] <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
[17:46:49] <cradek> I *think* so
[17:47:34] <jmkasunich> but where is it copying _from_? (I think &actualPosition is where it is copying _to_)
[17:48:30] <paul_c> jmkasunich: Which version you looking at ?
[17:48:34] <jmkasunich> emc1
[17:49:06] <paul_c> EMC_TRAJ_STAT::update(*cms) ?
[17:49:11] <jmkasunich> yes
[17:49:43] <jmkasunich> line 2788 seems to be the line that updates actualPosition, 2787 updates position
[17:49:56] <paul_c> That function (and all the others in emc.cc) are purely for NML messaging.
[17:50:24] <jmkasunich> well isn't NML messaging how information gets to a GUI?
[17:50:58] <paul_c> i.e. any data listed is copied to NML buffers that EMC can not access directly.
[17:51:21] <jmkasunich> * jmkasunich must be thickheaded
[17:51:29] <jmkasunich> code in the GUI displays position
[17:51:41] <jmkasunich> code in emcmot sets position
[17:51:47] <jmkasunich> how does it get from A to B
[17:52:10] <jmkasunich> what field in emcmotStatus (shmem) eventually appears on the display
[17:52:17] <jmkasunich> I'll be damned if I can trace it
[17:53:01] <paul_c> At it's most basic level... NML just copies structFoo from A to B
[17:53:18] <jmkasunich> exact same structure layout in both places?
[17:53:20] <paul_c> It cares not what the data is, or how it is arranged.
[17:54:15] <jmkasunich> but I know for a fact that the struct used by the GUI isn't the same as the shmem struct
[17:55:28] <jmkasunich> the shmem one is defined at lines 340-394 of emc1/src/emcmot/emcmot.h
[17:56:15] <jmkasunich> it has fields
[17:56:18] <jmkasunich> oops
[17:56:39] <jmkasunich> it has fields "EmcPose pos;" and "EmcPos actualPos"
[17:57:18] <jmkasunich> which I _think_ eventually become emcStatus->motion.traj.position, and emcStatus->motion.traj.actualPosition
[17:57:25] <jmkasunich> but it's not a one-to-one structure copy
[18:00:49] <jmkasunich> hmmm... I think the emc2 counterparts are:
[18:01:35] <jmkasunich> EmcPose pos; --> EmcPos carte_pos_cmd; /* commanded Cartesean position */
[18:01:57] <jmkasunich> EmcPose actualPos; --> EmcPos carte_pos_fb; /* actual Cartesean position */
[18:03:32] <cradek> in emc2/src/emc/tas/taskintf.cc:1299 they are both copied
[18:04:26] <jmkasunich> and the emc1 copies as are done at src/emctask/minimilltaskintf.cc:1471-3
[18:04:57] <cradek> yay, we found them
[18:05:19] <jmkasunich> ok, so now I know what fields in emcmot we're interested in
[18:05:42] <jmkasunich> open emc2/src/emc/motion/control.c
[18:06:34] <paul_c> emcTrajUpdate is copying data to an EMC_TRAJ_STAT object
[18:07:09] <paul_c> which happens to be the same object that the GUI accesses.
[18:07:29] <jmkasunich> ok.... that is a later point in the path
[18:08:11] <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
[18:08:14] <jmkasunich> (I think)
[18:08:24] <paul_c> the data structure is all in the EMC_TRAJ_STAT::update(*cms) class
[18:08:48] <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
[18:10:41] <jmkasunich> cradek: emc2/src/emc/motion/control.c:1484 explains how carte_pos_cmd is generated
[18:11:00] <jmkasunich> (or should be... maybe I'm not updating it in free mode)
[18:14:20] <paul_c> * paul_c disappears for a bit.
[18:14:33] <jmkasunich> maybe cradek did too...
[18:27:02] <cradek> I'm back now
[18:27:46] <jmkasunich> take a look at the comment block at emc2/src/emc/motion/control.c:1484
[18:30:01] <cradek> In free mode, it is either copied from actualPos, or generated
[18:30:01] <cradek> by applying forward kins to (2) or (3).
[18:30:41] <cradek> in AXIS it's important to have the jitter-free commanded position for updating the live plot
[18:30:51] <cradek> so you can't just copy from actualPos (I think)
[18:32:49] <jmkasunich> I need to inspect the code more carefully
[18:33:06] <jmkasunich> the preferred approach would be to apply forward kins to 2 or 3
[18:33:54] <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)
[18:34:14] <jmkasunich> for those machines, the "copy from actual (7)" would be used
[18:34:37] <jmkasunich> for the standard x,y,z machine, the kins should be used
[18:35:18] <jmkasunich> anyway, the code that needs checked is in get_pos_cmds... the old code is below the comment block, if 0'ed out
[18:36:47] <cradek> well, I'm glad you understand this
[18:37:25] <jmkasunich> why does one count of jitter screw up your plot?
[18:37:47] <cradek> when stationary, the live plot will add a segment every time it jitters
[18:37:57] <jmkasunich> I see
[18:38:09] <cradek> (because it's reversing direction)
[18:39:19] <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
[18:39:46] <cradek> cool
[18:40:04] <jmkasunich> would you mind submitting a bug tracker saying that?
[18:40:08] <cradek> thanks for digging into this one
[18:40:17] <cradek> sure, I'll do it now
[18:40:31] <cradek> in tkemc is it called "commanded position"?
[18:40:38] <cradek> (the one that doesn't update)
[18:40:57] <jmkasunich> just "commanded"
[18:41:09] <jmkasunich> (there are 6 buttons in a row:
[18:41:13] <jmkasunich> relative
[18:41:14] <jmkasunich> machine
[18:41:16] <jmkasunich> actual
[18:41:18] <jmkasunich> commanded
[18:41:20] <jmkasunich> joint
[18:41:22] <jmkasunich> world
[18:42:12] <jmkasunich> at startup, relative, actual, and world are active
[18:42:44] <jmkasunich> if you change from world to joint, then the others are forced to machine and actual
[18:43:15] <jmkasunich> but in world, you can freely select between actual/comanded and relative/machine
[18:45:09] <cradek> ok, done
[18:47:05] <jmkasunich> I have some errands to run soon, but I'll try to look into it later today
[18:47:10] <cradek> great
[18:47:19] <cradek> I might be around (but I doubt I'll be able to help you)
[18:47:53] <jmkasunich> s'ok... by getting it down to carte_pos_cmd, we've moved it into an area that I understand
[20:32:51] <CIA-3> 03Zathras 07BDI build system * 10Babylon Cluster/Make.rules: File changed. New revision:Makefile
[20:32:59] <CIA-3> 03Zathras 07BDI build system * 10Babylon Cluster/Make.rules: File changed. New revision:configure
[20:38:34] <CIA-3> 03paul_c 07pc_2_6_test * 10emc2/ (10 files in 2 dirs): Move make and friends to src and leave the top level dir clear.
[21:43:00] <CIA-3> 03paul_c 07pc_2_6_test * 10emc2/ (7 files in 5 dirs): Make an attempt at merging changes in HEAD back into branch before progressing with the 2.6 kbuild.
[21:43:17] <CIA-3> 03paul_c 07pc_2_6_test * 10emc2/src/rtapi/ (Makefile mathstubs.c rtapi_common.h): Make an attempt at merging changes in HEAD back into branch before progressing with the 2.6 kbuild.
[23:52:42] <robin_sz> 'ello happy coders