the Hampton Inn in fabulous Ashtabula Ohio
(which I can't even think about without the dracula accent)
that just rolls of the tongue
yes. "Come to my castle in Ashtabula"
hi jmkasunich, SWPLinux
hi SWPLinux... in Cleveland now? or did you drive farther towards home?
I thought Ann Arbor to Cle was a bit short for a day's drive
that much less for tomorrow
yep - a little better than Independence
I'm quite annoyed at windows
I've encoded a test movie twice, and my doze machine still can't play it
encoded on WIn, or on Lin?
jmkasunich_ is now known as jmkasunich
jmkasunich_: no luck here on my xp either -- not sure if you saw that or not
didn't see it
thanks for trying
my IRC flaked out on me, even tho the net connection didn't (at least it didn't seem to)
I'll check on my machine at home tomorrow night or Wed
I have RealPlayer there as well as media player
and quicktime something-or-other
well, I'm not gonna wait that long to upload the whole thing, I'll do it tonight
I can re-encode again later if need be
I figured out how to add timestamps to the frames, but thats taking a while
1-2 frames/sec on my fast machine
7000+ frames ;-/
The video I re-encoded last night to make it smaller than 100mb didn't play on anything. It uploaded to youtube just fine.
I also wished for timestamps when watching the video
cradek: try the sample thats on the festcam page now
(its just part of the first day)
the stamping process is up to Friday at 3pm
skunkworks: what did you use to encode for youtube?
mencoder -vf scale=480:360 -o newfile.mov full_cycle.mov -oac pcm -ovc lavc
you didn't specify a specific vcodec?
I thought that was the -ovc lavc
mencoder "mf://*.png" -mf fps=10 -o festcam.avi -ovc lavc -lavcopts vcodec=mpeg4
lavc is the library. but I think that by default it gives mpeg4...
thats a family of codecs, the vcodec line specs a specific one
hmm seemed to work - other than I could not play it here.
the sample with timestamps plays fine
I was really winging it
Employ the specified codec (default: mpeg4).
I tried with msmpeg4 which is supposed to be doze compatible, and it didn't work any better under doze than the first one
on a 4 meg test file, the msmpeg4 encoder only added about 4K
so I'll probably use that for the real movie
getting close - Saturday 1am
heh, the lights out black frames are much faster
I want to find a picture with boris in it, to replace the one of cradek sitting there all by himself
I couldn't find one with boris, I looked a little bit
there are the photos we took while packing up ...
I think I'll crop/scale one of those
I only have one half-decent one, anybody else have better?
I don't have anything
slight change of subject: can you resolve jmkasunich.dyndns.org?
I have one, but I can't upload it until I get home
jmkasunich.dyndns.org has address 188.8.131.52
yes, "nothing to see here ..."
good, but strange - can't resolve it here
nice to know its working anyway
yay, 7811 images are now timestamped
* 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
$250 buys an X2 4600 65W, 2GB RAM, and a similar motherboard to the one I have now
I have a drive and case
ah - the other half ...
on the other hand .. meh
I never did get around to building any kernels at the Workshop
you built the one that didn't boot
I think I had that done beforehand (thinking ahead, you know)
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
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
let me look if there's a patch for i386/2.6.20
this is magma which I'm not sure you want to use
yep, dozens of patches for you to try
none newer than .17 (working) for 3.5 iirc
so random cvs version it would have to be
do you build rtai with dpkg-buildpackage?
or with something in /usr/src/modules
with make-kpkg I think
yeah /usr/src/modules is involved
what was the name of the tuning method that takes into acount period and such - I thought there was a wiki page on it
full movie uploading, eta about an hour
the oscillating fans look funny at 600x normal speed
and there was quite a bit more cat activity friday morning than I noticed the first time
that worked great it seems
what are you tuning?
just a motor.
[03:18:12] <skunkworks> http://www.electronicsam.com/images/KandT/servostart/ampmess.JPG
at a p of 460 I got a sustained oscolation of .036ms
that gives me a p=276 I=25555 and a d of 2.07
pluto + your board?
wow, that's a lot of I
but it gives good results?
so far.. but I now need to do some following error tests and such
unless I did the math wrong ;)
if it seems to land in the right place and not ring, it's probably pretty good
"Manual "tune by feel" methods have proven time and again to be inefficient, inaccurate, and often dangerous."
phooey on them
if my input scale is 30480 should my deadband be 0.000049
make it about one count
umm - one count as in one enoder count? so 0.000032808
I'd probably go with 0.000040
you're not gonna notice 40micro-inches on a part
:) 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
cradek: your I on the pluto was 30K
so it is
not sure how that's scaled though
I think it's mm input, volt output
I'm fuzzy about that kind of thing
you don't know fuzzy :)
time for bed
I did have one oddity.
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
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
(I did not copy the error - I can do that tonight)
2.1 or trunk?
trunk as of the workshop
and when I mean I changed them to inch - I mean 'inch
INIFILE: ERR_CONVERSION, section=AXIS_0, tag=UNITS, num=0, lineNo=147
Yes - exactly
I did not try .0397....
if you don't specify the units of a linear axis, [TRAJ]LINEAR_UNITS is used
but this still looks fishy
Like I say - it worked after I # out the units in each axis section
well crap. you tube rejected the festcam video because it was too long
as in time not size
it looks like petev's changes to inifile handling broke that
in 2.1, [AXIS_n]UNITS=inch was accepted and in trunk it's not.
skunkworks: well heck
get jmk to encode it at a different number of FPS?
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?
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
jepler: thank you
jepler: I'm trying to figure out how to do that
finally got it
woo whoo http://youtube.com/watch?v=l5q1rVKYLTQ
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.
oops - made a mistake on the pid calc last night
it should have been P=276 I=15333 d=2.07
I used the corrected D for the middle number instead of the original
It was neat as anything below a D of 460 the oscollation would die out. (flicking the shaft)
and still a math mistake. P=276 I=15333 D=1.242
so - does anyone need any math done? I seem to be quite good at it.
thanks anyway, but no
I got my k sub c and k sub p mixed up.
can't wait to see what the new numbers do - as the old ones seemed ok.
skunkworks_ is now known as skunkworks
Why would the jog buttons not work in axis and the lathe_pluto setup?
they're busted, only keyboard jogging works right
So it wasn't me. :)
a lathe issue?
no, they're busted for all the configs
keyboard it is then :)
You leave for a week and your internet becomes flakey.
jepler: I just read your pluto docs. Interesting that my spindle encoder is 4096 count, which you say is the maximum allowed
cradek: I think that if it's larger than that, the sign extension code doesn't work right
I wonder how common encoders with more lines are
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
I wonder if those encoders skunkworks got are 2540 line or 2540 count
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.
since the register is 14 bits wide that leaves 12 that are usable for counts
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
for mine, that's 60krpm at the spindle - not likely to be a limitation
if I thought about it, there might be something smarter I can do about the index in the HAL driver
because I know the last index seen is +-4096 from the current unindexed spindle count
I just haven't had a reason to figure it out
well mine seems to work perfectly
(which is more than can be said for index on most of the other devices)
cradek - 2540 line - 10160 count
skunkworks: going to use index?
skunkworks: or go above 24krpm with it?
they have a 100k count or 3000 rpm limit anyways
the max they can run at that line is 2362 rpm.
(although I was running them at 3000rpm without an issue last night. still came back to my index mark
the index with these will most likely only be used for homing.
(the big honking servos are only rated to 1200 rpm also)
won't matter if the index is only for homing .. matters whether it's used at all
so cradeks encoders are 1024 line? I see the issue then.
the spindle is
the servos don't have index - and I think they're 5xx lines or so
An axis with index pulse must have fewer than 8192 counts per revolution
hum, I wrote 8192 somewhere else (the HTML documentation?) -- I wonder which is right
It is still too small for mine I guess
that is in both the document and manual page
linked from your site
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)
as can anything above 4096
Would 10160 be possible? (index enabled)
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 :)
did you buy a whole box?
they were tempting, but I'm trying to learn not to buy stuff just because I might want it "some day"
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:21:13] <jepler> http://pastebin.ca/577188
the "position logic" stays like right now, but there's smarter index logic
we bought 7 of them
and got the guys emai address ;)
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
to support >4096 count encoders I'd be better of widening the registers and ditching PDM if necessary
with such a fast pwm, I doubt anyone cares about pdm
I second that.
I hear that if your target is a +-10V analog servo amp you want PDM no matter how fast the PWM Is
and you know how many pluto users have those
ok, I didn't know that
ripple voltage dV = I dT -- PDM makes dT small (100ns) instead of large (50us)
s/better of widening/better off widening/
good night guys