Back
[08:30:22] <jepler> who banned logger[psha]; did we discuss this?
[08:31:50] <jepler> I can see from chanserv that the ban was made about 1 day + 14 hours ago, and I didn't find anything in my scrollback about it
[08:32:16] <archivist> it has a fault and was constantly rejoining
[08:33:30] <jepler> I've configured my client so that I don't see joins/parts so I was unaware of that
[08:34:10] <archivist> as I am an op in some channels I dont hide them
[08:36:31] <jepler> archivist: was it something that just started happening within the last 2 days, or had it been going on for longer?
[08:37:00] <archivist> last few days
[08:37:02] <jepler> psha: if you ever see this (for instance via zlog :-P) contact us if you resolve the problems with logger[psha]'s connection reliability and we'll unban it.
[08:37:20] <jepler> not sure what more to do than that :-/ thanks for the info archivist
[08:37:24] <archivist> odd because the fault does not happen in the other channel
[08:51:57] <cradek> jepler: I did it, banned for 1 day and then when that expired the logger was still doing the same thing, so I made a new one for 3 days
[08:53:01] <cradek> it was joining/leaving several times a minute
[08:53:06] <jepler> cradek: OK. I didn't know you could make a ban that timed out, and I didn't see from chanserv that it was a time-based ban
[08:53:18] <cradek> a nice feature
[08:54:09] <cradek> -ChanServ(ChanServ@services.)- 1: logger[psha]!*@* (no AKICK reason specified) [setter: cradek, expires: 1 day, 8:41:34, modified: 1d 15h 18m 26s]
[08:54:19] <cradek> fwiw you can see all that with akick list
[09:00:04] <jepler> ah
[09:00:09] <jepler> I was using /msg chanserv flags #linuxcnc-devel
[09:23:11] <skunkworks> andys last push doesn't seem to work even for the test gcode
[09:23:55] <skunkworks> although it could be I just don't have the line configured right
[09:26:38] <skunkworks> http://electronicsam.com/images/KandT/testing/Screenshot-26.png
[09:39:49] <cradek> KimK: I figured out how to delete those wiki pages and am (slowly) doing it now, thanks for doing cleanup work
[10:36:03] <skunkworks> zlog
[11:03:50] <cradek> andypugh: fwiw, the interpreter knows and maintains the difference between +0 and -0, and there is precedent for it mattering: with wrapped rotary, G90G0A+0 and G0A-0 move in opposite directions
[11:04:31] <andypugh> That’s worth noting
[11:04:38] <andypugh> Is -0 < 0 ?
[11:04:50] <andypugh> And is +0 > 0 ?
[11:04:54] <jepler> andypugh: no
[11:04:56] <cradek> I think they are all equal
[11:05:39] <andypugh> So how does one make use of the difference?
[11:06:06] <jepler> signbit(-0.0) and signbit(0.0) are different
[11:06:47] <jepler> and there are some cases where the standard math functions treat them differently
[11:06:49] <andypugh> Is that actual code or pseudocode?
[11:06:51] <jepler> >>> atan2(0,0)
[11:06:53] <jepler> 0.0
[11:06:56] <jepler> >>> atan2(0,minuszero)
[11:06:58] <jepler> 3.141592653589793
[11:07:08] <jepler> andypugh: signbit() is a math function in C99 (but probably not in rtapi_math.h fwiw)
[11:07:12] <cradek> rs274ngc/interp_find.cc: int neg = copysign(1.0, sign_of) < 0.0;
[11:07:42] <jepler> (python has math.copysign but not math.signbit)
[11:07:43] <cradek> andypugh: so the answer is "weirdly"
[11:09:43] <andypugh> I think that, actually, the initial move of the block is an adequate (and logical, in the context of the profile analysis) way to define the +X -X quadrant, and the direction the profile runs in can give you the rest
[11:10:11] <andypugh> Using J is just silly, and the option of -ve J to undercut sounds useful.
[11:11:32] <andypugh> Anyway, I seem to have a working set of code now, so cleaely it it time to tear it all apart and try something better that has just occurred to me.
[11:11:41] <cradek> haha
[11:12:14] <andypugh> I have a few special-cases “if this and this then do this instead” and I don’t trust those to be correct
[11:12:27] <cradek> I can't help you decide on a good design, but I saw you had a misconception about -0 and wanted you to have all the facts to work with
[11:13:32] <andypugh> Yes, and I can see that it might be useful, and used. It certainly would be if we use J (U) L (W) to determine quadrant, but that’s not currently the plan.
[11:14:25] <andypugh> The advantage of using L(W) for Z-axis quadrant, I suppose, is that two tools can be used to cut the profile from two directions, though that is only useful if you also have perfect gouge detection.
[12:06:18] <andypugh> I just realised, I think I can optimise horizontal lines out of the profile :-)
[12:11:04] <skunkworks> andypugh, did you see
http://electronicsam.com/images/KandT/testing/Screenshot-26.png
[12:11:16] <skunkworks> the samples don't seem to work either
[12:12:23] <andypugh> Hmm, strange. I am fairly sure they all worked last night. But it was very late indeed.
[12:12:46] <andypugh> Don’t worry, I am ripping it all up anyway :-)
[12:14:28] <skunkworks> heh
[12:14:51] <skunkworks> It could sure be doing something wrong - but I didn't touch the sample programs
[15:21:00] <andypugh> I am running in a VM, and the messages “task: main loop took 0.010842 seconds” are kind of anying when I am analysing pages of output, and it keeps printing that and sending me back to the bottom. Does anyone know if it can be turned off?
[15:21:43] <andypugh> (I have DEBUG = 0)
[15:27:50] <bpuk> comment it out in the source and recompile is probably easiest
[15:28:40] <bpuk> oddly - I'm not getting that message at all
[15:31:03] <cradek> yeah I also think you have to take it out and rebuild
[15:31:26] <cradek> (I don't think that's a useful enough message to leave on all the time - others disagree)
[15:35:59] <andypugh> What is it telling me?
[15:37:19] <andypugh> bpuk: Suggestion: No L-offset on G0 moves
[15:37:35] <cradek> task didn't run for longer than expected (requested)
[15:37:52] <cradek> which is normal because it's not realtime
[15:37:54] <bpuk> andypugh: reasoning?
[15:37:54] <andypugh> Probably a VM thing thrn
[15:38:02] <cradek> no, we see it on real machines plenty
[15:38:16] <cradek> it's normal as long as it's not super bad
[15:38:21] <andypugh> bpuk: You want to touch the entry and exit moves, not offset
[15:41:07] <bpuk> a G0 move within the profile block is normally treated as a G1 (i.e. the rapid is ignored) after the first block. only time a rapid is used is on the return.
[15:41:27] <andypugh> Yes, exactly
[15:43:29] <bpuk> ok, so removing the L offset would mean that it doesn't retract after a cut?
[15:43:45] <bpuk> and does a reverse spring pass?
[15:44:17] <andypugh> https://ibin.co/33nq04V8tDWr.png
[15:44:38] <andypugh> If thee wasn’t an L offset on the entry and exit rapids, life would be better.
[15:44:55] <andypugh> (ignore the other glaring prblems with that one)
[15:45:24] <bpuk> L is W - so Z position offset (not X)
[15:45:31] <andypugh> Yes
[15:45:42] <bpuk> ok, so it would enter further to the right on all moves
[15:45:59] <andypugh> No, just the ones that start and end on a rapid
[15:46:26] <andypugh> Well, further right on ontry rapid and further left on exit rapid
[15:46:37] <andypugh> Let me do it…
[15:46:43] <bpuk> yeah - so would give a squarer cut to the profile #
[15:47:00] <bpuk> ok, turn R up a little so it's easier to see ;P
[15:49:40] <bpuk> checked my code - L and K aren't applied to the rapid entries or exits. the retract value is applied to the exit in both X and Z
[15:50:13] <andypugh> That was my proposal too
[15:50:33] <bpuk> which is why I was getting confused - you were proposing what I thought was normal ;)
[15:51:18] <bpuk> or at least, normal for type1 retracts
[15:51:22] <bpuk> type2 are totally differnt
[15:53:05] <andypugh> https://ibin.co/33nsfEd2m1x5.png is the difference
[15:53:13] <andypugh> It is nothing at all to do with retracts
[15:53:21] <andypugh> It’s the offset.
[15:54:14] <bpuk> second one is what I'd get (looking at the RHS and far LHS)
[15:54:15] <andypugh> Type II retracts (as documented) still elude me. Also not sure if entries are meant to follow the profile too.
[15:54:48] <bpuk> yeah, entries should follow the profile within the limit of the backangle
[15:55:01] <andypugh> <later>
[15:55:13] <bpuk> https://diy.haascnc.com/sites/default/files/Locked/Manuals/Images/G71PATH.png
[15:55:22] <bpuk> is probably the one of the better images I've seen
[15:55:53] <andypugh> Actually shows square entry
[15:56:39] <bpuk> so it does - I was getting confused with the prefinish and finish pass
[15:57:11] <andypugh> TBH with a prefinish I am not sure that an angled exit is a win
[15:58:40] <bpuk> I suspect (but don't know) that the original type1 systems didn't have prefinish, some controls adopted prefinish, others didn't. Type2 was then made to fix the deficiencies in the earlier type1 controls
[15:58:56] <bpuk> and you ended up with the same effect from two different features
[16:00:06] <bpuk> at least with the 'follow the path' exit, you'll be in the cutting zone, not in the rubbing zone. Needs more thought
[16:03:06] <andypugh> What does “follow the path” exit do if the path takes a sudden swerve?
[16:04:01] <bpuk> I'd have to test, I suspect if the path changes direction it simply continues upwards
[16:04:07] <andypugh> It is actually another tricky gouge-detection puzzle
[16:05:11] <andypugh> That picture might show the exit move curving round. It’s not clear.
[16:05:12] <bpuk> I can load some test profiles on the machine and work and photograph the toolpath?
[16:05:25] <andypugh> Yes, that would be interesting.
[16:06:31] <bpuk> probably be saturday morning before I get a chance, but I'll take the pawn file in at least
[16:08:09] <bpuk> or if you have a more 'evil' path to test?
[16:15:38] <andypugh> Let me try to make one
[16:16:00] <bpuk> but not so evil that it can't actually be machined with a sane tool right
[16:40:23] <andypugh> That’s no fun :-)
[16:40:33] <andypugh> I had intesecting circles for you :-)
[16:40:48] <andypugh> This is just a bit random:
http://codepad.org/Amo4NwZp
[16:43:57] <bpuk> to be honest, I'm curious to see what happens on a commercial control with intersecting circles
[16:44:03] <bpuk> I figure it will error out
[17:33:28] <andypugh> I am having a remarkable amount of difficulty coming up with an expression for “x is equal to or between a and b” when the relative magnitudes of a and b are not known.
[17:46:19] <bpuk> so b < a || a < b could be true
[17:46:44] <andypugh> Yes.
[17:46:55] <andypugh> or, even, b = a
[17:48:19] <andypugh> Lots of trivial examples on steckexchange where the limits are known constants
[17:48:20] <bpuk> ok. if (a==b) /* something */ else if (a>b) { if ((x<a) && (b<x)) {/* code */}} else { if ((x<b) && (a<x))}
[17:48:32] <bpuk> I _think_ that should do it
[17:48:58] <bpuk> the next option is to create new variables c = max(a,b) d = min(a,b) and perform the comparison then?
[17:49:05] <andypugh> For _exclusive_ in-range (x > a) != (x > b) works
[17:50:04] <bpuk> apart from the </<= error - I think I should be fairly close
[17:50:54] <andypugh> Yes, I have written a version with lots of “if”s but feel that there should be an elegant one.
[17:51:06] <bpuk> aaaah
[17:51:29] <andypugh> (x - a) * (x - b) <= 0 maybe?
[17:52:01] <andypugh> (actually, I think that’s it)
[17:52:16] <bpuk> I'll stick with if's ;)
[18:00:19] <andypugh> Well, actually, it turns out not to be as simple as I thought.
[18:00:45] <andypugh> (The test is, but the numbers I am working with are not)
[18:01:21] <bpuk> oh?
[18:01:31] <bpuk> floating point error?
[18:03:26] <andypugh> Looks like it, but somewhat too big
[18:05:31] <bpuk> expand it to the quadratic?
[18:05:45] <bpuk> probably more error that way
[18:08:39] <andypugh> I am not sure what you mean by that
[18:13:33] <bpuk> a daft thought - there would be a lot more operations, so it'd compound any error (x^2 -xb -ax -ab <= 0)
[18:52:24] <andypugh> There isn’t a lot to it. The first option (y = yc - dy) is correct, but numerically it isn’t right. I am just about to plot the arc in CAD to see if it is actually correct
[18:52:27] <andypugh> http://codepad.org/PfHfrJDV
[19:20:40] <andypugh> I finally see the problem. My quadrant isn’t a quadrant. How interesting.
[19:29:52] <andypugh> … because I changed the names of some variables. But not everywhere!
[19:51:34] <skunkworks> http://electronicsam.com/images/matsuura/20161130_171046.jpg
[19:54:50] <andypugh> What actually is it?
[19:55:51] <andypugh> (and, Aluminium looks out of place)
[19:58:33] <skunkworks> heh - i needed a big flywheel for an experiment :)
[19:58:52] <skunkworks> the aluminum is the adaptor i needef
[19:58:56] <skunkworks> needed
[20:01:03] <skunkworks> it also looks like the edm is looking promising.. the hydralic ram seems to servo.
[20:04:31] <KGB-linuxcnc> 03andypugh 05andypugh/g71type2remap f4f0163 06linuxcnc 10configs/sim/axis/g71/python/remap.py 03nc_files/aptest.ngc 10nc_files/lathe_pawn_G71.ngc G71 and G72 Type II: Change to a better algorithm with clues for the cut builder * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f4f0163
[20:04:51] <andypugh> skunkworks: That _ought_ to work
[20:10:35] <skunkworks> andypugh, g71test1.ngc seems to put it into an infinite loop..
[20:12:15] <skunkworks> andypugh, g71test.ngc.
[20:13:49] <andypugh> skunkworks: Not a loop, it’s opened the Python debugger
[20:16:42] <skunkworks> Sorry - I am probably not 100% focused on debugging right now.
[20:17:40] <andypugh> I didn’t mean to leave the debugger in there
[20:22:59] <KGB-linuxcnc> 03andypugh 05andypugh/g71type2remap b4d8ce7 06linuxcnc 10configs/sim/axis/g71/python/remap.py 10nc_files/G71test1.ngc G71 / G72: remove the thing that opens the debugger to confuse skunkworks * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b4d8ce7
[20:32:40] <linuxcnc-build_> build #2787 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/2787 blamelist: andypugh <andy@bodgesoc.org>
[20:47:21] <linuxcnc-build_> build #4643 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4643 blamelist: andypugh <andy@bodgesoc.org>
[20:49:41] <andypugh> It bogs down terribly with 1nm cuts :-)
[21:16:42] <Tom_L> are there iso images for 2.7.8?
[21:16:53] <Tom_L> or upgrade only..
[21:42:01] <cradek> you have to run the upgrades
[21:52:51] <Tom_L> i figured it out. thanks
[21:54:12] <Tom_L> yay, 2.7.8 installed
