Back
[02:08:49] <cradek> jmkasunich: I don't remember; it was a year or two ago
[02:09:15] <cradek> jmkasunich: I think there was a patch file and a tarball on free area of the web site
[03:00:11] <alex_joni> hello
[03:00:56] <SWPadnos_> hi
[03:15:12] <alex_joni_> alex_joni_ is now known as alex_joni
[03:15:21] <SWPadnos_> hi
[03:19:34] <rayh> Hi steven
[03:19:44] <SWPadnos_> hi Ray - how are you
[03:19:46] <SWPadnos_> ?
[03:20:04] <rayh> good.
[03:20:08] <SWPadnos_> cool
[03:20:28] <SWPadnos_> I read your post to the user list (along with the rest of the wiki/docs thread)
[03:20:34] <SWPadnos_> good stuff
[03:20:41] <rayh> having a bitch of a time getting the tickle command exec to pass proper args to halcmd
[03:21:04] <SWPadnos_> proper how? (or, a bitch how?)
[03:21:04] <rayh> I thought maybe I was being a bit harsh.
[03:21:08] <SWPadnos_> nah
[03:21:29] <rayh> the command I want to issue runs like this
[03:21:35] <SWPadnos_> one thing though - there's been a lot of progress since the WP5 days - LyX may not be the ideal tool any more ;)
[03:22:04] <rayh> set pascommand
[03:22:09] <rayh> dont even think it.
[03:22:12] <SWPadnos_> hhe
[03:22:20] <rayh> Lyx is far beyond xxx
[03:22:35] <rayh> tex and latex are the basis of publication these days
[03:22:49] <SWPadnos_> sure - they're very powerful
[03:22:51] <rayh> if you want a fscking word processor
[03:22:55] <SWPadnos_> just not as well known these days
[03:23:16] <rayh> Yes that's why I suggested taking a day or two.
[03:23:41] <rayh> It was difficult to get jmk to start using but Hal_xxx looks great
[03:23:50] <SWPadnos_> yep
[03:23:56] <rayh> Okay back to tickle
[03:23:59] <SWPadnos_> I'm sure I'll nbe the same way
[03:24:04] <SWPadnos_> ok - sorry to derail things
[03:24:44] <rayh> nah it's me. set passcommand show param
[03:25:14] <rayh> set passcommand "show param pid.0"
[03:25:45] <rayh> exec bin/halcmd $passcommand
[03:26:02] <rayh> it gets as far as show param pid
[03:26:41] <SWPadnos_> I wonder if there's some regexp thing going on
[03:27:01] <SWPadnos_> or if the .0 is interpreted to mean something (that happens to be null)
[03:27:04] <rayh> it seems that the . is a reserved character for the exec command.
[03:27:41] <rayh> the tcl wiki suggests this
[03:27:43] <rayh> set url
http://ats.nist.gov/cgi-bin/cgi.tcl/echo.cgi?hello=1&hi=2
[03:27:44] <rayh> exec [file join $env(COMSPEC)] << "start \"\" \"$url\" \n exit \n"
[03:27:55] <rayh> but I don't have a clue what that means.
[03:28:02] <SWPadnos_> heh
[03:28:42] <rayh> I have an idea that join is doing the work and the \"$url is the heart of it.
[03:29:02] <rayh> I will try that.
[03:29:16] <SWPadnos_> I'm looking at the O'Reilley TCL book now
[03:30:36] <rayh> rayh is now known as rayh_away
[03:30:41] <SWPadnos_> try set passscommand {{show param pid.0}}
[03:31:11] <rayh_ppmc_usc> think I did.
[03:31:15] <SWPadnos_> hm
[03:31:25] <rayh_ppmc_usc> gotta fire up emc
[03:31:59] <rayh_ppmc_usc> Starting emc...
[03:31:59] <rayh_ppmc_usc> iniFind is depreciated
[03:32:05] <rayh_ppmc_usc> gets me every time.
[03:32:18] <SWPadnos_> yeah - it keeps losing book value
[03:33:19] <SWPadnos_> have you tried escaping the '.'?
[03:37:48] <rayh_ppmc_usc> HAL:0: Unknown 'show' type 'show param {{pid.0.stepgen}}'
[03:37:55] <SWPadnos_> funny
[03:38:24] <SWPadnos_> did you put that in quotes?
[03:38:49] <rayh_ppmc_usc> with single {} i get HAL:0: Unknown 'show' type 'show param pid.0.stepgen'
[03:39:12] <rayh_ppmc_usc> let me try dcc to you of the file.
[03:40:39] <SWPadnos_> I'm playing in tclsh
[03:41:14] <rayh_ppmc_usc> that didn't work
[03:41:24] <SWPadnos_> heh - nope ;)
[03:41:49] <SWPadnos_> ok - here's the problem
[03:42:11] <SWPadnos_> when you pass the command in as one string, that's what halcmd sees it as - one string with those spaces in it
[03:42:22] <rayh_ppmc_usc> I'm not registered as this nick
[03:42:32] <SWPadnos_> tcl doesn't use the normal shell exec, it does its own thing
[03:42:46] <rayh_ppmc_usc> right.
[03:43:23] <SWPadnos_> do halcmd doesn't understand "show param pid.0' as a command (like help or show ...)
[03:43:28] <SWPadnos_> s/do/so/
[03:43:33] <rayh_ppmc_usc> someone suggested issuing a /bin/sh and then pass the arg
[03:43:47] <rayh_ppmc_usc> yes.
[03:43:55] <rayh_ppmc_usc> when I issue it in a terminal
[03:44:22] <rayh_ppmc_usc> let me look at the wiki once more.
[03:45:34] <rayh_away> http://wiki.tcl.tk/4304
[03:46:30] <SWPadnos_> can you pass an array as the command line params?
[03:46:34] <rayh_away> the set shell may work but if I'm opening a socket I may as well make it to halcmd
[03:46:59] <SWPadnos_> yes - if you echo the command to halcmd, that should work
[03:47:23] <rayh_away> could you explain that a bit more.
[03:48:15] <SWPadnos_> if you spawn "bin/halcmd -kf", and capture stdio to a pipe in tcl, then you should be able to print strings to the pipe, and halcmd should execute them
[03:49:32] <rayh_away> Right I've tried a bit of that. But it is not a natural thing for me to do.
[03:49:40] <SWPadnos_> ok
[03:50:09] <SWPadnos_> it also won't be perfect yet, since halcmd doesn't always give notification that it's finished with a command
[03:52:56] <rayh_away> I've read a bit about dumping buffers.
[03:53:25] <rayh_away> but I liked the single command use of halcmd better
[03:53:54] <rayh_away> and you don't have to fear about closing emc before you close the tickle
[03:54:16] <SWPadnos_> it's easier to understand, and less prone to startup / shutdowm difficulties
[03:54:18] <SWPadnos_> right
[03:54:54] <SWPadnos_> hmmm - an array may make some sense, actually
[03:55:27] <SWPadnos_> (excuse any not-quite-right TCL - I don't know the language)
[03:55:29] <rayh_away> make an array with all of the commands you want to pass
[03:56:17] <SWPadnos_> no - I'm thinking one with command, option, name elements
[03:56:42] <SWPadnos_> then exec bin/halcmd $cmd(command) $cmd(option) $cmd(name)
[03:57:57] <rayh_away> tickle doesn't do arrays real well but something like array(1.2.3,4)
[03:58:49] <SWPadnos_> exec bin/halcmd $cmd $option $arg
[04:00:15] <SWPadnos_> out of curiosity, why are you trying to build the entire command into one string?
[04:00:46] <rayh_away> I pass the string to a process
[04:01:18] <rayh_away> after I get one running, then I'll ask it to search for a running emc
[04:01:26] <rayh_away> look for the type of servo card
[04:01:33] <rayh_away> and make a set of tuning pages.
[04:01:56] <SWPadnos_> can you pass several vars instead of just one?
[04:02:22] <SWPadnos_> (like the $cmd $option $arg line above)
[04:02:46] <SWPadnos_> or is this not a tcl "process"?
[04:03:01] <rayh_away> I know that. Just not comfortable with variable number of args.
[04:03:33] <SWPadnos_> always pass all of them - just set option to "" if you don't need it
[04:03:51] <SWPadnos_> right - neverminf
[04:03:52] <SWPadnos_> d
[04:04:01] <rayh_away> and halcmd is not real friendly. Man readable but not friendly.
[04:04:06] <SWPadnos_> nope ;)
[04:04:24] <SWPadnos_> I talked to jmk yesterday about the filtering stuff
[04:04:40] <rayh_away> Where exec seems to trip up is when I put the . in.
[04:05:09] <rayh_away> to that point it hands the command to grep or whatever halcmd uses
[04:05:23] <rayh_away> and will spit out the reply.
[04:05:28] <SWPadnos_> I don't think the . is the problem
[04:06:03] <rayh_away> then why do I get a different answer when I issue the command from bash
[04:06:16] <rayh_away> than I do when I issue the same aparent command from exec
[04:06:27] <SWPadnos_> because tcl is sending the entire string as the first argument to halcmd
[04:06:51] <SWPadnos_> it sees one item on its command line, and tries to interpret that as a command (help, show, list, etc)
[04:06:56] <rayh_away> No halcmd is happy to return the result of "param pid"
[04:07:07] <SWPadnos_> not from tclsh
[04:07:16] <rayh_away> sure
[04:07:39] <rayh_away> it just won't return "param pid.0
[04:07:47] <rayh_away> as a special case.
[04:08:03] <alex_joni> does 'param pid' work?
[04:08:11] <SWPadnos_> either of those returns the error "HAL:0: Unknown command 'show param pid'"
[04:08:11] <rayh_away> yes.
[04:08:17] <SWPadnos_> (or pid.0)
[04:08:25] <rayh_away> no I get an answer
[04:08:25] <SWPadnos_> in tclsh anyway
[04:08:29] <SWPadnos_> odd
[04:08:32] <rayh_away> in tcl
[04:08:34] <alex_joni> indeed
[04:08:56] <rayh_away> let me switch to the box and get a return
[04:09:09] <SWPadnos_> I'd like to see what the halcmd error is also
[04:09:25] <rayh_ppmc_usc> there is no error if I set it up right.
[04:09:53] <rayh_ppmc_usc> I just don't get the limited return that I want.
[04:10:09] <rayh_ppmc_usc> I get back all of bin/halcmd show param pid
[04:10:24] <rayh_ppmc_usc> rather than bin/halcmd show param pid.0.stepgen
[04:11:33] <rayh_ppmc_usc> If I start a terminal and ask for watch bin/halcmd show param pid.0.stepgen I get a really nice display of what I'd like to see in the tuning screen.
[04:11:40] <rayh_ppmc_usc> course I don't need watch
[04:12:08] <rayh_ppmc_usc> cause I can loop the update
[04:15:31] <alex_joni> is there a pid.0.stepgen ?
[04:15:41] <alex_joni> don't remember such a name
[04:16:25] <SWPadnos_> ppmc.0.stepgen ;)
[04:16:42] <alex_joni> ahh.. ok, got confused
[04:16:56] <SWPadnos_> that's the closest I can think of
[04:17:02] <rayh_ppmc_usc> Hey I think your idea of multiple args may get be there.
[04:17:08] <rayh_ppmc_usc> brb
[04:17:11] <SWPadnos_> ok
[04:17:23] <rayh_ppmc_usc> Nah I'm confusing two different modules
[04:17:26] <SWPadnos_> I've got to go for a while. see you later
[04:17:36] <rayh_ppmc_usc> pid.0 or pid1
[04:17:43] <rayh_ppmc_usc> for one view
[04:17:54] <rayh_ppmc_usc> and axis.0.xxx for another.
[04:18:24] <SWPadnos_> SWPadnos_ is now known as SWP_Away
[04:19:21] <rayh_ppmc_usc> wah. Thank you steven. It works great.
[04:24:42] <alex_joni> nice to hear that
[04:39:15] <rayh_away> rayh_away is now known as rayh
[05:18:53] <alex_joni_> alex_joni_ is now known as alex_joni
[08:36:36] <alex_joni> hi pete
[08:36:44] <petev_> hi alex
[08:37:02] <alex_joni> seen lots of talk of you & jmk about TP
[08:37:10] <petev_> yes
[08:38:16] <alex_joni> also lots of talk between dmess & les_w on #emc today
[08:38:22] <petev_> yes
[08:38:37] <alex_joni> ok.. just pointing it out
[08:51:23] <alex_joni> chris: can you point me out what the difference in cradek_stable from a RUM-free HEAD is?
[08:53:40] <cradek> alex_joni: I'm not sure what a RUM-free HEAD is
[08:53:49] <cradek> alex_joni: do you mean the base of the stable branch I made?
[08:53:53] <alex_joni> current HEAD without the RUM changes
[08:54:01] <cradek> alex_joni: I say that only because I don't know what has been added to HEAD
[08:54:02] <alex_joni> or you didn't follow HEAD
[08:54:06] <alex_joni> OK
[08:54:08] <alex_joni> gotcha
[08:54:25] <alex_joni> only about 10 commits in the last 6 months.. so no worries
[10:06:06] <SWP_Away> hiya Ray
[10:06:29] <rayh_usc> Hi steve
[10:06:39] <SWP_Away> so - you got it working - that's great
[10:06:42] <rayh_usc> Your multiple args solved the problem for me.
[10:06:46] <SWP_Away> cool
[10:06:53] <petev_> swp: any thought on the interp base class?
[10:07:03] <rayh_usc> Got the start of a tuner going now.
[10:07:12] <SWP_Away> petev_: haven't really looked at it yet - sorry
[10:07:31] <petev_> ok, got an optimized version that's 3x as fast as what I sent you
[10:07:34] <SWP_Away> rayh_usc: is tcl smart enough to pass all the elements of an array when you exec?
[10:07:38] <SWP_Away> hhe - cool
[10:07:40] <SWP_Away> heh
[10:07:55] <rayh_usc> you've got a usc board. as soon as I get a bit further I'l send to you for your opinions and code
[10:08:04] <SWP_Away> cool
[10:08:16] <rayh_usc> Yes I think so but will have to test a bit first.
[10:08:41] <SWP_Away> sure - testing makes perfect ;)
[10:11:14] <alex_joni_> alex_joni_ is now known as alex_joni
[10:11:21] <SWP_Away> SWP_Away is now known as SWPadnos_
[10:11:59] <SWPadnos_> actually - test programs for each card can be made fairly easily
[10:12:02] <SWPadnos_> test / tuning
[10:13:10] <SWPadnos_> but it would be better with a hal access library, rather than 'exec'-ing halcmd all the time
[10:16:02] <rayh_usc> I suppose that's true but exec gets around the shutdown issue.
[10:16:20] <rayh_usc> It can be a mess to clean up an improper shutdown.
[10:16:34] <SWPadnos_> I was thinking more like a library that you load, and have direct functions for the things you're execing now
[10:16:52] <SWPadnos_> not a piped interpreter like we were talking about before
[10:18:24] <rayh_usc> I have no clue how that would work.
[10:18:34] <SWPadnos_> which - the pipe or the library?
[10:18:35] <petev_> swp: does tcl have bindings for other languages?
[10:18:48] <rayh_usc> Sure about 50 or more
[10:18:52] <SWPadnos_> I think you can make tcl bindings for "C" libraries
[10:19:08] <petev_> hmm, I thought tcl was just interpreted by wish
[10:19:13] <rayh_usc> not this you
[10:19:19] <petev_> is there a way to tell wish it's a C binding?
[10:19:30] <rayh_usc> sure.
[10:19:34] <rayh_usc> lots of em.
[10:19:44] <rayh_usc> that's what we are using in emcsh and iosh
[10:20:00] <rayh_usc> These are both expanded wish shells
[10:20:09] <petev_> no, emcsh is a C program that interprets stuff from the GUI
[10:20:26] <petev_> ok, expanded wish
[10:20:45] <petev_> so not really a tcl C binding mechaism built in at all then
[10:20:46] <SWPadnos_> but you can use external packages as well
[10:22:22] <rayh_usc> I wouldn't know the difference. Sorry
[10:22:55] <SWPadnos_> isn't tk a C library that's used by tcl? (for the most part)
[10:23:10] <petev_> while both of u guys are here, what are your thoughts on being able to support interpreters other than g-code?
[10:23:25] <petev_> swp: I don't know tcl/tk at all
[10:23:41] <SWPadnos_> me either - I've just got the O'Reilley book ;)
[10:23:49] <rayh_usc> canterp is in there now
[10:24:03] <SWPadnos_> I'd like multiple interpreters, but I'm not sure how far we can realistically go with that
[10:24:12] <rayh_usc> The front end to canterp is "step"
[10:24:13] <SWPadnos_> at some point, the interp ends up being a CAM program
[10:24:22] <SWPadnos_> is that STEP?
[10:24:27] <rayh_usc> yes
[10:24:42] <SWPadnos_> I thought there were patent or copyright issues with STEP
[10:24:46] <rayh_usc> and I hear screams that STEP is proprietary
[10:25:06] <SWPadnos_> yep
[10:25:08] <rayh_usc> NIST got an agreement from STEP that what they do will be open.
[10:25:15] <petev_> the reall issues are with g-code specific stuff being exported to the task an UI APIs
[10:25:30] <SWPadnos_> I'd like to be able to load an STL file, myself. but that goes way beyond an "interpreter"
[10:25:50] <SWPadnos_> well - it's not necessarily G-code specific (some is, but some isn't)
[10:26:06] <SWPadnos_> relative coordinates - could be used in non-G-code interps
[10:26:09] <petev_> so, can we generalize stuff like active Gs, Ms, etc. to make them non g-code specific?
[10:26:12] <rayh_usc> Well Bob and weber has been working on EMC operation from inside his display.
[10:26:19] <rayh_usc> at
[10:28:13] <SWPadnos_> think of them as machine states - they may have different words to describe them (in different lagnuages), but they're the same thing
[10:28:17] <petev_> ray, I'm looking at canterp, and it implements a whole new emc task
[10:28:30] <petev_> swp: yes, that's what I'm thinking
[10:28:34] <SWPadnos_> so a G-code front end would look at metric units, and say that the machine is in G21 mode
[10:28:44] <petev_> but now they are all gcode specific all the way to the UI
[10:29:02] <SWPadnos_> the GUI and the interpreter need to be fairly closely linked, I think
[10:29:08] <petev_> swp: but that builds g-code knowledge from the interp into the UI
[10:29:11] <SWPadnos_> (it's a bummer - I'de prefer if that weren't the case)
[10:29:17] <petev_> what if G21 was something else?
[10:29:24] <alex_joni> night all
[10:29:39] <SWPadnos_> what I'm saying is that the machine says to the GUI (or interp) "I'm in metric units"
[10:29:54] <SWPadnos_> and the interp (or GUI) tells the operator "the machine is in G21 mode"
[10:30:07] <SWPadnos_> because that's how the G-code interpreter interprets metric
[10:30:07] <petev_> yes, but take a case where the G code isn't as standard is all I'm saying
[10:30:20] <petev_> the UI is guessing at what the g-code is for that machine mode
[10:30:28] <rayh_usc> prp
[10:30:38] <SWPadnos_> right - in SteveCode, it might say "the machine is using 1000 micron units"
[10:30:46] <petev_> yep
[10:30:54] <SWPadnos_> no - the GUI asks the interpreter to tell it the machine state
[10:31:06] <SWPadnos_> the interpreter becomes a forward and reverse interpreter
[10:31:21] <petev_> hang on
[10:31:26] <SWPadnos_> it looks at the machine state, and converts to the names for that "language"
[10:31:35] <petev_> so right now the interp has status that needs sharing with the GUI
[10:31:56] <petev_> if we generalize this status, how can the GUI show it in languague specific terms?
[10:32:09] <SWPadnos_> unfortunately, I can't continue now - will you be around in a few hours?
[10:32:21] <petev_> no, but later tonight
[10:32:34] <SWPadnos_> ok - that should be good - let's take it up then
[10:32:34] <petev_> tomorrow as well
[10:32:38] <SWPadnos_> yep
[10:32:39] <petev_> ok
[10:32:47] <SWPadnos_> see you later (time to eat! )
[10:32:51] <SWPadnos_> SWPadnos_ is now known as SWP_Away
[11:09:09] <rayh_usc> part
[13:27:29] <SWP_Away> SWP_Away is now known as SWPadnos_
[14:36:53] <SWPadnos_> hiya Ray
[14:37:15] <rayh> Hey wot's going on?
[14:37:24] <SWPadnos_> I have no idea
[14:38:00] <rayh> been there still there.
[14:38:05] <SWPadnos_> heh
[14:38:15] <SWPadnos_> at least I know I don't have far to fall ;)
[14:38:32] <rayh> right.
[14:38:52] <rayh> Now that i've got this first set of screens running
[14:39:08] <rayh> I'm thinking of expanding a bit.
[14:39:18] <SWPadnos_> which direction?
[14:39:33] <rayh> stomach of course.
[14:40:00] <SWPadnos_> heh
[14:40:05] <rayh> i can get the tuning stuff fairly easily
[14:40:27] <rayh> The next step is a big one -- changing links
[14:40:56] <SWPadnos_> like - insert PID hare, or "unhook that so I can play with it"
[14:41:03] <SWPadnos_> s/hare/here/
[14:41:13] <rayh> remember that qconfig that got attributed to me but was all your work?
[14:41:20] <SWPadnos_> heh -yep
[14:41:26] <SWPadnos_> (and Alex)
[14:41:51] <rayh> We had talked about using that for HAL config, didn't we?
[14:42:17] <SWPadnos_> yes - sort of
[14:42:23] <SWPadnos_> I think it was more for ini config
[14:42:38] <rayh> oh okay
[14:42:53] <SWPadnos_> I don't think it would have been possible to make it capable of configuring HAL - there are too many possible connections
[14:43:04] <SWPadnos_> it was also for setting build options, just like in the kernel
[14:43:13] <SWPadnos_> (though that isn't really needed these days)
[14:43:18] <rayh> Right I remember that
[14:44:56] <SWPadnos_> anyway - about your extensions (of the TCL kind)
[14:45:21] <rayh> I'm willing to postpone that build options for a bit but when we've got a hundred different drivers I'll be back.
[14:45:30] <SWPadnos_> heh - yeah
[14:46:29] <rayh> It would be possible to start up an emc2 with little to no hal other than iocontrol and it's cousins
[14:46:53] <rayh> nothing connected nothing threaded.
[14:47:06] <SWPadnos_> yep
[14:47:34] <rayh> and with a few choices add the stuff an integrator wants to add.
[14:47:48] <SWPadnos_> ah - right. I think I see where you're going
[14:47:53] <rayh> ppmc or mesa or parports
[14:48:47] <SWPadnos_> sure - select steppers or servos -> interface (parport / ppmc / servo card) -> scaling (encoder res, steps/inch) -> tuning ....
[14:48:52] <rayh> Since I've got the ability now to show stuf as it's added.
[14:49:28] <rayh> HAL becomes its own resource for available pins, parms and such
[14:49:33] <SWPadnos_> yep
[14:49:58] <rayh> I would want to separate the load commands into a file by themselves
[14:50:08] <SWPadnos_> the only information you don't have (until you connect everything), is the order you should run the functions in the various threads
[14:50:26] <rayh> True
[14:51:47] <SWPadnos_> why load separately? I'd think that it would make more sense to load a hal component / driver or two, then make the connections you know need to be made, in that file
[14:52:13] <SWPadnos_> that way, you could snap out one driver for another, and many of the pin names would go along with the load of that driver
[14:52:36] <rayh> Yes but halcmd can spit out a hal file only it won't contain the loads
[14:53:17] <SWPadnos_> ah - so you'd load a module, tell the user to connect what they want, then halcmd save to get the connections / params
[14:53:19] <rayh> and you can not reload using -f ?filename? if it does contain the load info
[14:53:44] <SWPadnos_> sure - the loads need to be somewhere
[14:54:39] <rayh> I could see side by side screens with iocontrol in one and a parport in the other
[14:55:02] <rayh> or motion and a parport
[14:55:16] <rayh> or motion and pids
[14:55:21] <SWPadnos_> yep
[14:55:34] <SWPadnos_> of course, the trouble is filtering ;)
[14:55:51] <rayh> It isn't quite the visual schematic that jmk was thinking about
[14:56:15] <SWPadnos_> nope, but it's a good start
[14:56:19] <rayh> filtering?
[14:56:34] <SWPadnos_> I'm not sure how long ValarQ will take with halgui
[14:56:59] <SWPadnos_> yeah - you would want to sort the pins/params into various groups
[14:57:03] <SWPadnos_> input or output
[14:57:10] <SWPadnos_> bit / byte / float
[14:57:15] <rayh> I've looked but don't read any python so ....
[14:57:19] <SWPadnos_> no - me either
[14:57:41] <rayh> certainly grouping is essential
[14:58:06] <rayh> some of this can be seen by looking at the show sig xxx
[14:58:20] <SWPadnos_> well - show pin/param xxx
[14:58:30] <SWPadnos_> sigs need to be created by your program
[14:59:07] <rayh> linkpp does some of that for you
[14:59:17] <SWPadnos_> treu
[14:59:21] <SWPadnos_> true, even
[14:59:46] <SWPadnos_> depending on how difficult it is, I have an idea for dealing with these things
[14:59:54] <SWPadnos_> well - I have an idea anyway
[15:00:11] <rayh> * rayh is all eyes
[15:00:26] <SWPadnos_> when you load a component, there are 4 kinds of I/Os
[15:00:42] <SWPadnos_> input or output pins, and read or write params
[15:01:02] <rayh> yes
[15:01:04] <SWPadnos_> an output pin can't be connected to anything other than a signal (and then only one that has no other output connected)
[15:01:57] <rayh> unless or... is interposed
[15:01:57] <SWPadnos_> so, for output pins, you either place no user-settable control, or if you're nice, you can place an edit box next to each one, so the user can name a signal that the pin should drive
[15:02:30] <SWPadnos_> write params aren't important for this application, so they can be ignored
[15:02:41] <SWPadnos_> (write meaning that the component writes to them)
[15:03:43] <rayh> I'll have to study the motion modules a bit more before that becomes clear to me.
[15:03:46] <SWPadnos_> read params need to be editable, ideally from a checkbox (for bits), or a range-limited numeric (for integer types), or a float editor
[15:03:51] <SWPadnos_> I'll explain in a bit
[15:04:26] <SWPadnos_> the easiest is to just have an edit box, and let teh user type on / off / 0 / 1 / true / false for bits, rather than choosing a control based on the type
[15:05:18] <SWPadnos_> the last type is the input pin, and what that needs is a drop-down box with signals and/or output pins of the same type
[15:05:31] <SWPadnos_> choose one, and the pin gets connected there
[15:05:48] <SWPadnos_> that's all four, right?
[15:06:59] <SWPadnos_> any questions?
[15:07:11] <rayh> lots but I see where you are going.
[15:07:14] <SWPadnos_> heh
[15:07:57] <SWPadnos_> actually - I'm there already - that's it except for some possible filtering enhancements (don't show pins on the same component in the input dropdown boxes, etc)
[15:08:28] <rayh> except for the loopback conditions.
[15:08:43] <SWPadnos_> sure - OK. it's easier to leave that out anyway
[15:09:13] <SWPadnos_> I'm not sure you connect loopbacks externally, but you could, I suppose
[15:09:37] <rayh> I'm recommending that for all signals from EMC
[15:10:14] <SWPadnos_> ah - right. the motion enable stuff
[15:10:22] <rayh> don't know that I'll get my way though.
[15:10:43] <rayh> I've already tried pouting, crying, stamping my feet....
[15:10:59] <SWPadnos_> I guess flying off the handle is your last option
[15:11:11] <rayh> that is pretty severe.
[15:11:25] <SWPadnos_> "or I'll take my ball and my bat, and go home!"
[15:11:57] <rayh> can't hardly do that, to many irons depend upon this emc fire.
[15:12:34] <SWPadnos_> remember though that you can't drive a signal from more than one output pin, so looping back within motion means that no machine state can come back to emc
[15:12:56] <SWPadnos_> for any looped input, that is
[15:13:29] <rayh> The intent is loop back if you don't need the signal outside.
[15:13:46] <SWPadnos_> yep - that makes sense, since there's no information coming from the machine
[15:13:47] <rayh> break the loop and use the signal then send the product back.
[15:14:14] <rayh> That model works well in ClassicLadder
[15:14:39] <SWPadnos_> it's a good genereic model - if you have the hardware, connect it, if not, fake it
[15:14:52] <rayh> it's the first row in my estop rung
[15:15:17] <rayh> all of the others interpose verious external hardware
[15:15:39] <SWPadnos_> well - you know my view on that ;)
[15:15:57] <rayh> Yes I do.
[15:16:03] <SWPadnos_> if you don't have the hardware, then you can't read it back
[15:16:10] <rayh> right.
[15:16:18] <SWPadnos_> if you do, then you need to read it back, to tell emc when the machine is shut down
[15:16:35] <rayh> but you ought to be able to connect stuff between the out and the return.
[15:17:16] <SWPadnos_> absolutely, as long as the software can't prevent the external switches from shutting off the machine
[15:17:27] <SWPadnos_> (which I think is your position as well)
[15:18:10] <SWPadnos_> also assuming that the switches exist in the first place ;)
[15:19:05] <SWPadnos_> anyway - back to hal-notquite-gui
[15:20:18] <SWPadnos_> about "write params" - those are basically just status from HAL components. you can't connect them to anything, and you can't change them, so they aren't useful in making machine connections.
[15:22:04] <rayh> okay i see that unless you want to watch following error.
[15:22:17] <rayh> or is that a param
[15:22:18] <SWPadnos_> oops - sorry, those are read params (they're backwards from pins)
[15:22:33] <rayh> oh darn
[15:22:34] <SWPadnos_> ferror is a pin
[15:22:42] <rayh> true.
[15:23:10] <rayh> a write parm changes an internal module's state
[15:23:31] <rayh> like scale for pid
[15:23:41] <SWPadnos_> yep - that's why you put an edit box next to it - so the user can enter a value for you to 'setp' with
[15:23:56] <rayh> okay
[15:24:21] <SWPadnos_> again - it would be ideal if a type-dependent edit control were used, but that can come later
[15:24:52] <rayh> could you add a sentence to that defining type-dep?
[15:24:59] <SWPadnos_> sure
[15:25:03] <rayh> you mean bit v int
[15:25:13] <SWPadnos_> place a checkbox for bits, since they can only be true or false
[15:25:22] <SWPadnos_> basically
[15:25:36] <SWPadnos_> use an edit box that has up / down buttons for integer types
[15:25:43] <SWPadnos_> use a generic edit for floats
[15:26:05] <rayh> right. is there a way to get max and min values from HAL
[15:26:17] <rayh> or do we need to supply these from outside?
[15:26:18] <SWPadnos_> no, but it's inherent in the type
[15:26:49] <SWPadnos_> a HAL_U8 is an unsigned byte, so it can only go from 0-255
[15:27:02] <rayh> ah we are not talking about max or min EMC values only the nature of the signal
[15:27:05] <SWPadnos_> HAL_S8 is a signed byte, -128 to +127
[15:27:09] <rayh> pin excuse me
[15:27:24] <SWPadnos_> right - though having max and min would be nicve
[15:27:49] <rayh> I could hard code the HAL_S8 is a signed byte, -128 to +127 stuff
[15:27:53] <SWPadnos_> in many cases, you can get the max or min bny trying to set the param to the max, and reading it back
[15:28:14] <SWPadnos_> yes - that's an absolute limitaion, so it should be there
[15:28:27] <rayh> give it a billion and see what gets set?
[15:28:40] <SWPadnos_> yes - that works for params
[15:28:47] <SWPadnos_> not for pins though
[15:28:56] <rayh> spinbox would handle this i think
[15:29:11] <SWPadnos_> yes - a spinbox works for integers, but not as well for floats
[15:30:15] <rayh> k I saved our thoughts and will mull a bit.
[15:30:21] <SWPadnos_> ok
[15:30:54] <SWPadnos_> think about how HAL would need to be changed, to make the configuration task easier
[15:31:15] <SWPadnos_> (not halcmd syntax, necessarily, more about the data that hal exports)
[15:31:45] <SWPadnos_> input limits would be the first thing on that list, I guess
[15:32:22] <rayh> sorting by owner
[15:32:38] <SWPadnos_> heh - that's there, just not in halcmd ;)
[15:33:23] <rayh> sometime when you have a bit, talk to me about your idea for the library for direct access to hal.
[15:33:31] <rayh> not now I'm going brain dead.
[15:33:50] <SWPadnos_> ok - it's JMK's idea - we'll talk more
[15:34:16] <rayh> I don't have my tickle docs but there are a lot of C options
[15:34:47] <SWPadnos_> yeah - I note that there's a chapter on C libraries ot the like
[15:35:10] <SWPadnos_> yep - "The Tk C Interface"
[15:35:20] <SWPadnos_> and "The cl C Interface"
[15:35:24] <SWPadnos_> Tcl, that is
[15:35:56] <rayh> Right there is a lot of stuff on how to do but it is way beyond me.
[15:36:29] <rayh> I've got enough for the tuning demo on tuesday
[15:36:35] <SWPadnos_> I'll read up on it - I know C well enough, but I have only seen Tcl/Tk from emc ;)
[15:36:51] <SWPadnos_> good deal
[15:37:15] <SWPadnos_> there's no library at the moment, anyway
[15:37:18] <rayh> catch you later. Thanks for all the help
[15:37:28] <SWPadnos_> sure - see you
[16:57:54] <SWPadnos_> Hi Pete
[16:57:57] <petev> hi
[16:58:44] <petev> any thoughts on the multi language interp stuff?
[16:59:03] <SWPadnos_> not too many since this afternoon
[16:59:28] <SWPadnos_> I think we were discussing how the GUI may need to be aware of the underlying language, and how to represent machine states
[16:59:30] <petev> were you suggesting earlier that the interp give back general status, plus a text description?
[16:59:59] <petev> I would like to find a way to keep the GUI language neutral if possible
[17:00:24] <SWPadnos_> no, the "machine" gives back some well-defined status, and the interpreter translates that into appropriate text (or graphical) representations
[17:00:51] <petev> ok, so then the GUI won't show stuff like active Gs or Ms?
[17:01:06] <SWPadnos_> so we define some generic machine interface, and the interpreter needs to be the go-between from machine <-> GUI
[17:01:19] <SWPadnos_> yes - the GUI would - I think the GUI needs to be aware of the underlying language
[17:01:19] <petev> hang on
[17:01:36] <petev> some of the status is interp and other is canonical (or machine)
[17:01:54] <petev> and interp is the only one that should know anything about language
[17:02:25] <petev> if the GUI is language aware, that makes it hard to have a universal interface for all languages
[17:02:31] <SWPadnos_> I'm not sure that's possible - the GUI has to show things in the context of the current language
[17:02:37] <petev> you would have to match GUI to each language
[17:02:58] <SWPadnos_> yes it does, but then an interpreter that takes in DXF isn't likely to have MDI input
[17:03:05] <petev> what if the GUI only knew general stuff like the current feed rate
[17:03:12] <petev> hang on again
[17:03:22] <petev> I don't think any interp will ever take DXF
[17:03:33] <SWPadnos_> sorry - the GUI for a DXF interpreter wouldn't necessarily have MDI input
[17:03:38] <petev> DXF doesn't describe tool paths or MOPs or whatever
[17:03:58] <petev> I think something that takes DXF is a type of conversational CAM
[17:04:05] <SWPadnos_> right - as I mentioned earlier, the idea of a *really* generalized interpreter may be too much of a reach
[17:04:08] <petev> it would be built into the GUI in my opinion
[17:04:32] <petev> I think we could generalize status like feed, speed, etc.
[17:04:44] <petev> but stuff like params gets a bit tricky
[17:05:03] <petev> ok course the current interp drops the ball on params anyhow
[17:05:07] <SWPadnos_> what are "params" in that context?
[17:05:19] <petev> params are in gcode context
[17:05:26] <petev> might be vars in another language
[17:05:56] <petev> what I would like is a universal interp interface that task would use
[17:06:20] <petev> then you could just plug in a different interp withou having to re-write task and the GUIs
[17:06:38] <petev> ideally, the task interface would never change
[17:06:58] <petev> this may be a tall order, but we should give it some thought
[17:07:18] <SWPadnos_> I don't think that's doable, unless you restrict the range of possible interpreters to ones that behave like G-code, though with different names for the functions
[17:07:29] <petev> there is already the notion that the UI is stateless to support mulitple UI
[17:07:36] <SWPadnos_> plus or minus some function, like an ellipse or something
[17:07:46] <petev> let's look at it
[17:08:01] <SWPadnos_> ok
[17:08:22] <petev> if the GUI just passes MDI code throuhg transparently and just tells the interp to open files, it doesn't need to know about the language
[17:08:37] <petev> if we can generalize the machine status, it may be doable
[17:09:00] <petev> we can extend the statelessness with some description of the state data
[17:09:05] <petev> dare I suggest XML
[17:09:16] <SWPadnos_> no - I don't think you dare ;)
[17:09:37] <petev> then the GUI just displays it according to some data description and makes no assumptions about state (which it shouldn't be anyhow)
[17:09:55] <SWPadnos_> hmmm
[17:09:58] <petev> the problem area comes in when the GUI has something like a parameter editing page
[17:10:21] <SWPadnos_> that would restrict all state to be represented in only text form
[17:10:36] <SWPadnos_> or a relative / absolute display selection
[17:10:45] <petev> yes, and the GUI is supposed to be stateless anyhow
[17:10:47] <SWPadnos_> or commanded vs. actual position
[17:10:56] <petev> the real state is in the interp, canonical, etc.
[17:11:11] <SWPadnos_> it is stateless - the switch only changes the particular value it displays, it doesn't change any data
[17:11:29] <petev> I think we can generalize stuff like position, feed rate, speed, etc. and give numerical values for those
[17:12:00] <petev> anything that needs a numeric type could have one
[17:12:17] <petev> we could define a set of types and include that in the XML or whatever
[17:12:38] <petev> stuff like params is where it gets tricky for me though
[17:12:59] <SWPadnos_> Your idea may work, but I think there'll be some difficulty in having a GUI that can discover everything it needs to know about the interp, so it can display something that's sane for it (the interp)
[17:13:03] <petev> the gcode stuff in documented in terms of param number, and certain codes indirectly effect params
[17:13:12] <SWPadnos_> params are one place where discovery can be a bear
[17:13:19] <petev> agreed
[17:13:46] <SWPadnos_> also tool tables
[17:13:48] <petev> I wish cradek would get involved in this a bit as he might have some ideas
[17:14:02] <petev> I don't think tool tabless will be a problem
[17:14:09] <SWPadnos_> actually, anything that isn't directly captured in the interpreted language is hard
[17:14:18] <petev> they should be part of canonical and have the same features regardless of language
[17:14:54] <SWPadnos_> true, though one interp may make use of e.g. shape information, and another may not
[17:15:01] <petev> no, I think it's the opposite, anything that is directly captured in the language is hard, as it will be different for each language
[17:15:04] <SWPadnos_> so the editor might need to be different
[17:15:21] <petev> are you talking code editor?
[17:15:29] <SWPadnos_> I'm thinking that things that are *indirectly* captured are the hard part ;)
[17:15:31] <petev> I think the code editor should be text based
[17:15:45] <SWPadnos_> no I wasn't, but that would also be important
[17:15:50] <petev> I don't want to force all status to be interp status
[17:16:06] <SWPadnos_> think of it like HAL
[17:16:20] <petev> I see the task API giving back interp stuff (language dependent) and canonical stuff (machine dependant)
[17:16:22] <SWPadnos_> you can plug certain bits of information directly from the machine into the GUI
[17:16:30] <SWPadnos_> other pieces get filtered by the interp
[17:16:33] <petev> yes, the canonical stuff
[17:16:58] <petev> nothing is filtered by the interp, it actually has it's own language dependante state info
[17:17:26] <SWPadnos_> I think it comes down to the fact that a generic GUI can tell you everything about the machine state, but it can't tell you what that means to the current interpreter without help
[17:17:30] <petev> I view task talking to interp and canonical and exporting the status from both in the task API
[17:17:38] <petev> the task API is what the GUIs will use
[17:17:48] <petev> it's only the interp status that's the issue
[17:17:58] <petev> canonical status will be the same for all languages
[17:18:34] <SWPadnos_> yes, but it means something different in one language vs. another (ie, you display G21 in G-code, and "Metric" in another language)
[17:18:37] <petev> in the current implementation, everything is pretty much from interp and there are all the world view issues and sync stuff
[17:19:06] <petev> yes, but what if the GUI just said "units = mm"
[17:19:12] <SWPadnos_> or you display nothing, because the language in use only uses one resolution (like the form of G-code used for PCBs)
[17:19:25] <petev> why say "active G 21, 1, ..."
[17:19:55] <SWPadnos_> it could do that, but the expert in G-code may want to see what the interpreter is doing in G code
[17:20:17] <petev> if we can generalize stuff like linear units, angular units, feed rate, spindle speed, etc. across languages, then maybe we can do something
[17:20:29] <SWPadnos_> remember - a pluggable interp is cool, but the real question is "what does it do for the users"
[17:20:52] <petev> if the gcode expert wants the gcodes, maybe thats were the text stuff from the interp comes in
[17:21:08] <petev> give a numeric value for calcs, and a text description
[17:21:12] <SWPadnos_> I'd bet that most users of emc will only want to use one interp, and they will want the GUI to look like it was meant for their language
[17:21:46] <SWPadnos_> right - you can filter status vars to make them look G-code-ish (or whatever)
[17:21:48] <petev> so should I just forget the universal interp stuff?
[17:22:09] <SWPadnos_> I don't think so, but I think it would be good to consider a UI and interpreter as a package
[17:22:23] <petev> I think lerman is hacking gcode and would be better served using another language
[17:22:32] <petev> I would like to support it with this new stuff
[17:22:56] <petev> what about a universal UI plugin interface?
[17:23:04] <SWPadnos_> no - he's adding in functions that already exist in other variants of G-code, though in somewhat different forms
[17:23:10] <petev> you use a gcode plugin with the gcode interp
[17:23:30] <petev> way different forms and ugly in my opinion
[17:23:40] <petev> gcode just wasn't meant for what he wants
[17:23:46] <SWPadnos_> well - a customizable UI platform (even if it isn't user-customizable) would go a long way there
[17:23:52] <petev> and I have never seen conditionals in gcode
[17:24:16] <petev> I think jepler already added a code filter plugin
[17:24:22] <petev> why not a status plugin
[17:24:27] <SWPadnos_> as long as they're extensions, and don't change the meaning of basic code, I see them as harmless
[17:24:53] <SWPadnos_> the code filter gets run once, before the file is passed to the interp. status is repetitive
[17:24:56] <petev> well not if they inpact error recover, performance, maintainability, etc.
[17:25:05] <SWPadnos_> true
[17:25:30] <petev> the plugin could have an on the fly type interface
[17:25:37] <petev> it doesn't have to be batch mode
[17:26:01] <petev> let's think about these ideas and discuss more tomorrow
[17:26:08] <petev> I don't want to keep you too late
[17:26:14] <SWPadnos_> the jepler plugin is a batch-mode run before loading the file - anything else isn't there yet
[17:26:26] <petev> ok, but it could be
[17:26:31] <SWPadnos_> yes it could
[17:26:48] <petev> the GUIs are going to break anyhow unless we build the RPC/NML wrapper
[17:26:56] <SWPadnos_> I'm looking up the STEP-NC language - maybe you should as well (if you haven't already)
[17:27:20] <SWPadnos_> I'm not sure that all "languages" we'll want will be text based
[17:27:20] <petev> I haven't, only because I have enough to look up and I heard it was prorietary
[17:27:33] <petev> I haven't seen many CAMs that generate it either
[17:27:39] <SWPadnos_> it is, but apparently NIST got permission to release it for free programs (like emc)
[17:27:55] <petev> hmm, but what about the CAM side?
[17:27:59] <SWPadnos_> I don't know the details though
[17:28:06] <petev> are guys going to program step manually?
[17:28:31] <SWPadnos_> that's why I"m looking it up - I know that some of the more popular CAD programs have CAM packages that can use it (like SolidWorks, I believe)
[17:28:39] <SWPadnos_> I couldn't tell you
[17:29:05] <petev> so do you think it would make sense to put the RPC stuff right in canonical and interp and run 2 threads instead of one?
[17:29:22] <SWPadnos_> I have no idea, I'm afraid
[17:29:28] <petev> I have 2003 solid works and it has nothing for STEP
[17:29:39] <SWPadnos_> do you have the CAM module?
[17:30:05] <petev> if we put the RPC directly in interp and canon, then changing interps woud automatically change the API without hte need to change task
[17:30:20] <petev> task would just be a thread engine to drive the RPC servers
[17:30:34] <petev> I didn't see any CAM options in 2003
[17:30:38] <SWPadnos_> what API would change in that scenario?
[17:30:43] <petev> I have most of the options that were available
[17:30:53] <petev> the API to the GUIs would chage
[17:30:54] <SWPadnos_> they are up to 2006, you know ;)
[17:30:59] <petev> but the task code wouldn't
[17:31:09] <SWPadnos_> right - the task API doesn't change - OK
[17:31:10] <petev> u change the interp or canon, and GUI API changes
[17:31:21] <SWPadnos_> so the GUI should also change
[17:31:25] <petev> yeah, there really wouldn't be a task API at that point
[17:31:36] <petev> just straight from canon and inter to RPC
[17:31:51] <petev> yes, your model of GUI matched interp and canon
[17:31:59] <petev> matches
[17:32:31] <SWPadnos_> I think it's the best way - it would give the best possible GUI for each interp, rather than some least-common-denominator thing
[17:33:00] <petev> ok, let me think about that implementation and lets discuss more tomorrow after sleeping on it
[17:33:03] <SWPadnos_> unless we have some way of developing GUIs relatively easily
[17:33:05] <SWPadnos_> ok
[17:33:09] <petev> maybe cradek will be around too
[17:33:13] <SWPadnos_> sounds good to me
[17:33:17] <petev> cool
[17:33:23] <SWPadnos_> He's fixing his emc computer at the moment
[17:33:32] <petev> BTW, the 3x interp speed is still doing file IO
[17:33:35] <petev> ahh
[17:34:01] <petev> I bet I can get the speed up way more when I read a line at a time into a buffer
[17:34:06] <SWPadnos_> I think the kernel preloads some number of blocks (or at least a page at a time)
[17:34:24] <SWPadnos_> you only have the syscall overhead (which could be significant)
[17:34:29] <petev> yeah, but it's still the overhead of all those calls instead of an index
[17:34:37] <petev> exactly
[17:34:53] <SWPadnos_> out of curiosity, have you used PDMWorks?
[17:35:08] <petev> I'm dangerously close to starting on the canonical output
[17:35:17] <petev> no, what is PDMworks?
[17:35:36] <SWPadnos_> it's the "revision control" part of SolidWorks
[17:35:42] <petev> I tested expressions today
[17:35:52] <petev> no, I don't use solid works that much
[17:35:59] <SWPadnos_> ah - OK
[17:36:14] <petev> I have to convert stuff to degress for the trig stuff, but all else is working
[17:36:15] <SWPadnos_> expressions as in G1X(3+sqrt(2))
[17:36:18] <petev> yes
[17:36:21] <SWPadnos_> cool
[17:36:25] <petev> I have it in radians now
[17:36:30] <petev> emc is in degrees
[17:36:36] <petev> but that's minor
[17:36:43] <SWPadnos_> standard C math library?
[17:36:50] <SWPadnos_> (or C+)
[17:36:52] <SWPadnos_> C++
[17:36:55] <petev> I took the liberty to fix some of the ugly kramer grammer
[17:36:58] <petev> it's C++
[17:37:15] <SWPadnos_> uh-oh - fix usually means break
[17:37:15] <petev> it recognizes a superset of krammers stuff
[17:37:22] <petev> no, I was carefull
[17:37:25] <SWPadnos_> ok - then it may work ;)
[17:37:31] <petev> try an atan in emc
[17:37:46] <petev> you have to divide it by another expression, or no go
[17:37:50] <petev> there are others too
[17:38:00] <SWPadnos_> by the way - I only received a fairly short header file earlier - is that what you sent?
[17:38:10] <petev> like expressions have to be inside [] but not if they are simple like a real number
[17:38:15] <petev> I though that was bunk
[17:38:33] <petev> I only require the [] when needed for precedence
[17:39:00] <petev> I also added operator precedence and associativity which kramer didn't even spec
[17:39:06] <SWPadnos_> I think they're separators more than anything - G code doesn't require any spaces
[17:39:15] <petev> it's more deterministic now
[17:39:41] <petev> yeah, but you don't need th[] for separators either
[17:39:58] <petev> I'll email you the latest and you can try and break it
[17:40:04] <SWPadnos_> in fact, I think it's supposed to ignore spaces entirely, so 12 is equal to 1 2
[17:40:15] <SWPadnos_> (I'm not positive about that though)
[17:40:40] <petev> hmm, that may be ugly, kramer doesn't do that and neither do I
[17:40:45] <petev> but spaces are ignored
[17:41:10] <SWPadnos_> I thought I had read that the first thing the interp does is strip out all spaces
[17:41:26] <petev> not when I look at the code
[17:41:33] <SWPadnos_> ok - it must be me then
[17:41:50] <petev> it may be a gcode thing though, I just don't think it's emc
[17:41:59] <SWPadnos_> ok
[17:42:02] <petev> it's poor practice anyhow to write 1 0 for 10
[17:42:27] <SWPadnos_> I agree
[17:42:42] <SWPadnos_> I also thikn it's bad to write G0X0Y12Z-0.43
[17:42:49] <SWPadnos_> but that's just me :)
[17:43:35] <petev> yeah, that's not quite as bad though
[17:43:43] <petev> I sent it off to u
[17:43:49] <petev> see if you can break it
[17:43:53] <SWPadnos_> OK - thanks
[17:44:02] <petev> oh, I think the one u got is printing expressions
[17:44:07] <petev> but it's in radians
[17:44:24] <petev> I'll fix that later and send u another
[17:44:52] <SWPadnos_> That's fine - I can test with radians as well
[17:44:56] <SWPadnos_> or change it
[17:45:12] <petev> yes, I sent u the source too
[17:45:35] <petev> wife's calling, gotta run, let's continue tomorrow
[17:45:43] <SWPadnos_> all right - see you then
[17:45:52] <petev> gnight
[17:45:57] <SWPadnos_> night