Back
[14:00:21] <skunkworks> join ubuntu
[14:57:50] <jepler> I am looking at adding improved support for "wrapped" ABC axes, so that 'g1 a720; g0 a0' doesn't have to unwind by two revolutions. Is it OK to only support ABC being wrapped, not the "linear" axes?
[15:00:23] <cradek> I think so
[15:00:42] <cradek> and btw: whee!
[15:00:58] <SWPadnos> I would think that ABC only would be fine
[15:01:11] <jepler> don't "whee" yet; it's far from done
[15:01:13] <SWPadnos> though it seems having a "modulo" parameter for any axis could work
[15:01:24] <SWPadnos> damn. I was just about to whee!
[15:01:56] <SWPadnos> oh, and the spindle (or was that done already?)
[15:02:18] <jepler> what about the spindle?
[15:02:45] <SWPadnos> well, remember how it would unwind a couple of revolutions on the mazak (after threading, before toolchange)
[15:04:19] <cradek> that's not an axis or joint though
[15:04:28] <SWPadnos> true
[15:04:40] <SWPadnos> it's kind of treated as one when threading though
[15:04:49] <cradek> it's just a fluke of the pid/index hal configuration
[15:04:55] <SWPadnos> heh
[15:05:05] <SWPadnos> design feature == fluke? :)
[15:05:23] <SWPadnos> oh, or are you saying that a different HAL config wouldn't do that?
[15:05:27] <cradek> right
[15:05:40] <SWPadnos> oh, ok
[15:06:17] <cradek> I think 'I' winds up while the 'position' is high. then we reset the position with index and wait for pid to settle
[15:06:27] <cradek> maybe we need an 'I' reset in pid
[15:06:29] <cradek> or something
[15:06:34] <SWPadnos> oh
[15:06:59] <SWPadnos> I could almost understand that if (a) I had seen teh mazak configs much and (b) I had any coffee
[16:05:38] <jepler> http://pastebin.ca/770771
[16:05:43] <jepler> does this make sense and seem sensible?
[16:12:46] <SWPadnos> sigh. DNS problems persist
[16:13:06] <jepler> poor SWPadnos
[16:13:32] <SWPadnos> hmmm. even though I still have the servers alex and fenn suggested.
[16:13:56] <SWPadnos> I wonder if my router intercepts DNS because it thinks it can do it better
[16:14:33] <SWPadnos> ah, no. it's because Windows is a stupid piece of shit
[16:14:54] <jepler> haven't you learned to run linux on all your machines, and use vmware for windows when absolutely necessary?
[16:15:17] <SWPadnos> yes, I've learned, but it's a "do as I say, not as I do" thing
[16:15:43] <jepler> it's funny, I notice that the vmware habits I picked up while using altera's tools kick in when I'm using the xilinx tools -- e.g., I move the mouse out of the xilinx ise window before I alt-tab to IRC..
[16:15:58] <SWPadnos> heh - funny
[16:16:27] <SWPadnos> do you have any thoughts on which of the environments you like better (other than the emulated vs native thing)?
[16:17:08] <jepler> overall, they seem pretty similar
[16:17:12] <SWPadnos> bummer ;_
[16:17:14] <SWPadnos> :)
[16:17:51] <jepler> altera's quartus had a keyboard shortcut (ctrl-l?) for "build project" which I used quite liberally. ise doesn't seem to -- you have to pick a menu item (which is keyboardable) or click the toolbar.
[16:18:12] <jepler> ise's editor seems less responsive but I was running it remotely over X
[16:18:26] <SWPadnos> yeah - actually, you have to select the correct file in the project tree before you get the menu item
[16:18:32] <jepler> of course, with ise I'll be able to ditch the IDE and use it commandline if I care to, and that's a big deal for me
[16:18:50] <jepler> ise's reports seem a bit better
[16:18:51] <SWPadnos> files that aren't the top file don't have a "generate bitstream" option
[16:19:02] <SWPadnos> yeah, or the built-in tcl shell
[16:19:15] <jepler> quartus also has some kind of tcl scripting, but I never learned any of it
[16:19:24] <SWPadnos> heh -me either
[16:21:42] <CIA-18> 03jepler 07TRUNK * 10emc2/docs/src/gcode/main.lyx: reduce large angular traverses to less than one full revolution
[16:21:40] <CIA-18> 03jepler 07TRUNK * 10emc2/src/emc/task/emccanon.cc: reduce large angular traverses to less than one full revolution
[16:22:16] <jepler> let me know how to break this ^^
[16:22:30] <SWPadnos> hmmmm
[16:23:00] <SWPadnos> I haven't seen the diff, but does that still allow something like G1 X10 A3600 ?
[16:26:12] <cradek> I'm scared by the number of lines in that diff
[16:26:18] <cradek> but, I'm excited about this feature
[16:30:08] <jepler> SWPadnos: yes, if you start at A0 it should go 10 revolutions.
[16:30:14] <SWPadnos> ok
[16:30:22] <cradek> only G0 cause the wrap behavior right?
[16:30:58] <SWPadnos> hmmm. I wonder if this problem can be solved without adding a "reset" G-code
[16:31:28] <cradek> which problem?
[16:31:46] <SWPadnos> the problem I'm thinking about is what I think that recent email was asking for
[16:32:09] <SWPadnos> you do a corkscrew using an XA move, but don't want to have to unwind the entire A rotation at the end
[16:32:16] <jepler> that's exactly the situation that this is supposed to fix
[16:32:19] <SWPadnos> rigth
[16:32:21] <SWPadnos> right
[16:32:38] <cradek> * cradek squints at SWPadnos
[16:32:53] <SWPadnos> but the corkscrew was a series of moves in a loop, which I thought kept on adding to A
[16:33:03] <jepler> If a G0 motion only moves rotational axes, and the target position for those axes is in the range from -360 to 360 degrees, then the motion is modified so that each rotational axis actually rotates less than one full revolution. Example:
[16:33:07] <jepler> N1 G0 X1 A[20*360]
[16:33:10] <jepler> N2 G0 A0
[16:33:12] <jepler> After line N1, the position of the A axis is 7200 degrees. 7200 degrees is the same as zero degrees on a rotational axis, so the rapid linear motion specified on line N2 actually produces no motion.
[16:33:44] <jepler> it doesn't matter whether it was 1 or 20 or 2000 moves to get to 7200 degrees .. or if you get to 7000 degrees (not a full circle)
[16:33:47] <cradek> jepler: -360?
[16:34:53] <SWPadnos> ok, for rapids that makes sense all the time
[16:36:05] <SWPadnos> I didn't catch that this was for rapids only
[17:13:58] <CIA-18> 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: AXIS should start even if no limits are specified for the ABC axes
[17:23:20] <CIA-18> 03jepler 07TRUNK * 10emc2/src/emc/ini/iniaxis.cc: make axis defaults large so that there is no need to specify min/max limit for rotational axes
[17:23:39] <CIA-18> 03jepler 07TRUNK * 10emc2/configs/sim/axis_9axis.ini: remove unneeded min/max limits for rotational axes
[17:28:50] <fenn> er, but what if you _do_ need to unwind the rotary axis?
[17:29:50] <fenn> G0 A[-20*360] ?
[17:30:07] <fenn> or would that go to -7200>
[17:32:50] <fenn> will periodic eventually be an axis type in the .ini file?
[17:42:00] <SWPadnos> it should probably be an ini file setting
[17:42:16] <SWPadnos> not necessarily a type, but a modifier [AXIS_n]PERIODIC=true
[17:47:20] <jepler> If you are at A7200 and want to move by -20 revolutions, you'd write G1 A0
[17:48:03] <fenn> that's confusing
[17:48:41] <cradek> I sort of agree, but I think any solution to this problem is going to be a bit odd. what do you think is a better solution?
[17:48:58] <fenn> a new g-code
[17:49:11] <cradek> that does what?
[17:49:15] <SWPadnos> heh - I think this is why I said there isn't a perfect solution (without adding a G-code)
[17:49:26] <fenn> resets the axis to 0 degrees
[17:49:36] <fenn> i think an ini file setting would be fine
[17:49:38] <cradek> fenn: like G92 A0?
[17:49:41] <fenn> right
[17:49:40] <SWPadnos> or resets the axis to <whatever> mod <period>
[17:50:13] <cradek> I hate to be the one who says it, but I wonder what other controls do
[17:50:17] <SWPadnos> heh
[17:50:26] <SWPadnos> you have a control ... ;)
[17:50:26] <cradek> G92 isn't the answer
[17:50:52] <cradek> SWPadnos: no rotary support
[17:50:58] <fenn> g92 will eventually overflow right?
[17:51:00] <SWPadnos> right
[17:51:12] <SWPadnos> right to cradek, not to overflow
[17:51:22] <SWPadnos> I think that's a double, so it should take a long time
[17:52:01] <jepler> the first problem you run into is that motor-pos-cmd gets big enough that it loses precision (it's a hal float, 32 bits with 24-bit mantissa)
[17:52:28] <SWPadnos> is the G92 offsetting done in the HAL code or in the TP code?
[17:52:47] <cradek> g92 is purely interpreter
[17:52:47] <SWPadnos> I thought it was a double internally, then converted to a float when stored to the HAL pin
[17:52:54] <jepler> offsets are all computed before the segments reach the real-time code
[17:53:09] <jepler> real-time code converts to joints and adds motor offsets
[17:53:11] <jepler> (roughly)
[17:53:17] <SWPadnos> ok, so there should be no loss of precision if the result of the offsetting is within +/- a few thousand units
[17:54:09] <jepler> if your program repeatedly does G1 A7200 / G0 A0, the output (motor) position will continue growing
[17:54:39] <SWPadnos> oh. that seems like a bad thing to me
[17:55:45] <jepler> it's unavoidable .. you continue moving in "positive revolutions" so the motor position keeps getting larger
[17:56:00] <SWPadnos> hmmm
[17:56:15] <SWPadnos> ok. this bears more thought
[17:56:19] <SWPadnos> at least for me ;)
[17:57:41] <fenn> i suppose the user could just setp motor-pos-fb and motor-pos-cmd to 0
[17:57:52] <jepler> (same if you do it by a new gcode, G92 A0, or by re-homing the axis)
[17:58:18] <jepler> (that is, homing with no home switch so that the current motor position is set to 0 degrees)
[17:58:26] <SWPadnos> right. we'd need a synchronous PID/encoder/TP reset
[17:58:56] <fenn> does homing already pretty much do what you want?
[17:59:42] <fenn> what somebody wants..
[18:00:06] <fenn> * fenn looks around squirrel-eyed and darts off into the bushes
[18:01:38] <cradek> I think someone told me that for a wrapped axis, his control (?) treats G90/G91 differently
[18:01:50] <cradek> you use g91 if you want to do 10 turns, for instance
[18:01:59] <cradek> you use g90 if you want 'indexing' behavior
[18:02:42] <cradek> and at the completion of every move, the axis position is reset to %360
[18:10:17] <alex_joni> jepler: I wonder what that does to a non-trivkin machine
[18:10:45] <SWPadnos> shouldn't this be in world coordinates, before he kins transform?
[18:10:53] <SWPadnos> * SWPadnos didn't look too closely at where he code is
[18:10:55] <SWPadnos> the
[18:11:10] <alex_joni> SWPadnos: yes, but going from 720 to 0 in world coords.. could mean something bad happens after kins
[18:11:27] <alex_joni> I'm just thinking aloud here..
[18:12:26] <SWPadnos> for a rotary axis, it shouldn't matter. I guess since there is still the option of using G1 instead of G0, you can G1A0 F10000000 to do it at the same speed as a G0
[18:13:41] <alex_joni> SWPadnos: think about a puma robot
[18:13:52] <alex_joni> A0 means a certain joint placement
[18:14:02] <alex_joni> A360 could mean something completely different
[18:14:03] <SWPadnos> sure
[18:14:16] <SWPadnos> also, you may have to unwind a joint, if there are non sliprings
[18:14:19] <SWPadnos> no, not non
[18:14:30] <alex_joni> didn't see sliprings :)
[18:15:02] <SWPadnos> so you'd use a G1 move to unwind the joint, instead of a G0 which would magically set it to (pos mod N)
[18:17:01] <alex_joni> all I'm saying is that G0 might stop beeing usefull for a nontrivkins
[18:17:53] <SWPadnos> oh, could be ;)
[18:18:11] <alex_joni> which is quite a change without an option :)
[18:41:19] <alex_joni> this is a bit odd: after changing from install to rip, and only 'make', emc2 -> sim/axis runs, but latency-test doesn't
[18:41:32] <alex_joni> halrun tries to load the wrong modules (from /usr..)
[18:47:17] <alex_joni> wow
[18:47:24] <alex_joni> SWPadnos: still around?
[18:47:50] <alex_joni> I'm getting 22666 and 24539 max jitter
[18:48:21] <alex_joni> not very moving numbers, unless I tell you it's inside a VM
[18:53:53] <alex_joni> http://imagebin.org/11692
[18:54:36] <alex_joni> oh, and the VMware server is running on a laptop :)
[19:09:46] <alex_joni> cradek: I need some help :)
[19:10:35] <cradek> uh-oh
[19:10:47] <alex_joni> I bet it's something trivial
[19:10:56] <alex_joni> can't wrap my head around it though.. was hoping a fresh set of eyes helps
[19:10:57] <cradek> I'll help if you fix pause/step (again)
[19:11:04] <alex_joni> in trunk?
[19:11:13] <cradek> trunk/2.2
[19:11:16] <alex_joni> ok.. I will
[19:11:21] <cradek> yayyyy
[19:11:28] <alex_joni> is it broken again?
[19:11:30] <cradek> ok I'm ready
[19:11:32] <cradek> yes actually
[19:11:37] <alex_joni> interp_convert.cc
[19:11:43] <alex_joni> line 2130ish
[19:11:48] <cradek> oh I didn't expect an emc question :-)
[19:11:56] <alex_joni> M66
[19:12:14] <alex_joni> I can't figure out why M66P0 works, and M66E0 doesn't
[19:12:36] <alex_joni> or maybe I do.. trying something
[19:13:37] <alex_joni> ok.. forgot to test for a flag
[19:13:52] <cradek> the test (missing or negative) looks wrong
[19:14:00] <cradek> lien 2127
[19:14:13] <alex_joni> 2137 ?
[19:14:40] <alex_joni> I have a checkout from this morning
[19:14:46] <alex_joni> before jeff's changes..
[19:15:05] <cradek> me too, I think
[19:15:07] <alex_joni> the L-word not 0, and timeout <=0 part?
[19:15:25] <cradek> // missing P or E (or invalid = negative)
[19:15:24] <cradek> CHK(((round_to_int(block->p_number) < 0) && (round_to_int(block->e_number) < 0)),
[19:15:29] <cradek> this test is not what the comment says
[19:15:38] <cradek> not sure which is right
[19:16:03] <alex_joni> I agree the test is wrong
[19:16:17] <alex_joni> it should be p_flag && p_number >=0
[19:16:31] <alex_joni> or e_flag && e_number
[19:16:37] <cradek> right
[19:16:37] <alex_joni> (or something along those lines)
[19:16:42] <alex_joni> I'll fix it
[19:17:58] <alex_joni> there's another copy/paste error further down
[19:18:34] <cradek> // E-word specified (analog input) and wait type not immediate
[19:18:34] <cradek> CHK(((block->e_flag == ON) && (round_to_int(block->l_number) != 0)),
[19:19:00] <cradek> I think this is wrong too, you should allow l_flag=OFF (I'm not sure l_number is guaranteed to be 0)
[19:19:15] <alex_joni> I think l_number by default is -1
[19:19:20] <cradek> I think you should not trust the number without checking the flag
[19:19:23] <alex_joni> but I tested for l_flag in my version
[19:19:27] <cradek> ok
[19:19:27] <alex_joni> right
[19:20:04] <alex_joni> yay
[19:20:15] <alex_joni> setp motion.analog-in-00 0.3
[19:20:20] <alex_joni> then M66E0
[19:20:26] <alex_joni> then G0x#5399
[19:20:29] <alex_joni> moves X to 0.3
[19:20:33] <cradek> neat
[19:20:53] <alex_joni> I'll fix the *_flag tests
[19:21:02] <alex_joni> then merge the latest cvs, and commit :)
[19:22:13] <alex_joni> cradek: seen that imagebin earlier?
[19:22:18] <cradek> no
[19:22:26] <alex_joni> http://imagebin.org/11692
[19:23:26] <skunkworks> are you running linux inside a windows vm?
[19:23:34] <alex_joni> skunkworks: yeah
[19:23:38] <skunkworks> yiked
[19:23:41] <skunkworks> or there abouts.
[19:23:50] <alex_joni> but I thought cradek would notice the kernel version :D
[19:24:28] <cradek> oh is that one of the crazy ones I built?
[19:24:33] <alex_joni> yeah
[19:24:46] <cradek> I think that one has a keyboard problem
[19:24:50] <alex_joni> runs nicely inside the VM here
[19:24:55] <alex_joni> no keyb issues
[19:25:32] <alex_joni> I love that I installed that VM on a single CPU machine
[19:25:50] <alex_joni> then I changed the machine, and simply copied the vmdk over
[19:28:04] <cradek> neat
[19:28:38] <alex_joni> cradek: care to tell me what to look after with step & resume?
[19:31:14] <cradek> run AXIS, start the splash screen running, pause, step, step, try to resume
[19:31:35] <cradek> on the second step, the pause button incorrectly pops out
[19:35:54] <cradek> crap, it's not doing it now
[19:37:35] <alex_joni> * alex_joni chuckles
[19:37:45] <alex_joni> I get that a LOT
[19:38:41] <alex_joni> I'll still look at it
[19:39:17] <cradek> ohhh
[19:39:22] <cradek> I gave the wrong instructions
[19:39:29] <alex_joni> oh
[19:39:28] <cradek> instead of running, step
[19:39:52] <cradek> you can step through the program but you can't 'resume' without first going into pause mode
[19:40:25] <cradek> in emctop it says paused=0 but it should be 1
[19:42:07] <alex_joni> yeah, I know that..
[19:42:14] <alex_joni> I think it turned out to be a feature
[19:42:34] <alex_joni> I remember that if that works, something else breaks lots worse
[19:42:50] <cradek> it looks like it would work perfectly if step from start would turn on 'paused'
[19:46:22] <CIA-18> 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: hook up charge pump.out
[19:50:03] <CIA-18> 03jepler 07v2_2_branch * 10emc2/src/ (configure.in configure): fix startup of halshow on RIP systems
[19:50:43] <CIA-18> 03jepler 07TRUNK * 10emc2/src/ (configure configure.in): fix startup of halshow on RIP systems
[19:55:48] <CIA-18> 03jepler 07TRUNK * 10emc2/src/hal/utils/halcmd_commands.c: fix 'watch' of signals in halshow
[19:56:10] <CIA-18> 03jepler 07v2_2_branch * 10emc2/src/hal/utils/halcmd_commands.c: merge from TRUNK: fix 'watch' of signals in halshow
[19:56:49] <CIA-18> 03jepler 07v2_2_branch * 10emc2/debian/changelog: note bugs fixed
[20:01:07] <CIA-18> 03jepler 07v2_2_branch * 10emc2/debian/changelog: another bug or two fixed
[20:05:58] <CIA-18> 03alex_joni 07TRUNK * 10emc2/src/libnml/posemath/_posemath.c: clarify a comment
[20:08:13] <CIA-18> 03alex_joni 07TRUNK * 10emc2/src/emc/nml_intf/ (emc_nml.hh emcglb.h):
[20:08:13] <CIA-18> * analog inputs for the motion controller
[20:08:13] <CIA-18> - can be queried from g-code using M66 Exx (where xx is the input number)
[20:08:14] <CIA-18> 03alex_joni 07TRUNK * 10emc2/src/emc/motion/ (control.c emcmotcfg.h mot_priv.h motion.c motion.h):
[20:08:14] <CIA-18> * analog inputs for the motion controller
[20:08:14] <CIA-18> - can be queried from g-code using M66 Exx (where xx is the input number)
[20:08:20] <CIA-18> 03alex_joni 07TRUNK * 10emc2/src/emc/rs274ngc/interp_convert.cc:
[20:08:22] <CIA-18> * analog inputs for the motion controller
[20:08:22] <CIA-18> - can be queried from g-code using M66 Exx (where xx is the input number)
[20:08:24] <CIA-18> 03alex_joni 07TRUNK * 10emc2/src/emc/task/ (emccanon.cc taskintf.cc):
[20:08:26] <CIA-18> * analog inputs for the motion controller
[20:08:30] <CIA-18> - can be queried from g-code using M66 Exx (where xx is the input number)
[20:11:09] <CIA-18> 03alex_joni 07TRUNK * 10emc2/debian/changelog: mention analog input reading
[20:18:16] <CIA-18> 03jepler 07v2_2_branch * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: fix charge-pump pin
[20:21:54] <alex_joni> cradek: oh-oh
[20:22:15] <alex_joni> I tried it with tkemc, and I'm under the impression it works as it should
[20:22:41] <alex_joni> (tried load program, step, step, resume, pause, step, resume, pause, step, step, resume)
[20:22:45] <alex_joni> it all worked as it should
[20:22:53] <alex_joni> trying axis now
[20:23:11] <cradek> I think axis expects status.whatever.paused to be right, tkemc doesn't
[20:23:36] <SWPadnos> how about load step step stop step step pause step step stop start step step pause stop step step ?
[20:23:45] <alex_joni> SWPadnos: that works too
[20:23:48] <SWPadnos> heh
[20:23:52] <alex_joni> but on each stop you start again
[20:24:12] <alex_joni> and step pause only works if you're really quick
[20:24:21] <SWPadnos> I thought the idea was for step to start but not continue if stopped when you step
[20:24:40] <alex_joni> what?
[20:24:42] <SWPadnos> heh
[20:25:05] <SWPadnos> ok when stopped, you hit step. that should "start", but only execute one line
[20:25:19] <alex_joni> yes
[20:25:21] <cradek> that should put you in the 'running and paused' state
[20:25:33] <SWPadnos> ok, so you shouldn't need to explicitly start again after each stop
[20:25:36] <SWPadnos> rigtj
[20:25:37] <SWPadnos> rigth
[20:25:53] <CIA-18> 03jepler 07v2_2_branch * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: fix external estop input
[20:25:55] <SWPadnos> I may have misunderstood your statement "but on each stop you start again"
[20:26:07] <alex_joni> restart the program
[20:26:11] <CIA-18> 03jepler 07v2_2_branch * 10emc2/debian/changelog: note new fix
[20:26:58] <SWPadnos> oh, on each stop, the executing line goes back to the start of the progeam. got it
[20:27:03] <SWPadnos> program
[20:27:09] <CIA-18> 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: fix externalstop input
[20:28:20] <alex_joni> cradek: with AXIS I can step, step, step, (for resume I need to push pause twice..), other than that it works ok
[20:29:57] <cradek> I know, that's the bug
[20:30:05] <cradek> if you step,step,step it should be in the paused state
[20:30:15] <alex_joni> I'm not sure what paused is
[20:30:26] <alex_joni> or how it gets extracted from stat
[20:30:32] <cradek> all I know it's a thing in the stat buffer
[20:30:35] <cradek> brb
[20:43:22] <alex_joni> jepler: in emctop.py, I can't seem to identify the "paused" field
[20:50:13] <alex_joni> n/m, found it in stat
[20:50:41] <alex_joni> cradek: that refers to motion paused or not.. only indirectly related to program pause
[20:53:05] <SWPadnos> hmmm. when you hit pause in the GUI, does motion pause immediately or after the current move completes?
[20:53:21] <SWPadnos> or does it (even worse) finish the motion queue?
[20:54:20] <cradek> immediately
[20:54:22] <alex_joni> it pauses quickly :)
[20:54:29] <SWPadnos> heh - ok, non-RT immediately ;)
[20:54:33] <alex_joni> decelerates and pauses
[20:54:35] <cradek> and if you then step, it goes to the end of that motion
[20:54:40] <alex_joni> yup
[20:54:51] <SWPadnos> ok, cool - that's what I'd hope for
[20:55:02] <cradek> yeah I think it's what you want
[20:55:07] <alex_joni> cradek: I was able to get emctop.py to show paused=1, but the button is still popped out
[20:55:18] <cradek> oh, hmmmmm
[20:56:15] <jepler> state {$task_state == $STATE_ON && $interp_state != $INTERP_IDLE} \
[20:56:15] <jepler> .toolbar.program_pause
[20:56:21] <jepler> relief {$interp_state == $INTERP_PAUSED} \
[20:56:22] <jepler> .toolbar.program_pause
[20:56:35] <cradek> yeah I was just finding that
[20:56:59] <alex_joni> so only for interp_paused it is pushed?
[20:57:10] <cradek> yes
[20:57:19] <cradek> sorry I misguided you
[20:57:32] <alex_joni> I'm not sure INTERP_PAUSED is always correct after stepping
[21:00:03] <jepler> axis can be changed to use whatever variable is correct..
[21:01:29] <alex_joni> axis is too right :P
[21:12:58] <alex_joni> jepler: when I resize emctop.py too narrow, it eats away the vertical scrollbar..
[21:21:34] <alex_joni> ok, I think I got something
[21:21:48] <alex_joni> jepler: can you verify my sanity for a couple of minutes?
[21:22:15] <jepler> alex_joni: I'll try
[21:22:32] <alex_joni> ok.. I did this.. I ran a program, and immediately hit "p"
[21:22:53] <alex_joni> interp_state was paused, as interpreting the file was paused
[21:23:02] <alex_joni> AXIS correctly displayed the pause button as pressed
[21:23:09] <alex_joni> next I stepped through the file
[21:23:36] <alex_joni> I kept stepping until I stepped through all the lines the interp had already read/interpreted
[21:23:50] <alex_joni> when I reached the end of that, the interp_state changed to "waiting"
[21:23:57] <alex_joni> and AXIS depressed the pause button
[21:24:12] <jepler> you mean it un-pressed, right?
[21:24:16] <jepler> became flat
[21:24:17] <alex_joni> right
[21:24:21] <alex_joni> sorry :)
[21:24:27] <jepler> depress is like inflammable
[21:24:35] <alex_joni> or like my sanity atm
[21:24:51] <jepler> OK so what EMC_STAT field should I look at instead?
[21:25:08] <jepler> from what I can tell your interpretation is correct
[21:25:10] <alex_joni> still interp_status
[21:25:30] <alex_joni> but I think both interp_paused and interp_waiting should push the pause button down
[21:27:21] <alex_joni> hrmm.. no
[21:27:49] <alex_joni> interp_waiting can also happen when the interp reached the end of the file..
[21:28:06] <jepler> yeah .. I notice that to permit the use of the unpause key, I check
[21:28:06] <jepler> if s.task_mode != emc.MODE_AUTO or s.interp_state not in (emc.INTERP_READING, emc.INTERP_WAITING):
[21:28:09] <jepler> return
[21:28:13] <alex_joni> jepler: I think we need a new status field, which correctly tells us if we're stepping
[21:28:43] <alex_joni> I'll add one..
[21:28:48] <alex_joni> maybe I get this right
[21:29:05] <cradek> maybe this will also fix the problem where you can't step over a G4?
[21:29:13] <alex_joni> you can't?
[21:29:25] <alex_joni> last time I tried you could
[21:30:30] <alex_joni> I remember it used to hang, but I fixed that
[21:30:43] <jepler> looks like tp->pausing is not passed back out of motion to userspace
[21:31:05] <alex_joni> tp->pausing is not always correct
[21:31:10] <alex_joni> like for G4
[21:31:12] <alex_joni> or other IO
[21:39:48] <alex_joni> jepler: I added a stat status field
[21:39:57] <alex_joni> I need to change emcmodule.cc now?
[21:51:17] <alex_joni> what does relief mean?
[21:52:12] <jepler> alex_joni: "relief" is the shape of the button's border
[21:52:22] <jepler> the three values usually used are "flat", "sunken", "raised"
[21:52:26] <alex_joni> ok..
[21:52:45] <alex_joni> you have some $task_state in axis.tcl
[21:52:53] <alex_joni> where do those come from?
[21:52:59] <jepler> from magic
[21:53:08] <alex_joni> * alex_joni figured that much
[21:53:49] <alex_joni> oh, and some are $::task_state
[21:53:54] <alex_joni> * alex_joni is a bit confused..
[21:57:55] <cradek> alex_joni: that comes from vupdate(vars.task_state, self.stat.task_state)
[21:58:20] <alex_joni> huh.. where is that?
[21:58:25] <cradek> in axis.py
[21:58:38] <alex_joni> oh
[21:58:42] <cradek> I think it somehow magically hooks the py and tcl variables together
[21:59:09] <alex_joni> my head spins :D
[21:59:29] <cradek> yeah.
[21:59:45] <jepler> but you have to add an entry to 'vars = Variables(...)' way above, too
[21:59:55] <jepler> and you have to add a 'trace variable' and maybe a dummy 'set' in axis.tcl, too
[22:07:17] <cradek> yay
[22:07:28] <alex_joni> only one slight bug still left in axis
[22:07:45] <alex_joni> after step, the pause is pressed, but you need to click it twice for it to unpress
[22:08:08] <alex_joni> I probably didn't update some internal state of the pauseresume stuff
[22:13:58] <CIA-18> 03alex_joni 07TRUNK * 10emc2/TODO: note some things already done
[22:14:01] <alex_joni> cradek: can you test?
[22:14:36] <cradek> yes
[22:14:51] <alex_joni> diffing another time to make sure I don't include garbage :D
[22:22:15] <jepler> there is one (estop_latch) but I dunno if it does "the right thing"...
[22:23:55] <alex_joni> here it goes
[22:24:16] <CIA-18> 03alex_joni 07TRUNK * 10emc2/src/emc/usr_intf/axis/extensions/emcmodule.cc:
[22:24:16] <CIA-18> * add a new task status variable
[22:24:16] <CIA-18> this one keeps track of the task paused state, and GUIs should update the state
[22:24:16] <CIA-18> of the pause button accordingly
[22:24:16] <CIA-18> * update axis to use the new task_paused variable
[22:24:17] <CIA-18> 03alex_joni 07TRUNK * 10emc2/src/emc/nml_intf/emc_nml.hh:
[22:24:19] <CIA-18> * add a new task status variable
[22:24:23] <CIA-18> this one keeps track of the task paused state, and GUIs should update the state
[22:24:25] <CIA-18> of the pause button accordingly
[22:24:27] <CIA-18> * update axis to use the new task_paused variable
[22:24:29] <CIA-18> 03alex_joni 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py:
[22:24:31] <CIA-18> * add a new task status variable
[22:24:33] <CIA-18> this one keeps track of the task paused state, and GUIs should update the state
[22:24:35] <CIA-18> of the pause button accordingly
[22:24:37] <CIA-18> * update axis to use the new task_paused variable
[22:24:39] <CIA-18> 03alex_joni 07TRUNK * 10emc2/share/axis/tcl/axis.tcl:
[22:24:41] <CIA-18> * add a new task status variable
[22:24:43] <CIA-18> this one keeps track of the task paused state, and GUIs should update the state
[22:24:45] <CIA-18> of the pause button accordingly
[22:24:47] <CIA-18> * update axis to use the new task_paused variable
[22:24:49] <CIA-18> 03alex_joni 07TRUNK * 10emc2/src/emc/task/ (emctask.cc emctaskmain.cc):
[22:25:01] <CIA-18> * add a new task status variable
[22:25:01] <CIA-18> this one keeps track of the task paused state, and GUIs should update the state
[22:25:01] <CIA-18> of the pause button accordingly
[22:25:01] <CIA-18> * update axis to use the new task_paused variable
[22:28:08] <jepler> CIA-18: just about done, I hope?
[22:28:13] <alex_joni> yeah
[22:28:14] <cradek> alex_joni: it's not quite right, but it might just be AXIS stuff
[22:28:27] <cradek> if I press step while running, the pause button sticks in, but it doesn't pause/step
[22:28:27] <alex_joni> cradek: only the 2 x pause I hope?
[22:28:37] <alex_joni> oh
[22:28:40] <alex_joni> it shouldn't do that :D
[22:28:41] <cradek> right, and the 2xpause for resume
[22:29:04] <alex_joni> step while running should be ignored
[22:32:24] <CIA-18> 03jepler 07TRUNK * 10emc2/src/hal/utils/halcmd_commands.c: allow 'signal', 'parameter', 'function' to be spelled out in show, list and save
[22:36:26] <CIA-18> 03alex_joni 07TRUNK * 10emc2/src/emc/task/emctaskmain.cc: fix pause gets pressed in AXIS if user hits step while program running
[22:37:20] <SWPadnos> nooooooooooooooooooooooooooooooo!
[22:37:33] <SWPadnos> alex - please stop now! :)
[22:37:54] <CIA-18> 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: prefer estop input to enable charge-pump (jlmjvm)
[22:37:55] <alex_joni> SWPadnos: what? you always said you had too much free time
[22:37:57] <CIA-18> 03jepler 07v2_2_branch * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: merge from trunk: prefer estop input to enable charge-pump
[22:38:02] <SWPadnos> not that much ;)
[22:38:39] <SWPadnos> hmmm. I don't think that's the better way to handle a charge pump
[22:38:44] <alex_joni> cradek: at least that step during running should be fixed now
[22:39:16] <SWPadnos> the charge pump should tell the external E-Stop hardware that the software is not locked up
[22:39:34] <SWPadnos> that should happen any time motion thinks it's OK to move
[22:39:38] <alex_joni> jepler: smooth :P
[22:47:01] <alex_joni> jepler: can you look at the problem that remains?
[22:47:14] <alex_joni> it's somewhere in axis.. but I can't seem to put my finger on it
[22:47:54] <jepler> alex_joni: I'll look for it, but not right now
[22:48:18] <alex_joni> ok, no hurry
[22:48:39] <alex_joni> the idea is that I managed to make the pause button pressed
[22:49:16] <alex_joni> but when I click it I can see it still sends EMC_TASK_PLAN_PAUSE, not RESUME as it should
[22:50:22] <alex_joni> I think the issue is in axis.py: task_pauseresume(*event), line: 2506
[23:13:45] <CIA-18> 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py:
[23:13:45] <CIA-18> use names instead of numbers for pin functions. this makes it possible to add
[23:13:45] <CIA-18> new pin functions without breaking old configuration files. migration from the
[23:13:45] <CIA-18> old numbered system is preserved, though this breaks backwards compatability
[23:13:45] <CIA-18> (e.g., from 2.3.0 to 2.2.2) of the configuration files
[23:40:52] <cradek> case EMC_TRAJ_RESUME_TYPE:
[23:40:55] <cradek> + emcStatus->task.task_paused = 1;
[23:40:58] <cradek> this seems wrong...?