Back
[00:11:03] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[00:14:13] <steve_stallings> hi SWP, make enough progress that you can come to the Fest?
[00:48:08] <cradek> steve_stallings: yes I brought it. but today I notice that I swiped the power resistor off of it. it needs some load on the 5v to run, if I remember right. if you can grab something like that, it would help.
[01:47:09] <steve_stallings> ok
[01:48:24] <cradek> it is 5v 30a so I bet you'd want to burn 10? % of that
[01:49:13] <steve_stallings> yikes, is this thing a switcher?
[01:50:00] <cradek> yes
[01:50:47] <steve_stallings> then it may not be happy with a servo drive as the load due to returned energy
[01:51:20] <steve_stallings> did jelper read back and see my other questions
[01:52:07] <steve_stallings> I did find and test the servo motor and encoder
[01:52:21] <cradek> umm, he's not here right now
[01:52:50] <steve_stallings> guess that susplains ie
[01:52:52] <steve_stallings> it
[01:53:11] <cradek> the question about the xylotex chips? he answered that one
[01:53:11] <cradek> (no)
[01:54:12] <steve_stallings> got that, still wondering about bringing stepper drivers to run his PCB mill
[01:54:33] <steve_stallings> it also happens to have a power supply suitable to run the servo
[01:54:48] <cradek> I think he will use jmk's xylotex starting tomorrow
[01:54:52] <cradek> oh he's back now
[01:55:07] <jepler> hi steve_stallings
[01:55:30] <steve_stallings> ah, so you do have access to a set of drivers...
[01:55:49] <jepler> steve_stallings: unless you have something I can keep at the end of fest
[01:55:54] <jepler> otherwise I have this board of jmk's to use for now
[01:57:39] <steve_stallings> ok, my drivers have to stay with me for future use at trade shows
[02:00:20] <jepler> thanks for offering
[02:00:46] <steve_stallings> welcome
[02:58:10] <steve_stallings> steve_stallings is now known as steves_logging
[03:00:21] <jepler> whee, hotel wifi works
[03:01:09] <cradek> cool
[03:01:12] <cradek> you win
[03:03:52] <CIA-48> EMC: 03jmkasunich 07TRUNK * 10emc2/src/emc/motion/teleop-notes: design notes for teleop - needs discussion and refinement
[03:58:45] <cradek> mshaver:
http://cvs.linuxcnc.org/cvs/emc2/src/rtapi/rtapi_bitops.h.diff?r1=1.6;r2=1.7
[04:12:40] <DanielFalck> cradek: are in the bus right now?
[04:46:26] <CIA-48> EMC: 03cmorley 07TRUNK * 10emc2/src/emc/usr_intf/pncconf/ (pncconf.py pncconf.glade):
[04:46:26] <CIA-48> EMC: A major change to support more mesa boards / firmware.
[04:46:26] <CIA-48> EMC: It breaks proper loading of saved mesa data at this point.
[04:46:53] <cradek> DanielFalck: I'm still indoors... but going to bed now I think.
[04:51:30] <DanielFalck> just curious if you were irc chatting in style from the mobile office :)
[12:15:58] <CIA-48> EMC: 03bigjohnt 07v2_3_branch * 10emc2/docs/src/hal/basic_hal.lyx: fix table display for not
[12:16:21] <CIA-48> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/basic_hal.lyx: fix table display for not
[12:19:13] <CIA-48> EMC: 03bigjohnt 07v2_3_branch * 10emc2/docs/src/hal/pyvcp.lyx: minor edit
[12:19:33] <CIA-48> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/pyvcp.lyx: minor edit
[14:16:07] <steves_logging> steves_logging is now known as steve_stallings
[15:48:39] <alex_joni> the festies are pretty quiet
[15:50:07] <micges> they're sleeping :)
[15:51:58] <micges> alex_joni: one question: who originally wrote emctask ? was there any rewrite of that part of emc ?
[15:54:49] <alex_joni> I think it's part of the original code
[15:55:00] <alex_joni> it was only hacked, not rewritten
[15:56:58] <alex_joni> micges: first version in CVS
http://cvs.linuxcnc.org/cvs/emc/src/emctask/emctaskmain.cc?annotate=1.1
[15:57:28] <alex_joni> micges: 2-Jul-1997 FMP created
[16:01:07] <micges> wow it was simple :)
[16:04:47] <alex_joni> not a lot simpler than today
[16:37:22] <alex_joni> hey SWPLinux
[16:37:29] <garage_seb> the festerers are at the Boeing surplus sale
[16:37:39] <alex_joni> getting planes?
[16:37:50] <SWPLinux> hi Alex
[16:37:56] <alex_joni> how's the photoshoot?
[16:38:00] <SWPLinux> I'm in Dallas still, my flight is late this afternoon
[16:38:08] <alex_joni> ah, cool
[16:38:09] <SWPLinux> we got the camera working, which is a plus :)
[16:38:12] <alex_joni> everything went well?
[16:38:26] <SWPLinux> the shoot is at the end of the month - watch MTV for the behind-the-scenes show :)
[16:38:35] <SWPLinux> it was good in the end
[16:38:40] <alex_joni> cool
[16:39:04] <SWPLinux> a couple of problems, including a circuit breaker tripping with no UPS for the PC, slowed it down a bit
[16:39:15] <alex_joni> ouch ;)
[16:39:17] <SWPLinux> yeah
[16:39:24] <SWPLinux> we have it down now though
[16:39:33] <SWPLinux> click the button, and 48 cameras take a picture
[16:39:52] <SWPLinux> 6 seconds later, all 48 images are on the server, scaled and cropped, plus a few full res proof frames
[16:40:07] <SWPLinux> 90 seconds later there's a flash and quicktime movie ready for upload to the web
[16:40:24] <alex_joni> heh
[16:40:30] <SWPLinux> which is pretty good, IMO :)
[16:40:40] <alex_joni> can you push the button again in those 90 seconds?
[16:40:43] <SWPLinux> sure
[16:40:46] <alex_joni> cool
[16:40:48] <jmk-wvm> hi y'all
[16:41:07] <alex_joni> hi jmk-wvm
[16:41:07] <SWPLinux> it rarely screws up actually. you can click a few times a second and it gets all the frames (usually)
[16:41:16] <SWPLinux> hi jmk
[16:41:20] <alex_joni> cool
[16:42:03] <SWPLinux> at the moment, I'm trying to get my AVR assembler/programmer working in Linux so I can add a retrigger delay to my control boxes
[16:42:18] <SWPLinux> since I don't like the thing triggering so fast :)
[16:44:47] <alex_joni> sounds like there might be issues with debounce on the trigger button ;)
[16:46:35] <SWPLinux> there is
[16:47:08] <SWPLinux> I think the debounce is 24 ms, but I guess there's noise on the release
[16:48:33] <alex_joni> jmk-wvm: I was thinking about the doc you commited
[16:48:50] <jmk-wvm> good ;-)
[16:49:08] <jmk-wvm> it needs more - specificly info about new ini file items, etc
[16:49:10] <alex_joni> I agree with most of it, but there's one thing I would like to see
[16:49:26] <alex_joni> for some nontrivkins (especially serial kins)
[16:49:40] <alex_joni> it's better to do rapids in an uncoordinated fashion
[16:50:05] <alex_joni> uncoordinated means all joints start and stop togethere, and they are driven by the simple TPs
[16:50:14] <jmk-wvm> huh?
[16:50:18] <jmk-wvm> that is coordinated
[16:50:28] <jmk-wvm> oh, I get it
[16:50:38] <alex_joni> you don't run the positions through kins
[16:50:43] <jmk-wvm> they all move at constant velocity such that they finish at the same time
[16:50:43] <alex_joni> it happens in joint space only
[16:50:47] <alex_joni> right
[16:51:00] <alex_joni> and the slowest or longest traveltime joint gives the overall speed
[16:51:10] <jmk-wvm> IMO, that is a fundamental change to the way EMC does things
[16:51:35] <jmk-wvm> running G1 thru the normal planner and kins, but G0 thru a different path would be very strange
[16:51:48] <alex_joni> I'm not saying for G0 vs G1
[16:52:11] <alex_joni> g-code is probably not good enough to specify these moves
[16:52:13] <jmk-wvm> you said "rapids"
[16:52:17] <alex_joni> right :)
[16:52:29] <alex_joni> in the back of my head there's a different interpreter
[16:52:45] <alex_joni> but that's a minor thing
[16:52:47] <jmk-wvm> but the same motion controller I hope ;-)
[16:52:47] <SWPLinux> in theory, rapids aren't required to be synchronized
[16:52:52] <alex_joni> jmk-wvm: yeah
[16:53:05] <alex_joni> although different motion commands for rapid and linear
[16:53:24] <alex_joni> right now they are all passed as EMCMOT_ADD_LINE or whatever the name is
[16:54:32] <jmk-wvm> how would such a command be implemented?
[16:54:45] <jmk-wvm> IOW, what would need to be added to my drawing?
[16:55:16] <alex_joni> can we postpone this for a couple hours?
[16:55:46] <alex_joni> or hang on, I'll switch PCs
[16:55:47] <jmk-wvm> sure - it's only about noon here
[16:56:03] <alex_joni> it's close to 8pm here, so I only have 5-6 hours left ;)
[16:56:09] <SWPLinux> heh
[17:00:41] <alex_joni> ok.. now
[17:00:59] <alex_joni> jmk-wvm: got that link handy?
[17:01:40] <jmk-wvm> http://jmkasunich.com/pics/emc2-motion-dataflow.pdf
[17:04:24] <alex_joni> jmk-wvm: I think it would need a datapath from coord mode traj planner (maybe even before it) directly to Single Join Traj planner
[17:04:41] <alex_joni> just like HOMING MOVES
[17:04:47] <SWPLinux> lerman, Lerman_____ it turns out I am arriving in Wichita tomorrow, at 2:something PM. if you need a ride, call me at (eight zero two) two three three-five two zero one
[17:05:51] <jmk-wvm> alex_joni: that sounds like a completely differnet mode
[17:06:20] <alex_joni> I think it would work like homing or something like that
[17:06:29] <alex_joni> SW3 changes
[17:06:55] <jmk-wvm> so its almost like you switch from auto/coord mode to joint mode, do a move, and then switch back
[17:07:18] <alex_joni> right
[17:07:33] <alex_joni> during the joint move you still update cart-pos using the forward-kins
[17:09:02] <jmk-wvm> the doc that I committed needs a lot more work - not just for what you are thinking, but that is part of it
[17:09:09] <alex_joni> I don't think the big picture changes much
[17:09:16] <alex_joni> * alex_joni agrees
[17:09:30] <jmk-wvm> there really should be a document that lists the motion controller to userspace interface - all the commands in command.c
[17:09:39] <jmk-wvm> and describes in english what they do
[17:09:48] <jmk-wvm> your new commands would be in there
[17:09:56] <alex_joni> what they are supposed to do ;)
[17:09:59] <jepler> and hopefully not too many of them say "we aren't sure what this does or whether it's even used" :-/
[17:10:31] <alex_joni> jepler: I don't think there are any commands towards the motion controller that fit that description
[17:10:32] <jmk-wvm> yeah
[17:10:55] <alex_joni> there are some status fields that do.. but that's a sideissue
[17:11:02] <CIA-48> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/extensions/emcmodule.cc: additional nml messages (thanks micges)
[17:11:17] <jmk-wvm> I was saying yaah to jepler - some things are a bit complex and confusing
[17:11:37] <alex_joni> what we also need is a picture like the one with the motion controller but covering GUI, task and motion
[17:14:55] <jmk-wvm> I don't know how to draw such a pic - the motion controller naturally lends itself to a data flow type drawing'
[17:14:56] <jmk-wvm> '
[17:15:54] <alex_joni> unfortunately I agree
[17:16:03] <alex_joni> I was wondering about SW2
[17:16:46] <alex_joni> in off mode and in joint mode you say SW2 is middle, preloading the single axis planner with HOME positions
[17:18:16] <alex_joni> maybe there should be an 'invalid' preset aswell
[17:21:05] <alex_joni> and I'm also not very sure why teleop and coord are different modes
[17:22:48] <alex_joni> s/are/need to be/
[17:25:20] <alex_joni> I'm thinking about a case when 2 axes are jogged (say keyboard and jogwheel), that will maybe cause additions in the velocities needed from a certain joint (I mean both jogs on different axes have an effect on the same joint)
[17:25:33] <alex_joni> keeping track of joint constraints will be even harder
[17:27:32] <steve_stallings> steve_stallings is now known as steves_logging
[17:28:06] <jmk-wvm> alex_joni: sorry for the distraction
[17:28:12] <alex_joni> np
[17:28:36] <jmk-wvm> teleop and coord are different because one is taking motion commands from the queue, and one is getting commands from the user
[17:28:44] <jmk-wvm> auto = running a program, or MDI
[17:29:26] <alex_joni> I agree they have different sources, but they might share the TP
[17:29:57] <jmk-wvm> disagree
[17:30:05] <jmk-wvm> the coord TP is _coord_
[17:30:19] <jmk-wvm> it processes one command at a time, either a line or an arc
[17:30:28] <jmk-wvm> the next command can't be started till the current one ends
[17:30:35] <alex_joni> or a jog towards a point :)
[17:30:42] <jmk-wvm> the simple TPs for each axis are completely independend
[17:30:46] <jmk-wvm> independent
[17:30:50] <alex_joni> yes, but imo they can't be
[17:31:18] <jmk-wvm> you can be jogging X, and then start a Y jog before the X jog finishes, and continue the Y jog after the X finishes
[17:31:19] <alex_joni> in theory they are independent but they are causing effects which aren't independent
[17:31:53] <alex_joni> then you simply abort the X jog, and add a XY jog, then stop the XY jog, and add a Y jog
[17:32:02] <jmk-wvm> yuck yuck yuck
[17:32:54] <alex_joni> hmm.. maybe the answer is inbetween somewhere
[17:32:57] <jmk-wvm> what if one (or both) of those jogs is being generated by a jogwheel?
[17:33:38] <alex_joni> then motion does the mixing ..
[17:33:43] <alex_joni> but.. yuck
[17:34:12] <alex_joni> maybe I was thinking implementation-specific, but I have this concearn:
[17:34:24] <alex_joni> user starts an X jog
[17:34:49] <alex_joni> the single axis TP planner checks joint restrictions and decides the jog is a bit too fast and it would exceed joint3 limits
[17:35:00] <alex_joni> it scales the jog speed accordingly
[17:35:16] <alex_joni> next the user starts an Y jog too
[17:35:28] <alex_joni> Y also causes joint3 to move (along with 1,2 & 5)
[17:36:02] <alex_joni> the problem I think is there is that the Y single axis TP planner won't know that X+Y jogs exceeds the joint3 limit
[17:41:54] <SWPLinux> are you guys talking about the same thing?
[17:42:17] <SWPLinux> it lokos like jmk is talking about joint mode and alex is talking about teleop (or non-teleop or whatever the coordinated jog mode is)
[17:42:57] <jmk-wvm> alex_joni: I understand that problem
[17:42:59] <alex_joni> SWPLinux: we both are talking about teleop
[17:43:08] <SWPLinux> ok
[17:43:19] <jmk-wvm> but it is only a subset of the constraints problem, and that approch doesn't solve the rest of the problem
[17:43:36] <jmk-wvm> some non-triv kins have constraints that vary along the move
[17:44:02] <alex_joni> jmk-wvm: I think the only thing I wanted to point out is that the single axis lanners might want to "talk" to each other
[17:44:54] <alex_joni> jmk-wvm: right.. the way the bots I work with work is that they start with the preset speed, and when they get to a joint limit they report that to the axis planners to slow down the whole speed
[17:45:16] <alex_joni> err.. the whole jog
[17:45:34] <alex_joni> * alex_joni really hopes jmk-wvm can read his engrish
[17:45:34] <SWPLinux> teleop needs a joint coordinator, not full coord mode
[17:46:00] <SWPLinux> essentially an adder that sums up all the contributions from the individual planners, and limits the overall output
[17:46:10] <jmk-wvm> teleop and full coord mode both have the same constraints problems
[17:46:27] <jmk-wvm> kins is what does the summing
[17:46:49] <SWPLinux> no, since in full coord mode there is only one source for motion commands
[17:47:15] <SWPLinux> so I'm saying add up all the joint planner commands, and then stick the result of that through the same limiting code that full coord uses
[17:47:31] <jmk-wvm> SWPLinux: you have completely lost me
[17:47:33] <alex_joni> SWPLinux: not joint planner
[17:47:39] <jmk-wvm> are you refering to the diagram?
[17:47:45] <alex_joni> * alex_joni tries a stab at it
[17:47:50] <SWPLinux> err, axis planners
[17:48:01] <SWPLinux> no, I'm not looking at the diagram at the moment
[17:48:09] <alex_joni> all the individual axis planners go to a sum-component, which then outputs to kins
[17:48:22] <jmk-wvm> no
[17:48:30] <jmk-wvm> no sum is needed before kins
[17:48:31] <SWPLinux> if it's like the one you drew when we were in WIchita last time, then I remember more or less what it looks like :)
[17:48:44] <jmk-wvm> because each axis planner drives only one axis, so they are independent inpuits to kins
[17:48:46] <alex_joni> SWPLinux:
http://jmkasunich.com/pics/emc2-motion-dataflow.pdf
[17:48:49] <SWPLinux> this is an after-kins sum
[17:48:51] <SWPLinux> I think
[17:49:02] <alex_joni> well.. kins does the summinh
[17:49:16] <SWPLinux> err, wait. are we talking about teleop still?
[17:49:51] <alex_joni> yes
[17:50:04] <SWPLinux> ok, in that case the summation must be after kins
[17:50:07] <jmk-wvm> the outputs of kins are per-joint values that contain the sum of all the per-axis contributions
[17:50:29] <alex_joni> right
[17:50:31] <SWPLinux> hmm. ok, that should work too
[17:50:52] <alex_joni> the point is when those per-joint values exceed values what should be done
[17:51:03] <jmk-wvm> right, but worse
[17:51:37] <SWPLinux> the resulting move should be slowed down
[17:51:53] <SWPLinux> just like it would be in trivkins if you set the jog speed higher than the axis limit
[17:52:06] <jmk-wvm> if the per-joint velocitiy exceeds a limit, you reduce the per-axis velocities (or the coord mode velocity along the desired multi-axis and maybe curved path)
[17:52:12] <SWPLinux> I guess I'd slow everything proportionally, but that is a debate point
[17:52:34] <alex_joni> that brings up the debate point what to do about coord
[17:52:46] <alex_joni> there are 2 possible ways to do it for coord:
[17:53:10] <alex_joni> 1. simulate the move before it's run, and check the slowest point and scale the move accordingly
[17:53:29] <alex_joni> 2. let it run and if a joint exceeds, slow down the move starting from that point
[17:53:47] <jmk-wvm> ideally, when you get past the slow spot, it would speed back up too
[17:53:53] <alex_joni> right
[17:54:00] <alex_joni> same for jogging
[17:54:05] <jmk-wvm> I really don't loike #1 at all
[17:54:26] <alex_joni> well.. I can only tell you how it's done on "my" bots
[17:54:29] <jmk-wvm> that would pretty much require the kins code to be in two places, once for pre-simulating the move, and one to actually do it
[17:54:44] <alex_joni> it's doing #1 for rapids, and #2 for coordinated moves (G1, & co)
[17:55:31] <alex_joni> #1 for rapids is pretty simple as it's not really coordinated
[17:56:26] <jmk-wvm> so it doesn't simulate the entire move, it onlly runs the kins calcs for the endpoint?
[17:57:06] <alex_joni> it checks the joint moves against joint restrictions
[17:57:24] <jmk-wvm> but only the endpoints
[17:57:33] <alex_joni> you basicly have a current position and an endposition
[17:57:36] <alex_joni> for each joint
[17:57:40] <jmk-wvm> right
[17:57:54] <alex_joni> it checks how far each joint has to turn, and translates that to time using max_vel/acc
[17:58:04] <alex_joni> then it takes the lowest time, and uses that
[17:58:10] <jmk-wvm> so you figure out which joint will take the longest, and then move all the joints so they finish at that time
[17:58:17] <alex_joni> right
[17:58:57] <alex_joni> it has the advantage that it's very fast, and you never hit singularities, etc
[17:59:50] <jmk-wvm> in cases where there is more than one way to get to a specific cartesean pose, how does it decide?
[18:00:16] <jmk-wvm> if you are incrementally moving, you always take whatever kins soluition is closest to the current pos
[18:00:21] <alex_joni> right
[18:00:41] <alex_joni> if you rapid there, then you use joint positions and it's determined
[18:00:45] <jmk-wvm> but if you are doing kins for an endpoint that is far away from the current pos, how do you decide which solution to use?
[18:01:03] <alex_joni> I think they only do incremental kins
[18:01:20] <jmk-wvm> you just said the opposite a few minutes ago
[18:01:30] <alex_joni> err.. did I?
[18:01:56] <jmk-wvm> <alex_joni> you basicly have a current position and an endposition
[18:01:56] <jmk-wvm> <alex_joni> for each joint
[18:02:07] <alex_joni> right, in jointspace
[18:02:18] <alex_joni> no kins involved
[18:02:52] <jmk-wvm> kins must be involved
[18:03:15] <alex_joni> only for coordinated moves
[18:03:41] <jmk-wvm> the desired endpoint comes from the user in cartesean coords - how do you get that endpoint in joint coords without using kins?
[18:03:56] <alex_joni> they don't come from the user in cartesean coords
[18:04:09] <alex_joni> * alex_joni is still talking about his bots
[18:04:24] <alex_joni> basicly we use teach-in programming
[18:04:29] <jmk-wvm> well, then it isn't teleop mode, it is joint mode
[18:04:32] <alex_joni> that means you go to a position and store it
[18:04:46] <alex_joni> when you store it, it saves the joint pos and the carth pos
[18:04:56] <jmk-wvm> I see
[18:05:15] <jmk-wvm> however, teach mode is not really relevant for machine tools, so I don't see how it helps us
[18:05:28] <alex_joni> the only time multiple solutions appear is when you generate a new point from within the program
[18:06:00] <alex_joni> then you generate a carth. point without joint positions, and it can get to cases where it's not always defined
[18:06:15] <alex_joni> but then you have a command which you can use to take solution A,B, etc
[18:07:27] <jmk-wvm> we are trying to solve completely different problems I think
[18:07:56] <alex_joni> I think we (I at least) drifted away
[18:08:15] <alex_joni> * alex_joni tries to get back on track
[18:08:37] <alex_joni> coordinated motion and joint constraints
[18:10:47] <alex_joni> maybe we can define a new limit (scaled from max_vel and max_accel), and when a joint hits that it's time to slow down a notch
[18:11:30] <alex_joni> having max_vel and max_accel (as defined in the ini) as the max physical limits, which can never be tripped
[18:11:47] <alex_joni> and during normal operation it would just work x% slower than that
[18:18:08] <jmk-wvm> stepping way back
[18:18:51] <alex_joni> dang it's hot here.. 95F
[18:19:00] <alex_joni> makes it hard to think even
[18:19:08] <jmk-wvm> I think the root problem is that in a simply implemented system, the guy generating the motion (either coord planner, or one or more single-axis planners) doesn't know that a joint constraint is being approached or exceeded until after the kins calcs have been performed
[18:19:31] <alex_joni> right
[18:19:53] <alex_joni> and it can't just decide to scale the speed and redo the calcs
[18:20:10] <jmk-wvm> it seems like there are two approaches:
[18:20:46] <jmk-wvm> 1) have some global scale factor, the joint-level code sees that we're getting close to the limit, and reduces the scale, then on the next servo period, the planners see that and slow down
[18:21:17] <jmk-wvm> 2) some very complex thing that I don't understand, that lets the planners know what the constraints are
[18:21:43] <alex_joni> I don't think #2 is solved/implemented by anyone
[18:22:45] <jmk-wvm> I sure don't want to go there
[18:23:00] <jmk-wvm> but IMO, some of what you are talking about ls more like #2 than #1
[18:23:26] <alex_joni> yeah, but mostly for not-coordinated moves
[18:24:01] <alex_joni> the bots I work with have a BIG difference between joint limits and speeds and coordinated move speeds
[18:24:06] <jmk-wvm> hmm, we are discussing lunch here - might be leaving soon
[18:24:17] <alex_joni> just an idea to have over lunch
[18:24:37] <alex_joni> normal speeds for coordinated moves are in the range of 10cm..500cm/min
[18:25:08] <alex_joni> normal speeds (if one would convert to carthesian) for uncoordinated moves are in the same range but /second
[18:26:12] <alex_joni> you can do 150-400 degs / second of a joint
[18:26:23] <alex_joni> that means a couple m/sec at the tooltip
[18:57:52] <SWPLinux> ok, looking at the diagram, it doesn't explicitly show where joint or axis constraints are applied, unless that's the function of the "single axis/joint traj planners"
[18:59:37] <SWPLinux> on that note, gotta catch a plane. see (some of) you tomorrow
[20:05:56] <jmk-wvm> each individual planner obeys its own constraints
[20:11:04] <alex_joni> talking about axis or joint? or both?
[20:13:09] <jmk-wvm> I had hopes that the individual planners for each joint and each axis would just be instances of the same code
[20:13:36] <jmk-wvm> in one of the branches, there is a new file called simple_tp.c that has a single axis planner
[20:13:51] <jmk-wvm> which is basically the code that is used for the joint planners today
[20:14:04] <jmk-wvm> I was hoping that the axis planners in my drawing would use the same code
[20:15:36] <alex_joni> well.. that's a bit harder with C
[20:15:45] <alex_joni> it would fit nicely on C++
[20:16:03] <alex_joni> but I think we need to allow all those limits to be in the ini
[20:21:42] <jmk-wvm> actually, simple_tp.c is in trunk too
[20:22:26] <jmk-wvm> struct simple_tp_t is basiclly an instance of a single axis/joint planner
[20:22:49] <jmk-wvm> simple_tp.h describes the API
[20:27:07] <jmk-wvm> looking at that, I realise that it doesn't explicitly have "preload" inputs
[20:27:40] <jmk-wvm> instead it preloads to whatever the output value ii
[20:27:43] <jmk-wvm> is
[20:35:46] <CIA-48> EMC: 03cradek 07TRUNK * 10emc2/src/configure.in: make sure python-tcl and tcl versions match
[22:10:17] <cradek> mshaver: T2:23:respawn:/sbin/getty -L ttyS2 115200 xterm
[22:20:59] <CIA-48> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/firmware/5i20/ (SVST2_4_7I47.BIT SVST2_4_7I47.PIN): another 5i20 firmware file, used by Matt Shaver
[22:26:12] <CIA-48> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/hostmot2.h: cleanup: remove an unused variable
[22:26:27] <CIA-48> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/stepgen.c: added a fixme