Back
[01:18:52] <cradek> jepler: what happens in mm mode?
[01:47:07] <jepler> cradek: ultimately the number should be interpreted as mm or inch according to the G20/G21 setting
[01:47:12] <jepler> presently it's always interpreted as machine units
[01:48:02] <cradek> another possibility is to honor the display units
[01:48:35] <cradek> but, I guess you can't know how to change the spacing
[01:49:24] <jepler> if the spacing comes from the .ngc file then it has to be G20/G21 that set the units
[01:49:41] <cradek> that's true
[01:49:48] <jepler> if it's set in the GUI then it should probably be user units
[01:50:25] <jepler> I mean, display units
[01:50:26] <cradek> I'm hesitant about it being set in the ngc, since it's undiscoverable
[01:51:22] <cradek> there are already lots of view items you can turn on and off (and the preference is saved) but this one requires a number so it's a bit different
[01:53:10] <fenn> it's very counter-intuitive to set it via g-code
[01:53:27] <fenn> view->grid would make more sense
[01:53:37] <cradek> but the scale.
[01:53:45] <fenn> dynamic scaling!
[01:53:56] <fenn> dont make grid squares smaller than 5 pixels
[01:54:01] <cradek> beware, jeff will kick you in the shins for that
[01:54:09] <fenn> well, that's his problem i guess
[01:54:16] <jepler> it's your shins
[01:54:22] <cradek> haha
[01:54:26] <cradek> told you so
[01:54:52] <cradek> once it scales a few times, I don't know how you'd know the numbers anymore
[01:55:01] <cradek> (qcad does that, and it's very disorienting)
[01:55:29] <cradek> actually I know how, but ... my shins
[01:55:31] <jepler> I think every drawing I've done in qcad is at a different scale, for that very reason
[01:55:45] <fenn> usually there is some kind of cursor-coordinates in the corner of the display
[01:55:57] <cradek> jepler: yeah, it's no good, although to a programmer it seems like a good idea I suppose
[01:55:58] <fenn> but that's something different altogether
[01:57:50] <fenn> a 'ruler' with numbers along the brightest visible grid line would be neat
[01:57:56] <cradek> you could draw the value along each grid line, at the bottom? and right? edge of the screen
[01:57:56] <cradek> you risk some clutter but if you want the values you'd have them
[01:58:21] <cradek> brightest?
[01:58:32] <fenn> well, like in qcad, the 10's lines are brighter
[01:58:56] <cradek> but waaah, I want 16ths
[01:59:17] <cradek> you can't impose the scale
[01:59:38] <fenn> waaah i want log scaling
[01:59:45] <cradek> waaah!
[02:00:10] <fenn> what's 16 squared? i dont even know
[02:00:18] <cradek> 256
[02:00:26] <cradek> 32
[02:00:29] <cradek> 17
[02:00:31] <cradek> who cares?
[02:01:25] <cradek> heck, it is 256, I was being stupid
[02:01:29] <SWPadnos> heh -duh
[02:01:38] <SWPadnos> and 256 squared is 65536
[02:01:45] <SWPadnos> and 65536 squared is 4294967296
[02:01:50] <fenn> calm down boy
[02:01:59] <SWPadnos> doesn't everyone know all the powers of 2 from 0 to 32?
[02:02:03] <fenn> i was just pointing out that 16ths gridlines dont scale very well
[02:02:07] <SWPadnos> ewww
[02:02:14] <SWPadnos> most people don't work in hexadecimal
[02:02:27] <SWPadnos> I, however, am not most people
[02:02:28] <fenn> hey that'd be neat, a hexadecimal ruler
[02:02:41] <fenn> give them to all your machinist-programmer friends
[02:02:43] <SWPadnos> most rulers have 16th's though, if they're good enough
[02:02:52] <SWPadnos> really good ones go to 64th's
[02:04:42] <cradek> really good ones go to 10 or 100
[02:04:52] <cradek> nothing worse than only having a 64ths ruler when working in the cnc realm
[02:05:12] <fenn> really good ones have this little clock thingy on them
[02:05:16] <cradek> I bought a nice scale with 32/64 on one side and 10/100 on the other
[02:05:18] <SWPadnos> I agree
[02:05:42] <cradek> $12 ? and very much worth it
[02:18:12] <Guest708> one of my best buy is a $10 6 inch digital caliper.
[02:18:20] <Guest708> Guest708 is now known as skunkworks
[02:19:58] <cradek> I've still never bought a digital indicator/caliper, I can see how it would be nice to zero, but it's not worth batteries etc
[02:21:28] <cradek> when I worked with engineers we had decimal-foot tape measures
[02:21:58] <cradek> I haven't seen them lately, maybe they were a fad
[02:22:40] <cradek> we did a lot of cad in feet, and decimal feet was more natural I guess
[02:26:27] <skunkworks> I think the one that I have - I bought 2 years ago and still have not put new batteries in it.,
[02:27:53] <skunkworks> it turns off. the second you move it - it turns back on.
[02:27:58] <skunkworks> pretty cool.
[02:28:01] <cradek> neat
[02:28:40] <skunkworks> never checked to see how acurite it is.. but if it is that important I pull out the dial micrometers.
[02:30:50] <cradek> a pair of 123 blocks is a nice quick check
[02:31:13] <cradek> some are surprisingly off mid-scale, then match back up later
[02:31:25] <cradek> or maybe it's cyclic
[02:31:58] <skunkworks> right.
[02:36:26] <cradek> I think it's a case of the man with more than one watch never knowing what time it is
[02:36:54] <cradek> your parts will fit together if you measure them with the same (chinese) stick
[02:39:39] <skunkworks> yes - although everything seems to measure what you would think. pick up shaft and it measures 1" and so on.
[13:20:25] <alex_jon1> alex_jon1 is now known as alex_joni
[14:59:22] <jepler> using the official ubuntu gutsy "-rt" kernel and a modified version of 'sim':
http://emergent.unpy.net/index.cgi-files/sandbox/ubuntu-gutsy-rt.png
[15:00:00] <jepler> max jitter has been slowly creeping upwards (at 31000 now)
[15:00:13] <SWPadnos> hmmm. I'd like to see a scope trace of a parport output
[15:00:31] <SWPadnos> I'm always suspicious of software (or hardware) that tests itself
[15:00:39] <jepler> indeed
[15:02:14] <SWPadnos> I wonder if that would be a sawtooth from some clock skew thing
[15:02:42] <SWPadnos> ie, max lat grown more or less linearly until the next time some timing edges meet, where it goes back down to near 0
[15:04:34] <SWPadnos> I made a half-hearted attempt to add a reset button to the dialog, but I was too tired to be able to read XML-like data formats
[15:08:10] <jepler> hah
[15:09:17] <jepler> this looks promising for servo-thread-only systems
[15:09:22] <jepler> but those are such a minority
[15:09:27] <SWPadnos> yeah - it does
[15:09:47] <SWPadnos> I wonder how "hard" that realtime is though
[15:10:20] <jepler> I doubt it was easy to get performance even this good, so in that sense I'd call it "hard"
[15:10:28] <SWPadnos> one of the interesting things I saw was that even with the computer crashed (hard enough that it wouldn't respond to pings or change numlock/capslock LEDs), the RT code still executed
[15:10:37] <jepler> depends on the kind of crash you get, I suppose
[15:10:53] <SWPadnos> this seemed to be a hard kernel crash
[15:11:06] <SWPadnos> but I could see the outputs on the scope still being updated
[15:11:09] <SWPadnos> and much less jitter too :)
[15:12:34] <SWPadnos> I think the overall jitter went down to 1.2 us - I could easily see the 30 ns PCI clock in the output (several evenly spaced transition points)
[15:15:07] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/0001-userspace-realtime-on-my-test-system-with-gutsy-k.patch
[15:16:27] <jepler> of course hal_parport doesn't build ..
[15:16:29] <cradek> wow that's very interesting
[15:16:59] <jepler> or, isn't built
[15:19:22] <SWPadnos> there would need to be some changes to sim_rtapi
[15:19:49] <SWPadnos> to use iopl and that kind of thing (if that's even doable - I don't know that all drivers correctly ask for IO regions)
[15:33:36] <cradek> cool, emc and r2 look like they agree on how arcs in G91 mode work, so I think I can carefully write a dialect with REALIZE that works on both
[15:34:13] <cradek> fwiw the manual does say that more than one number after the decimal for F, or more than four for XYZ, "will cause an error"
[15:34:54] <cradek> (they don't say whether it's an error on the display or an error in your part)
[15:35:15] <SWPadnos> heh
[15:35:36] <cradek> and trailing zeroes can be left off, except for G4, which requires two of them
[15:38:27] <rayh> May I ask a probably dumb question. What's r2?
[15:38:46] <cradek> not dumb. my bridgeport r2e3
[15:39:15] <cradek> I keep running into controller bugs/features
[15:39:17] <rayh> Ah. Okay. And the gcode is their style.
[15:39:39] <cradek> yeah it's pretty bad
[15:39:42] <rayh> Do you have their cam generator as well.
[15:40:03] <cradek> nope
[15:40:16] <cradek> I didn't get any software, but I've figured out how to upload gcode to it
[15:40:19] <rayh> Matt was talking like he has one laying around.
[15:41:21] <cradek> is that just some dos software?
[15:41:32] <cradek> or was it an entire special computer
[15:45:04] <rayh> I don't know much about it.
[15:45:31] <rayh> But I thought it was software that loaded on a computer. Must have been dos.
[15:45:53] <cradek> thanks, I might ask him about it, but I will be running emc on it one of these days.
[15:47:19] <rayh> That's the right way if it's a cripple.
[15:48:13] <cradek> I've fixed the myriad problems with the original hardware - it actually works fine now (as well as it ever did)
[15:48:40] <cradek> but, I'd like to do tapping, tool length probing, maybe eventually some 5 axis, etc - emc is the way to do all that
[15:49:39] <cradek> besides I can run programs longer than "100 feet" then too
[15:49:47] <cradek> (12000 bytes)
[15:50:23] <SWPadnos> just leave off all those extra zeroes and you can get more lines in the 12k
[15:50:52] <SWPadnos> and never specify a movement mode (G1, G2...) more than necessary
[15:51:06] <SWPadnos> (or do an emc rertofit :) )
[15:51:25] <cradek> rayh: recently I found that if you specify F2. you get 2, F2 gives 0, and F2.00 gives 20!
[15:51:35] <rayh> Some of the older formats required fixed lengths for numbers and such
[15:52:01] <cradek> I meant to cut some 1/2" plate at F4 but ended up with 40 until I stopped it
[15:52:04] <rayh> Some didn't even have decimal
[15:52:25] <SWPadnos> right - without a decimal point, it assumes the last digit (or the only digit in that case) is in the tenths place
[15:52:32] <rayh> 60100 was 60.100
[15:52:51] <SWPadnos> but then again, why would it use tenths if it only has resolution of 1 (ie, rounded down from 0.2 to 0)
[15:53:01] <rayh> wierd stuff it was.
[15:53:48] <SWPadnos> that's how gerber files are laid out - the format is without decimal points, but the precision is specified in the header line
[15:55:49] <rayh> Ah so it like a format command.
[15:55:53] <SWPadnos> yep
[15:56:04] <SWPadnos> that cryptic FSLAX2.4Y2.4 thing in gerber files
[15:56:45] <rayh> The Moog HydraPoint used 8 wide punch tape and had a block of 17 of these for each action.
[15:57:23] <SWPadnos> eek. hydraulics and paper cards. quite a winning combination :)
[15:57:38] <jepler> ETOOMANYCOMPUTERS
[15:58:00] <jepler> I've spent the last hour scoping the parport on the wrong machine (hint: nothing was happening)
[15:58:09] <cradek> arrrgh
[15:58:11] <SWPadnos> heh
[15:58:33] <cradek> that would be funny if it weren't me ... oh wait
[15:59:28] <rayh> How many times have I done that with ini files.
[15:59:47] <SWPadnos> I only believe I'm allowed to laugh because I've spent many hours probing the wrong connector, wrong pin, forgetting to turn on the power etc
[15:59:48] <cradek> and forgetting to compile
[16:02:15] <jepler> the regularity of the parport signal is quite good w/500us period
[16:02:23] <jepler> in line with the latency-test reading
[16:02:36] <SWPadnos> excellent
[16:03:28] <cradek> neato
[16:05:32] <jepler> I'm triggering on rising edge with a scope delay set the same as the claimed rtapi period, so I see the next rising edge after the edge that triggered
[16:06:05] <jepler> all the rising times so far fit within 2.5 8uS divs, with only a coupler of outliers beyond 1 div
[16:07:04] <jepler> instead of being distributed at the 500uS mark and above, it's distributed evenly a bit before and a bit after
[16:10:31] <jepler> now up to 40uS
[17:29:07] <skunkworks_> our k&t used leading zeros. 01 was 1 inch. 010001 was 1.0001 - it did not see decmal places.
[17:30:22] <skunkworks_> I made the 'tape emulator' take care of that. so 1.3 was conveted to 01.3
[17:31:03] <skunkworks_> or .030 was 00.030
[17:32:01] <skunkworks_> but then when you went into g1/2/3 - it only had 0.0000 digits. (we could only conture to 9.9999 inches.)
[17:32:15] <skunkworks_> crazy
[17:34:24] <skunkworks_> and it was g01, g02 and g03 :)
[17:52:05] <jepler> http://axis.unpy.net/01190912545
[18:47:06] <fenn> maybe you could call it 'soft realtime'
[18:47:21] <fenn> or perhaps 'firm' realtime :)
[18:48:44] <fenn> this is a fine vintage of emc with a delicate nutty realtime texture
[18:55:41] <skunkworks_> ah - yeah
[18:56:18] <skunkworks_> :)
[18:56:39] <skunkworks_> add-on realtime.
[18:58:31] <alex_joni> jepler: I see you really started using git
[19:28:39] <jepler> alex_joni: it's nice for organizing changes when I don't think they'll quickly go into cVS
[19:28:42] <jepler> CVS
[19:29:10] <alex_joni> cool
[19:40:27] <skunkworks_> logger_1: hello
[19:40:44] <skunkworks_> logger_1: bookmark
[19:40:44] <skunkworks_> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2007-09-27.txt
[19:40:46] <skunkworks_> heh
[19:40:48] <skunkworks_> odd
[19:42:51] <alex_joni> yeah, might have revived it a bit too son this morning
[19:42:54] <alex_joni> too soon
[19:56:54] <jepler> you're a cyborg in a pistol duel with two other cyborgs. you have been programmed to fire pistols with an accuracy of 33%. the other two cyborgs shoot with accuracies of 100% and 50%, respectively. the rules of the duel are one shot per-cyborg per-round. the shooting order is from worst shooter to best shooter. thus, you go first, the 50% guy goes second, and the 100% guy goes third; repeat. if a cyborg dies, we just skip his or her turn, obviously
[19:57:26] <jepler> what should you shoot at in round 1 to maximize your chances of survival over time?
[19:57:49] <jepler> am I missing something about this puzzle? It seems very simple: Shoot at the 100% player first.
[20:01:09] <jepler> huh I have an odd problem with my keyboard
[20:01:22] <fenn> it makes a terrible clicking noise?
[20:01:30] <jepler> left shift plus g or h produces no letter; right shift plus any key on that row produces no letter.
[20:01:53] <jepler> shift-' also doesn't work with left shift
[20:02:12] <jepler> it affects both machines hooked to this kvm
[20:08:09] <skunkworks_> ir is a good idea as - you shoot first - if you miss - the next robot 50% is also going to shoot at the 100% guy.
[20:08:38] <skunkworks_> i would think.. Unless it is a windows operating system ;)\
[20:08:59] <rayh> is skunkworks the 100% guy?
[20:09:02] <fenn> its a cyborg not a robot - sometimes people make bad decisions
[20:09:26] <fenn> like getting in gun duels with a 100% accuracy opponent
[20:09:53] <fenn> the correct answer is 'run, run quickly'
[20:09:54] <skunkworks_> heh
[22:06:45] <SWPadnos> here's an interesting discussion of the cyborg gun battle wuestion:
http://www.ocf.berkeley.edu/~wwu/cgi-bin/yabb/YaBB.cgi?board=riddles_hard;action=display;num=1027808060
[22:06:48] <SWPadnos> question
[23:26:55] <SWPadnos> holy cow! did anyone else see the machining druid thing Michel Gouget just posted to the user list?
