Back
[09:52:17] <KGB-linuxcnc> 03Francis Tisserant 05v2.5_branch 53b4cae 06linuxcnc 10docs/src/config/stepconf_fr.txt 10docs/src/gcode/gcode_fr.txt 10docs/src/hal/basic_hal_fr.txt 10docs/src/hal/pyvcp_fr.txt French doc. update to follow John * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=53b4cae
[10:52:28] <micges> seb_kuzminsky: hi
[10:52:46] <micges> seb_kuzminsky: mesaflash supports 7i90 flashing
[11:11:53] <seb_kuzminsky> hey micges
[11:11:55] <seb_kuzminsky> neat!
[11:26:53] <micges> seb_kuzminsky: I must only clean command line options (got a little messy with all boards supported)
[11:27:07] <seb_kuzminsky> heh
[11:27:16] <seb_kuzminsky> did you merge the debian packaging commits i sent you?
[11:27:29] <seb_kuzminsky> that's mesaflash3, right?
[11:27:36] <micges> not yet
[11:27:39] <micges> yes
[11:27:44] <seb_kuzminsky> ok
[12:21:51] <KGB-linuxcnc> 03Francis Tisserant 05v2.5_branch 6f07a96 06linuxcnc 10docs/src/index_fr.tmpl French doc. update: added a link to Contributing to LinuxCNC * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6f07a96
[17:35:51] <andypugh> I am quite a long way down the line towards an unlimited-size tool database, moving the tool data out of NML and into an SQL database. (Those at Wichita will have seen this already, I am only a little further along now than then).
[17:36:54] <andypugh> I am actually at a stage where I could probably push a branch that works just like LinuxCNC does now, except with no limits on tool table size.
[17:37:31] <andypugh> But, on reflection, I don't think I like it.
[17:40:23] <seb_kuzminsky> that's cool, andy
[17:40:42] <andypugh> The current idea is that you define a database structure and a "query file" in the INI. The database structure is standard SQL, the "query file" is a strange mix of XML and SQL, where many individual SQL queries are organised by sql-like tags, and a Python library knows how to pull out a query, subsitute-in the required values, and return a result.
[17:40:55] <seb_kuzminsky> the thing that annoys me the most about the current tooltable implementation is that the api is not well defined - it's not a clean interface
[17:41:25] <seb_kuzminsky> hrrm... that sounds strange
[17:42:00] <andypugh> Well, I have a clean API, but that is part of the problem. You can only do things to the tool table that my Python library knows about, and that also exists in you SQL query file...
[17:43:00] <andypugh> Part of what bothers me is that actually the interface between the Python code and C++ is rather untidy.
[17:43:30] <andypugh> (Possible solution, code the database access code in C++ instead).
[17:43:58] <andypugh> But part of this was to make it easier for folk to modify the tool database implementation.
[17:45:32] <andypugh> Currently I am trying to support both an almost exact copy of the current database and the rather more all-encompassing database that we came up with earlier in the year.
[17:46:48] <andypugh> But I am thinking perhaps I should drop that part, and just say "we think that this database covers all possible situations, you have to use this structure, but you can change how you access and use it"
[17:48:21] <andypugh> If I do that, then the C++ code can run database queries natively, without going via Python.
[17:49:53] <andypugh> Having said that, it is only iocontrol.cc that is bothering me at the moment, And I want to pull the tool handling there out, and put it into a HAL module.
[17:49:55] <seb_kuzminsky> how modular are you making the tooltable interface?
[17:50:16] <andypugh> I suspect _too_ modular.
[17:50:48] <seb_kuzminsky> could the sql queries be hidden behind the api, as part of the modular tooltable handler?
[17:51:19] <andypugh> hence the query-module so that the same API can get data from any database structure.
[17:51:47] <seb_kuzminsky> i guess i dont understand the new architecture you're working on
[17:51:56] <andypugh> I am not sure I do :-)
[17:53:20] <andypugh> I started down this path expecting tear-ups along the way, I think my question is whether I should finish andpush (in a branch) what I think is a dead-end.
[17:58:23] <andypugh> The problem with the catch-all database is that it makes tooledit look a bit funny.
[18:00:10] <andypugh> Though I guess that tooledit only really needs to see the tools by default, and the other stuff (which tool is in which magazine, which spindle can access which magazine) can be deeper down and, in fact, not even dispayed when unambiguous.
[18:01:24] <andypugh> It might even make sense for me to switch to working on tooledit, as that is likely to clarify the requirements.
[18:01:38] <Tom_itx> you're not dealing with the changer separately?
[18:02:37] <andypugh> Yes, and no.
[18:02:52] <Tom_itx> load the tools into the table and handle the prefetch order with changer code
[18:03:49] <andypugh> Step 1 is to demonstrate that sql can work identically to the current implementation. Actully mah has already done this, and deleted iocontrol, in one of his remap examples !
[18:03:52] <Tom_itx> the changer code could be hidden
[18:05:20] <andypugh> As I see it, a requirement for making this work "properly" (as I see it) is for a selecatble HAL module to be able to field the TOOL_SELECT and TOOL_CHANGE etc NML commands.
[18:06:18] <andypugh> A C or C++ module can do this (I think) but then integrators/users can't tweak to suit.
[18:06:51] <andypugh> As far as I know Python HAL modules can't field NML commands.
[18:07:56] <andypugh> if/when NML is replaced this limitation should go away
[18:08:56] <andypugh> Then something equivalent to iocontrol.cc will be a HAL module, like HALUI, but (I guess) loaded by default.
[18:09:37] <andypugh> Then, the integrator can (for example) choose to change tool on T, not M6.
[18:10:17] <Tom_itx> prefetch?
[18:10:33] <andypugh> Probably not.
[18:10:50] <Tom_itx> why would you change tool on T?
[18:10:56] <andypugh> Lathe
[18:12:20] <Tom_itx> lathe recognizes M6 as well doesn't it?
[18:12:44] <Tom_itx> i could see using T as a prefetch
[18:12:47] <andypugh> In LinuxCNC, yes. Not in Fanuc.
[18:12:51] <Tom_itx> on a separate line
[18:13:08] <Tom_itx> i'm looking at an okuma pocket reference showing M6 as toolchange
[18:13:26] <andypugh> Pre-fetch makes no sens on a lathe. T as pre-fetch already works in LinuxCNC
[18:14:00] <Tom_itx> some complex machines would use that
[18:14:05] <Tom_itx> not many
[18:17:43] <andypugh> I am trying to cover all the bases. Multiple tools in the same pocket (with their own offsets). Multiple pockets with the same tool...
[18:18:26] <Tom_itx> multi pockets with the same tool would be dynamic
[18:18:33] <Tom_itx> the offsets would follow the tool
[18:18:37] <andypugh> Yes.
[18:19:03] <Tom_itx> i'm not sure about multi tool pockets
[18:19:11] <Tom_itx> where would you use that?
[18:20:39] <andypugh> The multi-pocket tool use-case is not caring _which_ 6mm end-mill you get, as long as a) Your spindle can access it, and b) It's not marked as broken.
[18:22:15] <Tom_itx> would that better fall into a place where you touch off the new tool ( a feature many have asked for ) then resume cutting
[18:22:16] <andypugh> The multi-tool pocket is actually more common. Gang tooling on a lathe, or a mill woodruff cutter defined by top, bottom or middle as the offset basis
[18:23:02] <andypugh> Yes, a big part of this work is to make the tool data more "live" than it is now.
[18:23:37] <andypugh> (Which is horribly complicated when you consider preview and readahead...)
[18:23:42] <Tom_itx> i just haven't run across 'multi-tool pocket' yet
[18:25:19] <Tom_itx> back up a line before the currently executed line and resume, restarting any readahead?
[18:25:57] <Tom_itx> i'm sure code wise it _is_ a mess
[18:27:01] <andypugh> Yes. For example the Axis preview runs through the code. It needs to accurately preview the tool offfsets, but not _change_ the tool offsets. So can it write to the database or not?
[18:27:29] <Tom_itx> i wish i was a better programmer, this sounds fun in a demented way
[18:27:50] <andypugh> If there is a G10 in the code, then how do we "unwrap" that from preview to run-time?
[18:28:15] <Tom_itx> mind you, i haven't looked at any of the code
[18:28:42] <andypugh> I have, and I can't follow it, at the moment.
[18:29:48] <andypugh> Anyway, Danimal (not seen for too long) Used to machine his sprockets using two sides of the same insert, represented as two tools, but in the same physical holder.
[18:30:04] <Tom_itx> hmm
[18:30:37] <andypugh> Once you start looking at it, nearly anything mad can make sense in some situations.
[18:30:38] <Tom_itx> i think we (on the okuma) rotated the insert and reset the offset
[18:31:00] <Tom_itx> then resumed
[18:31:35] <andypugh> You can handle it in the toolchanger code by simply choosing to interpret T2 and T22 as meaning the same thing.
[18:32:17] <Tom_itx> what would flag the change?
[18:32:45] <andypugh> That's the point. There is no chabge
[18:32:53] <andypugh> Or even, no change
[18:34:09] <andypugh> So, if you have T2 loaded and issue a T22 the changer returns immediately and says "you got it" then on M6 G43 the offets chance to match the other cutting edge.
[18:35:07] <Tom_itx> i know that we never pre'measured all edges of an insert
[18:35:22] <Tom_itx> we would reset the offset after we changed it
[18:35:36] <Tom_itx> what if the operator rotated the insert the wrong way?
[18:35:47] <Tom_itx> for example
[18:36:08] <Tom_itx> or dropped it in the shavings and had to get another one
[18:36:22] <andypugh> Different situation
[18:39:21] <andypugh> Imagine you are in the sprocket making trade, and you use a holder with a triangular tip, with one tip pointing straight back at the operator. You machine one flang of your sprocket with one tip, then the other side with a different tip (and ignore the third one)
[18:40:10] <andypugh> So, at any one time you have two different offsets for the same toolholder.
[18:40:22] <Tom_itx> i was under the assumption the tip would be symetrical
[18:40:49] <andypugh> It is. But the tips are in different positions in space
[18:40:50] <Tom_itx> you're suggesting a modified tool?
[18:41:11] <Tom_itx> i see what you mean
[18:41:24] <Tom_itx> we never did that but i suppose it could be done
[18:41:30] <Tom_itx> we'd just call up another tool
[18:42:01] <Tom_itx> did danimal suggest such a thing?
[18:42:06] <andypugh> That's the point, it _is_ a different tool. But the toolchanger has nothing to do
[18:42:47] <andypugh> The tool changes, the "pocket" stays the same
[18:43:09] <Tom_itx> so instead of calling T1 M6 H1 to T1 M6 H11 you would just call the offset?
[18:43:34] <Tom_itx> or whatever offset you're using
[18:43:50] <andypugh> That way works too.
[18:44:16] <Tom_itx> i was just trying to see if you were overcomplicating it
[18:44:24] <Tom_itx> i can see what you mean now
[18:44:32] <Tom_itx> nothing i've ever done though
[18:44:38] <andypugh> (Hmm, actually, it's G43 that takes the H-word isn't it?)
[18:44:51] <Tom_itx> i'd have to look
[18:44:58] <Tom_itx> sounds right
[18:45:08] <cradek> yes you'd just load your new G43 with a different H (I've done exactly that)
[18:45:36] <Tom_itx> that was my wonder about changing the T2 to T22
[18:45:38] <Tom_itx> was all
[18:45:48] <Tom_itx> just change the offset
[18:46:18] <andypugh> I think Tn then G43 (some other number) works too, though you have to define tools that don't actually exist, and they have to have imagibnary pockets too)
[18:46:24] <Tom_itx> and it wouldn't work on some, we had one with 99 and another with 119 tools
[18:46:34] <Tom_itx> so it would actually go to T22
[18:47:31] <Tom_itx> if you're dealing with offsets and not tools it makes sense to me to change the offset
[18:47:47] <Tom_itx> s/tools/tool positions
[18:48:36] <Tom_itx> the multi pocket tool makes perfect sense to me
[18:48:51] <Tom_itx> that's common especially on prefetch changers
[18:49:41] <andypugh> Currently LinuxCNC is confused by an offset which doesnt belong to a tool.
[18:50:16] <Tom_itx> so you can't have defined offsets without an associated tool?
[18:50:21] <andypugh> One tool, one offset, one pocket.
[18:50:56] <Tom_itx> One tool, multi offsets, multi pockets makes sense to me
[18:50:59] <andypugh> And woe betide you if you accientally try to load a tool that is only a placeholder for an offset :-)
[18:51:32] <Tom_itx> define the offset multiple in the ini
[18:51:40] <Tom_itx> so it's well out of the tool range
[18:51:42] <andypugh> The plan is that ToolID is unique, but that the T-number could call up any number of equivalent toools.
[18:52:32] <cradek> andypugh: I'm glad you're back to thinking about this.
[18:53:14] <Tom_itx> i'm just feeding input here... no intention to discredit what you're doing
[18:54:50] <Tom_itx> it would take an advanced user to access this anyway
[18:55:47] <andypugh> I will probably push a branch this weekend that shows that it can work. Though I would hesitate to guarantee that obsure parts of the code are not still accessing the actual tool file.
[18:57:15] <andypugh> One obvious test I need to do is a sequence of moves with a G43 between them. The "what offset is current when" stuff is the real issue I need to sort out.
[18:58:13] <Tom_itx> you would in effect have offsets changing in 2 places
[18:58:51] <Tom_itx> that's why i suggested changing the offset instead of the tool
[18:59:12] <andypugh> Then if you want the operator to be able to tweak the offsets of a live tool to keep inside his tolerances...
[18:59:25] <Tom_itx> it would work the same
[18:59:42] <Tom_itx> H1 H11 would not interfere with each other
[18:59:54] <andypugh> But if readhead is already at the end of the program?
[18:59:55] <Tom_itx> you change the value of H1 for wear, H11 remains
[19:00:06] <Tom_itx> then you're screwed
[19:00:36] <Tom_itx> or you stop at what the _actual_ last executed line was
[19:00:51] <andypugh> "You're scewed" isn't normally acceptable on a commit description
[19:01:03] <Tom_itx> i dunno if the code keeps track of that information
[19:01:11] <Tom_itx> heh probably not
[19:01:58] <Tom_itx> it works similar to a keyboard buffer
[19:02:17] <Tom_itx> but you want to be able to stop at the last letter typed and resume from there
[19:02:17] <andypugh> No, it doesn't/
[19:03:04] <andypugh> GUI preview is a big issue, and readahead is another.
[19:03:40] <Tom_itx> does preview show lookahead or actual?
[19:03:56] <Tom_itx> it should show actual
[19:04:22] <andypugh> In fact, if I knew then what I know now, I woulf probably have kept well away from this issue, and let a proper programmer pick it up, or not. I only own 20 tools, I don't need this.
[19:05:09] <Tom_itx> well, you're braver than I
[19:05:55] <andypugh> My error was in announcing that I was working on it. It makes it harder to back away.
[19:06:27] <andypugh> I might well stil just announce "Sorry, too hard for me"
[19:06:35] <Tom_itx> naw, just hail the next venture louder