Back
[08:42:44] <micges> param axis.0.f-errored is not setting true if axis 0 is on following error
[08:47:41] <micges> correct: it is set to True only for few ms
[08:48:49] <micges> is this assumed behavior ?
[09:22:31] <micges> in axis s.axis[0]["ferror_current"] is not updating
[09:39:24] <micges> cool: s.axis[0]["fault"] is updated
[11:48:44] <cradek> following errors are short because as soon as "machine on" is turned off, the following error is gone because commanded position matches actual position
[11:49:05] <cradek> you can trigger scope on f-errored
[11:53:39] <micges> must connect to catch component and will be ok
[12:19:06] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/docs/src/config/stepconf.lyx: fix link to the wiki
[12:19:20] <CIA-40> EMC: 03jepler 07v2_2_branch * 10emc2/docs/src/config/stepconf.lyx: from TRUNK: fix link to the wiki
[14:52:43] <jepler> wow .. the graph of f-error is pretty wild during accel/decel phases
[14:53:16] <cradek> ?
[14:53:30] <jepler> using mr_boo's configuration
[14:53:39] <cradek> stepgen?
[14:53:45] <jepler> yeah
[14:53:46] <jepler> http://emergent.unpy.net/files/sandbox/boo-ferror.png
[14:54:02] <cradek> backlash comp?
[14:54:35] <jepler> no
[14:54:44] <jepler> pure stepconf configuration, no backlash
[14:55:08] <cradek> .035 inches of ferror?
[14:55:14] <cradek> oh mm I bet
[14:55:20] <jepler> yes , mm
[14:55:59] <cradek> what's one step?
[14:56:54] <jepler> inifile [AXIS_0] section:
http://pastebin.ca/1205887 full stepconf file:
http://pastebin.com/m50544576
[14:57:38] <jepler> (realllllly sloooooowwwwww acceleration)
[14:59:23] <jepler> I haven't seen it actually f-error yet but it sure does look weird
[15:00:33] <cradek> 7.6 seconds to get to full speed? seriously? that's just misconfigured
[15:02:12] <jepler> that's probably true but it should also be a valid configuration
[15:02:30] <jepler> axis behaves badly after an abort on a machine with such long decel times
[15:02:44] <jepler> it freezes until the abort is finished or something
[15:02:52] <cradek> hmmm
[15:03:14] <cradek> I bet it's waiting to send some message
[15:03:24] <jepler> can't do that (EMC_TRAJ_SET_TELEOP_ENABLE) in auto mode with the interpreter idle
[15:03:30] <jepler> if I mash other keys right away I get this ^^
[15:03:43] <cradek> yuck
[15:38:20] <skunkworks_> isn't that a max of .00045"?
[15:39:04] <skunkworks_> does it have to do with a 1ms trajetory loop
[15:39:07] <skunkworks_> ?
[15:39:47] <skunkworks_> and a way higher stepgen accelleration headroom? maybe?
[15:40:17] <skunkworks_> * skunkworks_ is quiet now..
[16:00:58] <jepler> I don't have a theory yet :-P
[16:01:35] <jepler> but I did get a following error~
[16:01:36] <jepler> !
[16:02:18] <jepler> doing G0X80000 I was at motor position of about 35000. I hit escape, and during the decel phase I got a joint 0 following error
[16:03:07] <jepler> http://emergent.unpy.net/files/sandbox/boo-ferror2.png
[16:07:01] <jepler> http://emergent.unpy.net/files/sandbox/boo-ferror3.png
[16:08:10] <cradek> always on abort?
[16:09:22] <jepler> no; now that I'm way out at motor position 35000 it readily ferrors on the acceleration phase of a G0 move
[16:09:28] <jepler> that's what -3.png is
[16:10:56] <jepler> increasing stepgen accel headroom from 1.25 to 4 isn't enough to keep it from erroring, but increasing it to 40 is
[16:11:32] <cradek> which part is wrong? motion commanded or stepgen?
[16:13:23] <jepler> good question
[16:15:22] <jepler> after 2s (4 horizontal divs at 500ms/div) the commanded postion has changed by about 1mm (5 vertical divs at 200micro mm) which I think is right for 1mm/s^2 acceleration
[16:15:26] <jepler> -fb is lagging behind it
[18:12:18] <micges> jepler: what indicate flag s.state in emcmodule ?
[18:13:03] <micges> it has only two states (1, 2) and 2 is only for few ms after changing modes
[18:20:43] <jepler> micges: RCS_DONE = 1, RCS_EXEC = 2
[18:21:09] <jepler> so I gather it's 2 if task is actually processing something, and 1 otherwise
[18:41:38] <micges> thanks
[18:44:54] <micges> what is RCS mean ?
[18:45:56] <cradek> Remote Command Something
[18:46:22] <cradek> http://www.ece.osu.edu/nist_rcs_lib/
[18:46:43] <cradek> 'realtime control systems' I guess
[18:47:28] <micges> cool
[19:04:41] <micges> s.axis[0].inpos is not updated
[19:05:06] <micges> correct: s.axis[0]["inpos"]
[19:11:24] <jepler> to be honest I don't know what "inpos" is supposed to do.
[19:11:30] <jepler> I've never used it for anything
[19:11:53] <alex_joni> I think it turns on, while sitting/not moving
[19:12:03] <micges> its always on
[19:12:10] <alex_joni> even while moving?
[19:12:25] <micges> but in HAL axis.0.in-position is updated correctly
[19:12:32] <micges> even while moving
[19:12:45] <alex_joni> well.. guess no-one needs it, so it's probably broken
[19:12:48] <jepler> here (v2_2_branch) I don't see the hal pin or the stat buffer item ever change
[19:13:40] <jepler> during a jog, the hal in-position changes to FALSE for me but stat inpos stays as 1
[19:13:45] <issy> alex , from where is betther to get data's from the nml or the halui
[19:14:04] <alex_joni> halui gets it from NML
[19:14:21] <micges> jepler: here too
[19:14:25] <issy> thanks
[19:14:25] <alex_joni> so I think connecting to halui adds an unneeded delay
[19:14:27] <alex_joni> hi seb_kuzminsky
[19:14:34] <seb_kuzminsky> hi alex
[19:14:44] <alex_joni> back amongst pc's ?
[19:14:52] <micges> s.axis[0]["ferror_current"] is also broken
[19:15:02] <seb_kuzminsky> heh, back amongst pcs with motion control hardware :-)
[19:15:11] <alex_joni> those are the only one that count :)
[19:15:15] <seb_kuzminsky> hehe
[19:15:43] <micges> only mentioning, I get that info from HAL and its ok
[19:15:59] <seb_kuzminsky> how does the motion planned interact with the motion controllers? does it spit out a list of waypoints that get into *.position-cmd?
[19:16:51] <cradek> every time it's run (every TRAJ cycle) it makes a new commanded position along the path
[19:17:08] <seb_kuzminsky> the commanded position is pretty near by usually?
[19:17:17] <alex_joni> yup
[19:17:25] <alex_joni> in an accessible range
[19:17:39] <alex_joni> meaning you should be able to get there (taking into acount max vel/accel, etc)
[19:18:03] <seb_kuzminsky> the maxaccel/maxvel code in hm2 stepgen might interact poorly with that
[19:18:08] <seb_kuzminsky> it does this:
[19:18:32] <seb_kuzminsky> "if i decelerate now at maxaccel, will i overshoot position_cmd?"
[19:18:36] <alex_joni> I think you need the same thing as regular stepgens (some headroom)
[19:18:55] <seb_kuzminsky> "if so, decelerate, if not accellerate but clip to maxvel"
[19:19:45] <jepler> micges: as for ferrorCurrent and ferrorHighMark (C++ names, ferror_current and ferror_highmark in python), it looks like they may just be if'd out for some reason
[19:19:48] <jepler> if (get_emcmot_debug_info) {
[19:19:51] <jepler> stat[axis].ferrorCurrent = joint->ferror;
[19:19:53] <jepler> stat[axis].ferrorHighMark = joint->ferror_high_mark;
[19:19:56] <jepler> }
[19:19:58] <jepler> in taskintf.cc around line 566
[19:20:22] <seb_kuzminsky> what's the headroom of the sw stepgen?
[19:20:40] <alex_joni> usually 20-40%
[19:21:07] <seb_kuzminsky> meaning, the stepgen driver keeps 20-40% of maxaccel "in reserve"?
[19:22:54] <alex_joni> I know it used to, not sure if this changed lately
[19:23:13] <seb_kuzminsky> hm
[19:24:30] <seb_kuzminsky> i dont see how it can build up any kind of speed in that situation. if the tp gives it a nearby position-cmd, it's going to seek a velocity which allows it to decelerate to a stop in the requested distance (ie: low speed)
[19:24:50] <seb_kuzminsky> maxvel only comes into play on long moves
[19:25:30] <alex_joni> I don't think your stepgen needs to take the "if I decelerate now at maxaccel, will I overshoot pos_cmd" part
[19:25:49] <alex_joni> the position cmds that come from motion controller are all valid points
[19:25:56] <alex_joni> so you should be able to get there
[19:27:24] <seb_kuzminsky> do you mean, stepgen.maxaccel should be +Inf, and tp.maxaccel should be the true maxaccel of the stepper?
[19:29:14] <alex_joni> no.. I mean you get the next pos_cmd
[19:29:31] <alex_joni> and you just try to get there using max_accel and max_vel (if it's applicable)
[19:30:33] <cradek> when you get a new pos every cycle, d_pos/period (the velocity) will be <= tp.maxvel, and d_velocity/period (the accel) will be <= tp.maxaccel
[19:30:56] <alex_joni> cradek: you still have to clamp just in case
[19:31:20] <seb_kuzminsky> cradek: that makes perfect sense, the tp has its own maxvel & maxaccel that it enforces
[19:31:24] <cradek> I think your challenge, should you choose to accept it, is to make a nice smooth step pulse ramp to that new velocity
[19:31:28] <alex_joni> seb_kuzminsky: I think the best answers you should get from jmkasunich (when he's around)
[19:32:08] <seb_kuzminsky> cradek: i accept! and i understand that's the challenge, and that challenge has me confused:
[19:32:08] <cradek> yeah, I'm nearly clueless about how stepgen works, he's the smart one about it
[19:32:34] <seb_kuzminsky> i get *only* a new pos-cmd from tp
[19:32:59] <seb_kuzminsky> i have to try to get there using *my* maxvel and maxaccel
[19:33:21] <seb_kuzminsky> the maxaccel is the controlling parameter for the "smooth step pulse ramp" part of the challenge
[19:33:37] <alex_joni> right
[19:34:09] <seb_kuzminsky> let's say pos-fb is 0, maxvel is 1, and maxaccel is 1, and tp says: pos-cmd=1
[19:34:25] <seb_kuzminsky> oh yeah, and vel-fb is 0
[19:34:30] <alex_joni> I think the way to debug this is by doing a halscope of motion cmd_velocities, vs. stepgen fb_velocities
[19:35:00] <alex_joni> so you were standing still.. and you need to go to 1 in the next servo cycle
[19:35:17] <seb_kuzminsky> so i start accelerating at 1/s*s until i get halfway there, now pos-fb is 0.5 and vel is 0.5...
[19:35:19] <alex_joni> I doubt you can do that with maxvel (1 unit / second) and maxaccel (1 unit /s^2)
[19:35:28] <jepler> seb_kuzminsky: the situation you describe would mean that you have a bad configuration, since it's unreachable
[19:35:37] <seb_kuzminsky> and if i want to implement the pos-cmd of 1, i need to decelerate
[19:35:40] <seb_kuzminsky> hmmm
[19:35:55] <alex_joni> seb_kuzminsky: the next time you check your position (servo-thread), you will already have a new position target
[19:36:11] <seb_kuzminsky> alex_joni: ah...
[19:36:25] <alex_joni> remember they get called in a specific order
[19:36:29] <jepler> (if you're talking about a full emc setup; if you're just giving position inputs from a halcmd, then software stepgen will give a trapezoidal motion profile to the endpoint)
[19:36:32] <seb_kuzminsky> and it's far enough away that i can keep accellerating...
[19:36:54] <seb_kuzminsky> jepler: right, and a big part of my problem is i'm running hal & hm2 without the other components
[19:36:58] <cradek> yes you don't have to worry about the future. you just need to get to the specified point
[19:37:16] <seb_kuzminsky> i should set up the rest of it in a full machine config (hm, and maybe build a machine too)
[19:37:32] <alex_joni> a sim only config should be fairly simple
[19:38:03] <cradek> hm, you can't see the step pulses in halscope. that's kind of a pain I bet.
[19:38:03] <jepler> seb_kuzminsky: btw Saturday September 27 still looks like the day I'll be in Boulder.
[19:38:15] <jepler> seb_kuzminsky: is that still going to work for you?
[19:38:31] <seb_kuzminsky> so in a normal configuration, tp gives you a pos-cmd that's so far away that it's not time to decelerate yet
[19:38:47] <seb_kuzminsky> that's part of the setup of a sane machine
[19:38:53] <seb_kuzminsky> jepler: sounds great!
[19:38:57] <alex_joni> unless the pos-cmd is closer and you need to decelerate to reach it in exactly one servo-period
[19:39:20] <jepler> seb_kuzminsky: I expect there will be 3 of us -- me, my gf, and one of the people we're visiting
[19:39:25] <alex_joni> seb_kuzminsky: the idea is that you need to adjust your velocity so you reach the target_pos in the next servo_period
[19:39:54] <seb_kuzminsky> alex_joni: subject to maxaccel and maxvel
[19:40:09] <cradek> I don't think you need to worry about maxvel
[19:40:29] <seb_kuzminsky> if the tp's doing it's job, it's keeping pos-cmd far enough away from pos-fb that you cruise most of the time (ride at the top of the trapezoid)
[19:41:11] <cradek> in a rapid you will get new points that are period*maxvel apart
[19:41:21] <seb_kuzminsky> jepler: you guys up for some hiking & dinner & beer? afternoon/evening-ish?
[19:41:23] <cradek> that's cruise at maxvel
[19:41:25] <seb_kuzminsky> cradek: right
[19:41:42] <cradek> IMO you don't have to check anything against any maxvel
[19:41:48] <jepler> seb_kuzminsky: yeah that sounds good, assuming the weather cooperates
[19:42:07] <seb_kuzminsky> then why does the sw stepgen have maxvel & maxaccel? if the tp takes care of that
[19:42:15] <alex_joni> cradek: what if someone wants to use the stepgen independent from motion?
[19:42:25] <cradek> seb_kuzminsky: ^^
[19:42:29] <alex_joni> HAL only.. set a target pos 10" away, and wait for it to get there
[19:42:36] <alex_joni> it does need to clamp on max_vel
[19:42:43] <jepler> alex_joni: you can use a limit3 block for that
[19:42:53] <alex_joni> jepler: inside the fpga?
[19:43:09] <alex_joni> or on the setp command?
[19:43:12] <jepler> alex_joni: all seb_kuzminsky gets to do is send a new velocity command to the fpga once per ms anyway
[19:43:13] <cradek> I have no opinion except I believe that is not a feature needed for operation with emc
[19:43:30] <alex_joni> I agree that it's not needed with emc operation
[19:43:34] <jepler> ( .. I think, anyway, that the fpga doesn't do velocity ramping)
[19:43:41] <seb_kuzminsky> jepler: that's right
[19:43:53] <cradek> oh? then there's nothing to do is there?
[19:44:15] <alex_joni> then I guess the way to do this is use a siggen or whatever to drive it in HAL-only mode
[19:44:22] <seb_kuzminsky> any ideas why matt shaver and eric johnson are getting following errors with hm2.stepgen?
[19:44:29] <alex_joni> or maybe a software stepgen :D
[19:44:39] <cradek> I thought you were writing velocity slewing for something that runs faster than the TP
[19:44:57] <jepler> so in the hypothetical standalone case, use limit3 to get a curve that follows constraints. then all hm2 has to do is create velocity commands that hit the position commands, using a maxaccel hint if necessary
[19:45:34] <seb_kuzminsky> tp runs every 10 ms or so, right?
[19:45:37] <alex_joni> jepler: right, I agree (and we should drop max_vel from here on)
[19:45:41] <alex_joni> seb_kuzminsky: 1 ms
[19:45:43] <cradek> seb_kuzminsky: depends
[19:45:46] <alex_joni> usually
[19:45:58] <seb_kuzminsky> ok call it 1 ms
[19:46:01] <alex_joni> some run it at 5kHz vs. the regular 1kHz
[19:46:03] <cradek> some of our old configs have it running at 10ms but I run it at .5ms on my machine
[19:46:26] <alex_joni> lets call it 1 ms then :)
[19:46:34] <cradek> if it's running less often, you don't care, you still get a new position every ms (servo cycle)
[19:46:44] <seb_kuzminsky> hm2 on the 5i20 runs comfortably at 10 KHz or so
[19:47:09] <cradek> so traj period is a red herring - at every servo cycle you get a new position.
[19:47:34] <alex_joni> I don't think seb is familiar with traj vs. servo thread, and that's ok :)
[19:47:42] <seb_kuzminsky> boy howdy am i confused
[19:47:49] <alex_joni> seb_kuzminsky: sorry :)
[19:47:52] <cradek> uh-oh
[19:48:14] <seb_kuzminsky> i started at the bottom and didnt climb very far up your software stack :-/
[19:48:28] <alex_joni> the very upper layers are not that interesting here
[19:48:46] <seb_kuzminsky> isnt it from the upper layers that the following error is coming from?
[19:48:48] <alex_joni> interpreter reads the g-codes converts that to simple commands (linear moves, circular, etc)
[19:49:01] <alex_joni> that gets sent to the motion controller (first layer which is RT)
[19:49:15] <alex_joni> motion controller takes the current move it needs to perform
[19:49:28] <alex_joni> and splits that into points (pos_cmd's)
[19:49:42] <alex_joni> every time the code gets called, it spits out a new target position
[19:50:08] <alex_joni> it also looks at the feedback position, and if the last target position and the feedback position are too far apart it calls it a following error
[19:50:27] <alex_joni> ferror makes a lot of sense with servo motors (imagine a DC motor + encoder)
[19:50:39] <alex_joni> motion commands a certain move, but the drive is busted, motor doesn't move
[19:50:50] <jepler> for steppers it's a good way to say "you have a bug, or misconfiguration, or maybe both" :-P
[19:50:54] <alex_joni> the difference between pos_cmd and pos_fb is getting bigger
[19:51:12] <alex_joni> if it's bigger then a certain value (in the ini) you have an error condition
[19:51:21] <alex_joni> for steppers ferrors shouldn't happen
[19:51:32] <alex_joni> unless there is something broken (like jepler said)
[19:51:50] <alex_joni> * alex_joni waits for seb_kuzminsky to read ^^
[19:51:51] <seb_kuzminsky> yes i see...
[19:52:37] <alex_joni> so say you were moving at a certain speed, and you are in a certain position (when your function gets called again)
[19:52:50] <alex_joni> you get a new pos_cmd, and you need to adapt your speed to that
[19:53:22] <alex_joni> I think the software stepgen only adapts speed in the servo-period function, and the make-pulses only outputs steps at the computed velocity
[19:53:41] <seb_kuzminsky> that's like hm2, except here make-pulses is in the fpga
[19:54:19] <alex_joni> but going into greater detail involves some guessing from my side.. so I shouldn't do that :)
[19:54:43] <seb_kuzminsky> you talked about interpreter, motion controller, and servo-thread
[19:54:55] <alex_joni> skipping a lot of boring details :)
[19:54:57] <seb_kuzminsky> interp can run pretty slow, mc a bit faster, and servo faster still
[19:55:06] <seb_kuzminsky> there's a faster one called "base" too, right?
[19:55:08] <alex_joni> interp actually runs the fastest :D
[19:55:21] <seb_kuzminsky> durr
[19:55:22] <alex_joni> but it depends what you understand under fast :)
[19:55:32] <alex_joni> you have a program.. lets say 10 lines long
[19:55:44] <alex_joni> interp finished reading and interpreting it in about .1 second
[19:55:59] <alex_joni> way before motion even started moving the motors up to cruise speed
[19:56:23] <alex_joni> let me be a bit more specific (maybe you get a better picture)
[19:56:25] <seb_kuzminsky> by "fast" or "slow" i meant the frequency with which it gets called, not how much wallclock time it takes, but i see what you mean
[19:56:39] <alex_joni> there is a software component called task
[19:56:51] <alex_joni> which is the main emc2 glue point
[19:56:56] <alex_joni> where all components meet
[19:57:08] <alex_joni> task is a process which contains the interpreter
[19:57:19] <alex_joni> task makes sure to call the interp. when a file needs to be run
[19:57:32] <seb_kuzminsky> k
[19:57:42] <alex_joni> the GUI (one of the GUI's, or maybe even more than one) are connected to task
[19:57:49] <alex_joni> that's the path the user interacts with emc2
[19:57:59] <alex_joni> (push various things, do jogging, load programs, etc)
[19:58:06] <seb_kuzminsky> ok
[19:58:30] <alex_joni> another component connected to task is the iocontroller (has a bunch of HAL pins like iocontrol.0.lube)
[19:58:38] <seb_kuzminsky> mmm, lube
[19:58:51] <alex_joni> not _that_ kind of lube :P
[19:58:55] <seb_kuzminsky> aw
[19:59:13] <alex_joni> ok.. these 3 things (task, gui, iocontroller) are all non-realtime
[19:59:18] <seb_kuzminsky> ok
[19:59:20] <alex_joni> means they run as regular linux tasks
[19:59:35] <seb_kuzminsky> iocontroller is sort of like an abstract interface to the machine, right?
[19:59:37] <alex_joni> they can be preempted, they can sleep for a couple seconds (in extreme cases)
[19:59:50] <alex_joni> it's a HAL interface for some non-RT pins
[19:59:57] <seb_kuzminsky> hm, ok
[20:00:08] <alex_joni> stuff that isn't required to update at a very precise moment
[20:00:12] <seb_kuzminsky> sur
[20:00:13] <alex_joni> like coolant on/off
[20:00:15] <alex_joni> etc..
[20:00:32] <alex_joni> (sidetrack: it could just as well be included in the RT part..)
[20:00:45] <alex_joni> ok.. lets get back to the 3 (GUI, task, io)
[20:00:52] <alex_joni> these "talk" through NML channels
[20:01:04] <seb_kuzminsky> some kind of message-oriented ipc?
[20:01:15] <alex_joni> which are certain kind of datapaths, which can be across different machines
[20:01:30] <alex_joni> it's called Neutral Message Layer (or something along those lines)
[20:01:39] <seb_kuzminsky> something like tcp sockets?
[20:01:49] <alex_joni> it uses tcp sockets yeah
[20:01:52] <seb_kuzminsky> k
[20:02:02] <alex_joni> we can probably talk more than 2-3 days about it :)
[20:02:17] <alex_joni> anyways.. it's a datapath across machines, even across OS's
[20:02:36] <alex_joni> (you could in theory have each of the 3 running on different machines with different OS's)
[20:02:47] <alex_joni> the 4th component is the RT motion controller
[20:02:57] <seb_kuzminsky> ah! the part i've actually heard about!
[20:03:01] <alex_joni> task talks to the motion controller through a SHM (shared memory)
[20:03:48] <alex_joni> that's one of the few possible IPCs between a linux task and a RT task
[20:04:05] <seb_kuzminsky> right, shm makes sense there
[20:04:11] <alex_joni> so.. the user wants to run a program (starts doing that from the GUI)
[20:04:34] <alex_joni> that action gets sent to task which opens the file, and gets interp to interpret it
[20:04:48] <alex_joni> interp converts the g-code into canonical codes (basic machine operations)
[20:04:58] <alex_joni> and puts those on the interpreter queue
[20:05:16] <alex_joni> tasks takes things from the interp queue, and sends them to motion through SHM
[20:05:31] <seb_kuzminsky> motion is a RT thread?
[20:05:36] <alex_joni> the motion controller takes the commands from the SHM, and puts them in a TC queue
[20:05:52] <alex_joni> not a RT thread, it's a RT function called from the servo_thread
[20:05:58] <seb_kuzminsky> ok
[20:06:00] <alex_joni> s/from the/at the rate of/
[20:06:59] <seb_kuzminsky> these canonical codes are things like "linear move to 100,100,100"?
[20:07:04] <alex_joni> so when motion gets called (each servo cycle) it takes one command from the shm (only one fits there) and processes it (usually it's something like: queue a linear move towards whatever)
[20:07:15] <alex_joni> seb_kuzminsky: yeah
[20:07:32] <alex_joni> linear moves (with feedrate), linear traverse (max speed), circular, probing,
[20:07:35] <alex_joni> IO stuff
[20:07:36] <alex_joni> etc
[20:07:39] <seb_kuzminsky> k
[20:08:13] <alex_joni> ok.. so after motion processed the command it does a couple more things
[20:08:33] <alex_joni> it checks limits
[20:08:58] <alex_joni> it updates a bunch of other things (which skip my mind without looking) :)
[20:09:05] <alex_joni> it calles the TP (Trajectory planner)
[20:09:18] <alex_joni> ok, the TP is probably the part you care about
[20:09:29] <seb_kuzminsky> hold on a sec
[20:09:33] <alex_joni> * alex_joni holds
[20:09:53] <seb_kuzminsky> the motion takes one canonical command each time it's called? it might take much longer to implement each command, no?
[20:10:07] <alex_joni> it takes it and puts it on a queue
[20:10:15] <alex_joni> doesn't always execute it right away
[20:10:41] <seb_kuzminsky> interp makes a command like "move one foot away at one inch per minute" and sends it to motion
[20:10:42] <alex_joni> there are some commands (like set feed override, or set some thing which happen right away)
[20:10:55] <seb_kuzminsky> motion works on that one command for uh like 12 minutes
[20:11:04] <seb_kuzminsky> then motion takes the next command from interp
[20:11:06] <seb_kuzminsky> ?
[20:11:10] <alex_joni> nope
[20:11:20] <alex_joni> motion takes the command from shm and puts it on a queue
[20:11:34] <alex_joni> the next time it gets called it can take another command and put it on the queue
[20:11:37] <alex_joni> etc..
[20:11:50] <alex_joni> it will however take 12 minutes to process the first item from the queue
[20:12:01] <alex_joni> and then only it will go to the next thing on the queue
[20:12:05] <seb_kuzminsky> ok, and it's tp that processes things from motion's queue?
[20:12:10] <alex_joni> right
[20:12:12] <seb_kuzminsky> ah
[20:12:26] <seb_kuzminsky> to interp makes canonical commands, motion validates them (limits etc) and gives them to tp
[20:12:34] <alex_joni> kinda :)
[20:12:37] <seb_kuzminsky> heh
[20:12:47] <cradek> wow, a lot of words since I left
[20:12:51] <seb_kuzminsky> "the devil's in the details, and it's *all* details"
[20:12:51] <alex_joni> conceptually it's pretty close :)
[20:13:01] <seb_kuzminsky> cradek: alex_joni keeps smacking me with the clue bat
[20:13:20] <alex_joni> now that we have a queue with commands, and TP is there to do something with it I'll pass the word to cradek
[20:13:28] <alex_joni> seb_kuzminsky: hint: TP is his baby
[20:14:19] <seb_kuzminsky> do the commands in the motion->tp queue look just like the commands in the interp->motion queue?
[20:14:25] <alex_joni> no
[20:14:31] <seb_kuzminsky> oh good :-)
[20:14:34] <alex_joni> well.. as you said .. details
[20:14:58] <alex_joni> but only a couple things from the interp queue end up on the tp queue
[20:15:11] <seb_kuzminsky> right, for example no lube ;-)
[20:15:16] <alex_joni> exactly :D
[20:15:20] <alex_joni> TP likes it rough
[20:15:32] <seb_kuzminsky> chips flying everywhere, i get it
[20:15:51] <seb_kuzminsky> but still, tp gets commands like "move 1 foot @ 1 ipm"
[20:15:54] <alex_joni> right
[20:16:11] <alex_joni> and then it's TP's job to spit out new pos_cmd's every servo cycle
[20:16:22] <alex_joni> it knows it runs every 1 msec
[20:16:27] <seb_kuzminsky> tp runs in the servo thread, like motion?
[20:16:32] <alex_joni> yup
[20:16:38] <cradek> motion actually runs it
[20:16:40] <alex_joni> motion is a bunch of function calls:
[20:16:45] <alex_joni> process_inputs()
[20:16:50] <alex_joni> do_forward_kins()
[20:16:56] <alex_joni> check_for_faults()
[20:17:03] <alex_joni> set_operating_mode()
[20:17:07] <alex_joni> handle_jogwheels()
[20:17:15] <alex_joni> get_pos_cmds()
[20:17:24] <alex_joni> compute_screw_comp()
[20:17:28] <alex_joni> output_to_hal()
[20:17:33] <alex_joni> update_status()
[20:17:47] <alex_joni> - now I bet you're really confused :)
[20:18:08] <alex_joni> * alex_joni tries to fit hm2 in the above functions
[20:18:12] <seb_kuzminsky> getting less confused by the minute, your descriptions are great
[20:18:19] <alex_joni> process_inputs() read the _fb pins
[20:18:20] <seb_kuzminsky> hm2 comes later, after tp
[20:18:25] <seb_kuzminsky> oh i see
[20:18:45] <alex_joni> do_forward_kins() we skip for now (it applies to robots and oligopods :D)
[20:18:57] <seb_kuzminsky> goes from axes to joints, right?
[20:18:59] <alex_joni> check_for_faults() -> reports the ferror
[20:19:02] <alex_joni> right
[20:19:30] <alex_joni> set_operating_mode() and handle_jogwheels() are not relevant while running a program
[20:19:47] <alex_joni> get_pos_cmds() -> calls TP to generate a new pos_cmd
[20:20:01] <seb_kuzminsky> based on the current command on the queue from interp
[20:20:06] <alex_joni> right
[20:20:19] <alex_joni> and based how far along inside that move it already progressed
[20:20:27] <alex_joni> and based on the current velocity
[20:20:31] <seb_kuzminsky> right, based om the info from process_inputs etc
[20:20:35] <cradek> and feed override etc
[20:20:55] <seb_kuzminsky> and cutter comp maybe?
[20:21:01] <alex_joni> yeah, add feed_override, adaptive_FO and spindle_override in there, and it gets crazy
[20:21:07] <cradek> no, the interpreter comps the path before motion sees it
[20:21:12] <seb_kuzminsky> ok
[20:21:15] <alex_joni> cutter comp is done before the interp queue is filled
[20:21:25] <seb_kuzminsky> ok i'll shut up & listen :-)
[20:21:45] <alex_joni> although cradek was pondering on moving cutter comp somewhere else...
[20:21:57] <cradek> only until I regained my sanity
[20:22:04] <alex_joni> heh
[20:22:11] <alex_joni> ok.. so TP generates a next position
[20:22:26] <seb_kuzminsky> so the TP in get_pos_cmds() makes a new set of pos-cmd values
[20:22:32] <alex_joni> right
[20:22:52] <alex_joni> those might get "adapted" for screw errors (unusual ..)
[20:23:06] <alex_joni> and then they get written to the pos_cmd pins
[20:23:26] <alex_joni> then HAL (after the motion controller function finished) calls the next function in the thread
[20:23:35] <alex_joni> which is probably the hm2-mumble
[20:23:43] <seb_kuzminsky> in the servo thread
[20:23:46] <alex_joni> right
[20:24:01] <seb_kuzminsky> something like: hm2_read(); motion(); hm2_write();
[20:24:07] <alex_joni> 'xactly
[20:24:21] <seb_kuzminsky> ok...
[20:24:28] <alex_joni> you see motion() follows the same rules.. (read, process, write)
[20:24:35] <seb_kuzminsky> sure
[20:24:49] <alex_joni> any other way and you get odd results :)
[20:24:57] <alex_joni> (we had that happen at times..)
[20:25:07] <seb_kuzminsky> intuit(); search_feelings(); write_cmd();
[20:25:22] <alex_joni> users adding the write function at the beginning of the servo thread
[20:25:38] <alex_joni> so things were out of sync by one servo cycle.. messy :D
[20:26:00] <seb_kuzminsky> thanks for that explanation, some things are starting to fall into place for me now
[20:26:10] <alex_joni> I'm happy if that's so :)
[20:26:28] <alex_joni> and I'm sorry I couldn't point you to some docs that would explain the same things ..
[20:26:41] <alex_joni> not that I don't like explaining them..
[20:27:04] <seb_kuzminsky> motion (or is it tp) has its own maxvel and maxaccel limits for each axis (or is it joint)
[20:27:24] <cradek> tp runs in axis space
[20:27:30] <cradek> maxvel and accel are axis limits
[20:27:37] <alex_joni> yeah, now..
[20:27:43] <alex_joni> they should be joint limits though
[20:27:51] <seb_kuzminsky> alex_joni: makes sense
[20:28:19] <alex_joni> http://www.linuxcnc.org/images/stories/EMC_Control_LG.gif
[20:28:32] <alex_joni> seb_kuzminsky: that's slightly outdated, but it's still pretty valid :)
[20:28:55] <seb_kuzminsky> thx, looking at it now
[20:29:47] <alex_joni> from here:
http://www.linuxcnc.org/content/view/42/13/lang,en/
[20:31:14] <alex_joni> the stepgen docs should be also quite interesting:
http://www.linuxcnc.org/docview/devel/html//hal_rtcomps.html#sec:Stepgen
[20:31:30] <alex_joni> (gotta run for a while.. bbl)
[20:31:38] <seb_kuzminsky> thanks a lot alex!
[20:31:58] <alex_joni> seb_kuzminsky: sure thing
[20:53:17] <seb_kuzminsky> cradek: have you had a chance to try hm2.pwmgen lately?
[20:56:26] <cradek> no I haven't tried it since that first time
[20:57:08] <cradek> I think there is a thing keeping me from using it - but I don't remember what it is
[20:57:35] <cradek> maybe it's index mask?
[21:03:05] <seb_kuzminsky> hm2 has no index mask yet
[21:03:22] <seb_kuzminsky> i was just curious about the pwmgen bug, i think i got it squished
[21:03:38] <jepler> cradek: we got that special firmware e-mailed from peter that was supposed to have the index mask pins available
[21:04:23] <jepler> bbl
[21:05:58] <cradek> jepler: oh, cool
[21:09:05] <cradek> whee, time for the weekend to start
[21:24:04] <alex_joni> back.. guess I didn't miss much
[22:03:09] <seb_kuzminsky> hi alex
[22:05:24] <alex_joni> hey seb
[22:07:48] <seb_kuzminsky> i think the crux of my present problem (following error) is in the pos-cmd that tp outputs
[22:08:12] <alex_joni> go on..
[22:08:44] <seb_kuzminsky> is it true that this cycle's pos-cmd from tp is (servo-peroid * tp.maxvel) away from pos-fb (modulo tp.maxaccel)?
[22:10:36] <alex_joni> modulo?
[22:10:49] <seb_kuzminsky> "ignoring"
[22:11:13] <alex_joni> hmm.. this cycle pos-cmd can be 0..servo-period*tp.maxvel from the last pos-cmd
[22:11:33] <seb_kuzminsky> thx
[22:11:41] <alex_joni> actually -1 * servo_period*tp.maxvel .. servo_period * tp_maxvel
[22:11:56] <alex_joni> but I can't say about pos-fb..
[22:12:07] <alex_joni> the TP doesn't care much about fb
[22:12:22] <alex_joni> only the motion controller watches the difference between cmd and fb
[22:12:28] <alex_joni> and if it's too large it errors
[22:12:47] <seb_kuzminsky> for motion-controlled (as opposed to stand-along) stepgens, shouldnt stepgen.maxaccel be +Inf, and let the tp worry about it?
[22:12:57] <seb_kuzminsky> *stand-alone
[22:14:31] <alex_joni> theoretically yes..
[22:14:45] <alex_joni> but we fixed a lot of TP problems by having limits in stepgen aswell :)
[22:18:58] <alex_joni> seb_kuzminsky: I still think you need to get a grip on jmkasunich , when he'll be around
[22:19:19] <alex_joni> I have only some conceptual knowledge about this stuff, he knows it way better
[22:21:01] <alex_joni> and the downside of beeing way over the pond, is that it's about bedtime for me
[22:21:12] <alex_joni> (or past.. whichever way you want to look at it :P)
[22:22:34] <alex_joni> good night all
[22:22:46] <seb_kuzminsky> ok thanks again alex
[22:22:46] <seb_kuzminsky> good night
[22:22:47] <alex_joni> seb_kuzminsky: anytime
