iotask is so ridiculous
sometimes I think it was made ridiculous on purpose
well, regular task is that way too
cradek: what's ridiculous about it?
I like the idea that the toolchanger might give you a random tool :)
heh, nothing like a little surprise huh?
sigh. of all the times for DigiKey's credit card processing system to go down
this is not the ideal one
that doesn't mean it's free?
while we are talking about the tool changer and tool table let's entertain another thought
I would like to see the tool table use the same name as the .ngc file
should not be difficult?
well, that's not the way it works now..
iotask doesn't know about the current part program at all
and what tool file do you have in mdi?
what do you do if you change from a program with a program-specific tool table to no program-specific tool table?
.. those are some of the questions that I have right away
how do you deal with named subroutines in separate files, or inclusion of files in other circumstances?
(ie, if we ever add an "include" directive)
named subroutines would be ignored - included files would be ignored
the file test.ngc would cause the file test.tbl to be called
stustev: you can pretty much embed your tool table with G10 L1 commands in the ngc file
although I don't see how you'd adjust lengths and stuff like that
I was thinking of data flow from the programming room to the CNC machine. The tool list given to the operator/tool crib could be the .tbl file. The tool lengths could be determined with the tool setter and written into the .tbl file before the file is loaded in the control.
so you don't want to edit the gcode file itself.
do we have anything that works like include? if so you could include the file containing the G10 L1 commands.
O-calls are said to be able to go into other files, but I don't know much about that
in theory, O<name> call will attempt to load the file $nc_files_dir/<name>.ngc if the named subroutine isn't in the current file (or other already-parsed files)
and O<number> mught do it too (loading e.g. 237.ngc)
micges: some of your changes on joints_axes3 don't seem related. if they aren't, they should go on a different topic branch or on master
examples include: "Change global canon variables" and "A B C axes are unconditional now"
I haven't looked at all your recent checkins to figure out all of them
with ABC you right
EMC: 03micges 07joints_axes3 * r41562f0e1350 10/src/emc/nml_intf/canon.hh: A B C axes are unconditional now
EMC: 03micges 07joints_axes3 * r1e89c003053b 10/src/emc/task/taskintf.cc: Update info only for existing joints
EMC: 03micges 07joints_axes3 * ra3e4459e2907 10/configs/sim/ (keystick.ini xemc.ini): Change sim keystick and xemc configs to run
EMC: 03micges 07joints_axes3 * r7a48f7850192 10/src/emc/ (nml_intf/canon.hh task/emccanon.cc): Change globals canon variables into one struct CanonConfig_t
EMC: 03micges 07joints_axes3 * r8d4a02390d2f 10/src/emc/usr_intf/ (keystick.cc xemc.cc): Remove setting up emc global TRAJ variables from xemc and keystick
EMC: 03micges 07joints_axes3 * ra32e2884c0b9 10/src/emc/ (6 files in 3 dirs): Make AxisConfig structure locally in taskintf.cc
EMC: 03micges 07joints_axes3 * r8c81007145d7 10/src/emc/ (4 files in 3 dirs): Make global TrajConfig now locally in taskintf.cc
EMC: 03micges 07joints_axes3 * rcba76a2e3b4b 10/src/emc/ (6 files in 4 dirs): Create global structure for TRAJ config values
EMC: 03micges 07joints_axes3 * rbcf21942d707 10/src/emc/ (6 files in 3 dirs): Remove redefines of EMCMOT_MAX_DIO and EMCMOT_MAX_AIO
with canon I've do this to make sure of all relations with canon<=> taskintf globals
but right its not directly related
then it doesn't belong on a topic branch
or, it doesn't belong on a topic branch where the topic is "joints_axes3"
is it possible to revert both wrong you mentioned?
first, decide where the change should really have been made: master, or a new topic branch.
if it's a new topic branch (canon_cleanup?) then create it.
then cherry-pick those commits to the branch
then merge that branch into joints_axes3
if you later do more cleanup commits, do them where they belong; if you want them as a basis for work on joints_axes3, use merge to get them
those two bad commits can be left? I'll do beter next time
it won't cause a problem to leave them there
and I am not sure it is just those two commits. those are the two that I looked at first.
imagine that joints_axes isn't ready for emc 2.4. We might want your task/canon cleanups. If it's on a separate branch, then we can just merge it into master. If it's mixed in with the work on joints_axes that's not ready, we can't just merge it,
just based on the change message, "remove redefines" is probably another one that should be on a different branch
bbl, time to go to the office
I see whole six commit not belong :/
jepler: i'll fix it
micges: thanks. if you need any help with using git, please ask
jepler: git can delete commits?
not after you've pushed them.
after you've pushed a commit, it can never be changed.
so best thing is create branch for my 'additional work' , delete them from ja3, and then merged them from 'additional'?
you never delete anything
delete I mean remove from source
you make the commits again on a new branch (using git cherry-pick it's usually very quick)
then on joints_axes3 you merge the new branch
the next time you want to make a cleanup that is independent of joints_axes3 you make it on the other branch, then merge again
I see now
cradek: how far away is your mill?
you know it is an addiction - right?
ha, I don't want to talk about that
"you are selling the old one ... right? ... right?"
That never even crossed my mind ;)
why would you do that ;)
the bp is one heck of a drill press
bp will probably stay with its controller now? (unless it just totally dies)?
yeah, I think it's not worth the time or money to retrofit
cradek: what are the specs on the servos? (on the mori?)
I don't know
they look big
it rapids very fast
590 ipm on xy, it says
do you know if you get the amps?
amps, servos, spindle drive
cradek: new mill?
yes, working on arranging shipping now
jepler: seems like some things in AXIS are bitrotting. Upon startup the "P" icon is pressed in, but the view is "Z". also the up arrow for recalling from mdi history doesn't always start at the bottom of the list.
hm the first one I hadn't noticed
some days I think axis could use a good reaming, other days I think it's better to touch it as little as possible
and the latter always wins
[16:45:53] <cradek> http://pastebin.ca/1502201
jepler: I'm running into this a lot. In this situation I want to commit everything except configs/sim/axis.ini
git add src/git commit -a give me all that other crap too - what incantation do I want?
git add -u src?
strange - actually it's not the Z view, it's perspective but rotated to put the viewpoint along Z
EMC: 03cradek 07random_toolchange * r24910dacc94e 10/src/emc/ (7 files in 5 dirs): give both prepped pocket and tool number to hal. fixes manual tool change.
well now, manual tool changes make sense again (the prompt has the tool number). a tool changer can prep according to the pocket number or tool number.
but for nonrandom and manual, the pocket numbers still swap around
maybe it doesn't matter?
yeah I wonder about that
the case that is still broken (which is a case we never had before) is where the changer is nonrandom but you want big tool numbers
there should be a 1:1 big-toolno:pocket mapping
at the moment, the entire tool table is loaded in one fell swopp (with an NML "load tool table" message), right?
it's loaded and saved all at once
or individual tool entries can be changed via the G10L1 (>) construct in G-code?
the entire table is rewritten when you do that
and there's a corresponding "change one entry" NML Command
I'm thinking about the case where the GUI is on a separate machine from the control
and file name/location issues
that's no better or worse than before
like with G-code - you can't load a file from the GUI to a remote PC directly. the file has to exist in the same place on both machines (at least it used to be that way)
I'm thinking about how to make it better, or at least guarantee it's not worse :)
the tool table is mixed duty - human readable/editable, and also read and written by iotask
now that I type it, I see that is a lot like the gcode program
I may be reasoning from incorrect assumptions though. is it true that the whole table is passed in a single message? (thus limiting it to 56-ish entries)?
so I'd deprecate that, and use only the "set single tool" function
that would eliminate what I see as the main limitation on tool size
I'm not smart enough to change that
a "helper function" would be needed which would iterate over the tool table file and call the "set one tool" function as needed
heh. sure you are :)
if you have T1 and T9999999 it's a wrong implementation to have 9999999 entries in memory and read/write/query them one at a time
err - I meant tool table size up there
so we need something other than tool number - and we have it - pockets
I think it's much more ok to have a smallish number of pockets
I bet skunkworks K&T has a 64-tool changer
56 is too low for a few machines, but it can be bigger (as has been demonstrated)
that had the big chain that goes around the top, didn't it?
you have to change the mumble.nml file
oh, just increase the max buffer size?
that may not be so bad
I think it is 60
>55 or 56 at any rate
I love it when I move the mouse and the cursor goes the wrong way
jepler: so if the mazak was changed to be random, it would work better because you don't need the piece of infomration you don't have upon startup (namely, which pocket the current spindle tool came from). instead of needing that, you only have to put it somewhere and remember where
I wonder which system has a saner way of setting up tooling for a new job (original or random)
in the old system you determine a free pocket/tool number, use T#M6 to load it, and then put the new tool in the spindle?
I think they are pretty similar - with random, you make the tool table entries first, then insert the tools
yeah, that's an interesting question. when does the tool table get saved?
you can only load T1M6 if T1 is in the tool table?
hmmm. how do you load T3720?
does that require a hand-edited file?
I described the procedure in my mail to emc-devel
ok. I should read that :)
yes you must edit the file to add new tools
so at this point what isn't covered is "return to old pocket" toolchangers, like the ones that arrange the tools in a row at the edge of the table, returning the old tool before picking up the new tool?
yes, and that is no better or worse than before
you could use the tool number to find the pocket, ignoring emc's pocket number manipulations?
when you do a prep, you get the tool and pocket values both in hal
it's interesting that the canon call is LOAD_TOOL(int) but that int is not used for anything
it would be great to have LOAD_TOOL(float nominal_radius, float radius_tolerance, float min_length, float max_length)
T[spot drill] M6
I'm entirely serious
it could find the matching description
more like LOAD_TOOL(size) which returns compensation numbers
that would be cool actually
integer tool descriptions suck
I just wish somebody would hurry up and make a totally new CNC control that uses hal and existing components/drivers, but rewrites the rest
that's a project for another day
we can tell them they're allowed to call it emc2009 and then we can retire
royalties from the naming agreement should keep us comfortable
nah, I need my emc paycheck
SWPadnos_ is now known as SWPadnos
neat. I had cherry-picked a fix so it was on my branch and also master. that does not confuse the merge. it must keep track.
jepler: for my not related cleanups from where is better to create branch?
I think it will be ok to branch from master?
jepler: what to enter after resolve confilicts of cherry-pick ? can't find it
after fixing the conflict, 'git add' it
Automatic cherry-pick failed. After resolving the conflicts,
mark the corrected paths with 'git add <paths>' or 'git rm <paths>' and commit the result.
When commiting, use the option '-c 7a48f78' to retain authorship and message.
(of course, the -c option to use depends on what you cherry-picked)
// JOINT_MAX_* are used to send limits to motion
- extern double JOINT_MAX_VELOCITY[EMCMOT_MAX_JOINTS];
- extern double JOINT_MAX_ACCELERATION[EMCMOT_MAX_JOINTS];
+ // extern double JOINT_MAX_VELOCITY[EMCMOT_MAX_JOINTS];
+// extern double JOINT_MAX_ACCELERATION[EMCMOT_MAX_JOINTS];
delete. don't comment out.
looking at many of these changes, it seems at first that they should be applicable to master but they have joints stuff mixed up in them.
"for safety" indeed