steves_logging is now known as 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
block delete can be applied to _any_ code
so there are no such things as non-deleteable
OK, I am reading Haas documentation instead of EMC docs. Haas prefixes deleteable code with a / character, so it is easily identifable.
Is any code in EMC deleteable? If so it would seem that a pause must precede the decision point.
I think you can put the optional block delete character on any line
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*?)
and if you want to skip a whole block of code, you need to put it on every line in that block
OK, EMC uses the same / flag character.
so for the mazak motor mount case, we'de have dozens of line of normally queueable code that would be marked, and thus unqueuable
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
(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...)
yeah, it already clear that you can't possibly do a preview properly
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.
The transition could still be used to flush the queue.
I wasn't thinking in terms of transitions
I suppose that could work
OK, but that is what I proposed.
I still think block delete should be deprecated
in favor of O-word IF
It would seem that such decision points would not be part of any code that needs to execute without delay.
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.
the preview obviously can't be fixed
Deprecating internal code is one thing, deprecating a part of standard that has existed for decades is another.
however queuing makes changing the state of the delete input during a program run a very iffy thing regardless of the preview
steve_stallings: perhaps deprecated is the wrong word
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 /
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.
no constraint in the docs doesn't mean it won't do wild and crazy things in practice
suppose you have a string of 0.001" long moves, all with / in front of them
True, but Haas is pretty good about covering their ass on such issues.
and you flip the switch in the middle - there is no way to know exactly which ones will or won't be executed
That is why I proposed evaluating the switch only on a non-deleteable to deleteable transition. Admittedly this is my own invention.
evaluating on a transition, or flushing the queue on the transition?
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.
Evaluate on transition, flush if change detected.
that won't work
the interpreter can be seconds or minutes ahead of the cutter
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
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
How does the intrepter handle flushing when it encounters M codes?
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
M codes (and many other tnings) aren't queued
OK, so the transition forces a flush, then evaluates the swithc.
There is a distinction between flushing and not queueing?
related cvs activity here: http://cvs.linuxcnc.org/cvs/emc2/src/emc/canterp/canterp.cc?rev=1.14
steve_stallings: no, I think that people use terminology inconsistently
"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
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?
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.
I am of course ignoring the implications for preview.
the only problem I see with that is that you can't get good contouring in code prefixed with a "/"
well, and that somebody has to write it, test it, and check it in
branching using o-words based on run-time values also messes up the preview - that is just a fact of life
jepler: steve is only proposing allowing the queue to drain at the beginning of a series of lines with /
jmkasunich: ah, I missed that
so if you have 1000 lines in a row, all with /, the queue would drain at the first one
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.
and I think the input would also be tested only at the first one
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"
so checking at transitions between / and non-/ code is a good idea IMO
is queueable a word?
then it must be in the running for most consecutive vowels
queueing has the same length run, but a higher vowel:consonant ratio
in case anyone was wondering
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?
SWPadnos: not true
queueing = 3 cons, 5 vowels, queueable = 3 cons, 6 vowels
3/8 > 3/9
err - or the inverse
or converse or something
KimK_ I've done similar, using M60 and IF to skip spring passes
you said higher vowel:cons ratio
5/3 is not higher than 6/3
yeah - I missed the fact that there's an extra e at the end :)
yes, 'queueing' is the most vowely word in /usr/share/dict/words; other words may be tied, though
if 'vowely' is defined as count of consecutive vowels
only jepler would actually check it
only jepler would be _able_ to check it in less than one hour
I wonder if he'll publish the python program that did it ;)
jmkasunich: I'm not familiar with M60 & IF. Is this an EMC2 only feature, or does another control offer that?
IF (and other conditional, looping, and subroutine features) are emc only
all lumped under "O-words"
M60 lets you read the state of an external input, and may exist in some other controls
If you allow "...and sometimes Y...", how about syzygy?
they're not consecutive
the z splits the vowel run
KimK_: it doesn't have many consecutive vowels though
as does the g
that would qualify for something though, since it only has sometimes vowels
"most orthogonal use of questionable vowels"
"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.
its the only word I know of that has no "traditional" vowels
had to be one ;)
enjoy your argument over block delete
I think I'm done arguing
just remember that the one with the most stubborn argument has to implement it
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.
I still hate it, and I won't use it, but I think steve_stallings suggestion is an improvement on what is there now
oh good. then Steve gets to implement it :)
the other Steve
Can I use .NET and Basic?
if you write all the interface libraries, I suppose you could
but it may be harder than learning C ;)
just use C-pound
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.
it's OK. we can reverse any commits you make
CVS protects us from ourselves :)
steve_stallings is now known as steves_logging
jmkasunich, note that he's running 2.1.0 - waaaay out of date
I was just wondering that.
I don't know exactly what's changed, but wasn't there a hell of a lot of work done on spindle synch?
thats true - do you want to say something about that or should I?
I'm headed for bed, otherwise I'd check the CVS logs to see what's changed
so I guess you should :)
jmkasunich: on another note, I threaded a bunch tonight on trunk, and it seems to work much better on my machine
that has the accel fix?
yes, the one with the assumption we both dislike
I knew it would work better, as long as you don't violate the assumption
the results seem good but it was internal so I can't get a real great look at it.
am I missing something obvious or is measuring internal PD almost impossible?
thats what go/no-go gages are for
seems like with three balls the size of the thread wires and an internal caliper or mic that has flats...
bah, really? is that the only way people do it?
I dunno - I suspect a lot of work is gaged instead of measured
that sure is easy if you have the equipment.
377 lines in debian/changelog between 2.1.0 and now.....
I wouldn't trust any of our x.x.0 releases :-)
G76 was brand new in 2.1.0
G76 is so cool
* cradek pats /me on the back
it is nice
I recently coded a loop with G33 tho
cause I wanted to be able to measure, then say "take one more pass", without running the entire multi-pass cycle again
I've now done tapered start/end and internal with g76, features I wrote but never tried
ah, I've wished for something like that, hmm.
I've recently used G76 with the tool upside down behind the work to cut an external thread
so still with M3
the M4 problem bugs me even though I've never needed it :-)
my spindle won
won't reverse until I get a three phase motor on the machine
so don't look to me to be worried about M4 threading in the near future
why did you put the tool on the back that time?
cause I had a turning/facing tool in the front on the regular toolpose
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
or even use the same tool
you have to know where the point is tho
true, that's much easier
why would you not know where the point is?
I have a way of neglecting that for threading tools
a way, as in a workaround, or as in a habit?
well both - I assume it has a sharp point, and tweak the offset until the PD is right
so I think that means the controlled point ends up where the sharp point of the tool would be
because who cares what the radius actually is
nobody, until you try to cut an OD with the end of the tool
I usually touch off with the point, assume its sharp, and then adjust the G76 till I get the right PD
so I could actually cut with the tip
there ought to be a right number for the g76 i,j,k
ideally you could cut any thread without messing with anything
I lied a bit - if I assumed a sharp V, I'd cut too deep on the first pass
I struggled to figure out the right numbers for my thread tonight
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
just use a fishtail gauge?
a calibrated one
sounds finicky though
also, there are pitch-dependent factors involved
not if you make the controlled point the point where the sharp tip would be
I was just thinking that
well the pitch-dependent stuff is in your g76 line then
yeah, but that is fine
PD is a function of pitch anyway
yeah you only have to figure it out once.
you look that up in MH
also the distance from sharp tip to pitch line is a constant times the pitch
probably sqrt(3)/4 or something like that
(it's a bit too bad that g76 doesn't take these numbers more directly)
I know what I meant anyway
I like it that G76 does what you tell it to do and doesn't do any fancy math
in my happy place I could cut a correct thread with g76, instead of a book, a calculator, and g76
(... and four tries)
the chinese cemented carbide internal threading tools I bought aren't anywhere near 60 degrees
some of that cheap stuff is fine, others are just useless
I wish I could know before ordering it
order a diamond hone
regarding correct threads - you'll always need a book
if I'm doing a thread that matters, I use MH, to get not just the nominal but the tolerance limits, for PD, etc
you can't embed that into M76, and shouldn't try
yeah that's surely true
it might be nicer if i,k were radii instead of offsets
(also it's a constant pain that MH is diameters and G76 etc are radius)
but I'm not about to open that can of wax
I don't like the radii idea at all
it's "too late" to change it anyway
time for dog walk and sleep - goodnight
KimK_IA_AFK is now known as KimK_IA
KimK_IA is now known as KimK_IA_AFK
EMC: 03tissf 07TRUNK * 10emc2/docs/src/examples/gcode_fr.lyx: french translation update
EMC: 03tissf 07TRUNK * 10emc2/docs/src/gui/axis_fr.lyx: french translation update
[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.
EMC: 03jepler 07v2_2_branch * 10emc2/debian/changelog: not new fix
I was wondering what the old fix was
Guest954 is now known as skunkworks__
skunkworks__ is now known as skunkworks