You into spring up there?
I think so
hard to tell after being in Honolulu for a week ;)
Ah. I don't think that's right.
hey - do you need a manual for the pulsegen?
I realized I had forgotten to send one
I believe that it's working but I don't know how well.
ok. I'll email you a pdf sometime soon.
heh - that's relatively good news
Have to check when I get back down there.
man - what a PITA it is to get the boss setup to load in simulator mode
yep, it has a lot of connections
and some are net commands (With motenc pins in them), followed later by other connections to that net
so the nets need to exist ...
that's a slightly old version too, got more connections now ;-)
lots of joint amplifier faults :)
maybe I should connect the boss controller to something :)
the amp fault stuff is processed by the boss plc
yep. can I just set a signal to true and connect it to all the amp-ready inputs?
this is because the enable also resets existing faults, and emc doesn't wait for this to happen
you don't have to connect anything to it, if you don't care about the fault out signals
I get joint  amplifier faults, which cause the machine to go to OFF (estop reset) state
and you set the ready input to true?
err - no :)
I just bought a USB wifi, hopefully I'll have it in a few days and can get the machine on the net
that will make things easier
ah, not all the bits in the comment (in boss_plc.c) are implemented
should be, what is missing? though I kept it up to date
it looks like the amp-ready / amp-fault stuff isn't there
or I just don't see where it's exported
it is as I'm using it
ok, it's acalled boss_plc.0.z-fault-out instead of boss_plc.<id>.z-amp-fault-out
oh, better check those comments for accuracy ;-)
much better once I fake those to true :)
hmm, should I change the comments or the exports, which name do you prefer?
I think the -amp-fault-out is more descriptive
(but also longer, so YMMV :) )
strange. the CPU clock control doesn't pop up the frequency when a single core is maxed out
which would be ideal for AXIS generating a preview, since it's single-threaded
hmm, you're throwing more variables into the mix witth the duo core stuff
nope, but I am with simulator mode ;)
have you sucessfully run sim already?
yes, I have a modified version of your boss setup loaded right now
I'm just playing with a large g-code file - I think they've improved the nVidia drivers significantly
I can spin this large preview around in very fluid realtime, with axis at 1920x1100-ish
it's 515634 lines of g-code
that's pretty good
it's only a 7800GT video card - not even one of the quadro FX3500's
ok, enough playing - now to make a vcp panel for home testing
dunno - I got sidetracked :)
well the problem happens during the final move in state 18
I don't really understand all the data structures used in there, so I'm not sure what's going on
state 13 appears to change the cmd pos
which seems like it would upset the PID, but I'm not sure if it gets sent out directly
what is clear is if HOME_OFFSET = 0, there is no problem as there is no final move
was stuart using a final move in his homing?
I definitely did, on both my lathes
but I haven't used either of them for a few months
did you have drives that would detect accel violations?
yes, one was steppers, the other was servo with tight FE limits
neither would have allowed a big accel violation
I *know* I would have noticed it
what magnitude was your emc FE set to?
did you home sim/axis and scope it?
SWP was working on the sim
just to eliminate the drives themselves from the equation, you should be able to disconnect the drive, and use a physical (digital / storage) scope to look at the voltage swing
not sure how far he got, he was making a VCP
what is that, about 4 thou?
FERROR=.1 MIN_FERROR=.03 (mm)
I got to the point of copying a vcp file into the boss sim dconfig, not much further
yeah something like that
that's pretty loose
that was at 1ips rapids
that's pretty slow ;-)
I'm running 3.3 ips and 1 thou now, and I consider that a bit loose
not on a machine with 2" of travel
it's very fast
when using just the drives, they will hold about 2 counts (100,000 = 1 in) on fast moves
this is not any big deal, as the belts are not on
so I would expect it to be at least this good
the emc position loop doesn't hold anything near as good
[01:51:01] <cradek> http://timeguy.com/cradek-files/emc/simaxis-Xhoming.png
what are the signals?
green=switch, purple=state, cyan=acc, red=vel
so you're using a different homing seq then what I was trying?
I just homed X in sim/axis
looks like you are moving back onto the switch, no?
yeah looks like
and what is HOME_OFFSET?
the problem I see occurs in state 18
it doens't happen unless HOME_OFFSET is non zero
I can home fine with HOME_OFFSET=0
[01:55:26] <cradek> http://timeguy.com/cradek-files/emc/homing-with-offset.png
offset=.5, so the last move in stage 18 is longer
try changing the latch vel sign so it's like the sequence I was using
sim/axis is a nicely configured test bed - there are ddt for vel/acc etc
what are you using to sim the switches?
search +, latch -?
there are some comparators
it's all in there already
I have the sign of latch the opposite of search
search is +, latch is -
[01:58:21] <cradek> http://timeguy.com/cradek-files/emc/stillfine.png
you can see the last move is a rapid (-1.2) and accel is right
hmm, the graphics are messed up on this one
I'll take your word for it
what is your ACCEL limit?
portions of the traces are missing
maybe its an explorer issue
the image is fine
you must be throwing out pixels
not me, bill
well surely even windows can view a png without screwing it up
I don't have problems with them
so I wonder what the difference is here?
looks like the same seq and limits now
I don't know what to suggest except you make the same plot for us to see
what is your VEL limit?
you have this exact config, it's sim/axis
you didn't change any params?
no it's running right off trunk
ok, what are you using to sim the switch?
well I made LATCH_VEL negative
is the switch sim built in too?
damn. I wish I had known that :)
there's a lot of stuff in sim/axis...
I can make the same plot, but we will not see much at the end where is counts as the drives and emc will stop due to the accel problem
I'll try and crank the following error way up to get more data
can you scope the output of the motenc card with a digital / storage scope?
maybe, but what would that help?
I can see the command to the drive from the drive GUI
you can see if the problem is in the PC
so you don't trust the AB drives?
well, there's some funky software somewhere. when debugging, I don't like to assume anything
the drives may be fine, but who knows if there's a problem somewhere else (like mm instead of inches set somewhere in the drive, causing all the acc/vel/ferror stuff to be wrong)
I can try and capture with a scope, but we will have to estimate the accel from the ramp
"put on your stupid hat", as one engineer friend once said :)
not exactly accurate
I don't think so, as I can make moves with the jog wheel, etc. without problem
if you have a spare DAC on the motenc (or one that can be used as such), you can output acc from a ddt to the extra output
this IS a rapid which is 7x the search vel
the search vel is pretty low
I ran moves at the full 200 ipm from the drive
I have emc limited to 180 ipm
so I expect it would work
who knows, maybe the drive needs 20 ms after homing before another move
the drive doesn't know it's a home move
how would it?
the drive provides faked encoder feedback, doesn't it?
it's not faked, it's actual encoder feedback
100k counts/inch - that's quite a bit
2500 lines * 4 * 5 TPI * 2:1 ratio
2500 lines - there you go :)
mine are "only" 1000 :)
my jog wheel has 500 lines ;-)
I think 50 would have been better, but it's what I had in my junk box
ok. I was thinking that this drive was one of the ones that provides a (programmable) encoder output, so it would need to have its internal counter zeroed or something
clearly we need more data
and I don't think anyone but petev is going to be able to collect it
it can divide the count from the motor, but I have the divide set to 1
I think the only way I can get more data is to increase the FE, and just have the drive limit accel, but not fault
then it should run until emc decides the FE is too much
I can try this
what happens if you set the EMC maxvel to something insanely low, like 0.1 IPS, with accel similarly low?
or did you already go that low?
no, haven't tried anything like that
argh, somehow a windows machine mangled your .ini file
the boss file?
ok, 0.1 vel, 1 acc might be something to try - to see if it's porportional to the limits or "constantly very high" ...
looks ok here, how is it mangled?
yeah - I noticed basically the entire file being - then + in that diff
^M ^M ^M
I wonder if that happens somehow if I commit with tortoise?
maybe, but only if it sucks
more likely an editor did it
tortoise is the best cvs/svn I have found
my editor does not change it
that I know
want me to fix it?
there's a tortoise option to "use UNIX line endings" (options tab)
I'll try and check the files to see if I can see what's happening before any further checkins
but it's not "if detected" - I suspect it's always
I can only commit from the linux box, it's not a big deal
oh you fixed it in rev 1.2
petev, how did you get ssh to work with tortoise?
SWPadnos, I used Putty
1.1, which I had from earlier today, was the screwed up one
hmm, that's odd
I didn't specifically edit it anywhere, it must be the cvs client
you can load your ssh key into pageant, which is part of the putty package
cradek, were you using servo_sim.hal ?
no, just sim/axis
sorry, I don't mean to speak in code
ok, looks like that loads core_sim.hal
ok, I see an issue with the sim file
where are the PID loops? the ddt are on the commanded positions
it may well be the PID that is causing the large accel
try the sim that uses pid then
hi guys, I'm back
jmk, to recap where we are
I suspect that FF0=1 and P=100 may cause rather faster swings than the TP outputs
the problem occurs during the final move in state 18
this only happens if HOME_OFFSET != 0
cradek ran a sim without PID and the commanded position looked ok
I suspected the PID earlier when looking at state 13
but I wasn't sure if cmd_pos was output directly
ok, state 17 (final move start) sets free_pos_cmd... that is the INPUT to the free mode planner
a step change there yeilds a vel and accel limited trapezoidal move a the output of the planner
what is the cmd_pos in state 13?
petev: which cmd_pos?
we gots too many of them
line 1577 in control.c
lemme update, my 1577 doesn't seem to match up
you are looking at latest CVS?
I think so, let me check
no, looks like it was a bit old
joint->pos_cmd is the output of the free mode TP
where does it end up? does it get on the hal pin?
stand by... looking for a doc
BTW, I have my base period the same as the servo period. I didn't see any reason to have it faster with a servo setup
I _think_ thats OK
to rule it out you might try making base period 1/2 of servo period
but thats a long shot
[02:35:49] <jmkasunich> http://www.linuxcnc.org/docs/EMC2_Developer_Manual.pdf
will make things a lot easier to understand
back in a minute
so if I read that correctly, it looks like that position will be sent to the PIDs when the free mode is selected in state 17 ?
so won't that jump in cmd position cause the output of the PIDs to change too quickly?
free mode is in effect thru the entire homing process
lets look at state 13 first
offset is the amount of adjustment needed to make the current position = HOME_OFFSET
it is added to both pos_cmd and pos_fb, so there is no following error
its subtracted from motor_offset, so the actual outputs to HAL don't change
but pos_fb gets updated from enc, no?
and its added to free_pos_cmd so the free planner won't try to move
motor_pos_fb is coming from the encoder
and to the PID ...
pos_fb is motor pos with motor-offset subtracted out
and that happens every servo cycle?
the code in that diagram executes every servo cycle
so what happens when state 17 commands the move?
at the point where "do_homing()" runs, the subtract of motor-offset from motor-pos-fb has already taken place, but the add of motor-offset to pos-cmd has not
so state 13 corrects pos_fb, pos_cmd, and motor_offset
later on, at the end of the control code, motor_offset is added to pos_cmd to make motor_pos_cmd
the next effect of state 13 is a step on pos_fb and pos_cmd (to the desired position based on home switch) but no step in the signal going to the motor
I follow the concept
so what happens when the final move starts?
this problem happens even when you are NOT homing to an index, right?
yes, but only with a final move
without the final move, there is no problem
after the pause times out, the free mode planner command gets set to the home position, the free mode velocity limit is set to the machine limit, and the free mode planner is enabled
what about the accel limit?
at which point pos_cmd (output of free mode planner) should do a accel and vel limited move until it matches free_pos_cmd
thats already set to the machine limit and never changes
free mode vel changes, because the free mode planner is used for search move, latch move, jogs, etc
hmm, I clearly see accel violations at the drive, thought the vel never gets a chance to see where it will settle
I guess I need to put a ddt on the PID output
have you looked with halscope at motor-pos-cmd, and/or pos-cmd?
don't look at the pid output
look at the command to the PID
the drive sees the PID output, not the cmd
do you have your PID properly tuned?
it is not very agressive at all
which is something else I wanted to talk to you about later
right now PID output is in ips
then why do you think its causing wild accels?
and the DAC and drive are scaled accordingly
unless its command contains wild accels
FF1 is set to 1
and a mild P
no I or D
I get accel violations at the drive
mild P = ? number
I removed the drive accel limits and used current limits
so 1" of error will cause 100 ips of velocity command out of the PID
with the drive I could acel at 25 ips with about 3 A current
ips^2 you mean?
I set the current limit to 12.5 A and emc would still trip it on the final move
I gathered from reading back that you aren't actually at the EMC machine when you are talking to us?
so it's accel is way past 25 ipss
no, the emc machine is not on the network yet
I'm working on that
so its gonna be a pain in the ass to do any testing?
I can take the notebook out there if it will help
you talk to us, then hike out to the machine, then hike back..
we'll never get anywhere that way
yeah, but if we need to test a lot, I'll setup the NB
not a problem
ok, so what do you want to test and I'll set it up
it would be nicer if you could post halscope pics, but we'll make do
several tests come to mind
try turning off FF1 first, see if that makes a difference
then we'll move on from there based on that result
when I was playing with PID tuning, it didn't quite behave as I expected
what did you use for command while tuning? siggen or something>?
with FF1 off, tracking pretty much sucked no matter what I set
no, didn't do anything rigourous yet as the belts are still off
just checking for oscillations and using the jog wheel
I had the mazak scaled the way you have yours scaled (PID out = ips), and IIRC both P and I gains are a few thousand
so I'm not surprized tracking is weak
I think cradek found that ff1 in the 0.01 range had a rather large effect
on NIST-lathe, I think
even the slightest amount of D causesed oscillation
I think the mazak has D set to 8 or something
I had P all the way up to 5000 and it didn't make much difference with FF1 enabled
well, right now we're chasing too many variables
without FF1, there was noticably more oscillations, but tracking wasn't a whole lot better
gotta pin it down, which means we gotta stop talking and start testing
so do you think PID is a problem when tuned so mildly?
I don't know what to think, I need data
ok, tell me what you want
halscope monitoring home_state, pos_cmd, and motor_pos_cmd, set to trigger when state becomes 18
do a home
already did that
what info do you want?
and since you can't post the halscope pic, describe it to us
what is the value of pos_cmd immediately prior and immediately after the trigger?
so everything looks normal, but emc gets a following error in state 18
and the drive indicates excessive accel
what is the value of pos_cmd immediately prior and immediately after the trigger?
ok, that is a bit of a problem
hal scope seems to have a bug or two
the cursor seems to get out of sync with the sample
it would change depending which way I moved the mouse on approach
cursor on the same spot, but two different results
even if you zoom in?
I was zoomed all the way to 1 msec
the sample rate
also, it looke like only 3 digits to the right of the decimal are displayed
I rarely use the cursor, so I can't vouch for it, although I don't think I've ever seen that
which may not be enough
I just read the scope like a regular scope
use vertical scale to get it on screen
ok, I can try that
then if needed, use offset to get it close to the center
then scale it bigger
let me setup the NB and make another run
you can use offset to allow a scale of 1u-inch per div even if the value of the signal is 1000 inchs
ok, I have it setup
u said you wanted to trigger on state=18?
it goes from 13 to 18, right?
how do I do that in hal scope?
so you can set the trigger level to 15 and rising, and should be good to go
13 is never seen
I think it runs in the loop
well, it goes from something low to 17 or 19, right?
17 or 18, sorry
so set it just under 17
"how to do in halscope" meaning what buttons to push?
trigger is on the right hand side
I got that
ok, u want the pos cmd/fb ?
home-state, pos-cmd, motor-pos-cmd, and motor-pos-fb
ok, let me setup with those
cradek: you did testing with sim_axis?
[03:17:20] <cradek> http://timeguy.com/cradek-files/emc/stillfine.png
and that has the ddts and sim switches in it
ok, purple is state
green is xvel = ddt of motor-pos-cmd
blue is accel?
oh, green is not xvel
red/pink is xvel
green is what? the switch?
cradek> green=switch, purple=state, cyan=acc, red=vel
so when the switch opens, you get decel to stop, pause, then accel to rapid rate for the offset move
ok, there is an offset between the motor cmd and the joint cmd
having the ddts in there certainly make this easier to read... position is gonna be harder
joint cmd and fb look pretty much the same
joint cmd meaning pos-cmd?
let me zoom way in
these are the pin names
I assume that's what you whanted?
sorry, the hal name and the source variable name don't quite match
joint-pos-cmd is the hal pin for pos_cmd the variable
(which means that drawing is in error, bummer)
well I think I got the right pins
you do. I would expect joint-pos-cmd to make a step change when going thru step 13
any how, I don't see any diff between motor-pos-cmd and motor-pos-fb
motor-pos-cmd should not
but emc throws a following error
good, that means PID works ;-)
and the drive see excessive accel
what is the actual value of motor-pos-cmd at that point?
according to the cursor, it's -0.034 +/-
and there is no step change of any kind?
very gradual with the level of zoom I'm at, it's changing like -0.034, -0.035, ...
so one thou per msec
or 1 ips
1 inch per sec
not very fast
yeah, but that's cutting speed ;-)
nothing that should cause a problem without belts
I ran much higher tests with the drive
thats not the point
so I know the motor setup is capable of it
look at cradek's pic: http://timeguy.com/cradek-files/emc/stillfine.png
the bottom trace is velocity
well, it does rule out the motor setup
you see the search move (positive), then it ramps to a stop. pauses, then the latch move (negative), ramps to a stop, pauses, then the final move (also negative, faster)
you need to be able to see the same thing on you machine if you hope to understand whats going on
yes, but not much faster
taking the derivative manually sucks though
I have more of a delta between my latch and rapid speed
not much faster, because thats how its configured
ok, so first
where is emc detecting the FE when it's not visible in hal scope?
is hal scope limiting displayed digits?
ok, lets figure that out
we need another channel
second, why does the drive indicate the excessive accel?
if you have it configured for 4, click on the button at top right of the screen,and change to 8
ok, what do yo wnat to add?
three new channels actually... axis.N.f-error, axis.N.f-error-lim, and axis.N.f-errored
trigger on f-errored going true
are those params?
hmm, the ferror is right when the state goes to 0
the ferror is a red herring then
so it looks like it's after the final move?
of course you get a following error after your amp trips out
Its not completing the final move, the amp is tripping, emc tried to keep going, then says "hey, you're not keeping up"
strange thing is the amp is not set to trip out
it is only limiting right now
so it never faults
I thought you said it was tripping?
limiting is the same thing, if it can't keep up with the commands that EMC is sending out, its gonna ferror
I can set the amp to do different things
emc is getting an FE
the amp is just limiting the accel to 25 ips
emc is set to 20 ipss
so it shouldn't cause a problem if things are correct
if EMC asks for more than 25ipss, then the amp will limit it, the fb will fall behind the command, and emc will error out
the ferror is a symptom only, happens well after the problem
yes, but if emc is working, it shouldn't ask for more than 20 ipss
so lets forget it and concentrate on the problem
ok, I see FE at 0.003
right - the problem is an apparent excessive accel NOT an ferror
so we need to look at accel
but motor-cmd and fb are the same according to hal scope
so how did FE get to 0.003?
the same within 0.003? even after the point that it trips?
it hasn't tripped yet at that point
I'm just wondering why the numbers don't add up
me too - I'd give a lot to be able to look at the scope with my own two eyes
I haven't seen any diff between cmd/fb in hal scope
cmd and fb are never the same - you would have no pid output without some error
what scale are you at?
(for cmd and fb)
using the cursor
let me try and magnify
a pox on cursors
well I thought that would be more accurate
even at 5m gain I don't see a diff
but ferror is at 0.003
I assume ferror is getting worse over time
after all, it trips eventually
ferror should also be a bit noisy/fuzzy due to encoder counts, etc
you have 100K counts per inch, right?
yes, let me confirm that without cursor
yes, that's correct
and appears to be ramping slowly
2500 lines *4 * 5tpi * 2:1
it doesn't look noisy at all
slight ramp, then state goes to 0, and FE drops to 0.001
if you change the ferror scale to 50u/div, you should start to see individual encoder counts
but 50u/div will push 0.003 offscale
let my try and zoom closer
it's not noisy, pretty steady ramp
you can click the offset button (under the vertical scale and pos sliders) and set an offset of 0.003, so the trace will be centered around zero even when you crank the gain up
I can't seem to get enough offset to see it at 50u though
let me try
scale down until you see the trace, then not the level (cursor _might_ be handy there), then click the offset button, enter that value in the dialog
that should shift the trace down, so the value you entered is center-of-screen
then you can scale up lots without it going off-screen
why is the pos slider different than offset?
pos slider moves the trace up and down a max of one screen width
its used to position the trace on the screen
offset can subtract out thousands of divisions of offset
(try that on a real scope..... ;-)
but they seem to be separate offsets
so it's hard to zero the pos once you change it
using pos and offset is a pain
so I tried pos first, and now I have no idea what it is set to
I suggest setting scale low (like 1M/div), offset to zero, use pos to center the trace, then don't touch pos again
anyhow, at 50u, the ramp is very smooth, I can see a nice stair step
it would be nice to have a "set pos to screen midpoint" button
it is building until the time when state goes to 0
"smooth stairstep" ? thats a new one
also very confusing to the reader
if its stairstepping, its not smooth
I mean the stair step is monotonic, it's not noisy
anyhow, the cursor reading may be all wrong
is each step 10u inches?
at this res, it reads 0.001 everywhere
I don't think it shows enough resolution
the cursor has issues ignore it
at 50u/div, 10u encoder steps are 1/5 of a division, you can see that with your eyes
there is about 10 div between the max FE and when state goes to 0
I've been using scopes for 25 years, and scopes with cursors for a much shorter time, I don't use the cursors much
the screen is only 10 div high?
yeah, I have it centered nicely ;-)
if its in the center, how can it be 10 div from anything?
from largest FE to when state goes to 0
this is the range of FE
when state goes to 0, FE drops way down
let me try and zoom the cmd/fb
state goes to zero when it trips, at that point it stops calculating FE, instead it forces command to equal feedback
so ferror will go to zero at the moment of trip
ok, so there are about 10 div of FE before that
10 div at what scale?
but It doesn't look like the diff between cmd/fb matches that
so 500u inches at the moment it trips
does that match up with your config?
how'd you do that?
should I check it in?
my min FE is 0.001
you da man
of course check it in
and FE is 0.005
so it seems well within that limit
also, FE seems to be delayed one cycle
well, you were also capturing f-error-lim, right?
it is stil increasing when the delta is not
take a look at f-error-lim
it should be between 0.001 and 0.005
I've wanted that since day 1, and it was only 4 lines of code
f-error-lim should reach 0.005 at max speed, and be 0.001 at zero speed
and the error should occur when f-error exceeds f-error-lim
nice labeled traces
the error will be indicated by f-errored going true
it looks like it correlates with ferror lim if I got the scale and offests right
hm, I think it's leaking pango layouts though
whatever tf those are
it looks like it must be on a decel, as the ferror lim is decreasing
I think its time we got a couple ddt blocks in your hal config
so we can measure velocity and accel directly
yeah, I was thinking that 2 hours ago ;-)
messing around with offsets gets old fast
the limit is way above the ferror
so how come you didn't put them in then?
but one is going up, and the other down
because I started talking with you ;-)
you're saying that at the moment f-errored goes true, the absolute value of f-error is less than f-error-lim?
with both traces having the same scale, offset, and position settings?
no, they cross at that point, but for the bulk of the move, it is well below
well, that means its working like its supposed to
same as far as I can tell, and the cross point correlates with errored
yes, but it seems as if the error is on decel, not accel
that is new info
I assumed it was accel
we need to look at the commanded vel and accel now
we're either exceeding limits, or we're not
if we are, its a bug
so you want the ddt on the PID outputs?
on axis output?
what is this fixation with pid output ;-)
I want to see what the drive see
since it is indicating excessive accel
ok, we'll put 3 ddts in
axis (2), pid (1) ?
incidentally, when you recompile so you get cradek's nice labels, if you change TIP_FORMAT in hal/utils/scope_vert.c, you can increase the resolution of the value reading
two on motor-pos-cmd, and one on pid output
I'm sure it would have been more than 4 lines if I had ever done it - nice job cradek
ok, I have to get a memory stick and make some edits
SWPLinux: I think it'll be 5 lines before I get it right
don't forget the comment ;)
* cradek <- not a gtk programmer
me either, that's why I - err - floated to other things when I started that task
oh, and I meant to say scope_disp.c, not scope_vert.c
any particular position you want the ddts in thread order?
put them at the end
the vel one should be before the accel one, since the latter processes the former's output
can I use a net command with only one pin?
leaving us so soon?
another strange thing
when I start emc again after the homing error, axis pops up a dialog that say it cannot home until machine is out of estop and on
so seems like something got left behind from the previous run
I believe following error causes an estop
this is with a complete exit of GUI and re-start
so you will have to reset that
emc should always require that right after startup
it should never start with estop reset afaik
wait, you mean as soon as it comes up it pops the dialog? before you give it any commands?
that is usually the case, but sometimes it has started without needing the soft e-stop reset
but this dialog only happens after the homing failure
it should always require F1/F2 before homing (or any other motion)
should being the key word
but it doesn't
SWPLinux: yes, we all agree on that.... but if I understand pete, its acting like he pressed home the instant the gui comes onto the screen
so where is state maintained between loads?
(before he does f1 f2)
this is on an RT system, right?
jmk, that's correct
and only when the previous run failed to home
but I exited everything, even made a new hal file this time
so where is that being saved?
and emc is completely shutting down? (are you invoking it from the command line, or from an icon?)
first time from command line to check hal file, then icon
(more shoulds) - emc shouldn't start up if the previous run hasn't shut down ...
it didn't copletely load the first time due to hal error in my file
I think you have ghosts
also, axis doesn't even lt you try to home if the machine is not on
so it really seems like an error msg is stored somewhere
I don't know what the kernel -> user error message transfer path is, so I can't rule that out
isn't it NML or shmem?
when you get the homing error dialog, do you dismiss it (and any that follow it) before shutting down axis?
yes, but I don't get that error on the previous run that fails
I only get an FE dialog
and I dismiss it
I have no clue
its after midnight here, and I can only focus on one problem at a time
do you have the ddts in?
I lost server connection in the shop
won't let me back on
fun with wireless
anyhow, the PID accel is 3.2K
and the cmdAcc is 600K
something seems crazy
the commanded velocity is changing by 600 ips in a single sample?
let me log out here and see if it frees my nick for the shop
ok, I'm on again in the shop
ok, cmdVel is negative
goes from 0 to -600
then back to 0
in one period?
-600 for one sample
ok, that smells like a step change of position
stepping 0.6 will result in a vel of 600
(with a 1KHz servo rate)
so where the hell is that coming from?
that kind of a step should be clearly visible with halscope - scope the ddt input, assuming its there, work your way back
let me look at the cmdPos
if its coming out of motor-pos-cmd, how come you didn't see it eariler?
the cmdPos drops from 600m to 0 in one step
cmdPos is the signal driven by pin axis.N.motor-pos-cmd?
just lost connection in the shop again
have you tried setting FF1 to 0 yet?
let's make a game plan and I'll get more data and we can continue tomorrow so you can sleep
how much cat5 do you have laying around?
yeah, was thinking about that
that sounds like a good plan, I'm fading
I think there's a spool in the shed
if you can get the emc box online, it would be an enormous help
I ordered a usb wifi today
you can pastebin messages, and imagebin scope screenshots
yeah, that will help
so what we know is there is a step on the decel
and it's coming from the cmdPos from axis
what was that step, with respect to home state?
hang on, I have to go check
when going to state 18? or 100mS later? or ...?
you only need a position step of 0.0006 to get a 0.6 PID output when FF1=1 (at 1 KHz)
(position or feedback, actually)
ok, this is starting to make sense
it is right at the start of state 17
err - nevermind. position command only for FF
that is right after the setting of the position in state 13
so something is glitching
this is motor-pos-cmd, not joint-pos-cmd, that shows the step?
yes, it is the input to the PID
joint-pos-cmd _should_ show the step, motor-pos-cmd should not
I was wondering exactly how the decision is made as to which command position is output - the free planner position or the coordinated planner position
I'm not looking at joint pos
petev_ just makin sure
the hal file says motor-pos, but let me double check
it is correct
it's motor-pos, unless you changed that very recently ;)
SWPLinux: free mode vs. coord mode... aka manual vs auto/mdi when seen from the GUI
ok guys, I'm fading fast
I had noticed the variables like free_tp_enable and free_tp_active
petev_ if you can get a net connection to that box for tommorrow it would be great
anything you want me to look into for tomorrow?
I should be around all evening tomorrow
SWPLinux: free_tp_enable is set by any code (such as homing) that has changed free_pos_cmd and now wants the planner to start moving
free_tp_active means it is moving (output pos != input pos)
hah, that was my shop connection
that timeout is too long
ok, but all this homing stuff is done in the same "machine state", so auto/manual can't be the only thing deciding the output
(at least, I'd think that the home sequence would all be in the same machine state)
I don't follow
the entire home sequence (and all jogging) is done in free mode
SWPadnos, I think its in free mode the whole time
the free tp is used for jogging too
nevermind - I'll take a look at get_pos_cmds (or wherever the actual pin is updated)
you can only home in manual mode
so this should probably show in the sim, no?
what should show in the sim?
the pos step
cradek posted a scope image hours ago showing that it doesn't happen in sim
yeah, but it's one sample, and he wasn;t zoomed in
believe me, if we could reproduce this, we wouldn't be talking to you
it could be happening, but you only need a 0.0006 change in command pos to get that 0.6 PID output step
maybe he didn't see it
SWPLinux: you're smoking something I think
heh - not tonight, thank you : )
well, somebody is miscommunicating
pete says there is a 0.6 (not 0.0006) change in the POSITION command
not the PID output
at least I sincerely hope he was talking about the position command
right, the PID output was huge
the pid acc change was 3.2K
just a little beyond the limits ;-)
ok, so maybe I should be smoking something tonight ;)
petev_ the code in state 13 only runs once, you could put some rtapi_prints in there...
crap, no you can't
rtapi_print (which uses printk) can't print floats
maybe a conditional and a print?
you can muliply by 1 million and print a long
fake it - manually separate the int and fraction parts, and print them %d.%d ...
just mult by a million
too easy ;)
that covers +/-2000 inches with microinch resolution
I'll type cast it to long and let jmk convert in his head ;-)
only if you print it as a pointer
I'd print the values of every variable accessed in step 13, at the beginning and end of that step
you might want to do a print or two in step 17 too
I wonder if it would happen on the first move after home with home_offset=0 ?
step 18 lasts too long, you'd print a few hundred lines unless you add conditionals
yeah, I think step 17 would be interesting
as it doens't happen if 17 isn't used
17 is always used
I don't think so
it may command a zero length move, but it _is_ used
let me check
state 13 unconditionally transferes to 17
yes, you're right
I'll try and get more data for tomorrow and maybe get the machine on the net
17 delays until the previous move (latch move) comes to a stop (free_tp_active == 0), then waits for the delay
don't want to print during that, it will fill up the buffer
print starting at 1654
did you say you never see it in state 17?
1654 is inside state 17 in my copy of the code
it looks to me like the decel and delay periods should be showing state = 17
duh - nevermindd
petev_: you have a USB memory stick by any chance?
scope screenshot (gimp can do that, its on ubuntu by default) -> USB -> doze box on the net -> imagebin
for tomorrow, I really need to crash now
let me try a capture
how do I use gimp, I have never used it before?
don't bother, just hit print-screen and make up a filename
let me try it
SWPLinux: print-screen prints the whole screen, gimp lets you capture a window
oops - alt-printscreen for just the active window
oh, didn't know about that
no need for gimp
ok, this lame industrial kb has no print screen key
hmm. I'd bet that if you can mount an FTP / website like a filesystem (which I'm pretty sure is possible), you could save the screenshot directly to the web
well, there's gimp ;)
are there any hot keys for linux print screen?
it's probably configurable - one sec
yep - System -> Preferences -> Keyboard Shortcuts
click on the "take screenshot of a window" line, and press the new key combo you want to use
if you need to use gimp... its under graphics... once loaded, File->Acquire->Screenshot, then you can pick single window, whole screen, etc
it opens the shot in a window, SaveAs saves it
trying gimp, the kb shortcut is "print", duh
just change it - to something like ctrl-alt-p
crap, it captured with all the gimp stuff on top
I think there is a "delay for X seconds" option
set it for 5, then click in the scope window so it comes into the foreground
ok, got it
what format does gimp save?
it can save all kinds
png is a good choice
gimp is like photoshop or paintshop pro or whatever...
redefining the window capture key may be a better choice, especially if you're memory constrained on that machine
hmm, pastebin says more than 10% binary, file ignored
use imagebin for images
[05:25:12] <SWPLinux> http://www.imagebin.org
minus the www, I guess
sheesh, I don't know where it put it, I uploaded, but see nothing
is it <256kB?
is there a delay before the site updates?
I don't see it in the 50 most recent posts
I know, or if you search on my nick
hmm. I wonder if they have a problem with the format you saved in
they add the images to a database so they can limit the total number of images and the duration any one is kept
well, it shouldn't be a problem, but one never knows :)
let me log my other machine out of my mailbox and freakin email it
it's about bedtime for me as well - don' t hurry on my account
ok, no problem
thought u might want to see it
I do want to see it, but I'm getting a bit tired. I think I haven't recovered from last week's trip yet
i'm sending it
OK. I'll take a look
u get it?
must be on it's way
it's not in the outbox anymore
256k limit, it silently trashes big ones
it should arrive in a few minutes
it's only 53k
spadnos sover net ??
well, smtp isn't an instant transport ...
wow, something is slow
seems that way
I wish HAL scope could save it's trace info to a file
I think maybe I'll go to bed before 2:00 tonight :)
yeah - that would be an excelelnt thing
then others could zoom, pan, etc.
I think fenn was working on that for a bit, but I'm not sure how far he got
hopefully you will get the email by tomorrow ;-)
good night. I'll take a look then, and maybe we can get to the bottom of the matter in the evening with jmk
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2007-05-03.txt
jepler: did I unwittingly require gtk 2?
cradek: no, I wittingly required it long ago
cradek: but yes, pango is gtk2-only
In my flailing around looking for docs, I saw something that said everything else is obsolete for drawing text
the gtk folks love to label their old APIs obsolete
jepler: that wouldn't be hard to add
accurate velocity in the stat buffer? I would rather have that, than the bad estimate
I'll do the back end
(it'll be in machine units)
so it'll give <dx,dy,dz,da,db,dc> ?
no, dxdydz only
I'm sure that's fine too
but I mean as opposed to just the magnitude of the velocity
oh, no I was doing tangential velocity only, it's very easy
is dx,dy,dz useful for something?
the other thing I'd like to see in halscope is a continuous mode, where the trace goes across the screen as it continuously samples, wiping out the previous trace as it goes
do you know how hard that is?
no, I don't.
magnitude is fine too
ok, (slowly) checking it in
I'll try to figure out how to put it on a hal pin too
did it compile?
let me check that :-)
300 MHz you know
yes it compiles
at first glance emcmotStatus->current_vel seems to work right (I made it a hal param too)
what about in the free planner?
hmm good question
well I know the answer
it shows 0
I suppose I can add it
yeah I knew that much
cradek: with that change the DRO "Vel:" is much better -- the estimate doesn't "wobble around"
does it change when you change displayed units?
yes it shows 1524 (mm/sec) instead of 60 (in/sec) on the long G1s in the splash gcode
does it always go to 0 when you stop?
I saw it stick at nonzero when I hit F1 (I think)
this change I'm working on may fix that
so far it's consistently dropped to 0 at a normal exit (M2)
free mode done
I bet teleop mode is not right
looks like axis won't show velocity when it's showing joint positions
hmmm. will this work for non-trivkins machines?
SWPadnos: free mode won't be right I guess
coord will I think
I haven't looked at the patches - is the vel based on the cartesian motions (pre-kins)?
yes when in coordinated mode
ok, then it shouldn't matter (for coord mode)
cradek: I still don't get a nonzero velocity when I am jogging in cartesian mode, whether on stepper-xyza or scara
cradek, jepler: re velocity during jogs..
if you want that, you'll need to calc it in joint space, not cartesean space
cartesean space doesn't exist in free mode
* jmk2 vanishes
cradek: Jepler: - works cool. Now 15ipm is 15ipm :)
had to run the installed version just to be sure what I was seeing
I did calc it in joint space ... worked for me
oh in cartesian mode with nontrivkins you mean?
err do we call that world mode?
that jmk appearance was odd...
he probably saw the commits, then popped on from his work laptop
I think he sits at work reloading the irc logs all day (hi jmk!)
* alex_joni thinks so too
lots of people reading the logs
cradek: now that my cover is busted.. don
cradek: now that my cover is busted.. don't hold back
wow something happened to the warm weather
did it vanish?
cradek, did you get my emails(2) from last night?
I think so
I caught a step in the pos cmd at the end/start of homing states 13/17
can you reproduce it on one of the sim configs yet?
I don't see it on sim when run on the same model MB
I'm going to try sim on the machine itself
I setup another emc for testing
it's very strange that it happens right when all the offsets are adjusted
the joint-pos-cmd step looks fine, but the one on motor-pos-cmd is not right
hmm, it still doesn't work, wonder what I'm doing wrong
can one of you tell me what obvious thing I'm missing for teleop mode please?
cradek: in teleop there is a vel prescription
why not use that directly?
because it's not the "current" velocity
you mean the requested teleop vector right?
I want it to show the result of all the limits like accel
that doesn't take into account accel phases and all
well it looks right to me, so I'm leaving it :-)
cradek: it also looks right from where I'm looking
alex_joni: I'm convinced it is right - the only unfortunate glitch is that it doesn't work
cradek: details, details
I made sure that COORD_FLAG is false, so it's not the else that keeps it from running
cradek, u still there?
I have loosened up some of the amp limits to get more data
I think the error has something to do with starting position
I can see a negative step to 0 in pos-cmd
then I see a nice 2nd or 3rd order s ramp
so it's wrong for one servo cycle?
so it's like the machine wasn't where emc thought it was before the free mode move started
yes, one cycle step in the output
then a nice ramp as you would expect
the size of the step appears to be somehow related to the switch hysteresis (how long I hold it pressed for)
cool it sounds like you're close to finding it
I don't know about that, but I did get some new info
that code seems overly complicated to me, but it's probably straight forward to jmk
I think I should get this one on the usb stick for jmk to see
yes getting him pictures may be the fastest way to a solution :-)
wtf, now I don't get velocity readout while jogging a trivkins either
motion.current-vel (the hal pin) does work in world mode
it's somewhere later, in task or AXIS
cradek, how are err msgs communicated to the GUI?
I knew that code was right!
_petev: the error nml channel
is there any storage across re-starts of EMC?
not that I know of
after I get a homing error, I will get an err dialog the next time I run emc that says it can't home until the machine is out of estop and on
this is right on startup without even trying to home
so something seems to be left behind from the previous run
this happens with a full exit of the GUI and a re-start
* cradek loans _petev a rubber chicken to wave over the monitor
and the EMC related X apps are still unstable, but none of the other X apps seem to have a problem
it's possible that some buffer is left around for a bit, and goes undetected by the runscript (which tries to find a running instance)
but I don't have any idea how that could be
sure - similar to the problems people have in Windows when they exit a program and the window goes away, but the process is still there
but again, I have no idea of what mechanism might allow that to happen on Linux
I have no idea how the NML stuff is implemented either
I thought on a local connection, it was a direct buffer to buffer copy
SWPadnos: yay, thanks for volunteering to debug it!
I wonder if all the RT stuff is not exiting
EMC doesn't complain about it on the re-start
sure - as soon as I get my big machine working RT again :)
Ok, I think the bug count is rising
I just took the home offsets out to see how far things would get
so the home position is 0 as is the min limit for the axis
due to PID noise the axis read -0.001
so emc says a soft limit has been exceeded
the machine remains on, but you can't move the axis in any mode, even with limits overriden
hmmm. I think that's correct but annoying behavior
so what the hell are you supposed to do?
except that last line
well that's how it is working
(I wrote that before the overriden limits comment)
even the HAL jog inputs don't move it
hmmm. I don't have enough actual machine operating experience to have any useful suggestions
I'm assuming that a coordinate change wouldn't affect that situation
(like the touch-off funciton in AXIS)
I tired MDI, and it at least complained about the soft limit
using manual mode silently ignores you
well I can make moves at full rapid speeds no problem once the machine is homed
well something is strange with the err channel. The min sw err msg seems to be stuck in there and just keeps coming up when emc is started and there is no way to get rid of it. I'm going to try tkemc and see if there is any difference
tkemc had no problem and did not display the err msg, so it must be something in the axis nml interface
hmmm. it looks like switching to perspective mode in the AXIS preview uses the "original" viewport size to calculate scaling
or something like that
you know how when you go from an orthogonal mode to perspective, by middle-dragging the preview, the scale changes
it's a bit craptacular
if I do that with axis at its minimum size, I get a preview plot that's N pixels wide
I get what looks like the same N pixels wide when I maximize the window to 1920x1100-ish
the P and Z toolbar buttons work fine, it's the middle-drag perspective change that does this
I think it only auto scales/centers when you use the icons or switch the view to "P" with the keyboard
please feel free to fix, I'm not sure what it should do exactly
I'm reasonably sure of what I'd like (sort of), but I have no idea how to fix it :(
I think I looked through that code some months ago, and the perspective scaling is done in a library call, and I haven't delved into the libraryyet