Back
[01:20:13] <cradek> chris@rover:~$ halcmd -s
[01:20:13] <cradek> Segmentation fault
[01:20:28] <jmkasunich> ?
[01:22:03] <jmkasunich> unique to script mode?
[01:22:03] <SWPadnos> mlock limit?
[01:22:59] <cradek> still looking...
[01:27:43] <cradek> inscrutable!
[01:27:59] <SWPadnos> scrut harder! :)
[01:28:01] <jmkasunich> unrepeatable?
[01:28:24] <cradek> no, simple bug, halcmd -s does something wrong (it expects a command to be on the commandline, but there isn't)
[01:30:11] <SWPadnos> oops. that's probably my fault
[01:53:24] <CIA-40> EMC: 03cradek 07TRUNK * 10emc2/src/hal/utils/halcmd_main.c: fix silly segfault on "halcmd -s"
[01:53:47] <cradek> embarassing how long it took me to fix that
[01:53:59] <cradek> getopt() is kind of obscure
[01:56:47] <SWPadnos> that's an understatement
[02:14:29] <cradek> hey I even did what I set out to do, after that sidetrack
[02:38:32] <jmkasunich> and what was that?
[03:40:10] <cradek> write a simple 'waitfor' script that exits when a hal signal gets to a certain state
[03:40:51] <jmkasunich> for M1xx stuff?
[03:41:03] <cradek> some of the ladder on the lathe has a 'request' input, like request-low-gear, set by a M10x, and I wanted M10x to wait until LowGear actually happens, in this case after the spindle stops.
[03:41:14] <jmkasunich> ah
[03:41:15] <cradek> same for hi/lo gear, collet open/close
[03:41:40] <cradek> the interp waits for M10x to exit (successfully) before proceeding
[03:41:51] <cradek> so it ends up doing just what I want
[03:41:57] <jmkasunich> what does it do if M10x returns failure?
[03:42:12] <cradek> M5; M10x (low gear); S300 M3
[03:42:24] <cradek> jmkasunich: aborts I think
[03:43:42] <jmkasunich> probably not easy to implement "gearshift is stuck" detection tho
[03:44:14] <cradek> some stuff, like collet closer state, actually has feedback
[03:44:29] <cradek> but I have not hooked it up to anything yet
[03:44:53] <cradek> so you could detect "can't close the collet because there is no air pressure" for instance
[03:45:00] <jmkasunich> so the collet closer does not use the waitfor script at the moment
[03:45:19] <cradek> yes it does, but only because I make it wait for the spindle to stop
[03:45:35] <jmkasunich> but it doesn't waitfor "collet closed"
[03:46:10] <cradek> I think I wrote that, but it will rarely/never wait
[03:46:10] <jmkasunich> I guess error detection in many of these cases would be a timeout
[03:46:21] <cradek> yes possibly
[03:46:30] <jmkasunich> if 10 seconds and collet still open, something is wrong, return failure and abort program
[03:46:47] <cradek> the whole thing is a hack, but it's an easy hack and it does what I want
[03:46:52] <jmkasunich> heh
[07:25:02] <alex_joni> cradek: M66 could do that too, with a timeout
[07:25:17] <alex_joni> but that means putting it into g-code .. which is probably a pain
[10:33:09] <micges> in today chechout trunk: stopping program cause error: can't do that (EMC_TRAJ_SET_TELEOP_ENABLE) in auto mode with the interpreter idle
[10:46:18] <micges> selecting [machine->skip lines with '/'] while running program make this option inconsistent with preview
[13:07:54] <jepler> micges: the second is an expected behavior -- you have to reload after toggling that option for the preview to be accurate.
[13:11:42] <jepler> cradek: your revision 1.189 of axis.py causes the other behavior micges mentions
[13:12:50] <jepler> er, wait, I'm wrong about block delete + reload too -- there is an explicit reload there; it must also be broken by that same change
[13:34:04] <SWPadnos> man. something has got to be done to make systems boot into the RT kernel after EMC2/RTAI installation
[13:34:24] <SWPadnos> I think that's been 50% of the user problems lately, maybe more
[13:47:52] <rayh> Yep.
[13:48:26] <rayh> I almost wish that we didn't have the install script.
[13:48:38] <SWPadnos> or something
[13:49:20] <rayh> Is there a way to expand that script to modify the bootloader?
[13:49:23] <SWPadnos> I don't know if it's intentional that the RT kernel isn't selected, or if it's that the version is older and therefore isn't selected in the "normal" way
[13:49:38] <SWPadnos> I know it can, since new kernels get selected usually
[13:50:31] <rayh> This box has that same issue.
[13:50:56] <SWPadnos> there are downsodes to automatically switching though, since the extra modules aren't installed by default
[13:51:16] <SWPadnos> so some people would lose video settings (many I think), and some will lose their net connection (wireless) ...
[13:54:29] <rayh> It looks like there are quite a few options in this menu.lst that I've not seen before.
[13:54:36] <SWPadnos> heh
[13:54:45] <SWPadnos> there are "meta-options" and actual options
[13:55:10] <SWPadnos> I think things with one # can be meta-options - settings that the scripts use to decide what to do
[13:55:13] <rayh> ## should update-grub adjust the value of the default booted system
[13:55:13] <rayh> ## can be true or false
[13:55:13] <rayh> # updatedefaultentry=false
[13:55:14] <rayh> ## should update-grub add savedefault to the default options
[13:55:14] <rayh> ## can be true or false
[13:55:14] <rayh> # savedefault=false
[13:56:23] <SWPadnos> https://bugs.launchpad.net/ubuntu/+source/grub/+bug/88507
[13:57:01] <SWPadnos> apparently, the default noot image is only updated if vmlinuz and initrd.img are symlinks, which doesn't happen by default any more
[13:57:06] <SWPadnos> s/noot/boot/
[13:58:46] <rayh> I do see two generic kernels listed there. It would probably be instructive to see how a new kernel changes the default boot.
[13:58:55] <SWPadnos> http://ubuntuforums.org/showthread.php?t=809163
[13:59:24] <SWPadnos> apparently, updatedefaultentry is there to keep the current kernel as the default when you install others - ie, it does the opposite of what we want
[14:04:26] <rayh> Right I see that in man update-grub
[14:09:30] <rayh> I think if we changed that and then a new generic kernel came along it would point to that rather than the rtai.
[14:10:45] <SWPadnos> yeah, that's the danger of a stock install then EMC2/RTAI install
[14:11:00] <SWPadnos> the generic kernel is still there, and is likely to get updated more often
[14:11:39] <rayh> We need some way of making the rtai replace the generic at position 0 in the list.
[14:11:45] <SWPadnos> actually, if we'd change to the RT kernel as part of the install, then having updatedefault=true would keep the RT kernel selected
[14:13:16] <rayh> You lost me but I believe you.
[14:14:23] <SWPadnos> heh
[14:48:40] <cradek> I'm confused
[14:48:53] <cradek> jepler: what about block delete is broken?
[14:52:45] <cradek> I'm getting the teleop message too though. I thought it was an old bug that shows up on machines that take a long time to abort, but I must have at least made it worse
[14:53:01] <cradek> at first glance I don't see axis.py even sending that message - must be deeper.
[14:54:09] <cradek> oh set_joint_mode()/c.teleop_enable()
[14:57:13] <cradek> but I don't see how it is called. I will study it more later.
[15:09:47] <jepler> cradek: well, I didn't test block delete myself, but micges says it's broken (doesn't reload? doesn't reload right?)
[15:13:20] <micges> jepler: option is switched and preview is not reload while running
[15:13:26] <micges> bbl
[15:22:27] <KimK_IA> KimK_IA is now known as KimK_IA_AFK
[15:36:57] <jepler> (I thought maybe it wasn't automatically reloaded just because you switched the menu option, but I saw in that diff that it is reloaded there)
[18:50:45] <micges> second problem is in set_mode_from_tab function in axis.tcl
[18:55:39] <micges> jepler: while running selecting block delete switch that option but while running program the preview isn't reload at all
[18:56:14] <micges> errr
[18:56:53] <micges> while clicking "block delete" option while running program the preview isn't reload at all
[19:33:21] <cradek> I have to admit I don't know what changing block delete while running should do, and if I knew that, I then wouldn't know how to make emc do that
[19:35:16] <SWPadnos> in terms of the preview, about the only thing that would make sense would be to have "potentially deleted" blocks in a separate display list, and turn display of that list on and off with the switch
[19:35:22] <SWPadnos> but it's still wrong, so why bother
[19:36:08] <cradek> no, with block delete you are choosing between two entirely different programs
[19:36:19] <SWPadnos> can't it be changed while running?
[19:36:21] <cradek> consider /G91
[19:36:29] <SWPadnos> sure
[19:36:58] <SWPadnos> and there's also the problem of the first move that isn't optional starting in an unknown place
[19:37:02] <cradek> if you can change it while running, you can choose between many many programs
[19:37:06] <SWPadnos> heh
[19:37:36] <cradek> one problem (I almost said "the" problem) is that while running you've already interpreted ahead
[19:38:23] <SWPadnos> right, and the preview is the ultimate there - it previews the whole program with whatever conditions exist at load time
[19:39:34] <micges> ok then didn't allow to toggle delete switch while runnig program
[19:40:06] <SWPadnos> I'm pretty sure it's meant to be changeable during a program run
[19:41:11] <micges> emc isn't prepare to allow such things (and much more) while running becouse long interp queue
[19:41:43] <cradek> that is the simplest fix that would give consistent easily-understood behavior
[19:41:44] <SWPadnos> yeah - changes like that should cause a queue clear and re-interpret
[19:47:02] <micges> emc should have to interp queueing but parameters to queued commands must be taken while running specific command - this will allow great imporve functionality and future developmnent
[19:50:44] <micges> anyone know how to do that ?:)
[19:51:49] <SWPadnos> I'm not sure I understood whatyou said ;)
[20:00:51] <micges> emc should preload all gcode and interp should only execute block deleted command if block delete switch at the moment is off
[20:01:12] <micges> else it should skip queued command
[20:09:33] <SWPadnos> you can't do that, for the reason cradek pointed out
[20:10:00] <SWPadnos> what if the optionally deleted block is a mode change (G90 or G91), or a units change, or a plane change?
[20:10:52] <SWPadnos> so the question arises - does the block delete input get looked at when the interp is reading ahead and queueing, or when the blocks are getting executed?
[20:11:37] <micges> should do the second
[20:12:06] <SWPadnos> in that case, you can't do more than one block of lookahead
[20:12:08] <micges> and if g90 is in block delete then it could be skipped
[20:12:34] <SWPadnos> err - you can't queue more than one block, and even that may have to be re-interpreted if the switch changes
[20:12:51] <micges> I know
[20:13:17] <micges> emc must allow such that I said
[20:13:27] <micges> it doesn't do that now
[20:13:52] <SWPadnos> the implication of what you said (if I understood it correctly) is that there can be no interpreter lookahead
[20:14:02] <SWPadnos> which isn't necessarily a bad thing
[20:14:27] <micges> why not ?
[20:15:32] <SWPadnos> because g-code can change the expected machine state on every line, and that optional delete therefore gives 2^N possible programs (where N is the number of lines of lookahead)
[20:15:54] <micges> can't it be that it will look ahead and execute queued block command only if switch is off ?
[20:16:00] <SWPadnos> no
[20:16:22] <SWPadnos> consider this: a program that makes a hexagon, but 3 sides are optionally deleted
[20:17:07] <SWPadnos> the shape you get depends on how many of those optional blocks are deleted
[20:17:45] <micges> yup
[20:17:58] <SWPadnos> actually, I'm not sure what the queued entities are - if they only contain the next endpoint, (like line to X,Y), then it could work
[20:18:32] <SWPadnos> if they say "line from x1,y1 to x2,y2", then it can't, because x1,y1 depends on which blocks are deleted
[20:18:45] <SWPadnos> and that's just geometry, let alone modal settings
[20:19:06] <Lerman> And parameter assignments.
[20:19:10] <SWPadnos> sure
[20:19:35] <SWPadnos> and then add the possibility that there may be 1000 optionally deleted blocks, and you have an interesting queue stalling problem :)
[20:19:55] <SWPadnos> note: this may all work fine in practice, but in theory it looks pretty bad to me ;)
[20:20:53] <Lerman> The state of the block delete switch should only change when the machine is stopped.
[20:21:13] <SWPadnos> I don't know that that's the original intent
[20:21:54] <SWPadnos> consider something like an optional tool change (skilled operator decides when the tool "sounds bad", and hits a button so it can be changed at the next opportune moment)
[20:23:42] <jepler> axis is never going to show you a preview with the block delete changed part way through. it's also not going to reload while the program is actually running.
[20:23:55] <Lerman> So, the block delete switch would be kept ON until the operator wanted to change a tool.
[20:24:28] <Lerman> The operator would turn OFF block delete so that the blocks containing the tool change were executed.
[20:24:29] <SWPadnos> whichever sensitivity it needs, yes
[20:26:28] <Lerman> Well, just feed hold the machine, jog to a good position and change the tool, etc. (Whoops -- we can't do that with EMC) :-)
[20:26:38] <SWPadnos> heh
[20:28:16] <micges> lerman: that solution to change tool is much better that using delete swich
[20:28:44] <Lerman> Except that the one with the delete switch would work right now.
[20:29:24] <SWPadnos> it could have been useful on the Mazak also, when running those servo mounts
[20:29:44] <SWPadnos> you do each station as a single optionally deleted call
[20:29:55] <SWPadnos> maybe a pause between them also
[20:30:18] <SWPadnos> when you're priming the assembly line, you hit the button to skip the second two stations
[20:30:36] <SWPadnos> next time through, hit it after station 2 has started, but before the station 3 call
[20:30:59] <SWPadnos> (it's harder when you're fluching the queue though - that's left as an exercise for the reader :) )
[20:31:03] <SWPadnos> flushing
[20:31:22] <Lerman> I think that's a pretty decent use for block delete.
[20:32:18] <SWPadnos> in any case - it seems to me that allowing it to change during a run is desirable
[20:33:03] <Lerman> Agreed. But notice that the pause between stations is desirable (if not strictly necessary).
[20:33:55] <SWPadnos> sure. I don't know if there's a way to pause with G-code though
[20:34:08] <SWPadnos> there's optional stop, but that's like M2 AFAIK
[20:36:11] <Lerman> Doesn't M0 do that?
[20:36:23] <SWPadnos> is that pause?
[20:36:32] <SWPadnos> like you hit cycle start to continue?
[20:36:43] <Lerman> Yes.
[20:36:50] <SWPadnos> cool then. I sit corrected
[20:37:03] <Lerman> Or M1 (optional stop).
[20:38:01] <Lerman> I use M0 to pause when I manually change tools. With a MSG to tell the user what is required.
[20:38:05] <micges> good night all
[20:38:12] <SWPadnos> see you micges
[20:38:41] <Lerman> So. M0 (msg, Turn on BLOCK DELETE to skip station 1)
[20:39:41] <Lerman> I like it. (I know, I already said that.)
[20:40:06] <SWPadnos> heh
[20:46:46] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/src/rtapi/rtai_ulapi.c:
[20:46:46] <CIA-40> EMC: fix segfault in halcmd when the usre locked memory value isn't increased
[20:46:46] <CIA-40> EMC: at some point, rtai_malloc seems to have started returning -1 for failure. accomodote both versions of rtai by checking for -1 and NULL.
[20:47:21] <CIA-40> EMC: 03jepler 07v2_2_branch * 10emc2/src/rtapi/rtai_ulapi.c: from TRUNK: fix for halcmd segfault on modern systems when locked memory is not available
[20:47:35] <jepler> how nice that this was obvious the next time I looked at it
[20:48:51] <SWPadnos> cool :)
[21:28:38] <jmkasunich> I think block delete is an abomination whose time is long past
[21:28:59] <jmkasunich> specifically, its time ended when "O100 if " was added
[21:31:01] <SWPadnos> block delete gives the external system (HAL) or the operator the same kind of control
[21:31:32] <SWPadnos> if "if" can check an input pin, then that's still there, of course
[21:31:51] <jmkasunich> M60 can check an external pin
[21:31:59] <jmkasunich> you even get to check one of several pins
[21:32:13] <jmkasunich> so for example the mazak program could have a switch for each of the three stations
[21:53:47] <CIA-40> EMC: 03bigjohnt 07TRUNK * 10emc2/nc_files/probe-hole.ngc: add hole probe
[21:54:34] <CIA-40> EMC: 03bigjohnt 07v2_2_branch * 10emc2/nc_files/probe-hole.ngc: add hole probe
[21:56:45] <CIA-40> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/ (Getting_Started.lyx Master_User.lyx): add hole probe and some updates
[21:56:49] <CIA-40> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/common/ (user_intro.lyx userforeword.lyx): add hole probe and some updates
[21:56:54] <CIA-40> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/examples/gcode.lyx: add hole probe and some updates
[21:58:40] <CIA-40> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/examples/gcode.lyx: add hole probe
[22:12:44] <CIA-40> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/Master_User.lyx: minor edit
[22:22:24] <KimK> KimK is now known as KimK_NE_AFK
[23:57:09] <cradek> it would be nice if you could change block delete while paused (M0)
[23:57:26] <cradek> I do not believe you need to be able to change it at any time
[23:58:04] <cradek> although I would be surprised if old controls without lookahead don't let you do that
[23:59:07] <cradek> I don't *think* BOSS does though, but probably only because it's on a button that's shared with a bunch of other functions