Back
[01:20:35] <jmkasunich> cradek: you around?
[01:21:14] <jmkasunich> I'm hoping you recall some stuff about the main TP (I'm being too lazy to study the source)
[01:27:27] <cradek> yes
[01:31:24] <jmkasunich> I assume there is a way to "stuff" a position (pose) into the TP?
[01:31:40] <cradek> you mean set the current position?
[01:31:42] <jmkasunich> so it knows where the machine is when you switch from free to coord, for example
[01:31:45] <jmkasunich> yes
[01:31:47] <cradek> sure
[01:31:59] <cradek> it's tpMumbleSetMumblePos()
[01:32:09] <jmkasunich> ok - I'll grep for that ;-)
[01:32:39] <cradek> tpSetPos(tp, pose)
[01:32:48] <jmkasunich> I think this thing I have drawn up will help clarify a lot of the funky code in motion
[01:33:01] <jmkasunich> http://jmkasunich.com/pics/emc2-motion-dataflow.pdf
[01:33:12] <jmkasunich> still adding a few details, but take a look
[01:38:15] <jmkasunich> refresh - just updated it
[01:39:00] <jmkasunich> I think this drawing (assuming it can be coded, which I believe is true), plus some state info, does what we want with less funky logic
[01:39:10] <cradek> neat
[01:39:50] <cradek> this will take a while to absorb
[01:39:55] <SWPadnos> question about jogging: can you use a single control to jog a non-cartesian-aligned and non-joint path?
[01:40:05] <SWPadnos> ie, jog at 45 degrees in XY
[01:40:12] <jmkasunich> swp: not directly
[01:40:21] <SWPadnos> ok, so HAL machinations are needed for that
[01:40:26] <jmkasunich> you could issue two jog commands
[01:40:27] <cradek> we would be losing that capability
[01:40:30] <jmkasunich> or two wheel commands
[01:40:40] <jmkasunich> wait - we're not losing anything
[01:40:42] <cradek> I think you could theoretically do it now, if a gui let you
[01:40:53] <SWPadnos> you can do it now using HAL
[01:41:00] <cradek> you can teleop in the (1,2,3) direction
[01:41:08] <SWPadnos> but it's not easy, and can't control it from any GUI
[01:41:09] <jmkasunich> if you hit two jog keys at "same time" today, you can jog at 45 degrees
[01:41:19] <cradek> jmkasunich: I want 32.75 degrees
[01:41:19] <jmkasunich> and this doesn't change that in any way
[01:41:21] <SWPadnos> hmmm. I should have said 30 degrees then ;)
[01:41:34] <jmkasunich> then you need to issue jogs with velocities that are different
[01:41:47] <cradek> they won't be coordinated
[01:41:57] <jmkasunich> there are currently no EMCMOT commands to do that - you'd have to issue two jog commands as quickly as possible
[01:41:59] <SWPadnos> I guess my point is that it would be good to consider world-mode jogging on non-aligned paths
[01:42:01] <cradek> I'm not saying this is *important* but we are losing the functionality
[01:42:14] <jmkasunich> we don't have the functionality now
[01:42:19] <cradek> yes we do, in teleop
[01:42:20] <SWPadnos> since there's lots of rip-up/retry coding going on ;)
[01:42:32] <jmkasunich> oh, in teleop, not jogs
[01:42:36] <cradek> teleop takes a vector and does coordinated motion
[01:42:47] <SWPadnos> but you can't jog that, it's MDI only, right?
[01:42:51] <jmkasunich> a velocity vector
[01:43:01] <cradek> has nothing to do with mdi
[01:43:06] <SWPadnos> err - I hate teleop ;)
[01:43:21] <jmkasunich> I understand - teleop takes a velocity vector
[01:43:32] <jmkasunich> jogs (as written today) are single axis commands
[01:43:34] <cradek> we're gaining incremental jogs and jogwheels, and losing coordinated motion along arbitrary vectors
[01:43:43] <cradek> (in nontrivkins)
[01:43:45] <jmkasunich> well, thats not entirely true
[01:44:07] <jmkasunich> because this diagram doesn't care where or how the "keyboard jog" commands come from
[01:44:25] <jmkasunich> we could implement EMCMOT_JOG_VECTOR that has a 9-tuple of velocities
[01:44:36] <jmkasunich> and initiates jogs on all 9 axes
[01:44:42] <cradek> that's not enough for coordinated motion
[01:44:51] <jmkasunich> why not?
[01:44:55] <cradek> the accels would have to be different too
[01:44:58] <jmkasunich> oh, because they don't accel to gether
[01:45:07] <SWPadnos> actually, I think the keyboard/jogwheel distinction shouldnt be in this diagram. that's a decision that's made elsewhere
[01:45:23] <SWPadnos> and there could be 3 (or more) options on some machines
[01:45:33] <jmkasunich> swp: I just show both as possible sources for movement commands to the planners
[01:45:46] <cradek> I don't care about this, I think it's fine if it works like the current joint jogs
[01:45:49] <SWPadnos> sure - and I guess there are exactly two sources for those motions: NML and HAL
[01:45:52] <jmkasunich> there is some interlocking between them that matters
[01:46:15] <cradek> but we should all understand what we're losing and gaining
[01:46:29] <jmkasunich> I was unaware that teleop was that coordinated
[01:46:35] <cradek> pretty sure it is
[01:46:37] <jmkasunich> so it accels and decels along a vector, eh?
[01:46:40] <cradek> (nothing uses it that way)
[01:46:43] <cradek> yes
[01:46:53] <cradek> well who knows how it works today
[01:47:00] <SWPadnos> it's a G1 planner, with moving endpoints ;)
[01:47:00] <jmkasunich> heh
[01:47:00] <cradek> "barely"
[01:47:12] <cradek> SWPadnos: no endpoints, only direction and velocity
[01:47:18] <SWPadnos> oh
[01:47:28] <SWPadnos> it's a G1' planner ;)
[01:47:29] <cradek> it's not very good for machine tools
[01:47:33] <cradek> (IMO)
[01:47:38] <cradek> for robocranes, maybe
[01:47:43] <cradek> I don't care about robocranes
[01:47:46] <jmkasunich> it was used to allow a joystick to control a robocrane
[01:48:01] <jmkasunich> joysticks can request vectors, not just 0, 45, 90 degrees
[01:48:04] <SWPadnos> well, that off-axis jogging thing would be very cool, though someone with a CNC could just write an MDI line
[01:48:08] <cradek> I care about machine tools, not robots
[01:48:53] <jmkasunich> we don't run joysticks thru NML anyway, since thats not RT
[01:49:07] <SWPadnos> teleop does, doesn't it?
[01:49:08] <cradek> yes we do
[01:49:10] <jmkasunich> if somebody wants joystick behavior, they can use the wheel jog inputs
[01:49:12] <SWPadnos> that's from userspace
[01:49:31] <jmkasunich> halui does that?
[01:50:05] <cradek> halui.jog.N.analog
[01:50:09] <cradek> it works great last I heard
[01:50:12] <jmkasunich> ah, ok
[01:50:14] <cradek> it does issue NML commands
[01:50:41] <cradek> sendJogCont(joint,*(halui_data->jog_speed) * *(halui_data->jog_analog[joint]));
[01:50:43] <jmkasunich> in that case, we'll get the same capabilities, but now in cartesean as well as joint space
[01:50:52] <cradek> yes
[01:50:57] <jmkasunich> they won't be perfectly coordinated as teleop was, but they'll be pretty good
[01:51:16] <cradek> it's not coordinated motion but it'll be fine for a joystick
[01:51:22] <jmkasunich> yuck - the cat sitting in my lap just farted - phew
[01:51:25] <SWPadnos> couldn't one "jog" command contain offsets/endpoints for all axes?
[01:51:26] <SWPadnos> heh
[01:51:29] <cradek> thanks for sharing that.
[01:51:51] <jmkasunich> SWPadnos: thats what the hypothetical EMCMOT_JOG_VECTOR was all about
[01:51:55] <cradek> SWPadnos: jmk suggested that above, but it doesn't make it coordinated
[01:52:12] <SWPadnos> ok, I guess I missed that :)
[01:53:10] <jmkasunich> so, are we comfortable with losing the finer points of coordinated teleop?
[01:53:31] <SWPadnos> I'd prefer not to, but I'm not sure I have a solution that allows that
[01:53:34] <jmkasunich> in return we gain a more stable state transition system, and jogs that work the same in both joint and axis space
[01:53:57] <jmkasunich> if we would like to retain coordinated teleop, I wonder if the main TP can do it?
[01:54:08] <jmkasunich> or does it depend strictly on having an endpoint?
[01:54:15] <jmkasunich> it - main tp
[01:54:29] <cradek> you could SetLine to a long way away, and then abort it later
[01:54:30] <SWPadnos> all the functionality is there, it should be a question of where the endpoint (or velocity) comes from
[01:54:48] <cradek> but I still don't care about this :-)
[01:54:53] <jmkasunich> ok
[01:55:07] <SWPadnos> if there are major machinations regarding where the endpoint comes from, then there's probably a design flaw somewhere
[01:55:31] <jmkasunich> can we review the drawing? explaining it to you guys will help me find bugs in it
[01:55:45] <SWPadnos> I've got it up
[01:55:49] <cradek> ok
[01:56:10] <jmkasunich> ok, lets talk about SW5 first
[01:56:28] <jmkasunich> if you have working forward kins, SW5 is down
[01:56:55] <jmkasunich> if you don't have working forward kins (not homed, or simply no forward kins at all), it is up
[01:57:17] <jmkasunich> so you always have something that you can use as cartesean (axis) feedback
[01:58:12] <jmkasunich> the arrow going into the bottom of the main (coord mode) planner is the value that it is being set to when its not in control of the machine
[01:58:24] <jmkasunich> set to current position, so when you put it in control nothing jumps
[01:58:44] <jmkasunich> the same applies to the two simple planners, axis and joint
[01:59:10] <jmkasunich> when the machine first starts, SW1 and SW3 are in their middle positions
[01:59:31] <jmkasunich> the home location, usually zero, is being sent out as a command
[01:59:56] <jmkasunich> SW4 and SW2 are up
[02:00:18] <jmkasunich> so the two simple planners are being preset to the current commanded position
[02:00:50] <jmkasunich> so, all three planners are being preset to "home"
[02:01:00] <jmkasunich> then you do machine on - which puts you in free mode
[02:01:12] <jmkasunich> SW3 switches to down
[02:01:26] <jmkasunich> the single joint planner drives the output
[02:01:40] <jmkasunich> and you can jog around.
[02:02:03] <jmkasunich> here's one thing I'm undecided on
[02:02:19] <jmkasunich> I was originally thinking of four states - off, free, teleop, and coord
[02:02:35] <jmkasunich> but in theory there are three 'off' states
[02:02:47] <jmkasunich> free off, teleop off, and coord off
[02:03:16] <jmkasunich> does that make any sense (or am I talking to myself)
[02:03:30] <SWPadnos> a couple of questions/points:
[02:03:34] <jmkasunich> ok
[02:03:46] <SWPadnos> 1) I don't know that you can drive SW1 with "home" at startup
[02:04:09] <SWPadnos> last knows, zero, absolute encoder position, forward kins results from feedback ...
[02:04:16] <SWPadnos> known, not knows
[02:04:41] <jmkasunich> startup is a bit of a chicken/egg thing
[02:04:45] <SWPadnos> 2) is that a connection dot to the right of "AXIS POS CMD", connecting to the vertical line from SW2 "up" position
[02:04:47] <SWPadnos> yes
[02:05:18] <jmkasunich> yes, its a dot - the top of sw2 is driven by the output of sw1
[02:05:49] <SWPadnos> ok - couldn't tell where DRO FB would be from with SW5 up :)
[02:06:21] <jmkasunich> regarding 1
[02:06:25] <SWPadnos> SW3 is even more dicey with home vs. feedback position
[02:07:23] <jmkasunich> remember, the switches are in the middle position right after power up only
[02:07:29] <jmkasunich> amps are NOT enabled at that point
[02:08:09] <jmkasunich> I need to draw a state table (to communicate to you, and to get my own thoughts straight)
[02:08:20] <jmkasunich> position of each switch in each mode
[02:08:39] <jmkasunich> in general though, SW1 and SW3 determine "who" is controlling the position
[02:08:45] <jmkasunich> SW3 down = free mode
[02:08:52] <jmkasunich> SW3 up, SW1 down = teleop
[02:08:58] <jmkasunich> SW3 up, SW1 up = coord
[02:09:02] <SWPadnos> yep. it seems that some of those switches aren't separate - they're more like multiple contacts from a single coil (though I could be wrong on that)
[02:09:33] <SWPadnos> I guess some are "don't cares" when others are a certain way
[02:10:01] <jmkasunich> whenever SW3 is up and the machine is enabled, SW4 is also up, and the single joint planner is being constantly loaded with the commanded position (which is coming from kins)(
[02:10:36] <jmkasunich> that way its ready for a transition to free mode - SW3 goes down, position doesn't change, we stop loading the planner and let it run as commanded by jogs, etc
[02:11:24] <jmkasunich> likewise with the axis planner - when SE1 is up, SW2 is also up and the planner is being loaded with the axis position (which is coming from the main planner)
[02:12:21] <jmkasunich> when disabled, SW2 and SW4 are both down - the planners are preloaded with feedback position
[02:12:34] <jmkasunich> hmm, I think maybe SW2 is in the wrong place
[02:13:04] <jmkasunich> I really do need to make a table, and don't have time tonight
[02:13:07] <SWPadnos> heh
[02:13:14] <SWPadnos> it's complex stuff
[02:13:38] <SWPadnos> and this also doesn't take into account things like "is homed", for transitions between modes
[02:13:49] <jmkasunich> but in general, the idea is that there are three planners, at any time those that are NOT running the machine are being preset with the current position
[02:13:50] <SWPadnos> at least not as far as I can understand it at the moment
[02:13:56] <SWPadnos> sure
[02:14:23] <SWPadnos> and there's only one (at most) running the machine at any given time
[02:14:26] <jmkasunich> right - in addition to a table that shows switches as a function of state, I need a state transition table/chart/whatever
[02:14:30] <jmkasunich> exactly
[02:15:03] <jmkasunich> lemme see if I can get this right:
[02:15:20] <jmkasunich> when disabled, SW4 is down - preset joint planner with feedback pos
[02:15:44] <jmkasunich> SW2 is down - preset axis planner with feedback pos (after fwd kins)
[02:16:05] <jmkasunich> SW5 is down - preset coord planner with feedback pos (after fwd kins)
[02:16:30] <jmkasunich> I need to think about the case where there are no fwd kins - thats why I have switches that let me use the current command instead
[02:16:41] <jmkasunich> anyway, next state: free mode
[02:16:56] <jmkasunich> SW4 is a no-care - that planner is active and controlling the machine
[02:17:05] <SWPadnos> it seems that SW4 could be represented as a selector between FB, homing, key jog and wheel jog
[02:17:17] <jmkasunich> SW2 and SW5 are still down, presetting those planners from feeeback
[02:17:33] <SWPadnos> oh, nevermind
[02:17:48] <jmkasunich> not quite - the SW4 branch forces the output of the planner - the jogs obey vel and accel constraints
[02:18:03] <SWPadnos> right - that's a switch for the feedback position, not the command input
[02:18:13] <SWPadnos> dots and line crossings and stuff ...
[02:18:19] <SWPadnos> (ad eye crossings :) )
[02:20:58] <jmkasunich> ok, teleop mode:
[02:21:16] <jmkasunich> SW4 is up, keeping the joint planner preset to the current position command
[02:21:25] <jmkasunich> SW2 = nocare - that planner is active
[02:21:49] <jmkasunich> SW5 is up - keeping the main planner preset to the current position command
[02:21:55] <jmkasunich> finally, coord mode
[02:22:03] <jmkasunich> SW4 is up, keeping the joint planner preset to the current position command
[02:22:13] <jmkasunich> SW2 is up - keeping the axis planner preset to the current position command
[02:22:20] <jmkasunich> SW5 = nocare - that planner is active
[02:23:06] <SWPadnos> I think the diagram needs more arrows ;)
[02:23:11] <jmkasunich> the "no forward kins" case is why SW1 has "home" as one of its inputs
[02:23:42] <jmkasunich> if you have no forward kins, you never have valid cartesean feedback, so you never know what you can prime your planners with
[02:23:54] <jmkasunich> _except_ right after homing - then you can prime them with "home"
[02:24:20] <SWPadnos> in that case, whatever the interp (or other higher level controller) decides is the correct position, it would be the top position of SW1
[02:24:51] <SWPadnos> ok
[02:25:04] <jmkasunich> before homing all joints, SW1 would be in the middle, and SW4 and SW5 would be up - so both planners would be preloaded with "home"
[02:25:16] <SWPadnos> that means that there needs to be a good set of joint and world home positions in the ini file
[02:25:43] <jmkasunich> when you've homed all joints, you know they now match the axes, and that is the neccessary condition for transitioning from free to teleop or coord
[02:25:44] <SWPadnos> for no-forward-kins machines?
[02:25:51] <jmkasunich> right
[02:26:11] <SWPadnos> I don't think you'd want to preload home position until after the homing process completes
[02:26:14] <jmkasunich> if you have working forward kins, then SW4 and 5 can be down, and you can preload the main and axis planners any time you want
[02:26:31] <SWPadnos> though that's a nitpick - there still needs to be a home preload option at some point
[02:26:38] <jmkasunich> why not? teleop and coord are locked out until you home everything
[02:26:53] <jmkasunich> you gotta have some value in the planners, might as well make it home
[02:27:11] <SWPadnos> might as well leave it at zero, or whatever the higher level program loads at startup
[02:27:32] <jmkasunich> the higher level program doesn't get to load it
[02:28:11] <SWPadnos> hmmm
[02:28:13] <jmkasunich> planners ramp their outputs from "wherever they are" to "where they're supposed to go" but only when enabled
[02:28:27] <jmkasunich> prior to entering either coord or teleop, those planners won't be enabled
[02:28:43] <jmkasunich> so nothing from "upstairs" can affect their outputs
[02:29:44] <SWPadnos> oh right, this is after the coord planner
[02:29:48] <jmkasunich> to a degree this is nitpicking - all we care about is that the instant we switch SW3 to "up", the value coming from the kins had better be match where we are - and if we have no forward kins, the only place that can be guaranteed is at home
[02:30:23] <SWPadnos> even that can't be guaranteed without forward kins (but at that point it's an operator error :) )
[02:30:31] <jmkasunich> it can be guaranteed
[02:30:45] <SWPadnos> in a sense, it's an overspecification in the ini file
[02:30:55] <jmkasunich> we do not allow a transition from free to teleop or coord unless all joints are homed
[02:31:02] <jmkasunich> oh - you mean if the ini is wrong
[02:31:05] <SWPadnos> it's up to the integrator to insure that the numbers entered for all joint homes match the numbered entered for all axis homes
[02:31:07] <SWPadnos> right
[02:31:24] <jmkasunich> ok - at this point I'm assuming that the ini is correct
[02:31:32] <SWPadnos> good simplifying assumption ;)
[02:31:51] <SWPadnos> things could get interesting if that's not true though - something for the back of the mind
[02:32:12] <SWPadnos> hmmm
[02:32:17] <jmkasunich> if we have forward kins, it doesn't matter, since SW4 and SW5 will be down, and the planners will be loaded with the actual feedback position, not home
[02:32:23] <SWPadnos> right
[02:32:28] <jmkasunich> if we have forward kins we can also switch to teleop or coord any time
[02:33:09] <SWPadnos> for support of HOME_OFFSET on non-trivial machines, the offset has to be applied after all joints are homed
[02:33:13] <jmkasunich> "have" in this context means that the code is present _and_ that it yields correct results - some kins functions may be ambiguous unless homed
[02:33:22] <SWPadnos> it's a world-mode offset
[02:33:30] <SWPadnos> (for axes anyway)
[02:33:36] <SWPadnos> heh
[02:33:38] <jmkasunich> huh? home offset is a joint thing - location of the switch (or index) in joint coords
[02:33:46] <SWPadnos> ok
[02:33:51] <jmkasunich> there is no home offset for axes, only for joings
[02:33:52] <jmkasunich> tsd
[02:33:57] <jmkasunich> blah
[02:33:59] <jmkasunich> joints
[02:34:00] <SWPadnos> heh
[02:34:35] <SWPadnos> ok, so there's HOME_POSITION for axes, and that tells EMC where the machine is (in world coordinates) after the joints are all homed
[02:34:55] <jmkasunich> I was gonna just call it HOME, but yes
[02:35:29] <jmkasunich> [JOINTs] home and [AXISs]HOME define the same pose, in the two spaces
[02:35:30] <SWPadnos> ok, is that clearly defined as "world location with all joints at their respective HOME_OFFSETs"?
[02:35:45] <jmkasunich> no, with all joints at their respective HOMEs
[02:35:48] <SWPadnos> ok
[02:36:10] <jmkasunich> HOME_OFFSET has nothing to do with anything except the physical location of the home switch or index
[02:36:15] <SWPadnos> ok
[02:36:50] <SWPadnos> is HOME assumed to be zero for every joint? (regardless of HOME_OFFSET)
[02:37:10] <SWPadnos> assumed / defined ...
[02:37:16] <jmkasunich> HOME can be anything
[02:37:56] <SWPadnos> ok - I should ook at the various homing related ini vars before going into that too much
[02:38:00] <SWPadnos> or look
[02:38:26] <jmkasunich> basically, homing works like: go find the switch, call that spot HOME_OFFSET, then go to HOME
[02:38:53] <SWPadnos> ok
[02:39:40] <jmkasunich> when all joints are at HOME, all axes are also (by definition) also at their HOME
[02:39:50] <jmkasunich> and the kins equations had better bear that out ;-)
[02:40:24] <jmkasunich> hmm
[02:40:30] <jmkasunich> there is a bit of reduncancy there isn
[02:40:32] <jmkasunich> isn't there
[02:40:33] <SWPadnos> yep
[02:40:45] <jmkasunich> we could have only the axis homes in the inifile
[02:40:55] <jmkasunich> with the joint homes computed by running inverse kins
[02:41:10] <SWPadnos> there can be a "lint" check on that - run the world home position through inverse kins and make sure the joint poisitions match to some degree
[02:41:20] <SWPadnos> that's also possible
[02:41:44] <jmkasunich> if SW1 is centered, axis home is being fed to kins, so joint home is on the upper end of SW3
[02:41:51] <jmkasunich> the center position of SW3 isn't needed
[02:42:09] <SWPadnos> true
[02:42:19] <jmkasunich> at the end of homing, the homing state machine would set the joint planner's target position to whatever is on top of SW3
[02:42:48] <jmkasunich> and as soon as that move is complete, both sides of SW3 are the same and its safe to transition to coord or teleop
[02:43:07] <jmkasunich> (for that joint - there will be logic to test all joints)
[02:44:36] <jmkasunich> I have to walk the dog and pack for a trip (and get some sleep - early flight)
[02:44:46] <jmkasunich> I'm gonna keep pondering this, and add some state tables
[02:44:53] <SWPadnos> ok. I'll ponder as well
[02:45:02] <SWPadnos> or at least as long ;)
[02:45:55] <jmkasunich> I just updated to remove the center position from SW3
[02:45:58] <steves_logging> steves_logging is now known as steve_Stallings
[02:47:48] <steve_Stallings> JMK - I have not caught up yet but wanted to comment on the cubic being removed. At one time I had considered a smart external device and thought cubics would be a good way to send motion commands across a medium bandwidth communication link.
[02:48:14] <jmkasunich> argh
[02:48:43] <steve_Stallings> Yea, I don't know enough to understand just how messy that might become.
[02:48:44] <SWPadnos> steve_Stallings, that's a different question, I think
[02:49:06] <SWPadnos> he was talking about the cubic sub-interpolator within the trajectory planner
[02:49:19] <jmkasunich> SWPadnos: he knows that
[02:49:21] <SWPadnos> bit how the trajectory planner gets its path information
[02:49:25] <SWPadnos> s/bit/not/
[02:49:28] <jmkasunich> notice that its missing in my drawing?
[02:49:28] <SWPadnos> sure
[02:49:31] <SWPadnos> heh
[02:50:07] <jmkasunich> I think steve_Stallings was envisioning the cubics (output by the main TP at 1/10 the servo rate) as being the input to his smart amps
[02:50:17] <SWPadnos> I wonder if we're agreeing - that a cubic path specification would be somewhere off the left side of that page
[02:50:23] <jmkasunich> which immediately brings up issues like "well then how do you jog"
[02:50:35] <jmkasunich> SWPadnos: no, we're not agreeing
[02:50:42] <SWPadnos> well!
[02:50:59] <jmkasunich> there used to be a cubic spec just to the right of the INVERSE KINEMATICS box
[02:51:06] <SWPadnos> ok
[02:51:42] <jmkasunich> my thoughts regarding smart amps:
[02:51:53] <jmkasunich> 1) don't like em (but thats irrelevant)
[02:52:12] <steve_Stallings> It was just a comment about possible consequences of removing the cubic interpolator layer. I realize that chopping into the system there probably raises many more issues.
[02:52:16] <jmkasunich> 2) I'd drop the servo rate if needed, and then use "motor pos command" from the right side of the drawing to run the amps
[02:52:51] <jmkasunich> that way you don't break homing, jogging, etc
[02:53:09] <jmkasunich> screw comp - the whole shooting match - cutting into the middle breaks lots of stuff
[02:53:31] <steve_Stallings> OK, I need to catch up reading and look at the diagram. Is its URL referenced in this thread?
[02:53:52] <SWPadnos> http://jmkasunich.com/pics/emc2-motion-dataflow.pdf
[02:53:59] <jmkasunich> http://jmkasunich.com/pics/emc2-motion-dataflow.pdf
[02:53:59] <steve_Stallings> Thanks.
[02:54:49] <jmkasunich> steve_Stallings: your thoughts and critique are welcome - I need to do some switches vs. machine state charts, and state transition stuff
[02:55:13] <jmkasunich> but eventually this will replace a lot of crufty code
[02:55:31] <jmkasunich> there is a mishmash of flags here and there, and different conditions for doing differnet things
[02:55:32] <steve_Stallings> Less cruft is good 8-)
[02:55:46] <jmkasunich> some of the transitions (mostly teleop ones) are probably not right
[02:57:00] <steve_Stallings> Your previous efforts, especially HAL, show clear construction and solid engineering. Here's to more of the same.
[02:57:37] <jmkasunich> blush
[02:58:32] <steve_Stallings> Just wait until we find some gawd-awful plastic trophy to present at a the next Fest.
[02:58:50] <SWPadnos> hmmm. maybe a penguin of some sort
[02:58:56] <SWPadnos> nah, that's been done ;)
[02:59:25] <jmkasunich> gotta run, goodnight guys
[02:59:30] <SWPadnos> see you jmk
[03:01:14] <steve_Stallings> gee, it late, maybe I should eat dinner now, off to the microwave dinner...
[03:01:24] <SWPadnos> brzzzzap!
[03:28:12] <SWPadnos> oh great:
[03:28:30] <SWPadnos> <<< 550-Postmaster verification failed while checking <spadnos@sover.net>
[03:28:32] <SWPadnos> <<< 550-Called: 209.198.112.38
[03:28:33] <SWPadnos> <<< 550-Sent: RCPT TO:<postmaster@sover.net>
[03:28:35] <SWPadnos> <<< 550-Response: 550 5.1.1 <postmaster@sover.net>... User unknown
[03:28:36] <SWPadnos> <<< 550-Several RFCs state that you are required to have a postmaster
[03:28:38] <SWPadnos> <<< 550-mailbox for each mail domain. This host does not accept mail
[03:28:40] <SWPadnos> <<< 550-from domains whose servers reject the postmaster address.
[03:28:41] <SWPadnos> <<< 550 Sender verify failed
[03:28:42] <SWPadnos> 550 5.1.1 <emc-users@lists.sourceforge.net>... User unknown
[03:28:44] <SWPadnos> <<< 503 valid RCPT command must precede DATA
[03:28:45] <SWPadnos> apparently I can't post to the SF lists any more
[03:31:04] <cradek> buh?
[03:31:05] <cradek> 250 2.1.5 postmaster@sover.net... Recipient ok
[03:31:32] <SWPadnos> hmmm
[03:31:40] <cradek> I don't see any problem. maybe it was spurious.
[03:32:13] <SWPadnos> I'll try again
[03:32:25] <SWPadnos> here's the full text:
http://pastebin.ca/925585
[03:33:00] <SWPadnos> I haven't received the message - did it actually go through to SF?
[03:33:27] <cradek> I don't see a recent message from you
[03:33:30] <SWPadnos> ok
[03:33:41] <SWPadnos> let's see if it works the second time
[03:34:25] <SWPadnos> ah. apparently it did
[03:34:51] <cradek> yes
[03:35:57] <SWPadnos> now to answer "Administrator"
[03:36:05] <cradek> heh
[03:51:28] <steve_Stallings> regarding JMK's comment about lowering servo rate and using MOTOR POS command to HAL as the medium bandwidth output to a "smart amp", doesn't a cubic provide more information, i.e. a cubic isn't necessarily a straight line but external interp of MOTOR POS would have to be?
[03:51:35] <jepler> hm, 'make tags' doesn't work on my gutsy machine
[03:51:35] <jepler> find . -type f -name '*.[ch]' |xargs etags -l c --append
[03:51:35] <jepler> etags: Unknown option: -l
[03:51:47] <cradek> yuck
[03:51:53] <cradek> all those damn tags programs want different options
[03:52:30] <jepler> indeed
[03:52:32] <jepler> lrwxrwxrwx 1 root root 24 2008-01-06 18:24 /etc/alternatives/etags -> /usr/bin/ctags-exuberant
[03:52:35] <jepler> lrwxrwxrwx 1 root root 23 2008-01-06 18:24 /usr/bin/etags -> /etc/alternatives/etags
[03:52:42] <jepler> hm looks like ctags-exuberant tries (but fails) to mimic etags...
[03:52:55] <jepler> somebody who cares should write some configure tests, I guess
[03:53:12] <cradek> I agree
[03:54:11] <SWPadnos> steve_Stallings, I'm not sure that the output of the cubic interp is what you'd be looking for
[03:54:27] <jmkasunich> more like the input to the interp
[03:54:42] <jmkasunich> (just stopped by to write and print a note for the petsitter)
[03:54:42] <SWPadnos> it still outputs positions, but they're "smoothed" differently
[03:54:49] <SWPadnos> heh
[03:54:59] <cradek> ha "write"
[03:55:12] <jmkasunich> type
[03:55:21] <SWPadnos> writing is so much harder to read
[03:55:29] <jmkasunich> writing is so much harder to write
[03:55:30] <SWPadnos> the font isn't very legible ;)
[03:55:45] <jmkasunich> especially when the last note has 95% of the content of the new one
[03:56:39] <steve_Stallings> OK, but is my understanding of cubic interp being able to do things (non-straight line) that MOTOR POS would not allow for correct?
[03:57:13] <SWPadnos> steve_Stallings, I think the (or at least a) key to making smart drives work well is to specify the new target position in addition to the expected accel and jerk limits for that move
[03:57:43] <SWPadnos> the output of the interp is still a series of positions, as far as I know
[03:58:03] <steve_Stallings> yikes, I have enough trouble with the simple stuff
[03:58:56] <steve_Stallings> isn't the cubic spec something that can be solved multiple times with delta time, and the solution is not necessarily a straight line?
[03:58:56] <SWPadnos> that's how you'd get the motors to play nidely with each other
[03:59:19] <SWPadnos> my suspicion is that you need very high cycle rates for independent drives to be able to do contouring correctlu
[03:59:25] <SWPadnos> correctly
[03:59:40] <SWPadnos> many applications are positioning, not pathing
[03:59:47] <SWPadnos> for those, smart drives are fine
[04:00:56] <steve_Stallings> but that is not my goal, I want to make it possible to do a high performance CNC machine with the control software running on a "consumer" box that may soon be devoid of deterministinc latency interfaces
[04:01:20] <SWPadnos> I understand the goal, I think
[04:01:45] <SWPadnos> just pointing out what I believe is needed, unless you want to require sub-millisecond command rates (for all axes)
[04:02:34] <jmkasunich> steve_Stallings: emc is architected around realtime - using servos instead of steppers gets you away from sub-millisecond requirements
[04:02:50] <jmkasunich> I guess the next step would be to go from milliseconds to tens or hundreds of milliseconds
[04:03:07] <jmkasunich> that will need more than just hooking into where the cubic interpolators are/were
[04:04:56] <alex_joni> morning all
[04:05:00] <steve_Stallings> my goal is in the region of 2KHz sub-interp updates in "smart amp" with communication at frame rates compatible with USB, i.e. 3 to 4 mS updates
[04:05:19] <cradek> whoah alex is up early
[04:05:24] <alex_joni> yah :/
[04:05:28] <alex_joni> need to leave home too
[04:06:30] <steve_Stallings> JMK - I have kept you up late enough, seeds for thought planted and that is enough for now
[04:06:46] <jmkasunich> goodnight again
[04:08:19] <steve_Stallings> steve_Stallings is now known as steves_logging
[04:08:37] <alex_joni> gotta run
[04:08:42] <alex_joni> jmkasunich: like the new pdf
[06:10:17] <scutsxg> it quiet here