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