[2773566.303251] hm2/hm2_5i20.0: prev = ( 65531, 65336 )
65536 seems like an unlikely value for a 16-bit timestamp
i was hoping to fix that before anyone noticed ;-)
it's a 16-bit timestamp, but i extend it to 32 bits by tracking rollovers
or at least i try
that warning message means i fail... :-(
it detects the problem and spackles over it, reporting vel=0, and then next time the encoder moves it snaps out of it and works fine
until the next time it gets confused
spackle for software - thats a new one ;-)
I gotta get me a bucket of that
seb_kuzminsky: looking at your TODO -- you probably should keep a widened-to-64-bits 'counts' and compute position based on it. but +-2^31 counts is still a pretty long way on any linear axis or number of revolutions for any single thread..
spindles would be the biggest risk of overflow
yeah but ISTM rollovers only matter during a thread, and you always reset to 0 at the start of a thread
I'm just in favor of avoiding such issues by extending to something long enough that overflow is a non-issue
now that we use doubles for pins, the limiting factor is the count
that's quite a TODO (I hadn't really looked at it before)
seb is very organized
I don't think it's feasible to widen hal's integer datatypes but internal values can be stored as 64-bit ints
jmkasunich: s/is very organized/needs prosthetic memory/
jepler: counts is not as big a problem as rawcounts
c++ sucks, or else I write sucky code in it
how can I tell which is the case?
I am working on writing a sort of database, and I had calculated that a certain operation on a moderate size database might take 50ms on a 100-megabit network by taking into account the amount of data to be read from disk
but it turns out that my implementation takes that much CPU time to perform the operation
so trying to speed it up by reducing the I/O won't make much difference
is the operation (or your implementation of it) O(n^2) or something?
* jmkasunich goes back to wrapping xmas presents
this encoder could not have overflowed. it's X, it only moves a few inches, and all I did was home it (starting from approximately the home position)
jmkasunich: it uses a structure that has O(N lg N) inserts, and I do a lot of inserts
but still N is only around 10000 in my test
that and creating and concatenating strings
cradek: if you're talking about the hm2 encoder messages you posted, it's not count-overflow related
it's timestamp-overflow related
atr the operations performed over the network, or is the result transferred over the network?
jepler: goes gprof work with c++?
seb_kuzminsky: yes, though inlining and the terrible names of the g++ internal functions make it hard to be sure what's what
I'm pretty confident it's the stl container and string stuff that is taking the majority of the time, though
(actually I've been using callgrind: I've nearly forgotten about gprof even existing)
haha, I was just thinking "wow that's a pretty good bug report"
then I saw who the submitter was :-P
does the calculated "ratio" (between axis motion and spindle speed) need to be negative in that case?
to keep "pseudo-time" going forward for the cut
cradek: are you planning to work on that bug, or are you hoping somebody else will?
he craftily assigned it to jmkasunich :)
no, I think that sf did it automatically
heh. could be - it is HAL after all
can't get away with just filing a report, can I
EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/TODO: updated driver-mess clean-up notes
I'm not working on it right now, but that dodges your question
git-stash is cool
I was working on some stuff, but it turned out to be broken
meanwhile I'd also fixed some stuff
if nobody fixes it in a week, I might
so I used git-stash to save my changes, then working from a diff I'd made I applied my fixes and commited them
then I applied the changes I'd stashed and was back to working on the unstable stuff
it's really just a shorthand for creating a short-lived branch..
cradek: fair enough
did it bite you hard enough to ruin something?
nope, I noticed it in plenty of time.
in other news, the mill will keep feeding without caring one bit whether the 1/8" drill is still drilling
hm, that might end badly
the middle part might be pretty bad too
yes, the failure is somewhere in the middle part
seb_kuzminsky: I'm now getting a flood of those messages every few minutes
jepler: "git stash" sounds like "bzr shelve" - pretty handy
cradek: yes it happens pretty often here too :-(
YEAH, BUT DOES BZR HAVE AN EQUIVALENT TO 'GIT AMNESIA' WHICH LOSES YOUR COMMITS
no it relies on the underlying unix command 'rm' for that :-P
I think I should stop now
you need to lay off the egg gnog man
why reimplement things that are already written so well
mmm egg nog
why not just drink the rum and skip the milk and raw egg?
there are three asynchronous things going on with hm2 encoder counting
1. the encoder is moving, producing edges
2. the hm2 encoder timestamp clock is running (1 MHz, 16-bit counter)
3. the driver is sampling the encoder count/timestamp register and the ts clock register once per servo loop
if the current encoder reading differs from the one we read the previous time through the loop, it's easy to deal with rollovers
if the current count/ts is the same, we know the upper bound on velocity, and we report that, easy
but we have to keep track of the timestamp count register, and watch for roll-overs
those roll-overs are applied to the timestamp we read from the count/ts register, next time it changes
except if the count changed before the roll-over happened
it gets icky
i drew out a bunch of timelines with the ts clock roll-over, the encoder edge, and the sampling all happening at different times
and i tried to derive the algorithm from that
but i guess i messed up somewhere
i'll look at it again soon
for now it looks scary in the log but shouldnt hurt too bad during actual operations
ok, thanks for explaining, I will just disregard it (or remove the warning from mine)
it only hurts the velocity output, right? that's very minor for me.
neat, I had not done CSS with at-speed before. it works great.
cvs server will be down for awhile while I move it to a different machine
cvs still not up, but things are progressing
can someone give the cvs server a try? looks like to me it's working at this point.
the web interface works
myself, I checked ssh
tortoise without proper ssh setup is appropriately refused ;)
the time is not quite right. is ntp blocked?
cradek: I ctrl-c'd it at bootup, it was hung
but that was before I made one last networking change
can you run it again and see whether it works now?
still seems disallowed
ping: cannot resolve tick.usno.navy.mil: Host name lookup failure
for now the nameserver isn't working again yet
you can use .217 for now
that's why ssh login took so long too
26 Dec 12:37:27 ntpdate: step time server 188.8.131.52 offset 240.954470 sec
looks fine now, that was it
I've run into a snag -- I wanted to migrate another real machine into a vm, but (I think because of the drivers on the initrd) it doesn't mount its root partition at boot time
do you have a guess as to what's missing?
because you can force it into the initrd ... somehow
not if I can't boot the machine
5 hours of spring left - I better go get to work.
sure you'd have to do it before you move it to the vm
the old system was ide (sata) disk, vmware always emulates scsi hard disks
well yes then it might have been possible :-P
can you boot from cd and fix it?
it's a really old system (fedora core 2 or 4 or something) so who knows if an ubuntu "rescue" cd will be very helpful
maybe if you chroot into it and mkinitrd (dpkg-reconfigure linux-image-`uname -r`) it will just work
I also considered trying qemu, which I think emulates ide hard disks(?)
lots of hits imply that vmware can too, but the option's not where they say
vmwar can emulate IDE disks, but I think you may need the GUI to create that type of VM
oh darn -- qemu is 32 bits only?
ad0: 4096MB <VMware Virtual IDE Hard Drive 00000001> at ata0-master UDMA33
acd0: CDROM <VMware Virtual IDE CDROM Drive/00000001> at ata1-master UDMA33
I guess I should keep looking for that option, then
aargh this is the machine where ubuntu has a bug that makes it not recognize the cdrom
"This virtual disk was created as a SCSI disk with SCSI geometries. It cannot be used as an IDE disk."
* jepler figures out what files to edit
and .. it boots to a rescue shell!
jepler: web interface is working here also. :) fyi
jepler: cvs up works here
from a dapper VM
amount of files downloaded by pbuilder to build emc2: Need to get 119MB/120MB of archives. After unpacking 479MB will be used.
whee.. that's quite a bit
.. and then it doesn't work. pukes building the documentation
No information for converting gif format files to png.
Define a converter in the preferences.
sh: convert: not found
Execution of "convert" failed.
Error: Cannot convert file
hmm.. it shouldn't build html docs iirc
that's building pdf docs
hmm.. I thought we didn't need convert only for pdf docs
did that change recently?
I only know the errors that are shown to me
I think it's silly that gif needs to be converted to png anyways
well .. installing convert seems to fix it
I know that lyx tries to discover ways to convert images
there are probably multiple possible packages that would work
juve is now known as alex_joni_