Back
[05:30:23] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[07:26:13] <fenn_> fenn_ is now known as fenn
[15:49:26] <CIA-42> EMC: 03jmkasunich 07TRUNK * 10emc2/docs/src/gcode/main.lyx: minor rewording
[17:08:10] <CIA-42> EMC: 03jmkasunich 07TRUNK * 10emc2/src/emc/motion/motion.c: change name of spindle-at-speed pin, add pin to manpage
[17:08:21] <CIA-42> EMC: 03jmkasunich 07TRUNK * 10emc2/docs/man/man9/motion.9: change name of spindle-at-speed pin, add pin to manpage
[17:09:02] <cradek> jmkasunich: there is also a "emc/motion's interface to hal" lyx document where you could put the same excellent wording
[17:09:32] <jmkasunich> I was just thinking "this should be in the lyx somewhere too" - will do
[17:11:43] <jmkasunich> of course, finding which lyx file is a bit of a challenge
[17:12:57] <jmkasunich> ah, config/emc2hal/lyx
[17:16:41] <jmkasunich> that pin was already in the lyx, I added the new words, kept some of the old, and added a few more
[17:17:59] <CIA-42> EMC: 03jmkasunich 07TRUNK * 10emc2/docs/src/config/emc2hal.lyx: document rename of pin, add some clarification
[17:19:06] <jmkasunich> re: synced outputs - I have some other stuff I need to do today (prep a mcmaster order for this CIM jig repair job, etc)
[17:19:17] <jmkasunich> I might (no promises) take a shot at it this evening
[19:19:27] <seb_kuzminsky> i need better pre-release testing practices...
[19:19:38] <alex_joni> ?
[19:19:48] <jmkasunich> bug report on emc-users
[19:19:54] <jmkasunich> edge case
[19:19:59] <alex_joni> oh, ouch
[19:21:11] <mshaver> Question: The 5120 HAL driver doesn't seem to export the "is_output" parameter for GPIO pins anymore (just updated TRUNK for the first time in a couple months). Is the input/output character of a GPIO pin now determined by the BIT file?
[19:21:50] <seb_kuzminsky> mshaver: hmm, it should
[19:22:02] <seb_kuzminsky> for any gpios that are *not* used by enabled module instances
[19:22:13] <mshaver> I'll re-look at it!
[19:22:21] <mshaver> yep, non module pins
[19:22:32] <seb_kuzminsky> if a module instance (encoder, pwmgen, etc) is using the io pin, then the pin's input/output state is fizxed
[19:22:39] <seb_kuzminsky> but this pin is not used by a module? hmmm
[19:22:52] <mshaver> I'll get a dump of "halcmd show" for you
[19:22:59] <seb_kuzminsky> can you pastebin "dmesg" and "halcmd show"... thanks
[19:23:00] <alex_joni> try one without any modules loaded
[19:23:11] <alex_joni> s/loaded/enabled/
[19:23:16] <mshaver> give me about 5 mins
[19:23:24] <seb_kuzminsky> no dont! that'll tickle the bug eric johnson just found! :-(
[19:23:32] <seb_kuzminsky> one encoder needs to be on... :-(
[19:23:34] <alex_joni> ok, then add one encoder :)
[19:29:33] <jepler> seb_kuzminsky: argh, are we going to need a 2.2.9?
[19:29:36] <jmkasunich> do bugs giggle when you tickle them?
[19:29:49] <mshaver> sorry, I am stupid...
[19:29:50] <jmkasunich> jepler: I don't think so, more of a "don't do that"
[19:30:07] <mshaver> there's just no more P2, P3, etc. in the param names anymore
[19:30:13] <seb_kuzminsky> mshaver: yay for once it's not me being stupid! :-D
[19:30:15] <seb_kuzminsky> mshaver: whoa
[19:30:22] <seb_kuzminsky> mshaver: are you on 2.2.8 or trunk?
[19:30:25] <seb_kuzminsky> * seb_kuzminsky crosses fingers
[19:30:30] <mshaver> TRUNK
[19:30:34] <seb_kuzminsky> yay
[19:30:36] <seb_kuzminsky> yes
[19:30:40] <mshaver> is it different?
[19:30:44] <seb_kuzminsky> that's intentional! woo something went right
[19:31:00] <mshaver> well, for YOU anyway ;)
[19:31:11] <seb_kuzminsky> cradek and jmkasunich suggested naming the gpios differently, and making the load-time info show the stuff differently
[19:31:15] <seb_kuzminsky> so i changed it for trunk
[19:31:19] <alex_joni> jepler: maybe keeping encoder=1 would be ok
[19:31:26] <alex_joni> for 2.2.8
[19:31:50] <mshaver> I did collect a bunch of plots on the following error problems, but I want to be sure it's till a problem with the latest stuff
[19:31:59] <alex_joni> but if 2.2.9 is needed I have 2-3 hours available now (after that I'm MIA until sunday evening)
[19:32:01] <seb_kuzminsky> mshaver: thanks
[19:32:14] <mshaver> I'll rerig my .hal file and report back in 30mins or so
[19:32:20] <seb_kuzminsky> okie dokie
[19:32:20] <mshaver> you're welcome!
[19:32:34] <jmkasunich> alex_joni: I can't imagine this is severe enough to rush a release
[19:32:44] <alex_joni> jmkasunich: ditto
[19:32:50] <seb_kuzminsky> i agree too
[19:33:07] <seb_kuzminsky> i just wish i wasnt so sloppy
[19:51:29] <CIA-42> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/ (TODO encoder.c ioport.c pwmgen.c watchdog.c): add missing sanity checks, should fix the crash Eric Johnson reported
[19:55:56] <alex_joni> heh: + // this should never happen - what's an AnyIO board without IO?
[19:56:19] <alex_joni> how about an AnyIO board with lots of components inside?
[20:18:00] <mshaver> seb_kuzminsky: I'm OK on the 5i20 again
[20:25:42] <alex_joni> no more ferrors?
[20:42:15] <mshaver> I still have ferrors, getting ready to post my info in an e-mail on the users list
[21:00:11] <seb_kuzminsky> mshaver: i'll look forward to it ;-) i wanna lick that bug
[21:02:17] <jmkasunich> first tickling, now licking
[21:02:24] <jmkasunich> tmi
[21:02:47] <mshaver> Way TMI...
[21:04:17] <seb_kuzminsky> what? bugs are tasty is all
[21:06:53] <cradek> I do know that feeling
[21:07:29] <jmkasunich> http://www.instructables.com/id/EL4VNQ4U63EQZJJM8H/
[21:10:14] <jepler> jmkasunich: thanks for that
[21:10:26] <jmkasunich> heh
[21:11:22] <jmkasunich> did your list of acceptable foods just shrink, or did you aready know most of those
[21:11:58] <cradek> sorry, I don't see any "food" there...?
[21:13:41] <mshaver> OK, I'm going to spam a bunch of lines here as I've posted this to the users list, but my posts can take hours or days to show up there, and Seb is here now...
[21:13:49] <mshaver> I've been using the 5i20 to generate step pulses for these drives:
[21:13:49] <mshaver> http://www.mattshaver.com/kc6/DriveYKA2608MG-H.pdf
[21:13:49] <mshaver> It works great, smooth as oiled Teflon on glass!
[21:13:49] <mshaver> Relevant config files:
[21:13:49] <mshaver> http://www.mattshaver.com/kc6/kc6.ini
[21:13:50] <mshaver> http://www.mattshaver.com/kc6/kc6.hal
[21:13:52] <mshaver> The problem is, I get following errors at higher speeds. Some halscope
[21:13:54] <mshaver> plots:
[21:13:56] <mshaver> http://www.mattshaver.com/kc6/g0z2a50.png
[21:13:58] <mshaver> http://www.mattshaver.com/kc6/g0z5a25.png
[21:14:00] <mshaver> http://www.mattshaver.com/kc6/g1z5f10a50.png
[21:14:02] <mshaver> The file names reflect the command that caused the movement, and the max
[21:14:04] <mshaver> acceleration value used.
[21:14:38] <jmkasunich> ohh, chinglish
[21:14:46] <cradek> whoah
[21:14:46] <jepler> in this graph the error is 1.5 inches?
http://www.mattshaver.com/kc6/g0z5a25.png
[21:15:04] <mshaver> yea, probably
[21:15:18] <cradek> 1.6 ish
[21:15:20] <jmkasunich> clearly not getting enough velocity
[21:15:24] <mshaver> I have max ferror set to 100" just to avoid tripping on them
[21:15:32] <jepler> but surely that's useless for milling!
[21:15:48] <mshaver> no problem, it's a lathe! :)
[21:15:52] <skunkworks> heh
[21:16:06] <cradek> it won't follow the programmed path even remotely closely
[21:16:14] <jmkasunich> you commanded 2" in a little over 200mS, that is 10 inches/second
[21:16:16] <mshaver> So far, I haven't cut anything, so I don't know
[21:16:47] <jmkasunich> you got 2 inches in about 350mS, that is 5.7 inches/sec
[21:17:25] <jmkasunich> the axis max velocities are 4 inches/second
[21:17:34] <jmkasunich> what's wrong with this picture
[21:18:14] <mshaver> if I knew, I wouldn't be asking you guys!
[21:18:21] <jmkasunich> 2nd problem, you are setting the stepgen velocities and accels the same as the EMC ones - no headroom
[21:18:44] <jmkasunich> third problem (probably a typo), you are using the AXIS_2 values for both stepgen.01 and stepgen.02
[21:19:36] <mshaver> I guess it is a typo, but they're the same anyway
[21:20:36] <jmkasunich> in the third plot, the requested speed is low enough that the stepgen can track it, so it does (with a small error, probably based on the algorithm seb uses, which requries error proportional to velocity)
[21:20:49] <mshaver> I'll agree there's no headroom, I can fix that, but why is there such a difference between the commanded vel and the max vel in the .ini
[21:21:05] <jmkasunich> that I don't know offhand
[21:22:03] <jmkasunich> how are you creating that move? jog?
[21:22:18] <mshaver> For headroom, if EMC_vel = STEPGEN_vel * X, what is X?
[21:22:21] <mshaver> mdi
[21:22:39] <jmkasunich> 0.9 or so
[21:22:52] <jmkasunich> at least to start
[21:22:54] <mshaver> ok
[21:23:19] <skunkworks> what about accelleration headroom - with the software stepgen - that was more important.
[21:23:28] <jmkasunich> are you at the machine now, or are these stale pics?
[21:23:59] <mshaver> last night, I can do more, it's in the other room
[21:24:05] <jmkasunich> good
[21:24:17] <jmkasunich> are you using Axis?
[21:24:24] <jmkasunich> (I have a feeling I won't like your answer)
[21:24:26] <mshaver> yes
[21:24:26] <cradek> what's the velocity readout say?
[21:24:39] <jmkasunich> oh, good
[21:24:40] <seb_kuzminsky> i'm just listening for now, because i dont have anything to add
[21:24:45] <jmkasunich> what cradek said
[21:25:04] <jmkasunich> do various MDI moves, both G1 Fsomething, and G0
[21:25:07] <mshaver> vel goes up to 240
[21:25:11] <jmkasunich> and sanity check the speeds
[21:25:18] <jmkasunich> 240 ipm = 4 ips = correct
[21:25:46] <jmkasunich> now time a 4" or 8" move, does it take the proper 1 or 2 seconds?
[21:26:02] <jmkasunich> (plus a bit because of accel/decel)
[21:27:17] <mshaver> OK, let me time a move, give me 5 mins
[21:27:48] <cradek> my basic sanity checks here seem to pass
[21:28:10] <seb_kuzminsky> on the two problematic plots that mshaver posted, it looks like motion is asking for more velocity than stepgen delivers, right? so the ferror grows, and that's the fundamental problem
[21:28:14] <seb_kuzminsky> (sorry, i know i'm slow)
[21:28:23] <jmkasunich> seb_kuzminsky: yes
[21:28:41] <cradek> mshaver: there is also axis.2.joint-vel-cmd which might be interesting to check/plot
[21:28:42] <jmkasunich> the question is, why is it asking for so much (which is more an emc problem than a driver problem)
[21:29:03] <seb_kuzminsky> unless hm2.stepgen is delivering less than it promises
[21:29:30] <jmkasunich> well, without actually being able to operate halscope, I can't tell the velocities accurately
[21:29:47] <jmkasunich> but it looks like EMC is asking for 10 ips, stepgen is giving 5.something, and the ini says 4
[21:30:03] <jmkasunich> so pecularities all around
[21:30:43] <jmkasunich> * jmkasunich wants a halcmd prompt on mshaver's machine, this indirect troubleshooting sucketh
[21:30:46] <cradek> http://timeguy.com/cradek-files/emc/mdi-g0-f72.png
[21:30:48] <seb_kuzminsky> mshaver: kc6.ini says 100,000 ns period for base, servo, & traj threads, that seems fast
[21:31:32] <cradek> er, that's a 1" move
[21:31:48] <seb_kuzminsky> the .ini [TRAJ] section says AXES=3 and COORDINATES=X Z, is that normal?
[21:31:53] <jmkasunich> nothing being done in the base thread
[21:32:13] <jmkasunich> and 10KHz for servo does seem extremely fast - mshaver, any reason you aren't using the default 1mS?
[21:32:51] <seb_kuzminsky> the 5i20 can easily handle 10 KHz... but 1 KHz *is* pretty standard
[21:34:03] <seb_kuzminsky> it's confusing to me that axis.0 goes to stepgen.00, but axis.2 goes to stepgen.01, but i guess that should work fine
[21:34:39] <cradek> seb_kuzminsky: yes AXES=3 is correct
[21:34:55] <seb_kuzminsky> cradek: it just skips axis.1 which is Y?
[21:35:23] <cradek> http://www.linuxcnc.org/docs/devel/html/config_ini_config.html#sub:[TRAJ]-section
[21:36:17] <seb_kuzminsky> cradek: thanks
[21:36:49] <cradek> seb_kuzminsky: you don't have to use all of them, but you do have to tell it the highest one you intend to use (I don't remember all the details of why this is, unfortunately - it's a common point of confusion)
[21:37:13] <mshaver> http://www.mattshaver.com/kc6/g0z8f240.png
[21:37:35] <mshaver> An 8 inch move at 240"/min
[21:37:56] <jmkasunich> command moved exactly 8" in exactly 2 seconds (within my ability to read the plot)
[21:38:01] <cradek> sure looks like 2 seconds to me
[21:38:03] <mshaver> The position command takes 2 secs
[21:38:04] <mshaver> yes
[21:38:14] <cradek> nice plot.
[21:38:17] <mshaver> but the axis doesn't get there until later
[21:38:27] <mshaver> i LOVE halscope
[21:38:35] <cradek> I love being vindicated :-)
[21:39:00] <mshaver> I'd love it if this lathe worked...
[21:39:43] <cradek> I wonder what happens if you double stepgen's maxvel
[21:39:52] <seb_kuzminsky> so motion is asking for the right thing (4 ips), and hm2.stepgen isnt delivering, is that what that means?
[21:39:52] <jmkasunich> halcmd show pin 5i20.0.stepgen.*
[21:39:58] <jmkasunich> halcmd show param 5i20.0.stepgen.*
[21:40:01] <cradek> I wonder if it's limiting to a proportion of maxvel, or some random value
[21:40:08] <jmkasunich> pick whatever looks most educational, and scope it
[21:40:11] <cradek> seb_kuzminsky: yes it looks like
[21:40:20] <seb_kuzminsky> i bet my stepgen implementation is just buggy
[21:40:46] <skunkworks> isn't someone else using it also (eric?)
[21:41:06] <seb_kuzminsky> skunkworks: yes, and they're reporting the same problem... :-(
[21:42:05] <jmkasunich> it appears to move about 2.6 divs in 2 seconds, that is 2.6 in/sec, or 65% of the limit
[21:42:21] <cradek> if (s->hal.param.maxvel > max_pos_per_s) {
[21:42:29] <cradek> this test can silently reduce maxvel
[21:42:41] <mshaver> jmkasunich: I think this is up to date:
http://www.mattshaver.com/kc6/kc6.txt
[21:42:51] <mshaver> "halcmd show"
[21:43:29] <jmkasunich> 3.937008 hm2_5i20.0.stepgen.01.maxvel ?
[21:43:34] <cradek> yep
[21:43:37] <jmkasunich> thought it was supposed to be 4.0?
[21:43:41] <cradek> that's what my calculator says the limit will be too
[21:43:49] <skunkworks> heh
[21:43:51] <cradek> mshaver: with your stepspace/steplen, that velocity is impossible
[21:44:35] <jmkasunich> "The upmost pulse response frequence amounts to 200Kpps"
[21:44:37] <mshaver> I was worried about that. What are the units of these, nanoseconds?
[21:44:43] <cradek> yes
[21:44:44] <seb_kuzminsky> ns yes
[21:45:09] <jmkasunich> 200K steps/sec / 50800 steps/in equals you ain't gonna get 4 ips, buddy!
[21:45:20] <mshaver> I spec'ed that based on the drive data sheet.
[21:45:30] <cradek> darn
[21:45:48] <jmkasunich> the drive cannot do 4 ips at that number of steps/inch
[21:46:00] <cradek> you can get a nice 3.75 though
[21:46:16] <jmkasunich> however, there is something else, since it seems to be limiting at 2.6, not 3.9blah
[21:46:26] <cradek> oh
[21:46:38] <mshaver> OK, 3.93... then
[21:47:00] <mshaver> * mshaver even used a calculator
[21:47:29] <cradek> still doesn't explain 2.6 does it
[21:47:51] <mshaver> There is a difference in the two slopes at 180"/min also
[21:48:04] <mshaver> I like the new max velocity slider in axis
[21:48:08] <jmkasunich> the plot thickens!
[21:48:18] <cradek> thanks
[21:48:28] <mshaver> would you like a plot at lower speed?
[21:48:32] <jmkasunich> yes!
[21:48:38] <mshaver> ok, 5 mins
[21:48:42] <jmkasunich> do 2 inches/sec
[21:48:58] <mshaver> your wish is my suggestion
[21:49:09] <jmkasunich> (or whatever, but 2 makes the math easier, exactly half of the original, and below the 2.6 we're getting now)
[21:51:27] <cradek> hm2->stepgen.step_rate_reg[i] = steps_per_sec_cmd * (4294967296.0 / (double)hm2->stepgen.clock_frequency);
[21:51:39] <cradek> here's a nice line that might scale the velocity incorrectly
[21:51:53] <cradek> if it turns out we have a proportional error
[21:52:15] <cradek> seb_kuzminsky: I very much like your self-documented code
[21:52:29] <jmkasunich> ?
[21:52:33] <seb_kuzminsky> ?
[21:52:40] <cradek> ?
[21:52:46] <jmkasunich> you mean the nice variable names, etc?
[21:52:49] <cradek> yes
[21:52:49] <seb_kuzminsky> the buggy code we're debugging now?
[21:52:56] <cradek> yes, it's SO easy to read
[21:53:04] <seb_kuzminsky> heh, thanks :-)
[21:53:22] <cradek> if the women don't find you handsome, they should at least find you handy
[21:53:42] <seb_kuzminsky> i'll let my wife know
[21:53:48] <seb_kuzminsky> i dont think she got that memo
[21:54:01] <skunkworks> only way I get by.
[21:54:40] <jmkasunich> I don't understand line 125
[21:54:55] <jmkasunich> position_at_stop += *s->hal.pin.velocity_fb * seconds_until_stop;
[21:55:09] <seb_kuzminsky> it's one part of a linear equation
[21:55:21] <seb_kuzminsky> i try to decide if it's time to decelerate yet
[21:55:36] <seb_kuzminsky> by looking at where we are now (pos_fb) and where we'd end up if we started decelerating now
[21:55:41] <seb_kuzminsky> if we dont overshoot, i keep going
[21:55:56] <jmkasunich> pos_at_stop = where we are now + how far we'll travel during the stop time, if we keep goiong at the same speed +/- how far we'll travel during the stop time if we are decelling
[21:56:11] <jmkasunich> line 125 is the middle term in that, and I don't see why it is there
[21:56:48] <seb_kuzminsky> s_final = s_now + (v_now * t) + (1/2 * a * t * t)
[21:57:05] <seb_kuzminsky> if i remember my physics, which i might not
[21:57:12] <jmkasunich> right, but why v_now * t?
[21:57:39] <jmkasunich> d = 1/2 a * t^2 covers the movement during decel
[21:58:12] <seb_kuzminsky> jmkasunich: i dont think so
[21:58:15] <seb_kuzminsky> http://en.wikipedia.org/wiki/Equations_of_Motion
[21:59:18] <jmkasunich> which equation?
[21:59:43] <seb_kuzminsky> http://en.wikipedia.org/wiki/Equations_of_Motion#Motion_equation_4
[22:00:04] <seb_kuzminsky> maybe i'm thinking about this wrong, or overcomplicating it or something
[22:00:22] <seb_kuzminsky> i'm not at all wedded to the way i'm currently doing things, if there's a better/simpler/cleaner way i'm all ears
[22:01:30] <seb_kuzminsky> mshaver setp stepspace and steplen to 2500, and the params he linked show they're set right
[22:01:32] <jmkasunich> I think it should be the same as software stepgen (with tweaks as needed to handle the differneces between hw and sw "base thread"
[22:01:33] <jepler> better/cheaper/faster
[22:01:55] <seb_kuzminsky> but then maxvel should be 4.000, and it's 3.93something
[22:02:16] <jmkasunich> it _should_ be 3.93 something
[22:02:39] <jmkasunich> 2500 nS space and len = 5uS period = 200KHz max, which matches the drive spec
[22:02:50] <seb_kuzminsky> oh right, i was forgetting the scale
[22:02:53] <seb_kuzminsky> you're right
[22:02:53] <jmkasunich> 200KHz divided by 50800 steps/inch = 3.93 inches/sec
[22:03:24] <jmkasunich> that problem is matts problem - drives simply won't do more than 3.93
[22:03:40] <jmkasunich> he should probably tell EMC 3.75, and tell stepgen 3.93 - that will give a bit of headroom
[22:03:50] <seb_kuzminsky> with that many microsteps or tpi or whatever gives such a large scale
[22:03:51] <seb_kuzminsky> i see
[22:04:10] <jmkasunich> large scale is why people buy 5i20's
[22:04:33] <cradek> 5i20 can't make the drive go faster than its spec
[22:04:41] <jmkasunich> right
[22:04:52] <jmkasunich> but software stepping would poop out at about 1/4 of that
[22:05:16] <jmkasunich> I'm still stuck on equations of motion
[22:05:56] <seb_kuzminsky> sw stepgen doesnt use them?
[22:06:01] <seb_kuzminsky> or uses them differently
[22:06:09] <cradek> did matt ever send a dmesg?
[22:06:14] <jmkasunich> cradek: no
[22:06:21] <jmkasunich> seb_kuzminsky: it uses them but differnetly
[22:06:33] <mshaver> hold on, got to upload my plot
[22:07:00] <jmkasunich> I'm 100% convinced that the middle term shouldn't be there (in the case of decelling from V to 0)
[22:07:01] <seb_kuzminsky> jmkasunich: without the v*t term?
[22:07:34] <jmkasunich> seb_kuzminsky: it is actually a lot more complex in sw stepgen
[22:07:52] <jmkasunich> but I'm trying to grasp one level at at time
[22:08:21] <jmkasunich> starting with "why is he getting 2.6 ips instead of 3.93"
[22:08:42] <jmkasunich> and now I'm fixated on line 125 since it doesn't compute
[22:09:03] <jmkasunich> v is initial velocity, final velocity is zero
[22:09:07] <jmkasunich> it will take t seconds to stop
[22:09:22] <jmkasunich> the average speed during the stop will be _less_ than V
[22:09:30] <seb_kuzminsky> jmkasunich: it will be v/2
[22:09:36] <jmkasunich> so the distance to stop must be less than v*t
[22:09:38] <jmkasunich> precisely
[22:09:54] <jmkasunich> but line 125 adds v*t
[22:10:09] <jmkasunich> and then lines 127/129 add even more
[22:10:20] <jmkasunich> oh, they subtract
[22:11:17] <jmkasunich> v/2 * t is the same as 0.5 * a * t^2 I bet
[22:11:35] <jmkasunich> so you are adding v*t, then subtracting off 1/2 * v*t
[22:11:48] <mshaver> http://www.mattshaver.com/kc6/g0z8f120.png
[22:11:53] <seb_kuzminsky> jmkasunich: i think you're right
[22:12:12] <jmkasunich> delete 125, invert the += and -= in 127/129, and I think you get the same answer
[22:12:18] <cradek> mshaver: so the slopes are the same, that's good
[22:12:24] <mshaver> [AXIS]MAX_VEL = 3, [TRAJ]MAX_VEL= 2
[22:12:25] <seb_kuzminsky> looks good :-)
[22:12:34] <jmkasunich> yep, this is a limit problem, not a linear problem
[22:12:45] <mshaver> Maybe I'm just too tightly contrained
[22:12:52] <jmkasunich> data = priceless
[22:12:54] <mshaver> constrained
[22:13:03] <jmkasunich> mshaver: your drives limit you to 3.93 inches/sec
[22:13:03] <seb_kuzminsky> halscope = data
[22:13:06] <seb_kuzminsky> ;-)
[22:13:15] <cradek> I'm off to drive home, bbl, wish me luck
[22:13:18] <jmkasunich> but something else is limiting you to 2.6ish, that is probably a bug
[22:13:21] <mshaver> I'll try loosening up my timings
[22:13:23] <seb_kuzminsky> seeya cradek
[22:13:23] <jmkasunich> good luck
[22:13:30] <mshaver> luck!
[22:13:38] <jmkasunich> mshaver: don't loosen the timings!
[22:13:44] <jmkasunich> that will just break the drives in stead
[22:13:50] <jmkasunich> instead
[22:13:51] <mshaver> oh?
[22:14:01] <jmkasunich> your timing specs are correct for the drive
[22:14:14] <mshaver> you mean lower my velocity expectations?!!
[22:14:19] <jmkasunich> the driver is calculating the correct max speed of 3.93 inches/sec (see the show halcmd)
[22:14:46] <mshaver> so 90% of that is probably ok
[22:14:55] <mshaver> say 3.75"/s
[22:15:16] <jmkasunich> if you are married to your expectations, maybe you can adjust the microstep ratio of the drive - I didn't read all the fine print in the manual
[22:15:23] <jmkasunich> but 200KHz is a hard limit
[22:15:48] <jmkasunich> (drive limit, not 5i20 limit - if you exceed that, the optos will be outside their specs, and you might lose steps)
[22:15:51] <mshaver> I played with this a lot and I'd rather just go a little slower than add roughness. It's _really_ nice now.
[22:16:04] <alex_joni> see you all in a couple of days.. have fun (but not too much ;)
[22:16:12] <seb_kuzminsky> seeya alex_joni
[22:16:15] <mshaver> See you alex!
[22:16:15] <jmkasunich> then I'd tell EMC 3.75, and tell the driver 3.93, which will give you some headroom
[22:16:31] <jmkasunich> bye alex_joni, have a fun and safe trip
[22:17:00] <mshaver> I'll set those limits and then see about reducing my max ferror - thanks for all this help!
[22:17:01] <jmkasunich> mshaver: in the meantime, we'll dig into the code and see why you are only getting 2.6ips
[22:17:12] <jmkasunich> that part is almost surely a fixable bug
[22:17:21] <mshaver> oh, you think that's still a problem?
[22:17:30] <jmkasunich> of course
[22:17:36] <mshaver> ugh...
[22:18:01] <mshaver> oh well, I can do plots through tomorrow, then I go home for Christmas
[22:18:17] <jmkasunich> oh, you are at smithy?
[22:18:24] <mshaver> yep
[22:18:35] <mshaver> I'll be back Jan 3rd or so
[22:18:45] <mshaver> probably for the whole month
[22:18:53] <jmkasunich> you need a 5i20 and a PC at home
[22:19:01] <mshaver> and a machine
[22:19:09] <jmkasunich> this is a stepper machine, you don't need the iron on the end of the wires to troubleshoot this
[22:19:16] <jmkasunich> you don't even need the motors or drives
[22:19:25] <mshaver> true
[22:19:56] <mshaver> I do have to come back as we are finally getting in the new control boxes from china
[22:20:00] <jmkasunich> you said that
http://www.mattshaver.com/kc6/kc6.txt is current - it shows a scale of 20000 for stepgen.02
[22:20:12] <seb_kuzminsky> .02 is unused, right?
[22:20:17] <mshaver> I re-uploaded that file just now
[22:20:30] <mshaver> yep
[22:20:44] <jmkasunich> oh, duh
[22:20:55] <mshaver> I need to check this
[22:21:22] <mshaver> I want to be sure I'm not leading you guys into unneeded work
[22:21:25] <jmkasunich> 5 float RW 3.937008 hm2_5i20.0.stepgen.01.maxvel
[22:21:26] <jmkasunich> 5 float RW -50800 hm2_5i20.0.stepgen.01.position-scale
[22:21:49] <mshaver> I did go 8 inches on those moves
[22:21:58] <jmkasunich> that says you ought to be able to get 3.93 inches/second
[22:21:58] <mshaver> I don't think I could be that far off
[22:22:31] <jmkasunich> mshaver: I was looking at stepgen.02
[22:22:41] <jmkasunich> seb corrected me, you are using stepgens 0 and 1
[22:22:51] <seb_kuzminsky> mshaver: any chance you can send us your config dir?
[22:22:51] <mshaver> ah, ok
[22:23:02] <jmkasunich> the scope plots threw me off because you are plotting axis.02
[22:23:03] <mshaver> http://www.mattshaver.com/kc6/
[22:23:18] <seb_kuzminsky> goodness
[22:23:25] <mshaver> gracious
[22:23:32] <seb_kuzminsky> great balls of fire
[22:24:34] <mshaver> jmkasunich: it's the funny way you have to configure for lathe mode
[22:24:41] <jmkasunich> yeah
[22:25:15] <jmkasunich> although now that we're focused on stepgen issues, I'd avoid the problem by pointing halscope at the stepgen pins and/or params
[22:25:27] <mshaver> you can bookmark this link - I'll keep it updated with the latest files
[22:25:39] <mshaver> ok!
[22:25:54] <seb_kuzminsky> i'll play with this tonight when i get home to my 5i20
[22:26:01] <mshaver> THANKS!
[22:26:11] <jmkasunich> I should try this config on my 5i20 box
[22:26:17] <mshaver> I'll be here late, maybe 9 or 10 est
[22:26:33] <mshaver> (443)789-4628 if you need something right away
[22:26:53] <mshaver> plots, etc.
[22:27:07] <seb_kuzminsky> (443)789-4628, is that like #emc-devel?
[22:27:09] <seb_kuzminsky> ;-)
[22:27:10] <jmkasunich> well, if I can reproduce here, I won't need much
[22:27:39] <mshaver> it's more like /join #matt-cellphone
[22:27:57] <mshaver> true, no real encoders even
[22:28:22] <seb_kuzminsky> now there's two of *you*
[22:28:27] <jmkasunich2_> logger_dev: bookmark
[22:28:27] <jmkasunich2_> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-12-16.txt
[22:28:41] <jmkasunich2_> this box has RT and a 5i20
[22:28:58] <jmkasunich> this one doesn't
[22:29:08] <jmkasunich2_> the wonders of kvm ;-)
[22:29:09] <mshaver> I'll fix those typos you found earlier too
[22:29:55] <jmkasunich2_> you are running latest trunk, right?
[22:30:04] <mshaver> yes, todays
[22:30:12] <jmkasunich2_> * jmkasunich2_ does an update
[22:30:41] <mshaver> I got hung up until I did an emc-environment
[22:31:01] <jmkasunich2_> heh - that is second nature here
[22:31:23] <jmkasunich2_> I don't think I actually have EMC installed on this box, only on the shoptask
[22:31:48] <mshaver> I actually never needed it before, but then I installed 2.2.8 also & things got more complicated
[22:33:31] <seb_kuzminsky> mshaver: your config that you showed us is for 2.2, it wont work on trunk
[22:33:37] <seb_kuzminsky> the gpios changed name for trunk
[22:34:07] <mshaver> I took out all the P2s and P3s
[22:34:14] <seb_kuzminsky> ok
[22:34:41] <jmkasunich2_> I just copied all the config files from the dir you posted - as soon as the build finishes we'll see what happens
[22:34:54] <mshaver> is there anything else I have to do?
[22:34:54] <jmkasunich2_> now I remember why I build a faster PC
[22:35:13] <jmkasunich2_> buily
[22:35:13] <mshaver> I also switched to hm2_pci
[22:35:17] <jmkasunich2_> built
[22:35:19] <jmkasunich2_> dang
[22:35:48] <mshaver> I guess hm2_pci detects the type of card & exports pins with the right names?
[22:36:18] <seb_kuzminsky> mshaver: yes it does :-)
[22:36:41] <seb_kuzminsky> mshaver: the gpio rename should be all that's needed to go from 2.2 to trunk
[22:37:08] <mshaver> cool!
[22:37:31] <jmkasunich2_> hmm, that's interesting
[22:37:45] <jmkasunich2_> the config picker is supposed to display a README file if one exists, to describe the config
[22:38:00] <mshaver> yea, it displays a bunch of hash
[22:38:03] <jmkasunich2_> it is displaying kc6.txt instead
[22:38:36] <mshaver> oh! I ignored this as it's the least of my problems...
[22:38:57] <mshaver> I never figured out what it was
[22:39:03] <jmkasunich2_> kc6.hal:32: pin 'hm2_5i20.0.encoder.00.position' does not exist
[22:39:17] <jmkasunich2_> mshaver: agreed - it isn't your problem at all, it is the config-picker's problem
[22:39:51] <jmkasunich2_> hm2/hm2_5i20.0: firmware hm2/5i20/KC62.BIT not found
[22:40:02] <seb_kuzminsky> the BIT file is in the config dir
[22:40:04] <jmkasunich2_> you're gonna have to post your firmware bitfile
[22:40:09] <jmkasunich2_> duh
[22:40:15] <seb_kuzminsky> peter made a custom one for matt
[22:40:26] <jmkasunich2_> yeah, I knew that, just didn't see it in the dir
[22:40:29] <mshaver> like the spaghetti sauce, it's in there!
[22:40:53] <mshaver> * mshaver references an ancient tv commercial
[22:42:04] <jmkasunich2_> * jmkasunich2_ remembers that commercial
[22:42:50] <SWPadnos> Prego
[22:43:01] <jmkasunich2_> woo-hoo - config started
[22:43:06] <mshaver> actually, I thought it was Ragu
[22:43:17] <mshaver> I could be wrong
[22:43:19] <jmkasunich2_> me too
[22:43:24] <SWPadnos> maybe I was speaking Italian :)
[22:44:11] <jepler> surely somewhere along the line prego and ragu were both bought by one of the tobbaco companies, themselves renamed to "inspira" or something else latin-sounding that doesn't remind anybody of cancer
[22:45:02] <mshaver> I was getting ready to spar with SWP, but that comment is way funnier than anything I could have come up with!
[22:45:08] <SWPadnos> heh
[22:45:13] <SWPadnos> Grazie!
[22:45:39] <SWPadnos> speaking of which, I may be required to help cook. RIGHT NOW! :)
[22:45:54] <jmkasunich2_> fsck
[22:45:58] <jmkasunich2_> limit switches
[22:45:59] <mshaver> I'll bet your a good cook!
[22:46:03] <SWPadnos> heh
[22:46:08] <SWPadnos> sometimes
[22:46:12] <SWPadnos> sigh
[22:46:20] <SWPadnos> at least I have load binders now - woohoo!
[22:46:36] <mshaver> whatcha goin to get?
[22:46:54] <jmkasunich2_> SWPadnos: real load binders, or ratchet straps?
[22:48:32] <jmkasunich2_> mshaver: you might have been away when this was asked - why the 10KHz servo period?
[22:48:59] <mshaver> I don't know
[22:49:10] <jmkasunich2_> then change it to 1kHz
[22:49:11] <mshaver> I just sort of put numbers in there
[22:49:15] <mshaver> ok
[22:49:22] <jmkasunich2_> (not likely the cause of this problem, just an observation)
[22:49:46] <jmkasunich2_> fsck again
[22:49:54] <jmkasunich2_> "can't issue MDI command when not homed"
[22:50:02] <mshaver> actually, i thought it was 1ms, must of left off a zero
[22:50:06] <jmkasunich2_> I ain't gots no home switches
[22:50:09] <mshaver> yep, that's new!
[22:50:22] <mshaver> I just noticed it today myself
[22:50:43] <jmkasunich2_> * jmkasunich2_ edits out homing dat
[22:50:44] <jmkasunich2_> a
[22:53:07] <jmkasunich2_> hmm, can't replicate
[22:54:35] <seb_kuzminsky> it steps at the correct rate on your machine?
[22:54:42] <jmkasunich2_> stand by
[22:55:29] <jmkasunich2_> ftw? jog slider is at 120 IPM, not 240 (and that is the top of the scale)
[22:55:58] <jmkasunich2_> grrrrrrr
[22:56:16] <jmkasunich2_> velocities were lowered in the ini file
[22:56:52] <mshaver> sorry, I did that to make the last plot :(
[22:56:54] <jmkasunich2_> don't be messing with stuff!
[22:57:02] <jmkasunich2_> why?
[22:57:12] <jmkasunich2_> we didn't want to see the results of a different config
[22:57:21] <jmkasunich2_> we wanted to see the same config, doing a differnt thing
[22:57:27] <jmkasunich2_> G1F180 vs G0
[22:58:52] <mshaver> sorry, not thinking right
[23:00:28] <jmkasunich2_> yay, I can reproduce the problem
[23:01:19] <jmkasunich2_> interestingly, hm2_5i20.0.stepgen.01.velocity-fb goes to 3.93 ips, however the output clearly is NOT going that fast
[23:02:43] <jmkasunich2_> 2.59 ips actual speed, +/- a bit (reading off scope screen, with benefit of cursor, but not writing down all the digits)
[23:03:25] <mshaver> velocity-fb doesn't match the rate of change in motorpos-fb?
[23:03:40] <jmkasunich2_> right
[23:03:53] <jmkasunich2_> I'm looking right at the driver pins
[23:04:17] <seb_kuzminsky> stepgen.c:177 and 179 is where it converts velocity_fb to fpga-register values
[23:04:38] <jmkasunich2_> it can't be a scale error in that conversion
[23:04:51] <jmkasunich2_> oh, maybe it can
[23:05:03] <jmkasunich2_> must be
[23:05:15] <jmkasunich2_> at 150 ipm, fb tracks cmd
[23:05:30] <jmkasunich2_> but vel-fb says its doing 3.5ish ipm, not 2.5ish
[23:06:09] <jmkasunich2_> now _that_ is weird
[23:06:24] <mshaver> a low pass filter
[23:06:42] <jmkasunich2_> at 120 ipm, it does 2 ips (as it should) and vel-fb also says it is doing 2 ips
[23:07:32] <jmkasunich2_> and at 60 ipm, vel-fb says it is doing 1 ips
[23:08:35] <jmkasunich2_> at 130, vel-fb is oscillating between 2.44 and 2.49
[23:08:52] <jmkasunich2_> lemme stick a couple ddts in here...
[23:10:52] <mshaver> back in 2 mins
[23:13:21] <jepler> fwiw I'm seeing it here too on 2.2.8 with modified kc6 config
[23:13:36] <jepler> my contribution is that with FO set to about 64% the error seems bounded, otherwise it seems unbounded
[23:13:44] <mshaver> back
[23:13:56] <jmkasunich2_> ok, now I'm using ddt's to measure velocity cmd to the driver, and velocity fb from the driver, as well as the driver's own velocity fb
[23:14:56] <jmkasunich2_> for a move at 120 ipm = 2 ips, cmd is 2.005, fb jumps between 1.97 and 2.03, and the driver says between 2.04 and 2.14
[23:15:18] <jmkasunich2_> at 150 ipm = 2.5 ips
[23:15:29] <jmkasunich2_> cmd is 2.506
[23:15:51] <jmkasunich2_> fb is 2.506ish (with a low-pass looking front end)
[23:16:06] <jmkasunich2_> and the driver claims it is doing about 3.5
[23:16:12] <jmkasunich2_> with the same front end
[23:17:40] <jmkasunich2_> at 180 ipm = 3 ips, the cmd is 3.008, the fb is 2.58, and the driver claims 3.93 (it's limit)
[23:20:19] <cradek> data!
[23:23:25] <jepler> hmph, I get an "unexpected realtime delay" everytime I start this config
[23:23:39] <cradek> is it still 10kHz servo cycle?
[23:23:45] <jepler> I didn't change it
[23:23:51] <cradek> that's too fast I guess
[23:24:03] <jmkasunich2_> yes, I had the same thing here
[23:24:11] <jmkasunich2_> I changed to 1ms, problem still happens
[23:24:23] <jepler> it makes the "realtime delay" message go away though
[23:24:26] <jepler> (for me)
[23:25:20] <jmkasunich2_> the code sure seems like it is setting the hardware register to a constant times velocity_fb
[23:25:31] <jmkasunich2_> and that is the hal pin I'm looking at
[23:25:52] <jmkasunich2_> but the position rate-of-change is NOT a constant times the value of that pin
[23:27:03] <jmkasunich2_> I fear.....
[23:27:56] <jmkasunich2_> for velocities up to just under 2 ips = ~100KHz, the driver's idea of velocity, and a ddt of position feedback match
[23:28:06] <jmkasunich2_> above that they diverge by increasing amounts
[23:28:27] <jmkasunich2_> this smells like an fpga issue
[23:29:15] <jmkasunich2_> that frequency is half of the upper limit.... I wonder how peter handles step_len and step_space in the vhdl?
[23:29:27] <jepler> look at what happens when you change stepspace interactively
[23:29:36] <jepler> it can make the graphs match up again (lowering it) or not (raising it)
[23:31:05] <jmkasunich2_> I just lowered steplen and that made it better
[23:31:56] <jmkasunich2_> stepspace has the same effect
[23:32:54] <jmkasunich2_> what seems to matter is the sum of the two
[23:33:02] <jepler> yes I think that's what I'm seeing
[23:33:04] <jmkasunich2_> I tried 4900/100
[23:33:29] <mshaver> i think i just went 50/50 at 200kHz
[23:33:39] <jmkasunich2_> I should had an s32 pin that has the value that is being written to the hardware
[23:33:49] <jmkasunich2_> mshaver: you should do whatever the driver datasheet calls for
[23:33:51] <mshaver> the max input freq of the drive
[23:34:07] <jmkasunich2_> this is clearly a driver or fpga bug tho, wouldn't matter what you did
[23:35:17] <jepler> if (wewouldcount = '1') and
[23:35:17] <jepler> (((waitforhold = '1') or (dirsetupwait = '1') or (waitforpulse = '1')))
[23:35:20] <mshaver> steps on falling edge pulse width > 2.5uS
[23:35:20] <jepler> then -- need to pause
[23:35:23] <jepler> ddshold <= '1';
[23:35:52] <jmkasunich2_> that is vhdl, right?
[23:35:55] <jepler> I think it may hold the dds during the step pulse and step space time
[23:35:57] <jepler> jmkasunich2_: yes
[23:36:11] <jepler> line 278 of kubstepgeny.vhd in TRUNK
[23:36:37] <jmkasunich2_> but if it _always_ holds the dds, then there would be a deviation for any speed, not just above a certain point
[23:36:44] <jepler> hm yes
[23:36:45] <mshaver> um, this is a custom .bit file from peter
[23:36:59] <jepler> maybe it's the 'wewouldcount' that makes it not operate like I was first thinking
[23:37:06] <jmkasunich2_> same stepgen vhdl though, just a different mix of stuff
[23:37:28] <jepler> mshaver: I'm seeing the same things jmkasunich2_ and you are seeing, but I'm using the svst8_4.bit firmware
[23:37:28] <jmkasunich2_> jepler: seems likely
[23:37:34] <mshaver> ok
[23:37:39] <cradek> good!
[23:38:02] <cradek> * cradek waits for peter w to appear
[23:38:28] <jepler> fwiw, my halscope:
http://emergent.unpy.net/index.cgi-files/sandbox/mesa-stepgen-mismatch.png
[23:39:19] <jepler> once again, I'll mention that I'm using 2.2.8; I think jmkasunich2_ said he was on TRUNK
[23:40:13] <seb_kuzminsky> hm2 in 2.2.8 == hm2 in trunk
[23:40:24] <jepler> I should go downstairs and make sure there are no motors attached to the mesa card on this machine I'm testing over ssh :-P
[23:40:33] <jmkasunich> heh
[23:40:36] <jmkasunich> zoom
[23:41:04] <jmkasunich> a little bird just whispered in peters ear (via email), we'll see if that works
[23:43:01] <jmkasunich2_> I should hook up a real scope and see what length pulses are actually coming out
[23:44:41] <jmkasunich2_> of course, that means I need to figure out what pin it is
[23:45:03] <jmkasunich2_> P2-17 says dmesg
[23:45:10] <jmkasunich2_> seb_kuzminsky: I like that feature
[23:48:05] <seb_kuzminsky> jmkasunich: you should, it was your idea! (or cradek's, i dont remember)
[23:50:27] <jepler> seb_kuzminsky: you want a tarball of this config I have, so you can see this behavior for yourself?
[23:50:49] <jepler> (it'll save you a little time compared to starting with mshaver's, since it makes some assumptions about attached hardware)
[23:50:56] <seb_kuzminsky> yes please jeff
[23:51:05] <seb_kuzminsky> mailto:seb@highlab.com
[23:51:10] <seb_kuzminsky> pretty please with a cherry on top
[23:51:14] <seb_kuzminsky> or a url would work ;-)
[23:52:32] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/kc6.tar.gz
[23:52:40] <seb_kuzminsky> thx
[23:53:11] <seb_kuzminsky> i'll check it out after i tuck the munchkins into bed, in about 3.5 hrs
[23:53:19] <jepler> that's about when I'll tuck myself in :-P
[23:53:30] <jepler> ah not quite
[23:55:27] <seb_kuzminsky> ok i'll be back in a bit
[23:55:38] <seb_kuzminsky> jmkasunich, jepler, mshaver, cradek: thanks for the debugging help
[23:55:43] <jmkasunich2_> ok, with the 2500/2500 space/len settings, I'm getting 5uS spaces between 2.5uS pulses
[23:56:37] <jmkasunich2_> which works out to (surprise) 2.62 inches/sec with the 50800 scale
[23:56:59] <mshaver> at ~200kHz commanded vel?
[23:57:12] <mshaver> 3.9"/S
[23:57:15] <jmkasunich2_> at 4ips, so yeah
[23:57:28] <jmkasunich2_> lemme try the lower values I was using earlier
[23:57:46] <jmkasunich2_> I wish I could tell the scope to trigger in mid-move
[23:57:55] <mshaver> well, that's interesting - wish I had brought a scope with me
[23:59:22] <mshaver> maybe hal-generate a sync pulse & output it on a spare pin? a lot of trouble I guess...
[23:59:53] <jmkasunich2_> yeah, I can do it by hand, since the moves are several seconds long
