Back
[00:30:00] <steves_logging> steves_logging is now known as steve_stallings
[00:32:13] <steve_stallings> thinking out loud here... are there not provisions for queue flushing when the interpreter encounters M codes or other items that are not real time? well it would seem that a transition from non-deleteable code to code that can be deleted could also flush the queue
[01:06:31] <jmkasunich> block delete can be applied to _any_ code
[01:06:49] <jmkasunich> so there are no such things as non-deleteable
[01:10:50] <steve_stallings> OK, I am reading Haas documentation instead of EMC docs. Haas prefixes deleteable code with a / character, so it is easily identifable.
[01:12:52] <steve_stallings> Is any code in EMC deleteable? If so it would seem that a pause must precede the decision point.
[01:18:31] <jmkasunich> I think you can put the optional block delete character on any line
[01:18:44] <jepler> I suspect that (A) the documentation says that *any* line may have the block delete character but (B) it doesn't work for O-words at all (and what would it *mean*?)
[01:18:48] <jmkasunich> and if you want to skip a whole block of code, you need to put it on every line in that block
[01:19:54] <steve_stallings> OK, EMC uses the same / flag character.
[01:20:11] <jmkasunich> so for the mazak motor mount case, we'de have dozens of line of normally queueable code that would be marked, and thus unqueuable
[01:20:27] <jepler> but it's accepted on (say) a G10 L2 line to set coordinate system offsets; a G91 line to set incremental distance mode; a G41 line to set tool radius compensation
[01:20:59] <jepler> (since I think about this from the direction of generating an accurate preview, these cases (which can totally change the preview) are what leap to mind...)
[01:21:02] <jmkasunich> yeah, it already clear that you can't possibly do a preview properly
[01:21:52] <steve_stallings> Yes, everything to be skipped needs the flag character. This still allows for accurate detection of a transition from a line that has no / and a following line that does have a prefixed / character.
[01:22:14] <steve_stallings> The transition could still be used to flush the queue.
[01:22:42] <jmkasunich> I wasn't thinking in terms of transitions
[01:22:50] <jmkasunich> I suppose that could work
[01:22:56] <steve_stallings> OK, but that is what I proposed.
[01:23:14] <jmkasunich> I still think block delete should be deprecated
[01:23:23] <jmkasunich> in favor of O-word IF
[01:23:38] <steve_stallings> It would seem that such decision points would not be part of any code that needs to execute without delay.
[01:24:18] <jepler> when I glanced at the channel earlier this morning I thought it was only a question of the axis preview not updating when the BD switch is activated halfway through a program run. that's simply a matter of documenting the actual behavior, because it can't be reasonably fixed.
[01:24:55] <jmkasunich> the preview obviously can't be fixed
[01:25:01] <steve_stallings> Deprecating internal code is one thing, deprecating a part of standard that has existed for decades is another.
[01:25:25] <jmkasunich> however queuing makes changing the state of the delete input during a program run a very iffy thing regardless of the preview
[01:25:42] <jmkasunich> steve_stallings: perhaps deprecated is the wrong word
[01:26:24] <jmkasunich> I'm thinking more like - discourage its use, point out that M60 input followed by IF can do the same thing only better, and don't waste time trying to fix the fundamental flaws in /
[01:28:34] <steve_stallings> The EMC docs do state that the Delete function should be set before the run starts. I can find no similar constraint in the Haas documentation.
[01:29:13] <jmkasunich> no constraint in the docs doesn't mean it won't do wild and crazy things in practice
[01:29:34] <jmkasunich> suppose you have a string of 0.001" long moves, all with / in front of them
[01:29:40] <steve_stallings> True, but Haas is pretty good about covering their ass on such issues.
[01:29:57] <jmkasunich> and you flip the switch in the middle - there is no way to know exactly which ones will or won't be executed
[01:30:45] <steve_stallings> That is why I proposed evaluating the switch only on a non-deleteable to deleteable transition. Admittedly this is my own invention.
[01:31:13] <jmkasunich> evaluating on a transition, or flushing the queue on the transition?
[01:31:28] <KimK_> Recently I used Block Delete on a Fanuc, and as long as I flipped it just before it executed the "slashed" lines, it was OK.
[01:32:12] <steve_stallings> Evaluate on transition, flush if change detected.
[01:32:27] <jmkasunich> that won't work
[01:32:43] <jmkasunich> the interpreter can be seconds or minutes ahead of the cutter
[01:32:44] <jepler> here's one time in the past that this came up, I can't spot whether any solutions were arrived at:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2006-11-19.txt
[01:33:07] <jepler> I have a vague recollection that alex did "something" along the lines of what cradek suggested then, but emc doesn't actually behave that way now: 22:02:37 <cradek> I think you "just" have to not queue past any line that starts a block that might be deleted
[01:33:19] <steve_stallings> How does the intrepter handle flushing when it encounters M codes?
[01:33:24] <jmkasunich> if you want the switch to be read right before a slashed cut starts, you must stop the interpreter until the motion controller finishes the move prior to the slashed one
[01:33:56] <jmkasunich> M codes (and many other tnings) aren't queued
[01:34:03] <steve_stallings> OK, so the transition forces a flush, then evaluates the swithc.
[01:34:36] <steve_stallings> There is a distinction between flushing and not queueing?
[01:34:46] <jepler> related cvs activity here:
http://cvs.linuxcnc.org/cvs/emc2/src/emc/canterp/canterp.cc?rev=1.14
[01:34:59] <jepler> steve_stallings: no, I think that people use terminology inconsistently
[01:35:26] <jepler> "flush" would imply throwing stuff away, but I think in all cases we're talking about allowing the queue to drain, then evaluating the external condition, then acting on it
[01:37:00] <steve_stallings> So, if I understand, encountering an M code causes the interpreter to stop queueing things until the queue is empty, then act on the M code, then resume queing?
[01:37:25] <jepler> yes
[01:38:20] <steve_stallings> Then my proposal was to act in a similar fashion when the current G code line is prefixed with a / and the previous one was not.
[01:39:40] <jepler> right
[01:39:41] <steve_stallings> I am of course ignoring the implications for preview.
[01:39:44] <jepler> right
[01:40:08] <jepler> the only problem I see with that is that you can't get good contouring in code prefixed with a "/"
[01:40:15] <jepler> well, and that somebody has to write it, test it, and check it in
[01:40:25] <jmkasunich> branching using o-words based on run-time values also messes up the preview - that is just a fact of life
[01:40:57] <jmkasunich> jepler: steve is only proposing allowing the queue to drain at the beginning of a series of lines with /
[01:41:19] <jepler> jmkasunich: ah, I missed that
[01:41:25] <jmkasunich> so if you have 1000 lines in a row, all with /, the queue would drain at the first one
[01:41:30] <steve_stallings> I think code that is written with blocks marked with a / would be highly unlikely to assume smoothe contouring during a transition from non-deleteable to deleteable code.
[01:41:33] <jmkasunich> and I think the input would also be tested only at the first one
[01:42:16] <steve_stallings> correct
[01:43:05] <SWPadnos> it seems unlikely that someone would use optional delete to intentionally change the shape of something - I'd expect it to be used to eliminate entire operations or "maintenance items"
[01:43:32] <SWPadnos> so checking at transitions between / and non-/ code is a good idea IMO
[01:45:07] <jmkasunich> is queueable a word?
[01:45:23] <SWPadnos> sure :)
[01:45:37] <jmkasunich> then it must be in the running for most consecutive vowels
[01:45:47] <SWPadnos> heh
[01:46:20] <SWPadnos> queueing has the same length run, but a higher vowel:consonant ratio
[01:46:41] <SWPadnos> in case anyone was wondering
[01:46:44] <KimK_> Changing the shape? I used Block Delete last to allow some spring passes if I was done deepening a groove (otherwise keep deepening), does that count?
[01:46:51] <jmkasunich> SWPadnos: not true
[01:47:12] <jmkasunich> queueing = 3 cons, 5 vowels, queueable = 3 cons, 6 vowels
[01:47:28] <SWPadnos> 3/8 > 3/9
[01:47:46] <SWPadnos> err - or the inverse
[01:47:50] <SWPadnos> or converse or something
[01:47:51] <jmkasunich> KimK_ I've done similar, using M60 and IF to skip spring passes
[01:48:05] <jmkasunich> you said higher vowel:cons ratio
[01:48:17] <jmkasunich> 5/3 is not higher than 6/3
[01:48:30] <SWPadnos> yeah - I missed the fact that there's an extra e at the end :)
[01:48:49] <jepler> yes, 'queueing' is the most vowely word in /usr/share/dict/words; other words may be tied, though
[01:48:57] <jepler> if 'vowely' is defined as count of consecutive vowels
[01:49:14] <jmkasunich> only jepler would actually check it
[01:49:26] <jmkasunich> only jepler would be _able_ to check it in less than one hour
[01:49:32] <SWPadnos> I wonder if he'll publish the python program that did it ;)
[01:49:34] <KimK_> jmkasunich: I'm not familiar with M60 & IF. Is this an EMC2 only feature, or does another control offer that?
[01:50:03] <jmkasunich> IF (and other conditional, looping, and subroutine features) are emc only
[01:50:11] <jmkasunich> all lumped under "O-words"
[01:50:28] <jmkasunich> M60 lets you read the state of an external input, and may exist in some other controls
[01:50:36] <KimK_> If you allow "...and sometimes Y...", how about syzygy?
[01:50:51] <jmkasunich> they're not consecutive
[01:50:51] <SWPadnos> the z splits the vowel run
[01:50:53] <jepler> KimK_: it doesn't have many consecutive vowels though
[01:50:56] <SWPadnos> as does the g
[01:51:05] <KimK_> Oh, OK
[01:51:25] <SWPadnos> that would qualify for something though, since it only has sometimes vowels
[01:51:37] <KimK_> Ha
[01:51:48] <SWPadnos> "most orthogonal use of questionable vowels"
[01:51:52] <jepler> "Io" has the highest vowel-run-ratio. I and a too, of course, but clearly you want to break ties by longer words. Au, Eu, and individual vowels all appear in my doctionary but I don't know what they mean.
[01:52:02] <jmkasunich> its the only word I know of that has no "traditional" vowels
[01:53:29] <jepler> SWPadnos:
http://pastebin.ca/1220370
[01:53:53] <SWPadnos> heh
[01:53:56] <SWPadnos> had to be one ;)
[01:54:29] <jepler> 'night all
[01:54:33] <jepler> enjoy your argument over block delete
[01:54:37] <SWPadnos> see you
[01:54:39] <jmkasunich> goodnight
[01:54:49] <jmkasunich> I think I'm done arguing
[01:54:52] <jepler> just remember that the one with the most stubborn argument has to implement it
[01:55:01] <SWPadnos> /argument
[01:55:06] <KimK_> I'll be curious to read the log on the rest of this later, but have to go now. Thanks to all for your hard work.
[01:55:12] <SWPadnos> see you
[01:55:12] <jmkasunich> I still hate it, and I won't use it, but I think steve_stallings suggestion is an improvement on what is there now
[01:55:27] <SWPadnos> oh good. then Steve gets to implement it :)
[01:55:34] <SWPadnos> the other Steve
[01:57:47] <steve_stallings> Can I use .NET and Basic?
[01:58:21] <SWPadnos> if you write all the interface libraries, I suppose you could
[01:58:27] <SWPadnos> but it may be harder than learning C ;)
[01:58:51] <jmkasunich> just use C-pound
[01:59:48] <steve_stallings> I have a few neurons that have been exposed to plain C, but letting me muck around in the intrepreter would be a disaster of vast scale.
[02:00:04] <SWPadnos> it's OK. we can reverse any commits you make
[02:00:26] <SWPadnos> CVS protects us from ourselves :)
[02:07:18] <steve_stallings> steve_stallings is now known as steves_logging
[02:36:17] <SWPadnos> jmkasunich, note that he's running 2.1.0 - waaaay out of date
[02:36:57] <skunkworks_> I was just wondering that.
[02:36:59] <SWPadnos> I don't know exactly what's changed, but wasn't there a hell of a lot of work done on spindle synch?
[02:41:11] <jmkasunich> thats true - do you want to say something about that or should I?
[02:42:06] <SWPadnos> I'm headed for bed, otherwise I'd check the CVS logs to see what's changed
[02:42:18] <SWPadnos> so I guess you should :)
[02:44:31] <cradek> jmkasunich: on another note, I threaded a bunch tonight on trunk, and it seems to work much better on my machine
[02:44:40] <jmkasunich> that has the accel fix?
[02:44:55] <cradek> yes, the one with the assumption we both dislike
[02:44:59] <jmkasunich> heh
[02:45:13] <jmkasunich> I knew it would work better, as long as you don't violate the assumption
[02:45:39] <cradek> the results seem good but it was internal so I can't get a real great look at it.
[02:46:25] <cradek> am I missing something obvious or is measuring internal PD almost impossible?
[02:46:57] <jmkasunich> thats what go/no-go gages are for
[02:47:03] <cradek> seems like with three balls the size of the thread wires and an internal caliper or mic that has flats...
[02:47:21] <cradek> bah, really? is that the only way people do it?
[02:47:47] <jmkasunich> I dunno - I suspect a lot of work is gaged instead of measured
[02:48:42] <cradek> that sure is easy if you have the equipment.
[02:49:09] <jmkasunich> 377 lines in debian/changelog between 2.1.0 and now.....
[02:49:53] <cradek> I wouldn't trust any of our x.x.0 releases :-)
[02:50:01] <jmkasunich> G76 was brand new in 2.1.0
[02:50:26] <cradek> G76 is so cool
[02:50:33] <cradek> * cradek pats /me on the back
[02:50:44] <jmkasunich> it is nice
[02:50:51] <jmkasunich> I recently coded a loop with G33 tho
[02:51:02] <cradek> why?
[02:51:12] <jmkasunich> cause I wanted to be able to measure, then say "take one more pass", without running the entire multi-pass cycle again
[02:51:31] <cradek> I've now done tapered start/end and internal with g76, features I wrote but never tried
[02:51:51] <cradek> ah, I've wished for something like that, hmm.
[02:51:56] <jmkasunich> I've recently used G76 with the tool upside down behind the work to cut an external thread
[02:52:45] <cradek> so still with M3
[02:53:01] <cradek> the M4 problem bugs me even though I've never needed it :-)
[02:54:20] <jmkasunich> my spindle won
[02:54:22] <jmkasunich> oops
[02:54:31] <jmkasunich> won't reverse until I get a three phase motor on the machine
[02:54:43] <jmkasunich> so don't look to me to be worried about M4 threading in the near future
[02:54:45] <cradek> heh
[02:54:56] <cradek> why did you put the tool on the back that time?
[02:55:29] <jmkasunich> cause I had a turning/facing tool in the front on the regular toolpose
[03:04:23] <cradek> a useful threading cycle would be like g76 but before the last spring pass with the threading tool, it would switch to a turning tool and graze the thread peaks
[03:04:40] <jmkasunich> or even use the same tool
[03:04:55] <jmkasunich> you have to know where the point is tho
[03:05:00] <cradek> true, that's much easier
[03:05:37] <cradek> why would you not know where the point is?
[03:05:44] <jmkasunich> end radius
[03:06:04] <cradek> oh, hm.
[03:06:25] <cradek> I have a way of neglecting that for threading tools
[03:07:52] <jmkasunich> a way, as in a workaround, or as in a habit?
[03:08:02] <cradek> habit
[03:08:30] <cradek> well both - I assume it has a sharp point, and tweak the offset until the PD is right
[03:08:52] <cradek> so I think that means the controlled point ends up where the sharp point of the tool would be
[03:09:05] <cradek> because who cares what the radius actually is
[03:09:30] <jmkasunich> nobody, until you try to cut an OD with the end of the tool
[03:09:36] <cradek> yes
[03:10:04] <jmkasunich> I usually touch off with the point, assume its sharp, and then adjust the G76 till I get the right PD
[03:10:16] <jmkasunich> so I could actually cut with the tip
[03:10:46] <cradek> there ought to be a right number for the g76 i,j,k
[03:11:06] <cradek> ideally you could cut any thread without messing with anything
[03:11:23] <jmkasunich> I lied a bit - if I assumed a sharp V, I'd cut too deep on the first pass
[03:11:51] <cradek> I struggled to figure out the right numbers for my thread tonight
[03:11:59] <jmkasunich> if you could "touch off" with something that touches the flanks of the tool instead of the tip, then you could do as you suggest
[03:12:27] <cradek> just use a fishtail gauge?
[03:12:45] <jmkasunich> a calibrated one
[03:12:48] <cradek> yep
[03:13:01] <cradek> sounds finicky though
[03:13:05] <jmkasunich> also, there are pitch-dependent factors involved
[03:13:28] <cradek> not if you make the controlled point the point where the sharp tip would be
[03:13:35] <jmkasunich> I was just thinking that
[03:13:39] <cradek> well the pitch-dependent stuff is in your g76 line then
[03:13:47] <jmkasunich> yeah, but that is fine
[03:13:54] <jmkasunich> PD is a function of pitch anyway
[03:13:55] <cradek> yeah you only have to figure it out once.
[03:14:00] <jmkasunich> you look that up in MH
[03:14:32] <jmkasunich> also the distance from sharp tip to pitch line is a constant times the pitch
[03:14:48] <jmkasunich> probably sqrt(3)/4 or something like that
[03:15:05] <cradek> (1/pitch)*sqrt(3)/4
[03:15:31] <cradek> I think
[03:15:49] <cradek> (it's a bit too bad that g76 doesn't take these numbers more directly)
[03:16:39] <jmkasunich> 1/tpi maybe
[03:16:45] <jmkasunich> not 1/pitch
[03:16:48] <cradek> yes 1/tpi
[03:16:55] <cradek> = lead
[03:17:04] <cradek> I know what I meant anyway
[03:17:55] <jmkasunich> I like it that G76 does what you tell it to do and doesn't do any fancy math
[03:18:38] <cradek> in my happy place I could cut a correct thread with g76, instead of a book, a calculator, and g76
[03:18:46] <cradek> (... and four tries)
[03:19:58] <cradek> the chinese cemented carbide internal threading tools I bought aren't anywhere near 60 degrees
[03:20:24] <cradek> some of that cheap stuff is fine, others are just useless
[03:20:35] <cradek> I wish I could know before ordering it
[03:20:54] <jmkasunich> yeah
[03:21:04] <jmkasunich> order a diamond hone
[03:21:15] <jmkasunich> regarding correct threads - you'll always need a book
[03:21:57] <jmkasunich> if I'm doing a thread that matters, I use MH, to get not just the nominal but the tolerance limits, for PD, etc
[03:22:20] <jmkasunich> you can't embed that into M76, and shouldn't try
[03:22:23] <jmkasunich> IMO
[03:22:31] <cradek> yeah that's surely true
[03:23:10] <cradek> it might be nicer if i,k were radii instead of offsets
[03:23:49] <cradek> (also it's a constant pain that MH is diameters and G76 etc are radius)
[03:24:27] <cradek> but I'm not about to open that can of wax
[03:24:31] <jmkasunich> good
[03:24:40] <jmkasunich> I don't like the radii idea at all
[03:25:10] <cradek> it's "too late" to change it anyway
[03:42:25] <jmkasunich> time for dog walk and sleep - goodnight
[10:16:44] <KimK_IA_AFK> KimK_IA_AFK is now known as KimK_IA
[11:16:08] <KimK_IA> KimK_IA is now known as KimK_IA_AFK
[13:03:56] <CIA-40> EMC: 03tissf 07TRUNK * 10emc2/docs/src/examples/gcode_fr.lyx: french translation update
[13:03:59] <CIA-40> EMC: 03tissf 07TRUNK * 10emc2/docs/src/gui/axis_fr.lyx: french translation update
[13:14:02] <christel> [Global Notice] Hi all, Apologies for taking you on a detour via Splitsville this morning, the issues were a result of late-scheduled maintenance at NERO. It should all be done now and we'll strive to ensure that we can give you advance warning next time! Thank you for using freenode and apologies for the inconvenience caused.
[15:31:32] <CIA-40> EMC: 03jepler 07v2_2_branch * 10emc2/debian/changelog: not new fix
[15:33:52] <jepler_> *note*
[15:33:53] <jepler_> sigh
[15:34:34] <SWPadnos> heh
[15:34:49] <SWPadnos> I was wondering what the old fix was
[17:26:21] <Guest954> Guest954 is now known as skunkworks__
[18:04:01] <skunkworks__> skunkworks__ is now known as skunkworks