mhaberler: wow, you've found how to assign accelerators!
it's definitly deserves it's place in FAQ
yes, it was some trial-and-error
took not to document.
more importantly: I think I just finally nailed the toolchanger hang problem
major queue safari ;-)
being caught barefooted by jepler has major motivational powers ;-)
psha: I would appreciate if you could review abort-toolchange in my repo
turn on DBEUG in ini to 0x7FFFFFFF to see it in action
I am fairly sure this one's good to go
and if I abort the toolchange with Escape, even the toolchange window goes aways ;-)
alex_joni: the emc.nml config was a non-issue - queuing works, I just dont know why ;-)
psha: I amended the abort-toolchange patch (minor touchup, nothing functional)
previous version looks fine
i'd rather split them into two patches pins and abort fix but it's ok in current state too
EMC: 03jthornton 07master * r1013c409d657 10/docs/src/gui/ (13 files in 2 dirs): add hal widgets and action widgets
EMC: 03jthornton 07master * rfd8aa3af511a 10/docs/src/gui/gladevcp.lyx: fix markup errors
opps didn't add the action widgets yet
man.. tracking us is like nailing a pudding on the wall.. I really appreciate it
btw is this stuff anywhere comprehensible? does intent and advantages come across?
the wiki pages at this point are more tutorial than reference manual
sometimes that is better :)
at this stage of the sales process, I agee ;-)
jt I just spotted a navigation sort of "problem" no obvious link from http://www.linuxcnc.org/docview/html/gcode_overview.html
are you able to functionally reproduce what we're doing? making sense yet?
archivist: the arrows in the upper right corner?
mhaberler: I've got a small start on it as time allows I'll build a complete panel
I know but you could add a menu item
jthornton, and any overview item could point to its own page for more details
I think thats why pingu next door is confused
I agree but I don't know how to change that and it is quite complicated
I think ping is confused
I dont think so, it looks like parental supervision required
EMC: 03jthornton 07master * r77cdd3037410 10/docs/src/common/machining_center.lyx: add parameters 5420-5428
write a feature and documentation magically falls from the sky!
actually from a cave
EMC: 03jthornton 07v2.4_branch * rfedcba70b7d5 10/docs/src/hal/rtcomps.lyx: add missing stepgen.n.enable pin
* jthornton heads to the shop
cradek: Here's why we needed a fixed toolchanger, and paramters to MDI widgets: http://www.youtube.com/watch?v=I0xycYiyn1M
I don't have speakers on this machine so I could only look at the video...
cradek: thanks for the #5420 ff changes
unfortunately this is only semi-useful in the probing scenario I described, because #5420 includes the offsets which are about to be warped by a G10 L20 on probe success
if I'd be a real PITA, I'd ask for '5430 ff - Current Position in machine actual and in the current program units for X, Y, Z, A, B, C, U, V & W' because these could be used with a G53 G0
but then I'm not a PITA, so I dont ask
JT-Shop: It's this ooostrian english which you know from the former Californian governor
I didnt hear I'll be back
'it's not a toooomer'
mhaberler: I've taken the liberty of cleaning up your patch a bit, and fixing one more scenario (F2 to go to machine off during tool change)
cradek: would you like to test this on your machine with a real toolchanger before I push it to origin/master?
so it worked for you?
can I see the changes?
yes, F1 and ESC during tool change with sim/axis worked fine, and so did F2 after the small additional fix
the prepare-related paths are untested since I use prepare loopback
did you test aborting with random tool changer?
I dont have any
mhaberler: so do I
any way to do this in sim?
cradek: indeed, I think there's a race condition which I describe in the commit message
it would potentially affect both random and nonrandom changers, though
.. or maybe that's not at all what you're wondering about
mhaberler: there's configs/sim/random_tc.ini so you can do testing of random toolchanger machines
cradek: random_tc behaves the same way as sim/axis as far as I can see
so if you abort, the pocket swap doesn't happen?
what was the issue with F2 and what's the purpose of the reordered emcIoAbort() in emctask.c?
it just deasserts tool-change if that was set, and tool-prepare if that was set
mhaberler: otherwise task times out waiting to send LUBE_OFF to io
cradek: yes, it looks that way. In simpockets.tbl I have T0 P0; no tool
T1M6 ESC to abort a toolchange
simpockets.tbl continues to have T0 P0 ;no tool
re race: maybe io should explicitely signal an abort by an extra pin
so there would be no ambiguity
question is when to deassert that
I'm not clear about how the handshake is supposed to work. I have my ladder leave the signal on for 1 second and hope io sees it in that time.
cradek: I doubt the actual requirement is documented
cradek: I think that the changer needs to assert -changed until it sees -change go false
jepler: I know we've talked at it before (and you tried to fix it at least once)
I dont think that can be resolved without OOB communication that the abort happenend
also a TC might want to abort itself
so one solution would be to have a bidirectional abort pin connected between tc and io
one sets to 1, other party clears, meaning it was acknowledged
actually that's what I'm doing in that gladevcp toolchanger; my 'OOB notification' is by calling emc.command.abort()
it's really jumping layers though
in the past I've had a failed tool change - mechanism jammed - I always shut down emc, recovered mechanically, made sure the tool table was right (matched where I ended up leaving the tools), restarted emc. emc can't know how to recover from that.
longer term we sure could think about these things and revise how the toolchanger interface works
I think we're near the limit of what can be improved within the current system
cradek: that's exactly the case where the TC wants to signal abort to iocontrol
i.e., we don't fix this stuff with a few 5-line hacks
well, that was 'a failure to communicate' between emc and iocontrol
the TC pin banging is really a different issue
yes that's probably right
I imagine it would be possible to have an iocontrol argument to default to the old pin protocol so people's toolchangers wont break, and on explicit request in the EMCIO ini stanza tell it to honor the abort pin
I would probably hook that abort to estop
usually when emc starts hanging because something failed, an estop fixes it
not sure if it's the same kind of hangs you're working on
but also your 'toolchanger mechanism jammed' switch
my ladder resets some of its state when there is an estop, too
if I had that switch, I'd just put it in the estop chain
actually I should time the arm, and detect "jammed" if it doesn't finish in the usual time.
... and estop
some machines detect failed tools and keep running by using backup tools
let's think about the semantics of the tc abort for a minute
the way it is now it aborts the program without the tc completed and that's the way it should be because you can 'run from line' at the M6 line and restart the toolchange
the Les Newell script dodged that question by starting at line M6 plus 1 because the TC wasnt restartable
oh. Iocontrol does have an emc-enable-in input been which is supposed to be connected to estop
the reason why I dont want to use that is: I dont want an aborted TC to be equal to an estop
I might want to restart-from-line and then estop is a bad idea because axes might move a bit
archivist: I'd assume such logic would be outside iocontrol, like a ladder?
mhaberler, some detect torque on drills and taps to detect waer and swap to a new tool
does it make sense to make emc know about that?
yes it eventually imo, comes from spindle power use during operation
actually I have already tried the abort pin idea; it just returns an RCS_ERROR back to task and that does the right thing
so that would be HAL-visible, but not necessarily emc-visible?
by emc-visible I mean 'abort a program' or somesucht
hmm if tool 4 takes excess power this cycle replace with tool 44 next time
let me rephrase that: on that machine, is the g-code program aware of that happening?
perhaps that can be hidden inside the toolchange but in the big picture a manufacturing centre should inform user of out of spec item
definitely, that's what the HAL UI's all about
so yes gcode does not need to know
actually if one were to mirror the current g-code line on a HAL pin, one could restart the program at that very line by HAL only
I'm not sure whether that's such a great idea though - noise on that line and away runs the machine ;-)
mhaberler: current line is always availbable via emc.stat
I now, thats what I use
I meant in HAL...
I conced it's a whacky idea.
I'd just like to see two choices from a M6 success or failure... where failure stops a running program (if not from MDI) and bails from the tool change request
I think that's how it currently is
aborting an M6 by any means (pin, emc.command.abort(), escape) leaves the old tool loaded unchanged
if you run-from-line where the M6 is, that's retried so it is an idempotent operation on abort
abort means deasserting tool-change and tool-prepare lines if they were active
restart means - start the TC pin protocol anew
is there a hal pin for tool change abort that I can call from my ladder when it fails after a timeout
... if you aren't using subroutines or looping
I think a toolchange-abort pin would be a good idea
for example in halui
that would work great for me
since it needed only to fire TOOL_ABORT command
maybe we can add jepler's current patch which is already a step forward
I'm happy to do a prototype iocontrol with toolchange-abort pin AND a protocol description ;-)
I thought abort already aborts it
why a separate pin?
which abort? deassert emc-enable-in?
that causes estop!
it's the wrong thing todo because it kills restartability of the program
pin for clearing most errors
cradek: i've not checked - just supposed that such functionality belongs to halui
halui.abort is probably fine for doing the abort
it doesnt address the race condition, which a bidirectional toolchange-abort pin would
I'm saying it already aborts the tool change, IF hitting escape in AXIS does it
ok, very likely - didnt try that but from reading the code it should not do so immediately, too
halui should work like all the other GUIs - it shouldn't have (or need) special powers
i am talking iocontrol.toolchange-abort, not halui.toolchange-abort
this pin will become part of a hardened tc/iocontrol protocol
If I do a Tn M6 and it misses it takes a long time for Axis to respond to any keypress... I can test the escape key
that was the fix I posted this morning
it now immediately aborts the TC, and iocontrol deasserts the tool-change and tool-prepare lines
which it didnt before
axis locks up during a tool change and escape does nothing
at least not immediately
mhaberler: yay, that's a big improvement.
JT-shop: it's not in master - you need to apply jeplers or my patch
cradek: happy to hear
I suggest the link jeff posted above, covers a scenario mine doesnt
folks: there is no need to do this immediately. I suggest to get jepler's version of the patch in
meanwhile I do a protocol description of how it currently works between TC and iocontrol, propose a revised proto with a toolchange-abort pin, and do an iocontrol prototype which you can test drive
if you like it then we can go forward
I need to think this through - a half baked proto is good for some damage
the patch (for fixing UI unresponsiveness after F1, F2, ESC and non-keyboard equivalents during toolchange) was: http://emergent.unpy.net/files/sandbox/0001-make-aborting-toolchanges-work.patch
I like the sound of that patch (looks like the simplest possible fix)
since you dont know me: here's a credential wrt realtime specs: http://www.springerlink.com/content/7220gv34381380nm/
yes, it was my fifth iteration
credentials not needed, but knowing to use LaTeX is a good sign :-)
* jepler laughs at cradek
at the time this was published i was not even in school :D
still somewhere under table i think :)
yeah, and Ada was en vogue
I made good civil use of Airforce money;-)
mhaberler: You bought everyone a round at the bar?
sort of. If you know the area: The Oasis in Menlo Park was the watering hole of choice.
jepler: I'll start with master, branch, apply your patch an build the iocontrol prototype with toolchange-abort pin from there.
mhaberler: OK. I anticipate having that patch on linuxcnc.org master branch soon
oh, fine. Then I'll start from there.
does it make sense to have a separate tool-prepare-abort pn?
as soon as it is in master I'll give a a good test on the Hardinge :)
I think you just need one abort that cancels all pending IO actions (including program run or queued mdi commands)
unless (I guess) you want to give an operator message about which of prep/change failed
actually I have the means to signal that to the emc layer, I extended the emcioStatus structure to signal what was aborted
I am just conisdering wether semantics of a prepare-abort and a change abort are the same
your jammed changer would be a prepare-abort
my abort button is a change-abort
it really bois down to wether some different action can be taken on the emc layer, or if throwing up the hands is good enough
the operator messsage is a good start. I'll put it in; not using it is always an option.
if the machine has dual changers
what is that..?
I imagine is a rare luxury and may not exist in the wild
in the case of prepare, you'd get signaled a) the prepare was aborted by pin b) the tool number to prepar was ..
Sorry, I lost my connection to the intertube for a while, I may have missed some of your "future tool changer" discussion. But if you're thinking of adding features like tool load limits ("...if tool 4 takes excess power this cycle replace with tool 44 next time...") good idea, you may want to consider adding tool usage limits too. Tool 4 has been used 123 times, 122 times, 121 times, etc.
that's something you could do in your gcode (using one #xxxx variable for each tool, just increment when you load the tool)
like T1 counts would be in #2001 and T2 in #2002 etc
when you replace T1, you'd issue #2001=0
nah belongs with the tool not the gcode
load limits - not so easy
archivist: with my scheme, the count is stored in emc, not the gcode (but the limit and check would be in gcode)
then its contact time too
how it's possible to measure contact time? is it contact with material?
again, that's harder
psha: time it's in a running spindle seems like a good estimate
<- not volunteering to implement it
* psha hiding behind cradek
btw it may be easily implemented as a userspace component?
for a certain job, I think a count would be good enough
"after the twelfth widget, the finish isn't so good, and it sounds dull. I'll set the load limit in the gcode for this job for 10"
if [ #2001 gt 10 ]
(msg, replace T1 and set #2001=0 in MDI, then run from here again)
N1 T1 M6 G43
cradek: emc.stat.tool_in_spindle is tool number?
then you could even have the flexibility to check them all at the start of the program!
not aware of any other system using gcode for tool wear/counts
set the tool life to 12 hits ( sounds very dungeon and dragons somehow, do you get more life with a coolant spell :)
archivist: I'm just saying how you could easily, flexibly, solve the problem today
seems better than a bunch of "someday someone oughta"
someday someone oughta save the information in the tool table - if you can find the letters to use, it's flexible enough to hold that kind of information now
it could even track the time the tool was loaded, easily enough, but that's not really the same as the time it's spent cutting.
it = iotask
or the conditions under which is it cutting
cradek: time spend cutting may be calculated from G1-like commands maybe?
psha: that's information that iotask really doesn't have
it could easily check the time when tool load/unloads happen, but anything else is harder
yes, i see
nimonic steel is just a bit different to brass , emc cannot know
btw when i've looked at the your link about bits in #emc there lifetime was mentioned as '6000 inches' - not time
so maybe a simple count, if doing a certain job over and over, would help
apart from looking at spindle load
psha: the interp could actually keep track of the lengths cut (approximately) and send a message to iotask saying what they were, right before the tool unloads
saying what they were = saying total length cut since tool load
which reminds me...radius and distance calculation on rotaries :)
if a tool is too old, I think I'd rather have it fail before the beginning of the program, though - not at tool load time.
hell a sufficiently smart user (using generated gcode) could keep track of the lengths in the vars, just like he could keep track of the load counts
to make a variable persistent across emc runs, you just add the line to the var file for that number you want to be persistent
That "load limits" one is a good idea, though harder to implement. I worked on a simple turning job where they were making simple bushings with chamfers, big though, 4140 steel, maybe 5" OD x 3.5" ID x 2.5" thick? A new insert started out at 12% spindle load. There was never any worsening in the finish visually. But the operator needed to change the insert when it got up to 15-16% load...
...because if he forgot, when the load got up to 17-18%, it would crush the insert into the seat, and the seat into the toolholder, destroying all three.
cradek: is it possible to fetch current G-code? other then load same file and read stat.current_line?
programmatically seeing the difference between 12 and 15 seems difficult (I'm sure those readings aren't too steady throughout the cut)
psha: fetch where?
in userspace comp
no other way that I can see
somewhere outside of interp :)
in addition, 'current' is kind of hard to define
JT-Shop_ is now known as JT-Shop
Yes, you're right (small differences in load while cutting) and also huge variances in load during accel/decel.
so the machine had an analog meter showing the spindle motor load and the guy just watched it and had a feel for how it should look?
(I have one of those meters on mine, but haven't wired it up yet)
yes, exactly, they had encounter this enough times before (repeat production) that they found a way to avoid it.
sounds like having the readout is the key, not really a control feature at all
HAAS I looked at showed the load too
Having the readout is the first key, having the operator not forget to look is the second key, lol
meat programming is harder
KimK: and second key is bit crushed into it's seat? :)
third key is "you're fired", lol
so 17-18% was the foreboding value? and the crash was actually a higher value? couldnt think of better word
cradek: tool table is not altered on tool changes?
Yes, so they started changing inserts "early" (before the load got that high).
in some configs (random tool change) it is rewritten
you could easily make it always rewrite, if you wanted to save data there.
sorry for tuning in late.
re tool life counters: with the gladevcp toolchanger example I sent a youtube link today, you can count toolchanges and times, and save such values as persistent attributes; lifetime counters were something I had in mind with persistence
what we cant do yet is pulling parameters from gcode (#xxxx) etc but psha will fix this in less than 190seconds if asked to
haha you think so...
OK, go. 189, 188, 187...
heh, it took me two weeks to dig into interp... don't ask me to do it again :)
I said pulling a parameter; I didnt say it must make sense
psha: you learn faster than me then :-)
is it done yet?
cradek: i've good practice in programming archeology ;)
really belongs in emc itself, if anywhere
no really, the reason for 190seconds was a bugfix turnaround time psha deliverd day before yesterday
ok, it was a minor fix, and he had a bad day
cradek: re: time/path coutners
maybe it's good to just store them in some G-code variables by interp
and access them from Python
yes, that's sure easy and flexible
this will involve only minor changes in interp
I don't see how python fits in
python may eat it from outside :)
thanks for your blessing. We now turn to the editor window ;-)
and remember :)
psha: if you're going to put it in emc, seems like it should be in the tool table
i'm just looking on it from different sides...
just finding excuses not to write papers :)
imagine a new canon call AGE_TOOL(100 seconds) or AGE_TOOL(100 inches) that interp calls before LOAD_TOOL(next one)
iotask simply adds that age value to the existing one, and rewrites the tool table
tool table would also have max age (seconds or inches)
when you request tool load, it would just fail if the tool is already too old
<- not volunteering to write this
it's just the clear and obvious way to do it, IMO
cradek: problem is you'd either have to store two values in tool table (total age and current age) or fill current age when replacing tool
I wasnt joking with this Python parameter access; we need to rethink passing values without resorting to may special-case solutions
in the case of tool age the tool table is the obvious place, but beyond that thats open
or use some external storage (g-code var?) to store current age
yes you'd have to zero out the 'age' when replacing the tool, just like you have to remeasure the length
pingufan just threatened on #emc that he will take next steps tomorrow
now be nice...
I think that is a popular method in pro controls, tool table holds the limits. Well, not sure if limit value or counter, but in the tool table at any rate.
cradek: btw really tooltable format is not limited to one letters?
since it's not Gcode?
yeah it's parsed in C, not with the gcode parser.
I think it's best if it's letternumber letternumber like gcode, though - it's familiar to everyone and fairly flexible
it used to have just a set of columns - very hard to add stuff with backward compatibility
i've just clarifed it a bit for me :)
yes we tried to automatically convert old tool tables when we switched to the letter scheme
so you can still see how bad it sucked :-)
this tool hits requires the work to be repetitive ( number of uses ), while tool life would be time ( more trickier ).
so you'd zero the tool uses left when changing the job.
heck, when changing the detail
tom3p: 'good for so many inches' seems pretty useful, but 'so many counts' might mean more to the operator and be easier for him to set
'replace operator after N tool changes'
can we get inches of work done?
like I said -- my stack of finished parts is 10 high - tool sounding bad/cutting badly - set tool life to 9 loads
tom3p: yes - in theory the interpreter could calculate that number and do something with it.
I would think intuitively a downcounter would be best. Everybody knows how a "gas gauge" works. And it's clear by inspection how much is "left".
KimK: interesting how that only takes one number in the tool table, not two, but makes the operator need to remember it in his head
ah, now thats handy, a notebook for the operator, theres always sticky notes for the night crew, and marks on the knobs.
tie the notes to the job ( program) or the tool ( tool table)
KimK: if this is the next-to-last load, there could be a warning message to replace before next run. that would let the run not be interrupted when the relevant M6 is hit.
Yes, but the operator already needs other "outside" info, insert numbers, etc. Isn't that why they're trying to do that "new g-code" format? Not sure how successful they've been. Who can agree on what containing "everything" should contain?
Sure, that sounds like a good idea
A "low fuel" light!
let me do a bodycount where state is held and retained in EMC. We have:
the var file
HAL widgets with persistence thrown in
and fairly limited access pathes between them
cradek: cutting commands in interp enqueue_STRAIGHT_FEED and enqueue_ARC_FEED?
yes that's pretty much it
pretty easy to have them add their length to a sum
be aware the program is interpreted ahead of time, though - it will be wrong for an aborted program run
Yikes, "cutting commands"(?) (from g-code?) in the queue are persistent? That doesn't sound good. To the uninitiated, at least.
if you have 10m table and running G1 X1000 than it counts :)
So it will try to (or make it easier to) resume a long cut that was interrupted? What, without restarting the g-code? Still doesn't sound good. But maybe I don't understand.
KimK: some Gcodes are living in wold isolated from outside - like fixed G0 X0
others, like probing etc are communcating with outside
and they need to be interpreted at time and code after it is not interpreted until that command is done
so it's ok
OK, you're the expert.
i only believe that _such_ thing won't be noticed for a long :)
so i try to explain why it's ok :)
EMC: 03jepler 07master * r9ccb01223996 10/src/emc/task/iotaskintf.cc: milltask: don't overrun an allocation
EMC: 03jepler 07master * re5de9a934f7f 10/src/emc/motion/usrmotintf.cc: milltask: don't busywait motion
EMC: 03jepler 07master * r5ebf364ad2bc 10/src/emc/ (iotask/ioControl.cc task/emctask.cc task/iotaskintf.cc): make aborting toolchanges work
jepler: the 0x4000 magic size assumption definitely looked suspicious
str = (char *)malloc(((ARRAY_SIZE + 2) * 2 * 11 + 80) * sizeof(char) );
I have no idea whether any messages are actually bigger than 0x4000
cradek: ssssssh that's a trade secret
cradek: are you just saying this was *your* code?