mozmck: on your 9.10 machine running your realtime kernel, do you use hostmot2 and/or get a warning about __fixunsdfdi when building the emc2 kernel modules
I don't have any mesa stuff so I don't use hostmot2, but I didn't get that error when compiling either.
mozmck: it's a warning, not an error, so it's possible it just scrolls by..
I did get a different error in hostmot2 and fixed it: something changed in newer kernels but I can't remember what it was.
hmm, let me compile again and see...
yuck, polar has a misfeature that's hard to fix
g0 @1 ^135 / @0 / @1
what's that do, lose the degrees?
I expected it to go right, but here it goes left for some reason
x87 defines atan2(+-0,+-0) as -0, +0, -pi or +pi depending on the signs of the inputs
g0 @1 ^135 / @0 / @1 goes left, g0 @1 ^45 / @0 / @1 goes right
(but I don't know if it's consistent)
I don't know how to fix this.
just saw hostmot2 go by and no errors or warnings...
mozmck: thanks for the info!
hm, that's interesting. I just did 'sudo sh emc2-install.sh' and it got an error doing the gpg key import
this is master with a fresh pull
.. but it's scrolled away now
aren't those messages all at the end, at the modpost or ldd stage?
something about permissions
(or whatever the program is called)
SWPadnos: yeah, modpost I think is right
there's no warning about __fixunsdfdi at all that I can find.
I guess I need to make it an error if I can't fix it.
cradek, how about something simple but icky: if (fabs(radius)>TOLERANCE) angle=atan(blah blah)
else angle doesn't get changed
cradek: you mean, reject @0?
angle not getting changed is not a complete fix
jepler: no, reject @ without ^ if at 0,0
cradek: oh, that's not so bad
what's not fixed by retaining the old angle? (I don't fully understand the problem)
maybe s/at/darn close to/
TOLERANCE or DELTA or whatever it's called
SWPadnos: I don't think the angle is stored explicitly
I haven't read the source though
yeah, me either
an extreme case is never specifying an angle in the program, but programming @1 while at the origin
ok, I can see that as a problem, though zero would be a reasonable initial angle
but you want this to be defined, right? X1Y0 / ^45
yes that's definitely defined
x1y0 establishes a unique radius
x0y0 does not establish a unique theta
yes and angle
all points on the plane except the origin have a unique radius and theta
I depend on those unique r/t because if you don't specify one or the other it goes unchanged
yeah, so it's difficult to choose whether a move to 0,0 followed by @something should go to something back where it came from, in the direction it was going, or be an error
exactly like how x/y work
(or do something else)
I'm going to make it an error
sounds good to me :)
if something is the only possible solution it must be the solution that should be implemented </spock>
errors are good. when the person smarter than you comes along, the error can be taken away and useful behavior put in its place
jepler: yes, and I certainly wish him/her all the best and I look forward to it.
the smart "figure out what they meant" code - I'll be interested in seeing that
sometimes it's even future-me who is smarter, which is heartening
CHKS((block->radius_flag || block->theta_flag), _("Sorry, I'm too tired to implement polar coordinates in G53 mode"));
you can do a tiny bit better on that error message
"... Maybe later."?
someone *cough* really oughta test polar + cutter comp
hmmmmm, the plot thickens
if at the origin, and in G91 mode, @1 is indeterminant, as is ^1, as is @1^1
ulp, it's sure true that those 64-bit 8.04 packages don't do well under vmware -- kern/preempt just kills the system.
whole system or virtual system?
it could be that 64-bit vmware just performs so badly under that kind of workload that it never meets its deadlines..
hello, need some help getting the actual line executing a program
16:37:57 <jepler> gtom_: the documentation lists motion.program-line but I can't verify at the moment that it works as advertised
gtom_: I dunno if you saw this; I said it after you left a few days ago
didnt see that..
the problem exists in axis also.. users do not see the first lines of a program if you step the program...
i mean, theres no feedback to the user...
sadly that is a huge swirl
a way to resolve this???
I don't know that answer, sorry
it's not a question with a short answer. emc has several ideas of the line number (the last line of gcode parsed, the last line of gcode executed, the last line of motion gcode executed). it has a complicated system for single stepping that has bugs. it has flow control, which complicates matters too. it needs someone to understand it all and make it better.
will take a closer look at the code, maybe ill find a way to resolve this... :)
(by "it has flow control", I mean that our gcode interpreter now has flow control like subroutines and loops, which wasn't part of the initial design)
'morning all :)
fascinating: g0@.5^45 / g91 g81 r.1 z-.5 @-1 l10 f60
(first one g90)
no points on the plane have a unique r,theta
g90 g0 @-1 ^45 / @.5
should the other line have generated a line of holes along a 45 degree angle?
sort of. for each hole, it goes a negative incremental radius. in the example I gave, it bounces back and forth across the origin.
crossing the origin feels screwy but it does what you ask - I suppose it just needs careful documentation
the 45 isn't sticky
the g81 block does not specify ^ so the angle should be "unchanged" throughout the cycle
just like not specifying X, you get a vertical line
yeah, except X is orthogonal to Y
whereas @^ and XY aren't
@^ are orthogonal in the polar system
so it's more complicated to decide when to recalculate the angle
I see the "parallel" anyway (haha geometry pun)
no, I mean the pairs are specifying the same thing
they're not independent
within one system they are, but the two systems are "overlaid"
unless you make it modal
I don't follow you
well, all the other coordinates are completely independent of each other as far as G-code is concerned
so you have separate variables for XYZABCUVW, and you can leave them alone when they're not specified
they don't change
that's not true for r+theta, since you need to recalculate X and Y when @^ change
and you need to recalculate @^ when XY change
that is also true for polar if you consider ^ to not wrap and restrict @ >0
that's a separate issue
ok I see how you mean x/y/@/^ interact, but I don't see that as a problem - what am I still missing?
@^ is a synonym for XY, which is not the way any other coordinates wotrk
you have to be careful about *not* recalculating @^ unless it's absolutely necessary
OR always normalize it
well, that's a problem if you have e.g. a peck cycle (array) that lands on the origin
start at -10, go by 1 for 21 loops
I'm also thinking that it's at least part of the problem with the back and forth behavior of the expected "line of holes" code
peck cycle array are relative motion and I think that's undefined if you're at the origin
non-sequitur: can you specify ABC in a peck cycle?
well I'm not at all convinced that the back-and-forth is wrong, I only think it's interesting :-)
I'd be surprised at it
I don't think you can move ABC
I was just thinking about drilling a series of holes around the perimeter of a tube or something
more or less indexing
there's no plane that agrees with that kind of motion
cycles only work perpendicular to planes
it's a peck cycle that moves e.g. C a fixed amount per hole
I know what you mean
it's a perfectly sane kind of motion, but there's no gcode plane (g17, g18, ...) corresponding to (say) XA with Z perpendicular
anyway - just curious about that
CHKS(((block->g_modes > G_80) && (block->g_modes < G_90)), NCE_CANNOT_PUT_AN_A_IN_CANNED_CYCLE);
EMC: 03cradek 07master * rf28d2ebf9742 10/src/emc/rs274ngc/ (interp_find.cc interp_internal.hh): Error on polar specifications that make no sense
micges_work1 is now known as micges
weird, seb says that a second 3x20 firmware I built works for him, but the only change was something pcw said didn't matter :-/
don't you hate when that happens
jepler: I presume adding packaging stuff for 10.04 is not a new feature?
it's new, but should be added
steves_logging is now known as steve_stallings
especially since we're hoping/planning on having a 10.04 based liveCD
yeah, I guess I'll be working on that
mozmck: if it's just packaging it'll be uncontroversial
just looking under debian on master, and noticed that there are not extras directories for each distro.
are they not needed now?
getting packaging right is part of the stabilization process that's supposed to be made easier by the feature freeze
they aren't at odds IMO
mozmck: git show 6b75e58b4 for my logic about debian/extras
At Cabin Fever show I was able to talk with George Bulliss about EMC developers access to the facilities at the school hosting the CNC Workshop.
They can allow late night access provided the names of those staying late are given to security in advance.
when/where is that?
mozmck: it looks like it's still possible to have a different 'extras' directory for each DISTRIB_NAME but I hope that the default in extras/ can work for as many systems as possible
sounds good. as far as I know that stuff hasn't changed. I just copied an old one for 9.04 and it worked fine.
mozmck: ann arbor MI, juneish
bleh, that's like across the world for me :(
yeah, only halfway across the world for jeff and me
[15:48:57] <steve_stallings> http://bbs.homeshopmachinist.net/forumdisplay.php?f=10
someday I might have to use one of those newfangled aeroplanes again
:) would love to go though
you can't carry the bus on those though
mozmck: with a blue hat, yes
steve_stallings is now known as steves_logging
mozmck: you're complaining it's far?
alex_joni: heh, I guess it all depends on how much time/money you have. Sometimes Dallas is far and I'm only a hour away!
that is soo true
mozmck: is Lincoln NE on your way?
Dallas is always far, even if you're there already
I don't know, have to look.
Lincoln isn't between the Dallas area and Ann Arbor :)
no I see it sure isn't
SWPadnos: yeah, can take a hours to get across it in traffic...
you have a pretty decent diagonal path. for some dumb reason I was thinking you'd have to go north to 80.
no looks fairly straightforward
google says +4h to go through lincoln
22 vs 18
18 is not as bad as I was thinking it would be
if it is 18...
a little less than me going to Galesburg :)
usually it ends up a bit more than that
12 for us
alex_joni, it's 18 for you as well, just on an airplane :)
I was thinking it might help if we'd drive together, but it's no win for you
yeah, thanks for the thought though
I bet flying to detroit is MUCH cheaper for you
than driving I mean
I'll just have to see when the time gets closer.
what's the date?
hmmm. it's 75 miles more to go on I-90 instead of going through Canada, but I wonder if the border crossing would eliminate that disadvantage
June 22-25 I think
(I only remember because my anniversary is during that time ...)
alex_joni: we're going through chicago and would be happy to pick you up :-)
budapest-detroit is ~13h on the shortest connection
heh, about the same as our drive!
total: 1334$ at LH
man, jmk lucks out for once
same state even
bbl, have to go work on vehicles...
hmmm. $1300 or so for that ticket
so if I can turn on live view remotely, that would eliminate the problem
[21:51:44] <alex_joni> http://www.nosucherror.com/
wow, those dorm rooms are cheap