Back
[14:52:53] <rayh> oh we have a logger now.
[14:52:57] <SWPadnos_> heh
[14:53:01] <SWPadnos_> been there for a while
[14:53:03] <SWPadnos_> Hi
[14:53:10] <rayh> logger_devel bookmark
[14:53:25] <rayh> logger_devel: bookmark
[14:53:25] <rayh> See
http://solaris.cs.utt.ro/irc/irc.freenode.net:6667/emcdevel/2005-12-06#T14-53-25
[14:53:25] <SWPadnos_> try that with a comma or colon
[14:53:32] <rayh> that's better.
[14:54:17] <SWPadnos_> ok - about a month
[14:55:26] <rayh> How you doing today SWPadnos ?
[14:56:33] <SWPadnos_> ok - you?
[14:59:22] <rayh> cold as xxxx here.
[14:59:40] <SWPadnos_> It's a balmy 27 degrees herel
[14:59:45] <rayh> car wants to fight over starting
[14:59:57] <rayh> balmy -27 coming your way.
[15:00:03] <SWPadnos_> oh great
[15:00:18] <SWPadnos_> maybe I should clean out the second half of the garage so I can park inside
[15:00:24] <rayh> might stay north of you if we get another tropical storm.
[15:01:10] <rayh> I'm fighting with a clean way to nav through hal_show
[15:01:14] <SWPadnos_> well - that would be nice
[15:01:39] <SWPadnos_> I came up with a tcl line that works - I can print any of the parts of a pin or param
[15:01:47] <rayh> don't know if you saw the signal menu
[15:01:59] <rayh> really. a general purpose search
[15:02:36] <SWPadnos_> not quite that, but it gets rid of some of the quirks of halcmd show (like the extra hex value that sometimes gets printed)
[15:02:42] <SWPadnos_> exec bin/halcmd $cmd $what | sed -e {s/ (..) //} | awk {{ printf "%-42s = %-14s\n",$5,$4 }} | grep -F "$pattern"
[15:03:02] <SWPadnos_> the awk part can be changed to print any of the fields, in any order
[15:03:17] <SWPadnos_> (fields being name, owner, direction, value, type)
[15:04:50] <rayh> I see $cmd, $what and $pattern are these the things we can manipulate
[15:05:10] <SWPadnos_> there are probably ways to have tcl do most of the work there - the only real magic is the sed part, which removes the extra value printed for U16 and U8
[15:05:14] <SWPadnos_> yes
[15:05:27] <SWPadnos_> actually, cmd would need to be "show" like you had it
[15:05:40] <rayh> okay
[15:05:41] <SWPadnos_> what should be pin or param or all
[15:06:10] <rayh> got it.
[15:06:13] <SWPadnos_> pattern is a string that gets matched anywhere (not only in the name - I'm working on that)
[15:07:09] <rayh> The display pattern I was using in hal_show is getting very awkward.
[15:07:31] <SWPadnos_> uh - what? :)
[15:07:33] <rayh> once you get beyond a 3 axis minimill it gets huge.
[15:07:37] <SWPadnos_> yes
[15:08:28] <SWPadnos_> in fact, the stock ppmc ini has something like 267 params, and 160 or so pins
[15:08:37] <SWPadnos_> without classicladder
[15:09:01] <rayh> I've got it so that I can "watch" a set of pins selected by check buttons from the list
[15:09:26] <rayh> or sigs
[15:09:34] <SWPadnos_> incidentally, we (jmk and I) did some benchmarks last night
[15:09:45] <rayh> and the results
[15:09:58] <SWPadnos_> using bash, you can spawn about 100 processes / second
[15:10:15] <SWPadnos_> it's around 5-10 ms per exec
[15:10:25] <SWPadnos_> I didn't try in tcl, but I imagine it's no faster
[15:10:54] <rayh> okay.
[15:11:04] <SWPadnos_> so there's no way you'll be able to exec halcmd for every pin or param value you want to watch
[15:11:08] <rayh> the default "watch" command repeats at 2 sec intervals.
[15:11:39] <SWPadnos_> ok - that's still a pretty heavy load
[15:11:56] <SWPadnos_> I guess only 5% or so for 10 watches, so not too bad
[15:12:01] <rayh> if you say so
[15:12:30] <rayh> I'm looking for a way to "clump" your labview notion of bundle
[15:13:01] <rayh> a set of elements into a viewable or editable page.
[15:13:34] <SWPadnos_> yeah - it's a question of how much knowledge you want to put into the tcl program
[15:14:01] <SWPadnos_> I guess one way to do it is to search the names of the pins
[15:14:05] <rayh> The first show page works pretty well but then I understand how to read it.
[15:14:08] <SWPadnos_> the first part (before the first
[15:14:16] <SWPadnos_> the first part (before the first '.') is the module
[15:14:30] <rayh> except motmod
[15:14:36] <SWPadnos_> then possibly an instance number
[15:14:44] <rayh> which evolves into axis
[15:14:58] <SWPadnos_> well - you don't care about that - you want to provideeach axis as a separate entity
[15:15:00] <rayh> does it have other first things as well
[15:15:16] <SWPadnos_> axis.0.* should be one clump, probably
[15:15:35] <rayh> except that there is little to tune there
[15:15:41] <rayh> more in pid
[15:15:48] <SWPadnos_> nothing to tune, but lots to connect
[15:15:57] <rayh> Right.
[15:16:00] <SWPadnos_> (and not everything gets conected, so that's no help :( )
[15:16:22] <rayh> did you get anywhere with bundling at the linkxx level?
[15:16:29] <SWPadnos_> lots of axis.0 params though
[15:16:31] <SWPadnos_> nope
[15:16:39] <SWPadnos_> that will have to be later
[15:16:47] <rayh> no problem
[15:17:03] <rayh> Such a thing can be implemented here if we like
[15:17:07] <SWPadnos_> there are a number of things we want to do with hal, and it's really hard without msking a good library that can be called from multiple languages
[15:17:29] <rayh> right.
[15:17:53] <rayh> so in essence we are stuck with halcmd for now.
[15:18:09] <SWPadnos_> yep, I'd say that's the case
[15:18:18] <rayh> and about 100 calls to it per second
[15:18:33] <SWPadnos_> yes, or open a pipe and send it commands
[15:18:50] <rayh> would that be faster turn around.
[15:18:53] <SWPadnos_> that should be way faster
[15:18:58] <SWPadnos_> orders of magnitude
[15:19:06] <rayh> oh...
[15:19:25] <SWPadnos_> one sec - let me benchmark that ;)
[15:19:52] <rayh> well if we have a way to ensure proper shutdown...
[15:20:02] <SWPadnos_> yep
[15:20:37] <rayh> so we can close out the open before the emc.run tries to remove all the rt
[15:21:08] <SWPadnos_> yes, or so that the halcmd gets closed correctly, so realtime stop can work
[15:21:10] <rayh> that would be easy enough it we started hal_show from a tkemc menu
[15:21:43] <rayh> or a line in halcmd could say I'm going away, screw this pipe.
[15:22:05] <SWPadnos_> you'd still have to be monitoring it
[15:22:35] <rayh> You know, there are a couple of the menu things in tkemc that don't work here.
[15:22:42] <SWPadnos_> or have only one function that may talk to it, and closes the pipe if it sees that message
[15:22:49] <SWPadnos_> which?
[15:22:56] <rayh> perhaps it time to fix those and add this.
[15:23:03] <SWPadnos_> (not that I can help, but maybe if you talk about it, you'll figure it out ;) )
[15:23:27] <rayh> I've not done any tickle editing for emc2 so far.
[15:23:40] <rayh> there is tuning
[15:24:50] <SWPadnos_> how good is tcl at handling arrays (and regular expressions)?
[15:25:42] <rayh> arrays are simply strings with a common base name
[15:25:58] <SWPadnos_> hm - OK.
[15:26:03] <rayh> you can fake a x dimensional name
[15:26:26] <rayh> myarray(x,y,z)
[15:26:27] <SWPadnos_> that's what I'm thikning - 2-D arrays of pin stuff
[15:26:50] <SWPadnos_> an array of lists (or list of arrays)
[15:27:25] <rayh> arrays make the global command much easier
[15:27:37] <rayh> I'm not much good when it comes to namespaces
[15:28:24] <SWPadnos_> yeah - you load all pins / params once every time you change the HAL status (by loading or unloading a module)
[15:28:47] <rayh> Yes we will
[15:29:25] <rayh> so most of the whole thing needs to be inside a proc
[15:29:37] <SWPadnos_> yep
[15:30:01] <rayh> I looked at tabbed widgets but don't like em for this purpose
[15:30:09] <SWPadnos_> it's pretty easy to get awk and sed to return a nice string of data, in the order and format we want
[15:30:11] <rayh> Thinking more like a tree widget
[15:30:19] <SWPadnos_> a tree would be great
[15:30:29] <SWPadnos_> separate on each '.' in the names
[15:30:38] <SWPadnos_> branch, I mean
[15:30:50] <rayh> something like that should work
[15:31:27] <rayh> and would minimize the clicking to move stuff into linking and tuning
[15:31:57] <rayh> and watching
[15:31:58] <SWPadnos_> yep - also reduces screen real estate, since you only print the significat portion at each level
[15:32:31] <SWPadnos_> 'ppmc' or 'encoder' collapes down to a "level separator" in the tree
[15:32:33] <rayh> ah so we need to find a tree widget that expands.
[15:32:36] <SWPadnos_> collapse
[15:32:40] <SWPadnos_> yes
[15:33:30] <rayh> This will require an expansion to tk8.4
[15:33:45] <rayh> * rayh goes looking
[15:33:53] <SWPadnos_> http://www.bodenstab.org/
[15:34:07] <SWPadnos_> Tk Canvas tree widget
[15:34:27] <SWPadnos_> ported to tk8.4 -
http://www.bodenstab.org/files/tree-8.0.4.1.tgz
[15:34:54] <SWPadnos_> not sure it's what you want, but hey ;)
[15:35:27] <SWPadnos_> actually, it probably is what you want
[15:43:11] <rayh-yetanother> have time to take a look at this page
http://wiki.tcl.tk/14716
[15:43:34] <SWPadnos> I can look
[15:46:15] <SWPadnos> I wish he'd define what a "seed" or "fruit" are in that metaphor ';)
[15:46:20] <SWPadnos> the trees look nice though
[15:47:21] <SWPadnos> ok - it's further down (after the code)
[15:50:34] <alex_joni> hello
[15:50:39] <SWPadnos> hello
[15:50:45] <alex_joni> what's cookin?
[15:50:49] <alex_joni> smells like burning
[15:50:49] <rayh> phone
[15:50:59] <SWPadnos> ticklish things are afoot
[15:51:54] <alex_joni> later guys ;)
[15:51:58] <alex_joni> gotta head home
[15:51:59] <SWPadnos> see ya
[15:52:03] <alex_joni> yeah..
[16:02:30] <rayh-yetanother> back
[16:03:00] <rayh-yetanother> I remember now that Matt had made a cp2 that had a tree.
[16:03:21] <rayh-yetanother> The layout of the screen divided into three areas looks good to me.
[16:04:12] <rayh-yetanother> tree for nav, upper right for display, lower right for editing.
[16:16:40] <rayh> Wow. I'm amazed at how much work Matt put into that.
[16:51:21] <SWPadnos_> ugh - gotta reboot
[16:51:25] <SWPadnos_> brb
[17:15:54] <rayh> I'll apt-get the bwidget toolset and test the tree there.
[17:39:51] <SWPadnos_> hey rayh-yetanother, I'm back
[20:48:19] <SWPadnos> OK - I'm looking at Interpreter.hpp
[20:48:50] <SWPadnos> I think there should be support for non-text interpreters
[20:49:05] <SWPadnos> or, interpreters for non-textual formats
[20:49:43] <petev> elaborate
[20:50:15] <SWPadnos> well - suppose I have an interpreter for IGES files (just suppose)
[20:50:17] <petev> I was viewing the language model as line based to support MDI
[20:50:23] <petev> ok, hang on
[20:50:39] <petev> I think u keep mixing interp stuff with full conversational CAM
[20:50:43] <SWPadnos> nope
[20:50:44] <petev> I think the 2 are separate
[20:50:58] <petev> how can u machine from IGES?
[20:51:12] <petev> it's just a model, no MOPs specified
[20:51:36] <petev> I see a higer layer CAM that takes the IGES and works interactively
[20:51:46] <petev> it coverts to whatever the interp language is
[20:51:47] <SWPadnos> well - it has geometry, the machine has avaulable tools and spindle HP, the only thing missing is material type and / or surface roughness
[20:51:51] <petev> how do u see it?
[20:52:01] <SWPadnos> not with text - that's the point
[20:52:15] <SWPadnos> this gets back to the GUI / interpreter as a pair
[20:52:18] <petev> that is CAM, and very high end at that, u are talking about AI
[20:52:42] <SWPadnos> let me say why I'm coming at it this way
[20:52:44] <petev> most CAM packages still require the user to call out MOPS applied to regions, etc.
[20:52:49] <petev> ok
[20:53:00] <SWPadnos> ok - I have a friend who's a machinist
[20:53:05] <SWPadnos> mechanical engineer, actually
[20:53:27] <SWPadnos> he has been machining stuff since he was 8 years old (his grandfather was a toolmaker)
[20:53:50] <SWPadnos> this guy has two Bridgeports in his basement, and he just CNC'd one of them
[20:54:02] <SWPadnos> he looked at EMC, and decided against it for several reasons
[20:54:22] <SWPadnos> oh - let me say that he's a bright guy, and he isn't afraid of computers or Linux
[20:54:38] <SWPadnos> he builds his own, he overclocks (and does testing to be sure that it's stable), etc.
[20:54:50] <SWPadnos> he's played with Linux since RH 5.1 or so
[20:54:57] <SWPadnos> so none of that is a problem
[20:55:08] <SWPadnos> he finally settled on the $250 DeskCNC package
[20:55:15] <petev> why?
[20:55:22] <SWPadnos> (getting there ;) )
[20:55:31] <SWPadnos> are you familiar with DeskCNC?
[20:55:37] <petev> not really
[20:55:51] <SWPadnos> ok - it's a windows program and an external, serially connected, step generator
[20:56:07] <petev> ok
[20:56:37] <SWPadnos> the software has built-in engraving from BMP, built-in 3D machining from STL, 2.5D from DXF (or WMF, I think), etc
[20:56:40] <petev> looking at site now
[20:56:49] <SWPadnos> basically, you load the file you want to machine, and machine it.
[20:57:21] <SWPadnos> the software does internally convert to G-Code, and then runs the Gcode file through its interpreter
[20:57:26] <petev> that may work for very simple stuff
[20:57:29] <SWPadnos> so it just includes the CAM in the package
[20:57:40] <SWPadnos> it works for complex stuf as well, since it does STL files
[20:57:49] <petev> but I still don't see why this wouldn't be a layer on top of g-code or whatever
[20:57:55] <SWPadnos> he designs with SolidWorks, and takes the STL directly into DeskCNC
[20:58:05] <SWPadnos> it can be
[20:58:07] <petev> you need a lot more tool info and material info and coolant info to do AI MOPs
[20:58:31] <SWPadnos> I'm just thinking forward to another, as-yet-unknown system
[20:58:38] <petev> I can add all the tool info to canon, but it will be ugly
[20:58:48] <petev> it's much more than the machine needs to know
[20:58:57] <SWPadnos> I think that we can allow for binary interpreters by adding one or two functions to the interp class
[20:59:01] <petev> which makes me think it belongs in another tool file for the CAM
[20:59:20] <petev> the whole interp model with read/execute is line based
[20:59:29] <petev> we would have to come up with something new
[20:59:32] <SWPadnos> it doesn't have to be
[20:59:49] <SWPadnos> no - you make sure that all classes implement functions to convert from / to text
[20:59:54] <petev> ok, but why do we need a binary language?
[21:00:13] <petev> why can't CAM module covert to whatever text based language?
[21:00:25] <SWPadnos> why have different interpreters at all?
[21:00:47] <SWPadnos> G-code can do all necessary machining functions, just make CAM packages that convert to G-code, and drop the whole
[21:00:51] <SWPadnos> thing
[21:00:54] <petev> because the old guys like g-code and some guys want programability
[21:01:29] <petev> if we go to binary, u are basically in the dark when it's running
[21:01:31] <SWPadnos> programmability doesn't affect basic G-code
[21:01:46] <petev> I can easily make a binary lexer/parser if there is value in it
[21:01:52] <SWPadnos> if you *allow* binary in your interface, then you change nothing for text languages
[21:02:01] <petev> u can't really program in g-code effectively
[21:02:15] <petev> true, but what about the interp model?
[21:02:30] <petev> and what do we gain from binary?
[21:03:06] <SWPadnos> if the interface allows binary and text, then you don't have to redefine the interface if/when a binary machining file format comes out
[21:03:30] <SWPadnos> it's transparent to the rest of the system anyway - the interp reads the file itself, not the GUI
[21:03:45] <petev> ok, so this is future proof, but it makes it that much harder to define a general interp API
[21:03:49] <petev> what are your ideas?
[21:03:50] <SWPadnos> the only GUI function you'd lose is the text window with the program (and of course MDI)
[21:03:53] <SWPadnos> I don;t think so
[21:04:16] <petev> well the whole interp model is read/execute
[21:04:21] <SWPadnos> first, make the GetLine a virtual function
[21:04:21] <petev> so what would read mean?
[21:04:29] <SWPadnos> yes, but it's the interp itself that reads
[21:04:31] <petev> hang on
[21:04:38] <petev> the GUI doesn't do getline
[21:04:52] <petev> the get line in the interp is to give the GUI the text to display
[21:05:06] <petev> the interp reads the file or gets past MDI data in the read call
[21:05:21] <petev> token to you
[21:05:27] <SWPadnos> right - so virtualize it so that a future binary interpreter can printf something like "Extruded Boss #27"
[21:06:02] <petev> ok, that's easy enough
[21:06:08] <SWPadnos> you don't see the canonicals, you don't see each move the machine makes, but you get a language-dependent indication of what's happening
[21:06:19] <SWPadnos> for G-code, it would return the text of the line
[21:06:33] <petev> ok, what else
[21:06:52] <SWPadnos> there would need to be some capabilities functions, such as "can accept text MDI"
[21:07:01] <SWPadnos> I'm not sure of all capabilities that would be needed
[21:07:34] <SWPadnos> the line number would need to be virtualized somehow, since it doesn't make sense for binary files
[21:07:49] <petev> BTW, I don't see a problem running 2 interps in the same build
[21:08:12] <SWPadnos> how do you mean?
[21:08:21] <petev> they are just a C++ object
[21:08:31] <petev> I could have a binary one and a text one for MDI
[21:08:39] <petev> task could make calls to either
[21:08:52] <SWPadnos> well - they have the same external interface, so loading two would likely generate dynamic link problems
[21:09:00] <SWPadnos> ok - as standalones
[21:09:11] <petev> no, they are objects
[21:09:20] <petev> it's just a pointer to a diff object
[21:09:25] <petev> nothing to to with RPC
[21:09:30] <SWPadnos> G-code falls down when you want to describe more complex shapes, like NURBS
[21:09:37] <petev> the RPC interface could have a param to select the interp
[21:09:43] <SWPadnos> that's one place where a binary file could be useful
[21:09:49] <petev> task could have several at it's disposal
[21:10:08] <SWPadnos> sure - separate executables eliminates the link issues
[21:10:19] <petev> there are no link issues
[21:10:29] <petev> in fact, it saves code space if they are together
[21:10:38] <petev> all the common code is shared
[21:10:52] <petev> I can instance two of the same type, one of each type, no prob
[21:11:08] <petev> there is no global mess or anyhting like the current implementation
[21:11:24] <petev> and the abstract class keeps the interface the same
[21:11:32] <SWPadnos> well - each "library" would export the same symbols, so you couldn't load more than one at a time, or the dynamic linker would complain (assuming they all came into the same process space)
[21:11:45] <petev> no, you are missing something
[21:11:50] <petev> let me try and explain
[21:11:55] <SWPadnos> if you're talking about somipling them in, then it's no problem
[21:12:01] <SWPadnos> compiling
[21:12:15] <petev> it's not a problem either way
[21:12:25] <petev> you just have to instance the right class
[21:12:32] <petev> I make C++ libs all the time
[21:12:42] <petev> the vtable pointer takes care of it
[21:12:51] <SWPadnos> right - the mangled names will be different
[21:13:00] <petev> same entry code gets called, but different behavior depending on object type
[21:13:17] <petev> no, same base class=same entry code
[21:13:22] <petev> vtable is the diff
[21:13:38] <petev> do you know how the vptr works in c++?
[21:13:42] <SWPadnos> yes
[21:14:01] <petev> ok, so one object will have a different vptr than the ohter
[21:14:26] <SWPadnos> maybe we're thinking of two different things regarding the interp
[21:14:31] <petev> same base class API will get called, but different func will run depending on object type
[21:14:53] <petev> the c++ compiler generates code for a func table lookup
[21:15:01] <petev> the vptr points to the func table
[21:15:23] <SWPadnos> I understand the C++ internals, it's the .so files I'm having a hard time with
[21:15:24] <petev> ok, here's how I define the interp
[21:16:03] <petev> it includes a lexer/scanner, a status/state block, and an execution engine that makes calls to canonical
[21:16:29] <petev> the API gives access to the status/state and control of the execution engine
[21:16:51] <petev> task makes calls to both the interp and canon
[21:17:13] <petev> ok, for the .so, remember the this pointer
[21:17:17] <SWPadnos> how are you thinking that the user will select one or more interps to use at any given time?
[21:17:24] <petev> the code in the lib operates on the object passed to it
[21:17:47] <petev> for the user to select, there could be some API in taks that says load interp XX
[21:17:57] <petev> task could new one up and start using it
[21:18:05] <SWPadnos> ok - so each interp would be in its own .so file?
[21:18:15] <SWPadnos> specified from the GUI or ini
[21:18:23] <petev> no, forget the .so, they could be in the same one
[21:18:32] <petev> all the interp code could be in one lib if we want
[21:18:39] <SWPadnos> I'm not sure they can be in *separate* ones - that's my problem ;)
[21:18:55] <petev> ok, let me break it down
[21:19:04] <petev> common base class
[21:19:10] <petev> that's in one .so
[21:19:17] <petev> now we have derived classes
[21:19:27] <petev> they can be in other .so files if we want
[21:19:33] <SWPadnos> OK - I see now. two interps means 3 .so files
[21:19:38] <petev> they use common base class .so
[21:19:39] <SWPadnos> bae, interp1, interp2
[21:19:40] <SWPadnos> base
[21:19:48] <petev> we can put all together, or separate or whatever
[21:20:06] <petev> yes, I think you got it now
[21:20:15] <SWPadnos> phone
[21:20:21] <petev> ok
[21:21:59] <SWPadnos> SWMBO - couldn't ignore it ;)
[21:22:04] <petev> yep
[21:22:13] <petev> ok, so here's how this works with task
[21:22:20] <SWPadnos> ok - the basis of my confusion is that I would want to have "pluggable" interps
[21:22:30] <petev> all task code is linked against base class, except..
[21:22:41] <petev> for the code that loads the different interps
[21:22:55] <SWPadnos> so I can specify at least one in the ini file, and it gets loaded. I couldn't reconcile the base classes being duplicated in all the interp libs
[21:22:59] <petev> that code instances an interp object of the desired derived class
[21:23:28] <petev> yeah, you wouldn't want to dup the base class code
[21:23:32] <petev> that would be a waste
[21:23:35] <petev> it's the same code
[21:23:50] <SWPadnos> hmmm - I think I see a problem with where you're headed
[21:23:58] <petev> what?
[21:24:08] <SWPadnos> but keep going - I could be wrong
[21:24:17] <SWPadnos> (unles you're done) ;)
[21:24:38] <petev> I'm pretty much done unless u are unclear on some part
[21:25:08] <SWPadnos> OK - the issue is that task (or some part of it) has to be recompiled to be able to use any new interpreter clas
[21:25:17] <petev> yes
[21:25:18] <SWPadnos> in practical terms, it's not an issue
[21:25:27] <SWPadnos> in theroetical / architectural, it is ;)
[21:25:27] <petev> right, that's what I think
[21:25:31] <petev> why?
[21:25:51] <SWPadnos> I'd like it if a manufacturer could have a proprietary interpreter that they can plug into emc
[21:26:14] <SWPadnos> I wouldn't like them to do it, but like the kernel, not everyone wants to open-source their stuff
[21:26:23] <SWPadnos> it would be like a binary driver for a language
[21:26:31] <petev> I see, well that can be done, but then it would be hard to support multiple interps and they couldn't be objects
[21:26:48] <SWPadnos> right - hence my name conflict issues
[21:27:13] <petev> hmm, that really makes it ugly if the interp is not an object and just an API
[21:27:27] <petev> I like the whole object oriented idea
[21:27:40] <SWPadnos> I think that any one GUI would only need a single interp at a time
[21:27:54] <SWPadnos> so they can have the same name, and you just choose the .so to load dymanically
[21:28:01] <SWPadnos> (the classes can all have the same name)
[21:28:24] <petev> yes, but if task only knows base class, how does it create an object of the proper class?
[21:28:51] <SWPadnos> there is exactly one name for an interpreter class (like "Interp")
[21:29:05] <petev> we could hack the base class so it weren't really a c++ class and we could have API to allocate object mem, but that's geting ugly
[21:29:15] <SWPadnos> if you load STEP-Interp.so, you get the Step interpreter when you instantiate an Interp
[21:29:39] <SWPadnos> the function names would be the same from interp to interp
[21:29:42] <petev> so u are saying that the interp object is declared globally then and we only use one at a time?
[21:29:49] <SWPadnos> yes - I think so
[21:30:07] <petev> if we only want one at a time, then we could declare the object globally
[21:30:40] <SWPadnos> yep
[21:31:12] <petev> how is loading from the .so going to impact other external references to things like canon in the interp .so?
[21:31:32] <petev> does this mean we need dymanic binding to canon as well?
[21:31:38] <SWPadnos> it shouldn't - canon shouldn't be calling interp functions, I don't think
[21:31:52] <petev> no, it's the other way, interp calls canon
[21:32:19] <SWPadnos> exactly - so as long as the canon is already loaded, there are no link issues
[21:32:36] <petev> right, but then canon has to be a .so, not statically linked
[21:32:50] <SWPadnos> no - it can be internal to the program
[21:32:54] <SWPadnos> the task program
[21:33:01] <petev> the linker will handle that?
[21:33:04] <SWPadnos> I think so
[21:33:08] <petev> or loader I mean
[21:33:16] <petev> hmm, I didn't think it could
[21:33:22] <petev> will have to check on that
[21:33:27] <SWPadnos> even if it doesn't, canon.so would be loaded alreasy, since the GUI would likely want to initialize it
[21:33:46] <petev> yeah, we can make canon a .so if we have to
[21:34:00] <petev> I just wasn't planning on it, but not a big deal
[21:34:04] <SWPadnos> well - consider that printf can be used, and you don't have to reload clib
[21:34:11] <SWPadnos> libs
[21:34:13] <SWPadnos> libc
[21:34:55] <SWPadnos> anyway - getting back to the binary interpreter interface
[21:34:58] <petev> I will have to check this out, in doze can you have a DLL that call funcs in your executable?
[21:35:11] <petev> I have never seen it before
[21:35:27] <SWPadnos> I think so - as long as all external references are satisfied (your exe may have to export some funcs)
[21:35:47] <petev> ok, if that's the case, it shouldn't be a problem
[21:35:49] <SWPadnos> I'm not sure - it bears looking into
[21:36:02] <petev> this does remind me of something though
[21:36:09] <petev> what about the M100 stuff
[21:36:22] <SWPadnos> that's G-code specific
[21:36:29] <petev> if these are external processes, how will they make calls?
[21:36:34] <SWPadnos> STEP-NC probably doesn't have M-codes
[21:36:37] <petev> no, the external process aspect
[21:36:43] <petev> nothing to do with g-code
[21:36:58] <petev> does this mean we need an RPC for canon API too?
[21:37:06] <SWPadnos> they don't make calls to the emc core, unless they set themselves up as NML clients
[21:37:17] <SWPadnos> they also can't execute G-code, as it is
[21:37:17] <petev> yeah, but without NML
[21:37:33] <petev> what good is an external process if it can't call to the EMC core?
[21:37:45] <SWPadnos> they're not actually that useful at the moment
[21:37:52] <SWPadnos> at least, not for machine tasks
[21:38:06] <petev> hmm, isn't that something we should fix?
[21:38:20] <SWPadnos> you could run an external program that might talk to a toolchanger PLC or something
[21:38:46] <SWPadnos> it's somewhat fixed with emc2, since the external code can use halcmd
[21:38:56] <petev> doesn't seem very usefull unless there is a way to communicate with EMC
[21:39:11] <SWPadnos> and with emc1 (or emc2), there's an NML interface, so it is possible to make the core do stuff
[21:39:23] <petev> how is external execution synched if no canon calls are made?
[21:39:26] <SWPadnos> in the new system, that might be RPC, btu it's still possible
[21:39:38] <SWPadnos> emc stops while the M1xx code is run
[21:39:49] <petev> so I guess we should have an RPC to canon then?
[21:39:55] <SWPadnos> but there's a problem with getting position back, I'd bet
[21:39:59] <petev> yeah, but motion could be way ahead
[21:40:08] <SWPadnos> how do you mean?
[21:40:13] <petev> does the interp wait for the motion queue to go empyt before the exec?
[21:40:18] <SWPadnos> I hope so
[21:40:31] <petev> this all seems like a kludge
[21:40:41] <petev> seems like the external proc should have to make canon calls
[21:40:48] <SWPadnos> it may not though - you could conceptually have an external coolant controller that doesn't need synch
[21:40:50] <petev> then things can proceed as normal
[21:41:12] <petev> so what are we really trying to do?
[21:41:19] <petev> support stuff outside of HAL?
[21:41:31] <petev> if so, we should solve that in HAL with a module
[21:41:52] <SWPadnos> I'm not sure what the original purpose of the external M1xx was
[21:41:53] <petev> use the modbus or whatever
[21:42:11] <petev> I thought it was to implement user m-codes
[21:42:23] <SWPadnos> yes, but for what purposes, I don't know
[21:42:24] <petev> but they should still call canon in my opinion
[21:42:31] <SWPadnos> (and with what capabilities)
[21:42:35] <petev> canon should handle anything the machine can do
[21:42:44] <petev> how it does it is a different issue
[21:42:55] <petev> phone
[21:43:07] <SWPadnos> remember - emc1 didn't have HAL, so you could have an external program that fiddled with parport3, and emc wouldn't be the wiser
[21:43:09] <SWPadnos> ok
[21:53:18] <petev> ok, I'm back, dang work stuff getting in the way of fun ;-)
[21:54:22] <SWPadnos_> heh - I was just thinking about looking at this stack of bills
[21:54:33] <petev> yep
[21:55:08] <petev> so how much do we want to byte off right now?
[21:55:54] <petev> seems like we are almost re-writing everything if u include the changes to motion that jmk is looking at
[21:56:01] <SWPadnos_> yep
[21:56:19] <SWPadnos_> also looking at the motion / planning discussion on the dev list
[21:56:38] <petev> yeah, sounds like plenty of reasons why it's needed
[21:56:45] <SWPadnos_> I think that what we have works well for now, but I'd like to plan the far future
[21:56:49] <petev> no one has addressed the cutter comp issue though
[21:57:13] <SWPadnos_> and then make incremental changes, always looking at the far goals
[21:57:18] <petev> well I can easily do the RPC on canon and make interp a global object
[21:57:20] <SWPadnos_> yep - that's another one
[21:57:37] <SWPadnos_> referring to cutter comp ;)
[21:57:50] <petev> what about the binary for interp?
[21:57:56] <petev> how do u see the API for that?
[21:58:09] <SWPadnos_> for a binary interpreter?
[21:58:10] <petev> what does read() mean?
[21:58:12] <petev> yes
[21:58:37] <SWPadnos_> interp::read would have to decide when it's done with an "object" or "command"
[21:58:42] <SWPadnos_> it just gets a file pointer
[21:59:08] <petev> ok, that doesn't really change anything other than the MDI string that read can take now
[21:59:16] <petev> so how do we get rid of that?
[21:59:20] <SWPadnos> right
[21:59:33] <petev> do u also prefer to pass file args instead of names?
[21:59:41] <petev> I think I would
[21:59:45] <SWPadnos> actually - no ;)
[21:59:50] <petev> but I didn't want to change too much
[21:59:54] <SWPadnos> it depends on remote operator panels though
[22:00:00] <petev> why not make task open all the files?
[22:00:21] <petev> keep all of the internal objects just dealing with file handles
[22:00:30] <SWPadnos> it can do that, but it can't tell when the file is done without the interp
[22:00:38] <SWPadnos> also, remote displays are a problem
[22:00:50] <petev> no, I just mean for stuff like the open() call
[22:01:00] <SWPadnos> think of the plant manager who's trying to see (from their office) which machine will be done the soonest
[22:01:01] <petev> I would rather have task open it
[22:01:10] <SWPadnos> they may not have the file on their machine
[22:01:37] <SWPadnos> and it'as almost guaranteed to be in a different location even if they do have it
[22:01:39] <petev> so why not have the filenames end with the task API and be file handles below that?
[22:01:53] <SWPadnos> what good is a file handle on a remote PC?
[22:01:54] <petev> then all file open code would be in one place
[22:02:05] <petev> hang on
[22:02:21] <SWPadnos> (this is an issue we have now, btw)
[22:02:22] <petev> so are u thinking that task will run on a differnt PC than the rest of EMC
[22:02:31] <petev> I thought we decided against that
[22:02:32] <SWPadnos> no - that the GUI will
[22:02:47] <petev> right, but the GUI can pass a file name to taks
[22:02:50] <SWPadnos> I may be thinking of a differnet interface than you
[22:02:51] <petev> task will open it
[22:02:54] <petev> then pass handles
[22:03:14] <SWPadnos> not if the machines are talking via NML or RPC
[22:03:26] <petev> right now filename stuff lives at the lowest levels, and I don't really like it
[22:03:39] <SWPadnos> if it's remote X, and the gui is actually running on the task machine, it's OK
[22:03:39] <petev> NML/RPC is to task, agreed?
[22:03:50] <petev> I don't follow
[22:04:07] <SWPadnos> let me tell you the problem that exists now, and we can go from there
[22:04:13] <petev> NML/RPC has to pass a filename that is good on the remote machine, correct?
[22:04:15] <petev> ok
[22:04:24] <SWPadnos> right now, you can run several GUIs, and they may be on separate PCs
[22:04:41] <SWPadnos> that's actually executing at remote locations (remote to task / io / motion...)
[22:04:52] <SWPadnos> and communicating via NML
[22:05:08] <SWPadnos> now, you load up tkemc on your remote box, and try to look at what's happening with the machine
[22:05:35] <SWPadnos> emc status tells you that it's on line 2457 of file /parts/customerX/jobY/bigpart.ngc
[22:05:41] <cradek> it's true that the guis load the file from the filesystem
[22:05:45] <SWPadnos> but you don't have that file
[22:05:54] <SWPadnos> or it's not in the same location
[22:05:59] <petev> right
[22:06:03] <SWPadnos> so you can't see what's being executed
[22:06:30] <petev> so what do u suggest, more interp API to pass info to GUI?
[22:06:42] <petev> it already has getLine()
[22:06:43] <SWPadnos> that's a problem between the GUI and the interp, because the interp is giving status that isn't valid on other machines
[22:07:14] <SWPadnos> yes - GetLine is the way to do that - pass the actual text (or a description) of what being executed
[22:07:27] <petev> ok, but for most controls, u load the file onto the control, then it only let's u open stuff that's local
[22:07:41] <SWPadnos> that's also a problem
[22:07:54] <SWPadnos> the GUI API has to be able to export list sof available files
[22:08:17] <SWPadnos> also, the GUI should be able to drip-feed the interp, if necessary
[22:08:22] <petev> so is there going to be some dir dedicated to the files?
[22:08:23] <SWPadnos> (a la MDI)
[22:08:32] <petev> GUI drip feed is MDI
[22:08:52] <petev> but drip feed is ugly because there is no blending, etc.
[22:08:57] <SWPadnos> I'm not sure - I'm just looking at an issue we have now, and thinking of ways of eliminating it in the future
[22:09:22] <petev> ok, so let's hear some suggestions, from u too cradek
[22:09:26] <SWPadnos> one way would be to disallow remote GUIs ;)
[22:09:31] <petev> no
[22:09:36] <SWPadnos> I agree
[22:10:33] <SWPadnos> I was just thinking of tftp or the like, but some NC files can be a gigabyte, so that's not necessarily an option (in either direction)
[22:11:26] <petev> I think for HSM, remote files will be ugly
[22:12:37] <SWPadnos> yep
[22:13:10] <SWPadnos> that's another place where a GUI / interp pair can be better than a generic GUI
[22:13:37] <alex_joni> evening
[22:13:37] <SWPadnos> the GUI can scan the file (using the interp), and tell if it needs to buffer or not, and possibly where to break the file up
[22:13:40] <SWPadnos> evening
[22:14:06] <petev> hmm, then how does data get to control PC?
[22:14:10] <alex_joni> what's cookin`?
[22:15:00] <petev> talkin about all the stuff that needs fixin
[22:15:16] <SWPadnos> well - not all of it, there isn't time ;)
[22:16:21] <SWPadnos> ahem - sorry
[22:16:29] <SWPadnos> (phew - just in time)
[22:16:59] <petev> ok, so do we really want to consider gui/interp pair?
[22:17:04] <SWPadnos> hey alex - maybe the logger should have the url in the sign-on message
[22:17:17] <petev> this will relaly impact when the gui is made up of several guis
[22:17:23] <petev> I'm not sure I want to go there
[22:17:24] <alex_joni> SWPadnos: care to fix some perl?
[22:17:26] <SWPadnos> I think it's the only way to get the max functionality in the GUI
[22:17:37] <SWPadnos> alex_joni, love to, only I don't know perl
[22:17:52] <alex_joni> same here.. yet the logger seems to understand only perl
[22:17:54] <SWPadnos> but I could probably muddle through if needed
[22:18:12] <alex_joni> it's a waste of time.. probably there are lots of more serious loggers out there..
[22:18:14] <SWPadnos> yeah - it does get complex
[22:18:53] <petev> ok, so let's deal with the easy API stuff now
[22:19:05] <petev> should I make the MDI read a separate func?
[22:19:19] <petev> it can return an error or whatever for a binary interp
[22:19:20] <SWPadnos> no - there should be a way of sending a block to the interp from the GUI
[22:19:32] <petev> a block of binary?
[22:19:48] <SWPadnos> sure - an array of bytes would work
[22:20:04] <petev> ok, well that's pretty much what it is now
[22:20:15] <SWPadnos> remember - the GUI in that case could be a bunch of buttons with names like "pocket" and "rectangle"
[22:20:15] <petev> I'll add a length and omit the null term
[22:20:40] <petev> ok, so these are minot changes, no big deal
[22:20:50] <petev> what about the language neutral status stuff?
[22:20:55] <SWPadnos> no - I'd leave that -- if the param is null or missing, read from the file
[22:21:12] <petev> no, I mean the null term on the char string
[22:21:16] <SWPadnos> yep - the changes are minimal - that's why I thought they should be there
[22:21:28] <SWPadnos> where?
[22:21:42] <petev> implied in the read() func with MDI data
[22:21:51] <petev> won't work well for binary
[22:22:31] <SWPadnos> ok - I only see the header, so It doesn't look bad from here ;)
[22:22:48] <petev> yeah, the header takes a char *
[22:23:01] <petev> the only way to tell the length is a null terminated string
[22:23:03] <SWPadnos> that's the 0 I was looking at
[22:23:16] <SWPadnos> yes - for a text-based interpreter, it would do that
[22:23:18] <petev> that is for the pointer, not the string lenght
[22:23:37] <petev> a null ptr means read the file
[22:23:38] <SWPadnos> right - and null means read from file
[22:23:42] <petev> yes
[22:23:54] <SWPadnos> (that was the only 0 I saw)
[22:24:05] <petev> right, but if the pointer is not null
[22:24:10] <petev> how long is the string?
[22:24:18] <SWPadnos> that's where the capabilities come in
[22:24:21] <petev> for text based, null terminated string works
[22:24:32] <petev> for binary, I'll need a length arg
[22:24:47] <SWPadnos> when the interp is reading the file, we don't care how it looks for termination of a command - it's up to the interp
[22:25:09] <SWPadnos> if you try to use a text-only GUI, it can't send MDI commands
[22:25:09] <petev> and you want to apply this to the MDI data too?
[22:25:20] <petev> sounds like a seg fault wating to happen
[22:25:45] <SWPadnos> yes - a dialog with a hundred buttons that generate appropriate binary commands is the equivalent of mdi
[22:25:48] <petev> why can't a text gui send text MDI to a text interp?
[22:25:58] <SWPadnos> it can - there's no problem with that
[22:26:12] <petev> right, when sending binary MDI, I would like to know the length of the MDI buff
[22:26:20] <SWPadnos> I should have said that a text-only GUI can't send MDI to a binary interp
[22:26:32] <petev> don't want to trus the buf format for that is all I'm saying
[22:26:39] <SWPadnos> you have to
[22:26:39] <petev> trust
[22:26:43] <petev> why?
[22:27:00] <SWPadnos> let's make sure we're talking about the same thing here
[22:27:11] <petev> why can't I just make read like this read(char *p=null, len=0)
[22:27:31] <petev> for MDI, you give a ptr and len
[22:27:42] <SWPadnos> well - that's probably fine
[22:28:12] <petev> that way we don't impose any restrictions on the binary either for termination
[22:28:23] <SWPadnos> sure
[22:28:32] <petev> ok, that's easy
[22:28:33] <SWPadnos> and it doesn;t hurt to send strlen(cmd) with MDI either
[22:28:40] <SWPadnos> in case of transmission errors
[22:28:42] <petev> now the language neutral status
[22:28:51] <petev> sure, could do that
[22:29:40] <SWPadnos> * SWPadnos is looking at canonical.hpp
[22:29:58] <petev> ok, that has many issues with axis and motion API that are probably missing
[22:30:03] <petev> but it's a start
[22:30:07] <petev> it's pretty big too
[22:30:18] <SWPadnos> also, it's restricted to G-code relative settings at this point
[22:30:29] <petev> not supposed to be
[22:30:38] <petev> it's supposed to be atomic machine operations
[22:30:45] <petev> regardless of language
[22:30:46] <SWPadnos> consider a language (or extension to G-code) that would allow you to do curcles on arbitrary planes
[22:30:51] <SWPadnos> circles
[22:30:56] <SWPadnos> (or oter thing)
[22:30:58] <SWPadnos> gah
[22:31:00] <petev> if you see stuff that seems language specific, lets talk about it
[22:31:15] <SWPadnos> OK - Plane only allows orthogonal planes
[22:31:20] <petev> ok, but canon can;t handle that now
[22:31:31] <petev> it doens't know how to do motion like that
[22:31:42] <petev> so it's a machine limitation, more than g-code
[22:31:45] <SWPadnos> rotated, skewed, perspective warped, etc should all be possible
[22:31:47] <SWPadnos> ok
[22:32:28] <alex_joni> http://www.abandonia.com/games/en/12/TheLostVikings.htm <- this brings out memories :)
[22:34:13] <SWPadnos> well - it may be that the canon needs to be changed to support some non-G-code functions
[22:34:23] <petev> yes
[22:34:32] <petev> I was just trying to cover what we need now
[22:34:43] <petev> maybe a nurbsFeed or something
[22:34:58] <SWPadnos> nonetheless, if the concepts of G-code are made into generic representations, the limited capabilities of the language and / or the machine can still be represented
[22:35:09] <petev> I'm stil having problems with cutter comp though and other feed functions
[22:35:27] <SWPadnos> so, if you have a Plane structure that can represent an arbitrary plane, it can also represent an orthogonal plane
[22:35:40] <petev> true
[22:36:01] <SWPadnos> SWMBO is home - I may have to go in a bit ;)
[22:36:26] <SWPadnos> I might make an arbitrary tool offset spec as well - one that takes length into account
[22:36:26] <petev> ok
[22:36:45] <petev> I have length and diameter now
[22:36:58] <petev> what else would the machine need to know about?
[22:36:59] <SWPadnos> G-code and the current canon would present two distinct pieces of information in a single status struct
[22:37:20] <SWPadnos> possibly shape, but we don't nee to get into that ATM
[22:37:23] <SWPadnos> need
[22:37:32] <petev> I think we should consider how many calls it takes to get status now too
[22:37:46] <petev> I consolidated some, but it's still pretty atomic
[22:37:55] <SWPadnos> yes - there should be a single call for all status, and then separate ones for subsystem status
[22:38:20] <petev> yes, but lets keep task API separate from the individual object for the moment
[22:38:28] <SWPadnos> the units should be in some generic length, with constants for the mm, inch, etc
[22:38:54] <petev> the generic conversion comes from what is read by Init()
[22:39:03] <SWPadnos> (ie, represent as a float in meters, and have consts METER = 1, CM = 0.1, INCH=0.0393...)
[22:39:06] <petev> there is an enum for units
[22:39:24] <petev> hmm, not sure I want that
[22:39:27] <SWPadnos> what if I want mils as the unit (as in an NC drilling machine)
[22:39:35] <petev> I would like to keep args small for efficiency
[22:39:51] <SWPadnos> an enum is likely 32 bits, a float is 32 bits
[22:40:01] <petev> everything is double in EMC
[22:40:07] <petev> that's 64 bits
[22:40:14] <SWPadnos> ok - so 64 bits - not a big deal
[22:40:15] <petev> and an enum can be less than 32 bits
[22:40:36] <petev> it all adds up when you have NML/RPC and need speed for HSM
[22:40:42] <SWPadnos> or just use floats for some of this stuff - the length unit doesn't need to be specified with more than 12 digits of precision
[22:41:02] <SWPadnos> (or whatever a float gives you)
[22:41:05] <petev> ok, make notes on what you think should be changed, and email them to me
[22:41:14] <petev> I'll review it tonight
[22:41:25] <SWPadnos> will do - sorry I didn't take the time before discussing it
[22:41:27] <petev> I think there is also a lot of axis/motion status/control missing
[22:41:35] <petev> no problem
[22:41:55] <SWPadnos> hmmm - axis stuff will be difficult - do you want joints or world numbers?
[22:42:01] <SWPadnos> (or both)
[22:42:18] <petev> not so much axis init params, but more stuff we need to do when running
[22:42:23] <alex_joni> canon should only know world stuff
[22:42:26] <petev> stuff like home, limit, etc.
[22:42:27] <SWPadnos> sure - like axis velocity
[22:42:43] <petev> alex: I think canon should know machine stuff
[22:42:47] <alex_joni> but it should be aware of the number of joints, and how to configure them
[22:42:56] <alex_joni> not necessarely in status
[22:43:04] <petev> I would like all machine operations to go through canon
[22:43:30] <petev> I don't like that way some stuff does and other bypasses with NML to somewhere else
[22:43:54] <petev> I thought canon was supposed to be the model of the machine?
[22:44:06] <SWPadnos> well - realize that canon is only the motion / IO interface (I think)
[22:44:10] <petev> If so, then shouldn't it include everything about the machine?
[22:44:16] <SWPadnos> it doesn't do setup and the like
[22:44:39] <petev> well, it will do setup, but it's all hidden in Init()
[22:44:53] <SWPadnos> there are different phases of machine use, I;m not sure you need the general motion controller to be able to do setup
[22:45:05] <petev> define setup?
[22:45:07] <SWPadnos> it may make sense to split that out into a separate module
[22:45:14] <petev> I was refering to loading all the params, etc.
[22:45:16] <petev> not user setup
[22:45:18] <SWPadnos> kins, PID, etc
[22:45:29] <SWPadnos> ok - again - I should think before I speak ;)
[22:45:34] <petev> PIDs are from HAL now
[22:45:43] <petev> kins I was going to load in Init()
[22:46:09] <petev> this is all stuff we need to think about
[22:47:14] <SWPadnos> yep
[22:47:28] <SWPadnos> I'll think about how the status bits can be more abstract than they are now
[22:47:42] <petev> yes
[22:47:45] <SWPadnos> that will likely result in the structs growing, but that's the proce you pay for flexibility
[22:47:48] <SWPadnos> price
[22:48:13] <petev> yeah, I think more structs and less funcs would be more efficient than what's there now
[22:48:26] <petev> the current canon requires 6 calls to get a full position
[22:48:33] <petev> I couldn't handle that one
[22:48:38] <SWPadnos> heh
[22:49:07] <petev> yes, call for x, y, z, a, b, c, all separate calls
[22:49:27] <SWPadnos> I thought you could just get the tran struct in one shot
[22:49:33] <SWPadnos> or pos, or whatever it is
[22:49:44] <petev> no, not in the API I saw
[22:49:57] <SWPadnos> where were you looking?
[22:49:59] <petev> I didn't even see where some of the structs were used
[22:50:03] <petev> in canon.hh
[22:50:17] <SWPadnos> right now, the entire status is a single humongous struct, and you just extract anything you want from it
[22:50:23] <petev> u might be able to get some of this stuff from the task API in one shot no doubt
[22:50:25] <SWPadnos> (one struct from each module)
[22:50:34] <petev> no, not in canon
[22:50:45] <SWPadnos> emc1 or emc2?
[22:50:46] <petev> I think u are looking at the NML interface
[22:50:49] <petev> emc2
[22:50:52] <SWPadnos> one sec
[22:51:01] <petev> I bet the NML makes a ton of calls to file the struct
[22:52:55] <petev> u looking at canon.hh?
[22:53:17] <SWPadnos> yep
[22:53:25] <petev> look around line 624
[22:53:26] <SWPadnos> there is a single call GET_EXTERNAL_POSITION
[22:53:37] <petev> where?
[22:53:45] <SWPadnos> each of those others just calls that, and returns a single part of the struct
[22:54:01] <petev> what line, I don't see one in my file
[22:54:14] <SWPadnos> it's not in canon.hh, but it's used in canon.cc
[22:54:30] <SWPadnos> emc/task/emccanon.cc
[22:54:42] <petev> right, but the API to canon makes you do 6 calls for a position
[22:55:12] <SWPadnos> yes, which is stupid
[22:55:15] <petev> yes
[22:55:19] <petev> and I changed it
[23:01:05] <alex_joni> I'm off to bed guys
[23:01:07] <alex_joni> night all
[23:01:11] <petev> gnight
[23:01:47] <alex_joni> petev: if you come up with something, a drop to the devel list would be very appreciated ;)