Back
[01:44:47] <skunkworks> SWPLinux: hotel?
[01:44:52] <SWPLinux> ja
[01:45:06] <skunkworks> jah
[01:45:15] <SWPLinux> the Hampton Inn in fabulous Ashtabula Ohio
[01:45:37] <SWPLinux> (which I can't even think about without the dracula accent)
[01:46:49] <skunkworks> that just rolls of the tongue
[01:47:17] <SWPLinux> yes. "Come to my castle in Ashtabula"
[01:47:36] <jepler> haha
[01:47:39] <jepler> hi jmkasunich, SWPLinux
[01:47:47] <SWPLinux> hi jepler
[02:08:05] <jmkasunich_> helloooooo
[02:08:43] <jmkasunich_> hi SWPLinux... in Cleveland now? or did you drive farther towards home?
[02:08:52] <SWPLinux> Sunny Ashtabula
[02:08:58] <jmkasunich_> ;-)
[02:09:18] <jmkasunich_> I thought Ann Arbor to Cle was a bit short for a day's drive
[02:09:27] <jmkasunich_> that much less for tomorrow
[02:09:40] <SWPLinux> yep - a little better than Independence
[02:10:01] <jmkasunich_> I'm quite annoyed at windows
[02:10:20] <jmkasunich_> I've encoded a test movie twice, and my doze machine still can't play it
[02:10:27] <SWPLinux> hmmm
[02:10:36] <SWPLinux> encoded on WIn, or on Lin?
[02:10:46] <jmkasunich_> jmkasunich_ is now known as jmkasunich
[02:10:53] <jepler> jmkasunich_: no luck here on my xp either -- not sure if you saw that or not
[02:11:15] <jmkasunich> didn't see it
[02:11:19] <jmkasunich> thanks for trying
[02:11:36] <jmkasunich> my IRC flaked out on me, even tho the net connection didn't (at least it didn't seem to)
[02:11:46] <SWPLinux> I'll check on my machine at home tomorrow night or Wed
[02:12:00] <SWPLinux> I have RealPlayer there as well as media player
[02:12:09] <SWPLinux> and quicktime something-or-other
[02:12:13] <jmkasunich> well, I'm not gonna wait that long to upload the whole thing, I'll do it tonight
[02:12:20] <jmkasunich> I can re-encode again later if need be
[02:12:42] <jmkasunich> I figured out how to add timestamps to the frames, but thats taking a while
[02:12:47] <jmkasunich> 1-2 frames/sec on my fast machine
[02:13:04] <jmkasunich> 7000+ frames ;-/
[02:13:05] <cradek> hi guys
[02:13:07] <jmkasunich> hi
[02:13:08] <skunkworks> The video I re-encoded last night to make it smaller than 100mb didn't play on anything. It uploaded to youtube just fine.
[02:13:26] <cradek> I also wished for timestamps when watching the video
[02:13:38] <jmkasunich> cradek: try the sample thats on the festcam page now
[02:13:53] <jmkasunich> (its just part of the first day)
[02:14:15] <jmkasunich> the stamping process is up to Friday at 3pm
[02:14:57] <jmkasunich> skunkworks: what did you use to encode for youtube?
[02:15:41] <skunkworks> mencoder -vf scale=480:360 -o newfile.mov full_cycle.mov -oac pcm -ovc lavc
[02:16:17] <jmkasunich> you didn't specify a specific vcodec?
[02:16:32] <skunkworks> I thought that was the -ovc lavc
[02:16:37] <jmkasunich> mencoder "mf://*.png" -mf fps=10 -o festcam.avi -ovc lavc -lavcopts vcodec=mpeg4
[02:16:48] <jepler> lavc is the library. but I think that by default it gives mpeg4...
[02:16:51] <jmkasunich> thats a family of codecs, the vcodec line specs a specific one
[02:17:08] <skunkworks> hmm seemed to work - other than I could not play it here.
[02:17:11] <jepler> lavc (-lavcopts)
[02:17:11] <cradek> the sample with timestamps plays fine
[02:17:14] <skunkworks> I was really winging it
[02:17:16] <jepler> vcodec=<value>
[02:17:16] <jepler> Employ the specified codec (default: mpeg4).
[02:17:32] <jmkasunich> I tried with msmpeg4 which is supposed to be doze compatible, and it didn't work any better under doze than the first one
[02:18:22] <jmkasunich> on a 4 meg test file, the msmpeg4 encoder only added about 4K
[02:18:30] <jmkasunich> so I'll probably use that for the real movie
[02:18:58] <jmkasunich> getting close - Saturday 1am
[02:19:48] <jmkasunich> heh, the lights out black frames are much faster
[02:20:18] <jmkasunich> I want to find a picture with boris in it, to replace the one of cradek sitting there all by himself
[02:21:30] <cradek> I couldn't find one with boris, I looked a little bit
[02:22:13] <SWPLinux> there are the photos we took while packing up ...
[02:22:18] <jmkasunich> I think I'll crop/scale one of those
[02:22:43] <jmkasunich> I only have one half-decent one, anybody else have better?
[02:24:12] <cradek> I don't have anything
[02:24:52] <jmkasunich> slight change of subject: can you resolve jmkasunich.dyndns.org?
[02:24:55] <SWPLinux> I have one, but I can't upload it until I get home
[02:25:18] <cradek> jmkasunich.dyndns.org has address 66.134.149.136
[02:25:24] <SWPLinux> yes, "nothing to see here ..."
[02:25:39] <jmkasunich> good, but strange - can't resolve it here
[02:25:44] <jmkasunich> nice to know its working anyway
[02:29:41] <jmkasunich> yay, 7811 images are now timestamped
[02:32:48] <jepler> * jepler contemplates buying about $250 in hardware so that he can put his dual-core machine to the use it was intended for, and also continue to mess with 64-bit smp emc2
[02:33:09] <SWPLinux> which hardware?
[02:33:10] <jepler> $250 buys an X2 4600 65W, 2GB RAM, and a similar motherboard to the one I have now
[02:33:23] <SWPLinux> ah
[02:33:27] <jepler> I have a drive and case
[02:33:33] <SWPLinux> ah - the other half ...
[02:33:35] <SWPLinux> :)
[02:33:39] <jepler> on the other hand .. meh
[02:34:11] <SWPLinux> I never did get around to building any kernels at the Workshop
[02:34:17] <jepler> you built the one that didn't boot
[02:34:20] <jepler> or something
[02:34:40] <SWPLinux> I think I had that done beforehand (thinking ahead, you know)
[02:38:35] <jepler> I seem to remember noticing that feisty is based on the 2.6.20 kernel which is what I chose when I compiled rtai on dapper
[02:41:21] <cradek> I'm going to have to try to make a newer smp+rtai kernel and hope the keyboard thing is fixed. I'll try 2.6.20 if there is rtai support
[02:41:41] <jepler> let me look if there's a patch for i386/2.6.20
[02:41:58] <jepler> this is magma which I'm not sure you want to use
[02:42:18] <jepler> hal-linux-2.6.20-i386-1.8-04.patch
[02:42:24] <jepler> yep, dozens of patches for you to try
[02:43:00] <cradek> none newer than .17 (working) for 3.5 iirc
[02:43:18] <cradek> so random cvs version it would have to be
[02:46:59] <jepler> do you build rtai with dpkg-buildpackage?
[02:47:08] <jepler> or with something in /usr/src/modules
[02:47:18] <cradek> with make-kpkg I think
[02:47:24] <cradek> yeah /usr/src/modules is involved
[02:53:26] <skunkworks> what was the name of the tuning method that takes into acount period and such - I thought there was a wiki page on it
[02:53:34] <cradek> zeigler-nichols
[02:53:41] <skunkworks> thanks
[02:54:05] <jmkasunich> full movie uploading, eta about an hour
[02:58:20] <cradek> cool
[03:00:12] <jmkasunich> the oscillating fans look funny at 600x normal speed
[03:00:44] <jmkasunich> and there was quite a bit more cat activity friday morning than I noticed the first time
[03:15:39] <skunkworks> wow
http://en.wikipedia.org/wiki/PID_controller#Ziegler-Nichols_method
[03:15:42] <skunkworks> that worked great it seems
[03:17:25] <cradek> what are you tuning?
[03:17:58] <skunkworks> just a motor.
[03:18:12] <skunkworks> http://www.electronicsam.com/images/KandT/servostart/ampmess.JPG
[03:18:32] <skunkworks> just playing
[03:19:19] <skunkworks> at a p of 460 I got a sustained oscolation of .036ms
[03:20:14] <skunkworks> that gives me a p=276 I=25555 and a d of 2.07
[03:20:37] <cradek> pluto + your board?
[03:20:47] <cradek> wow, that's a lot of I
[03:20:54] <cradek> but it gives good results?
[03:21:45] <skunkworks> so far.. but I now need to do some following error tests and such
[03:21:52] <skunkworks> unless I did the math wrong ;)
[03:22:22] <cradek> if it seems to land in the right place and not ring, it's probably pretty good
[03:23:08] <jmkasunich> "Manual "tune by feel" methods have proven time and again to be inefficient, inaccurate, and often dangerous."
[03:23:13] <jmkasunich> phooey on them
[03:23:44] <cradek> heh
[03:24:44] <skunkworks> if my input scale is 30480 should my deadband be 0.000049
[03:25:07] <jmkasunich> make it about one count
[03:26:47] <skunkworks> umm - one count as in one enoder count? so 0.000032808
[03:27:19] <jmkasunich> or thereabouts
[03:27:25] <jmkasunich> I'd probably go with 0.000040
[03:27:42] <jmkasunich> you're not gonna notice 40micro-inches on a part
[03:29:47] <skunkworks> :) pretty cool looking at axis display - as I try to turn it - it doesn't go more than .0002 until I knee over the drive. "feels" like I am moving it though
[03:32:43] <skunkworks> cradek: your I on the pluto was 30K
[03:34:55] <cradek> so it is
[03:35:41] <cradek> not sure how that's scaled though
[03:35:58] <cradek> I think it's mm input, volt output
[03:36:03] <cradek> I'm fuzzy about that kind of thing
[03:39:21] <skunkworks> you don't know fuzzy :)
[03:55:00] <skunkworks> time for bed
[03:55:04] <skunkworks> night
[12:16:49] <skunkworks> I did have one oddity.
[12:17:44] <jepler> what's that?
[12:19:05] <skunkworks> THe pluto is metric - so I went into the ini to change it to inches each axis has units = 1 and then the task has linear_units=1. I changed them all to inch
[12:19:20] <skunkworks> 'inch'
[12:20:25] <skunkworks> then got a error in the termial over and over about a units error until I remarked out the units in each axis's section
[12:21:08] <skunkworks> (I did not copy the error - I can do that tonight)
[12:21:37] <jepler> 2.1 or trunk?
[12:21:57] <skunkworks> trunk as of the workshop
[12:22:03] <jepler> OK
[12:22:39] <skunkworks> and when I mean I changed them to inch - I mean 'inch
[12:22:41] <skunkworks> '
[12:22:41] <jepler> INIFILE: ERR_CONVERSION, section=AXIS_0, tag=UNITS, num=0, lineNo=147
[12:22:52] <skunkworks> Yes - exactly
[12:23:15] <skunkworks> I did not try .0397....
[12:23:31] <jepler> if you don't specify the units of a linear axis, [TRAJ]LINEAR_UNITS is used
[12:23:35] <jepler> but this still looks fishy
[12:23:58] <skunkworks> Like I say - it worked after I # out the units in each axis section
[12:26:49] <skunkworks> well crap. you tube rejected the festcam video because it was too long
[12:26:56] <skunkworks> as in time not size
[12:26:58] <jepler> it looks like petev's changes to inifile handling broke that
[12:27:09] <jepler> in 2.1, [AXIS_n]UNITS=inch was accepted and in trunk it's not.
[12:27:14] <jepler> skunkworks: well heck
[12:27:26] <jepler> get jmk to encode it at a different number of FPS?
[12:30:42] <skunkworks> That might work. I cannot play it here to see the actual length. Youtube says 10 minutes maximim. How long is it actually? or is it an encoding problem?
[12:31:18] <jepler> cradek: alex_joni: can someone with permissions on sf make petev an assignable person for bug reports? I am filing this [AXIS_n]UNITS bug and want to assign it to him
[12:32:54] <skunkworks> jepler: thank you
[13:17:29] <cradek> jepler: I'm trying to figure out how to do that
[13:25:35] <cradek> finally got it
[13:25:44] <skunkworks> Yay you
[13:25:45] <skunkworks> :)
[13:26:27] <skunkworks> woo whoo
http://youtube.com/watch?v=l5q1rVKYLTQ
[13:29:12] <skunkworks> I ran the video in videolan and it said it had an error and if I wanted to fix it. I said yes then it played in videolan - but it would not save the fix. So I download a repair utillity called ASF-AVI-RM-WMV Repair <- yah whatever. And then re-uploaded it back to youtube. whew.
[14:23:49] <skunkworks> oops - made a mistake on the pid calc last night
[14:24:33] <skunkworks> it should have been P=276 I=15333 d=2.07
[14:25:00] <skunkworks> I used the corrected D for the middle number instead of the original
[14:25:21] <skunkworks> (I)
[14:33:32] <skunkworks_> It was neat as anything below a D of 460 the oscollation would die out. (flicking the shaft)
[14:40:55] <skunkworks_> and still a math mistake. P=276 I=15333 D=1.242
[14:41:29] <skunkworks_> so - does anyone need any math done? I seem to be quite good at it.
[14:41:43] <cradek> thanks anyway, but no
[14:42:18] <skunkworks_> I got my k sub c and k sub p mixed up.
[14:43:39] <skunkworks_> can't wait to see what the new numbers do - as the old ones seemed ok.
[14:43:54] <skunkworks_> yah
[14:44:01] <skunkworks_> skunkworks_ is now known as skunkworks
[14:44:45] <skunkworks> Why would the jog buttons not work in axis and the lathe_pluto setup?
[14:45:33] <cradek> they're busted, only keyboard jogging works right
[14:45:37] <skunkworks> ah
[14:45:49] <skunkworks> So it wasn't me. :)
[14:46:02] <cradek> nope
[14:46:27] <skunkworks> a lathe issue?
[14:46:40] <cradek> no, they're busted for all the configs
[14:46:46] <cradek> I think
[14:47:01] <skunkworks> In head?
[14:47:03] <cradek> yes
[14:47:06] <skunkworks> ok
[14:47:18] <skunkworks> keyboard it is then :)
[15:59:11] <skunkworks> join ubuntu
[17:26:52] <skunkworks> You leave for a week and your internet becomes flakey.
[19:18:26] <cradek> jepler: I just read your pluto docs. Interesting that my spindle encoder is 4096 count, which you say is the maximum allowed
[19:21:36] <jepler> cradek: I think that if it's larger than that, the sign extension code doesn't work right
[19:22:04] <cradek> I wonder how common encoders with more lines are
[19:22:07] <jepler> I dunno
[19:25:59] <jepler> I might be able to make all those quadrature registers 1 bit wider -- that would cost about 8 more LEs, I think, and permit encoders up to 8192 per revolution
[19:26:46] <cradek> I wonder if those encoders skunkworks got are 2540 line or 2540 count
[19:27:46] <jepler> I tell the direction of the rotation by looking at the top two bits. 00 -> 01 -> 10 -> 11 -> 00 means "increasing". if the top two bits of the register change by 2 (eg from 00 -> 10) then I can't tell the sign.
[19:27:59] <jepler> since the register is 14 bits wide that leaves 12 that are usable for counts
[19:28:50] <jepler> if you don't use index on a particular axis, that limitation doesn't matter and it's just the limitation of 4096 counts per servo cycle
[19:30:22] <cradek> for mine, that's 60krpm at the spindle - not likely to be a limitation
[19:32:16] <jepler> if I thought about it, there might be something smarter I can do about the index in the HAL driver
[19:32:31] <jepler> because I know the last index seen is +-4096 from the current unindexed spindle count
[19:32:48] <jepler> I just haven't had a reason to figure it out
[19:33:46] <cradek> well mine seems to work perfectly
[19:34:04] <cradek> (which is more than can be said for index on most of the other devices)
[19:34:49] <skunkworks> cradek - 2540 line - 10160 count
[19:34:58] <cradek> uh-oh
[19:34:57] <jepler> skunkworks: going to use index?
[19:35:28] <jepler> skunkworks: or go above 24krpm with it?
[19:35:57] <skunkworks> they have a 100k count or 3000 rpm limit anyways
[19:36:44] <skunkworks> the max they can run at that line is 2362 rpm.
[19:37:16] <skunkworks> (although I was running them at 3000rpm without an issue last night. still came back to my index mark
[19:39:00] <skunkworks> the index with these will most likely only be used for homing.
[19:39:31] <skunkworks> (the big honking servos are only rated to 1200 rpm also)
[19:41:14] <jepler> won't matter if the index is only for homing .. matters whether it's used at all
[19:42:20] <skunkworks> so cradeks encoders are 1024 line? I see the issue then.
[19:42:31] <cradek> the spindle is
[19:43:01] <cradek> the servos don't have index - and I think they're 5xx lines or so
[19:43:55] <skunkworks> An axis with index pulse must have fewer than 8192 counts per revolution
[19:44:13] <jepler> hum, I wrote 8192 somewhere else (the HTML documentation?) -- I wonder which is right
[19:44:25] <cradek> hmm
[19:44:28] <skunkworks> It is still too small for mine I guess
[19:45:33] <skunkworks> that is in both the document and manual page
[19:45:44] <skunkworks> linked from your site
[19:48:42] <jepler> unless I'm counting bits wrong or something, I don't think that 8191 counts (per index or per poll) works. That can change the top 2 of 14 bits (e.g., before: 1 after: 8192)
[19:49:13] <jepler> as can anything above 4096
[19:51:26] <skunkworks> Would 10160 be possible? (index enabled)
[20:00:11] <skunkworks> if not I am sure the mesa does. and that will be the final solution for the big machine.. But we do have enough of these encoders to do 2 machines :)
[20:08:29] <cradek> did you buy a whole box?
[20:10:24] <cradek> they were tempting, but I'm trying to learn not to buy stuff just because I might want it "some day"
[20:16:31] <jepler> skunkworks: I'm convinced that I could make index work up to 16383 counts (without changing the firmware) even though I haven't quite worked out the logic
[20:17:17] <cradek> woo
[20:21:13] <jepler> http://pastebin.ca/577188
[20:21:29] <jepler> the "position logic" stays like right now, but there's smarter index logic
[20:22:18] <jepler> hmmmm
[20:23:10] <skunkworks> we bought 7 of them
[20:23:20] <skunkworks> and got the guys emai address ;)
[20:23:38] <jepler> this won't be right in the following circumstance (which is probably uncommon): within 1ms, the encoder hits the index, then reverses past its position at the last report
[20:23:37] <skunkworks> email
[20:36:48] <jepler> to support >4096 count encoders I'd be better of widening the registers and ditching PDM if necessary
[20:43:36] <cradek> with such a fast pwm, I doubt anyone cares about pdm
[20:44:17] <skunkworks> I second that.
[20:47:46] <jepler> I hear that if your target is a +-10V analog servo amp you want PDM no matter how fast the PWM Is
[20:48:24] <jepler> and you know how many pluto users have those
[20:49:36] <cradek> ok, I didn't know that
[20:53:45] <jepler> ripple voltage dV = I dT -- PDM makes dT small (100ns) instead of large (50us)
[20:54:51] <jepler> s/better of widening/better off widening/
[21:00:46] <alex_joni> good night guys
[21:03:43] <skunkworks> night alex
