Back
[10:45:00] <skunkworks> jepler: so - if I have a setp parport.0.pin-01-out true and a ssetp parport.0.pin-01-out-reset true
[10:45:45] <skunkworks> after the reset - the hal file will force the port true the next period?
[10:46:15] <skunkworks> (I don't have to do anything else except setp the port true once in the hal file...)
[11:04:56] <cradek> in reset mode, the input being true means "generate a pulse this period". you've got that turned on, so it'll make pulses until you turn it off.
[11:06:38] <skunkworks> ah - ok
[11:07:52] <skunkworks> hmm - wait. I want to send pulses out of the printer port every period. so those 2 lines should be all I need?
[11:08:02] <skunkworks> (other than the reset function)
[11:08:13] <skunkworks> and the reset time..
[11:09:20] <skunkworks> or would I have to be runing a function that sets the pin high each period?
[11:11:44] <skunkworks> (I will be playing with actual hardware later today - so I can just play with it then..)
[14:35:52] <mhaberler> bizarre question of the day: I need a reliable way to cause an RT missed deadline fault in an RTAI thread function. Any suggestions?
[14:38:18] <jepler> mhaberler: repeatedly call rtapi_delay() until you're sure to have gone on too long?
[14:38:29] <mhaberler> ok
[14:38:49] <jepler> (do it based on an I/O pin that you set back to 0, so it only happens once? or a rising edge on an IN pin?
[14:38:52] <jepler> )
[14:39:00] <Tom_itx> will rtapi_delay() accept a delay parameter?
[14:39:15] <jepler> man rtapi_delay says it will
[14:39:24] <Tom_itx> instead of multiple calls
[14:39:41] <jepler> well it's designed so that it can only delay for rtapi_delay_max, typically 1/4 of a period
[14:39:46] <mhaberler> all in place already; turned out the rtapi exception handling was all cleaned up in the ub branch already - I just had forgotten I did it already
[14:39:49] <Tom_itx> oh
[14:39:51] <jepler> so you'd need to call it 4 times to be sure you've wasted an entire period
[14:40:14] <mhaberler> so rt fault behavior and pins are now defined by a loadable halcomp
[14:40:32] <mhaberler> which can redefine default behavior (just printing errors)
[14:50:54] <zultron> http://pastebin.ca/2420162
[14:51:32] <zultron> Whoops, meant for mhaberler. Anyway, mhaberler, bit of a bizarre error....
[15:06:58] <jepler> zultron: doesn't ring a bell with me, or with google :-/
[15:13:48] <zultron> Thanks, jepler. mhaberler set me straight; I was doing something I shouldn't have been.
[15:15:48] <jepler> I won't worry about it any further
[16:17:48] <mhaberler> jepler: this is the state of affairs with RT fault handling:
http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=shortlog;h=refs/heads/ub-rtfault-handling
[16:18:21] <mhaberler> all RT faults are funneled through a single exception handler in RTAPI, and that can be redirected
[16:18:52] <mhaberler> rtmon.comp is a HALcomp which bends the exception handler onto itself and hence can implement policy how to deal with faults
[16:19:16] <mhaberler> (unpolished, but works )
[16:52:08] <cradek> Kenneth_Lerman: do you think this is something?
http://sourceforge.net/p/emc/bugs/315/
[16:56:45] <cradek> Kenneth_Lerman: trying the first block, I do get the error, and I can't spot anything wrong with it when reading the docs
[16:57:43] <Kenneth_Lerman> It may be something. Unforch, I haven't played with this is a few years. I don't have a working recent configuration.
[16:57:58] <cradek> can I do anything to help you get set up again?
[16:59:07] <andypugh> I think Nick is the gcodetools guy, so he has probably looked at the easy answers..
[16:59:46] <Kenneth_Lerman> Have you tried it and seen it fail? I'd be interested in knowing which line is sees the error in. And what illegal character it is seeing.
[17:01:47] <Kenneth_Lerman> Is this the entire file that is being read? Does it occur when run right after the program is started? (Or might there be some lingering incorrect context)|
[17:03:41] <Kenneth_Lerman> Are there two bugs in this one fragment? Is he saying that taking out either the break or the return fixes things completely?
[17:03:43] <cradek> it errors for me as AXIS loads it and runs it to generate the preview, on a new linuxcnc startup
[17:04:10] <cradek> I typed the program myself so I know it's not got nonascii garbage in it (that tripped up someone recently)
[17:04:52] <cradek> 'o124 break' is the implicated line, but of course those can be off by 1
[17:04:52] <Kenneth_Lerman> Has anyone tried this test on an old version? (Does it fail on just newer releases?)
[17:05:21] <cradek> I don't know that
[17:05:34] <cradek> and I haven't tried the second block at all
[17:06:31] <cradek> I'm going to build v2.5_branch
[17:11:21] <cradek> in 2.5 branch I do not get an error, so perhaps someone has broken it in master
[17:12:57] <cradek> it should be possible to bisect it
[17:13:04] <cradek> but not on this very slow computer...
[17:15:27] <Kenneth_Lerman> As far as the second bug is concerned, that might be a feature rather than a bug. :-{ My recollection is that the code for O words does a static evaluation of subroutine definitions. That means that after iit hits the O<multipass> SUB, it is no longer executing code. For that reason, #<sub> = #1 won't be evaluated. And therefore, it is undefined. Defining it somewhere that is executed, will...
[17:15:28] <Kenneth_Lerman> ...leave it defined, and we won't get the error.
[17:16:02] <cradek> it's unfortunate there are two reports combined into one
[17:18:54] <cradek> Bisecting: 648 revisions left to test after this (roughly 9 steps)
[17:18:55] <cradek> (sigh)
[17:19:33] <Kenneth_Lerman> Yes, it would be nice to be able to just stamp them reject and tell them to resubmit. We have an answer for the second one, though. The documentation should be changed to clarify (1) how it works and (2) what is being done won't work requires that the variable be predefine. On the other hand, it might be fixable by skipping the error generation for this case.
[17:20:15] <cradek> with persistence here I should be able to find the breakage for the first block in the report
[17:21:21] <Kenneth_Lerman> It might be faster to manually bisect this. Most of the 648 do not relate to the interpreter. If you can determine which ones do, you can pick your bisection points to be in the middle of those changes. That might cut your bisections in half.
[17:22:57] <cradek> also there's a way to tell git that only changes in certain directories count
[17:23:07] <cradek> I'll go to a faster machine AND do that
[17:26:19] <mhaberler> Hi Ken - good to see you out in IRC land!
[17:32:00] <Kenneth_Lerman> I'm not usually here. I returned from our summer place in Otis, MA, connected my laptop, and happened to see cradek's note. My status (as shown on my computer) is "away". I don't know why "chatzilla" doesn't show that (or how it would appear on irc).
[17:33:07] <Kenneth_Lerman> I had a chat with Stuart about five axis tool compensation and have been thinking about it.
[17:33:33] <Kenneth_Lerman> I think it is easy if you consider it to be five axis tool *wear* compensation.
[17:33:56] <cradek> you mean assume small "diameters"?
[17:34:23] <cradek> that sure makes you less likely to have invalid/degenerate paths
[17:34:27] <Kenneth_Lerman> That is, you create the path for a nominal tool and can only enter the difference (a negative number) into the tool table.
[17:34:46] <Kenneth_Lerman> That means you will never have invalid paths.
[17:36:19] <cradek> I'm quite sure you're not right about "never"
[17:36:24] <cradek> less likely to
[17:36:45] <cradek> negative just means swap left/right, nothing more, it's no kind of magic bullet
[17:37:18] <Kenneth_Lerman> So, if you have a radius wear of .005, you offset the tool .005 in the direction perpendicular to the motion of the tool (and to the axis of the tool). It is a magic bullet because the tool can always fit in the radius (since it is smaller).
[17:37:52] <Kenneth_Lerman> For tool length compensation, you just offset the tool along its axis (that one is easy).
[17:37:55] <cradek> you'll still fail cutting inside on your .001 inch radius arc
[17:39:16] <cradek> well that would have failed without the compensation
[17:39:21] <cradek> I need to think harder
[17:39:43] <cradek> er no, it wouldn't have
[17:39:44] <Kenneth_Lerman> Sorry, I should have been more clear. This would be a *new* mode called cutter wear compensation. All it would do would be to offset the tool by the appropriate amount. For arcs, it would move in or out depending on the left or right side and direction of the arc.
[17:40:06] <cradek> I don't see how that's different?
[17:42:37] <cradek> argh these bisect targets don't build
[17:42:43] <cradek> it's maddening
[17:45:29] <Kenneth_Lerman> The difference is that the user (Stuart in particular) knows what will happen and doesn't care. I think the calculation is pretty simple. Before, we had to worry about the tool fitting in the corner. Stuart just wants us to follow the specified path, but just shift over a little to correct for the worn tool. He knows that when he specifies four corners of a pocket by moving in four straight...
[17:45:31] <Kenneth_Lerman> ...lines he will get rounded corners. We will adjust things so that the pocket is the same size -- except that the corner radii are .005 smaller (in my example). He's OK with that. (That's my understanding) If he wanted to specify an exact radius, he could program the arcs, and so long as the cutter was smaller than specified, he would get the right shape.
[17:47:34] <cradek> I've heard him say that before ("just move the tool over!") but I don't see how you can avoid the concave corner problem by just waving your hands
[17:49:02] <Kenneth_Lerman> Well, you know the tool will fit into the desired shape because a larger tool fit into that shape.
[17:49:49] <cradek> maybe we are not talking about the same thing at all
[17:50:30] <cradek> you still have to analyze the moves and calculate new endpoints at every corner, right?
[17:50:30] <Kenneth_Lerman> That's why *I* specify tool *wear* compensation. A tool can't wear to a larger size. (That's NOT true. The radius of a lathe tool can get larger as the point wears.)
[17:51:37] <cradek> to me, -.005 right is exactly the same as +.005 left; maybe I'm missing something conceptually
[17:52:28] <Kenneth_Lerman> Yes. At every change of motion. On a straight move: add the wear to the length of the move, if following on the right side- move the target tool position to the right by the wear amount.
[17:53:30] <cradek> I don't follow that at all
[17:53:31] <Kenneth_Lerman> Nope -- the length of the move amount is wrong. It depend, I think, on the angle of the next move.
[17:53:45] <cradek> sure it does
[17:54:02] <cradek> it might make an inside or outside corner
[17:55:06] <cradek> this is exactly what cutter comp already does
[17:56:01] <skunkworks> after a couple of false starts - that seemed to work
[17:57:19] <cradek> if the corner is concave you have to stop short, if it's convex you have to go around (or past) it
[17:57:47] <cradek> fwiw, stuart thinks going past (make a longer pointy corner) instead of around (make an arc) simplifies it - I don't agree
[18:00:31] <Kenneth_Lerman> Stuart is talking about having the path specified with small negative changes in tool diameter. You are correct that the general problem where the edge is specified and we must offset around the outside is not easy. Postscript tackled this problem with lots of special cases and parameter that determine how "pointy" a very sharp edge might me.
[18:01:49] <cradek> I still don't understand why negative tool diameter means anything special. SMALL tool diameter helps you not fail to find the new path but negative doesn't help as far as I can see
[18:02:29] <cradek> yes I've seen postscript can give you a fillet instead of a super pointy corner - that'd be a lousy answer in cutter comp
[18:04:25] <cradek> I'm failing to bisect this. I can't find a nearby ref that even builds.
[18:05:13] <andypugh> That seems strange.
[18:05:52] <cradek> current failure is e200945b4b9b11c2406268ad23a186a08df8b668
[18:06:02] <cradek> it contains merge conflict markers
[18:06:12] <cradek> and the log message contains "mopup"
[18:06:21] <Kenneth_Lerman> One of the docs on tool diameter compensation discusses two ways in which it might be used. In the first, the *part* is described by the motion (as if the tool diameter were zero) and the compensation creates the part by offsetting... appropriately. In the second, the *path* is specified for a nominal tool and the compensation adjusts the path so that the correct part is created. I think...
[18:06:23] <Kenneth_Lerman> ...Stuart is talking about the second case. It's my (perhaps naive) claim that so long as the tool diameter is smaller than the one for the calculated path, we cannot have gouging problems. Furthermore, it should be pretty straightforward to compute the path.
[18:06:52] <cradek> I understand the two use cases and I assert that the code to accomplish them is exactly the same
[18:07:04] <cradek> and they have exactly the same problems
[18:07:05] <zultron> cradek, maybe follow the instructions and mop it up? >:D
[18:07:24] <zultron> Sorry, not constructive.
[18:07:31] <cradek> the only benefit is in having smaller offsets in #2 - you're less likely to become degenerate
[18:08:44] <cradek> zultron: bad vc hygeine in the past is a gift that keeps giving :-(
[18:08:49] <andypugh> Stuart was discussing "East Coast" v "West Coast" in this context. Being from neither coast, I saw them as "right" and "wrong".
[18:09:50] <Kenneth_Lerman> My understanding of the degenerate cases is that line segments disappear because the tool becomes larger and that causes a segment to be swamped out of the path (I know that doesn't mean anything concrete).
[18:09:59] <cradek> yes
[18:10:40] <cradek> well not because the tool becomes larger -- it's that the path is moved
[18:10:52] <Kenneth_Lerman> In the case of a smaller tool, I don't think that occurs (of course, what seems obvious isn't always true).
[18:10:54] <cradek> whether you're moving the path + or - doesn't matter
[18:11:22] <andypugh> Do the "gouging" errors inidcate that the tool path generator can't solve the path, rather than it being a very annnoying attempt to save us from ourselves?
[18:11:34] <cradek> that is not true. you're thinking of the tool getting smaller when you should be thinking of moving the given path left or right
[18:12:46] <cradek> mhaberler: I think it's likely that this bug 315 is caused by your interp changes, but I'm utterly failing to bisect it because many of the commits don't compile
[18:14:21] <mhaberler> what makes you think so?
[18:14:53] <cradek> they are sweeping changes, and there have been no other sweeping changes since v2.5_branch
[18:15:33] <mhaberler> anything more exact than that ;-?
[18:15:34] <cradek> my bisect is failing because there is a large number of adjacent commits that are uncompileable because they contain merge conflict markers
[18:16:09] <mhaberler> which one you tried, the first or the second?
[18:16:12] <cradek> no sorry, I would have the exact commit by now if not for the poor vc hygeine
[18:16:19] <cradek> still on the first
[18:17:26] <cradek> maybe this will save you a little time:
http://timeguy.com/cradek-files/emc/315.ngc
[18:18:10] <cradek> in v2.5_branch I get the "breaking" comment; in master it fails to load
[18:18:30] <Kenneth_Lerman> cradek: I think I've made an example that shows you are correct in that you still get degenerate segments. :-( On the other hand, Stuart would say that is his problem. Just compute the points and the moves one at a time and execute them. If there are problems with the part, they are the programmer's problem.
[18:19:02] <cradek> Kenneth_Lerman: I agree he says things like that, but I don't buy it for a second
[18:19:19] <Kenneth_Lerman> because...
[18:19:21] <cradek> go ahead and have the control do something random and wrong - we'll notice it and work around it, don't worry
[18:19:39] <cradek> can't say that with a straight face
[18:20:06] <Kenneth_Lerman> Well, not really random. Actually, well defined (if nothing else read the code :-{ )
[18:20:38] <cradek> the current cutter comp code errors in the cases where it would make the tool cut into the part incorrectly
[18:20:54] <cradek> if you are saying that is not a necessary requirement I just disagree
[18:21:28] <cradek> I agree it's not random, that was unnecessarily hyperbolic of me
[18:22:01] <andypugh> Better hypoerbolic than hypergolic.
[18:22:21] <Kenneth_Lerman> I think Stuart would disagree in that he would say that your definition and his (of incorrectly) are different. (I know you knew that -- my comment was unnecessarily snarky).
[18:22:46] <cradek> heh
[18:22:50] <andypugh> Talking of hypergolic, this amused me:
http://www.tor.com/stories/2012/07/a-tall-tail
[18:23:28] <andypugh> "what's the worst possible rocket fuel, and what would be the worts possible oxidiser to go with it"
[18:24:17] <Kenneth_Lerman> Should we let the user (or perhaps the integrator) make the choice, though? I'd certainly "trust" Stuart to be responsible for the consequences of his actions. (Although I don't know about the average user.)
[18:24:29] <cradek> Kenneth_Lerman: I just think he's not thought it through, that's all.
[18:24:48] <cradek> I think that's sorta the wrong question.
[18:25:15] <andypugh> I came in late. What prevents you from using the current tool compensation the way described?
[18:25:38] <Kenneth_Lerman> Well, the real question is can we make it do what he really needs?
[18:26:00] <cradek> I've heard similar thoughts about the ijk that you can easily misspecify (mismatched radii). Why not let me set the tolerance to 10 inches and let the user avoid the error? because it will do a wrong thing. erroring is always better than doing a wrong thing.
[18:26:09] <cradek> ... ijk arcs
[18:26:52] <Kenneth_Lerman> The current tool compensation fails (and doesn't continue) if it detects that the cutter won't fit in the corner it is trying to cut. Some users just say that it should just do what you said -- even if that isn't what you meant.
[18:27:03] <cradek> I'm not a fan of "making it an option" as a way of avoiding the work of doing it right
[18:27:23] <cradek> if that's the problem you're trying to fix, then you should make it handle the removal of degenerate moves
[18:27:56] <Kenneth_Lerman> Is this a case where we can do it right? I should have guessed that you would say that.
[18:28:28] <cradek> a user who changed an offset and then got a ruined part is NEVER going to say "serves me right! At least it didn't error and tell me it was impossible!", I think that's just fiction
[18:29:03] <cradek> if you're talking about degenerate moves, sure you could handle them, but it's complicated
[18:29:09] <Kenneth_Lerman> OK. I need to think about how to detect and remove degenerate moves.
[18:29:22] <cradek> ok that's a goal that makes sense to me :-)
[18:29:49] <cradek> this has nothing to do with 5 axis now though, right?
[18:30:46] <Kenneth_Lerman> Well, I'm not sure I making it a goal yet. But I do want to understand it better. You are correct in that the number of axes doesn't really matter once you hit the magic number two.
[18:30:50] <cradek> (I should say: you can probably come up with the right thing to do about certain degenerate moves in certain cases)
[18:31:22] <cradek> we sorely need shared pencil and paper to talk about this in a reasonable way :-/
[18:32:27] <Kenneth_Lerman> degenerate moves makes me think of the pervert going after the underage girl. I'm outta here to get some dinner. Thanks for chatting.
[18:32:36] <cradek> also, if you are considering writing a new comp algorithm I suggest making it possible to be at a level outside the interpreter
[18:32:40] <Tom_itx> whiteboard
[18:33:17] <cradek> there are architecture problems that could possibly be solved by doing that separation
[18:33:35] <cradek> we should chat more about it, and you're welcome for, uh, raining on things
[18:47:48] <KGB-linuxcnc> 03dgarrett 05master eb06ff3 06linuxcnc 10(17 files in 6 dirs) * pyngcgui: more fixes for package builds
[18:49:08] <cradek> dgarr: thanks for working on that
[18:50:16] <cradek> oh how I love the buildbot
[19:43:48] <mhaberler> cradek: if you disable lines 797..802 of b11704e8 (Chris Radek 2012-02-02 15:15:01 -0600 797) 315.ngc passes
[19:44:19] <mhaberler> interp_read.c - the trailing expression issue on skipped oword
[20:37:49] <dgarr> cradek: my first tests of the debs for lucid and precise are ok -- thanks
[21:03:10] <skunkworks> jepler: cradek: the reset worked. (all I had to do was setp the pin high - and the pin toggled on for a the time specified by reset every base period.) pretty cool stuff.
[21:03:35] <skunkworks> inverting that created the latch at the time needed.
[21:04:35] <skunkworks> all I can say is the performace of those drives and steppers are pretty bad. the artical says that you will probably not get much more than 20ish ipm out of them and they are right.
[21:05:11] <skunkworks> plus there seems to be a funny interaction when you run 2 axis at once. they get noiser. I don't think they are missing steps - but buy does it sound crappy.
[21:06:51] <skunkworks> the original control must have done phase drive of some kind. I got a little hung up trying to get it to work as I forgot to set a switch to on which sets the driver in step/dir mode. I was flipping most of the data bits on the printer port and the steppers would clunk.
[21:07:41] <skunkworks> So for grins I might try to figure out what the patter is - most likely just 4 phase drive.. and see for grins if that works better. wth
[21:11:11] <skunkworks> (that is what goes from the interface to the drive board - abcd.
[21:11:18] <skunkworks> for each axiis
[21:13:18] <skunkworks> 72 steps per rev steppers with 10.something tpi ball screws. half stepped
[21:16:44] <jepler> skunkworks: you got it to move? great
[21:17:15] <jepler> too bad it doesn't work very well though
[21:21:37] <skunkworks> eh - it was kinda expected..
[21:21:46] <skunkworks> it would be usable as is - just slow.
[22:06:57] <KGB-linuxcnc> 03elson 05v2.5_branch ad2a8b7 06linuxcnc 10src/hal/drivers/hal_ppmc.c * add encoder filter clock selection parameter to loadrt command line
[22:06:57] <KGB-linuxcnc> 03elson 05v2.5_branch 241586a 06linuxcnc
[22:06:57] <KGB-linuxcnc> Merge branch 'v2.5_branch' of ssh://jmelson@git.linuxcnc.org/git/emc2 into v2.5_branch