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