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