Back
[00:13:50] <cradek> two very pleasant surprises today
[00:13:53] <cradek> my probe works
[00:14:07] <cradek> all the fancy schmancy probing stuff I put in emc2 (while not having a probe) works
[00:16:08] <cradek> o7 if (X pass min to max to min) ... o7 endif
[00:16:21] <cradek> it's fascinating that this is accepted without an error
[00:16:46] <cradek> also o5 if (If step direction is down, step down. Else step up)
[00:59:20] <skunkworks> Nice!
[01:04:44] <cradek> wheee
[01:05:33] <cradek> if I probe along Y, it says my 4" gage block is 3.9999. In X, it's 3.9996
[01:06:17] <cradek> would have been fun to see some 4.0000 but it is quite good.
[01:16:02] <BJT_Shop> cool
[01:35:31] <BJT_Shop> yea! the computer with the 5i20 has been moved to the shop to hook up to the plasma cutter THC here we come!
[10:33:22] <micges_work> hello
[10:33:39] <micges_work> I have connected to my laser flowmeter
[10:34:47] <micges_work> It generates impulses on frequency based on current flow of water, how can I easly get current frequency of it in hal?
[10:46:26] <micges_work> I can't find any module for any frequency count or signal average on time counting
[10:46:53] <micges_work> (I suppose there isn't any such component)
[12:56:34] <jepler> isn't that what you'll get from the velocity output of encoder in 1-channel mode?
[12:57:05] <jepler> (every time I look at the screen, I see "laser flamethrower", not "laser flowmeter")
[12:57:16] <micges_work> hehe
[12:57:21] <SWPadnos> funny, I have the same problem
[13:06:30] <micges_work> jepler: it works, thanks
[13:08:16] <jepler> you're welcome
[13:11:47] <cradek> I don't know what a laser flamethrower is, but I want one
[13:40:48] <skunkworks_> copying a 1gb file on the raid takes 20 seconds.
[13:41:14] <skunkworks_> logger_dev: bookmark
[13:41:14] <skunkworks_> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-10-15.txt
[13:41:17] <SWPadnos> is that the total time until the drive lights go out?
[13:41:26] <skunkworks_> hmm - good question
[13:42:12] <SWPadnos> that sounds a bit slow actually, that's 50M/second, which relatively modern drives can couble (individually)
[13:42:17] <SWPadnos> double
[13:43:53] <skunkworks_> this is a really cheap esata card - the small pci-e card
[13:45:04] <skunkworks_> I copies it on the raid in 20 seconds and on the os hardrive (same drive as what is making up the raid) in about 26 seconds
[13:45:22] <SWPadnos> odd
[13:45:38] <SWPadnos> it's actually 100M/second aggregate, since it has to read and write
[13:45:49] <SWPadnos> so that's what I'd expect with the single drive
[13:46:02] <SWPadnos> (assuming that's the time until "lights out")
[13:46:15] <skunkworks_> yah - have not looked yet. :)
[13:48:14] <skunkworks_> like this
http://www.newegg.com/Product/Product.aspx?Item=N82E16815158088
[13:48:24] <skunkworks_> 'like'
[13:49:46] <skunkworks_> it has the Sil3726 chipset
[13:50:12] <SWPadnos> it's hard to know if it's just a junk design from the pictures :)
[13:50:36] <skunkworks_> came with this
http://www.newegg.com/Product/Product.aspx?Item=N82E16816132016
[13:50:39] <SWPadnos> is the OS hard drive connected to a motherboard SATA port?
[13:50:44] <skunkworks_> yes
[13:50:55] <SWPadnos> ok
[13:51:18] <SWPadnos> take one drive of the same type (if you have another), connect it to an esata port, and do the same test you did on the OS drive
[13:51:25] <SWPadnos> see if it takes >26 seconds
[13:51:52] <SWPadnos> oh, the newegg discount email has a 10% (up to $10) off code on hard drives
[13:51:57] <SWPadnos> so 2.5TB drives are $100
[13:52:00] <SWPadnos> err, 1.5
[13:52:04] <skunkworks_> wow
[13:52:11] <skunkworks_> lights out in 20 seconds.
[13:53:11] <SWPadnos> remember that the second time you copy the file, it's probably in cache, so it doesn't need to be read from disk again
[13:54:01] <skunkworks_> this is very un-scientific I am sure.
[13:54:07] <SWPadnos> heh
[13:54:43] <SWPadnos> so that enclosure is a power supply and two esata port replicators?
[13:54:50] <skunkworks_> I have a 1gb file on the desktop and on the raid drive. I right click copy - then past in the same directory - or desktop depending on the test.
[13:55:22] <SWPadnos> oh. try time cp file1 file2 && sync
[13:56:20] <SWPadnos> or, to test write speed, time dd bs=1M count=1024 /dev/null file2 && sync
[13:56:29] <SWPadnos> err
[13:56:33] <SWPadnos> or, to test write speed, time dd bs=1M count=1024 /dev/null > file2 && sync
[13:57:12] <SWPadnos> and to test read speed, time dd file2 /dev/null
[13:57:12] <skunkworks_> SWPadnos: so that enclosure is a power supply and two esata port replicators? YEs
[13:57:34] <SWPadnos> hmmm. maybe you don't redirect dd, just dd dev1 dev2
[13:57:37] <SWPadnos> ok
[13:58:15] <skunkworks_> I don't think you could ever boot off of the raid... It only sees the first drive in each port at boot.
[13:58:34] <SWPadnos> yeah, you need a true multiport card to do that
[13:58:49] <SWPadnos> like the areca or 3ware cards, but then you also need 8 cables ...
[14:00:11] <cradek> hm, I think motion saves the probed position before it uses forward kins to generate the current position. I think this means you always get a position one servo cycle old when probing.
[14:01:33] <cradek> (wish we had sub-servocycle encoder snapshot on mesa, and the necessary supporting code in emc)
[14:02:08] <SWPadnos> it would be great to have a secondary index/latch input on the canonical encoder
[14:02:39] <skunkworks_> wouldn't speeding up the servo cycle have the same effect. (similar)
[14:02:40] <cradek> to get full accuracy on my machine I need to probe at 2ipm (well, 1ipm if this bug is what I think it is)
[14:02:41] <SWPadnos> and a corresponding "latched output"
[14:03:01] <cradek> skunkworks_: yes but I can't speed it up much - too much ladder going on
[14:03:07] <skunkworks_> ah
[14:03:25] <skunkworks_> put ladder in a slower thread?
[14:03:51] <cradek> can't do that either, because it wouldn't keep up with the tool changer
[14:04:00] <skunkworks_> hmm
[14:04:44] <cradek> it spins the parts using a big 3 phase AC motor, and you have to brake it (apply some DC) at just the right time
[14:06:14] <skunkworks_> I guess I was thinking keep the ladder in the origonal servo period but speed up the rest. (sorry - probably being dense)
[14:06:34] <cradek> oh I see what you mean now
[14:07:06] <cradek> I bet you are right - I might be able to get a 2x or even 3x improvement (but I'd like 20-30x)
[14:07:24] <cradek> all my whining aside, probing is really slick
[14:08:33] <skunkworks_> :)
[14:08:49] <jepler> hdparm has a mode that tests unbuffered sequential read speed
[14:08:59] <skunkworks_> video?
[14:09:25] <jepler> sudo hdparm -t -T /dev/sda
[14:11:53] <SWPadnos> does that work on RAIDs?
[14:13:27] <jepler> no, it works on individual discs
[14:13:51] <SWPadnos> that's kinda what I thought
[14:14:07] <SWPadnos> I'm nor sure it's a good idea to use that on a drive that's part of a RAID
[14:14:09] <SWPadnos> not
[14:14:39] <jepler> it's only a read test, not a read/write test
[14:14:48] <skunkworks_> seemed to work...
[14:15:34] <pcw_home> cradek: the latest HostMot2 encoder counter source has a probe input (shares the index latch)
[14:15:40] <SWPadnos> ah
[14:15:59] <SWPadnos> you'd think that "unbuffered sequential read test" would have clued me in to that
[14:16:15] <pcw_home> bbl
[14:16:16] <skunkworks_> http://pastebin.ca/1622121
[14:16:39] <skunkworks_> sort of what I expected - write was a little slower - read a little faster.
[14:17:33] <skunkworks_> heh - forget what I just said
[14:18:57] <skunkworks_> * reads where faster on the raid which is what I would expect.
[14:19:04] <cradek> pcw_home: hmmm!
[14:19:16] <SWPadnos> yeah, strangely only by 50% or less
[14:19:32] <skunkworks_> like I say - crappy hardware. (but really cheap)
[14:19:38] <SWPadnos> skunkworks_, turn off the RAID, and do the read test on one of the drives in the RAID
[14:19:51] <SWPadnos> see if it's comparable to the motherboard-connected one
[14:20:18] <skunkworks_> the quality of the case is nice though.
[14:20:23] <SWPadnos> heh
[14:20:45] <SWPadnos> LaCie has a NAS with 5x 1TB drives on clearance for $549
[14:20:59] <SWPadnos> that sounds like a good deal to me, though I think it is refurbished
[14:22:06] <skunkworks_> did you guys see this
http://blog.backblaze.com/2009/09/01/petabytes-on-a-budget-how-to-build-cheap-cloud-storage/
[14:22:17] <SWPadnos> yeah, pretty cool stuff
[14:37:29] <skunkworks_> our server with a real raid card
[14:37:31] <skunkworks_> http://pastebin.ca/1622155
[14:38:51] <cradek> does ppmc use a latched copy of the count or internal reset for homing?
[14:39:30] <SWPadnos> I think it actually resets the count, but I'm not sure
[14:40:24] <cradek> hmm
[14:40:44] <cradek> if we do anything for probing, it can't work on ppmc then
[14:41:39] <SWPadnos> not if you use the index input for probing
[14:43:18] <cradek> with hm2 it seems like you could just have another RW handshake like index-enable
[14:44:02] <jepler> if you add axis.0.motor-pos-probed then interfaces that can do better can use it; those that can't just hook it to the same thing as motor-pos-fb
[14:44:07] <cradek> maybe then more pins encoder.0.count-latched and encoder.0.position-latched
[14:44:15] <SWPadnos> with either of them, you could run a faster thread that just reads the counters and latches the values when it sees the probe input
[14:44:26] <jepler> I don't know if there's a handshake needed, or just always latch on rising edge of probe signal
[14:44:38] <cradek> currently you can probe on either edge
[14:44:44] <jepler> hm
[14:44:55] <cradek> i.e. probe toward or away from the work
[14:45:02] <jepler> right
[14:45:25] <cradek> I guess the firmware would have to know which edge to latch? not sure.
[14:46:01] <SWPadnos> the latch still has to go to the motion controller, since that's what decides whether there's an error or not
[14:46:10] <SWPadnos> (ie, end of move, no probe input)
[14:46:41] <cradek> well it could watch the raw probe input too - I think that's what jeff is suggesting
[14:47:35] <cradek> once you find that the raw probe input has fired (whatever edge you are seeking) you could just read the motor-pos-probed
[14:48:02] <cradek> if the firware latches on both edges would that just work? or is it asking for trouble to assume so much?
[14:48:12] <jepler> the probe signal will have to be hooked into whatever physical input(s) hostmot2 uses for encoder latch
[14:48:22] <cradek> sure
[14:48:48] <cradek> but you could also read that yourself as gpio and send it to motion.probe-input
[14:49:35] <jepler> if you're probing in a way that just grazes the surface, it's possible to imagine getting a rising edge and then a falling edge all in 1 cycle
[14:49:43] <jepler> in that case, "both edges all the time" is no good
[14:50:12] <cradek> but then the gpio won't detect the rising edge you're waiting for, and you'll just ignore it
[14:50:37] <jepler> true
[14:50:41] <SWPadnos> that was the scenario I was thinking of when I mentioned latching the probe input
[14:51:06] <cradek> however much bouncing you get, you'll either read the edge you want (in which case the LAST latched value is what you want anyway) or not the edge you want (in which case you never know the difference and don't care about the latched value)
[14:51:08] <SWPadnos> if the counter is only latched (not reset), then it seems that latching on either edge is OK
[14:52:11] <jepler> I don't see how it could possibly work if the counter resets
[14:52:36] <cradek> yeah I'm pretty sure it can't
[14:52:44] <cradek> Bit13LatchOnProbe 1 = Latch count on probe (Version 3 counters only)
[14:52:44] <cradek> Bit12ProbePolarity 1 = active high (Version 3 counters only)
[14:53:00] <cradek> unfortunately I think hm2 doesn't do "latch on either edge"
[14:53:19] <jepler> 'latchonprobe' is commented out in the current firmware source qcountersf.vhd
[14:55:29] <jepler> since it requires a polarity I guess we'd have to give motion a 'probe polarity' output as well
[14:55:34] <jepler> which will also have to be hooked through to the mesa
[14:57:46] <cradek> the advantage of a handshake like index-enable is you'd be able to get the value when you get your first reading from the bouncy probe instead of the last
[14:58:04] <cradek> I said above that you want the last one - that may be wrong
[14:58:58] <jepler> you can get your choice of first or last depending on the JustOnce setting
[14:59:15] <cradek> but if we use a handshake like that, we can't notice the probe has accidentally fired while homing (for instance) and stop (like we do now)
[15:53:10] <pcw_home> Yes the current probe latch is the same as the index latch for cheapness
[15:53:12] <pcw_home> so homing has to be separate from probing, currently theres no way
[15:53:13] <pcw_home> to tell a probe event from a index event but I guess that could be added
[15:54:04] <cradek> the driver knows which one you want - I don't think it matters
[15:55:16] <pcw_home> Sure and the hardware should only have one enabled at a time
[15:55:17] <pcw_home> but if you were looking to avoid a probe crash while homing
[15:55:19] <pcw_home> the hardware will be no help
[15:55:40] <cradek> oh I see what you mean
[15:55:54] <jepler> a sensible setup for emc might be to have all encoders share the same latch input -- and you don't give up anything because you'll use the same physical input pin to also go to emc's probe input
[15:56:18] <jepler> (for most people that'd be sensible, anyway)
[15:56:47] <pcw_home> Yes that how it work currently theres a single probe input pin
[15:56:49] <cradek> oh I didn't think about that - you'd need to wire all the latch inputs together
[15:57:00] <cradek> ok
[15:58:59] <jepler> oh, wait, now I understand what pcw_home was saying about a single latch
[15:59:07] <jepler> ick
[15:59:39] <jepler> but as long as the probe input is at least a servo period wide, you'll still be able to diagnose "probe tripped during homing", won't you?
[16:00:00] <pcw_home> Its not a single latch, theres one per encoder (its the index latch)
[16:00:14] <cradek> yes if we use the scheme of hooking the probe gpio to motion
[16:01:03] <cradek> if we use the RW handshake (which I think is needed to catch a very short probe signal) we wouldn't have that
[16:02:23] <cradek> I feel like hacking the VHDL to latch on either edge and adding a motor-pos-probed pin and then making minor changes to motion would give us a fairly easy solution that would still be compatible with other drivers (but maybe not the best solution)
[16:03:39] <pcw_home> If I had a place for the bit I could have a probe status FF but I waqs trying to keep it compatible
[16:03:41] <pcw_home> with the existing driver
[16:04:01] <cradek> the best solution is probably a rewrite of probing to use a RW handshake, but then you bust all the drivers, and doing it on a simple parport etc is a swirl
[16:05:01] <pcw_home> RW handshake like index?
[16:05:09] <cradek> yes exactly like that
[16:05:36] <cradek> emc requests a probe latch, driver tells emc when it's done
[16:06:18] <pcw_home> Currently its exactly like index (because its just another index input with separate mask/enable)
[16:07:06] <cradek> sounds like your firmware is ready (except we don't have the latest), all we have to do is figure out how the heck to make emc and the hal driver work
[16:09:22] <pcw_home> If you want both edges I could replace the mask and polarity bits with enable rising-edge and enable falling-edge
[16:10:51] <pcw_home> (bits)
[16:12:00] <cradek> that would let me hack it into working pretty quick, I think, but I wonder instead of doing that if we should have a coherent design first
[16:12:22] <cradek> that's the problem with giving people like me the source...
[16:12:54] <jepler> cradek: that assumes you have a machine with enough hard drive space to install the xilinx software and enough RAM to run it
[16:13:54] <cradek> jepler: pcw_home is always good enough to build for us...
[16:14:13] <cradek> or does seb usually do it?
[16:14:23] <cradek> too bad he (and jmk) are not here
[16:14:26] <jepler> I'm pretty sure it's pcw
[16:15:22] <cradek> on one hand we have "hack it into working with mesa" and on the other "add probing to the canonical encoder in a smart and flexible way"
[16:15:30] <cradek> my inclination is #1 and jmk's would be #2
[16:16:18] <jepler> not only encoder, but stepgen
[16:16:32] <cradek> ooooh
[16:16:35] <jepler> with software stepgen you could get one-step probe accuracy
[16:16:45] <jepler> it still revolves around latching a position on some signal's edge
[16:17:15] <cradek> what about hm2 stepgen?
[16:17:19] <jepler> ooh pretty
http://antwrp.gsfc.nasa.gov/apod/ap091015.html
[16:17:46] <cradek> wow
[16:18:03] <cradek> how in hell did someone photograph that? it lasted 2 seconds I bet.
[16:18:29] <jepler> cradek: I don't see any position latches in the hm2 regmap for stepgen..
[16:21:08] <pcw_home> I guess it would be pretty cheap for the stepgen since you really only need to latch the top
[16:21:09] <pcw_home> 16 bits of the position register (integer part of a step)
[16:22:20] <cradek> if bits are scarce seems like you could give the difference from the currently reported count
[16:22:42] <cradek> [warning: half-baked]
[16:26:31] <pcw_home> I just dont want to add a feature that makes any of the existing configurations not fit
[16:26:32] <pcw_home> (though they could be yet more compile time options...)
[16:26:57] <jepler> we should first find a design that works with (nearly) unmodified hm2 encoder + software stepgen
[16:27:22] <jepler> that should be a sign that it's a sensible design
[16:27:44] <cradek> pcw_home: would changing the latchonprobe/probepol to latchonrising/latchonfalling break any other hm2 users?
[16:28:07] <pcw_home> No
[16:28:22] <jepler> with a "probe polarity" output from motion it seems like we could properly program the two bits to give the edge we want
[16:28:31] <jepler> "both edges" sounds like a hack around not having such an output in the motion controller today
[16:28:33] <pcw_home> (since theres no driver support yet)
[16:28:55] <cradek> jepler: well, I bet you are right
[16:29:27] <cradek> pcw_home: do you have non-emc2 customers using hm2 or is it pretty much just us?
[16:30:57] <pcw_home> We do, Even the USB version
[16:30:57] <cradek> // trigger when the probe clears, instead of the usual case of triggering when it trips
[16:31:01] <cradek> char probe_whenclears = !!(probe_type & 2);
[16:31:10] <cradek> it would be trivial to export this on a hal pin
[16:41:06] <cradek> pcw_home: what would it take to get us the updated firmwares with these existing probe functions?
[16:52:59] <pcw_home> I can bulld one later today if I get a chance, just tell me the base config, cardtype
[16:53:01] <pcw_home> and where you want the probe input pin (that doesn't sound right)
[16:54:26] <cradek> I am currently using loadrt hm2_pci config="firmware=hm2/5i20/SVST8_4.BIT num_encoders=1 num_pwmgens=0 num_stepgens=0 enable_raw,firmware=hm2/5i20/SVST8_4.BIT num_encoders=4 num_pwmgens=4 num_stepgens=0 enable_raw"
[16:55:54] <cradek> I'm not sure where the probe input pin should be. it's currently net ProbeTouch hm2_5i20.1.gpio.071.in_not => motion.probe-input
[16:56:40] <pcw_home> OK I'll make a probe enabled SVST8_4
[16:56:41] <pcw_home> and add it to I/O 71
[16:56:56] <cradek> is that the highest pin on one of the connectors?
[16:57:15] <cradek> if so, that's maybe a noncrazy place for it
[16:59:58] <cradek> yes, it is the highest gpio
[17:00:06] <cradek> I think that's a good place
[17:01:32] <cradek> thank you! I'll try it out and hack on seb's beautiful driver and jmk's beautiful motion controller...
[17:13:45] <pcw_home> I know what you mean. I'm glad no one looks too close at my VHDL...
[17:13:54] <pcw_home> bbl
[18:29:06] <cradek> http://www.linuxcnc.org/component/option,com_kunena/Itemid,20/func,view/catid,20/id,976/lang,en/#980
[18:29:11] <cradek> ^ this works fine for me
[18:42:33] <SWPadnos> he hasn't mentioned the version he's using
[18:43:57] <cradek> I ignored the thread until today (thinking it was obviously-bad gcode) since it showed up in my email with everything in [brackets] stripped out
[18:44:11] <cradek> o1 if (the number is small enough now) ... o1 endif
[18:44:40] <cradek> grrr web bbs grrr
[18:44:59] <SWPadnos> heh
[18:47:15] <cradek> <br /><br />o2 while (Y loop steps down)<br /><br />g0 y#29
[18:47:30] <cradek> and rss2email is vindicated because it's also wrong in the rss
[18:48:07] <SWPadnos> I wonder what happens if people use [code] ... [/code] in their posts
[18:48:39] <cradek> <pre> they should use ASCII for god's sake </pre>
[18:49:21] <SWPadnos> not on a web<b>BBS</b>
[18:52:07] <micges> cradek: gocde from his first post hangs up axis indeed
[18:53:01] <cradek> hm, I only tried the second
[18:53:17] <cradek> I notice he doesn't set initial conditions before using while
[18:53:31] <SWPadnos> it looks like he did
[18:53:36] <cradek> so I'm sure I could set variables in a way that would make the program never finish, if I bothered
[18:53:49] <SWPadnos> err
[18:54:13] <cradek> I'm wrong
[18:54:15] <SWPadnos> the second program initializes all of the vars used in the while loop
[18:54:16] <cradek> (about the second one)
[18:56:09] <cradek> #29 = [#29 + #23] (Decrement Y)
[18:57:15] <cradek> I notice this is an increment, which makes the test o2 while [#29 GT #22] (Y loop steps down) never fail
[18:57:33] <cradek> I think he means to use #28 somehow
[18:58:45] <cradek> I prefer o1 repeat [n] g91 g1 right, g1 up, g1 left, g1 up, o1 endrepeat
[18:58:57] <cradek> these loops are just awful to get right
[19:00:48] <SWPadnos> err
[19:01:03] <SWPadnos> the text I see on the forum is "#29 = [#29 - #23] (Decrement Y)"
[19:01:07] <SWPadnos> not plus
[19:01:26] <SWPadnos> in the second example anyway
[19:01:38] <cradek> the second example runs fine
[19:01:47] <cradek> I haven't tried the first example
[19:01:53] <SWPadnos> ok
[19:02:01] <cradek> but micges says it loads forever, which I can believe, since it appears to be wrong
[19:02:07] <SWPadnos> I'm sure there are errors in the first one (it's too long to look at :) )
[19:02:29] <cradek> however, the mystery is that the poster reports the second one also doesn't load
[19:02:29] <SWPadnos> since he says he has problems with the second one also, I wonder what version he's running
[19:02:34] <SWPadnos> right
[19:02:49] <SWPadnos> (not that I remember any specific fixes to while loops lately)
[19:03:08] <skunkworks_> I bet he didn't save it before reloading it into axis.
[19:04:07] <cradek> it's so easy to write gcode that goes forever. I wish there was a decent way for AXIS to know when to give up
[19:07:15] <skunkworks_> yay - samba running. (the final problem was avg's firewall on xp)
[19:07:58] <cradek> I know TLA stands for three letter acronym, but there's no equivalent for two letters
[19:08:31] <cradek> PL for pair of letters?
[19:08:48] <cradek> "the TLA on my PL made samba fail"
[19:09:01] <skunkworks_> heh
[19:09:21] <skunkworks_> I don't know if avg is an acronym.. Never thought of it.
[19:09:31] <skunkworks_> must be
[19:09:39] <cradek> anti virus grogram
[19:09:44] <skunkworks_> active virus guard maybe.. someone should google it.
[19:10:10] <cradek> my high school friend insisted that the letters on his (volkswagen) gas gauge stood for Full and Rempty
[19:10:20] <skunkworks_> heh
[19:10:30] <cradek> (I have no idea what the R meant)
[19:11:46] <SWPadnos> "Running on fumes"
[19:12:00] <SWPadnos> "refuel now"
[19:12:03] <cradek> http://content.mamotorworks.com/img300/fr4564.jpg maybe this was it??
[19:12:18] <cradek> pretty sure his had an F though
[19:12:18] <skunkworks_> The 1955 VW did not have a gas guage (fuel gage). Instead, when it ran out of gas and started to sputter, the driver reached below the dashboard, turned a lever there to the 'RESERVE' position and the car would run to the next gas station on 'reserve.'
[19:12:28] <SWPadnos> http://wiki.answers.com/Q/What_do_the_r_mean_on_a_vw_bug_fuel_gauge
[19:13:01] <cradek> ha
[19:13:07] <cradek> so we should have looked on the internet
[19:13:18] <SWPadnos> yeah, way back when in the '70s
[19:13:34] <skunkworks_> internet was around when you were in highschool...
[19:13:36] <cradek> skunkworks_: motorcycles still have that clever scheme...
[19:14:00] <skunkworks_> cradek: the quote I coppied from mentioned that also :)
[19:14:07] <SWPadnos> some jaguars had dual tanks as well
[19:14:18] <SWPadnos> with a dashboard switch to select them
[19:14:35] <SWPadnos> like the 1976 XJ6-L, for example
[19:14:35] <cradek> my modernish VW says 0, 1/2, 1/1
[19:14:41] <cradek> I think they just like being contrary
[19:14:45] <SWPadnos> heh
[19:15:03] <SWPadnos> I recently rented a Toyota, and the rental form had eighths of a tank marked off
[19:15:14] <SWPadnos> 1/8, 2/8, 3/8, 4/8, 5/8, 6/8, 7/8 :)
[19:15:35] <SWPadnos> I had to return it 6/8 full
[19:21:54] <skunkworks_> should have gotten points for reducing the fraction..
[19:22:55] <SWPadnos> I agree
[19:23:08] <SWPadnos> but it was probably the best travel deal ever
[19:23:17] <SWPadnos> I rented the car for one day (for $45 or something)
[19:23:57] <SWPadnos> they picked me up at my hotel to get the car, they picked up the car at the other hotel I drove to (about 30 miles away), they brought my sister to the airport a couple of days later when they finally picked up the car
[19:24:19] <SWPadnos> saved me three $70 cab fares, and let me get around to various stores as I needed
[20:29:11] <cradek> http://timeguy.com/cradek-files/emc/0001-Fix-probe-results-being-stale-by-a-servo-cycle.patch
[20:29:43] <cradek> I came this close -><- to breaking backlash compensation and I would have never noticed
[20:29:55] <cradek> so I wonder if one of you good folks would review this for me
[20:36:45] <micges> looks fine to me
[20:36:56] <alex_joni> same here
[20:37:10] <micges> cradek: why would you break backlash ?
[20:37:40] <cradek> because the first thing I did was move do_forward_kins above process_inputs, which is completely wrong
[20:38:20] <micges> ah I see
[20:38:53] <cradek> it has to read some inputs (joints) and then do kins on them, and then read other inputs (probe)
[20:39:02] <cradek> ... I think
[20:40:39] <cradek> thanks guys
[20:40:56] <CIA-82> EMC: 03cradek 07master * rbf4fb9c24b1b 10/src/emc/motion/control.c: Fix probe results being stale by a servo cycle
[20:49:28] <micges> cradek: speaking of motion, when you rewrite tp, did you rewrite it from scrach based on existing code or you writed from scratch only badly working code?
[20:49:46] <cradek> to do sub-servo-cycle latching right, I'd have to get a faster opto22 input module (or eliminate it)
[20:50:43] <cradek> micges: I don't understand what you are asking
[20:51:26] <micges> err, how much did you rewrite tp ?
[20:51:28] <cradek> micges: I wrote the simplest possible TP that would plug in to the existing interfaces and got that working, then added stuff like blending in a new way
[20:52:05] <cradek> micges: it has very little resemblence to EMC1 by now
[20:52:09] <cradek> (for better or worse)
[20:53:25] <alex_joni> jepler: s/translating/rotating/
[20:53:59] <micges> cradek: ok tnaks
[20:54:04] <micges> thanks
[20:54:35] <cradek> why?
[20:58:02] <micges> I was digging on TP due to jointsaxes3 work, and trying adding some analog synched output, and trying to figure place to added s-curve acc/deacc
[20:59:28] <micges> and I think few places can be better done (like many nested ifs on main tp function) but don't have time to actually implement this
[20:59:36] <cradek> if you don't want to do anything smarter than current (only considering adjacent moves when calculating blends or max speeds) you can just replace tcRunCycle
[20:59:59] <cradek> if you want to be smarter than that you will probably need to rewrite everything
[21:01:01] <micges> I thought so
[21:05:03] <jepler> alex_joni: argh, I didn't write carefully enough
[21:05:08] <jepler> care to correct me on the mailing list too?
[21:05:34] <alex_joni> nah, I bet it's fine ;)
[21:05:41] <alex_joni> but if you insist I will
[21:09:08] <jepler> it sounds like I missed the entire point of my message
[22:26:02] <PCW> cradek:
[22:26:04] <PCW> SVST8_3P.BIT and SVST8_3P.PIN :
http://filebin.ca/jkavy (3 because I had to delete one stepgen to make the probe stuff fit)
[22:26:06] <PCW> SOURCE including the 5I20 bitfiles that jepler wanted rebuilt:I/O standard was not specified) :
http://filebin.ca/zedfac
[23:04:45] <PCW> Also looks like you do have the ability to detect a probe event when homing (if JustOnce , LatchOnProbe and LatchOnIndex) are all set
[23:04:47] <PCW> probe events and index events will both clear their own status bits (but if they happen in the same servo period there's no way to know what the latched count represents)
[23:33:22] <BJT_Shop> on my 57 VW R meant Reservierung
[23:33:37] <SWPadnos> "reserved"
[23:33:40] <SWPadnos> or "reserve"
[23:33:41] <BJT_Shop> yep
[23:33:57] <BJT_Shop> ops not my 57 my 60
[23:34:05] <SWPadnos> details
[23:34:07] <BJT_Shop> 57 had no gauge
[23:38:56] <PCW> "gauge" by the sound of the engine...
