Back
[01:19:52] <jmkasunich> quiet tonight
[03:10:12] <SWP_Away> cradek, are youthere
[03:10:15] <SWP_Away> ?
[03:10:30] <cradek> yes
[03:10:31] <SWP_Away> SWP_Away is now known as SWPadnos
[03:10:44] <SWPadnos> I just looked at the TP change you made
[03:10:55] <SWPadnos> in the context of the commit mail, not in the TP
[03:10:55] <cradek> uh-oh
[03:10:57] <SWPadnos> heh
[03:11:04] <cradek> which one?
[03:11:07] <cradek> there have been so many
[03:11:09] <SWPadnos> are dx et al guaranteed to be positive?
[03:11:14] <SWPadnos> the lates
[03:11:16] <SWPadnos> t
[03:11:21] <cradek> yes, look up and see the fabs()
[03:11:32] <SWPadnos> ok
[03:11:46] <cradek> let me check again to make sure, but I think there are fabs everywhere they are needed
[03:11:48] <SWPadnos> so why sqrt (2dx)?
[03:12:10] <SWPadnos> (separate question)
[03:12:23] <cradek> d=at^2/2 => t=sqrt(2d/a)
[03:12:42] <SWPadnos> ok, it's accel there. of course
[03:13:03] <cradek> this means I need to add comments
[03:13:16] <SWPadnos> well, there may be other stuff around
[03:13:26] <SWPadnos> as I said, this was from reading hte diff, not the resulting code
[03:13:47] <cradek> dx = fabs(x - canonEndPoint.x);
[03:13:48] <cradek> dy = fabs(y - canonEndPoint.y);
[03:13:48] <cradek> ...
[03:13:59] <SWPadnos> ok
[03:14:15] <SWPadnos> I'm not sure how this can be tested without actual hardware
[03:14:17] <cradek> thanks for checking it though
[03:14:24] <SWPadnos> looking at it must make the head hurt (a lot)
[03:14:36] <cradek> use stepper without headroom, it's a great test
[03:14:55] <cradek> any constraint violation immediately triggers a following error
[03:15:25] <SWPadnos> ok, with suitably lowered FERROR, presumably
[03:15:46] <cradek> yes, it should be pretty low
[03:16:06] <SWPadnos> like 2 steps or thereabouts, if you really want to be paranoid
[03:16:30] <cradek> jepler started putting rotary support in axis - it's cool, the cone rotates
[03:16:37] <SWPadnos> neat!
[03:17:22] <SWPadnos> I guess there would need to be a separate mode for rotary tables
[03:17:41] <SWPadnos> something like rotating the image, with "shadow axes"
[03:17:55] <cradek> yeah, it's only going to be right for one machine (A axis parallel to X) without hacking
[03:18:25] <SWPadnos> A is defined as parallel to X, so that may not be an issue
[03:18:37] <SWPadnos> if the naming and ordering works (which it may not)
[03:18:50] <cradek> yeah, that's the only rotary setup I've ever used
[03:19:32] <SWPadnos> the other popular one would be a pivoting head, I think
[03:27:43] <SWPadnos> one paranoid question: is it guaranteed that the axis max_accels are positive?
[03:27:55] <jepler> what would a negative value mean?
[03:28:20] <SWPadnos> I'm not sure, but it would result in a sqrt(negative) in this code
[03:28:24] <SWPadnos> hence the paranois
[03:28:26] <jepler> well don't do that then
[03:28:30] <SWPadnos> paranoia
[03:28:33] <SWPadnos> I agree
[03:29:14] <SWPadnos> ok. it looks like it isn't forced positive in iniaxis.cc
[03:31:12] <SWPadnos> ah, but it is set to 0 if negative, in emcAxisSetMaxAcceleration (phew ;) )
[03:31:30] <cradek> * cradek rolls his eyes
[03:31:33] <SWPadnos> heh
[03:31:53] <SWPadnos> sorry - used to embedded programming, you look for anything that can screw up your otherwise perfect code
[03:33:02] <SWPadnos> (of course, 0 would cause divide-by-0 erros, so it's not perfectly safe)
[03:34:11] <jepler> it's so weird to see the cone change orientation!
[03:34:22] <SWPadnos> that sounds really cool to me
[03:34:23] <cradek> I understand defensiveness but I can't imagine writing one extra line of code in order to let someone set their accels to zero and still have emc work
[03:34:40] <SWPadnos> nope - I'm not planning on committing a change there
[03:34:44] <jepler> it got through 187 lines of G[12] XYZA and G[34]XYZ torture
[03:34:45] <cradek> I think, clearly, it shouldn't work
[03:34:48] <jepler> er, G[01]XYZA
[03:34:52] <jepler> and G[23]XYZ
[03:34:54] <cradek> jepler: yay
[03:34:58] <SWPadnos> great!
[03:35:27] <SWPadnos> all we need now is for the tool shape to be dependent on the tooltable settings (length and diameter)
[03:35:33] <SWPadnos> * SWPadnos ducks
[03:35:35] <cradek> I'm shocked by how many things have been completely wrong all along
[03:35:53] <SWPadnos> it is pretty amazing
[03:36:02] <SWPadnos> that nobody seemed to notice
[03:36:23] <jepler> oh and that was mostly with 900% FO
[03:36:42] <SWPadnos> I guess there haven't been many non-cartesian machines, outside of academia (where they expect to do weird stuff on their own)
[03:37:04] <cradek> SWPadnos: they noticed, they just set their hal to allow 2.5x the accels they asked for
[03:37:16] <cradek> SWPadnos: then it worked almost all the time :-/
[03:37:19] <SWPadnos> I'm thinking in emc1.x
[03:37:28] <SWPadnos> since the code should be very similar
[03:37:43] <cradek> in emc1, there were virtually no checks of the output, so you just got wrong vel/accels.
[03:38:12] <jepler> which meant stalls for steppers?
[03:38:15] <SWPadnos> yep - the headroom was in the reduced software limits
[03:38:37] <SWPadnos> no, people would just use 80% of the real capability
[03:38:43] <SWPadnos> the headroom was in the machine
[03:40:21] <cradek> jepler: I fixed at least one terrible problem in emc1 that caused stalls for me (helixes)
[03:40:27] <cradek> oh and offsets
[03:40:30] <cradek> so yeah, stalls
[03:40:41] <cradek> ooh, I haven't tested offsets
[03:41:10] <jepler> I'm shocked and amazed that the tp could even know about offsets
[03:41:28] <cradek> no, it's task
[03:41:49] <SWPadnos> oh, that's good for EDM reversals
[03:42:22] <SWPadnos> but not whole program reverse
[03:42:57] <jepler> I don't get the connection between offsets & reversals
[03:43:42] <SWPadnos> sorry - if the tool offsets are already in the moves the TP sees, then no special notice has to be taken of offset modes or values for reversals
[03:43:51] <jepler> oh
[03:43:52] <SWPadnos> normally, you'd have to switch offset side
[03:44:20] <jepler> It's not how the rs274ngc interpreter works, but in my view stuff like units and offsets should be dispensed with as early as possible
[03:44:57] <SWPadnos> either that, or every communication carries all three (coordinates, units, and offsets)
[03:45:58] <jepler> 462 more lines of XYZA torture passed .. goodnight
[03:46:19] <cradek> goodnight
[03:46:23] <SWPadnos> night
[03:49:18] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/torture-xyza.png
[03:49:50] <SWPadnos> heh, now make the path look like a hotwheels track, including orientation ;)
[03:50:13] <SWPadnos> that's one seriously screwed up toolpath
[04:03:41] <SWPadnos> or are you looking for the other one?
[04:03:55] <SWPadnos> (ie, the DreamHost site)
[05:39:47] <SWPadnos> SWPadnos is now known as SWP_Away
[16:59:55] <SWPadnos> one minor question, spawned by Eric Johnson's email to the user list
[17:00:02] <alex_joni> shoot
[17:00:22] <SWPadnos> it probably doesn't matter much, but shouldn't hte average servo-thread look like this:
[17:00:26] <SWPadnos> all read functions
[17:00:30] <SWPadnos> the two motion functions
[17:00:34] <SWPadnos> the pid calcs
[17:00:37] <SWPadnos> all output functions
[17:00:45] <alex_joni> yeah.. that's about it
[17:00:57] <alex_joni> I see.. capture-pos -1
[17:00:57] <SWPadnos> ok, because the default configs have PID before motion
[17:00:59] <alex_joni> right?
[17:01:23] <alex_joni> and capture at the beginning.. not at almost end
[17:01:24] <SWPadnos> that's one thing, plus he didn't mention that he added pid.x.do-calcs to the threads ;)
[17:01:39] <alex_joni> he shouldn't do that.. that's in core_servo.hal afaik
[17:02:02] <SWPadnos> I've got an email pointing that out, and was listing how I thought the thread should look
[17:02:08] <SWPadnos> if he uses core-servo
[17:02:40] <SWPadnos> I note that univstep doesn't, it has its own univstep_load.hal file
[17:02:52] <alex_joni> I'm looking at his full config dir now
[17:03:21] <alex_joni> HALFILE = ../common/core_servo.hal
[17:03:21] <alex_joni> HALFILE = vti_motion.hal
[17:03:21] <alex_joni> HALFILE = vti_io.hal
[17:03:37] <SWPadnos> ah, OK.
[17:04:23] <SWPadnos> the pid calcs should be added at position 3, not 1
[17:04:40] <SWPadnos> so that motion-command-handler and motion-controller are before them
[17:10:57] <alex_joni> SWPadnos: how so?
[17:11:31] <alex_joni> I see the pid.x.do-pid-calcs are the first one in core_servo
[17:12:04] <alex_joni> and the order core_servo, motion, io is in all the drivers
[17:12:10] <alex_joni> motenc, m5i20, stg, ..
[17:15:43] <alex_joni> SWPadnos: think I found the problem for Eric
[17:15:56] <alex_joni> P = 6.0
[17:15:56] <alex_joni> I = 0.000
[17:15:57] <alex_joni> D = 64.000
[17:16:04] <alex_joni> that's awfull small P there
[17:16:12] <alex_joni> that's the X axis of his ini
[17:17:40] <SWPadnos> what about FF1?
[17:18:00] <alex_joni> 0
[17:18:12] <SWPadnos> that should be 1, I think
[17:18:16] <alex_joni> FF0 = 0.000
[17:18:16] <alex_joni> FF1 = 0.000
[17:18:16] <alex_joni> BIAS = 0.000
[17:18:26] <alex_joni> SWPadnos: not necessarely
[17:18:31] <alex_joni> you can tune only using PID
[17:18:34] <SWPadnos> for velocity mode
[17:18:42] <alex_joni> but with such a small P, you'll get ferrors right away
[17:18:46] <SWPadnos> it helps a lot, I gather
[17:18:52] <alex_joni> it'll be too mushy (soft)
[17:19:03] <alex_joni> oscilating all over the place probably
[17:19:17] <SWPadnos> yep
[17:20:11] <alex_joni> I'm going to add his configs to CVS
[17:20:21] <alex_joni> use some "sane" PID values
[17:20:42] <alex_joni> 100,0,0...
[17:21:26] <SWPadnos> good plan
[17:55:51] <alex_joni> done ;)
[17:58:01] <SWPadnos> I see that
[17:58:15] <SWPadnos> looks like the commit emailer is being efficient today
[18:00:27] <alex_joni> SWPadnos: I'd appreciate you flying over those files
[18:00:35] <alex_joni> just a quick glance should be enough ;)
[18:00:37] <SWPadnos> who, me?
[18:00:54] <alex_joni> reading them might be too much to ask of you :P
[18:01:01] <SWPadnos> sorry - was working on my "get-axis" script ;)
[18:01:43] <alex_joni> hehehe
[18:01:58] <SWPadnos> I was just figuring out how to tell what the directory name will be when it's untarred
[18:02:19] <SWPadnos> tar tjf axisblahblah | head -1 does it nicely
[18:02:35] <alex_joni> heh
[18:03:04] <alex_joni> ok, I'm starting a hexapod on emc2 ;)
[18:03:16] <SWPadnos> uh-oh
[18:03:21] <alex_joni> I've had it with people trying and failing to do that
[18:03:48] <SWPadnos> do you think that Bostjan just didn't home before switching modes?
[18:04:02] <alex_joni> I think he might be helpless
[18:04:16] <SWPadnos> heh, could be
[18:04:28] <alex_joni> not wanting to say clueless
[18:05:21] <SWPadnos> well, he has a lot of help
[18:07:25] <SWPadnos> damn. I thought it was `command` to get the text output of a command into a script
[18:07:46] <SWPadnos> like AXISPATH = `tar tjf axis | head -1`
[18:12:00] <alex_joni> wonder if this is a bad idea?
[18:12:22] <alex_joni> I aded a variable called KINEMATICS to Makefile.inc
[18:12:46] <alex_joni> so the user can specify trivkins, genhexkins, or whatever
[18:12:58] <SWPadnos> that would be really great, if you're thinking of having a configure-time (or make-time) option
[18:13:04] <SWPadnos> even better would be a run-time option
[18:13:13] <SWPadnos> like separate motion-controllers or something
[18:13:28] <alex_joni> for now it's the user who can comment out genhexkins, and comment trivkins
[18:13:40] <SWPadnos> heh
[18:13:59] <alex_joni> I simply hated doubling the whole motmod dependencies, just because one of them is differnet
[18:14:00] <SWPadnos> it doesn't have top be too easy yet
[18:14:03] <SWPadnos> yes
[18:14:15] <alex_joni> and adding a configure option is dumb too
[18:14:21] <alex_joni> not really the place for that
[18:14:23] <SWPadnos> it would be optimal to have a separate module that does the kins only
[18:14:33] <alex_joni> sub-optimal
[18:14:37] <alex_joni> just ask paul ;)
[18:14:51] <alex_joni> LOL
[18:14:52] <SWPadnos> mr "floats are non-atomic"? ;)
[18:15:04] <alex_joni> mr "those shitty little modules"
[18:15:15] <SWPadnos> heh. Mr. Monolithic
[18:15:23] <SWPadnos> like Linus, I guess
[18:15:37] <alex_joni> that'll be the day
[18:15:43] <alex_joni> when you can compare the two
[18:15:47] <SWPadnos> heh
[18:15:53] <alex_joni> that's blasphemie
[18:15:54] <alex_joni> ROFL
[18:16:06] <SWPadnos> well, they both write Linux code, and neither one of them is American :)
[18:16:25] <alex_joni> I fit in that description too :P
[18:16:50] <SWPadnos> there you go, you're just like Paul
[18:16:53] <SWPadnos> oops, I mean Linus
[18:16:58] <alex_joni> fsck off
[18:17:00] <alex_joni> :P
[18:17:03] <SWPadnos> heh
[18:17:12] <alex_joni> oops.. that was a typo
[18:17:25] <alex_joni> it's just like the keys are right next to each other
[18:17:33] <alex_joni> lol
[18:17:51] <SWPadnos> the fsck macro-key
[18:18:06] <alex_joni> alt-Fs
[18:20:05] <SWPadnos> that would be a perfect use for the Optimus keyboard
[18:24:06] <SWPadnos> damned spaces
[18:24:20] <SWPadnos> AXISPATH = `command` doesn't work (of course)
[18:24:26] <SWPadnos> but AXISPATH=`command` does
[18:24:38] <alex_joni> yes, thought you knew that
[18:24:55] <SWPadnos> I did, but shell scripting isn't exactly my best language ;)
[18:24:56] <alex_joni> :-(
[18:37:46] <alex_joni> oh, fsck it..
[18:37:54] <alex_joni> just found a bug in tkemc
[18:38:07] <alex_joni> thought I nailed that one ages ago, but didn't test on 6 axes :)
[18:45:24] <alex_joni> what's the write/print command in tcl again?
[18:45:41] <SWPadnos> printf?
[18:45:48] <alex_joni> in tcl?
[18:45:51] <alex_joni> don't think so
[18:46:00] <SWPadnos> or print
[18:46:07] <alex_joni> print
[18:47:38] <alex_joni> puts even
[18:53:26] <alex_joni> aaargh.. I hate tcl
[18:53:41] <alex_joni> SWPadnos: can you look at something and tell me if I'm completely bonkers now?
[18:53:51] <SWPadnos> possibly ;)
[18:53:58] <alex_joni> tkemc.tcl
[18:54:03] <alex_joni> around line 1600
[18:54:14] <SWPadnos> one sec
[18:54:23] <alex_joni> 1556 over here
[18:54:30] <alex_joni> set minusAxis -1
[18:55:21] <SWPadnos> in proc minusDone?
[18:55:27] <alex_joni> just before
[18:55:30] <alex_joni> the idea is this:
[18:55:45] <alex_joni> minusAxis holds the active axis which gets jogged with the minux key
[18:55:56] <alex_joni> -/= jog the active axis
[18:56:07] <alex_joni> which you can select with the mouse or whatever
[18:56:18] <alex_joni> can be XYZABC or whatever
[18:56:24] <alex_joni> now, the problem
[18:56:25] <SWPadnos> and "-1" means no axis selected
[18:56:28] <alex_joni> yup
[18:56:43] <alex_joni> after the key gets released I want to reset it to -1
[18:56:49] <alex_joni> but that doesn't happen
[18:57:25] <SWPadnos> hmmm
[18:57:32] <SWPadnos> that should be in minusup, I think
[18:57:50] <SWPadnos> which it is
[18:58:07] <alex_joni> minusDone actually
[18:58:13] <SWPadnos> both
[18:58:22] <alex_joni> but I placed a puts in minusDown
[18:58:27] <SWPadnos> minusDone is called from both minusDown and minusUp
[18:58:28] <alex_joni> and it never gets reset
[18:59:02] <SWPadnos> I think this is an example of how hard it is to debug event-driven programs ;)
[18:59:12] <SWPadnos> I think this is how it works:
[18:59:22] <SWPadnos> at - keypress, minusdown gets called
[18:59:50] <SWPadnos> it does several things, including setting up a callback with the "after cancel minusDone" line
[19:00:06] <SWPadnos> it then goes directly on to the jog command, and exits
[19:00:19] <alex_joni> right
[19:00:19] <SWPadnos> after either a cancel, or a minusUp event, the minusDone command will be called
[19:00:31] <alex_joni> which does the jogStop
[19:00:52] <alex_joni> and rebinds the minusDown to the keypress event
[19:01:01] <SWPadnos> so the minusDone isn't executed from minusDown, so the variable will not be reset while minusDown is executing
[19:01:04] <alex_joni> oh fsck me
[19:01:10] <alex_joni> it's set minusAxis -1
[19:01:15] <alex_joni> not set $minusAxis -1
[19:01:20] <SWPadnos> not $minusAxis?
[19:01:21] <SWPadnos> heh
[19:01:32] <SWPadnos> set 1 -1 = that shouldn't work ;)
[19:02:23] <SWPadnos> but you need to leave the minusAxis set until jogStop is called (in minusDone)
[19:02:34] <alex_joni> yeah, only unsetting it there
[19:02:39] <SWPadnos> ok
[19:03:35] <alex_joni> yay, jogging 6 axes in tkemc ;)
[19:03:45] <SWPadnos> cool
[19:03:53] <SWPadnos> simultaneously? ;)
[19:04:04] <SWPadnos> too many fingers needed :)
[19:04:37] <alex_joni> SWPadnos: that's what I'm used to
[19:04:41] <SWPadnos> heh
[19:04:48] <alex_joni> the robots we use have 12 keys for jogging ;)
[19:05:00] <SWPadnos> hmmm - nevermind ;)
[19:05:02] <alex_joni> I jog using 4 usually
[19:05:19] <alex_joni> I can even make it up to 6, but that's hard ;)
[19:05:19] <SWPadnos> you need a spaceball interface
[19:05:44] <SWPadnos> or a Bird
[19:05:57] <alex_joni> bird?
[19:06:41] <SWPadnos> http://www.ascension-tech.com/
[19:07:10] <SWPadnos> http://www.ascension-tech.com/products/pcibird.php
[19:07:27] <SWPadnos> full 6-axis mouse, basically
[19:07:33] <SWPadnos> actually, they have a 6-axis mouse
[19:08:04] <SWPadnos> http://www.ascension-tech.com/products/6dmouse.php
[19:08:42] <alex_joni> SWPadnos: bird is VERY interesting
[19:08:47] <alex_joni> any idea how expensive?
[19:08:59] <SWPadnos> yep, or a flck of birds - you can have dozens
[19:09:01] <SWPadnos> flock
[19:09:12] <SWPadnos> not sure these days, it's in the $thousands for the system
[19:09:45] <SWPadnos> there are similar products at Polhemus
[19:09:59] <SWPadnos> http://www.polhemus.com/
[19:13:53] <alex_joni> that is soo nice
[19:14:05] <SWPadnos> heh - yep
[19:14:21] <SWPadnos> I think Ascension was founded by someone at Polhemus, who had a new idea
[19:14:29] <SWPadnos> both those companies are local to me
[19:14:48] <alex_joni> http://www.polhemus.com/PATRIOT.htm
[19:14:56] <alex_joni> that's what I need
[19:14:59] <SWPadnos> in fact, I was just talking to a friend, who is working on some tiny thing for Ascension
[19:15:01] <alex_joni> but for larger than 5 feet
[19:15:26] <SWPadnos> I think they have a booster for the base station, and that you can use multiple bases to extend the range
[19:15:46] <alex_joni> I imagine synchronisation is an issue
[19:16:07] <SWPadnos> it's taken care of by the hardware/software they supply
[19:16:55] <alex_joni> can you ask how expensive one of those is?
[19:17:04] <SWPadnos> ok, it looks like the bigger transmitter is only for the FASTRACK system
[19:17:57] <alex_joni> yeah, looks better
[19:18:02] <alex_joni> industrial ;)
[19:18:07] <SWPadnos> what tracking envelope do you need?
[19:18:27] <alex_joni> about 4m across
[19:33:53] <alex_joni> cradek: you around in here too?
[19:34:03] <alex_joni> I was wondering about one thing..
[19:34:10] <cradek> yes
[19:34:12] <alex_joni> how should we handle more than 3 axes in hal?
[19:34:21] <alex_joni> whould we have the core_sim for 3 axes
[19:34:35] <cradek> for the stepper-xyza I modified core_stepper and called it stepper-xyza or something like that
[19:34:41] <alex_joni> then load another ontop (core_sim4) with defs for the 4th axis?
[19:34:46] <cradek> I think you should ask jmk, not me
[19:34:48] <alex_joni> and another one core_sim5, etc
[19:35:04] <alex_joni> I made one and called it core_sim_6.hal
[19:35:08] <alex_joni> for 6 axes
[19:35:11] <cradek> ok
[19:35:24] <alex_joni> but I placed it in hexapod not in common
[19:35:33] <alex_joni> wonder if common wouldn't be a better place
[19:35:53] <alex_joni> and have one for 3,4,5,6
[19:36:05] <alex_joni> then the user specifies in the ini which one he likes
[19:36:20] <alex_joni> but that is hard to do with the makefile copying
[19:36:56] <cradek> my opinion is that unless you think a halfile will be used by many configs, don't bother with common
[19:37:12] <alex_joni> yeah, but for core_servo it might be usefull
[19:37:17] <cradek> if it turns out differently, we can always move it into common
[19:37:23] <alex_joni> I mean we can have lots of servo users with 4 axes
[19:37:39] <alex_joni> not talking about what I am doing now, thinking about the future a bit
[19:37:55] <cradek> ok
[19:48:08] <cradek> oh I meant to ask you about g64 - on my inch machine the tolerance seems to be in inches even when in g21 mode - can you fix that?
[19:48:46] <alex_joni> huh.. I can try..
[19:48:51] <alex_joni> let me finish this up first
[19:49:00] <cradek> ok no hurry at all
[19:49:10] <alex_joni> actually there is..
[19:49:17] <alex_joni> tomorrow is my last day at home
[19:49:26] <alex_joni> on sunday I'm off to that fair I talked about
[19:49:26] <cradek> going on a trip?
[19:49:39] <alex_joni> yup, till next saturday most probably
[19:49:45] <cradek> ah, ok
[20:08:25] <SWPadnos> hmm - should the makefile have emc/kinematics/$(KINEMATICS).h in the headers (rather than both hex and triv)?
[20:08:59] <SWPadnos> of course, I should look at the whole file before asking such questions ...
[20:12:25] <alex_joni> there is not triv.h
[20:12:27] <alex_joni> :P
[20:12:39] <SWPadnos> nor hex, I imagine ;)
[20:12:51] <jepler> Is kinematics chosen at compile time or by .ini/.hal?
[20:12:58] <alex_joni> compile
[20:13:09] <alex_joni> jepler: it gets linked into motmod
[20:13:13] <jepler> ugh -- can that be fixed? Thta seems like a terrible limitation.
[20:13:17] <alex_joni> but it could be done differently
[20:13:28] <alex_joni> have it as a separate module
[20:13:31] <jepler> even if it's to build several versions of motmod and insert the right one
[20:13:58] <cradek> with that support we could have experimental tps too
[20:14:00] <alex_joni> jepler: I can do that, but that would mean to duplicate that long list of motmod objs
[20:14:18] <alex_joni> cradek: it's just matter of makefile I guess
[20:14:32] <cradek> and all the overly-complicated scripts
[20:15:02] <jepler> and whitelisting new modules in module_helper
[20:15:23] <alex_joni> yup, that's why I chose to do it like this for now
[20:15:41] <jepler> can we EXPORT_SYMBOL or whatever the kernel calls it, so that motmod.ko can use routines from kins.ko and tp.ko?
[20:15:56] <cradek> argh, I just wrote gauss-jordan the other day because I couldn't find it in posemath
[20:15:57] <alex_joni> yes, we can
[20:16:11] <jepler> Yeah, I'm *not* saying you should have waited to check it in or anything
[20:16:12] <alex_joni> but that means we make kins and tp modules
[20:16:27] <alex_joni> which is pretty bad for their average size
[20:16:33] <SWPadnos> oops - .o shouldn't have been committed
[20:16:34] <alex_joni> but I guess I'm ok with that
[20:16:42] <alex_joni> oopsy.. did I commit that?
[20:16:44] <SWPadnos> yep
[20:16:50] <SWPadnos> probably genhexkins.*
[20:17:12] <alex_joni> :(
[20:17:24] <SWPadnos> cvs killthisfilerightnow genhexkins.o ;)
[20:17:35] <alex_joni> remove
[20:17:46] <SWPadnos> cvs killthisfilerightnow --remove-all-traces genhexkins.o ;)
[20:18:16] <alex_joni> cvs killthisfilerightnow --remove-all-traces --make-never-has-existed genhexkins.o
[20:18:23] <SWPadnos> right
[20:39:18] <staggerlytom> hello
[20:42:00] <staggerlytom> is the pose data in block_pointer ( ie: block_pointer->x_number ) absolute ? even tho the gcode was G91?
[20:44:47] <alex_joni> no idea staggerlytom
[20:45:46] <staggerlytom> any idea how to add the data to debug printouts? ( the text in the terminal that invoked emc? )
[20:46:26] <cradek> the interp is not realtime, so you can add a printf wherever you like it.
[20:46:37] <cradek> you can also attach the debugger to task
[20:48:06] <staggerlytom> ok, i need the value, but not in realtime, thanks ( wait, to task? for pose? )
[20:48:29] <alex_joni> pose is in emcmotStatus soemthing
[20:48:41] <alex_joni> and it passes through task
[20:48:54] <alex_joni> from motion through SHM to task and then to GUI (through NML)
[20:48:59] <cradek> if you just want to see the stat buffer, run emctop inside axis
[20:49:28] <cradek> err whatever it's called "emc status" on the menu
[20:49:39] <staggerlytom> thanks alex,cradek ... (emctop, somethingnew2me )
[20:49:46] <alex_joni> cradek: I'm afraid I'm too tired to think about the G64Pxxx
[20:49:57] <alex_joni> the problem should be in emccanon.cc
[20:50:00] <cradek> alex_joni: that's fine :-)
[20:50:04] <alex_joni> inside SET_MOTION_CONTROL_MODE
[20:50:11] <alex_joni> there is a CONVERT_UNITS() needed
[20:50:17] <alex_joni> but I never figured out which is which
[20:50:17] <cradek> ok
[20:50:24] <alex_joni> TO/FROM something :D
[20:50:44] <cradek> yeah I unfortunately know all about those
[20:51:06] <cradek> I'm not sure that's what you need though
[20:51:16] <cradek> those don't change with g20/g21, they are about user units
[20:51:34] <cradek> but don't worry about it before your trip
[20:53:23] <alex_joni> how does feed_rate get specified?
[20:53:44] <alex_joni> FROM_PROG_LEN()
[20:53:47] <cradek> I don't know but it seems like the same problem
[20:53:52] <cradek> ah ok
[20:54:09] <alex_joni> so not FROM_EXT_LEN () which I think is ini specific
[20:54:15] <cradek> right
[20:54:23] <alex_joni> but FROM_PROG_LEN() which is program specific
[21:20:55] <alex_joni> cradek: still around?
[21:21:04] <alex_joni> seems jepler isn't responding..
[21:21:33] <SWPadnos> ping -f jepler ;)
[21:21:46] <alex_joni> ping -f -s 65535 jepler
[21:21:58] <SWPadnos> heh
[21:21:59] <alex_joni> heh, that broke down doze boxes ;)
[21:22:13] <alex_joni> but I guess it's 'sudo ping -f ...'
[21:22:14] <SWPadnos> methinks dmessier needs to step away from the bong
[21:23:04] <SWPadnos> or the PC
[21:23:57] <alex_joni> ok, so I guess cradek & jepler are not in.. so I'll leave a message
[21:24:15] <alex_joni> jepler, cradek : two problems when running AXIS & hexapod
[21:25:20] <alex_joni> #1 the position of the XYZ coord system is always at 0,0,0 but on the hexapod HOME position is at 0,0,-20 which makes it really hard to use (at -20 I can't really zoom in to view the cone bigger, or drag it around)
[21:25:49] <alex_joni> so I guess I would like to see the initial position of AXIS at the HOME position specified in the TRAJ section
[21:26:38] <alex_joni> #2 AXIS oes only nomral jogging, like mini, so that doesn't work for nontrivkins. for nontrivkins you jog using TELEOP_VECTOR, specifying speeds on the axes (XYZRPW or how they are called)
[21:27:30] <alex_joni> #2' I can't switch from world to joint view, that means I can't move a single joint before homing..
[21:31:00] <alex_joni> ok, since you're not protesting.. he'res a small user-request ;) (if it's not too hard to do).. how about making zoom (scroll wheel) zoom the area where the mouse pointer is, not center of the screen.. (that is usually common on CAD)
[21:32:35] <SWPadnos> plus rotation around the view, not the world origin
[21:33:06] <alex_joni> SWPadnos: if they don't come back quick we could go on for ever
[21:33:34] <SWPadnos> we are, so far it's working ;)
[21:44:01] <SWPadnos> SWPadnos is now known as SWP_Away
[21:51:51] <jepler> those are great ideas
[21:52:03] <jepler> I'm happy to accept patches during the axis 1.3 development cycle.
[21:52:07] <alex_joni> :P
[21:52:30] <alex_joni> if I only knew python ;-)
[21:53:18] <alex_joni> ok,joke aside.. did you see what we talked about in #emc ?
[21:54:02] <jepler> no, I haven't been following too closely
[21:55:03] <alex_joni> ok, bottom line conclusion
[21:55:07] <alex_joni> 2 different things
[21:55:14] <alex_joni> XYZRPY
[21:55:16] <alex_joni> and XYZABC
[21:56:17] <alex_joni> XYZRPW specifies only movement/tilting/rolling/yaw of the head (no movement of the workpiece)
[21:56:47] <alex_joni> XYZABC is a setup where the rotaries are moving the workpiece
[21:57:09] <jepler> OK
[21:57:24] <alex_joni> XYZRPW is easy, XYZABC is hard/next to impossible
[21:57:38] <alex_joni> XYZABC can be done only if you have additional knowledge about the machine
[21:57:49] <alex_joni> RPW is just the tilting of the cone
[21:58:03] <jepler> OK
[21:58:14] <alex_joni> I guess that's it ;)
[21:58:34] <alex_joni> each machine can be run as both I guess with proper kinematics
[21:58:35] <jepler> Here's my point of view: the only machine I have access to is XYZA, and that's not even mine -- it's in cradek's basement
[21:58:49] <alex_joni> right.. I have less ;)
[21:59:12] <alex_joni> but there's always simulation..
[22:02:00] <jepler> Do you think XYZA (or XZA) is going to be more or less common than XYZRPW?
[22:02:34] <alex_joni> that's hard to say
[22:02:41] <alex_joni> I think it will be more common on small mills
[22:02:48] <alex_joni> and less common on serious machines
[22:02:58] <staggerlytom> nutating heads are less common than rotaries
[22:05:29] <jepler> The code I've added for "A" axis backplot will be a useful starting point for showing tool orientation for these RPW machines
[22:06:47] <jepler> Which existing front-end uses TELEOP_VECTOR?
[22:08:39] <alex_joni> TkEmc
[22:10:39] <alex_joni> but the TELEOP stuff is in emcsh
[22:10:49] <jepler> emc_teleop_disable [0|1] ?
[22:10:56] <jepler> er, _enable
[22:11:26] <alex_joni> look at sendJogCont()
[22:13:47] <alex_joni> mini is borked.. it only shows 3 axes
[22:16:29] <jepler> alex_joni: ok--I kinda understand this, but I'm sure not completely. If you want this added to axis, I still say submitting a patch is the best way.
[22:16:40] <jepler> sending me one of these freaky xyzrpw machines would be second-best
[22:17:05] <alex_joni> heh ;) you could build one :)
[22:17:15] <alex_joni> like the wire-thingie I built
[22:17:18] <alex_joni> you can see that there
[22:17:37] <alex_joni> anyways, when I'll have some time I might get back on you with that patch
[22:18:00] <alex_joni> but I'll need some help to get going on AXIS, e.g. where to start looking .. ok ?
[22:24:09] <staggerlytom> nice xyzrpw:
http://www.cybamantech.co.uk/cyba/?page=home xyz overhead rpw like puma
[22:24:27] <staggerlytom> dnag, thats abc sorry
[22:24:39] <alex_joni> yup, ABC
[22:31:32] <alex_joni> ok, night all
[22:31:35] <alex_joni> * alex_joni goes to bed
[22:43:13] <staggerlytom> nite alex
[22:43:33] <staggerlytom> bye all
[23:40:23] <SWP_Away> SWP_Away is now known as SWPadnos
