fenn_ is now known as fenn
[02:36:24] <cradek> http://timeguy.com/cradek-files/emc/coin.png
this is a penny. I need to make a new probe tip - this one's not sharp enough for any detail but the edge
jmkasunich__ is now known as jmkasunich
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2007-11-09.txt
cradek: does loading (previewing) a gcode file with (PROBEOPEN) nuke the file?
I guess it doesn't, because (PROBEOPEN) is handled post-canon
while (debug) and (message) or whatever they're called are handled pre-canon
jepler, did you see my conversation last night with Wowbagger?
about AXIS hanging at NC file load
SWPadnos: yes but I didn't read it very closely
what's in the file?
ok. I don't think there's a problem with AXIS, I'm more suspicious of the guy's 233MHz laptop with neomagic display drivers and only 160M RAM
I had him reload the axis splash file
maybe his opengl is bad
it loads fine at startup, but if you load a file after that it gives you an endless hourglass
huh that sounds strange
and he was ssh'ed into it, using the GL on an Intel 915 setup last night
I couldn't figure out why it would work at startup and not afterwards
if it can take the whole X server with it (can't switch to text console), it's an X server bug
though this was remote, so who knows what might have been in there
but it would load the emc2/AXIS splash code fine
oh for some reason I thought it broke the whole system
pressing the reload button would hang it
nope, just axis
I had to ask him to clarify what "hang" meant though ;)
you might get a traceback from axis if you kill -INT it
cradek: what's it take to run the sim probe?
I take it there's some configuration stuff I don't have
[16:14:30] <cradek> http://timeguy.com/cradek-files/emc/probe.tar.gz
[16:14:33] <cradek> http://timeguy.com/cradek-files/emc/hemisphere.comp
so - your digitizing of the sphere was virtual? coolk
soon we'll have the secret service in here investigating cradek's counterfeiting racket
he did try to scan a coin..
G1 X0.120000 Y-0.960000 Z0.253132
G1 X0.080000 Y-0.960000 Z0.268646
G1 X0.040000 Y-0.960000 Z0.277190
now I am debating what to do about opening the log for append vs clearing it if it has contents (fopen "w" vs "a")
probeopen clears the file's existing contents unconditionally
I don't see any problem with that
that's great jeff, thanks
* cradek kicks CIA-18
I guess we have two partially-working CIAs now
Guest718 is now known as skunkworks___
skunkworks___ is now known as skunkworks_
hmmm. at the moment, are tool offsets part of the interpreter or canon/traj?
or, does canon operate in machine coordinates, and offsets / coordinate systems / other neat things are left as an exercise for the interpreter?
(or being another question phrasing, not an either/or option for canon)
be quiet, will you?
sound of silence..
"Hello darkness, my old friend"
hmm - I actually think I have that cd in the car..
mine is in the CD rack about 6 feet to my left
and on the PC :)
I think I only have 3 cd's right now in the car. Simon & Garfunkel, Feist, and tom petty ;) wife took the cd case..
hmmm. there seems to be a dichotomy in HAL drivers and pin naming/use
the fact that you (the user) need to explicitly tell HAL which I/O bit to use, for example, seems to conflict with the concept of drivers that auto-detect waht hardware is available and export different HAL pins depending on what's found
the former case conceptually is "the integrator should define exactly where the I/Os connect"
whereas the latter case is "the integrator doesn't have to know what hardware is connected"
this is reasonably easy to reconcile in the case of the parport, for example. just specify the order the ports should be scanned and their I/O modes, and you should get the same HAL pin <-> physical hardware pin connections every time
(unless you have PCI parports and the PCI subsystem decides to change the scan order or something)
in the case of more complex hardware, such as PPMC, Mesa, Motenc or STG, it's not so easy
maybe the "improved" latency test should be removed .. it sounds like a lot of people run emc 2.1 with timings that trigger this error, but never noticed a problem..
yeah, it's hard to tell whether it's better to warn people, or if they'r ehappier not knowing
hmmm. Do we really support RTLinux still?
it may still work
I see the rtl_??api.c files, but they're considerably older than the RTAI ones
ok, that was my conclusion
I have not heard this word "support" before - what does it mean?
err - attempt to make it work with ...
afaik nobody is using it.
I'm writing the abstract for the potential ESC talk, so I'm actually looking at it ATM :)
I think I was the last hold-out
so it's safe to say that although it started out somewhat cross-platform, it's Linux/RTAI only at the moment (sim excluded)
if you really want, it might be possible to talk me into booting that old disk. I probably still have it. I maybe can find it.
oh no, I don't really care about RTLinux these days
I'm pretty sure I kept it for a future day such as that
in fact, I haven't cared much since they started being a money-grubbing company
cradek, would you mind looking at the abstract (and commenting on it)?
can you send it? I'm about to run off for a bit
oh - I'm in a time crunch as well. I'll pastebin and see later if I've made any glaring errors :)
SWPadnos: I can look it over too, not sure I'll be much help though :)
ok. if only DNS were working again ...
stick other servers in there
yeah, no kidding
good night all