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