Back
[00:00:28] <cradek> this is how the mazak works now, I think, pretty much
[00:00:54] <cradek> it would be smart to change it to random. there are benefits.
[02:46:53] <jmkasunich> less kachunking per tool change ;-)
[02:47:44] <SWPadnos> but the kachunking is what makes it fun :)
[02:51:02] <cradek> hi hi!
[02:51:10] <cradek> was just grumbling at C++
[02:51:22] <SWPadnos> grumble--
[02:51:32] <SWPadnos> or should that be --grumble?
[02:51:43] <jmkasunich> grumble++
[02:51:50] <SWPadnos> shhh
[02:51:52] <cradek> "awwww, you were so close. bet you wish you could figure out the right argument types to this ridiculous overloaded function. too bad."
[02:52:15] <SWPadnos> it must be insufficiently overloaded, if you can't get it to compile with the arguments you want :)
[03:02:35] <CIA-4> EMC: 03cradek 07random_toolchange * rdb14b6328f3f 10/ (3 files in 2 dirs): make axis.ini a random-carousel machine, also a few cleanups
[03:03:47] <CIA-4> EMC: 03cradek 07random_toolchange * re15a6674127e 10/src/emc/rs274ngc/interp_convert.cc: remove debug messages
[03:04:56] <SWPadnos> ah, so you can still have 4-item tool tables, which let you specify both pocket and tool (?)
[03:05:07] <cradek> I'm very tempted to merge this, but it won't gracefully handle reading the old tool tables (I suspect it will mess them up)
[03:05:29] <SWPadnos> the old ones are pocket / FMS / (offsets), right
[03:05:32] <cradek> on a random-changer machine, pocket and tool are both in the tool table (that's how/where it keeps track)
[03:06:02] <SWPadnos> ok. my earlier concerns were due to my seeing the pocket number get removed from various configs
[03:06:06] <cradek> yes old ones have that
[03:06:24] <SWPadnos> I thought you had made a change that prevented both from being specified in the tool table
[03:06:25] <cradek> now if you don't shuffle between pockets, you don't need a redundant column
[03:06:31] <SWPadnos> ok, that's cool
[03:06:48] <SWPadnos> I withdraw my earlier criticisms then :)
[03:06:48] <jmkasunich> but what is wrong with the redundant column?
[03:06:54] <cradek> you say in the ini file whether you have a random tool changer
[03:07:05] <cradek> if you DO, your tool table must have tool# and pocket# for each tool
[03:07:15] <cradek> if you don't, you have just tool#
[03:07:41] <jmkasunich> if you start with a non-random config (and table), will it correctly convert the table if you change the ini file to say it is a random machine? what about vice versa?
[03:07:42] <cradek> jmkasunich: it's true, everyone could have the pocket numbers, and just ignore them
[03:07:57] <cradek> I think the answers are no and no
[03:08:18] <jmkasunich> seems like it might be simpler to always have both columns, if you have a non-random machine, then ignore the 2nd column on reading, and copy the first to the second on writing
[03:08:22] <cradek> it can't tell the format, because comments (arbitrary number of "words"/"columns" are allowed)
[03:09:03] <cradek> I figured it would be somewhat baffling to folks.
[03:09:17] <cradek> I think most people really only use tool numbers (if they use the tool table at all)
[03:09:24] <jmkasunich> no more baffling than the existing unused column is now
[03:09:28] <cradek> so that is the default, and there is no extra noise in the tables
[03:10:49] <jmkasunich> I just thought of a case I might use, that would like separate slot and number columns, but doesn't do random
[03:10:53] <cradek> I'd be perfectly happy with just one tool table format - I don't really care except for having to answer questions
[03:11:20] <jmkasunich> say I have 7 tools loaded in holders, with lengths set, etc.... each has a tool number and line in the table
[03:11:28] <jmkasunich> my job uses only three tools
[03:11:54] <jmkasunich> I have a little holder that sits next to the machine, I put the three tools I'm gonna use in those "pockets", and set the pocket numbers for the job
[03:12:11] <jmkasunich> then the manual-toolchange prompt will tell me which pocket to take the tools from for each change
[03:12:35] <cradek> if you did it random-style, you'd only need two pockets :-)
[03:12:58] <SWPadnos> unless you need 2 hands to hold a tool :)
[03:12:59] <cradek> manual-toolchange could tell you the pocket number, no problem, just hook it to that other hal pin.
[03:13:38] <jmkasunich> right - but unless I do random, I can't tell EMC the pocket/tool mapping (because you've deleted that 2nd column from non-random tables)
[03:13:45] <cradek> yep
[03:14:18] <cradek> I think tool numbers are more comfortable for your operation
[03:14:32] <cradek> you can put them in order in the "pockets", sure (and that's what I do too)
[03:14:42] <cradek> I don't think it needs to be more complex
[03:15:03] <jmkasunich> if there is only one column in the table, where do the pocket numbers come from?
[03:15:13] <cradek> one of the points of pockets in this new implementation is that one of the pockets is the spindle
[03:15:48] <cradek> they are just created by incrementing as the lines are read in
[03:16:17] <cradek> the first line is special - it is pocket 0 and tells which tool is in the spindle
[03:16:20] <jmkasunich> so for non-random, the pocket numbers are hidden (implicit based on line order), and for random, the pockets are explicit?
[03:16:27] <cradek> yes
[03:16:36] <jmkasunich> eww and ick
[03:16:49] <cradek> nonrandom, 0 and not-0 is the only important distinction
[03:16:59] <jmkasunich> I disagree
[03:17:01] <cradek> random, you have to be able to set it up arbitrarily
[03:17:04] <SWPadnos> I think I'd prefer to have the ability to do "sparse" toolsets
[03:17:09] <jmkasunich> exactly
[03:17:32] <jmkasunich> I can easily imagine having a changer with 10 pockets, but having more than 10 tools
[03:17:36] <cradek> explain?
[03:17:41] <jmkasunich> even on a non-random machine
[03:17:54] <jmkasunich> TTS toolholders are cheap
[03:18:05] <cradek> I mean what is a sparse toolset?
[03:18:16] <SWPadnos> not using all pockets in order
[03:18:19] <jmkasunich> I might wind up with a dozen, with common tools loaded in most of them, and tool numbers from 1 to 12
[03:18:34] <jmkasunich> but my actual machine might have a spice rack type changer, with only 5 holes
[03:18:47] <jmkasunich> spice rack = non-random
[03:18:58] <cradek> but you don't have to use all pockets in order?
[03:19:00] <jmkasunich> for the job, I pick 5 tools, and put them in the 5 pockets
[03:19:21] <SWPadnos> there are two things here, and I don't think they're related
[03:19:41] <jmkasunich> I realise that I can reorder lines in the file to tell EMC that tool N is in pocket 1, tool M is in pocket 2, etc
[03:19:48] <SWPadnos> one is whether tools get put back where they came from, and the other is whether there is a 1:1 mapping of tool number to pocket number
[03:20:12] <SWPadnos> I don't think they're the same question, or that they necessarily have the same answer
[03:20:14] <jmkasunich> but if I have another machine on the other end of the room with a random changer, I have to realize that there is a different scheme there, where number and pocket are explicitly spelled out
[03:20:23] <cradek> pockets are an accident that some machines have - gcode specifies tool numbers. when you change tools manually, IMO, you don't care where they are sitting - you care about their identifying numbers
[03:20:45] <jmkasunich> I disagree with your last statement
[03:20:54] <SWPadnos> sure. in the spice-rack setup (or any manual setup), you could use a "random" approach as well
[03:20:56] <jmkasunich> when I'm picking up a tool, there isn't a number printed on it
[03:21:17] <SWPadnos> take tool out of spindle, grab tool from pocken T, put tool that was in spindle into the newly-emptied pocket N
[03:21:26] <SWPadnos> you're now a manual random toolchanger
[03:21:31] <cradek> SWPadnos: if you do that, you're doing random, which is well supported
[03:21:36] <SWPadnos> rigth
[03:21:37] <jmkasunich> except that would be confusing
[03:21:38] <SWPadnos> right
[03:21:42] <cradek> (but you'd be a nut to do it that way)
[03:21:45] <SWPadnos> well, maybe and maybe not
[03:21:47] <SWPadnos> heh
[03:22:07] <jmkasunich> you'd actually take the tool from the spindle, put it in the empty pocket that it originally came from, then grab the new tool from its pocket and put it in the spindle
[03:22:17] <cradek> yeah
[03:22:26] <jmkasunich> you'd need extra hands otherwise
[03:22:45] <cradek> where I struggle with that is the tool table doesn't store all the state anymore
[03:22:47] <jmkasunich> a spice rack changer is an automatic version of the same thing
[03:22:56] <jmkasunich> what doesn't it store?
[03:23:02] <cradek> where the tools used to be
[03:23:10] <cradek> err
[03:23:15] <cradek> where the loaded tool used to be
[03:23:24] <jmkasunich> for a random changer you mean?
[03:23:26] <cradek> the drill is in pocket 0 now - where was it?
[03:23:29] <cradek> for nonrandom
[03:23:38] <cradek> for random, you don't care one bit where it used to be
[03:23:53] <SWPadnos> isn't that only important across runs?
[03:23:54] <jmkasunich> ok, I see the problem
[03:24:00] <jmkasunich> * jmkasunich ponders
[03:24:01] <cradek> the mazak has this problem if you start it with a tool in the spindle
[03:24:08] <cradek> if it was random, that's no problem
[03:24:27] <cradek> if it's nonrandom like now, you can't put it away
[03:24:28] <jmkasunich> I don't see how the "delete one column" approach has any bearing on that problem
[03:24:43] <cradek> it really doesn't
[03:24:57] <cradek> that's purely a cosmetic thing to not baffle people who don't care about pockets (99% of users)
[03:25:05] <jmkasunich> ok, just to be clear - I'm weighing in as opposed to deleting one column in the table
[03:25:35] <jmkasunich> that 99% of users can learn "that column is for advanced users, ignore it"
[03:25:36] <cradek> ok if we want to keep it there, we have to figure out its behavior for nonrandom machines
[03:26:14] <SWPadnos> it should specify the pocket number (I think that's what it was originally intended for)
[03:26:33] <jmkasunich> SWPadnos: yes, but that leaves the spindle problem
[03:26:36] <cradek> and when you load a tool?
[03:26:40] <SWPadnos> that's a separate problem
[03:26:54] <cradek> maybe for nonrandom, it's wrong to think of the spindle as a pocket
[03:26:57] <jmkasunich> if it specifies "the pocket number that the tool live in when it isn't cutting", then the problem becomes "what tool is in the spindle?"
[03:27:07] <SWPadnos> yes
[03:27:13] <SWPadnos> err - yes to cradek
[03:27:29] <cradek> but we *want* this functionality (remembering what is loaded)
[03:27:29] <SWPadnos> and then there's the specification that tool 0 means no tool loaded
[03:27:32] <SWPadnos> yes
[03:27:34] <jmkasunich> how about this for non-random: the pocket number specifies where the tool lives when it is not cutting. when the tool is in the spindle, the pocket number is negated
[03:28:28] <SWPadnos> or put a tool -1 in there, which is the one in the spindle
[03:28:43] <cradek> SWPadnos: to be honest, I don't care about that - you can have a "no tool" tool if you want. for random, if you want the spindle empty, you MUST have a "no tool" tool because it moves
[03:28:57] <jmkasunich> SWPadnos: you are thinking of "one line per pocket", but the file is "one line per tool"
[03:29:25] <jmkasunich> in fact, I have a different meaning for pocket 0
[03:29:26] <cradek> well the file is actually one line per pocket (each pocket/line has one tool number)
[03:29:51] <jmkasunich> cradek: interesting
[03:29:56] <SWPadnos> is it legal to have the same FMS number on multiple lines? (in the old code)
[03:30:04] <jmkasunich> is it really defined one way or the other, or is that a matter of interpretation?
[03:30:04] <cradek> depends on the emc version
[03:30:24] <jmkasunich> IMO, a large shop could have several hundred tools, even if the machine only has 20 pockets
[03:30:27] <cradek> jmkasunich: the tool table is whatever we want, of course
[03:30:40] <jmkasunich> the tool table should have a line for each tool, with the length, diameter, description, etc
[03:30:41] <cradek> yes that's why to use the fixed size thing (carousel) as the array index
[03:30:46] <SWPadnos> they could also have palettes of tools that get changed in one fell swoop
[03:30:53] <jmkasunich> then you modify the pocket table to say which tools are loaded, and where
[03:30:53] <cradek> no I disagree
[03:30:58] <cradek> the tool table lists the tools in the machine
[03:31:17] <jmkasunich> why?
[03:31:39] <cradek> because I have seven million tools in a huge robotic warehouse
[03:31:55] <SWPadnos> the tool table should list the tools available to the machine (in some way), because otherwise there's no way for the interp to error on an inaccessible tool number
[03:32:13] <cradek> um, also, the tool table has a (small) fixed size, like a carousel does (implementation reason)
[03:32:15] <jmkasunich> SWPadnos: I see the pocket number serving that purpose
[03:32:36] <SWPadnos> yes. that's why the "in some way" :)
[03:32:48] <SWPadnos> I might want to use tools 7, 9, and 13 on a job
[03:32:49] <jmkasunich> cradek: I think of the tool table as a text file, size virtually unlimited
[03:32:49] <cradek> dangit, I was sure I at least had the random-changer design right
[03:32:58] <SWPadnos> and not necessarily in pockets 1-3
[03:33:01] <SWPadnos> heh
[03:33:19] <cradek> jmkasunich: that mental model does not match the current implementation :-)
[03:33:26] <jmkasunich> yeah
[03:33:36] <SWPadnos> unless 56 > "virtually unlimited"
[03:33:48] <jmkasunich> and as always, I'm trying to make a mental model that is ideal, then bend the implementation to fit
[03:34:07] <SWPadnos> thatwould be top-down design
[03:34:10] <SWPadnos> or something
[03:34:18] <jmkasunich> the way I see it, each tool (in the entire shop, not just one machine) ideally has a unique identifier
[03:34:19] <cradek> fwiw, I think the random implementation is currently perfect
[03:34:32] <jmkasunich> I don't disagree
[03:34:39] <SWPadnos> coincidence?
[03:34:46] <cradek> I am not happy with any of the nonrandom designs proposed (or implemented, haha)
[03:34:46] <jmkasunich> well, 99% perfect
[03:35:09] <jmkasunich> I think the random and non-random should be made as similar as possible
[03:35:18] <cradek> well, I should say I think the design is perfect - the implementation is lightly tested and may be quite imperfect
[03:36:09] <cradek> I think the current nonrandom design in the branch is better than the old behavior in two ways: krufty column removed from table, keeps track of tool in spindle for next startup.
[03:36:13] <SWPadnos> I don't think there's a direct correlation between using a random toolchanger and being allowed to specify non-contiguous pocket numbers
[03:36:41] <SWPadnos> (but my understanding is that the code is that way in the branch)
[03:36:51] <jmkasunich> I think the new non-random design is both better and worse than the existing one
[03:37:00] <jmkasunich> better because it deals with "tool in the spindle"
[03:37:33] <jmkasunich> worse because it uses a non-obvious way to store tool/pocket mapping, even tho there is a simple and obvious way (which is used for random)
[03:38:18] <cradek> the idea there was I think the user doesn't care about pockets except "in the spindle" and "not in"
[03:38:28] <cradek> you disagree with that, and I sympathize
[03:38:33] <jmkasunich> I think you are assuming too much about the user
[03:39:06] <cradek> I assume the user will wonder what the magically-changing extra column of numbers is... I'm pretty sure I'm right about that
[03:39:14] <jmkasunich> I can think of several cases where user with a non-random changer might want other than a 1:1 mapping between tools and pockets
[03:39:28] <cradek> yeah I can too - you're right
[03:39:33] <cradek> still the in-spindle problem
[03:39:55] <cradek> your negative number proposal could fix that, but it's pretty ugly
[03:39:59] <jmkasunich> let me completely describe a proposal, then shoot holes in it
[03:40:21] <jmkasunich> assumption: the implementation can deal with a large text file
[03:40:33] <jmkasunich> 1) each line describes a tool, and there can be a bazillion lines
[03:40:51] <jmkasunich> 2) each tool has a unique identifier (tool number), and another column for "pocket"
[03:41:06] <jmkasunich> 3) if the pocket value is zero, that tool isn't loaded on the machine at all
[03:41:22] <jmkasunich> (if you have a bazillion lines, then only a small number of them will be non-zero)
[03:41:36] <jmkasunich> 4) if the pocket value is positive, the tool is in that pocket of the changer
[03:41:55] <jmkasunich> 5) if the pocket value is negative, the tool is in the spindle, and came from that pocket
[03:42:10] <jmkasunich> for non-random, the tool will go back into that pocket
[03:42:17] <jmkasunich> for random, the tool can go into any pocket
[03:42:35] <jmkasunich> for non-random, the only changes that EMC will ever make to the pocket column is to change the sign
[03:42:46] <jmkasunich> for random, EMC will change the pocket numbers
[03:42:54] <jmkasunich> * jmkasunich stops
[03:44:01] <cradek> digesting ... gurgle gurgle
[03:44:37] <SWPadnos> where is the tool table parsing / "loading" done now?
[03:44:49] <cradek> in "io"
[03:44:59] <SWPadnos> ok. I bet that would need to change
[03:45:08] <SWPadnos> io probably shouldn't be doing any file access anyway
[03:45:24] <cradek> let's not sidetrack
[03:45:54] <SWPadnos> that's not a sidetrack - this design implies that the tool table can't be passed as an NML message, since it's unbounded in size
[03:46:08] <cradek> you'd ignore the ones not in pockets
[03:46:45] <SWPadnos> ok, so the "load tool table" message says "this is the file name", and the parsing is in io
[03:46:50] <cradek> jmkasunich: would this negative thing be used for randoms too?
[03:47:03] <jmkasunich> yes, for consistency
[03:47:20] <jmkasunich> "-N" means "in the spindle, came from pocket N"
[03:47:42] <jmkasunich> so tool loading would always change the N to -N in the line that describes the new tool
[03:47:49] <cradek> the signals we have going out to hal are "prep pocket N" and "do the swap now"
[03:47:59] <jmkasunich> unloading would either change -N back to N (non-random) or -N to M (random)
[03:48:34] <cradek> but "came from pocket" is not meaningful on random
[03:48:55] <jmkasunich> it means something, we just don't care
[03:49:27] <cradek> so in random, you'd always have M and -M
[03:49:42] <jmkasunich> lost me
[03:49:57] <cradek> after a change, you'd have M (the previous tool in pocket M) and -M (the current tool which just came from M)
[03:50:23] <cradek> I mean: the previous tool _which is now_ in pocket M
[03:50:39] <jmkasunich> yes
[03:50:56] <cradek> I think that's more confusing than swapping M <-> 0
[03:51:17] <cradek> but I hate to have two completely different formats/implementations
[03:51:24] <cradek> bleh
[03:51:58] <jmkasunich> the problem is that for a non-random changer, you need both a flag (this tool is in the spindle) and a number (this is where it goes when it is done)
[03:52:07] <jmkasunich> for random, you only need the flag
[03:52:38] <cradek> there's yet another problem
[03:52:54] <cradek> none of the infrastructure for where to unload to is there
[03:53:13] <cradek> even if what pocket it came from is encoded in the tool table, it's not available in hal
[03:53:21] <jmkasunich> yep
[03:53:32] <cradek> the canon calls don't exist to pass it around (and I don't know what they would be)
[03:54:02] <jmkasunich> for existing non-random changers, we dumped that burden on the changer itself (ladder, hal, etc)
[03:54:03] <cradek> the calls are "prep pocket (pocket #)" and "change tool (some integer that is ignored)"
[03:54:12] <jmkasunich> and that is why it falls on its face after a power cycle
[03:54:20] <cradek> right
[03:55:15] <jmkasunich> I guess there are two fundamental ways of looking at the "tool database"
[03:55:28] <cradek> I'm totally lost as to what the general solution is here
[03:55:51] <jmkasunich> one is they way I described - where each line is a tool, and info about where it is lives in a column... the other way is that each line is a location, and info about the tool in that location is in column(s)
[03:56:39] <cradek> I like the second way because I can easily see an infinite number of tools
[03:57:40] <jmkasunich> maybe the truth is that there are two tables - one has one line per tool and has ONLY tool data (diameter, length, description), and the other has one line per pocket (where the spindle is a special pocket), and the only info it contains is a tool number (or zero if that pocket is empty)
[03:57:51] <cradek> I'm probably blinded by just wanting the right implementation for the machine I'm getting
[03:58:21] <cradek> yes that's possible - they are separate ideas
[03:59:38] <cradek> I see a tool table as the thing that goes with the job - it has a list of the small number of tools needed. the tool numbers might be big numbers
[04:00:00] <jmkasunich> thats where we disagree
[04:00:16] <cradek> well like you say, we're talking about different tables
[04:00:26] <jmkasunich> once a tool is mounted in a collet, its diameter and length and description don't change
[04:00:38] <jmkasunich> even more so for something like a face mill that doesn't even go in a collet
[04:00:48] <cradek> that's true
[04:01:06] <jmkasunich> that data should remain with the tool regardless of whether it is on the machine or in the crib
[04:01:31] <SWPadnos> that's a tool database
[04:01:35] <cradek> yes possibly (assuming other machines measure length the same way)
[04:01:42] <SWPadnos> from which you'd make tool tables for individual machines
[04:01:53] <jmkasunich> maybe SWP is onto something
[04:02:43] <cradek> I think it's long-held practice to punch a tape with a tool table that goes with the tool cart for the job
[04:03:10] <cradek> someone measures the tools and builds the table that matches the gcode
[04:04:03] <cradek> I don't know if that's current, obsolete, or a practice that's no longer possible but we wish it was
[04:04:21] <mozmck> I can ask a friend of mine who I'm doing some work for how his machines do it.
[04:04:32] <cradek> stuart said the other day he wanted tool tables named ngc-filename.tbl
[04:04:33] <jmkasunich> ok, going back to the "two table" model - let's suppose that the first table is actually an offline database, and the 2nd table (1 line per pocket, with tool numbers listed) is the "tool table"
[04:04:56] <mozmck> He's got machines with 120 tools or more, mostly new
[04:05:03] <jmkasunich> the tools also need length, dia, etc, that can be copied from the database for fancy shops, or measured and added by hand for simple shops
[04:07:06] <cradek> ugh, tired...
[04:07:12] <mozmck> the machines are new that is... if it would be any help
[04:07:14] <jmkasunich> yeah, it is getting late
[04:08:26] <cradek> mozmck: in those cases I never know what question to ask - "how do you do it" is easy but would "how would you like to do it in your wildest dreams?" is better - but nobody thinks about that because they are busy doing it the way they do it
[04:08:39] <jmkasunich> exactly
[04:09:13] <jmkasunich> in many cases, "how do you do it" gets an answer that is really "here's how we've been working around the crippled things the control makes us do"
[04:09:18] <cradek> shops are doing it the way their machines make them do it
[04:09:24] <mozmck> yeah, I'm just wondering how they do it on his new machines. might be of interest.
[04:09:32] <cradek> it would, I agree
[04:10:08] <SWPadnos> as a small shop guy, I'd want to be able to use "a few empty pockets" for a job
[04:10:34] <SWPadnos> which is why I'd want the ability to specify pockets for each tool, not starting at 1 and non-contiguous
[04:10:44] <cradek> SWPadnos: the oldest tool holders I have (the ones that came with the mill) have "TOOL #3" etc engraved on them
[04:10:58] <SWPadnos> heh
[04:11:02] <SWPadnos> barcodes on the new ones ;)
[04:11:08] <jmkasunich> as a guy who manually switches using a subset of the total list of tools, and who might eventually have a spice rack changer, I want to be able to put any tool in any pocket
[04:11:12] <cradek> the guy programmed T3 and when it said T3 on the crappy little LCD he fished around in his shoe box for that one
[04:11:15] <jmkasunich> (non-random)
[04:11:34] <SWPadnos> right
[04:12:17] <cradek> he definitely had a tool list like jmkasunich wants, not a pocket list
[04:12:22] <SWPadnos> I'd maybe have a 1/2 rougher, some sort of face mill, some smallish ball endmill, and probably others in there all the time
[04:12:30] <SWPadnos> I want those to go back where they came from
[04:12:57] <SWPadnos> I then add a few special tools for a job into other pockets
[04:13:06] <cradek> maybe this whole thing needs a lot more work (design)
[04:13:31] <SWPadnos> and maybe leave those where they are and run another job with stuff somewhere else (without wanting to take everything out every time)
[04:13:44] <SWPadnos> I'd only have to remove tools when I run out of pockets
[04:14:06] <cradek> I do have a little rack thing and I put the tools in the order I will use them, T1 in front, T2 behind etc.
[04:14:07] <SWPadnos> and I can see getting some "fragmentation" if I use the same tool on a couple of consecutive jobs, and just leave them where they are
[04:14:22] <SWPadnos> I think it does need more thought
[04:14:27] <jmkasunich> I really believe we need to think of "tool database" (dia, len, descr) and "tool locations" (pocket) as two different things
[04:14:44] <SWPadnos> ideally, the design doesn't force a method on people
[04:14:47] <jmkasunich> I don't know if EMC neccessarily has to be aware of both
[04:14:59] <SWPadnos> it just gives them the tools to do things close to the way they want
[04:15:08] <SWPadnos> (or exactly, if they're lucky/writing the code :) )
[04:15:23] <cradek> SWPadnos: I can't tell if you're saying "implement everything possible" or "implement nothing" but either way you're scaring me
[04:15:49] <SWPadnos> heh
[04:16:31] <SWPadnos> no, I'm saying that there may be several variables as to how a toolchanger / tool table should be used, and wherever possible, those variables should be left independent
[04:16:57] <SWPadnos> that's where I start to disagree with something like "a nonrandom toolchanger doesn't need pocket numbers any more"
[04:17:04] <SWPadnos> they're independent to me
[04:17:05] <jmkasunich> we need to divorce tool dimensional data from tool location data
[04:17:18] <jmkasunich> various kinds of changers will manipulate location data in different ways
[04:17:22] <SWPadnos> or put them in the same file for a specific job
[04:17:26] <jmkasunich> dimensional data always lives with the tool
[04:17:44] <SWPadnos> my first thought was that pockets should be in HAL
[04:18:03] <jmkasunich> I think you are right
[04:18:07] <SWPadnos> "gimme this tool" is what the interp says. HAL signals when that's done, or if it's not possible
[04:18:21] <jmkasunich> the only reason we are trying to make EMC proper deal with it is that HAL doesn't have non-volatile storage
[04:18:47] <SWPadnos> that should be on the list for HAL2 or HAL3 or whatever the next version will be :)
[04:19:21] <jmkasunich> well actually, toolchanging could be handled by a userspace HAL component with access to the file system
[04:19:38] <cradek> that's precisely what io is
[04:19:52] <jmkasunich> EMC proper (the interp really) needs the tool table for diameter and length comp ONLY
[04:20:11] <jmkasunich> the toolchanger (IO, or whatever) needs to know what tool is in what pocket, and what tool the interp wants, ONLY
[04:21:03] <jmkasunich> the latter bit of info is already sent thru a hal pin
[04:21:34] <jmkasunich> putting tool dims and tool/pocket mapping in the same file only complicates the design
[04:21:46] <SWPadnos> I'm tired now. good night guys
[04:21:47] <jmkasunich> although two files would probably confuse some users
[04:21:50] <SWPadnos> heh
[04:21:56] <SWPadnos> and text strings are ideal
[04:22:20] <SWPadnos> "rougher" - doesn't matter what size it is if you're using cutter comp (within reason)
[04:22:27] <cradek> yeah, goodnight, let's talk tomorrow or so
[04:22:34] <jmkasunich> night
[04:22:36] <SWPadnos> good plan
[04:22:38] <SWPadnos> see you
[04:22:42] <cradek> thanks all
[12:13:02] <SWPadnos> hmmm. there's no /docs/ directory on linuxcnc.org any more
[12:13:19] <SWPadnos> oh - that's a map to jeplers dir
[12:16:30] <BigJohnT> looks like the G-Code Properties Run time does not add up any Z moves...
[12:16:57] <SWPadnos> it doesn't take accel into account
[12:17:06] <BigJohnT> I knew it was something
[12:17:23] <SWPadnos> so if you do a lot of short Z moves with high F, it will seem to more or less ignore them
[12:17:35] <SWPadnos> it also doesn't know about blending or that kind of thing
[12:17:39] <BigJohnT> ah ok
[12:17:44] <BigJohnT> thanks
[12:17:48] <SWPadnos> suer
[12:17:51] <SWPadnos> sure
[12:17:53] <SWPadnos> IIRS
[12:17:55] <SWPadnos> IIRC
[12:18:06] <SWPadnos> pardon me - time to drink more coffee
[12:18:35] <BigJohnT> breakfast time here
[12:19:11] <SWPadnos> oh. I could have breakfast
[12:19:14] <SWPadnos> that might be nice
[12:20:34] <BigJohnT> grits and dry toast here
[12:20:59] <SWPadnos> I'll skiop it then, thanks :)
[12:21:02] <SWPadnos> skip
[12:21:41] <BigJohnT> :)
[12:25:16] <jepler> try loading up some lathe fpr or css code and looking at the estimated runtime :-/
[12:34:59] <BigJohnT> way off is it?
[12:36:06] <BigJohnT> hi ho hi ho it's off to work I go :)
[12:43:07] <jepler> (I should say "css and fpr", not "or")
[12:43:24] <jepler> (actually, I guess it's "fpr"; css is immaterial)
[12:59:34] <micges> about joints_axes3: It will be ok and clear that for trivkins configurations only [TRAJ], [KINS] and [JOINTS_n] section will be present and no [AXIS_n] section in inifile?
[13:09:27] <jepler> I think having [AXIS_X] would be clearer than having [JOINT_0] but if it is too much trouble then don't do it
[13:09:45] <jepler> (shouldn't it be [JOINT_#], not [JOINTS_#]?)
[13:13:56] <micges> yes JOINT not joints :)
[13:21:42] <micges> so in ini file should be some indicator that this machine is trivkins (in [TRAJ] or [KINS] would be the best)
[13:26:34] <micges> then It would be very simple
[13:32:41] <jepler> * jepler tries to figure out how a tar.gz got into his doc building source tree where a pdf should have been
[13:35:56] <BJT-Work> that's interesting
[13:36:23] <SWPadnos> I didn't identify it as a .gz, but I was only using hd (not file)
[13:52:55] <alex_joni> micges: once it's fully working, we can always expand it a bit to support "current" trivkins ini's
[13:56:53] <micges> I see
[13:57:00] <micges> bbl
[15:03:29] <micges> so next step in ja3 will be Axis modifications
[15:24:39] <SWPadnos> micges, one thing I had thought of for joint section naming is to have the ability to set aliases somewhere (like in the [KINS] section)
[15:25:02] <SWPadnos> so you'd have [KINS]JOINT0=KNEE
[15:25:16] <SWPadnos> and then you'd have a section names [KNEE] with the settings for that joint
[15:25:19] <SWPadnos> named
[15:26:33] <SWPadnos> it might be a little easier to manage things like STRUT1_2 (for a hexapod, as an example) rather than JOINT0-n
[15:26:45] <micges> and without aliases there will be only [joint_#] as always?
[15:26:50] <SWPadnos> yes
[15:27:08] <micges> cool idea
[15:27:19] <SWPadnos> JOINT0-n are immutable, but can be aliased by looking at settings in [KINS] (or somewhere) for keys named JOINT0-n
[15:27:35] <SWPadnos> thanks :)
[15:28:08] <SWPadnos> there's an old softrware saying that goes something like "all software problems can be solved with an additional layer of indirection" :)
[15:28:11] <SWPadnos> gah
[15:28:13] <SWPadnos> software
[15:28:31] <SWPadnos> * SWPadnos has had 3 cups of coffee already, what's the problem?
[15:29:14] <micges> hehe here is 32 degree in shadow :) maybe this is reason?
[15:29:21] <SWPadnos> hmmm.
[15:29:31] <SWPadnos> no. only ~23 here at the moment
[15:29:41] <SWPadnos> maybe they had decaf in the regular pot
[15:33:43] <micges> SWPadnos: on wiki there is idea to add [JOINT_#]NAME option
[15:34:25] <SWPadnos> what page?
[15:34:37] <SWPadnos> we've batteed this naming thing around a few times
[15:34:41] <SWPadnos> gah
[15:35:45] <cradek> I bet there will be a lot of polishing we can do after the basic functionality is there
[15:35:55] <micges> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?IniChanges
[15:36:08] <SWPadnos> thanks
[15:36:39] <micges> cradek: basic functionality is there :)
[15:36:46] <cradek> aha
[15:36:50] <SWPadnos> micges, I don't see anything saying what that NAME should be
[15:37:03] <SWPadnos> but you can add that in right now - NAME isn't used, and unused keys are allowed in ini files :)
[15:37:07] <SWPadnos> it becomes documentation
[15:37:19] <micges> #first joint
[15:37:19] <micges> [JOINT_0]
[15:37:19] <micges> NAME = table
[15:37:33] <SWPadnos> I know - I just don't see it being described or used anywhere
[15:37:36] <SWPadnos> and you can do that now
[15:37:39] <SWPadnos> [AXIS_0]
[15:37:47] <SWPadnos> Fred=Flintstone
[15:37:53] <micges> ok I see
[15:38:04] <SWPadnos> that's perfectly valid, and there are no issues unless someone needs to use the key Fred for something
[15:39:12] <SWPadnos> hmmm. for the last example on that page - are spindles joints?
[15:39:32] <SWPadnos> (the example is a 3-axis mill with 10 spindles, defined as joints)
[15:39:44] <micges> this was my example with many z joints
[15:39:53] <micges> each one can be homed
[15:40:02] <SWPadnos> ok, it says 10 spindles (joints)
[15:41:20] <micges> fixed
[15:42:27] <SWPadnos> oh - is the example supposed to be a bunch of separate quills?
[15:44:19] <micges> what is quill ?
[15:44:37] <micges> (can't find in dict)
[15:44:41] <SWPadnos> the thing that moves down when you pull the handle on a Bridgeport-type machine
[15:45:00] <SWPadnos> it's normally the Z axis on a Bridgeport
[15:45:07] <micges> more less
[15:45:35] <micges> its ini for table mill for very mass production of single detail
[16:30:36] <CIA-4> EMC: 03micges 07joints_axes3 * rba6abad51c03 10/configs/sim/ (sim_xyzbc.hal sim_xyzbc.ini sim_xyzbc.tbl): Add XYZBC sim configuration for testing
[16:31:26] <micges> cradek: you can see/test now progress
[16:31:40] <cradek> +# Third joint
[16:31:41] <cradek> +[JOINT_2]
[16:31:55] <cradek> man, these comments ...
[16:31:58] <cradek> micges: thanks, I will try it
[16:33:03] <micges> hehe
[16:37:45] <micges> things that I can't find/understand for now:
[16:37:54] <micges> 1. jogging in world mode
[16:38:53] <micges> 2. Axis doesn't preview jogging in joints mode when not homed, in BOTH kinematics type
[16:41:07] <cradek> I'm not sure how or if it can do #2
[16:41:44] <cradek> I only get four "homed" icons when I home all five joints
[16:41:54] <cradek> stat.homed shows 1 1 1 1 1
[16:42:44] <micges> in coord mode yes
[16:42:54] <micges> that was my 3 question
[16:43:09] <cradek> even in joint mode
[16:43:12] <micges> these are homed joints indicators
[16:43:18] <micges> not axes
[16:43:22] <cradek> I understand
[16:43:40] <cradek> two problems: 1) there are 4 of them, not 5 like there should be 2) they don't mean much in world mode
[16:44:47] <micges> cradek: so manual in world mode can be without homed icons ?
[16:45:06] <cradek> I'm not sure
[16:45:29] <cradek> you cannot even enter world mode if all the joints are not homed (or it should be that way)
[16:45:52] <micges> I'll be vary happy of your feedback in that area :)
[16:46:15] <cradek> again, thanks for working on this
[16:46:43] <micges> sure, I've learned much
[17:47:17] <micges> bbl
[19:28:44] <seb_kuzminsky> hi mshaver
[19:28:54] <cradek> hi matt, seb
[19:29:21] <seb_kuzminsky> what's new cradek
[19:29:38] <cradek> getting a "new" mill monday
[19:29:47] <cradek> new to me
[19:29:49] <seb_kuzminsky> ooh!
[19:29:56] <seb_kuzminsky> what is it?
[19:30:21] <cradek> it's a little VMC with tool changer
[19:30:28] <cradek> it's a sweet machine
[19:30:33] <seb_kuzminsky> neat! :-)
[19:30:52] <seb_kuzminsky> hence your random_toolchanger stuff
[19:30:54] <cradek> an ugly duckling, comes with no control, so I will have no "but it's working!" excuses
[19:31:07] <cradek> yep that's what it's for
[19:31:40] <mshaver> hi seb!
[19:31:47] <cradek> wonder if there's any other way this retrofit could "serve" the emc project
[19:31:58] <cradek> is there any mesa stuff that needs a testbed?
[19:32:16] <seb_kuzminsky> steppers with encoders! :-P
[19:32:21] <cradek> if no, I'll just use exactly the same as the other machine
[19:32:25] <cradek> haha, a little big for that
[19:32:53] <mshaver> hi cradek too! going back out to the shop to do testing, back later
[19:32:53] <seb_kuzminsky> i think 98% of hm2 users are using 5i20, with the other 2% on 5i23
[19:32:59] <SWPadnos> how about a PID that takes encoder velocity for D?
[19:33:17] <seb_kuzminsky> seeya mshaver, let us know how it works
[19:33:30] <cradek> if we had ADC, it could use real analog velocity
[19:33:31] <SWPadnos> hi bye Matt
[19:33:42] <SWPadnos> hmmm. I don't have a spare board for you, sorry
[19:33:51] <SWPadnos> spare analog input board, that is
[19:34:09] <cradek> surely it's velocity mode amps, so maybe it's the wrong machine to test that
[19:34:13] <seb_kuzminsky> cradek: i've been wanting to do ADC over SPI to HM2 for a long time now
[19:34:35] <mshaver> well, just got off the phone with Peter. I'm losing hundreds of steps during a fairly short test program :( I need to try a few things...
[19:34:42] <seb_kuzminsky> mshaver: ug
[19:34:44] <cradek> ick
[19:34:50] <SWPadnos> oops
[19:35:02] <mshaver> indeed! back in a bit
[19:35:04] <cradek> seb_kuzminsky: the edm guys would love that
[19:35:21] <cradek> also reprap
[19:36:51] <seb_kuzminsky> cradek: also cradek's new spindle vel feedback ;-)
[19:37:11] <seb_kuzminsky> ok ok i'll get my thumb out and do this
[19:38:59] <cradek> does mesa have the hardware part for adc already?
[19:39:09] <seb_kuzminsky> yes, hold on
[19:39:19] <SWPadnos> 7i64?
[19:40:33] <seb_kuzminsky> the 7i64 is only digital i think
[19:41:16] <seb_kuzminsky> 7i65
[19:41:48] <seb_kuzminsky> 8 16-bit DACs + 8 12-bit ADCs
[19:41:55] <seb_kuzminsky> plus a bunch of gpio
[19:42:39] <SWPadnos> ah
[19:45:11] <cradek> seb_kuzminsky:
http://www.youtube.com/watch?v=_UXd9df0-RM
[19:45:31] <cradek> mine won't be so pretty, but it's that machine
[19:45:43] <seb_kuzminsky> wow
[19:46:12] <seb_kuzminsky> those look like some snappy axes (& the tool changer)
[19:46:20] <cradek> yeah, it's very fast
[19:46:53] <cradek> looks like the original spec is 590 ipm on XY, 472 on Z
[19:47:02] <seb_kuzminsky> whee!
[19:47:18] <cradek> doesn't waste much time between cuts at that rate
[19:47:29] <cradek> my bp is 250ipm and it seems plenty fast
[19:47:36] <seb_kuzminsky> i like the exposed toolchanger on the side
[19:47:43] <cradek> the tool changer is much slower on the bp though :-)
[19:48:01] <seb_kuzminsky> that's the cradek_toolchanger? :-)
[19:48:08] <cradek> yeah
[19:48:19] <cradek> two arms, kind of slow and makes a grumbling noise
[19:48:25] <seb_kuzminsky> heh
[19:48:34] <SWPadnos> runs on caffeiene?
[19:49:08] <seb_kuzminsky> maybe it's just got some nuts loose?
[19:49:22] <cradek> haha
[19:49:25] <cradek> could be