Back
[00:44:13] <dgarr> jepler: i tested patch for adding set-manual-mode to axisui with my hardware today -- it works fine for my purposes
[00:52:13] <CIA-8> EMC: 03jepler 07master * r5de7d64b28e3 10/src/emc/usr_intf/axis/scripts/axis.py: add pin to set axis gui to manual mode so pendant can issue some commands
[00:52:22] <CIA-8> EMC: 03jepler 07master * rd675639da73d 10/src/emc/task/Submakefile: remove milltaskcanon, nobody uses it
[00:53:44] <jepler> dgarr: cool
[00:54:07] <jepler> hm, not sure I meant to push both :-/ oh well, let those who used milltaskcanon speak
[00:58:02] <dgarr> thanks!
[02:01:49] <jepler> * jepler kicks his dsl a few times for good measure
[02:05:40] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[02:09:33] <jepler> * jepler kicks his dsl a few times for good measure
[02:09:43] <cradek> you tried that already
[02:09:58] <cradek> it's not even raining
[02:14:22] <jepler> oh I had no idea that the first kick actually went out on the intertubes
[03:01:21] <jepler> meh
[03:04:34] <LawrenceG> whats cooking Jeff?
[03:06:42] <jepler> LawrenceG: just having connectivity issues
[03:07:19] <LawrenceG> bummer
[03:07:31] <jepler> I'll live, but you guys have to put up with me repeatedly pinging out
[03:10:03] <LawrenceG> I have been playing with the dspic33 series chips.... I now have a dual channel quadrature drive servo board running... speedy little chips... fp in C, nothing special
[03:10:36] <jepler> cool
[03:12:17] <jepler> I haven't been up to much cnc or emc related lately
[03:12:21] <LawrenceG> I still find it amazing what those little packages can do... 40MIPS of 24bit instructions/16 bit data with all the right hardware bits like pwm and encoder interfaces
[03:13:34] <jepler> yeah, encoder is nice. pwm isn't really special these days, but quadrature counting is
[03:13:46] <jepler> can it latch or reset on index too?
[03:14:22] <LawrenceG> it might be possible to run a 4 channel servo on one of these chips... it has the pwm and 2 hardware encoder interfaces... but the interrupt on change logic seems solid and could be used to a couple of encoders
[03:14:52] <LawrenceG> yes, it can reset on index
[03:16:38] <LawrenceG> printf and floating point just dont seem right on a microcontroller but hey... life is much better than the z80 days
[03:17:18] <jepler> indeed it is
[03:17:24] <jepler> see you later
[03:17:43] <LawrenceG> the pic is pretty close to the old pdp11 .... cheers
[04:29:08] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[06:25:16] <micges_work> hello
[13:45:23] <cradek> my servo amps really seem to want jerk limited input...
[13:46:02] <cradek> they can accel FAST with little following error but there is a big bump of error at the beginning and end of the accel
[13:46:14] <cradek> big = 0.001 inch
[13:47:25] <cradek> .001 inch = 25.4 encoder counts
[14:03:42] <cradek> so, uh, someone should do that.
[14:07:05] <skunkworks> heh
[14:07:30] <skunkworks> how would that be done? re-write of the trajectory planner?
[14:08:52] <cradek> yep
[14:09:11] <cradek> or possibly just a tweak to it, but I'm not sure how to do it
[14:09:33] <skunkworks> so - s-curve accelleration?
[14:10:15] <cradek> yes something like that
[14:10:19] <skunkworks> heh
[14:11:10] <cradek> if you bound jerk and make it trapezoidal like __/\__ you'll get something curvy for accel
[14:11:42] <cradek> sonja whatserface made jerk smooth (sine) which gives you a different curvy thing for accel
[14:12:27] <cradek> I tried her algorithm and it worked for some values but gave discontinuities for other values - surely just my implementation was wrong
[14:22:58] <skunkworks> yeck.
[14:28:20] <Dave911> Would it be possible just to detect the rapid accel changes and then throw in a limiting factor to limit jerk. So it wouldn't be a true S curve but at least limit the jerk to a reasonable amount?
[14:28:45] <Dave911> Rewriting a trajectory planner sounds intimidating.. ;)
[14:29:18] <cradek> Dave911: yes, but you'll go off the desired path
[14:29:46] <cradek> you really need to do the limiting along the path, not afterward per-axis, or you can't stay on it
[14:30:44] <Dave911> But you are going off the path right now with that .001 jerk. If you had .0001 jerk would you really see it?
[14:31:51] <cradek> it's hard to say how far off the path it really goes
[14:31:51] <Dave911> Right now you have 25.4 encoder counts for .001. .0001 is only 2.5 counts and that is close to the dither you will see with the hunting between counts anyway..
[14:31:56] <cradek> sure depends on the move
[14:32:27] <cradek> a pure X move that starts and stops at the wrong place can have 1" following error in the middle of the move and still be "on the path"
[14:32:47] <cradek> on a circle, a 1" following error in X will make it pretty unround
[14:33:21] <cradek> so I guess I don't know how much it's a problem
[14:33:47] <cradek> .001" error somewhere in a rapid matters not-at-all, and that's what I'm whining about, haha
[14:34:57] <Dave911> >>.001" error somewhere in a rapid matters not-at-all, and that's what I'm whining about, haha
[14:34:59] <Dave911> I agree... ;-) Uhhh. but not about the whining.. :-)
[14:35:32] <cradek> I think the amps have some crossover distortion (is that the right term?) because I get tiny ferror bumps at circle quadrants even though there is no jerk there
[14:36:35] <Dave911> >>pure X move that starts and stops at the wrong place can have 1" following error in the middle of the move and still be "on the path"
[14:36:36] <Dave911> How can that be on path ....?
[14:36:38] <Dave911> Are you sure that you don't just have some backlash??
[14:36:41] <cradek> but since I fixed the mechanical problems, I can't see any bump in quadrants in the part finish (arcpsiral test)
[14:37:09] <Dave911> Did you reball your ballscrews? I think I saw that ..
[14:37:38] <cradek> Dave911: think of a pure X move from 0" to 10". you can stop at 5, go back to 3, then go on to 10 and still be "on the path". that's an extreme case of a following error.
[14:37:39] <Dave911> That sounds like you had some backlash...
[14:38:05] <cradek> no, it never had any, but it had rough balls that I thought were causing mechanical resonance, I was wrong and found the problem elsewhere
[14:38:23] <cradek> it is smooth with no backlash now
[14:39:12] <Dave911> >>think of a pure X move from 0" to 10". you can stop at 5, go back to 3, then go on to 10 and still be "on the path". that's an extreme case of a following error.
[14:39:14] <Dave911> I see your point...
[14:39:31] <Dave911> Good thing you caught the ball problems before it wrecked your screws
[14:40:07] <cradek> Dave911: the nut had a sticker on it saying "for service send it back to [ballscrew service company]"
[14:40:21] <cradek> they were apparently even more inept than me :-)
[14:40:42] <cradek> each circuit was missing 6-8 balls
[14:43:34] <Dave911> About a year ago I got a call from a customer saying they were having major problems with a ball screw actuator .. so I drove 200 miles on a Saturday morning to see them. The actuator was binding up like crazy after it ran for a few days. Swapped actuators same problems. I told the customer the actuators were bad - they called the manufacturer - not possible - just rebuilt both of them.
[14:43:36] <Dave911> I told the manufacturers they were wrong. They flew them back the plant - on Monday they said the actuators were rebuilt improperly - the nut was installed backwards in the housing which caused it to bind after a couple hundred hours of operations. They ate a lot of crow over that one. Now the customer wants me to quote a ball screw actuator.. :-)
[14:44:31] <Dave911> Total cost to find problem was several thousand dollars. Downtime cost them 10's of thousands of $.
[14:45:10] <Dave911> So even the manufacturers can screw up sometimes ....
[14:46:04] <Dave911> Oh yeah... the ball screw assemblies were imported from China to save money - they were horrible to work on.. binding threads etc.
[22:06:54] <PCW> jepler: I have finally rebuilt the 5I20 bitfiles that had the missing I/O spec in the ucf file
[22:06:55] <PCW> plus have a new source set for the firmware: main changes are:
[22:06:57] <PCW> 1.Pinouts separated into individual files
[22:06:58] <PCW> 2. top level files only need 2 changes to build any config
[22:07:00] <PCW> 3. 5I20 ucf file fixed
[22:07:02] <PCW> 4. minor bug in PWM generator fixed (double buffered mode
[22:07:03] <PCW> could act like unbuffered mode occasionally)
[22:07:05] <PCW> 5. Three phase PWM gen added
[22:07:06] <PCW> Where should I send these?
[22:07:57] <cradek> do you want git push access yet?
[22:08:00] <jepler> PCW: seb and/or me would be fine
[22:08:04] <jepler> haven't seen much of seb lately
[22:08:51] <PCW> Maybe vacation
[22:09:39] <jepler> but yeah, if you wanted push access to do bitfile and source updates, that would be dandy
[22:10:39] <PCW> Wonder if thats easier with wnidows or NetBSD
[22:10:46] <cradek> surely bsd
[22:11:06] <PCW> Server here is NetBSD
[22:11:51] <PCW> OK Ill download the git package
[22:13:06] <cradek> just email me your .ssh/id_dsa.pub or .ssh/id_rsa.pub
[22:14:38] <alex_joni> windows is not complicated either
[22:14:54] <jepler> I hope you guys can take care of PCW, I have to BBL
[22:15:18] <alex_joni> we'll take good care of him :) see you later
[22:15:37] <cradek> alex_joni: git + ssh + it screws up your line endings = netbsd has got to be better
[22:15:56] <alex_joni> cradek: gitosis iirc does git+ssh
[22:16:08] <alex_joni> and programmers notepad can be set for *nix line-endings
[22:16:40] <alex_joni> err.. not gitosis
[22:16:42] <cradek> ok, I'll leave it up to him
[22:16:48] <cradek> I withdraw my opinion
[22:16:55] <alex_joni> msysgit
[22:17:04] <cradek> I know nothing about using windows for anything
[22:19:44] <PCW> I'd prefer NetBSD, fewer surprises
[22:19:45] <PCW> I know nothing about ssh, do i just run ssh-keygen with a password?
[22:20:26] <PCW> (my .ssh dir had only known_hosts)
[22:20:51] <alex_joni> PCW: yes
[22:21:30] <PCW> OK well that part was easy
[22:24:12] <PCW> git 4.3.20 ok?
[22:24:54] <cradek_> that doesn't look like a git version number. there are two tools named git unfortunately
[22:25:23] <cradek_> on my freebsd it's /usr/ports/devel/git
[22:25:27] <cradek_> not sure what netbsd uses for packages
[22:25:30] <cradek_> cradek_ is now known as cradek
[22:31:47] <PCW> OK wrong git
[22:31:48] <PCW> is 1.5.6 ok (otherwise I'll have to update my pkgsrc)
[22:32:00] <cradek> I think 1.5 and 1.6 work fine
[22:32:56] <PCW> OK good. ill do some git study