Back
[00:11:46] <jmk_sleep> jmk_sleep is now known as jmkasunich
[00:22:53] <jmkasunich> anybody home?
[02:37:55] <cradek> I am now...
[02:37:58] <cradek> how's it going?
[02:38:22] <jmkasunich> relaxing, recovering
[02:38:49] <cradek> I got your message, sorry to hear you didn't win, but I bet it was fun anyway
[02:39:12] <jmkasunich> yeah, but nerve racking
[02:39:33] <jmkasunich> this morning I plugged the cable from PC to H-bridges in one position off (stupid me, didn't key it)
[02:39:50] <jmkasunich> the parport in the laptop refused to work, we were sh*ting bricks
[02:40:02] <jmkasunich> fortunately a power cycle brought it back
[02:40:15] <jmkasunich> dunno what happened, some kind of CMOS latchup or something
[02:40:38] <cradek> oh hell
[02:40:47] <cradek> wow I would have expected to find it toasted
[02:41:18] <jmkasunich> me too
[02:41:33] <cradek> the Apple II had an unkeyed ribbon cable header that connected the floppy drive to the controller
[02:41:34] <jmkasunich> the connector had gnd, +5, and ins/outs on it
[02:41:43] <cradek> if you hooked it up one pin off, the whole works would die.
[02:42:11] <jmkasunich> ouch
[02:42:36] <cradek> and we were always moving the drives around - needed two to copy floppies, but every machine only had one
[02:42:41] <jmkasunich> in this case, the laptop's gnd was connected to the +5 of our board
[02:42:46] <cradek> anyway... showing my age!
[02:42:53] <cradek> ouch
[02:43:09] <jmkasunich> the laptop is ungrounded tho, so that wasn't fatal
[02:43:17] <cradek> well glad it didn't expire... you can't replace parts on a laptop board.
[02:43:37] <jmkasunich> the inputs on our board (outputs from laptop) were pulled up to +5, so to the laptop they were at ground, no harm
[02:43:38] <cradek> ha, just remembered I toasted the parport on my PC Jr that way too. Similarly hard to replace.
[02:43:57] <cradek> we experimenters are hard on stuff
[02:43:57] <jmkasunich> the outputs from our board (encoder) that were low at the time were -5 to the laptop, it didn't like that
[02:44:06] <jmkasunich> yeah
[02:44:22] <jmkasunich> I have a gutted laptop here that I want to put in a small package
[02:44:31] <jmkasunich> alum box, 12x6x1"
[02:44:47] <jmkasunich> no keybd or display
[02:44:57] <jmkasunich> and stuff one of those wavelans in it
[02:45:05] <cradek> did you get them working finally?
[02:45:22] <jmkasunich> not yet, but I know I can (one way or another)
[02:45:36] <cradek> yeah probably, given enough effort :-)
[02:45:41] <jmkasunich> the data is getting sent and received, I can see it
[02:45:45] <cradek> did you hear about the latest TP problem ray found?
[02:46:07] <jmkasunich> but the RX_RCV_OK bit isn't set, so the driver ignores it - I can fix that, by force if needed
[02:46:31] <jmkasunich> I saw something when reading back in the board channel, but not enough to know what it was
[02:46:36] <cradek> on blended colinear segments g0->g1 it overshoots, stops, backs up, and then does the next segment
[02:46:41] <jmkasunich> other than "yet another TP/blending problem"
[02:47:00] <cradek> yeah that's pretty much it.
[02:48:40] <jmkasunich> btw, speaking of laptops running RT code
[02:49:07] <jmkasunich> I think I saw something when reading back about apt-get emc2 and make install emc2 being incompatible?
[02:49:23] <jmkasunich> of course, I've already done both on this box :-/
[02:49:25] <cradek> depends what you mean by incompatible
[02:49:51] <cradek> configure/make install will use /usr/local as the prefix
[02:49:52] <jmkasunich> anyway, I'm trying to set up this laptop to compile and run emc2 (or other HAL stuff)
[02:50:01] <cradek> so they may not be as incompatible as we think
[02:50:22] <jmkasunich> I did apt-get build-essentials, and also got the 2.6.12-magma kernel headers and image
[02:50:28] <cradek> I always thought you would use make install OR a deb package - it's odd to do both
[02:50:32] <jmkasunich> what else is needed to compile
[02:50:42] <cradek> apt-get build-dep emc2
[02:50:52] <cradek> i.e. "get everything needed to build emc2"
[02:50:58] <jmkasunich> well, this is a developement box, I installed the package to see if it would work, I do make install to see if that works
[02:51:02] <jmkasunich> ok
[02:51:10] <cradek> sure, no problem, as long as you understand what you're doing
[02:51:35] <jmkasunich> I knew it was something simple, but that little tidbit (build-dep) isn't anywhere I could find
[02:51:53] <cradek> you'll want cvs too, which is not a build-dep (it's not strictly needed to rebuild the emc2 deb)
[02:52:04] <cradek> man apt-get does have build-dep
[02:52:29] <jmkasunich> got cvs
[02:52:38] <cradek> you're set then
[02:52:52] <jmkasunich> doing the build-dep right now
[02:53:37] <jmkasunich> I can see the joystick being a very handy source of test stimulus for HAL stuff
[02:53:56] <jmkasunich> buttons and analog inputs right there
[02:54:28] <cradek> yeah, sounds handy
[02:54:38] <cradek> not realtime right?
[02:54:47] <jmkasunich> no, but pretty darned quick anyway
[02:55:11] <jmkasunich> as long as you're not surfing the web or compiling a kernel, I bet there is no perceptible lag
[02:55:25] <jmkasunich> which is really the criteria for a human input device
[02:56:22] <cradek> true
[02:56:27] <cradek> humans aren't realtime
[02:56:48] <jmkasunich> I have to do more basement cleaning this weekend
[02:57:01] <jmkasunich> brought home some new junk, gotta get rid of old junk
[02:57:24] <cradek> that's a funny rule
[02:57:40] <jmkasunich> you gradually improve the quality of your junk stock that way
[02:57:55] <cradek> true
[02:57:57] <jmkasunich> got a HP 1653B logic analyzer this time
[02:58:06] <jmkasunich> needs a manual and a system disk
[02:58:43] <cradek> boot from floppy?
[02:58:52] <jmkasunich> it has a broken pin on one of the cable connectors, but a 0.100" center header is almost childs play these days
[02:59:09] <jmkasunich> yes, it runs some self tests, then says gimme a system disk
[02:59:26] <cradek> that may be a challenge to find if it's old...
[02:59:36] <cradek> crap, I don't see ray's overshoot bug here
[03:01:25] <jmkasunich> murphys law
[03:02:06] <cradek> alex said he saw it though. same ini, same program
[03:04:53] <jmkasunich> you aren't running your simple TP are you?
[03:05:02] <cradek> nope
[03:05:06] <cradek> the TESTING deb
[03:07:51] <cradek> ohhh
[03:07:55] <cradek> with FO=300% it does it bad
[03:07:58] <cradek> ok
[03:08:11] <cradek> ha, it's pretty funny
[03:08:27] <jmkasunich> FO does evil things to trajectory planners
[03:09:50] <cradek> http://timeguy.com/cradek-files/emc/reversal.png
[03:10:07] <cradek> Xpos, Xdir
[03:10:48] <cradek> the two moves in +x are colinear
[03:10:57] <jmkasunich> eww\
[03:11:26] <jmkasunich> the first one is a rapid, the second a feedrate move?
[03:14:19] <jmkasunich> what config are you running?
[03:17:53] <jmkasunich> hmm, on the laptop, I did a cvs checkout, already have build-deps, rebooted so I'm running the magma kernel
[03:18:07] <jmkasunich> but when I try ./configure, it can't find the RT
[03:19:04] <jmkasunich> I have the linux-image-2.6.12-magma and linux-headers-2.6.12-magma packages
[03:24:25] <jmkasunich> found it, I needed rtai-modules-2.6.12-magma
[03:29:11] <jmkasunich> you still here?
[03:29:14] <cradek> just got back
[03:29:20] <jmkasunich> cradek: anyway... showing my age!
[03:29:21] <cradek> my net connection is bad lately.
[03:29:26] <cradek> haha
[03:29:33] <jmkasunich> I'm curious, how old are you?
[03:29:36] <cradek> 32
[03:29:50] <jmkasunich> heh, a child
[03:29:52] <jmkasunich> 43
[03:29:53] <cradek> it's funny though
[03:30:17] <cradek> it's still my habit to not mention my age in technical forums like the emc channel
[03:30:28] <cradek> since I'm used to being too young to be taken seriously in complex matters
[03:30:40] <cradek> the funny part is I'm not that young anymore
[03:31:20] <jmkasunich> I think there are very few tech places where even late 20's is considered "too young"
[03:31:29] <jmkasunich> except possibly industial control ;-)
[03:31:32] <cradek> that's true
[03:31:43] <jmkasunich> hell, for SW folks, 40 is getting old
[03:31:48] <cradek> I guess I don't even feel as old as late 20s
[03:32:05] <cradek> I don't know how old I feel, I guess I don't spend much time worrying about it
[03:32:19] <cradek> the one thing I'm sure about is that I'm older than I've ever been
[03:32:26] <cradek> and now I'm even older
[03:32:29] <jmkasunich> not usually very important
[03:33:04] <cradek> (that's from a great song "Older" by They Might Be Giants)
[03:33:16] <jmkasunich> I wonder what the odds are of successfully "washing" a PCB
[03:33:23] <cradek> washing?
[03:33:35] <jmkasunich> I have a nice, dual output bench supply here
[03:33:45] <jmkasunich> it was scrapped because one output drifts
[03:33:56] <cradek> sounds like a great find
[03:33:59] <jmkasunich> the board has white stains on it, perhaps salt of something
[03:34:08] <jmkasunich> s/of/or
[03:35:12] <cradek> a watchmaker's trick is to was normally in soap and water, rinse well, then dunk in alcohol to displace the water (the alcohol dries quickly and completely)
[03:35:18] <cradek> is to wasH
[03:36:07] <jmkasunich> need a lot of alcohol to dunk a 8x4" board
[03:36:20] <cradek> yeah, not a problem with watches
[03:36:21] <jmkasunich> but maybe I'll take it to work and wash it with Flux Off
[03:36:34] <jmkasunich> thats mostly alcohol anyway
[03:36:51] <cradek> worth a try
[03:37:06] <cradek> I've never understood where the flux goes when you use that spray-on stuff
[03:37:11] <cradek> does it drip off?
[03:37:42] <jmkasunich> if you use enough Flux Off, the flux and cleaner drip off together
[03:38:06] <jmkasunich> we have it in a squeeze bottle, and let it drip into a tray/pan sort of thing
[03:38:40] <jmkasunich> theres a lid on the pan to avoid any embarassing flash fires, but the lid leaks enough that the alcohol evaporates slowly
[03:38:49] <jmkasunich> there's a lot of flux residue in the pan
[03:38:57] <cradek> I see
[03:40:10] <jmkasunich> I'm not feeling ambitious enough to pull the board tonight, there are about 8-10 little connectors
[03:40:16] <jmkasunich> 1,2,3 pins each
[03:40:22] <cradek> you could maybe spray it in place...
[03:40:36] <jmkasunich> one side of the board is up against the front panel
[03:40:40] <cradek> get your devel laptop working?
[03:41:13] <jmkasunich> yeah, I was just missing the rtai-modules-2.6.12-magma package
[03:41:21] <jmkasunich> just finished a make
[03:41:24] <cradek> ah
[03:41:45] <jmkasunich> I guess its not in build-deps because it is distro specific
[03:41:48] <cradek> unfortunately that's probably a build dep, but it seems wrong to depend on kernel modules to build a deb (and therefore on a particular kernel image)
[03:41:56] <jmkasunich> right
[03:42:07] <cradek> emc is an odd one
[03:42:25] <jmkasunich> yeah, most apps don't have kernel modules, let alone require kernel patches
[03:42:26] <cradek> some of the usual things don't quite fit
[03:42:30] <cradek> yeah.
[03:43:40] <jmkasunich> one of these days I'm gonna brave the kernel compile
[03:43:50] <cradek> it's not hard.
[03:44:00] <cradek> making correct debs is hard.
[03:44:13] <cradek> bordering on ridiculous
[03:44:14] <jmkasunich> I brought a whole load of crap home today (the power supply, the logic analyzer, several KVM swtiches, etc)
[03:44:21] <jmkasunich> one item is a dual CPU computer
[03:44:30] <jmkasunich> I want to make an SMP kernel with RTAI
[03:44:32] <cradek> cool
[03:44:38] <cradek> yeah I wonder about that too
[03:44:48] <cradek> seems there's occasionally talk on the rtai list about it.
[03:44:56] <jmkasunich> this box was a high end development machine
[03:45:07] <jmkasunich> rambus memory (remember that?)
[03:45:18] <cradek> yeah, it's sure expensive today
[03:45:22] <jmkasunich> two 667MHz Pentium3's
[03:45:31] <cradek> nice
[03:45:50] <cradek> my mill is a (uni) PIII-666
[03:45:56] <jmkasunich> there are 2x 128M sticks in the box, and I have one more here
[03:46:05] <cradek> but it also has a socket for another processor
[03:46:23] <cradek> it's also server grade
[03:46:34] <cradek> (sounds like a jet)
[03:46:41] <jmkasunich> thats kinda what these are
[03:46:49] <jmkasunich> dunno about sound, haven't powered it yet
[03:46:56] <cradek> I'm sure it'll be plenty loud
[03:47:02] <cradek> I like using used stuff
[03:47:28] <jmkasunich> same here
[03:47:32] <jmkasunich> recycling!
[03:47:32] <cradek> in "cheap, fast, good: pick two" old server hardware is definitely cheap/good
[03:48:02] <jmkasunich> when they bought it, they picked fast and good
[03:48:06] <jmkasunich> the fast changed with time
[03:48:08] <cradek> I recently bought a cheap/fast motherboard and processor too, that's also nice to have
[03:48:14] <cradek> yeah
[03:48:22] <jmkasunich> but when it winds up in the dumpster, cheap is very high, and good lasts
[03:48:45] <cradek> I guess good is the only permanent one
[03:48:56] <jmkasunich> yeah
[03:49:04] <jmkasunich> server grade stuff is definitely good
[03:49:10] <jmkasunich> dual power supplies
[03:49:17] <jmkasunich> everything easy to swap out
[03:49:32] <jmkasunich> thats why I was looking for a home for that disk array
[03:49:58] <jmkasunich> I wish I had space for the cabinets
[03:50:12] <jmkasunich> three 19" racks, 6ft tall, very high end stuff
[03:50:23] <jmkasunich> each one probably had $100K of server stuff in it
[03:50:54] <jmkasunich> nice full extension ball bearing slides...
[03:51:19] <jmkasunich> you're connection died again didn't it? ;-/
[03:53:33] <cradek> yep
[03:53:35] <cradek> durnit
[03:54:00] <jmkasunich> you don't lose anything, it just pauses for a long time?
[03:54:17] <cradek> I have to restart my ssh
[03:54:27] <cradek> I think it's because of the NAT table filling
[03:54:44] <cradek> I use one of those stupid wireless router things to connect to my broadband
[03:54:48] <jmkasunich> how many boxes do you have on your net?
[03:55:01] <cradek> not sure, a handful
[03:55:09] <jmkasunich> I have one of those stupid router things, not wireless tho
[03:55:16] <jmkasunich> no probs to date
[03:56:00] <jmkasunich> I have my wife's win XP box, this one, the compile farm (one node on the house network, it has its own router and subnet) and occasionally something else (like the laptop)
[03:56:25] <cradek> a high number of simultanous connections is what kills nat
[03:56:38] <cradek> I think because it has to keep a table of all of them for "a while"
[03:56:42] <jmkasunich> oh, and my win95 box, on the rare occasion I run it
[03:57:13] <jmkasunich> yeah, if they don't chose a good value for "a while" they have problems
[03:57:43] <jmkasunich> if I had a nice, quiet, fanless linux box I'd be tempted to use that for a router
[03:59:31] <cradek> yeah, I'm tempted to use a pc for nat again
[03:59:41] <cradek> I was happy to stop doing that when these boxes became cheap
[03:59:55] <jmkasunich> I set up one slot of the compile farm to do that just for the farm
[04:00:13] <jmkasunich> when we had the emcfest at Smithy the farm also routed for all the folks who were there
[04:01:24] <cradek> I had an old high-powered development machine (a 486 (!) with 32 meg (!) of ram) doing nat at home for years
[04:01:30] <jmkasunich> heh
[04:01:36] <jmkasunich> hmm
[04:01:48] <jmkasunich> remember those wavelan PCMCIA cards?
[04:01:55] <jmkasunich> they were installed in wireless access points
[04:01:56] <cradek> yep
[04:02:09] <jmkasunich> a box about 9x6x1"
[04:02:13] <jmkasunich> with a 486 inside
[04:02:30] <cradek> cool
[04:02:31] <jmkasunich> and what appears to be (from the sticker on it) an Award BIOS
[04:02:40] <jmkasunich> no video or keyboard connector tho
[04:02:42] <cradek> that would still be fine for nat (if it had enough ram)
[04:02:56] <jmkasunich> two pcmcia slots and an ethernet
[04:03:08] <jmkasunich> dunno if there was any other I/O, they're still out in the truck
[04:03:17] <jmkasunich> I'll know tomorrow when I unload
[04:03:21] <jmkasunich> no disk either
[04:04:15] <jmkasunich> a wireless access point isn't too different from a router in terms of HW requirements I don't think
[04:04:16] <cradek> you should take your remaining stuff to fest
[04:04:34] <cradek> I bet you could unload it at the ending auction/swap
[04:04:48] <jmkasunich> yeah, I will try to unload some of the junk ^h^h^h^h stuff there
[04:04:59] <jmkasunich> need a KVM switch?
[04:05:06] <cradek> the access point probably has just enough ram for a normal home user's nat. I need a lot more.
[04:05:21] <jmkasunich> you mean your access point?
[04:05:34] <cradek> yes
[04:05:50] <jmkasunich> yeah, its probably strictly consumer grade
[04:08:23] <jmkasunich> hmm, googling seems to indicate that the contraptions I have were simple bridges
[04:14:29] <jmkasunich> well well well.... 16 port KVM switches seem to bring pretty good bucks on ebay
[04:14:39] <cradek> I bet they do
[04:14:41] <cradek> those are not cheap
[04:14:46] <cradek> do you have the cables?
[04:14:48] <jmkasunich> I got two
[04:14:54] <jmkasunich> and 16 cables
[04:15:00] <cradek> wow
[04:15:12] <jmkasunich> also have three 4-way ones and some cables for those too
[04:15:39] <cradek> I could sure use one of those 16s at work, I'll get one someday
[04:15:44] <jmkasunich> (the 16-way ones use proprietary cables, DB-25 on the switch end, the 4-ways have normal connectors
[04:15:58] <jmkasunich> I'll make you such a deal ;-)
[04:16:05] <cradek> no, that was NOT a hint
[04:16:13] <cradek> you should sell them
[04:16:40] <jmkasunich> seriously, selling is a bit of a pain, if someone I know can use it, I'll either give it away or sell it cheap
[04:16:47] <jmkasunich> I didn't pay anything for it
[04:17:10] <cradek> they're probably worth actual money though.
[04:17:10] <jmkasunich> tomorrow when I unpack I'll get model info, etc
[04:17:14] <cradek> ok
[04:17:19] <jmkasunich> I'm pretty sure they're Black Box brand
[04:17:33] <cradek> I bet they weren't cheap then
[04:17:56] <jmkasunich> one is really a black box, it must be remotely managed. nothing at all on the front panel
[04:18:02] <jmkasunich> the other one has lights and buttons
[04:18:18] <cradek> some have magic key combinations I think
[04:18:35] <jmkasunich> could be, or it could be for a layered system
[04:18:55] <cradek> my office at work is next to the machine room - someday I'll knock a hole in the wall for a nice kvm
[04:18:58] <jmkasunich> tree structure, slave boxes feeding a master box that feeds the keyboard and monitor
[04:19:11] <cradek> I'm forever climbing behind the racks to plug the monitor into the right thing
[04:19:18] <jmkasunich> that sucks
[04:19:48] <jmkasunich> if the kvm works from key sequences, you don't even need a big hole - just big enough for one cable
[04:19:54] <cradek> yeah
[04:19:59] <cradek> that would be entirely slick
[04:20:13] <jmkasunich> once I get part numbers we can google
[04:20:16] <cradek> ok
[04:20:30] <jmkasunich> one nice thing about black box, they don't care where you got it, their tech support will talk to you
[04:20:35] <cradek> cool
[04:20:52] <jmkasunich> my current 2-way is a black box, I had some problems with it (turned out to be a PC problem)
[04:21:00] <jmkasunich> the guy spend 20 mins on the phone with me
[04:21:19] <cradek> sometimes companies have the right idea.
[04:21:26] <jmkasunich> the old HP pc worked fine with a HP PS-2 mouse, but not when connected thru the KVM
[04:21:41] <jmkasunich> then I found out that it also didn't work with a M$ PS-2 mouse
[04:21:48] <jmkasunich> the KVM emulates a M$ moust
[04:21:54] <cradek> ah
[04:22:04] <jmkasunich> the HP mobo or something must not like MS mice
[04:22:33] <cradek> that's a bizarre feature
[04:22:34] <jmkasunich> this was old stuff, that computer is long gone
[04:23:08] <cradek> ugh, trying to figure out the final direction (normal vector) on an arc/helix
[04:23:27] <jmkasunich> anyway, I think I'm gonna use one of the 4-way switches at my bench. I have two computers, but sometimes I want to test another box, or run a laptop without the horrible keyboard, etc
[04:23:36] <jmkasunich> eww
[04:23:40] <cradek> yeah that sounds nice
[04:24:00] <jmkasunich> if it was earlier and I wasn't tired I could maybe understand some of that
[04:24:02] <cradek> I like to have a two-input monitor for hooking up an extra
[04:24:25] <cradek> oh, I'll get it, I understood (fixed) helixes once
[04:24:31] <cradek> it's just finicky
[04:24:33] <jmkasunich> once - that is the key word
[04:24:44] <cradek> yep
[04:24:50] <jmkasunich> I understood quaternions and 3-d transform matrices once too
[04:25:14] <jmkasunich> wrote a whole bunch of 3d graphics stuff back in the day
[04:25:21] <cradek> sure wish I had all the education I briefly (serially) had in college
[04:25:38] <jmkasunich> yeah
[04:25:39] <cradek> it's just not possible to keep it all
[04:25:50] <jmkasunich> most of it lasted just long enough to pass the final
[04:25:56] <jmkasunich> I hated the purely theoritical stuff
[04:26:04] <jmkasunich> differential equations
[04:26:31] <jmkasunich> I understand the basic concepts, but withing a few months I forgot how to solve them analytically
[04:26:31] <cradek> yeah I wish I had the grasp on diff eq and statistics that I briefly had, for example
[04:27:37] <jmkasunich> the fact that I've managed to work as an EE for 21 years now with a nearly non-existant knowledge of diff-e-queues tells me something tho... ;-)
[04:28:02] <cradek> shhhh
[04:28:06] <cradek> don't give the secret away
[04:29:06] <jmkasunich> well, I think its bedtime
[04:29:12] <jmkasunich> have to catch up on my sleep
[04:29:18] <cradek> ok, goodnight
[04:29:20] <cradek> good idea
[04:29:29] <jmkasunich> jmkasunich is now known as jmk-sleep
[11:02:24] <alex_joni> morning all
[14:24:26] <cradek> hi alex
[14:30:07] <alex_joni> morning chris
[14:30:14] <alex_joni> * alex_joni is busy making sushi ;)
[14:31:18] <cradek> that sounds interesting
[14:32:25] <alex_joni> yeah ;) waiting for rice to boil
[14:33:27] <cradek> I have our planned tp fix partly done
[14:34:01] <alex_joni> you did? nice.. I had a bit of problems with cncuser
[14:34:09] <alex_joni> seems our TESTING is broken for 2.4 builds
[14:34:24] <cradek> my testing showed the reversal problem only when I was using FO over about 1.6 - is that what you saw too?
[14:34:37] <cradek> alex_joni: I think there's a vti rule missing in TESTING
[14:34:40] <alex_joni> I wasn't sure how to solve this (I knew how to solve it for him.. but not sure if I should move TESTING or not)
[14:34:41] <cradek> it's fixed in HEAD
[14:34:45] <alex_joni> yes, exactly
[14:35:11] <cradek> maybe we should move TESTING today especially if we're going to change tp.
[14:35:55] <alex_joni> ok, we should
[14:36:14] <cradek> ok, but a little later
[14:36:50] <alex_joni> yeah, sure
[14:36:58] <alex_joni> I'm worrying about wasabi right now :)))
[19:35:18] <rayh> alex_joni: You around. I need a bit of help with halscope.
[19:35:52] <cradek> maybe I can help?
[19:36:11] <rayh> Okay.
[19:36:24] <rayh> I'm guessing that accel is a rate of change thing.
[19:36:40] <cradek> yeah
[19:36:45] <cradek> in sim.ini there are some ddt blocks
[19:36:49] <rayh> so watch servo thread
[19:37:04] <rayh> link commanded to ddt and watch it's out?
[19:37:08] <cradek> you should stick those in your config
[19:37:10] <cradek> right
[19:37:16] <cradek> that'll give velocity, do it once more and you have accel
[19:37:39] <cradek> accel should look pretty much like a square wave +- maxaccel
[19:37:45] <rayh> so comand ->ddt->ddt->scope
[19:37:53] <cradek> err not sim.ini, core_sim.hal or something like that
[19:37:56] <cradek> right
[19:38:12] <rayh> I'm using stepper so that ought to be okay.
[19:38:41] <rayh> If I compare to command it's delayed by two?
[19:38:58] <cradek> not sure about that, probably right
[19:39:03] <cradek> linksp Xpos => ddt.0.in
[19:39:03] <cradek> linkps ddt.0.out => Xvel
[19:39:03] <cradek> linksp Xvel => ddt.1.in
[19:39:03] <cradek> linkps ddt.1.out => Xacc
[19:39:17] <cradek> something like this stuff from core_sim.hal is what you need
[19:39:22] <rayh> oh position rather than command
[19:39:38] <rayh> okay. Let me try and I'll get back.
[19:39:41] <cradek> makes it really easy to see what tp is doing
[19:39:43] <cradek> linksp Xpos <= axis.0.motor-pos-cmd
[19:39:58] <cradek> ok
[19:47:54] <jmk-sleep> jmk-sleep is now known as jmkasunich
[19:52:39] <rayh> I'm seeing a hop to +10 and then after a bit a tiny tiny spike to +15 then back to 10
[19:52:58] <rayh> the minus does not show the extra, just a nice clean +10
[19:53:45] <jmkasunich> hi guys
[19:53:47] <rayh> This is the arc to line back.
[19:53:52] <jmkasunich> looks like progress is being made
[19:53:52] <rayh> Hi John.
[19:54:15] <rayh> Looks like a lot of it.
[19:54:25] <cradek> rayh: even on line-line I still have a problem:
[19:54:26] <cradek> http://timeguy.com/cradek-files/emc/overshoot-fix3.png
[19:54:31] <jmkasunich> anything I can do to help? (testing or such?)
[19:54:44] <rayh> same direction or reversal?
[19:55:02] <jmkasunich> reversal looks like
[19:55:14] <rayh> Let me send you a gcode file to run. dcc?
[19:55:17] <cradek> yeah g1->g0 reversal
[19:55:28] <cradek> me? sure
[19:55:33] <jmkasunich> rayh: I have troubles with dcc (NAT I think)
[19:55:35] <jmkasunich> email it
[19:55:58] <rayh> Okay. Will do. Gotta sneakernet first.
[19:56:46] <jmkasunich> I really should figure that out and fix it
[19:57:07] <cradek> jmkasunich: typically you can forward one incoming port and tell your irc client to use it
[19:57:22] <cradek> jmkasunich: depends somewhat on the client
[19:57:32] <jmkasunich> I use several clients
[19:57:44] <cradek> you will have to configure each of them to use that port
[19:57:46] <jmkasunich> X-chat here on ubuntu, ksirc on KDE
[19:58:05] <jmkasunich> what are the security implications of forwarding a port?
[19:58:15] <cradek> depends what's listening there
[19:59:03] <jmkasunich> well, I don't want to get into networking stuff right now - you guys are on a roll, lets stick with TP
[19:59:15] <cradek> ok
[19:59:23] <cradek> I'm not sure we're on a roll though...
[19:59:38] <jmkasunich> well any improvement to the TP at all is a big thing
[19:59:59] <rayh> on the way.
[20:00:09] <jmkasunich> got it
[20:00:15] <jmkasunich> what config are you running?
[20:01:02] <rayh> I'm running a stepper. You could extract it from a tarball at www.linuxcnc.org/Dropbox/tp-testing.tgz
[20:01:34] <cradek> it's a fast-moving stepper config, that's for sure
[20:01:46] <rayh> But it's fast base_thread is 10, rapid 180, feed override 300%.
[20:01:56] <cradek> rayh: is this for a real machine?
[20:02:12] <jmkasunich> what would be most beneficial? me duplicating Ray's testing, or running another config, say sim, and looking at the TP output with scope?
[20:02:20] <rayh> No Just for testing. It is very close to what Smithy is running with Rutex drives.
[20:02:53] <rayh> I'm pretty confident that my results are replicable.
[20:03:11] <rayh> cradek: helped with halscope setup.
[20:06:56] <cradek> ok I've verified that this is NOT a feed override problem
[20:07:25] <cradek> you can get the accel spike with FO 100% if you just set F90 in ray's program
[20:11:26] <cradek> found my smoking gun
[20:12:05] <cradek> http://timeguy.com/cradek-files/emc/overshoot-fix4.png
[20:12:30] <jmkasunich> eww
[20:12:51] <jmkasunich> those are blends between colinear moves?
[20:12:59] <cradek> no, reversals
[20:13:07] <jmkasunich> huh?
[20:13:08] <cradek> they're right except for the spike to 2*maxaccel
[20:13:16] <jmkasunich> top trace is position right?
[20:13:20] <cradek> no, vel
[20:13:37] <cradek> from top down: vel, accel, number of active TCs
[20:13:37] <jmkasunich> duh
[20:13:41] <jmkasunich> ok
[20:13:51] <jmkasunich> brainfart, sorry
[20:13:53] <cradek> np
[20:14:08] <rayh> That's about what I'm seeing except that the width of the +15 spike isn't as wide.
[20:14:17] <jmkasunich> where is zero vel? 2 divs down from top?
[20:14:19] <rayh> uh narrower.
[20:14:24] <cradek> rayh: increase your feed a bit, you'll see it
[20:14:33] <cradek> rayh: also I think it actually goes to 20
[20:14:36] <rayh> k
[20:15:01] <cradek> jmkasunich: I think I don't have it right on a div
[20:15:09] <cradek> jmkasunich: but it is in the middle somewhere
[20:15:21] <jmkasunich> probably right in the middle of the too-fast ramp
[20:15:36] <cradek> yes very near there
[20:18:20] <rayh> on the arc to line it stayed the same but I see it now on the colinear as well.
[20:20:18] <rayh> You're right about the 20 on colinear. Must be a rapid to feed thing
[20:20:38] <rayh> the arc at feed to rapid reverse doesn't do it.
[20:21:13] <cradek> I don't think the motion type (rapid/feed) should matter
[20:22:15] <cradek> I think we've got a fundamental problem my simple fix isn't going to fix
[20:22:40] <rayh> It made blending a world better.
[20:23:04] <jmkasunich> incremental improvements are worthwhile
[20:23:07] <rayh> You say it's not a scale issue
[20:23:10] <cradek> yeah but these accels are still a big problem
[20:23:29] <cradek> I think I can write a program where you'll see 3x 4x 5x accel
[20:23:43] <jmkasunich> oh....
[20:23:59] <rayh> Think it's blending inside blending inside blending?
[20:24:34] <jmkasunich> short segments need that (multiple blends)
[20:24:52] <rayh> yes
[20:25:29] <jmkasunich> G0 X0 Y0 Z0 ; G0 X0.999 ; G0 X 1.0 ; G0 Y 1.0
[20:26:28] <cradek> no I can't seem to get 3x - maybe it's not as bad as I thought
[20:27:15] <rayh> What are the possible ways it can violate accel.
[20:27:59] <cradek> assuming all my fixes are right (you don't have some of them yet) the remaining way is just what your program does, go one way fast, a tiny perpendicular move, then back the other way fast
[20:28:19] <rayh> It can't just start a blend and then during decel say oops I'm not going to overshoot so hit the brakes harder.
[20:28:20] <cradek> see how it's the same as a reversal, except the reversal isn't adjacent moves?
[20:28:34] <cradek> I only fixed reversals that are adjacent moves
[20:28:46] <rayh> Okay.
[20:28:54] <jmkasunich> the general case needs unlimited lookahead
[20:29:00] <jmkasunich> messy
[20:31:11] <rayh> I've got a 2 gig contouring program that was the final exam for sherline's setup.
[20:31:25] <rayh> I'm going to try it here and watch accel.
[20:31:44] <cradek> yeah maybe set trigger at 11
[20:31:59] <cradek> are there no arcs in it?
[20:33:49] <jmkasunich> triggering at 11 will miss -11
[20:34:01] <jmkasunich> also only sees one axis
[20:34:27] <cradek> yeah, but he'll get one anyway I bet
[20:34:36] <jmkasunich> with some hal-fu you could run each accel signal into a wcomp (window comparator) that will switch if it exceeds -11 or +11
[20:35:06] <jmkasunich> then run all three comparator outputs into an AND (comp is true when inside the window, so false is an error)
[20:35:24] <jmkasunich> trigger on the and output going false
[20:38:57] <cradek> jmkasunich: how do I printf in kernelspace?
[20:40:43] <jmkasunich> printk is the kernel api
[20:40:50] <cradek> thanks
[20:40:52] <jmkasunich> rtapi_print is preferred tho
[20:41:14] <cradek> rtapi_print takes %d etc?
[20:41:24] <jmkasunich> theres also rtapi_print_msg(<msg-level>, foo)
[20:41:28] <jmkasunich> yes, but
[20:41:31] <jmkasunich> no %f
[20:41:34] <cradek> ok
[20:41:45] <cradek> [insert standard whine about not having a debugger here]
[20:41:54] <jmkasunich> yeah
[20:42:02] <cradek> I looked into the kernel gdb stuff
[20:42:16] <cradek> looks like it has a patch that hooks into all the same places rtai does
[20:42:20] <jmkasunich> you already know you can export additional HAL pins if you want
[20:42:31] <cradek> some people in the past have made it work for certain versions of kernel/rtai but not recently
[20:42:44] <cradek> jmkasunich: yep
[20:42:47] <rayh> I'm not seeing any unexpected accel during contouring.
[20:43:01] <cradek> rayh: all g1?
[20:43:59] <rayh> Yes
[20:44:18] <rayh> thousands of z changes
[20:44:42] <rayh> I'll try increasing feedrate and see what happens.
[20:49:06] <rayh> I'm seeing some +15 and a few +20 at f600 mm/min
[20:49:27] <cradek> spikes to 15 or levels at 15?
[20:52:38] <jmkasunich> I got a -15 spike with a very simple program
[20:53:03] <cradek> jmkasunich: you're running HEAD from the last couple hours?
[20:53:07] <jmkasunich> yes
[20:53:25] <jmkasunich> using sim config, with accels and vels to match rays
[20:53:33] <jmkasunich> and no FO
[20:53:37] <cradek> ok
[20:54:00] <jmkasunich> g0 x0 y0 z0 ; x0.999 ; x 1 ; y1
[20:54:50] <cradek> which axis has the accel spike?
[20:55:06] <rayh> For the most part on this heart program the accel is constrained. Very few exceed.
[20:55:23] <jmkasunich> X
[20:55:44] <jmkasunich> I just changed the y1 to y0, the spike is still there with no Y motion at all
[20:56:04] <jmkasunich> the spike is at the beginning of the decel period,it goes to -15, then -10
[20:56:31] <cradek> arg
[20:58:08] <jmkasunich> I also get a spike as it turns around (when I re-run the prog, it goes from X1 back to X0 and then immedately heads for X0.999)
[20:59:02] <jmkasunich> accel is +10 as the 1 -> 0 move finishes, spikes for one sample, then goes back to +10 as the 0->0.999 move begins
[20:59:26] <jmkasunich> the spike looks like about +13
[21:00:18] <jmkasunich> correction, it doesn't spike for one sample
[21:00:24] <cradek> well that's better than recently when you would have had +20 for the whole thing
[21:00:26] <jmkasunich> I didn't zoom in enough
[21:00:52] <jmkasunich> it ramps from +10 to +14 over about 10mS, then back to +10 over 20mS
[21:01:15] <jmkasunich> the other spike (on decel) is even more complex
[21:01:16] <cradek> huh, so it actually is more than one wrong cycle
[21:01:29] <cradek> can you also plot active-depth
[21:01:45] <cradek> well it can't be more than 1, since you only have two moves in your program
[21:01:58] <jmkasunich> was crusing at 0, then ramped to -3 over 10mS, then ramped to -13 over 10mS, held at -13 for 10mS, then ramped to -10 in 10mS
[21:02:41] <jmkasunich> I changed the program a little, to ensure a non-zero cruise period
[21:02:57] <jmkasunich> g0 x0 y0 z0 ; x 1.99 ; x2 ; m2
[21:04:02] <jmkasunich> duh - the 10mS stuff is coming from the TP period
[21:05:11] <jmkasunich> the TP only runs every 10mS, the 10mS long ramps are from the interpolator
[21:05:17] <cradek> oh ok
[21:09:52] <jmkasunich> I added some additional lines
[21:10:24] <jmkasunich> instead of x1.99, I have x1.990 ; x1.991; x1.992 ; x1.993, etc
[21:10:43] <jmkasunich> traj.active_tc now goes to 3
[21:11:06] <jmkasunich> and I have a couple disturbances, one from -10 to -7, one from -10 to -15
[21:11:51] <jmkasunich> the disturbances seem to coincide with times when active_tc is _decreasing_
[21:12:27] <skunkworks> logger_devel: bookmark
[21:12:27] <skunkworks> See
http://solaris.cs.utt.ro/irc/irc.freenode.net:6667/emcdevel/2006-02-25#T21-12-27
[21:14:32] <cradek> jmkasunich: I'm looking for a tc removal bug, but not seeing anything right off
[21:18:07] <cradek> jmkasunich: you're not ever seeing velocity violations, right?
[21:18:38] <jmkasunich> wasn't even looking for vel viols, lemme check
[21:19:05] <jmkasunich> nope, +/- 3 inches/src
[21:19:08] <jmkasunich> sec even
[21:41:36] <rayh> I'm about 1/2 way through the contouring program. My impression is that it will produce +20 on some odd longer z moves but for the most part seems well constrained. .
[21:41:53] <rayh> It should work fine running a Sherline.
[21:42:11] <cradek> unless that +20 stalls the steppers
[21:42:18] <jmkasunich> yeah
[21:42:47] <rayh> I really doubt that it will. This is running about 40 ipm and the sherline will run about 20.
[21:43:08] <jmkasunich> you have to set STEPGEN_MAXACCEL to 20 to prevent following errors, but you can only use 10 of that
[21:43:31] <jmkasunich> basically, whatever the steppers actual accel capability is, you have to leave half of it unused because of this bug
[21:43:36] <rayh> Many of the blocks in this code are moves less than 0.0005 so blocks are getting blended fairly quickly.
[21:44:12] <rayh> Right I understand the overhead issue.
[21:44:42] <rayh> But if you compare your worst results with the image in tp-test.tgz you will see the improvement.
[21:45:08] <jmkasunich> no doubt there has been improvement
[21:45:09] <cradek> yeah no question it's better
[21:45:10] <rayh> Just in terms of visual moves
[21:45:46] <rayh> Perhaps tomorrow I can set up the sherline and run this code.
[21:45:51] <cradek> "stop and turn around, then blend" is hard to beat for badness
[21:46:06] <rayh> I'm going to be that the motors will sing just as well as they do with old freqmod.
[21:46:20] <rayh> bet
[21:47:03] <rayh> I'll also bet that I don't see any significant disturbances with univstep.
[21:53:16] <cradek> argh, starting halscope too soon makes it eat its config file
[21:53:59] <rayh> That's not very civil.
[21:54:12] <jmkasunich> it needs work
[21:54:24] <jmkasunich> I want to be able to save named configs too
[21:54:44] <cradek> jmkasunich: I just start in a different directory to do that
[21:55:10] <jmkasunich> it would be nice to be able to change configs without even leaving the program
[21:55:16] <cradek> I agree
[21:55:30] <jmkasunich> IOW, one config to look at all three axis accels, another to look at one axis in detail, or whatever
[21:55:31] <cradek> or a "some last used configs" menu
[21:55:38] <cradek> yeah
[21:56:34] <jmkasunich> as far as starting it is concerned, add a loadusr halscope line at the end of your last hal file
[21:56:49] <cradek> done, thanks
[21:57:42] <cradek> argh, I hate these pm functions
[21:57:59] <jmkasunich> posemath?
[21:58:01] <cradek> yeah
[21:58:05] <cradek> they're so clumsy to use
[21:58:48] <cradek> instead of returning their result, you have to pass an address
[21:58:56] <cradek> so you need temporary variables for every single thing you do
[21:59:34] <cradek> if ( dot(unit(vector), unit(vector)) > 0 ) ...
[21:59:35] <jmkasunich> returning structs is fairly new to C isn't it?
[21:59:56] <cradek> you can't write this without three variables
[22:00:17] <cradek> no, I think even k&r C did that (and had struct assignment)
[22:01:12] <jmkasunich> not true
[22:01:29] <jmkasunich> K&R p. 209
[22:01:56] <jmkasunich> there are only 2 things that can be done with structs or unions, name on of its members or take its address
[22:02:19] <jmkasunich> operations such as assigning to or from it or passing it as a parameter draw an error message
[22:02:30] <cradek> wow
[22:02:36] <cradek> is that the pre-ansi version?
[22:03:08] <rayh> Yep 1978
[22:03:10] <jmkasunich> copyright 1978 ;-) I bought it for a C class in college, circa 1983
[22:03:18] <cradek> ok then dot should at least return a double! :-)
[22:03:24] <rayh> page 209
[22:03:33] <jmkasunich> agreed about dot
[22:03:43] <cradek> you guys need new books, I'm sure mine is post-ansi (wherever it is)
[22:03:57] <jmkasunich> 2nd edition probably
[22:04:03] <cradek> yeah
[22:04:15] <LawrenceG> cradek: Hi Chris.... do I detect that another improvement in the tp has been made?
[22:04:25] <rayh> I'm not seeing the same limitation in 2
[22:04:31] <cradek> LawrenceG: you could call it that if you're generous...
[22:05:14] <jmkasunich> waitaminnit - Rayh, the self proclaimed "not a programmer" has BOTH editions of K&R?
[22:05:21] <cradek> haha
[22:05:21] <jmkasunich> the truth comes out at last!
[22:06:01] <cradek> so maybe for only ... 20 years has this been possible
[22:06:02] <rayh> I'm old enough to have met both of them.
[22:06:20] <cradek> ok moving on...
[22:06:33] <rayh> They were at the u of o for a seminar
[22:07:12] <jmkasunich> cradek: I never got used to returning anything bigger than a long (nor to passing anything bigger than a long directly)
[22:07:54] <jmkasunich> too much copying
[22:08:53] <cradek> maybe I just hate C
[22:09:24] <jmkasunich> ;-P
[22:09:59] <rayh> "Structures bay be assigned, passed to functions, and returned by functions" second edition 260
[22:10:10] <alex_joni> hi guys
[22:10:14] <alex_joni> * alex_joni reads back
[22:10:19] <rayh> Hi alex.
[22:10:38] <cradek> rayh: what year is that one?
[22:11:23] <jmkasunich> they left out the part that says "but doing so invokes the equivalent of 'memcpy(from, to, sizeof(struct))' "
[22:11:24] <rayh> 1988
[22:13:09] <rayh> It also notes that they got rid of 8 and 9 as octal numbers.
[22:13:51] <cradek> 8 and 9 are some pretty funny octal numbers
[22:13:58] <jmkasunich> octal is one of the abominations of C
[22:17:11] <cradek> 25 is close enough to 10, isn't it?
[22:17:17] <rayh> Yep.
[22:17:44] <rayh> more that half of the changes in accel are less than 5
[22:18:14] <rayh> less than 10 percent are greater than 10
[22:20:12] <alex_joni> ok, I've finished catching up
[22:21:42] <alex_joni> cradek: what's the plan?
[22:23:21] <cradek> alex_joni: no plan here
[22:23:53] <alex_joni> then we need to get us one ;)
[22:25:43] <cradek> I'm experimenting to see if I can stumble onto reasonable blending
[22:26:11] <alex_joni> stumble?
[22:26:51] <cradek> well I know what various problems are, I sort of know things that might fix them, so I'm experimenting
[22:27:18] <alex_joni> ok :)
[22:27:24] <alex_joni> say if you need me to do something...
[22:28:09] <cradek> ok thanks
[22:28:17] <cradek> but I'm not even sure what I need to do...
[22:29:11] <alex_joni> think we need a testing program (one that gets all cases of blending)
[22:29:35] <cradek> I think ray was working on that
[22:29:57] <rayh> I was until I started this contouring program.
[22:39:49] <cradek> ok I have some interesting results now I think
[22:40:20] <cradek> sharp turns are blended less, accel constraints are always honored (I think)
[22:40:41] <cradek> much better path following
[22:40:42] <alex_joni> darn, having connection problems.. :(
[22:50:43] <alex_joni> >70% packet loss.. fscked:/
[22:55:21] <cradek> I don't like the results anyway
[23:02:14] <alex_joni> I don't like this crappy connection :(
[23:09:27] <alex_joni> good thing I have backup connections
[23:15:04] <alex_joni> how come you don't like the results?
[23:15:22] <cradek> I think there's too little blending now
[23:19:08] <rayh> I've got halscope vertical scale set to 10. Should there be one division excursion for max accel?
[23:19:24] <cradek> yes +- 1 div
[23:19:42] <rayh> I saw quite a few 20 then.
[23:21:17] <cradek> yeah I know...
[23:23:48] <rayh> They all seem to be colinear blends.
[23:27:21] <rayh> I don't see any of the hop to 10 then hop to 20 back to 10 and then zero.
[23:27:31] <rayh> If it wants 20 it goes right to it.
[23:34:46] <rayh> gotta be away for a while.
[23:34:58] <rayh> rayh is now known as rayh-away
