Back
[08:06:38] <alex_joni> http://learning.dtpm.unipa.it/emc/it/demo.htm <- that's nice :)
[12:30:17] <jepler> Guest905: morning sam
[12:41:22] <alex_joni> hi jeff
[12:42:14] <jepler> hi alex
[12:42:29] <jepler> fenn: was it arc commands or all MDI?
[12:43:35] <Guest905> Good morning
[12:43:42] <Guest905> Guest905 is now known as skunkworks_
[12:44:02] <skunkworks_> hello
[12:44:08] <skunkworks_> crap
[12:44:54] <Guest905> Guest905 is now known as skunkworks_
[12:45:10] <skunkworks_> jepler: good morning
[12:46:52] <alex_joni> jepler: I'm fairly confident the last version I put on the pastebin should be ok
[12:47:15] <alex_joni> pastebin.ca/744883
[12:53:17] <jepler> alex_joni: I'll try to look at it soon
[13:06:22] <alex_joni> jepler: ok, I'll be around today
[13:21:46] <skunkworks___> join ubuntu
[15:34:34] <cradek> did you guys figure out the arc thing?
[15:39:56] <skunkworks_> the small arc takes forever - or different arc issue?
[15:40:11] <cradek> that one
[15:40:21] <skunkworks_> Hi chris
[15:40:28] <cradek> swp/alex/fenn were arguing about it all day yesterday
[15:40:32] <cradek> hi
[15:40:39] <skunkworks_> aw - sorry I missed that. ;)
[15:40:55] <cradek> but, I see no checkin :-)
[15:41:36] <skunkworks_> seems everyone is hiding.
[15:43:32] <skunkworks_> fixed the honda this weekend finally. Turned out to be a coolant temp sensor. (the cel threw a red hearing - egr issue - but after resetting the computer it threw the correct code) ohm test verified it. 25 dollar fix.
[15:43:34] <cradek> I'm so happy 'cause today I found my friends - they're in my head.
[15:43:55] <SWPadnos> we were not arguing!
[15:44:09] <cradek> sorry, the 90s channel is on
[15:44:41] <SWPadnos> we were discussing emphatically
[15:45:19] <cradek> did you figure anything out? I don't want to redo any work, but I'd like it fixed
[15:45:44] <SWPadnos> I think alex hada pastebin that should be right (ish)
[15:46:17] <cradek> http://pastebin.ca/744883
[15:46:36] <SWPadnos> yeah, that looks familiar
[15:46:44] <SWPadnos> it has words and colors and stuff
[15:46:47] <cradek> yay for /lastlog
[15:47:19] <SWPadnos> must be an irssi thing
[15:47:25] <cradek> why didn't he check it in?
[15:47:34] <SWPadnos> inadequate testing?
[15:47:35] <cradek> surely all irc clients have /lastlog...?
[15:47:40] <cradek> /lastlog pastebin
[15:47:48] <SWPadnos> nope, not this one!
[15:47:54] <cradek> amazing
[15:48:02] <SWPadnos> yes, it truly is
[15:48:39] <SWPadnos> ah - that's why I didn't see it in my log - it's not a link
[15:49:10] <SWPadnos> does lastlog only look at the scrollback buffer, or does it seardh the log file(s)?
[15:49:16] <SWPadnos> search
[15:50:12] <cradek> just the local scrollback
[15:50:57] <SWPadnos> ok. I can do searches like firefox - press / in the log and start typing
[15:51:15] <cradek> ah, same thing then
[15:51:40] <SWPadnos> yep. though I do need to use the mouse or do some tabbing around, since it's a GUI focus thing
[15:52:41] <SWPadnos> oh - F6 HOME /searchterm
[15:52:45] <SWPadnos> simple!
[15:52:53] <cradek> alex should check this in so we can test it
[15:53:07] <cradek> what's in there is wrong - no need to be nervous about changing it :-)
[15:53:18] <SWPadnos> you could grab it from the pastebin and test it ...
[15:55:10] <cradek> ok I don't get it
[15:55:13] <SWPadnos> heh
[15:55:25] <cradek> I still don't see velocity being limited by a centripetal calculation
[15:56:29] <SWPadnos> somewhere around line 190-ish?
[15:56:48] <cradek> it's overwritten at line 204
[15:56:54] <alex_joni> * alex_joni is back
[15:58:40] <SWPadnos> I wonder if that check should be for tmax <1.0 or something. I don't see how you could get a negative tmax
[15:58:42] <SWPadnos> at line 201
[15:58:58] <SWPadnos> or 0, unless there's no movement
[15:59:00] <cradek> it's misguided 'defensive' programming
[15:59:26] <alex_joni> cradek: you spotted it again :)
[15:59:56] <cradek> there was a lot of code of that style in emc1 that was meant to cover up errors
[15:59:57] <alex_joni> there are a couple of changes in there which weren't directly related to centripetal
[16:00:05] <alex_joni> that's why I didn't check it in already
[16:00:26] <alex_joni> (for instance I separated circle and axial)
[16:00:44] <alex_joni> now if you have a very slow axis, a circle in XY with a short Z move should be faster than before
[16:00:45] <cradek> yeah that's cool
[16:00:56] <cradek> sometimes people have lower accel on Z
[16:01:01] <alex_joni> or that
[16:01:11] <alex_joni> although the calculations used don't use accel
[16:01:20] <cradek> sometimes people have lower vel on Z
[16:01:24] <cradek> :-)
[16:01:28] <alex_joni> time = distance/vel
[16:01:43] <alex_joni> we should have the real TP function here
[16:01:55] <alex_joni> 1/x accel + cruise + decel
[16:02:04] <alex_joni> or however you did that :D
[16:02:17] <cradek> I don't understand what you're saying
[16:02:45] <alex_joni> lets take only the axial move of the helix
[16:02:52] <SWPadnos> the moves are velocity limited, but the total time doesn't include accel
[16:03:03] <SWPadnos> it's only distance/maxvel
[16:03:07] <alex_joni> we assume it takes taxial = axial_len / maxvel .. right?
[16:03:13] <cradek> these times don't have anything to do with the actual time taken
[16:03:27] <cradek> think of them as parametric t, not time t
[16:03:41] <cradek> (especially since the accel calcs are in time^2)
[16:03:46] <alex_joni> right, but still.. if you'd have a Z with a very low accel
[16:03:57] <alex_joni> and XY with high accel, this doesn't really differentiate
[16:04:26] <cradek> yeah I understand what you're saying
[16:04:35] <cradek> it previously would use the slowest accel from any axis that moves
[16:04:50] <alex_joni> it still does that
[16:04:56] <alex_joni> the accels are computed further down
[16:05:08] <alex_joni> let me test and commit this version
[16:05:15] <alex_joni> then we can talk about it some more..
[16:05:37] <cradek> ok :-)
[16:05:45] <cradek> arcs are a huge pain
[16:24:44] <alex_joni> well.. it's in :)
[16:59:09] <alex_joni> cradek: got a chance to look at it?
[18:18:49] <cradek> alex_joni: not yet, sorry
[19:26:23] <alex_joni> cradek: no worries
[19:27:29] <alex_joni> only thing is that I'll be travelling the next couple of days
[19:27:53] <cradek> I'll look at it
[19:28:14] <alex_joni> I'll be around 1-2 hours
[19:28:43] <alex_joni> OT: one could connect more than one jogwheel for jogging.. right?
[19:28:53] <cradek> sure
[19:28:57] <alex_joni> each joint should have pins for one
[19:29:03] <alex_joni> ok.. was a bit too lazy to look it up
[19:29:05] <cradek> yeah they do
[19:31:45] <alex_joni> ok, cool.. that's what I expected
[19:33:15] <cradek> I think your latest checkin is right
[19:33:20] <cradek> (I haven't run it)
[19:33:59] <alex_joni> debugging by staring, eh?
[19:34:01] <cradek> you don't have to worry about centripetal accel in the // COMPUTE ACCELS section, since centripetal is always orthogonal to the accel along the helix
[19:34:34] <cradek> (I think)
[19:34:35] <alex_joni> and that section already uses the computed vel, which is clamped by centripetal accel
[19:34:38] <alex_joni> (I think)
[19:35:08] <cradek> no I think the vel isn't used
[19:35:31] <cradek> it could accel to c and back down if the segment is long enough and the machine fast enough
[19:35:47] <cradek> * cradek kicks jmkasunich and his various underscores
[19:35:53] <alex_joni> rofl
[19:39:51] <alex_joni> oh, one thing I wondered
[19:40:16] <alex_joni> how can both vel and acc = helical_length / tmax ?
[19:40:49] <alex_joni> shouldn't it be tmax^2 for acc?
[19:40:50] <fenn> acc is wrong
[19:41:09] <alex_joni> fenn: it is.. isn't it?
[19:41:41] <fenn> it usually gets clamped to one of the axis values so it doesnt matter anyway
[19:41:45] <skunkworks_> fenn: what is your video supposed to look like?
[19:41:57] <fenn> skunkworks_: supposed to be a video of me jogging the hexapod simulation around
[19:41:59] <alex_joni> skunkworks_: screwy
[19:43:04] <fenn> yes, its supposed to be screwy ( i think)
[19:43:25] <skunkworks_> ah - all I see is a top cut off view of the hexapod on the left and a partial view of emc on the right
[19:43:45] <alex_joni> where is it?
[19:44:38] <fenn> http://fenn.dyndns.org/pub/irc/test-0000.mpeg
[19:45:02] <fenn> it changes the color of the text in the terminal too
[19:45:25] <fenn> normally more orange than puke colored
[19:46:04] <alex_joni> puke colored? :P
[19:46:10] <alex_joni> don't go there ..
[19:46:27] <SWPadnos> vomit-hued
[19:46:36] <alex_joni> swampy is back :)
[19:46:45] <SWPadnos> not really, I just couldn't pass that up :)
[19:47:12] <alex_joni> it's starting quite slow
[19:47:22] <fenn> it doesnt start that slow normally, only when i'm recording
[19:47:31] <alex_joni> fenn: and beeping very annoyingly
[19:47:36] <fenn> and beeping?
[19:47:45] <alex_joni> there's a very high-pitched tone here
[19:47:58] <fenn> huh. i didnt know it had any audio
[19:48:11] <alex_joni> well.. it does.. very annoying :D
[19:48:35] <alex_joni> btw.. did you see my messages the other day about the hex sim?
[19:48:44] <fenn> oh yes i think that's noise in my motherboard built in sound
[19:49:08] <fenn> about the struts jumping around?
[19:49:09] <alex_joni> I really think you shouldn't place both joints and world
[19:49:27] <fenn> well, otherwise i'd have to re-implement kinematics which i'm not really motivated enough to do
[19:49:38] <alex_joni> why would you?
[19:49:52] <fenn> to get from joint coordinates (hal pins) to world coordinates (gl stuff)
[19:49:53] <alex_joni> can't you just find the joints ends?
[19:50:01] <fenn> that's inverse kinematics
[19:50:05] <fenn> the hard one
[19:50:17] <alex_joni> oh, you don't know how the joints are rotated
[19:50:37] <alex_joni> I understand..
[19:50:47] <alex_joni> can't you include the .c with a py wrapper?
[19:51:00] <fenn> probably
[19:51:13] <fenn> i'm not sure the point though
[19:51:33] <fenn> then i'd have to make something else to update position of the platform in the main loop (in vismach)
[19:51:48] <fenn> instead of halTranslate etc
[19:52:24] <alex_joni> hmm.. probably :)
[19:52:26] <fenn> having access to inverse kinematics seems like a reasonable design goal for vismach though
[19:52:31] <fenn> in general
[19:52:52] <alex_joni> * alex_joni wonders how complex it would be to write a generic vis*.py
[19:53:09] <fenn> * fenn refers alex_joni to the py-opengl manual :)
[19:53:20] <alex_joni> * alex_joni refers to the python manual first
[20:13:00] <alex_joni> fenn: so you agree it should be tmax ^ 2?
[20:13:40] <SWPadnos> I don't think accel is relevant (in that way) for arcs
[20:13:54] <alex_joni> still.. fixing it should be ok :)
[20:13:59] <SWPadnos> heh
[20:14:11] <cradek> huh?
[20:14:12] <SWPadnos> well, if you fix it so it correctly does something wrong, I'm not so sure ;)
[20:15:26] <fenn> i'd have to agree with swp
[20:15:31] <alex_joni> cradek: both vel and acc use the same formula
[20:15:37] <SWPadnos> for a line, you can use a simple test to see if the length is long enough to get to full speed or whatever. for an arc, the accels are used in varying amounts along the arc, so checking the total distance traveled is pointless
[20:15:47] <cradek> alex_joni: yes, and it's right
[20:16:01] <alex_joni> how so?
[20:16:20] <cradek> what do you think is wrong?
[20:16:27] <fenn> acc should be in mm/s^2
[20:16:34] <fenn> as it is now its mm/s
[20:16:37] <cradek> no it's not
[20:17:12] <fenn> cvs seems slow lately
[20:22:30] <alex_joni> fenn: those are not really t in mm/s^2
[20:22:37] <alex_joni> look how they are calculated
[20:22:41] <alex_joni> thelix = length/acc
[20:22:50] <alex_joni> ta = da/accel[a]
[20:22:52] <alex_joni> etc
[20:23:16] <fenn> then velocity is in mm/s^2?
[20:23:20] <alex_joni> nope
[20:23:24] <fenn> wtf
[20:23:30] <fenn> who writes this crap
[20:23:30] <alex_joni> it's just another reusing the same variables
[20:23:34] <alex_joni> * alex_joni smiles
[20:24:06] <cradek> I wrote that crap
[20:24:23] <SWPadnos> variables should be named like temporary_variable_which_is_named_for_one_use_but_has_several_over_the_execution_of_this_confusing_function
[20:24:25] <fenn> why is thelix = (helical_length / acc)
[20:24:47] <fenn> time is seconds, not seconds^2
[20:24:48] <alex_joni> SWPadnos: you forgot hungarian notation
[20:25:04] <cradek> add a dozen square-roots and then square the max if you want, but that would be stupid
[20:25:05] <alex_joni> thelix = temporary variable dealing with helix
[20:25:22] <fenn> cradek: it might be verbose, but it would be right
[20:25:39] <cradek> * cradek makes a wanking motion
[20:26:03] <lerneaen_hydra> O_o
[20:26:26] <alex_joni> what if we call it dvhelix :P
[20:26:47] <fenn> i dont see the problem with naming variables what they actually mean
[20:26:49] <cradek> t²helix
[20:26:53] <alex_joni> yeah.. that
[20:27:21] <SWPadnos> vIDontAlwaysLikeHungarianNotation
[20:27:28] <alex_joni> fenn: lets submit a feature request for UTF encoding for C++ variables
[20:27:44] <alex_joni> SWPadnos: whoCaresAnyways :P
[20:27:55] <SWPadnos> SurelyNotUs
[20:27:55] <fenn> fine be a bunch of dicks
[20:28:25] <alex_joni> fenn: I think a comment would end this dispute..
[20:28:49] <SWPadnos> it would make more sense if the variables were named well, and not reused. but alex had a good point - consider thelix as "temp for helix calcs", not "time to complete the helix"
[20:29:02] <cradek> anyone can find stylistic things in source code they don't like
[20:29:20] <SWPadnos> or stylistic things they don't like in source code :)
[20:29:31] <cradek> yes, that too
[20:30:10] <SWPadnos> one problem here is that we've all been discussing thelix and taxial as times, when in fact they're used as temps
[20:30:45] <fenn> other variables starting with t are times
[20:31:15] <alex_joni> there you go
[20:31:19] <SWPadnos> yes - no doubt confusing - see how long we've been talking about it :)
[20:31:29] <cradek> the calculations are identical for acceleration. adding sqrts would make it times, true, but would obscure the fact that they work the same
[20:31:38] <alex_joni> SWPadnos: we talk about anything long enough
[20:32:24] <cradek> and even if you massage the units to be 'seconds' you have to ask 'time to do what?' - it's still just a parametric breakdown of the acceleration
[20:32:45] <alex_joni> let's drop it
[20:32:57] <fenn> time to complete the helix
[20:33:00] <alex_joni> * alex_joni brings out the chair
[20:33:02] <fenn> at ini_maxvel
[20:33:11] <fenn> is what i thought it meant
[20:33:33] <cradek> I think it wouldn't actually mean that
[20:33:53] <alex_joni> I wonder.. beeing a chairman (or person).. does that mean I can whack someone with a chair?
[20:33:57] <SWPadnos> no
[20:34:03] <alex_joni> SWPadnos: oh
[20:34:08] <SWPadnos> it means you have to be extra courteous to everyone else
[20:34:14] <alex_joni> with a chair?
[20:34:16] <SWPadnos> because you *are* EMC2 now
[20:34:31] <cradek> yay, glad it's no longer me, I suck at that
[20:34:54] <SWPadnos> yeah
[20:34:58] <alex_joni> haha
[20:34:59] <SWPadnos> err - I mean - lucky tou
[20:35:02] <SWPadnos> you
[20:35:25] <cradek> nice save (but you were right the first time)
[20:35:38] <SWPadnos> heh
[20:36:04] <alex_joni> funny :)
[20:36:59] <SWPadnos> so - on a separate note, the Intel ICH7 really sucks for individual PCI bus access times
[20:37:14] <SWPadnos> it's almost as bad as a parport
[20:37:22] <SWPadnos> at least it's 32 bits wide
[20:37:49] <alex_joni> I/O Controller?
[20:37:55] <SWPadnos> 5i22
[20:37:59] <alex_joni> ah
[20:38:20] <SWPadnos> reading 12 words (ADC channels) takes around 27000 cycles at 1.83 GHz
[20:38:34] <alex_joni> but I guess that's without DMA
[20:38:36] <SWPadnos> yeah
[20:38:46] <SWPadnos> not sure how to do DMA transfers yet
[20:38:48] <alex_joni> ah.. btw, wanted your oppinion on a scope
[20:38:55] <SWPadnos> ok
[20:40:18] <alex_joni> http://www.arc.ro/index.php?page=p21
[20:40:24] <alex_joni> can't find an english page
[20:40:35] <alex_joni> ah, now
[20:40:37] <alex_joni> http://www.trinstruments.com/products/measuring-instruments/oscilloscopes/portable-scopes/ox-7042-c.html
[20:40:45] <cradek> runs windows!?
[20:41:01] <SWPadnos> sadly, many do these days
[20:41:11] <SWPadnos> Agilent, Tektronix, LeCroy ...
[20:41:14] <cradek> amazing
[20:41:27] <alex_joni> cradek: yeah, don't like that part..
[20:41:42] <SWPadnos> 1 GS/s seems excessive for a 40 MHz input bandwidth
[20:42:25] <SWPadnos> it actually says "windows-like"
[20:42:42] <alex_joni> yeah, it looks close to windows, but not 100%
[20:42:52] <alex_joni> played with a similar one today
[20:42:53] <alex_joni> not portable
[20:44:28] <SWPadnos> that's a pretty low res screen for a scope - 320x240
[20:45:14] <alex_joni> SWPadnos:
http://www.google.com/url?sa=t&ct=res&cd=1&url=http%3A%2F%2Fwww.perel.fi%2Fpdf%2Fox6000.pdf&ei=vAsdR5SECZ7ynAPvp52-CQ&usg=AFQjCNHLWA6YElhkQqql9B5NaxFN8V0NKg&sig2=u9sDUtCgrH_1kdAXHXdzPA
[20:45:26] <alex_joni> that one is about 850 EUR + VAT
[20:46:38] <SWPadnos> well, without really studying the specs too well, I'd say those woulc be good for motor tuning and when you need "a little more" than a multimeter. I wouldn't really consider them for lab use (like diagnosing electronic designs or that kind of thing)
[20:46:47] <SWPadnos> would
[20:48:02] <SWPadnos> ok - back to work for me
[20:48:09] <fenn> cradek: the problem is that the acc value gets sent on to the motion controller later, and it is expecting real world value in mm/s^2
[20:48:16] <alex_joni> it is
[20:48:27] <cradek> fenn: look at the code!
[20:48:34] <fenn> oh, duh
[20:48:36] <alex_joni> the intermediary values aren't "right"
[20:48:56] <fenn> nevermind :)
[20:48:57] <alex_joni> but the result is
[20:49:01] <jepler> SWPadnos: that seems like startlingly bad performance -- is ICH7 worse than other chipsets in this respect?
[20:49:24] <SWPadnos> it really cusk, but I can't say for sure if it sucks a lot more than other chipsets
[20:49:31] <SWPadnos> s/cusk/sucks/
[20:50:20] <SWPadnos> I did try enabling burst reads on the 9054, but then I looked at the ICH7 manual, which says it does single read operations (and neglects to mention burst reads, so I assume it doesn't do them)
[21:11:22] <alex_joni> * alex_joni goes to bed :)
[21:12:57] <alex_joni> good night all
[21:15:36] <skunkworks_> night alex
[22:13:43] <SWPadnos> hmmm. riddle-me-this:
[22:14:14] <SWPadnos> I have a header file that I want to include in both a userspace hal component and a realtime component - much like sampler / streamer
[22:14:44] <SWPadnos> the two source files are in separate dirs (which I can change to fix the problem, but that's not the point)
[22:14:58] <SWPadnos> the header is currently in hal/user_comps/
[22:15:44] <SWPadnos> I have added the required lines to the Submakefile there (and the HEADERS list) so it gets copied to the ../include directory, and I have verified that the header is in the include dir
[22:16:13] <SWPadnos> gcc ccomplains that the header isn't found
[22:16:34] <fenn> can you see the actual command to gcc?
[22:16:52] <SWPadnos> so I make a symlink from the components dir to the header in the user_comps dir, and I have the same problem
[22:17:05] <SWPadnos> no - what is it, make V=1 or something to get full output?
[22:17:33] <SWPadnos> what I'm puzzled by is that the header is now apparently in 3 places (2 actual plus a symlink), and it still can't be found
[22:17:40] <SWPadnos> I'm pretty sure it's spelled correctly
[22:18:08] <fenn> what's the error message?
[22:19:03] <SWPadnos> blahblah/waveoutput.c:34:24: error: pulse_data.h: No such file or directory
[22:21:17] <SWPadnos> ok - I had made the symlink in the drivers dir instead of the components dir
[22:21:31] <SWPadnos> but it still bothers me that the header isn't found from the ../include dir