#emc-devel | Logs for 2007-08-17

[11:02:26] <SWPadnos> alex_joni, how do you get the loggers running? I haven't managed is sincethe day I created your login
[11:08:33] <alex_joni> I simply run them from my login
[11:08:42] <alex_joni> cd to ~emcboard/logger/
[11:08:50] <alex_joni> and run the logger.sh script
[11:09:06] <alex_joni> I didn't manage to do that as emcboard or as su emcboard rfom my login :/
[11:18:42] <SWPadnos> hmm. I wonder if ownsership of the logs somehow changed or something stupid like that
[11:22:35] <SWPadnos> well, the .pid files are certainly owned by you, and can't be written by anyone else
[11:22:52] <SWPadnos> -rw-r--r-- 1 juve pg167418 6 2007-08-17 01:26 logger-emc-devel.pid
[11:22:52] <SWPadnos> -rw-r--r-- 1 cncman pg167418 6 2006-04-16 14:15 logger-emc-mazak.pid
[11:22:53] <SWPadnos> -rw-r--r-- 1 juve pg167418 5 2007-08-17 01:26 logger-emc.pid
[11:39:26] <cradek> can you just make the script rm them?
[11:40:15] <cradek> also, put a set -x at the top of the script and see where it fails
[11:40:57] <SWPadnos> ufortunately, the script just runs the two loggers - it's two lines long
[11:41:09] <SWPadnos> the logger itself is a perl script
[11:41:25] <SWPadnos> I'm assuming the set -x doesn't carry into the perl part ...
[11:41:51] <cradek> oh.
[11:42:02] <cradek> so the mystery is in the perl
[11:42:08] <SWPadnos> yes
[11:42:35] <cradek> you could still have the sh check for the pid files being stale and rm them
[11:43:29] <SWPadnos> it should do that already. I think they're there so the perl script can clean up after an unexpected exit
[11:43:46] <cradek> bbl
[11:43:49] <SWPadnos> they may not be the problem at all (but I'm still suspicious)
[11:43:52] <SWPadnos> seee you
[13:26:19] <skunkworks> logger_dev: bookmark
[13:26:19] <skunkworks> Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2007-08-17.txt
[13:36:21] <cradek> the way the boss prompts for mdi is interesting - it only requires a numeric keypad. you press MDI, and it prompts with G. Then you enter the gcode number, and it prompts for the appropriate words (x,y,z,etc). If you don't want one of them in the MDI command, you just press enter for that one. At the end you can review them (cycle through) and then press Execute.
[13:37:48] <cradek> I think you can enter and store a program that way - but I haven't figured out how (and who would want to?)
[13:38:27] <SWPadnos> think of all the typing you save
[13:38:41] <SWPadnos> by not typinmg in the letters :)
[13:38:47] <cradek> um righto
[13:45:37] <cradek> it has a couple other interesting features
[13:45:52] <cradek> a "quill up" button that does like G0 G53 Z0
[13:46:19] <cradek> a few options for test run, like run with max feed rate for everything, and run without moving Z
[13:46:26] <SWPadnos> hmmm
[13:46:37] <skunkworks> our fanuc has a numeric keypad - you have to press a function key to get the letter - then you type the numbers.
[13:46:39] <cradek> the max feed run is neat.
[13:46:41] <SWPadnos> it would be interesting to be able to mask axes
[13:47:15] <cradek> I think those are the only things that have made me think "hmm, that's cool" - the rest of it is pretty awful
[13:47:31] <skunkworks> heh
[13:47:38] <cradek> for instance the only incremental jog you have is .0001"
[13:47:52] <cradek> the only thing the jog wheel can do is .002"/click
[13:48:18] <SWPadnos> the wiki seems to be working - I wonder if it would make sense to add some of these observations to either the wish list page or some "expensive controls do this" page
[13:52:03] <cradek> when you switch to metric mode, the display changes to mm, but the jog wheel still moves .002" at a time
[13:53:05] <SWPadnos> somebody mentioned that axis seems to do the same thing ...
[13:53:39] <SWPadnos> but I don't know what version that was - it could be one that has the settings in the ini (with units)
[13:53:45] <cradek> in AXIS you can have metric or inch (or both) jog increments no matter how it's currently displaying
[13:53:58] <SWPadnos> right - I don't know if that was the case
[13:54:04] <SWPadnos> I suspect it was
[13:54:26] <cradek> I don't follow
[13:55:03] <SWPadnos> well, I don't remember if this was on IRC or in a user email, but he mentioned the axis "still jogged in inches even though the machine is metric"
[13:55:25] <SWPadnos> I don't know whether he has a version of AXIS with the jog increments set in the ini, or if it was a bug, or if it was user error
[13:55:38] <jepler> when axis displays ".01" in the jog increment box, it jogs .01 machine native units, regardless of whether G20/G21 is in effect or whether mm/in is currently used for the DRO
[13:55:42] <SWPadnos> so no worries until it's brought up again :)
[13:55:45] <SWPadnos> ok
[13:55:53] <jepler> if it displays ".01 mm" then it jogs .01mm, regardless of ...
[13:56:01] <jepler> if it displays ".01 in" then it jogs .01in, regardless of ...
[13:56:07] <jepler> (the latter two features may be new in 2.2, I'm not entirely sure)
[13:56:12] <SWPadnos> that first case may be what he saw, and I can see that it could be surprising
[13:56:12] <cradek> ^ correct behavior IMO
[13:56:46] <cradek> but blindly switching the units of the increment is wrong - .01 .001 .0001 are totally inappropriate in mm
[13:56:47] <jepler> I don't know if the behavior when no units is displayed is different from tkemc, but at least in 2.2 it's possible to explicitly get exactly what you want
[13:57:14] <SWPadnos> I'm sure it was case 1, since I don't think the person had compiled their own
[13:57:14] <cradek> yeah, I like how it is now
[13:57:39] <SWPadnos> I can definitely see that using a machine in mm (regardless of the native units), I'd expect the jog to also be in mm
[13:57:50] <SWPadnos> though it also makes sense that G90/91 shouldn't change the jog scaling ...
[13:58:12] <cradek> you mean g20/g21?
[13:58:19] <SWPadnos> err - yeah :)
[13:58:29] <SWPadnos> it's a simple off-by-70 error
[13:58:34] <cradek> yeah
[13:58:40] <SWPadnos> happens all the time
[13:59:21] <cradek> poor jmkasunich
[13:59:32] <SWPadnos> plumbers digging up the DSL lines?
[13:59:35] <skunkworks> seems to be having internet problems..
[17:00:54] <jepler> bizarre -- this e-mail I just got was cc'd to: Cc: emc group <emc@nist.gov>
[17:00:59] <jepler> is there any such thing?
[17:01:47] <cradek> there was long ago
[17:02:03] <jepler> er, I shouldn't say Cc'd
[17:02:04] <jepler> From: "watchman1@fastmail.fm" <watchman1@fastmail.fm>
[17:02:07] <jepler> To: Jeff Epler <jepler@unpythonic.net>, emc group <emc@nist.gov>
[17:02:58] <cradek> www.sherline.com/emc/Integrator_Handbook.pdf still has that address in it
[17:04:14] <SWPadnos> it looks to me like the error is on his line N900 - that's the 49th non-blank line
[17:04:46] <SWPadnos> maybe it should be this: N0900 G0 A[0-[#45]/3]
[17:05:02] <SWPadnos> [] removed from around [#45]/3
[17:05:10] <SWPadnos> but I can't test that
[17:30:47] <alex_joni> jepler: was it this email?
[17:30:49] <alex_joni> Subject: Re: [Emc-users] Problem with EMC script - understanding error message
[17:30:53] <alex_joni> From: "watchman1@fastmail.fm" <watchman1@fastmail.fm>
[17:30:55] <alex_joni> Date: Fri, August 17, 2007 11:55 am
[17:30:58] <alex_joni> To: "Jeff Epler" <jepler@unpythonic.net> (less)
[17:31:00] <alex_joni> gene.heskett@verizon.net
[17:31:05] <alex_joni> "EMC users list" <emc-users@lists.sourceforge.net>
[20:01:38] <alex_joni> jepler: around?
[20:10:48] <jepler> alex_joni: yeah
[20:14:05] <alex_joni> I was thinking about something
[20:14:17] <alex_joni> you have a very nice python sript called mdi
[20:14:32] <alex_joni> would it be possible to make a similar script that is called by a custom M-code?
[20:14:47] <alex_joni> it could :
[20:14:53] <alex_joni> 1. remember current linenumber
[20:15:03] <alex_joni> 2. switch from AUTO to mdi, manual, whatever is needed
[20:15:13] <alex_joni> 3. do some funky IO or motion commands
[20:15:20] <alex_joni> 4. set next-run line
[20:15:24] <alex_joni> 5. switch back to auto
[20:15:35] <jepler> you could sure try that -- all those individual operations are possible in a python script
[20:15:36] <alex_joni> 6. resume the program
[20:15:47] <jepler> but my faith in set-next-line is nonexistent
[20:16:02] <alex_joni> I think that would really address the "macro" needs
[20:16:03] <jepler> for instance, I know it won't work if you're in the middle of an O- construct
[20:16:12] <alex_joni> right, I agree
[20:16:32] <alex_joni> the alternative is to have support in emc to switch to mdi or manual while paused
[20:16:37] <alex_joni> but that's another can of worms
[20:17:37] <alex_joni> on another topic.. I put the stuff you said about IO on a wiki page
[20:17:41] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?IOCapabilities
[20:17:49] <alex_joni> * alex_joni plans to follow that plan
[20:17:50] <jepler> oh good
[20:17:56] <jepler> let me know when you've implemented it
[20:18:12] <alex_joni> wanna test something?
[20:18:32] <jepler> what's that?
[20:18:54] <cradek> it's when you try something before releasing it
[20:19:16] <jepler> cradek: that joke is something I never get any more or less tired of
[20:19:18] <alex_joni> jepler: it sounded like you have a plan for that after I implement it
[20:19:54] <alex_joni> like you have some app in mind where this would help
[20:20:43] <alex_joni> cradek: any thoughts about g-codes I should use?
[20:21:02] <jepler> alex_joni: not really .. it was brought up again by this discussion of "macros"
[20:21:05] <jepler> on the list
[20:23:06] <jepler> "do something based on the current state of the world" is one of the things missing between "O-words" and the things our users want to do with "macros"
[20:23:55] <alex_joni> like wait for something, then do anything
[20:24:01] <alex_joni> or check a value and branch
[20:26:45] <jepler> I ordered the "xenbot" 3-axis router and a xylotex 3-axis board .. so in a week or two I'll have a CNC machine
[20:26:54] <alex_joni> yay
[20:38:18] <skunkworks> jepler: great
[20:38:42] <skunkworks> * skunkworks can't wait to read about it on your website
[20:41:16] <alex_joni> does any of you get a popup window from this page? http://www.mhsware.com/
[20:41:49] <skunkworks> no
[20:43:05] <jepler> no but I have a bunch of stuff installed on my firefox so I'm not likely to anyway
[20:43:57] <skunkworks> I am running ie7 so I probably have a virus.. ;)
[20:44:04] <skunkworks> or it is a virus or..
[20:46:37] <skunkworks> mozzila doesn't either
[20:46:46] <alex_joni> ok, thanks..
[20:46:57] <alex_joni> I got it once on FF.. no idea what was happening
[20:47:01] <alex_joni> seems to be gone now
[20:48:17] <cradek> I'd like to see motion.analog-out-*
[20:48:39] <alex_joni> cradek: canon code is there .. I think
[20:53:13] <alex_joni> cradek: can you add some specs to that page? I'll implement it..
[21:03:02] <alex_joni> this stuff (inputs queried..) should be RT.. right?
[21:04:30] <cradek> I haven't been keeping up, sorry
[21:05:11] <alex_joni> no problems, I'm adding a couple of input-related functions
[21:05:22] <alex_joni> so you can have your program wait on an input
[21:05:48] <alex_joni> or check the value of a certain something, and do some funky o100 if-branching
[21:07:27] <SWPadnos> that should only need to be as RT as the interp, since canon doesn't "branch"
[21:07:42] <alex_joni> SWPadnos: how about wait?
[21:08:04] <alex_joni> one could do external feedhold + CL
[21:08:05] <SWPadnos> that should probably be RT, on the task timescale
[21:08:10] <alex_joni> but this should be similar
[21:26:18] <jepler> alex_joni: I think the pins should be *named* with the same prefix as the existing digital output pins
[21:26:40] <jepler> alex_joni: the "read"s will be fundamentally non-rt, because the result of reading an external input is to modify future gcode execution
[21:27:24] <jepler> it would be nice if the architecture lets the "write"s be done in RT and not prevent blending
[21:27:48] <alex_joni> write's beeing output from emc?
[21:28:06] <jepler> yes, I'm talking the view from the interpreter
[21:28:24] <alex_joni> there are 2 to set and 2 to reset
[21:28:27] <cradek> jepler: that's sure possible
[21:28:32] <alex_joni> I think one pair works with blending too
[21:28:44] <cradek> not today it doesn't
[21:28:47] <alex_joni> (the ones that happen imediately)
[21:28:52] <alex_joni> not waiting on motion to start first
[21:28:58] <cradek> oh
[21:29:02] <jepler> I tried them earlier and the one that said it was "synched with motion" did nothing as far as I could tell
[21:29:06] <alex_joni> cradek: I'm just guessing on how blending interacts
[21:29:23] <alex_joni> jepler: it's supposed to get set once the motion actually starts
[21:29:26] <cradek> I don't see why there should be more than one type of output
[21:29:32] <alex_joni> but maybe chris took them out of TP
[21:29:40] <alex_joni> cradek: I think some plasma/laser weirdness
[21:29:52] <jepler> I don't know how the one that *does* do something interacts with motion -- I didn't scope it, I just ran 'halcmd show' and entered MDIs
[21:30:10] <alex_joni> jepler: right
[21:30:27] <alex_joni> well.. it worked right at one point, I think
[21:31:38] <alex_joni> eek.. I knew this was going to be hard
[21:31:50] <jepler> good luck!
[21:31:52] <jepler> * jepler wanders off
[21:31:59] <alex_joni> jepler: the canon call for WAIT you proposed
[21:32:10] <alex_joni> it can't be blocking and return a value
[21:32:38] <jepler> OK -- it should "work like probing", then
[21:32:52] <alex_joni> yeah, probably
[21:32:57] <jepler> however exactly that works
[21:33:02] <alex_joni> drive safe :P
[21:33:33] <jepler> if you end up working on the interp part, probably best to do it on a branch .. I'm not convinced this can be finished in short order, and I wouldn't want it to hold 2.2 back.
[21:33:57] <alex_joni> I'll try to finish canon & task & motion for tomorrow
[21:34:26] <alex_joni> then we'll see about interp
[21:39:35] <alex_joni> jepler: I just remembered why inputs are bad.. because of lookahead in the interp
[21:48:57] <alex_joni> hi roltek
[21:49:54] <roltek> hi alex how you doing
[21:50:04] <alex_joni> pretty ok..
[21:50:23] <alex_joni> was wondering if other controls have a g-code to wait for an input
[21:50:46] <roltek> explain further
[21:51:03] <alex_joni> say I write some g-code to wait for an input to activate
[21:51:26] <alex_joni> but if it doesn't (and there's a timeout), I can write an if-branch to alert the operator
[21:51:33] <roltek> are we talking about m codes
[21:51:41] <alex_joni> m-codes or g-codes .. whatever
[21:51:52] <alex_joni> * alex_joni is interested in the mechanism
[21:52:31] <roltek> m codes will turn on relays or machine end lights
[21:52:41] <alex_joni> the issue I see here is that the interpreter (parsing the g/m-codes) can't know in advance what the input will be
[21:52:49] <alex_joni> roltek: yeah, those are outputs, and easy to handle
[21:53:23] <alex_joni> but say you want to write a program which checks a barcode, and based on that runs a certain subroutine
[21:53:30] <roltek> we use m codes for turning on air instead of coolant and for rotary indexer for my machines
[21:53:51] <alex_joni> roltek: still.. those are all outputs, going from the machine to the outside world
[21:54:12] <alex_joni> and maybe you have some feedback from them (a light turns on, etc), but not what I'm asking
[21:56:02] <roltek> i would think an input would be handled like a macro we use them on turning center for counting parts that way we program in thebar to stop pulling after so many parts or sub program
[21:57:13] <alex_joni> hmm
[21:58:40] <alex_joni> roltek: got the ballot?
[21:58:50] <roltek> yes i did
[21:59:02] <roltek> thank you guy's very much
[22:05:25] <alex_joni> ok, no problem
[22:11:52] <alex_joni> if we expect to make decisions (e.g. o-word branches) based on read inputs, I think the interpreter needs to stop interpreting until the get_input command executed
[22:12:38] <SWPadnos> it needs to get status back before issuing any more canon calls, but it can still interpret more code
[22:13:23] <SWPadnos> (ie, it could make an internal queue of canon /NML commands for each branch target, and send the appropriate one when it gets the read back)
[22:15:47] <alex_joni> yeah, but that requires majour restructuring
[22:15:56] <alex_joni> as it is now interp is run by task
[22:16:13] <alex_joni> and when it gets a command it knows, it simply calls the CANON call
[22:16:23] <alex_joni> which puts the stuff on the 'interp_list'
[22:16:51] <SWPadnos> sure - I'm only pointing out that the interp need not stop interpreting, it just needs to stop sending commands to canon
[22:16:53] <alex_joni> which is actually the canon_list
[22:17:10] <alex_joni> SWPadnos: as it is now, the two are too tightly coupled together
[22:17:22] <SWPadnos> well - it *can* stop interpreting :)
[22:17:41] <alex_joni> yes, that's what I'm starting to think..
[23:28:26] <alex_joni> * alex_joni heads for bed
[23:28:32] <alex_joni> http://pastebin.ca/661694 <- what I did so far
[23:28:41] <alex_joni> will read comments/ideas in the morning ;)