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