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