Back
[15:18:14] <Skullworks-PGA1> Skullworks-PGA1 is now known as Skullworks-PGAB
[18:11:27] <jmkasunich> cradek jepler
[18:11:31] <jmkasunich> waiting for s.axes != 0 -- Had to poll again...
[18:11:31] <jmkasunich> waiting for s.axes != 0 -- Had to poll again...
[18:11:31] <jmkasunich> waiting for s.axes != 0 -- Had to poll again...
[18:11:31] <jmkasunich> Traceback (most recent call last):
[18:11:31] <jmkasunich> File "/home/jmkasunich/emcdev/emc2head/bin/axis", line 3180, in ?
[18:11:31] <jmkasunich> time.sleep(.01)
[18:11:32] <jmkasunich> KeyboardInterrupt
[18:11:34] <jmkasunich> Shutting down and cleaning up EMC2...
[18:11:36] <jmkasunich> Cleanup done
[18:11:43] <jmkasunich> fresh cvs update, build, run sim/axis
[18:11:55] <jepler> there's (hopefully) a real error in there somewhere, obscured by the repeated message
[18:11:57] <jmkasunich> got a bazillion of those "waiting" messages on startup, had to control C out
[18:12:22] <jmkasunich> I can try again and stop it right away
[18:12:35] <jepler> find the print in src/emc/usr_intf/axis/scripts/axis.py and remove it
[18:12:49] <jepler> or let me check in a change to remove it
[18:12:54] <jmkasunich> wait
[18:13:00] <jmkasunich> when I tried again, it worked fine
[18:13:04] <jepler> :(
[18:13:11] <jepler> hmph
[18:13:15] <jmkasunich> must be some kind of one time thing, var file entry or something?
[18:13:28] <jepler> I don't even have a guess
[18:14:14] <jmkasunich> its working fine now, whatever it was
[18:14:56] <jmkasunich> would you expect to see these messages during startup:
[18:15:08] <jmkasunich> emcTrajSetAxes succeeding: axes=3 axismask=7
[18:15:08] <jmkasunich> forget .top.tabs.fmanual.axes.axisa 7 3 8
[18:15:08] <jmkasunich> forget .top.tabs.fmanual.axes.axisb 7 4 16
[18:15:08] <jmkasunich> forget .top.tabs.fmanual.axes.axisc 7 5 32
[18:15:08] <jmkasunich> forget .top.tabs.fmanual.axes.axisu 7 6 64
[18:15:09] <jmkasunich> forget .top.tabs.fmanual.axes.axisv 7 7 128
[18:15:13] <jmkasunich> forget .top.tabs.fmanual.axes.axisw 7 8 256
[18:15:15] <jepler> that's more spam I wrote and left in
[18:15:32] <jmkasunich> ok, I'll let you decide if it should stay or not
[18:19:01] <jmkasunich> petev's bug is confirmed, now to fix it
[18:20:00] <jmkasunich> yuck, its not just feedhold - feed override has the same effect
[18:20:34] <jmkasunich> jepler: I seem something else funny in sim/axis
[18:20:40] <jmkasunich> incremental jog units
[18:20:49] <jmkasunich> isn't sim/axis an inch machine?
[18:21:01] <jepler> yes, the inifile units should be inches
[18:21:26] <jmkasunich> the jog increments are weird
[18:22:10] <petev> jepler, is the "Touch Off" button on the manual tab supposed to touch off the current work coordinate or always G54?
[18:22:21] <jmkasunich> 1mm, 0.01in, .1mm, 1mil. .1mil, and 1/8000 in
[18:22:22] <jepler> petev: it always does G54
[18:22:26] <petev> ok
[18:22:32] <jepler> jmkasunich: you mean it seems like an odd set of choices?
[18:22:38] <jmkasunich> yes
[18:22:44] <jmkasunich> I expected 1in, 0.1in, 0.01in, etc
[18:22:51] <jepler> jmkasunich: those can be specified in the inifile -- I went a bit wild to test all the possibilities
[18:22:57] <jmkasunich> ok
[18:23:05] <jmkasunich> I'll fix up and commit a new inifile for that config
[18:25:27] <jepler> about the interpreter errors NCE_REQUIRED_PARAMETER_MISSING NCE_COORDINATE_SYSTEM_INDEX_PARAMETER_5220_OUT_OF_RANGE -- I would prefer that it be possible to start with an empty .var file. 5220 is set to 1 if not specified. Other variables are set to 0 if not specified. When written, the varfile will have those "required" items added to the var file if they weren't specified before
[18:25:44] <jepler> among other things, this means you don't have to manually copy a new var file when you upgrade to a version with 9 axes
[18:26:02] <jepler> if you somehow manage to put 0 in 5220, emc will still start
[18:26:03] <jepler> etc
[18:26:54] <jepler> I don't see how these errors really improve anything for the user
[18:26:55] <jmkasunich> petev: seems the jogwheel/feedhold problem isn't unique to jogwheels
[18:27:33] <jmkasunich> incremental jogs do the same thing
[18:27:50] <jmkasunich> both incremental jogs and wheel jogs change the target position of the axis
[18:28:23] <petev> probably not, but that's where I noticed it
[18:28:26] <jmkasunich> if feedhold is on, or feed override is zero, that stops the machine but doesn't prevent it from going to the target position once feedhold turns off or feed override becomes non-zero
[18:28:36] <petev> I think the whole taks level and notion of machine mode needs looking at
[18:28:44] <jepler> bbl
[18:29:00] <jmkasunich> feedhold and feed override are not task level items
[18:29:04] <jmkasunich> they are realtime items
[18:29:04] <petev> I think changes in mode need to be more clearly defined and what effect they have
[18:29:16] <petev> true, but I'm referring to auto/manual/mdi
[18:29:30] <jmkasunich> then we are having two completely different conversations
[18:29:32] <petev> seems like task leaves a lot of crap around when modes are changed
[18:29:49] <petev> I'm not sure motion can be blamed for this problem
[18:29:53] <jmkasunich> the bug you reported has nothing whatsoever to do with mode changes
[18:30:17] <petev> I think maybe it's tasks job to clean things up and not allow certain operations based on mode
[18:30:21] <jmkasunich> I started the machine in manual and haven't changed the mode
[18:30:29] <jmkasunich> jogging is certainly permissable in manual mode
[18:30:34] <jmkasunich> this is NOT a mode issue!
[18:30:45] <jmkasunich> it is a feedhold and feed override issue
[18:31:18] <jmkasunich> both feedhold and feed override work by clamping velocity in the motion controller
[18:31:27] <petev> what do you think the correct behavior is if a program is stopped with feed hold, then the mode is changed to manual?
[18:31:53] <jmkasunich> feedhold is feedhold, just like feed override is feed override - they both apply to all modes
[18:33:28] <petev> hmm, it might be possible to do that if task cleans up properly and motion ignores jogs, etc. during hold
[18:33:48] <petev> but I'm not convinced yet that everything cleans up properly when switching from auto to manual
[18:33:52] <jmkasunich> I don't understand why you keep bringing task into the picture
[18:34:15] <jmkasunich> if there are improper cleanup issues after mode change, that is a completely separate issue
[18:34:18] <petev> I have seen strange stuff where some unexpected motion occurs in manual when the hold is released
[18:34:29] <jmkasunich> I can replicate your reported bug without EVER going into auto mode
[18:34:58] <petev> sure, I'm just trying to get the big picture and how you think it should work
[18:35:17] <petev> many controls will cancel all motion, hold, etc. when you change modes
[18:35:43] <petev> some let you go to manual and make changes, then come back and continue with auto
[18:35:57] <jmkasunich> "many controls" - you are talking policy now, and I am NOT going there
[18:36:11] <jmkasunich> and I REFUSE to discuss mode changes
[18:36:20] <petev> well we need to at least know what the policy is for feed hold and overried, don't we?
[18:36:22] <jmkasunich> how many times to I have to say this bug is not a mode change bug!
[18:36:36] <jmkasunich> feedhold and feed override are related
[18:37:05] <petev> why are you getting so upset? I just want to understand what the desired policy is to see the best way to fix this
[18:37:06] <jmkasunich> feed override controls a variable called "scale" which scales all velocity
[18:37:15] <jmkasunich> feedhold simply sets "scale" to zero
[18:37:36] <jmkasunich> I'm getting upset because it seems you are ignoring everything I say
[18:37:56] <jmkasunich> if I can demonstrate the bug without a mode change, then how can the bug possibley be related to mode change cleanup?
[18:38:11] <petev> I'm not ignoring it, but you make a blanket statement like it is not a mode issue without any reason or stating the desired behavior
[18:38:43] <jmkasunich> 6 mins ago: <jmkasunich> feedhold is feedhold, just like feed override is feed override - they both apply to all modes
[18:39:22] <petev> listen, I just wanted to clarify the desired behavior of emc to mode changes and see if there were any further implications
[18:39:54] <jmkasunich> I am telling you that basically "forever", the "scale" variable has applied to all motion in any mode
[18:40:07] <jmkasunich> therefore mode changes are irrelevant
[18:40:39] <jmkasunich> if you want to discuss whether scale should apply in all modes, do it on list
[18:40:54] <jmkasunich> I'm not here to discuss policy, I'm trying to fix a reported bug
[18:41:09] <petev> this seems to be a fundamental issue with emc development, just because things have always been a certain way does not means it's best or right, I just wanted to discuss it
[18:41:20] <petev> no need to get upset
[18:41:24] <jmkasunich> this isn't the right venue to discuss it
[18:41:41] <petev> G28 has always been the way it is now, and it's wrong in my opinion
[18:41:55] <petev> no other commercial control I have seen works the way emc does
[18:42:17] <petev> so does that mean emc is right because it conforms to kramers spec?
[18:42:20] <jmkasunich> same issue - if the manual says it does X, any decision to change it will have far reaching effects and cannot possibly be decided by a couple people on IRC
[18:42:25] <jmkasunich> YES!
[18:42:42] <jmkasunich> emc must conform to the spec
[18:42:54] <jmkasunich> if there is a concensus that the spec is wrong, then the spec needs to change
[18:42:54] <petev> and spec changes cannot be discussed?
[18:42:59] <jmkasunich> and the code will follow
[18:43:27] <jmkasunich> but I'm saying that I personally at 2:42 on a saturday afternoon will NOT discuss spec changes
[18:43:33] <jmkasunich> if I can fix a bug I will
[18:43:40] <petev> ok, that's fine
[18:43:40] <jmkasunich> if not, I have other things I need to do
[18:44:19] <jmkasunich> your oringinal report sounds like a bug to me, so I wanted to fix it, if possible today
[18:44:29] <jmkasunich> a spec change will not an cannot happen that fast
[18:44:47] <petev> ok, so what do you think the best fix should be?
[18:45:01] <jmkasunich> the feedhold part seems straightforward
[18:45:29] <jmkasunich> if in feedhold, prevent initiation of any jog moves
[18:45:36] <jmkasunich> wheel, or keyboard
[18:45:54] <jmkasunich> the tricky part is feed override
[18:46:03] <jmkasunich> what if feed override is set to 0.001
[18:46:58] <jmkasunich> you can turn the wheel and dial in 0.1 inch of travel
[18:47:15] <jmkasunich> even tho it will take the machine almost forever to get there, I think it should go where you told it to go
[18:47:30] <jmkasunich> same with incremental jogs
[18:48:01] <jmkasunich> which by the way is a simple way to test this behavior, can do it with sim/axis and no hardware or jogwheel
[18:48:14] <jmkasunich> set an incremental jog of 1inch
[18:48:22] <jmkasunich> set FO to 0
[18:48:35] <jmkasunich> click the jog button, nothing happens
[18:48:43] <jmkasunich> set a non-zero FO, the 1" jog happens
[18:49:22] <petev> hmm, I think maybe this is where mode comes in
[18:49:23] <jmkasunich> damn, I think I found another bug
[18:49:32] <jmkasunich> this is all in manual mode
[18:49:40] <jmkasunich> you can't jog in any other mode
[18:50:40] <jmkasunich> the other bug: I could have sworn that if you had incremental jogs turned on, you could hit the key 3 times and it would jog 3 increments
[18:50:47] <petev> ok, then in manual mode I think all motion that cannot be executed when issued should be discarded
[18:50:58] <jmkasunich> but right now it seems to ignore any additional hits until it finishes the first one
[18:51:06] <petev> for instance when feed hold is asserted, any pending motion should be deleted
[18:51:22] <jmkasunich> I disagree only in detail
[18:51:25] <petev> if feed override is 0, motion should be ignored
[18:51:29] <jmkasunich> not deleted
[18:51:36] <petev> then what?
[18:51:41] <jmkasunich> no new motion should be requested when FO = 0
[18:51:48] <jmkasunich> but pending ones should be preserved
[18:52:16] <petev> I thing pending should be flushed in manual mode
[18:52:16] <jmkasunich> if you issue a 1" incremental jog, then hit feedhold half way thru, releasing feedhold shouldn't leave you at some random position
[18:52:27] <jmkasunich> it should finish the requested 1" move
[18:53:02] <petev> that I can see if the command was issued in the same mode, but commands from another mode need to be flushed
[18:53:06] <jmkasunich> after all, if you hit feedhold in the middle of a 3" machining pass (G1) in auto or mdi, you expect it to finish the pass when the hold is canceled
[18:53:37] <jmkasunich> agreed about mode change flushing commands, but thats not what we're talking about here
[18:53:38] <petev> true, but you don't want pending mdi stuff to run in manual
[18:53:43] <petev> ok
[18:54:04] <jmkasunich> mdi and auto moves are handled by a completely different TP than manual mode moves (jogs)
[18:54:04] <SWPadnos> geez you guys - that's a lot of log to read :)
[18:54:39] <jmkasunich> and any mode switch between those TPs re-inits them cancelling anything that was in progress
[18:54:40] <jmkasunich> * jmkasunich tests
[18:55:33] <petev> jepler, you back?
[18:55:57] <petev> SWPadnos, you got a test system handy?
[18:56:11] <SWPadnos> for sim, yes
[18:56:21] <SWPadnos> well, RT but no hardware - it's a laptop
[18:56:28] <petev> ok, can you try something with the latest CVS/head
[18:56:40] <jmkasunich> changing from manual to mdi immediately stops a jog, and changing back to manual does not resume it
[18:56:42] <jmkasunich> (as expected)
[18:56:47] <SWPadnos> hold on a minute. let me get upstairs and IRC from there
[18:56:54] <petev> jmk, agreed
[18:57:07] <petev> and vs versa
[18:57:18] <jmkasunich> not quite vice versa
[18:57:25] <petev> why?
[18:57:40] <petev> changing from MDI with a pending move to manual should kill the pending part
[18:58:00] <jmkasunich> changing from mdi to manual during a G0 X0 immediately stops motion, an error dialog pops up, and even tho the manual tab is active in axis, I can't jog
[18:58:07] <jmkasunich> should, sure
[18:58:18] <jmkasunich> I'm describing what happens, not what should
[18:58:24] <petev> ok
[18:58:42] <jmkasunich> are you on a working system?
[18:58:55] <jmkasunich> doesn't need hardware, doesn't need RT even
[18:59:02] <jmkasunich> but can't be a doze box ;-)
[18:59:03] <petev> I have a sim system avialable right now
[18:59:12] <jmkasunich> ok, this can be tested in sim
[18:59:47] <jmkasunich> start sim/axis
[18:59:49] <jmkasunich> f1, f2
[18:59:59] <jmkasunich> set jogs to incremental 1 inch
[19:00:18] <petev> SWP, can you try and test the axis machine->zero coordinate system for different coordinate systems?
[19:00:18] <jmkasunich> (oops, lemme commit my ini file change, 1" jogs aren't available at the moment)
[19:00:28] <petev> I can't get it to set all of them reliably on sim
[19:00:39] <petev> jepler put in a fix earlier today, so you need to update
[19:01:40] <jmkasunich> ok, change committed
[19:01:52] <petev> updating...
[19:02:31] <jmkasunich> jepler: you might want to take a look at this too - pete is right that there seem to be some mode change issues
[19:02:40] <jmkasunich> but there are also non-mode related jog issues that I'll try to address
[19:03:11] <jmkasunich> start sim/axls, hit F1, F2
[19:03:20] <jmkasunich> click home all
[19:03:34] <jmkasunich> set jog increment to 1"
[19:03:56] <jmkasunich> set jog speed slider to ~10 ipm
[19:04:12] <jmkasunich> start an X jog (arrow key, or click the + button)
[19:04:18] <jmkasunich> it starts moving
[19:04:21] <jmkasunich> then move FO slider to zero
[19:04:28] <jmkasunich> it stops as it should
[19:04:39] <jmkasunich> return FO slider to 100%, it resumes and stops at 1"
[19:05:00] <jmkasunich> now move FO slider to 0 again
[19:05:14] <SWPLinux> ok - got stepper_inch up and running, CVS fom ~1 minute ago :)
[19:05:20] <jmkasunich> click the + button twice (or hit -> arrow twice)
[19:05:26] <jmkasunich> nothing happens since FO is zero
[19:05:31] <jmkasunich> but the command is queued
[19:05:41] <jmkasunich> raise FO from zero, and it moves
[19:05:43] <jmkasunich> to 2 inches
[19:05:55] <jmkasunich> only moved 1" even tho two commands were issued
[19:06:01] <jmkasunich> now leave FO at 100%
[19:06:10] <jmkasunich> and issue two jogs
[19:06:19] <jmkasunich> again, it only moves 1"
[19:06:25] <jmkasunich> the 2nd one is ignored
[19:06:32] <jmkasunich> that seems like a new behavior to me
[19:06:55] <jmkasunich> I know you used to be able to click the jog button several times to jog that many increments
[19:07:27] <petev> hmm
[19:08:12] <petev> I think I prefer the new behavior, but I think you are right about how it used to work
[19:08:51] <jmkasunich> I don't prefer it at all
[19:09:21] <SWPLinux> it prevents someone from queueing up lots of motion with FO at 0
[19:09:29] <SWPLinux> and the resulting surprise when the slider is moved
[19:09:32] <jmkasunich> if I want to move 3 inches, I want to be able to hit -> three times without stop/start/stop/start/stop/start abuse to the machine
[19:09:40] <petev> hmm
[19:09:52] <petev> I would use MDI for that, but...
[19:09:53] <jmkasunich> SWPLinux: we've agreed in principle that when FO is zero nothing should be queued
[19:09:54] <SWPLinux> that's true, when the machine is moving
[19:09:59] <SWPLinux> ok
[19:10:08] <jmkasunich> but the problem happens even when FO is 100% and the machine is crusing along
[19:10:09] <SWPLinux> count me in on that one
[19:10:51] <jmkasunich> stand by a sec, trying something in tkemc (to see if its motion or GUI discarding the 2nd jog)
[19:12:25] <jmkasunich> ok, in TkEMC you can hit the jog key multiple times and they all get issued
[19:13:12] <petev> largest jog inc I see in axis is 0.1000, how do you set it to 1 in axis?
[19:13:23] <jmkasunich> in the ini file
[19:13:42] <jmkasunich> if you are using configs/sim/axis, updated in the last few mins, you should have 1inch
[19:13:49] <petev> ok
[19:14:08] <SWPLinux> I didn't have the 1" option
[19:14:17] <jmkasunich> hmm
[19:14:30] <SWPLinux> so I did make clean/make again- haven't run it yet
[19:14:32] <jmkasunich> <CIA-8> jmkasunich TRUNK * emc2/configs/sim/axis.ini: fix incremental jog increments
[19:14:42] <jmkasunich> no make should be needed, it was an inifile fix
[19:14:58] <jmkasunich> that was 14 mins ago
[19:15:46] <jmkasunich> if you need to do it manually for some reason (or for some other config) here's the diff:
[19:15:47] <jmkasunich> -INCREMENTS = 1 mm, .01 in, .1mm, 1 mil, .1 mil, 1/8000 in
[19:15:49] <jmkasunich> +INCREMENTS = 1 in, 0.1 in, 10 mil, 1 mil, 1mm, .1mm, 1/8000 in
[19:16:06] <jmkasunich> thats in the [DISPLAY] section
[19:17:51] <jmkasunich> ok, the "ignore a 2nd incremental jog while the first one is in progress" thing is apparently in axis, since tkemc doesn't do that
[19:18:09] <jmkasunich> which means I'm going to ignore it and let jepler and/or cradek figure it out
[19:19:24] <jmkasunich> the "issue and later execute a jog while FO is zero" is in motion
[19:19:53] <jmkasunich> thats is related directly to the original "turn the jogwheel while feedhold is on and it moves when you turn off feedhold" bug
[19:22:21] <jmkasunich> the fix might be as simple as 'ignore jog commands and jogwheel motion if "scale" is zero'
[19:23:01] <SWPLinux> do you think feedhold and FO=0 should be treated the same in all cases?
[19:23:05] <jmkasunich> if somebody sets scale (= feed override) to 0.0001, they might not like the result, but that is a perverse case
[19:23:09] <petev> that sounds pretty good
[19:24:38] <SWPLinux> or the more complex yet generic method: put a jog_threshold parameter in motion, and refuse to jog if scale<threshold
[19:24:53] <jmkasunich> eww
[19:25:12] <petev> I don't think it's so bad to jog slow, as long as the op can see the DRO changing
[19:25:19] <jmkasunich> yeah
[19:25:26] <petev> and any pending motion gets flushed on a mode change
[19:25:41] <jmkasunich> changing out of manual definitely flushes things
[19:26:00] <petev> then that seems like a reasonable fix
[19:26:19] <jmkasunich> the error dialog and other strangeness when you change from mdi to manual while an mdi command is still moving is yet another issue not related at all to this fix
[19:26:35] <Skullworks-PGAB> hmm it would seem that conditions where MPG wheel input would be allowed would also bypass FO
[19:26:54] <jmkasunich> Skullworks-PGAB: what?
[19:27:01] <SWPLinux> there's still a jog speed aplies to jogwheels
[19:27:02] <Skullworks-PGAB> but I guess thats all hardware
[19:27:04] <SWPLinux> applied
[19:27:19] <SWPLinux> no - a jogwheel in EMC just increments the target position of the jog
[19:27:32] <SWPLinux> but the jog speed setting still applies
[19:27:46] <petev> SWP, what results did you get for the "zero coordinate system" command in axis?
[19:28:41] <SWPLinux> I haven't gotten past "home all" yet :)
[19:28:55] <petev> ha
[19:29:12] <SWPLinux> ctrl-home doesn't do it for me, at least, the homed symbols don't appear
[19:29:47] <SWPLinux> h000. 3e00e try w5th a rea3 2eyb6ard
[19:29:53] <SWPLinux> oops - numlock on a laptop ;)
[19:30:02] <petev> you need to have HOME_SEQUENCE set for the axis in the INI
[19:30:38] <SWPLinux> is it not set by default in stepper_inch / sin_inch?
[19:30:43] <SWPLinux> sim
[19:30:51] <petev> I dont' think so
[19:31:01] <petev> is the home all button on the manual tab greyed out?
[19:31:08] <petev> or non -existent?
[19:31:16] <SWPLinux> nope - I guess not
[19:31:48] <SWPLinux> it's nonexistent, not grayed out
[19:32:02] <petev> then it's not set in the INI
[19:32:36] <jmkasunich> I wonder if I should do "if ( scale < 1e-6 )" instead of "if ( scale <= 0.0)"
[19:32:42] <SWPLinux> right just fixed that
[19:32:53] <SWPLinux> <some small number, yes
[19:33:03] <SWPLinux> 0.001 is probably low enough
[19:33:10] <jmkasunich> probably
[19:33:14] <SWPLinux> I'm not sure any UI will set it to less than that, except 0
[19:33:42] <jmkasunich> fortunately scale is a factor, not something with units
[19:33:53] <SWPLinux> gotta love dimensionless numbers :)
[19:34:16] <SWPLinux> I still don't have the 1" jog increment
[19:34:50] <petev> did you put the INCREMENTS line in the INI?
[19:34:51] <SWPLinux> oh duh. I'm not running sim/axis
[19:35:02] <SWPLinux> I think I might need central AC
[19:35:20] <SWPLinux> I've had enough coffee, but still don't seem to be thinking straight
[19:35:48] <petev> jmkasunich, there still seems to be some issue with having a soft limit and home position be the same
[19:36:03] <petev> jepler thinks the actual position gets loaded into commanded during a home
[19:36:06] <jmkasunich> don't do that
[19:36:09] <petev> does this sound right?
[19:36:21] <petev> don't do what?
[19:36:38] <jmkasunich> set home position to the soft limit
[19:36:40] <petev> is it bad to have sw limits of say 0, 18 and a home at 0?
[19:36:49] <jmkasunich> yes, home at 0.01 or something
[19:37:11] <petev> hmm, is there no easy fix for it?
[19:37:32] <jmkasunich> nothing simple
[19:37:31] <petev> after the error happens, emc is left in some funny state as well
[19:37:38] <jmkasunich> limits are not to be exceeded
[19:37:44] <jmkasunich> home is a place where you want to go
[19:37:54] <petev> I have tweaked my INI for now, but didn't consider it a permanent fix
[19:38:04] <jmkasunich> if they are the same, any tiny displacement whatsoever is gonna take you outside the limit
[19:38:25] <petev> yes, but remember, it's commanded position, not actual for the limit test
[19:38:34] <jmkasunich> I can only do one thing at a time
[19:38:36] <petev> so emc is actually loading a bad commanded position
[19:38:54] <jmkasunich> this gets back to mode changes and such - boundary conditions
[19:39:06] <petev> ok
[19:39:12] <jmkasunich> you can say it should never issue a bad command, but you have to consider everything that can happen
[19:40:01] <jmkasunich> it probably warrents a closer look, but not today
[19:40:16] <petev> fair enough
[19:41:42] <petev> SWP, you get homed yet?
[19:44:00] <SWPLinux> yeah - finally running the right sim axis, with a real keyboard, and I'm off the phone
[19:44:12] <petev> ok, try this
[19:44:15] <petev> go to mdi
[19:44:28] <petev> g54 g0 x9 y6
[19:44:55] <petev> then try and zero g54 with maching->zero coordinate system
[19:45:01] <petev> does that work?
[19:45:39] <SWPLinux> I got no error, but I don't know how to tell if it worked
[19:45:43] <petev> make sure you are viewing relative coords
[19:45:51] <SWPLinux> should the origin move?
[19:45:55] <petev> look at x, y, z
[19:46:00] <petev> they should be 0
[19:46:05] <cradek> petev: you're mistaken
[19:46:14] <petev> how?
[19:46:16] <SWPLinux> ah - nope - 9 and 6 are still showing
[19:46:37] <cradek> zero coordinate system means to clear the g54 offsets
[19:46:49] <petev> from the machine menu?
[19:46:57] <cradek> yes
[19:46:57] <SWPLinux> well, in that case it worked :)
[19:47:04] <petev> it gives the choice of all work systems
[19:47:16] <jmkasunich> well, CIA hasn't spoken yet, but I got the commit email - the jog/feedhold fix is committed
[19:47:23] <petev> does that mean to clear that coord system?
[19:47:26] <jmkasunich> petev: I'd appreciate if you can test - you have an actual wheel
[19:47:28] <cradek> yes
[19:47:34] <petev> jmk, will do
[19:47:40] <jmkasunich> i tested by setp axis.0.jog-counts, etc
[19:47:48] <cradek> you want to use touch-off and enter 0 as the "new" value
[19:48:01] <petev> cradek, ok, so there is no touch off all axis at once?
[19:48:05] <cradek> no
[19:48:08] <petev> ok
[19:48:10] <SWPLinux> cradek: that does the current coordinate system?
[19:48:17] <petev> so looks like all is fixed then
[19:48:29] <SWPLinux> glad to be of service :)
[19:48:33] <jmkasunich> "all" is a loaded term ;-)
[19:48:40] <jmkasunich> there are still 2 funnies
[19:48:41] <cradek> SWPLinux: the touch-off button always does G54 (which is the default system) but you can touch-off any system in the menu
[19:48:46] <jmkasunich> 2nd incremental jog ingored in axis
[19:48:51] <petev> might be nice to have the touch off button change the current coord system instead of always g54
[19:48:55] <jmkasunich> and mdi->manual mode switch while moving
[19:49:29] <petev> all reffered to jeplers fix ;-)
[19:49:35] <SWPLinux> I looked through axis.py and emcmodule.cc, and it looks like the jog just gets passed to motion
[19:50:12] <SWPLinux> it goes through several layers, but there's nothing that looks like it should swallow jogs
[19:50:14] <jmkasunich> strange - because running sim/sim-servo (which uses tkemc) lets me hit the arrow key as many times as I want, and moves that far
[19:50:30] <jmkasunich> running sim/axis doesn't
[19:50:40] <cradek> are the messages issued?
[19:50:45] <petev> hmm
[19:51:05] <cradek> ... no
[19:51:36] <SWPLinux> hmmm. it may be checking to see if you're already jogging, and not issue if so
[19:51:49] <SWPLinux> I also can't use L/R and U/D arrows simultaneously
[19:51:50] <petev> brb, going to test jmk jog fixes
[19:51:52] <cradek> arguably a feature
[19:52:06] <cradek> SWPLinux: in continuous mode you sure can
[19:52:15] <SWPLinux> yes, in continuous I can
[19:52:40] <SWPLinux> but I can't hit left then up, and have it do both actions
[19:52:44] <cradek> incr jogs that take much longer than a keypress/release freak me out anyway
[19:52:49] <SWPLinux> heh
[19:53:11] <jmkasunich> cradek: thats funny
[19:53:17] <SWPLinux> but that should mean that a real machine will stutter in incremental mode
[19:53:18] <cradek> I only use incr when touching off, and never more than .010 inch
[19:53:32] <cradek> jmkasunich: which thing?
[19:53:32] <jmkasunich> remember stuart's jogwheel velocity mode - thats because jogs that last longer than the wheel is turning freaked him out
[19:53:39] <SWPLinux> heh
[19:53:54] <cradek> jmkasunich: I'd be the first to say it was misconfigured if you could spin it faster than it moves
[19:53:55] <jmkasunich> and you thought he was nuts
[19:54:07] <cradek> (easily spin it faster)
[19:54:37] <cradek> it turns out we left it set at .010 as the max increment, and not velocity mode, because it could keep up with the wheel just fine
[19:54:51] <jmkasunich> oh
[19:55:06] <cradek> he may have changed it after I left, so as not to offend me :-)
[19:55:12] <jmkasunich> you mean I implemented vel mode and the guy who asked for it isn't even using it?
[19:55:20] <jmkasunich> heh
[19:55:34] <cradek> well that's how it looks, yes :-)
[19:55:35] <jmkasunich> bbl
[19:55:45] <SWPLinux> jmkasunich: do you know when you'll be back?
[19:56:19] <SWPLinux> I have FPGA build questions I'd like to get sorted out today or tomorrow (so I can work on some of that stuff on my trip)
[19:57:28] <SWPLinux> ok - it looks like I didn't look at the jog state arrays closely enough
[19:59:53] <petev> jmkasunich, looks like your fix is doing what you expected, but I did notice on strange thing, probably in task
[20:00:21] <petev> switchin from mdi to manual with feed hold asserted does not cause the error dialog like it does when feed hold is not asserted
[20:00:35] <petev> that is with pending motion
[20:02:56] <petev> jmkasunich, don't feel bad, my jog wheel is high resolution with no detents and I'm using velocity mode, that being said, I don't think I can turn it faster than the machine will go by hand anyhow
[20:05:03] <SWPadnos> didn't play many arcade games in your youth, did you? :)
[20:05:24] <petev> no, I just configured it correctly ;-)
[20:05:26] <SWPadnos> heh
[20:06:02] <petev> cradek, BTW, how do you stop / start the spindle in manual mode with axis?
[20:06:11] <cradek> f9
[20:06:15] <petev> ok
[20:06:15] <cradek> or click the button
[20:06:23] <petev> what button?
[20:06:25] <petev> I must be blind
[20:06:30] <cradek> maybe so
[20:06:45] <cradek> it's right there, there's spindle reverse/stop/forward buttons
[20:07:03] <cradek> like the rest of the manual buttons, if they aren't hooked up to anything they won't show
[20:07:30] <petev> ah, what do you mean hooke to anything, the pins from axis?
[20:07:38] <cradek> the iocontrol? hal pins
[20:07:44] <SWPadnos> HAL pins for spindle
[20:07:47] <cradek> right
[20:07:53] <petev> ok, so I need to connect them to halui or something?
[20:08:10] <SWPadnos> connect them to the output that will affect the spindle
[20:08:24] <petev> SWP, no, there is already a pin from motion for that
[20:08:34] <cradek> if your spindle works, you will already have the right thing hooked up
[20:08:45] <SWPadnos> hmmm. I thought that's what axis checked
[20:08:52] <petev> my spidnle works, but I have no buttons in axis
[20:09:03] <petev> I have buttons in tkemc and they work too
[20:09:24] <SWPadnos> the idea is that axis looks for the things that your machine supports (as evidenced by the appropriate HAL pins being connected), and only shows you what you need to control your machine
[20:09:37] <SWPadnos> makes it less cluttered for newbies
[20:09:38] <petev> cradek, is axis looking for certain hal pins in the hal config?
[20:09:40] <cradek> newsig spindle-fwd bit
[20:09:40] <cradek> linksp spindle-fwd <= motion.spindle-forward
[20:09:51] <petev> yeah, I don't use the spindle fwd/rev
[20:10:03] <petev> I use spindle speed
[20:10:04] <cradek> uh what do you use then?
[20:10:25] <petev> there are too many duped spindle control pins in hal
[20:10:34] <SWPadnos> I wonder what happens if you just connect motion.spindle-fwd to a signal (that connects nowhere else)
[20:10:36] <cradek> oh you count on speed to go to 0 to stop it?
[20:10:47] <cradek> SWPLinux: it'll work
[20:10:56] <petev> it does, I cheked it and jmk wanted to make it the only pin at one time
[20:11:21] <SWPadnos> ok, so net spindle-duh motion.spindle-fwd :)
[20:11:28] <cradek> well hook spindle-fwd to a signal
[20:11:31] <cradek> yeah
[20:11:38] <petev> there is also a spindle-on pin
[20:12:00] <petev> I think there are too many pins
[20:12:02] <SWPadnos> axis may check all three, but I don't know
[20:12:19] <SWPadnos> there are, but they support functionality you'd have to use external components for
[20:12:21] <SWPadnos> otherwise
[20:12:45] <cradek> I like that I can hook -fwd to a SSR and -speed to a dac and not worry about any special cases
[20:13:09] <petev> except if you have a back gear and fwd isn't always fwd ;-)
[20:13:31] <petev> cradek, how about adding spindle speed to the axis status bar?
[20:13:32] <cradek> sure, but that's a simple matter of hal configuration
[20:13:38] <SWPadnos> you still need the signal, you'd just have to get it with a comparator at 0
[20:13:45] <cradek> petev: see sim/lathe for a nice vcp readout of that
[20:13:47] <SWPadnos> (if it didn't exist in motion)
[20:14:22] <SWPadnos> petev, OT: what was the series of your Yaskawa motors and drives?
[20:14:33] <petev> can the pyvcp stuff integrate to the axis window, or does it have to be some new floating window?
[20:14:45] <petev> SGDA drives and SGMP motors
[20:14:49] <cradek> they're together
[20:14:57] <SWPadnos> there's a way to get it to integrate into axis
[20:14:57] <petev> ok, that sounds good
[20:15:20] <SWPadnos> thanks
[20:15:19] <cradek> I like my lathe setup where I have bargraphs for pid output too - it's a good indication of cutting load
[20:16:11] <petev> hmm, I'll have to check that out
[20:16:50] <cradek> I'd like the bargraphs to turn red at 90% on or something, but there doesn't seem to be support for that
[20:17:05] <petev> cradek, should axis have buttons for coolant too?
[20:17:11] <cradek> it does
[20:17:12] <petev> I do have those hooked up
[20:17:15] <petev> where?
[20:17:24] <cradek> with the others on the manual tab
[20:17:32] <petev> dang, don't have them either
[20:17:39] <petev> what hal pins is it looking for?
[20:18:11] <cradek> forget(widgets.mist, "iocontrol.0.coolant-mist")
[20:18:11] <cradek> forget(widgets.flood, "iocontrol.0.coolant-flood")
[20:18:11] <cradek> forget(widgets.lubel, "iocontrol.0.coolant-flood", "iocontrol.0.coolant-mist")
[20:18:42] <cradek> I think this code means "unpack this widget if all of these are not hooked up"
[20:18:54] <petev> ok, will check it out
[20:18:57] <cradek> forget(widgets.spindle_cw, "motion.spindle-forward", "motion.spindle-on")
[20:18:57] <cradek> forget(widgets.spindle_ccw, "motion.spindle-reverse")
[20:18:57] <cradek> forget(widgets.spindle_stop, "motion.spindle-forward", "motion.spindle-reverse", "motion.spindle-on")
[20:19:01] <cradek> ^^ fwiw
[20:29:37] <petev> cradek, is there any way to make the DRO fonts bigger in axis?
[20:55:17] <jepler> petev: I can't check this right now, but my recollection is that by setting '*Togl.font' to the desired font in XLFD syntax, you change the font in the "DRO"
[20:55:27] <jepler> that's *Togl.font in the X resource database
[20:58:22] <petev> ok, thanks
[21:10:00] <SWPLinux> cradek: quick question - do you know when the election will start and stop?
[21:10:26] <jmkasunich> I think ballots are supposed to go out this weekend some time
[21:10:38] <SWPLinux> ok- I may be able to vote before leaving then
[21:10:42] <jmkasunich> and I think duration is either one week or two weeks
[21:10:57] <SWPLinux> ok. see you - running now
[21:23:25] <alex_joni> bye SWPLinux
[21:23:26] <alex_joni> hi guys
[21:33:29] <jmkasunich> hi alex
[21:33:44] <alex_joni> hey John
[21:33:59] <alex_joni> seen you had a nice talk to petev :D
[21:34:15] <jmkasunich> I got a little carried away
[21:34:27] <jmkasunich> I wanted to do a 30 min bugfix, not review the spec
[21:34:27] <alex_joni> well.. it happens
[21:34:32] <alex_joni> * alex_joni is happy to be home
[21:34:47] <alex_joni> patched up a couple of robots this week
[22:02:48] <alex_joni> good night all
[23:25:43] <petev> jepler, u there?
[23:26:10] <petev> cradek, how about u?