jepler: what happens in mm mode?
cradek: ultimately the number should be interpreted as mm or inch according to the G20/G21 setting
presently it's always interpreted as machine units
another possibility is to honor the display units
but, I guess you can't know how to change the spacing
if the spacing comes from the .ngc file then it has to be G20/G21 that set the units
if it's set in the GUI then it should probably be user units
I mean, display units
I'm hesitant about it being set in the ngc, since it's undiscoverable
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
it's very counter-intuitive to set it via g-code
view->grid would make more sense
but the scale.
dont make grid squares smaller than 5 pixels
beware, jeff will kick you in the shins for that
well, that's his problem i guess
it's your shins
told you so
once it scales a few times, I don't know how you'd know the numbers anymore
(qcad does that, and it's very disorienting)
actually I know how, but ... my shins
I think every drawing I've done in qcad is at a different scale, for that very reason
usually there is some kind of cursor-coordinates in the corner of the display
jepler: yeah, it's no good, although to a programmer it seems like a good idea I suppose
but that's something different altogether
a 'ruler' with numbers along the brightest visible grid line would be neat
you could draw the value along each grid line, at the bottom? and right? edge of the screen
you risk some clutter but if you want the values you'd have them
well, like in qcad, the 10's lines are brighter
but waaah, I want 16ths
you can't impose the scale
waaah i want log scaling
what's 16 squared? i dont even know
heck, it is 256, I was being stupid
and 256 squared is 65536
and 65536 squared is 4294967296
calm down boy
doesn't everyone know all the powers of 2 from 0 to 32?
i was just pointing out that 16ths gridlines dont scale very well
most people don't work in hexadecimal
I, however, am not most people
hey that'd be neat, a hexadecimal ruler
give them to all your machinist-programmer friends
most rulers have 16th's though, if they're good enough
really good ones go to 64th's
really good ones go to 10 or 100
nothing worse than only having a 64ths ruler when working in the cnc realm
really good ones have this little clock thingy on them
I bought a nice scale with 32/64 on one side and 10/100 on the other
$12 ? and very much worth it
one of my best buy is a $10 6 inch digital caliper.
Guest708 is now known as skunkworks
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
when I worked with engineers we had decimal-foot tape measures
I haven't seen them lately, maybe they were a fad
we did a lot of cad in feet, and decimal feet was more natural I guess
I think the one that I have - I bought 2 years ago and still have not put new batteries in it.,
it turns off. the second you move it - it turns back on.
never checked to see how acurite it is.. but if it is that important I pull out the dial micrometers.
a pair of 123 blocks is a nice quick check
some are surprisingly off mid-scale, then match back up later
or maybe it's cyclic
I think it's a case of the man with more than one watch never knowing what time it is
your parts will fit together if you measure them with the same (chinese) stick
yes - although everything seems to measure what you would think. pick up shaft and it measures 1" and so on.
alex_jon1 is now known as alex_joni
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
max jitter has been slowly creeping upwards (at 31000 now)
hmmm. I'd like to see a scope trace of a parport output
I'm always suspicious of software (or hardware) that tests itself
I wonder if that would be a sawtooth from some clock skew thing
ie, max lat grown more or less linearly until the next time some timing edges meet, where it goes back down to near 0
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
this looks promising for servo-thread-only systems
but those are such a minority
yeah - it does
I wonder how "hard" that realtime is though
I doubt it was easy to get performance even this good, so in that sense I'd call it "hard"
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
depends on the kind of crash you get, I suppose
this seemed to be a hard kernel crash
but I could see the outputs on the scope still being updated
and much less jitter too :)
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
of course hal_parport doesn't build ..
wow that's very interesting
or, isn't built
there would need to be some changes to sim_rtapi
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)
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
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"
(they don't say whether it's an error on the display or an error in your part)
and trailing zeroes can be left off, except for G4, which requires two of them
May I ask a probably dumb question. What's r2?
not dumb. my bridgeport r2e3
I keep running into controller bugs/features
Ah. Okay. And the gcode is their style.
yeah it's pretty bad
Do you have their cam generator as well.
I didn't get any software, but I've figured out how to upload gcode to it
Matt was talking like he has one laying around.
is that just some dos software?
or was it an entire special computer
I don't know much about it.
But I thought it was software that loaded on a computer. Must have been dos.
thanks, I might ask him about it, but I will be running emc on it one of these days.
That's the right way if it's a cripple.
I've fixed the myriad problems with the original hardware - it actually works fine now (as well as it ever did)
but, I'd like to do tapping, tool length probing, maybe eventually some 5 axis, etc - emc is the way to do all that
besides I can run programs longer than "100 feet" then too
just leave off all those extra zeroes and you can get more lines in the 12k
and never specify a movement mode (G1, G2...) more than necessary
(or do an emc rertofit :) )
rayh: recently I found that if you specify F2. you get 2, F2 gives 0, and F2.00 gives 20!
Some of the older formats required fixed lengths for numbers and such
I meant to cut some 1/2" plate at F4 but ended up with 40 until I stopped it
Some didn't even have decimal
right - without a decimal point, it assumes the last digit (or the only digit in that case) is in the tenths place
60100 was 60.100
but then again, why would it use tenths if it only has resolution of 1 (ie, rounded down from 0.2 to 0)
wierd stuff it was.
that's how gerber files are laid out - the format is without decimal points, but the precision is specified in the header line
Ah so it like a format command.
that cryptic FSLAX2.4Y2.4 thing in gerber files
The Moog HydraPoint used 8 wide punch tape and had a block of 17 of these for each action.
eek. hydraulics and paper cards. quite a winning combination :)
I've spent the last hour scoping the parport on the wrong machine (hint: nothing was happening)
that would be funny if it weren't me ... oh wait
How many times have I done that with ini files.
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
and forgetting to compile
the regularity of the parport signal is quite good w/500us period
in line with the latency-test reading
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
all the rising times so far fit within 2.5 8uS divs, with only a coupler of outliers beyond 1 div
instead of being distributed at the 500uS mark and above, it's distributed evenly a bit before and a bit after
now up to 40uS
our k&t used leading zeros. 01 was 1 inch. 010001 was 1.0001 - it did not see decmal places.
I made the 'tape emulator' take care of that. so 1.3 was conveted to 01.3
or .030 was 00.030
but then when you went into g1/2/3 - it only had 0.0000 digits. (we could only conture to 9.9999 inches.)
and it was g01, g02 and g03 :)
[17:52:05] <jepler> http://axis.unpy.net/01190912545
maybe you could call it 'soft realtime'
or perhaps 'firm' realtime :)
this is a fine vintage of emc with a delicate nutty realtime texture
ah - yeah
jepler: I see you really started using git
alex_joni: it's nice for organizing changes when I don't think they'll quickly go into cVS
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2007-09-27.txt
yeah, might have revived it a bit too son this morning
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
what should you shoot at in round 1 to maximize your chances of survival over time?
am I missing something about this puzzle? It seems very simple: Shoot at the 100% player first.
huh I have an odd problem with my keyboard
it makes a terrible clicking noise?
left shift plus g or h produces no letter; right shift plus any key on that row produces no letter.
shift-' also doesn't work with left shift
it affects both machines hooked to this kvm
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.
i would think.. Unless it is a windows operating system ;)\
is skunkworks the 100% guy?
its a cyborg not a robot - sometimes people make bad decisions
like getting in gun duels with a 100% accuracy opponent
the correct answer is 'run, run quickly'
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
holy cow! did anyone else see the machining druid thing Michel Gouget just posted to the user list?