Back
[00:00:29] <cradek> iotask is so ridiculous
[00:00:53] <cradek> sometimes I think it was made ridiculous on purpose
[00:01:36] <cradek> well, regular task is that way too
[00:13:25] <mozmck> cradek: what's ridiculous about it?
[00:39:31] <SWPadnos> I like the idea that the toolchanger might give you a random tool :)
[00:40:14] <mozmck> heh, nothing like a little surprise huh?
[00:56:43] <SWPadnos> sigh. of all the times for DigiKey's credit card processing system to go down
[00:56:50] <SWPadnos> this is not the ideal one
[01:14:54] <jepler> that doesn't mean it's free?
[01:35:15] <stustev> while we are talking about the tool changer and tool table let's entertain another thought
[01:35:42] <stustev> I would like to see the tool table use the same name as the .ngc file
[01:35:52] <stustev> should not be difficult?
[01:54:51] <jepler> well, that's not the way it works now..
[01:55:17] <jepler> iotask doesn't know about the current part program at all
[01:55:24] <jepler> and what tool file do you have in mdi?
[01:55:39] <jepler> what do you do if you change from a program with a program-specific tool table to no program-specific tool table?
[01:55:46] <jepler> .. those are some of the questions that I have right away
[02:08:12] <SWPadnos> how do you deal with named subroutines in separate files, or inclusion of files in other circumstances?
[02:08:29] <SWPadnos> (ie, if we ever add an "include" directive)
[02:23:58] <stustev> named subroutines would be ignored - included files would be ignored
[02:24:21] <stustev> the file test.ngc would cause the file test.tbl to be called
[02:36:48] <cradek> stustev: you can pretty much embed your tool table with G10 L1 commands in the ngc file
[02:41:09] <cradek> although I don't see how you'd adjust lengths and stuff like that
[02:51:51] <stustev> 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.
[02:53:30] <cradek> I see
[02:55:28] <cradek> so you don't want to edit the gcode file itself.
[02:55:51] <cradek> do we have anything that works like include? if so you could include the file containing the G10 L1 commands.
[03:01:59] <jepler> O-calls are said to be able to go into other files, but I don't know much about that
[03:03:23] <SWPadnos> 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)
[03:03:45] <SWPadnos> and O<number> mught do it too (loading e.g. 237.ngc)
[03:03:48] <SWPadnos> might
[12:08:32] <jepler> 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
[12:09:10] <jepler> examples include: "Change global canon variables" and "A B C axes are unconditional now"
[12:09:31] <jepler> I haven't looked at all your recent checkins to figure out all of them
[12:11:26] <micges> with ABC you right
[12:13:13] <CIA-4> EMC: 03micges 07joints_axes3 * r41562f0e1350 10/src/emc/nml_intf/canon.hh: A B C axes are unconditional now
[12:13:13] <CIA-4> EMC: 03micges 07joints_axes3 * r1e89c003053b 10/src/emc/task/taskintf.cc: Update info only for existing joints
[12:13:14] <CIA-4> EMC: 03micges 07joints_axes3 * ra3e4459e2907 10/configs/sim/ (keystick.ini xemc.ini): Change sim keystick and xemc configs to run
[12:13:15] <CIA-4> EMC: 03micges 07joints_axes3 * r7a48f7850192 10/src/emc/ (nml_intf/canon.hh task/emccanon.cc): Change globals canon variables into one struct CanonConfig_t
[12:13:18] <CIA-4> 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
[12:13:21] <CIA-4> EMC: 03micges 07joints_axes3 * ra32e2884c0b9 10/src/emc/ (6 files in 3 dirs): Make AxisConfig structure locally in taskintf.cc
[12:13:24] <CIA-4> EMC: 03micges 07joints_axes3 * r8c81007145d7 10/src/emc/ (4 files in 3 dirs): Make global TrajConfig now locally in taskintf.cc
[12:13:27] <CIA-4> EMC: 03micges 07joints_axes3 * rcba76a2e3b4b 10/src/emc/ (6 files in 4 dirs): Create global structure for TRAJ config values
[12:13:30] <CIA-4> EMC: 03micges 07joints_axes3 * rbcf21942d707 10/src/emc/ (6 files in 3 dirs): Remove redefines of EMCMOT_MAX_DIO and EMCMOT_MAX_AIO
[12:16:34] <micges> with canon I've do this to make sure of all relations with canon<=> taskintf globals
[12:16:55] <micges> but right its not directly related
[12:17:11] <jepler> then it doesn't belong on a topic branch
[12:17:32] <jepler> or, it doesn't belong on a topic branch where the topic is "joints_axes3"
[12:19:07] <micges> is it possible to revert both wrong you mentioned?
[12:19:34] <jepler> first, decide where the change should really have been made: master, or a new topic branch.
[12:19:48] <jepler> if it's a new topic branch (canon_cleanup?) then create it.
[12:19:56] <jepler> then cherry-pick those commits to the branch
[12:20:02] <jepler> then merge that branch into joints_axes3
[12:20:24] <jepler> 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
[12:21:34] <micges> ok
[12:22:41] <micges> those two bad commits can be left? I'll do beter next time
[12:23:01] <jepler> it won't cause a problem to leave them there
[12:23:24] <jepler> and I am not sure it is just those two commits. those are the two that I looked at first.
[12:24:09] <jepler> 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,
[12:25:01] <jepler> just based on the change message, "remove redefines" is probably another one that should be on a different branch
[12:25:43] <jepler> bbl, time to go to the office
[12:30:48] <micges> I see whole six commit not belong :/
[12:31:06] <micges> commits*
[13:43:51] <micges> jepler: i'll fix it
[13:45:26] <jepler> micges: thanks. if you need any help with using git, please ask
[13:57:17] <micges> jepler: git can delete commits?
[13:57:29] <jepler> not after you've pushed them.
[13:57:35] <jepler> after you've pushed a commit, it can never be changed.
[14:00:03] <micges> so best thing is create branch for my 'additional work' , delete them from ja3, and then merged them from 'additional'?
[14:00:14] <jepler> you never delete anything
[14:00:38] <micges> delete I mean remove from source
[14:00:40] <jepler> you make the commits again on a new branch (using git cherry-pick it's usually very quick)
[14:00:51] <jepler> then on joints_axes3 you merge the new branch
[14:01:22] <jepler> 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
[14:02:01] <micges> I see now
[14:03:27] <micges> bbl lunch
[14:40:52] <skunkworks_> cradek: how far away is your mill?
[14:41:04] <cradek> 300 mi
[14:47:56] <skunkworks_> you know it is an addiction - right?
[14:48:00] <skunkworks_> :)
[14:48:06] <cradek> ha, I don't want to talk about that
[14:48:25] <cradek> "you are selling the old one ... right? ... right?"
[14:49:13] <skunkworks_> That never even crossed my mind ;)
[14:49:21] <skunkworks_> why would you do that ;)
[14:51:58] <cradek> the bp is one heck of a drill press
[14:53:01] <skunkworks_> bp will probably stay with its controller now? (unless it just totally dies)?
[14:53:20] <cradek> yeah, I think it's not worth the time or money to retrofit
[14:53:32] <skunkworks_> cradek: what are the specs on the servos? (on the mori?)
[14:53:54] <cradek> I don't know
[14:54:06] <cradek> they look big
[14:54:11] <cradek> it rapids very fast
[14:54:45] <cradek> 590 ipm on xy, it says
[14:54:51] <skunkworks_> yikes
[14:55:17] <skunkworks_> do you know if you get the amps?
[14:55:24] <cradek> yes
[14:55:28] <skunkworks_> nice
[14:55:34] <cradek> amps, servos, spindle drive
[15:35:52] <alex_joni> cradek: new mill?
[15:43:29] <cradek> yes, working on arranging shipping now
[16:10:41] <cradek> 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.
[16:12:45] <jepler> hm the first one I hadn't noticed
[16:14:19] <jepler> some days I think axis could use a good reaming, other days I think it's better to touch it as little as possible
[16:14:27] <jepler> and the latter always wins
[16:45:53] <cradek> http://pastebin.ca/1502201
[16:46:12] <cradek> jepler: I'm running into this a lot. In this situation I want to commit everything except configs/sim/axis.ini
[16:46:34] <cradek> git add src/git commit -a give me all that other crap too - what incantation do I want?
[16:46:58] <jepler> git add -u src?
[16:47:17] <cradek> !!
[16:47:18] <cradek> thanks
[16:49:14] <cradek> strange - actually it's not the Z view, it's perspective but rotated to put the viewpoint along Z
[16:50:44] <CIA-4> 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.
[16:52:11] <cradek> 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.
[16:52:51] <cradek> but for nonrandom and manual, the pocket numbers still swap around
[16:53:18] <jepler> maybe it doesn't matter?
[16:53:33] <cradek> yeah I wonder about that
[16:54:07] <cradek> 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
[16:54:24] <cradek> there should be a 1:1 big-toolno:pocket mapping
[16:55:21] <SWPadnos> at the moment, the entire tool table is loaded in one fell swopp (with an NML "load tool table" message), right?
[16:55:30] <cradek> yes
[16:55:36] <cradek> it's loaded and saved all at once
[16:55:38] <SWPadnos> or individual tool entries can be changed via the G10L1 (>) construct in G-code?
[16:55:48] <cradek> both
[16:55:53] <SWPadnos> right
[16:55:55] <cradek> the entire table is rewritten when you do that
[16:56:44] <SWPadnos> and there's a corresponding "change one entry" NML Command
[16:56:52] <cradek> yes
[16:56:55] <SWPadnos> cool
[16:57:18] <SWPadnos> I'm thinking about the case where the GUI is on a separate machine from the control
[16:57:38] <SWPadnos> and file name/location issues
[16:58:05] <cradek> that's no better or worse than before
[16:58:06] <SWPadnos> 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)
[16:58:09] <SWPadnos> right
[16:58:25] <SWPadnos> I'm thinking about how to make it better, or at least guarantee it's not worse :)
[16:59:06] <cradek> the tool table is mixed duty - human readable/editable, and also read and written by iotask
[16:59:11] <SWPadnos> yes
[16:59:35] <cradek> now that I type it, I see that is a lot like the gcode program
[16:59:58] <SWPadnos> 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)?
[17:00:05] <cradek> yes
[17:00:09] <SWPadnos> ok
[17:00:18] <SWPadnos> so I'd deprecate that, and use only the "set single tool" function
[17:00:43] <SWPadnos> that would eliminate what I see as the main limitation on tool size
[17:00:53] <cradek> I'm not smart enough to change that
[17:01:08] <SWPadnos> a "helper function" would be needed which would iterate over the tool table file and call the "set one tool" function as needed
[17:01:14] <SWPadnos> heh. sure you are :)
[17:01:31] <cradek> 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
[17:01:32] <SWPadnos> err - I meant tool table size up there
[17:01:38] <SWPadnos> I agree
[17:01:54] <cradek> so we need something other than tool number - and we have it - pockets
[17:02:11] <cradek> I think it's much more ok to have a smallish number of pockets
[17:02:32] <SWPadnos> I bet skunkworks K&T has a 64-tool changer
[17:02:35] <cradek> 56 is too low for a few machines, but it can be bigger (as has been demonstrated)
[17:02:42] <SWPadnos> that had the big chain that goes around the top, didn't it?
[17:02:44] <cradek> you have to change the mumble.nml file
[17:02:52] <cradek> ... somehow
[17:02:55] <cradek> bbl, lunch
[17:02:56] <SWPadnos> oh, just increase the max buffer size?
[17:02:58] <SWPadnos> ok
[17:02:59] <cradek> yes
[17:03:08] <SWPadnos> that may not be so bad
[17:15:14] <skunkworks_> I think it is 60
[17:15:30] <SWPadnos> >55 or 56 at any rate
[17:16:08] <SWPadnos> I love it when I move the mouse and the cursor goes the wrong way
[17:53:07] <cradek> 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
[17:54:31] <jepler> I wonder which system has a saner way of setting up tooling for a new job (original or random)
[17:55:28] <jepler> 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?
[17:55:29] <cradek> I think they are pretty similar - with random, you make the tool table entries first, then insert the tools
[17:55:45] <SWPadnos> yeah, that's an interesting question. when does the tool table get saved?
[17:55:48] <cradek> right
[17:56:22] <jepler> you can only load T1M6 if T1 is in the tool table?
[17:56:30] <cradek> jepler: yes
[17:57:03] <SWPadnos> hmmm. how do you load T3720?
[17:57:20] <SWPadnos> does that require a hand-edited file?
[17:57:22] <cradek> I described the procedure in my mail to emc-devel
[17:57:30] <SWPadnos> ok. I should read that :)
[17:57:32] <cradek> yes you must edit the file to add new tools
[17:57:32] <SWPadnos> again
[17:58:02] <SWPadnos> ok
[17:58:32] <jepler> 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?
[17:59:00] <cradek> yes, and that is no better or worse than before
[17:59:28] <jepler> you could use the tool number to find the pocket, ignoring emc's pocket number manipulations?
[18:00:00] <cradek> yes
[18:00:22] <cradek> when you do a prep, you get the tool and pocket values both in hal
[18:02:12] <cradek> it's interesting that the canon call is LOAD_TOOL(int) but that int is not used for anything
[18:02:27] <SWPadnos> heh
[18:03:32] <SWPadnos> it would be great to have LOAD_TOOL(float nominal_radius, float radius_tolerance, float min_length, float max_length)
[18:03:52] <cradek> LOAD_TOOL(string description)
[18:03:56] <SWPadnos> heh
[18:03:59] <cradek> T[spot drill] M6
[18:04:03] <cradek> I'm entirely serious
[18:04:06] <jepler> T#<spot_drill>
[18:04:10] <cradek> it could find the matching description
[18:04:12] <SWPadnos> more like LOAD_TOOL(size) which returns compensation numbers
[18:04:30] <SWPadnos> that would be cool actually
[18:04:38] <SWPadnos> T<rougher>
[18:04:43] <cradek> integer tool descriptions suck
[18:04:46] <SWPadnos> yep
[18:05:18] <jepler> 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
[18:05:19] <SWPadnos> bbl
[18:05:22] <cradek> that's a project for another day
[18:05:34] <jepler> we can tell them they're allowed to call it emc2009 and then we can retire
[18:05:47] <jepler> royalties from the naming agreement should keep us comfortable
[18:05:48] <cradek> nah, I need my emc paycheck
[18:19:16] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[18:33:52] <cradek> 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.
[18:57:34] <micges> jepler: for my not related cleanups from where is better to create branch?
[18:59:21] <micges> I think it will be ok to branch from master?
[18:59:29] <jepler> yes
[20:04:51] <micges> jepler: what to enter after resolve confilicts of cherry-pick ? can't find it
[20:06:10] <jepler> after fixing the conflict, 'git add' it
[20:08:55] <jepler> Automatic cherry-pick failed. After resolving the conflicts,
[20:08:55] <jepler> mark the corrected paths with 'git add <paths>' or 'git rm <paths>' and commit the result.
[20:08:58] <jepler> When commiting, use the option '-c 7a48f78' to retain authorship and message.
[20:18:08] <jepler> (of course, the -c option to use depends on what you cherry-picked)
[20:22:17] <jepler> // JOINT_MAX_* are used to send limits to motion
[20:22:18] <jepler> - extern double JOINT_MAX_VELOCITY[EMCMOT_MAX_JOINTS];
[20:22:18] <jepler> - extern double JOINT_MAX_ACCELERATION[EMCMOT_MAX_JOINTS];
[20:22:18] <jepler> + // extern double JOINT_MAX_VELOCITY[EMCMOT_MAX_JOINTS];
[20:22:19] <jepler> +// extern double JOINT_MAX_ACCELERATION[EMCMOT_MAX_JOINTS];
[20:22:21] <jepler> delete. don't comment out.
[20:23:52] <jepler> 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.
[20:23:59] <jepler> oh well
[22:49:22] <jepler> wow:
http://pastebin.ca/1502558
[22:49:31] <jepler> "for safety" indeed
[22:51:48] <BigJohnT> beats me