Back
[00:00:08] <cradek> did you ever reproduce pete's problem?
[00:00:39] <SWPLinux> no, I can't jog his setup - I think I need to add integrators to the PID output to simulate velocity mode (or something like that)
[00:00:50] <SWPLinux> err - I can't even jog that setup ...
[00:00:54] <petev_> cradek, my bug list is getting huge, I don't even know where to start
[00:01:11] <petev_> after just ignoring the homing issue and taking the offsets out for now
[00:01:12] <cradek> oh hi, didn't mean to talk about you like you weren't here
[00:01:20] <petev_> I keep finding more issues
[00:01:22] <cradek> start at the top?
[00:01:39] <petev_> it seems that you can't jog all the way to the limits in the INI file
[00:01:43] <cradek> that's great - we can use the testing
[00:01:52] <cradek> that's right, you can't jog exactly to a soft limit
[00:02:01] <SWPLinux> actually, I'm about to run for a couple of hours. hopefully I can catch up when I get back (or everything will already be fixed ;) )
[00:02:05] <petev_> and if the machine is too close to one of these limits, the HAL jog pins don't work at all
[00:02:31] <petev_> the distance from the soft limit seems random, it's different on each axis
[00:02:41] <petev_> and why can't you jog right to the limit?
[00:02:43] <cradek> petev_: it's a certain percentage of the axis travel, I think
[00:02:51] <cradek> probably too high a percentage
[00:03:09] <petev_> that seems stupid, I want the limit where I tell it to be, not some other calculated place
[00:03:12] <jmkasunich> hi guys
[00:03:16] <petev_> that's just plain confusing
[00:03:20] <cradek> because rounding would let you pass them by a tad sometimes, and it was irritating
[00:03:22] <cradek> hi jmk
[00:03:29] <petev_> and if the machine is too close, then the jog doesn't even work
[00:03:54] <jmkasunich> I wasn't thrilled with the percentage solution either (I'm the guilty party), but it was the best I could come up with at the time
[00:03:57] <cradek> petev_: how do you get it there? by setting home position to somewhere you couldn't normally jog to?
[00:04:00] <petev_> I find it more irritating not knowing where they are, and getting stuck after a home
[00:04:08] <petev_> yes, with home
[00:04:19] <cradek> ok, that will go away when you/we fix homing
[00:04:29] <jmkasunich> so your home position is exactly at the edge of the soft limits?
[00:04:37] <petev_> no, I took the offset out, and the home works fine
[00:04:52] <petev_> I can set my soft limit at -0.001 and home to 0
[00:04:58] <petev_> then the machine won't be able to jog
[00:05:01] <cradek> oh ok
[00:05:03] <petev_> that is just broken
[00:05:11] <cradek> yeah it should give you an error if nothing else
[00:05:21] <petev_> it just ignores you in manual mode
[00:05:35] <petev_> MDI mode comlains with an err msg
[00:05:41] <petev_> complains
[00:05:49] <jmkasunich> the problem is, if we let you got right up to _any_ limit, then roundoff error can take you over the limit, and you get stuck
[00:05:50] <petev_> jmk, I got some new data for you
[00:05:59] <jmkasunich> you are well aware of how its not nice to be stuck
[00:06:24] <petev_> yes, but I set my soft limits 0.050 past that motion range I wanted
[00:06:28] <jmkasunich> (roundoff error, overshoot, any number of things)
[00:06:29] <cradek> jmkasunich: it would be nice if it were a few counts/steps instead of a few %
[00:06:34] <petev_> and got stuck well before that
[00:06:39] <jmkasunich> PGA ;-)
[00:06:44] <petev_> the limit should be were the user says it is
[00:07:06] <jmkasunich> pete: I agree a few percent sucks, but it can't be where you want it
[00:07:15] <jmkasunich> for reasons that both cradek and I have explained
[00:07:24] <petev_> sure it can, the limit should never be hit, it's a limit
[00:07:40] <petev_> I will set it a bit past where I want the machine to go
[00:07:52] <cradek> if the limit is zero, and zero should never be hit, what's the minimum number you should be able to jog to?
[00:07:56] <petev_> if my machine will hold tenths, I can set it 1 thou past, etc.
[00:08:18] <petev_> cradek, I don't follow
[00:08:25] <petev_> if I want to be able to move to 0
[00:08:28] <jmkasunich> if you set it 1 thou past, then EMC will let you jog 1 thou past
[00:08:33] <petev_> and my machine will hold tenths
[00:08:42] <petev_> I'll set the soft limit to -0.001
[00:08:45] <jmkasunich> are you reading what we say?
[00:08:49] <petev_> then I should have no problem
[00:08:51] <petev_> yes
[00:09:06] <jmkasunich> if you set it to -0.001, then emc will let you jog to -0.001, and you'll have the roundoff->stuck problem
[00:09:24] <petev_> but I should never hit -0.001
[00:09:28] <jmkasunich> why not?
[00:09:35] <petev_> if I do, I'm fine with overriding the limit to get off of it
[00:09:46] <petev_> because I only want the machine to move to 0.000
[00:09:54] <cradek> override limits doesn't override soft limits
[00:10:01] <petev_> it's program bug, or operator error to go past it
[00:10:02] <jmkasunich> if you only want the machine to move to 0.000, then you set the limit to 0.000
[00:10:17] <petev_> if you do that, you can't move to 0.000
[00:10:22] <petev_> that's the whole problem
[00:10:32] <jmkasunich> we're talking past each other
[00:10:52] <jmkasunich> I'm perfectly aware that it won't go to the limit AS WRITTEN
[00:10:54] <petev_> try setting your limit to 0.000 and then jogging there, you can't
[00:11:04] <cradek> yes we all know that
[00:11:04] <jmkasunich> you are saying it should let you go to the limit
[00:11:08] <petev_> so what are you suggesting then?
[00:11:16] <petev_> changing the code?
[00:11:20] <jmkasunich> and I'm trying to splain why that lets you lock it up
[00:12:02] <jmkasunich> there has to be some distance between "where it will let you go" and "where it says you are on limit and won't let you go back"
[00:12:13] <jmkasunich> the current distance is IIRC 1% of the axis range
[00:12:14] <petev_> so what do you set your limits to if you want to be able to move you X axis from 0.000 to 18.000 ?
[00:12:20] <jmkasunich> I won't defend that choice
[00:12:24] <jmkasunich> but you got a better suggestion?
[00:12:48] <petev_> yes, let it lock up if a limit is hit, and make the limit overrid overrid soft limits
[00:13:05] <petev_> then the integrator can leave a few thou tolerance, or whatever the machine requires
[00:13:07] <cradek> the point of soft limits is to not 'lock up'
[00:13:19] <petev_> now, he doesn't even know where the real limit is
[00:13:33] <petev_> cradek, why? It's a limit, let it lock up
[00:13:49] <petev_> how is the soft limit different than a hard limit?
[00:14:09] <cradek> hitting a hard limit means there was a malfunction
[00:14:16] <petev_> I thought it's there for machines without hard limits, or when you want to stay within a fixture area, etc.
[00:14:18] <cradek> soft limits gracefully keep you off the hard limits
[00:14:35] <petev_> soft limits should be treated the same as hard IMHO
[00:14:43] <petev_> it's an error to hit a limit period
[00:14:44] <jmkasunich> actually, no
[00:14:44] <cradek> I disagree vehemently
[00:15:07] <petev_> the way they are now, they are useless
[00:15:15] <cradek> why should you be able to jog into a soft limit and get an error? the program can prevent it
[00:15:19] <jmkasunich> even if we accept your "let them hit it, and then do whatever to get off" premise (I'm more open to that) thats still not the same as hard limits
[00:15:21] <petev_> you don't even know where you can move to
[00:15:43] <petev_> by the same, I mean behavior wise
[00:15:44] <jmkasunich> pete, you are repeating yourself
[00:15:54] <jmkasunich> I KNOW that it makes it confusing
[00:16:01] <cradek> jmkasunich: do you know the machine resolution at this level? could you make it a few counts/steps instead of a percentage?
[00:16:03] <petev_> so what is the intended purpose of a soft limit?
[00:16:14] <jmkasunich> cradek: no, position is a float
[00:16:19] <petev_> cradek, I think that depends on the machine
[00:16:20] <cradek> to stop travel before you get to the hard limit
[00:16:30] <petev_> some may hold tighter tolerance than others too
[00:16:45] <jmkasunich> you mean PID accuracy?
[00:16:47] <cradek> for jogging and a program run both
[00:16:54] <petev_> jmk, yes
[00:17:06] <petev_> cradek, what is your view of a hard limit?
[00:17:16] <petev_> is that the point of damage?
[00:17:20] <cradek> I've answered the questions already
[00:17:40] <cradek> if a hard limit is ever hit, it means the machine malfunctioned or is misconfigured
[00:17:48] <jmkasunich> hard limit = a limit that causes a fault, and shuts down the machine
[00:18:00] <petev_> and a soft limit?
[00:18:07] <petev_> no fault?
[00:18:11] <jmkasunich> soft limit = a limit that keeps you from hitting the hard limit, and does not fault the machine
[00:18:17] <cradek> no fault
[00:18:39] <jmkasunich> part of the problem IMHO is that we have a truly sucky fault mechanism
[00:19:17] <cradek> jmkasunich: is there a way to tell what the next biggest/smallest representable float value is?
[00:19:20] <jmkasunich> you can fault the machine without the GUI popping up an error dialog, and you can pop an error dialog without faulting the machine,
[00:19:24] <petev_> so why do they need to be treated differently? Is it not an error to hit a soft limit?
[00:19:44] <jmkasunich> petev_: the whole purpose of soft limits is to NOT fault the machine
[00:19:58] <petev_> maybe 2 things are mixed here
[00:20:04] <jmkasunich> if you lean on the jog key, you want the machine to jog to end of travel and stop, not fault out
[00:20:11] <petev_> I thought the limits in the INI let EMC know how big the machine was
[00:20:26] <petev_> that way the traj planner can be smart and not hit a limit at ballistic speed
[00:20:39] <petev_> but it sounds like they are trying to serve 2 purposes
[00:20:57] <petev_> maybe there needs to be another set of params for the axis sizes
[00:21:01] <jmkasunich> they don't even do a perfect job of the first purpose
[00:21:30] <petev_> for the first purpose you can set them to +/- infinity and be done with them
[00:21:40] <jmkasunich> in auto/mdi mode, a G0/G1 that would take you outside the limits causes an error I believe
[00:21:44] <petev_> but you can't do that if they are being used by the traj planner
[00:21:49] <cradek> it's definitely true that you don't have to use soft limits
[00:21:53] <jmkasunich> a G2/G3 with an endpoint outside the limits will too
[00:21:55] <cradek> maybe that's what you want
[00:22:11] <petev_> but I want the traj planner to be able to know the axis sizes
[00:22:13] <cradek> jmkasunich: limits are checked when submitting the move, and also when moving
[00:22:13] <jmkasunich> but a G2/G3 that swings outside the limits and back in won't be detected by the TP
[00:22:20] <petev_> and it seems like that is overloaded on the soft limits
[00:22:29] <cradek> the first check is imperfect for arcs like you say
[00:22:35] <cradek> the second check always works
[00:22:49] <jmkasunich> second check = the one while executing the move?
[00:22:52] <cradek> yes
[00:23:11] <jmkasunich> if you are going fast, that check won't attempt to stop until you reach the limit, right?
[00:23:24] <cradek> hm maybe not, I'm not sure
[00:23:29] <cradek> maybe it's not perfect then
[00:23:43] <cradek> I'm pretty sure it does stop, but you're right that it would be slightly past the limit
[00:24:12] <jmkasunich> anyway, I think we can accept that g-code which goes outside the soft limits should cause an error, not just be silently truncated
[00:24:26] <jmkasunich> jogs OTOH, if they go outside the limit, they are truncated, with no fault
[00:24:40] <petev_> ok, so why not let a jog go to a soft limit, and move off of it, without getting stuck?
[00:24:47] <jmkasunich> otherwise you could never manually jog up to the limit, you'd be bound to overshoot and fault it
[00:25:06] <petev_> have a separate param for the traj planner to tell it the axis lengths
[00:25:27] <petev_> you can have a second param for the soft limits, that is the error margin
[00:25:39] <petev_> anything within margin is not an erros
[00:25:41] <petev_> error
[00:25:51] <petev_> then the integrator knows where the limits are
[00:25:55] <jmkasunich> I think I agree that you should be able to jog right up to the limit
[00:26:06] <petev_> and can disable soft limits without foobarring the traj planner
[00:26:10] <jmkasunich> and get off of it again without jumping thru hoops
[00:26:18] <petev_> right
[00:26:34] <jmkasunich> but there is a lot between "should" and "can"
[00:27:10] <petev_> right now you can't really disable soft limits, or the traj planner has no idea how large the axis is
[00:27:19] <petev_> that's a real problem
[00:27:29] <jmkasunich> I don't follow you
[00:27:32] <cradek> I don't either
[00:27:45] <jmkasunich> why do you want to disable the soft limits
[00:27:53] <petev_> how does the traj planner know the axis length, other than soft limits?
[00:28:04] <jmkasunich> and if you are doing that, why does the tp still need to know axis length
[00:28:13] <petev_> because I don't like the way they behave, and they are serviing two purposes
[00:28:20] <jmkasunich> no they are not
[00:28:24] <cradek> the purpose is to keep you off the limit switches
[00:28:38] <cradek> I don't know why you want to disable that in any situation
[00:28:41] <petev_> if the tp doesn't know the axis length, it may make a ballistic move outside of the range
[00:28:50] <petev_> and it won't be able to stop in time
[00:28:51] <cradek> and so could you, by jogging
[00:28:55] <jmkasunich> they tell the TP how to stay off the limits, they tell jogging how to stay off the limits - same purpose
[00:29:47] <petev_> one limit is the hard limit, that one needs to be obeyed by the tp
[00:30:26] <petev_> the soft limit can be anywhere the user wants, and shouldn't need to be considered by the tp, other than to stop if it is going past one
[00:30:34] <jmkasunich> petev_: tp can't obey hard limit
[00:30:39] <jmkasunich> hard limit is a switch, not a number
[00:30:40] <petev_> why?
[00:30:54] <jmkasunich> the tp has no clue how close to the hard limit it is until it trips
[00:31:03] <petev_> yes, but there should be a number that tells it the location of the switch, or at least close to it
[00:31:16] <cradek> yes that's the soft limit!
[00:31:17] <petev_> that's what the soft limit gets used for now
[00:31:17] <jmkasunich> the soft limits exist because they are a number, not a switch, and can be used to actually LIMIT things, as opposed to tripping off
[00:31:30] <petev_> cradek, that's the dual purpose and why it's a pain
[00:31:43] <cradek> you still haven't explained the dual purpose thing
[00:31:51] <jmkasunich> that what the soft limits are SUPPOSED to be used for, its not a dual purpose, its their only purpose
[00:31:53] <cradek> the SINGLE purpose is to keep the machine from hitting a limit switch
[00:31:59] <petev_> 1) where are the hard limits for tp
[00:32:14] <petev_> 2) the user wants some soft limits to limit his motion
[00:32:52] <cradek> ok you want an additional thing #2, we don't have it
[00:32:54] <jmkasunich> when you talk about 2, are you talking about limiting workspace to something significantly less than the overall machine workspace?
[00:33:08] <petev_> possibly
[00:33:11] <cradek> (fwiw I'd like that too)
[00:33:16] <petev_> if that's what the user wants
[00:33:22] <jmkasunich> that is not and was never the intent for soft limits - they are strictly to "guard" the hard limits
[00:33:34] <cradek> that's a separate problem though, and is a feature request, not a bug
[00:33:35] <petev_> maybe he has his rotary table on one end of the table and doesnb't want to hit it
[00:33:48] <petev_> well that's what I thought soft limits were
[00:33:48] <jmkasunich> I agree that your #2 would be a nice feature, but you are the only one who thinks that is the intent of the existing soft limits
[00:34:08] <petev_> and the bug is they are really telling the tp where the hard limit is, but they don't let you get near it
[00:34:38] <jmkasunich> I've admitted that the 1% rule sucks
[00:34:48] <petev_> so for #1, there needs to be some error tolerance param for the soft limit
[00:34:57] <jmkasunich> IIRC, that fix went in at the last workshop, under time pressure, to fix somebody's problem
[00:35:23] <cradek> I wish we could figure out the smallest possible number that keeps you off the soft limit, and maybe we can
[00:35:35] <cradek> I think that's the way it has to work though.
[00:35:37] <jmkasunich> my preferred implementation for soft limits would let you move right up to the limit, and then would prohibit further movement ONLY in the wrong direction
[00:35:41] <petev_> I know that will be machine dependant
[00:35:46] <jmkasunich> while still allowing movement back into the workspace
[00:35:55] <petev_> jmk, agreed
[00:36:03] <cradek> yes we all agree that would be ideal
[00:36:06] <jmkasunich> but thats a lot easier to say than to do
[00:36:28] <petev_> the only problem is the error tolerance, so just add a second param
[00:36:28] <jmkasunich> there is still a crapload of (IMHO) crufty global state stuff in the motion controller
[00:36:34] <jmkasunich> and its really hard to manage it all
[00:36:39] <petev_> agreed
[00:36:44] <petev_> gave me a headache
[00:36:54] <cradek> I think the error tolerance is not related to the machine, it's related to the position precision, which is a float
[00:36:55] <petev_> I don't even understand 1% of it ;-)
[00:37:06] <petev_> no, it's PID related too
[00:37:10] <petev_> I can tell you that
[00:37:27] <cradek> how close your machine holds the commanded position is irrelevant to what the limit of commanded position should be
[00:37:36] <petev_> if I let the drives control my motors, I can hold tigher position than with emc right now
[00:37:41] <cradek> if it has a foot of slop you just set the limit accordingly
[00:37:59] <petev_> not if you want to be able to move right up to the limit
[00:38:15] <petev_> if the PID is bouncing around, you will exceed the limit
[00:38:29] <petev_> so there has to be some error tolerance
[00:38:41] <petev_> or how do you define violating a soft limit?
[00:40:00] <jmkasunich> cradek: at present, I believe soft limits are applied to feedback, not command
[00:40:04] <jmkasunich> so it is relevant
[00:40:11] <petev_> yes, they are
[00:40:12] <cradek> oh, ok
[00:40:24] <jmkasunich> unless we decide the limits should apply to command, which might actually be the Right Thing
[00:40:40] <petev_> yes, that might be a clean solution
[00:41:49] <jmkasunich> I think that is a key issue.... because I was thinking of soft limits as "software limit switches" I applied them to feedback... (emc1 did too)
[00:42:04] <petev_> jmk, how hard is it to change?
[00:42:06] <jmkasunich> bit if we think of it as limiting the command, then it gets much cleaner
[00:42:12] <petev_> yes, much
[00:42:14] <jmkasunich> I'd have to look
[00:42:45] <petev_> ok, take a look at the hal scope capture I just emailed you
[00:42:53] <jmkasunich> just did
[00:43:00] <petev_> I loosened things up in the drive to get more info
[00:43:20] <petev_> the green trace is the motor pos cmd
[00:43:24] <jmkasunich> that step is plainly wrong
[00:43:27] <petev_> red is the state
[00:43:33] <petev_> but look at the nice move after that
[00:43:47] <petev_> it's like the start pos was wrong or somethin
[00:43:51] <jmkasunich> the nice move after that is the norm for the free mode traj planner
[00:44:00] <petev_> right
[00:44:16] <petev_> and the third trace (flat line) is the joint-pos-cmd
[00:44:34] <petev_> it is not changing here, as this is the final home move
[00:44:39] <jmkasunich> and you can make this happen at will?
[00:44:43] <petev_> yes
[00:44:48] <petev_> all the time
[00:45:02] <jmkasunich> something you just said confuses me
[00:45:18] <jmkasunich> joint-pos-cmd and motor-pos-cmd are at the same scale in that pic?
[00:45:34] <petev_> no, I don't think so
[00:45:47] <petev_> I expaded the motor pos to see it better
[00:46:03] <jmkasunich> there is NFW that motor-pos-cmd should be able to do a nice s-ramp without joint-pos-cmd doing the same thing
[00:46:38] <jmkasunich> btw, I saw you say this afternoon that scope should be able to save the actual data so someone else can zoom, select channels, etc
[00:46:40] <petev_> hmm, I don't think it had the same ramp on it, but I can't be sure
[00:46:40] <jmkasunich> I agree 150%
[00:46:45] <petev_> I can get another capture
[00:47:11] <jmkasunich> unfortunately, writing scope about killed me, there's no way I could go back and make that radical a change
[00:47:19] <petev_> I think that was actually late last night with SWP
[00:47:29] <jmkasunich> some log I was reading back...
[00:48:21] <jmkasunich> uh, that step change is NOT happening in state 12
[00:48:34] <petev_> let me see if I think it's state 13
[00:48:41] <petev_> but 13 doesn't show in hal scope
[00:48:52] <petev_> so the previous state is 12
[00:48:52] <jmkasunich> trigger level is 15.24, and its just a hair above the 3rd div
[00:49:02] <petev_> but the display probably looks like 15
[00:49:01] <jmkasunich> zero is the center div
[00:49:09] <jmkasunich> so you are at 5 per div
[00:49:17] <jmkasunich> and you were at 15 for a LONG time before the step
[00:49:25] <petev_> yeah, the trigger is high, but I have run it lower and it goes state 12,17,18
[00:49:31] <jmkasunich> you are homing to index in this trace, NOT to the switch
[00:49:44] <cradek> http://timeguy.com/cradek-files/emc/steps.png
[00:49:52] <petev_> yes, this was the X axis, and the index was still on
[00:50:04] <jmkasunich> the step is expected when index is on
[00:50:29] <cradek> reload steps.png - I moved a trace to make it clearer
[00:50:37] <cradek> I get steps in joint-pos but not motor-pos
[00:50:58] <petev_> ok, let me turn index off on X and capture again
[00:51:01] <jmkasunich> the encoder and thus the feedback resets to zero when it hits the index, so EMC needs to reset the command to zero to keep the PID from going nutz
[00:51:20] <petev_> well I still got a vel error in the amp on that trace
[00:51:35] <jmkasunich> could be, but we have to deal with one thing at a time
[00:51:39] <petev_> so something wasn't right, but maybe I zoomed in on the wrong area
[00:51:48] <petev_> yes, I'll turn index off
[00:51:50] <cradek> petev_: update so you get your traces labeled
[00:51:58] <petev_> hal scope?
[00:52:13] <jmkasunich> cvs up, and build
[00:52:20] <petev_> ha ha
[00:52:23] <jmkasunich> all of emc, not just scope
[00:52:24] <petev_> it's still not on the net
[00:52:28] <petev_> but I'll update it
[00:52:33] <jmkasunich> fsck, that would drive me insane
[00:52:47] <jmkasunich> a linux box that isn't on the net is only half a computer
[00:52:48] <cradek> * cradek sends petev_ a network cable
[00:53:04] <jmkasunich> all your software comes from the net
[00:53:44] <cradek> hmm I'm trying to remember if I ran cat5 to the barn when I ran 220 - I'm a moron if not
[00:54:01] <cradek> I'll find out when I get a mill :-)
[00:54:41] <cradek> jmkasunich: is my plot what you expect, with steps on joint but not motor?
[00:54:50] <petev_> cradek, I ordered a usb wifi, just not here yet
[00:55:59] <jmkasunich> cradek: yes
[00:56:09] <jmkasunich> thats homing to switch, not index, right?
[00:56:32] <cradek> right
[00:56:37] <cradek> no simulated index
[00:56:44] <jmkasunich> short dissertation on steps during homing:
[00:56:48] <cradek> we could probably do that (somehow)
[00:57:15] <cradek> jmkasunich: 'sokay, I can look at the code
[00:57:26] <jmkasunich> joint-pos-cmd is assumed to be wrong, thats the reason you are homing.... so at some point(s) it MUST step to get to the right value
[00:57:39] <roltek> i am a little late here but pete v is wright a soft limit as actually a hard limit
[00:58:01] <jmkasunich> if homing to switch only, the encoder or other feedback will never reset itself, no step change
[00:58:28] <jmkasunich> the code in state 12 is responsible for stepping joint-pos-cmd without stepping (disturbing) the motor
[00:58:56] <jmkasunich> if you DO have an index, then the motor feedback is going to step to zero when the encoder resets on index
[00:59:08] <jmkasunich> and motor-pos-cmd has to make the same step to avoid the PID going nutz
[00:59:22] <cradek> ok
[00:59:33] <cradek> so error stays the same
[00:59:46] <jmkasunich> unfortunately even if cmd and fb step at the same time, and error is never large, the FF1 term (derivative of command) does have a big spike
[01:00:00] <jmkasunich> that might be what pete is seeing
[01:00:09] <cradek> I thought he turned it off
[01:00:21] <cradek> several people suggested that I think
[01:00:24] <jmkasunich> I thought he turned index off too, but he posted a trace with it on
[01:00:34] <cradek> arg
[01:00:55] <jmkasunich> I think hes doing a whole lot of differnt things, and we don't know what is in effect for any given trial
[01:06:19] <petev_> so what conditions do you want? I will test an axis with index off
[01:06:27] <petev_> anything special on PID or whatever?
[01:06:39] <jmkasunich> nope, same as the test you just did
[01:06:50] <cradek> do whatever you need to do to show the error
[01:06:50] <petev_> but without index?
[01:06:57] <jmkasunich> if there is still a step when index is off, then something is wrong
[01:07:03] <petev_> it shows on anything with HOME_OFFSET != 0
[01:07:23] <jmkasunich> ok, do it with HOME_OFFSET != 0 then
[01:08:52] <jmkasunich> btw, the current soft limit margin is 0.1%, not 1%
[01:26:58] <petev> ok, I'm wondering if we need to back up a few steps here
[01:27:24] <petev> the last 2 captures, I had emc exit by itself while manipulating the hal scope capture
[01:28:04] <petev> maybe there is something basic wrong here, although this install ran for months via X to my doze box without issue
[01:28:15] <cradek> you're sure gonna have to figure that out
[01:28:22] <petev> do you think there is any issue witht the X server?
[01:28:30] <petev> none of the other X apps have ever exited
[01:28:38] <petev> even when the emc X apps do
[01:28:42] <tomp> i thought i saw that happen to me also, changing zoom on a stopped view... but chalked it up to me
[01:28:45] <petev> they are still running and fine
[01:28:45] <cradek> I could only guess
[01:29:05] <petev> tomp, it has happened too many times now to me
[01:29:13] <petev> I though the same thing the first couple of times
[01:29:34] <petev> cradek, what X tests would be good to run to check things?
[01:31:23] <cradek> petev: halscope exited or all of emc exited?
[01:31:47] <cradek> check the .xsession-errors log again and see what they said
[01:32:00] <petev> I have had both happen
[01:32:12] <petev> when just hal scope gui exits, the rest of emc stays loaded
[01:32:23] <petev> when emc gui exits, everything goes with it
[01:32:31] <jmkasunich> the latter is expected
[01:32:53] <jmkasunich> when the GUI shuts down, that transfers control back to the main runscript, which assumes you shut it down and does normal cleanup
[01:32:56] <cradek> right everything should exit
[01:33:09] <cradek> what video card is this? is it software rendering?
[01:33:17] <cradek> I suspect you have not run any other opengl app
[01:33:36] <petev> no, haven't tired any other opengl apps
[01:33:44] <petev> but I was running tkemc this time
[01:33:54] <petev> hal scope isn't opengl, is it?
[01:34:14] <petev> the video is buillt in to the chipset
[01:34:30] <cradek> hm
[01:34:37] <cradek> so it's not that
[01:34:44] <cradek> what's in the log?
[01:35:07] <petev> it's booting now, just gave it more frame buffer mem
[01:35:17] <tomp> i just had halscope dissappear when changing zoom on stopped trace... checking vid now... nVidia Corporation NV18 [GeForce4 MX 440 AGP 8x] (rev c1) (prog-if 00 [VGA])
[01:35:28] <cradek> it's one of those things that share video ram with system ram?
[01:35:34] <petev> yes
[01:35:51] <cradek> I strongly suggest you turn that off and plug in a video card
[01:35:54] <tomp> no shared on mine, pci card
[01:36:09] <petev> only one PCI slot and the motenc is in it
[01:36:15] <cradek> I'm very surprised you don't get realtime problems
[01:36:21] <petev> none
[01:36:39] <petev> I have used these boards a lot on multimedia stuff and haven't had issues
[01:36:59] <jmkasunich> have you run the RTAI latency test on that machine?
[01:37:08] <petev> no
[01:37:09] <tomp> yep
[01:37:15] <petev> I should quallify that none
[01:37:31] <petev> I did see a problem once when plugging in a USB stick
[01:37:39] <petev> but that's the only time
[01:37:47] <petev> and it was very correlated
[01:37:56] <petev> I assumed it was some ugly kernel ISR
[01:38:02] <cradek> I'm very surprised you're not having trouble
[01:38:05] <tomp> 14000 worst case, after hours of fiddling, never 'unexpected' message
[01:38:37] <petev> I have another test setup I built the other day on the same MB
[01:38:42] <cradek> petev: how much system ram?
[01:38:42] <petev> I'll run the RT test on it
[01:38:48] <petev> 256MB
[01:38:54] <tomp> (doh never ran emc, ignore the 'unexpected' bit)
[01:38:54] <petev> was using 16MB for video
[01:38:58] <petev> upped it to 32MB
[01:39:17] <jmkasunich> did you invoke halscope from a shell?
[01:39:35] <jmkasunich> if so, what anything printed to that shell?
[01:39:58] <petev> I invoked it from the GUI
[01:40:17] <petev> I get the EMC error dialog, which I posted a few weeks ago
[01:40:22] <jmkasunich> next time invoke it from a shell, so stdout and stderr don't go into the bitbucket
[01:40:30] <cradek> they may go to .xsession-errors
[01:40:35] <cradek> but yeah, use the shell
[01:40:35] <petev> only suspicious thing was some unexpected X server disconnect
[01:40:58] <cradek> I don't trust your motherboard for one second :-/
[01:41:37] <jmkasunich> I have some vague memories if chasing really weird problems with you before.... a long time ago, at LEAST a year
[01:41:52] <jmkasunich> was that you, or am I mixing you up with somebody else?
[01:42:00] <petev> yeah, but then that floating point bug was found
[01:42:00] <cradek> do you have a normal machine with several slots you could try instead?
[01:42:07] <petev> and it appeared to be the culprit
[01:42:11] <jmkasunich> whoever it was, we spent HOURS trying to reproduce it on my machine
[01:42:28] <petev> not a normal machine, I have an old dual processor box
[01:42:37] <cradek> P2 or P3?
[01:42:50] <petev> pretty sure it's P3
[01:43:05] <cradek> great
[01:43:12] <petev> it's the big clamshell thing
[01:43:17] <petev> they are huge
[01:43:24] <cradek> mine's bigger :-)
[01:43:37] <petev> I used to have one with 6
[01:43:41] <petev> it was a boat anchor
[01:43:41] <cradek> mine's bigger than the mill it controls
[01:43:43] <cradek> haha
[01:43:59] <cradek> 6 P3s?
[01:44:46] <petev> no, I think they were pentium Pros
[01:44:50] <petev> old stuff here
[01:44:59] <cradek> cool still
[01:45:10] <cradek> I've only seen quad Pro boards and those were impressive enough
[01:45:25] <petev> I have stressed these VIA boards a lot with a non RT patched kernel
[01:45:33] <petev> can't vouch for a patched one
[01:45:40] <cradek> I have no doubt they're fine without rtai
[01:45:54] <jmkasunich> RTAI brings out the worst in computers
[01:46:24] <cradek> yeah you have to pick the computer kind of carefully, and yours is possibly not a good pick
[01:46:27] <petev> what about tomp's config?
[01:46:35] <petev> I don't see anything in the xlog
[01:46:39] <cradek> not enough information to guess
[01:46:39] <petev> will check xsession
[01:48:11] <petev> the xsession has the gdk errors you said were normal, and a complaint about the sound driver already running or a stale socket
[01:48:17] <petev> nothing that looks real bad
[01:48:29] <cradek> nothing from emc then
[01:48:32] <petev> I'll start emc from a terminal
[01:48:34] <cradek> run from shell from now on
[01:48:37] <petev> no, nothing from emc
[02:03:27] <petev> ok, I have a capture with the cmd accel exceeding the limits
[02:03:34] <petev> but it is not obvious why
[02:03:50] <jmkasunich> cmd from motion, or after the PID?
[02:04:42] <petev> before pid, ddt on motor-pos-cmd
[02:04:57] <jmkasunich> two ddts if its accel
[02:05:15] <petev> yes, I will double check HAL file now to be sure
[02:05:17] <jmkasunich> can you post it somewhere?
[02:07:15] <petev> yeah, what format will imagebin take?
[02:07:24] <petev> I tried png yesterday with no luck
[02:07:59] <petev> should I try gif?
[02:08:07] <jmkasunich> can't hurt
[02:08:11] <petev> ok
[02:08:21] <jmkasunich> I haven't used imagebin myself, I have a local webserver
[02:11:44] <petev> much better, I guess it doesn't like png and siletntly ignores you
[02:11:45] <petev> http://imagebin.org/8458
[02:12:10] <jmkasunich> I thought you were gonna update?
[02:12:58] <jmkasunich> anyway... what are the channels in that pic
[02:13:05] <petev> I did update
[02:13:04] <jmkasunich> (the update would have labeled them)
[02:13:12] <petev> I tared a cvs up
[02:13:19] <petev> was everything checking in?
[02:13:29] <petev> #1 is the home state
[02:13:49] <petev> #2 is joint-pos-cmd
[02:14:00] <petev> #3 is motor-pos-cmd
[02:14:12] <petev> #4 is ferrored
[02:14:21] <petev> #5 is accCmd
[02:14:40] <petev> the INI file limit is 20
[02:14:45] <petev> and it's on 20/div
[02:14:55] <petev> you can see the first spike is off the screen
[02:15:04] <petev> and there are plenty above 40
[02:15:20] <petev> or above 20 and near 40
[02:15:22] <cradek> but is that after it ferrored?
[02:15:32] <jmkasunich> the big one (and all after that) are side effects of the ferror
[02:15:38] <petev> let me zoom in
[02:15:56] <jmkasunich> once you error out, the command is forced to track the feedback (so that you can restart smoothly
[02:16:12] <jmkasunich> so there is a big step when you error out, then bouncing as the axis comes to a halt
[02:16:49] <petev> well I wonder if the one from last night wasnt't the same thing and we just weren't looking at ferror?
[02:16:51] <petev> let me open it
[02:17:03] <petev> this one appear to happen on the same cycle
[02:17:20] <petev> a huge negative spike, then huge positive
[02:17:27] <jmkasunich> this is well into the "state 18" move
[02:17:50] <jmkasunich> I think your PID and/or drive just isn't keeping up with that move
[02:17:56] <petev> BTW, the machine will make G0 moves the full axis length after homing without error
[02:18:02] <jmkasunich> the accel is within spec up till that point
[02:18:15] <cradek> petev: a short G0 move is harder than a long one
[02:18:15] <jmkasunich> you should probably do again and capture velocity
[02:18:20] <jmkasunich> make sure its in spec too
[02:18:31] <petev> can do
[02:18:40] <petev> let me open that pic from last night
[02:18:54] <jmkasunich> I bet the error is happening when it goes from max accel to max decel
[02:19:00] <cradek> right, this G0 move is not long enough to cruise
[02:19:05] <jmkasunich> (that move is short enough that it has no cruise phase)
[02:19:07] <jmkasunich> ;-)
[02:19:12] <petev> that could be
[02:19:26] <cradek> this looks like a basic tuning problem so far
[02:19:48] <cradek> I thought you were going to open up ferror limits a bit - did you ever try that?
[02:20:12] <petev> no ferror on the trace from last night, but it happened much sooner at the 12/17 transition
[02:20:32] <petev> I opened up the drive limits, let me open up emc too
[02:20:48] <petev> do u have the pic from last night?
[02:21:18] <jmkasunich> not handy
[02:21:33] <cradek> I have homeError2 but it looks completely different
[02:21:47] <petev> the decel/accel looks similar, so maybe it ferrored at a different spot
[02:21:58] <petev> cradek, the first was just homeError.png
[02:22:09] <petev> #2 was on X axis and was totaly different
[02:22:36] <petev> ok, let me add PID output and vel
[02:22:41] <petev> and open emc limits
[02:22:55] <cradek> I can tell you now that pid is saturating
[02:23:09] <cradek> well I can guess anyway
[02:23:18] <jmkasunich> or the amp is saturating
[02:23:54] <petev> I can open the amp up more, but the amp can make much faster accel moves with less current
[02:23:55] <cradek> didn't you ever try it slower? I know swp suggested that yesterday
[02:24:06] <petev> for max vel?
[02:24:10] <cradek> yes
[02:24:11] <petev> or for accel?
[02:24:20] <petev> mav vel didn't change it
[02:24:22] <cradek> I don't know which is the problem here
[02:24:24] <petev> i didn't try accel
[02:24:34] <cradek> probably accel, since it's not cruising
[02:25:37] <petev> I I can do some quick checks in the drive and see what the current peaks are
[02:26:32] <petev> the drive did not saturate, + current peak was largest at 3.789 A and drive is limiting to 4.5 A now
[02:27:29] <cradek> well for some reason EMC sees it's not following
[02:28:17] <petev> that trace on X axis was generating an overspeed error
[02:28:29] <petev> and emc is at 180 ipm and drive at 200 ipm
[02:28:39] <petev> so let me do some more here on Z
[02:28:49] <petev> then get back to X if needed
[02:29:22] <cradek> vel isn't on this plot is it? I'm sure it wasn't going that fast if it wasn't even cruising
[02:30:31] <petev> probably not
[02:31:15] <cradek> you ought to try some .05" rapids or incr jogs
[02:31:22] <cradek> I bet they fault too
[02:31:32] <cradek> .05 or whatever your offset is
[02:32:58] <petev> ok, I just loosened up emc and the home completed
[02:33:13] <petev> and I don't see the large current spike in the drive
[02:33:28] <petev> so maybe that was being caused by the ferror side effects
[02:34:01] <cradek> so was this more a "wild goose chase" or a "swirl"?
[02:34:06] <petev> jmk, remember when we started looking at this and I asked about PID?
[02:34:07] <cradek> I vote swirl, but I'm not sure
[02:34:15] <petev> cradek, could be
[02:34:26] <jmkasunich> I don't remember what you asked
[02:34:34] <petev> but we looked at PID very early and jmk didn't think it was an issue
[02:34:47] <jmkasunich> I never said that you had it properly tuned
[02:35:00] <petev> remember I said the PID was pretty mild and I hadn't done any rigorous tuning as the belts were off?
[02:35:08] <petev> agreed
[02:35:19] <petev> but I asked first if you thought this might be a PID issue only
[02:35:21] <jmkasunich> I didn't think (and still don't) that giving the PID a legal profile to follow would result in excess output to the drive
[02:35:46] <petev> I think what we learned is the illegal output was from the ferror
[02:35:54] <petev> we didn't realize that yesterday
[02:36:03] <jmkasunich> but I never said that your PID was tuned well enough to track every possible legal position command
[02:36:16] <petev> agreed
[02:36:18] <jmkasunich> this kind of thing is why I like to work bottom up
[02:36:30] <jmkasunich> don't even run EMC until you have the PIDs tuned and working nicely
[02:36:40] <petev> well I started asking about PID first
[02:37:01] <petev> I was asking about small Dcausing oscillations
[02:37:08] <jmkasunich> I'm not gonna post-mortem the debugging process - I'm in the middle of trying to fix soft limits
[02:37:14] <petev> and no FF1 being horrible
[02:37:25] <petev> sure, so let's talk about PID
[02:37:39] <petev> I have ran P all the way from 100 to 1000
[02:37:55] <petev> but tracking sux without FF1
[02:38:09] <jmkasunich> I do all tuning without FF1
[02:38:24] <petev> this didn't seem quite right, as I would have though I could get better tracking without FF1 than I was seeing
[02:38:33] <petev> that's what I was trying
[02:38:34] <jmkasunich> a P of 1000 means that 0.001" of error will command 1 inch per second of movement back torward the proper position
[02:38:42] <petev> but I couldn't get any good motion without FF1
[02:38:49] <petev> yes
[02:38:50] <jmkasunich> so were you seeing that?
[02:39:12] <petev> I would have to check on the scope
[02:39:22] <petev> I was basically just looking at the ferror
[02:39:31] <jmkasunich> scope pid error (or cmd and feedback, but error has the advantage of being centered around zero), scope the PID output
[02:39:42] <petev> right
[02:39:53] <petev> and I wasn't seeing any real improvements without FF1
[02:40:01] <petev> FF1 improved things a lot
[02:40:04] <jmkasunich> thats not what I asked
[02:40:27] <cradek> I got good basic motion by increasing P until it oscillated, then using D to cancel the oscillation
[02:40:30] <jmkasunich> error of 0.001 and Pgain of 1000 should cause movement at 1ips toward the right position
[02:40:35] <petev> I answered your question, said I don't know, I was only looking at ferror
[02:40:40] <jmkasunich> you either did or did not get that behavior
[02:40:56] <petev> don't know, was only looking at ferror
[02:41:04] <jmkasunich> thats a problem then
[02:41:17] <petev> from ferror I did not see improvement
[02:41:24] <jmkasunich> this is very frustrating for me - I'm used to troubleshooting things with a scope
[02:41:28] <petev> cradek, I tried that
[02:41:41] <petev> bad oscillation at P=5000
[02:41:47] <jmkasunich> if I expect X, and I see Y, I start looking closer, I don't just change another variable and hope it gets better
[02:41:51] <petev> but worse when I add D
[02:42:14] <petev> well you are asking if the PID functions correctly
[02:42:25] <petev> I assumed it did what the params told it
[02:42:27] <jmkasunich> my experience on the mazak was that small D (less than 10, maybe less than 1?) damped the oscillations that came from too much P
[02:42:30] <petev> but I will check and see
[02:42:43] <jmkasunich> you say "tracking sucks" or similar words
[02:42:50] <cradek> I suspect pid works, just like homing works, you're not the first one to try it
[02:42:53] <jmkasunich> thats not quantitative
[02:43:05] <petev> meaning ferror was not very good
[02:43:18] <cradek> jmkasunich: yes that's my experience too
[02:43:31] <jmkasunich> how bad does it suck? is it off by 0.030? if so, and Pgain is 1000, it ought to be going in the right direction at 30 ips, so it should be there in 0.001 seconds
[02:43:39] <jmkasunich> if thats not happening, you gotta look deeper
[02:43:48] <petev> no, maybe 0.005 or so
[02:43:55] <jmkasunich> remember, you got another loop in that drive, a velocity loop
[02:44:09] <petev> yes, I tuned that one
[02:44:17] <petev> the drive has a step function
[02:44:22] <petev> and some auto tuning
[02:44:31] <jmkasunich> if you replace the PID with a siggen and put a +1/-1 ips square wave out the DAC, you are not gonna get a square wave on velocity feedback
[02:44:35] <jmkasunich> there is lag in the amp
[02:44:39] <petev> it was also bad before tuning, but after was very good
[02:44:56] <jmkasunich> define very good quantitatively
[02:45:17] <jmkasunich> -1 to +1 ips command step, how long till the motor is actually spinning at +1 ips?
[02:45:27] <jmkasunich> 1mS, 10mS, 50mS?
[02:45:31] <petev> I could give it position commands at max accel and it would not exceed very small following error < 0.001
[02:45:44] <jmkasunich> position commands direct to the drive?
[02:45:49] <petev> yes
[02:45:53] <tomp> the amp should tell you the 'lag' and that lag is the acceleration time of the system
[02:46:05] <jmkasunich> please don't tell me you are running a position loop in the drive AND a position PID in EMC
[02:46:10] <petev> no
[02:46:17] <petev> only for testing the motor setup
[02:46:23] <petev> the drive is in vel mode now
[02:46:37] <jmkasunich> so you are running the drive in vel mode, but you tuned it in pos mode?
[02:46:51] <petev> no, I tuned the vel loop in the drive
[02:46:51] <jmkasunich> that seems counterproductive
[02:47:00] <petev> then tested it using pos mode in the drive
[02:47:21] <petev> the ultramster interface will let you give position commands with the drive in vel mode
[02:47:31] <petev> and it closes the pos loop in the drive as well
[02:47:32] <jmkasunich> how were you giving it the pos commands? thru the interface?
[02:47:41] <petev> yes, rs232 to drive
[02:48:01] <jmkasunich> so you never tested its ability to respond to the PC sending it a velocity command thru the DAC?
[02:48:17] <petev> yes, but not without EMC
[02:48:46] <jmkasunich> you never did a step response or anything like that, using the DAC to send velocity
[02:49:10] <petev> no, only controlled ramps within the accel limit
[02:49:25] <petev> I didn't see the point of a step as the drive will limit it anyhow
[02:49:52] <jmkasunich> large steps, yes
[02:49:54] <jmkasunich> small ones, no
[02:50:04] <jmkasunich> small signal vs. large signal bandwidth and all that fun stuff
[02:50:05] <petev> it's a digital drive, so I'm not sure about that
[02:50:23] <SWPLinux> stupid Allen Bradley
[02:50:26] <SWPLinux> oops :)
[02:50:56] <jmkasunich> a sufficiently small step will not drive the amp into limit
[02:51:27] <petev> it is making accel checks digitally from what I can tell
[02:51:33] <jmkasunich> maybe a ramp (velocity ramp) is better for appraising the amp's capabilities, bandwidth, and tuning, I'm not gonna argue about step vs ramp
[02:51:34] <petev> I don't think it's an analog check
[02:52:04] <jmkasunich> digital vs. analog is irrelevant
[02:52:11] <petev> why do you say that?
[02:52:14] <jmkasunich> the current in the motor windings is analog
[02:52:23] <SWPLinux> um, this may have been answered already, bu twhat version of EMC are you using?
[02:52:26] <petev> digital does ADC on the cmd input and checks things with the DSP
[02:52:40] <petev> it never gets that far if it doesn't like the input cmd
[02:52:49] <petev> latest from CVS head
[02:52:53] <jmkasunich> I don't care whether the signal processing between the dac and the windings is op amps and resistors and caps or a DSP, its still a control loop
[02:53:09] <SWPLinux> well, not quite the latest, you would have trace names on the scope plot if it were
[02:53:27] <petev> I don't understand your point, if the DSP doesn't allow the input to get to the analog portion, what are we testing?
[02:53:27] <SWPLinux> and more digits in the value readout
[02:54:00] <jmkasunich> the drive is a black box, the fact that its a DSP doesn't matter
[02:54:02] <SWPLinux> I suspect you'd be testing the drive's response to the kind of output EMC can provide
[02:54:12] <jmkasunich> analog in, from the DAC, analog out, current and torque in the motor
[02:54:25] <petev> SWP, I did a CVS up earlier today and untarred on the machine
[02:54:28] <SWPLinux> which is eventually the same as a digital command, but isn't on the front end
[02:54:30] <petev> so it's pretty current
[02:54:43] <cradek> petev: you didn't get it right then, since yesterday's changes are not there
[02:54:45] <jmkasunich> it doesn't matter whether its opamps, a DSP, or magic pixies, it has a transfer function
[02:54:59] <SWPLinux> hmmm. I have trace names in halscope, so I'm wondering if you have an installed version that's partly there with your run=in=place
[02:55:15] <cradek> I want magic pixies
[02:55:17] <petev> cradek, any chance the make did not update correctly? I removed the old emc3 dir
[02:55:20] <Guest191> magic pixies?
[02:55:23] <cradek> what are we arguing about?
[02:55:45] <SWPLinux> halscope shouldn't matter since it's a separate app, but other things may not be so nice (like modules and the like)
[02:55:46] <petev> jmk, so you are saying you want to see the xfer func with the DSP in the loop?
[02:55:59] <cradek> possibly if your timesamps are wrong or there's other bogons somewhere
[02:56:05] <petev> that I will give you, but the DSP will be limiting according to the drive params
[02:56:20] <petev> I will make clean and build the same code again
[02:56:26] <Guest191> Guest191 is now known as skunkworks
[02:56:28] <SWPLinux> or you run a different shell then run halscope, rather than running halscope from a menu item in your EMC GUI
[02:57:12] <jmkasunich> biab
[02:57:21] <petev> SWP, I don't follow
[02:57:33] <SWPLinux> well, if you have an installed EMC, then that's on the path by default
[02:57:45] <petev> Oh, noting is pointing to that
[02:57:48] <SWPLinux> if you run your RIP EMC, then use a different shell to run halscope, it may be the installed version that gets run
[02:57:55] <petev> and I gave the full path to halscope when I ran it
[02:58:02] <SWPLinux> ok
[02:58:05] <tomp> petev: you say the tuning >was mild< and that you now >just loosened up emc< , so i think it's now 'looser' than before? can you state the numbers so we can see what 'fixed' it
[02:58:14] <SWPLinux> you can also source the scripts/emc-environment script
[02:58:15] <petev> I ran from a shell, but it hasn't crashed since I upped the frame buffer mem
[02:58:38] <SWPLinux> frame buffer memory? this is a shared video memory machine?
[02:58:39] <petev> tomp, PID is still FF1=1, P=100
[02:58:44] <petev> SWP yes
[02:58:56] <petev> EMC was ferror 0.001, 0.005
[02:59:05] <petev> now it's 0.005, 0.005
[02:59:08] <SWPLinux> ok. hopefully that won't cause problems with the 1 ms RT loop rate
[02:59:16] <SWPLinux> it shouldn't, but could
[02:59:38] <petev> I haven't gotten any warnings, except once when I plugges the USB stick and ther kernel seemed to go away for a bit
[02:59:44] <petev> plugged
[02:59:50] <SWPLinux> yep, USB is often an issue
[03:00:19] <SWPLinux> also, jymmm mentioned that latencies went down when he disabled some IDE interfaces that weere unused
[03:00:24] <SWPLinux> were
[03:00:28] <petev> tomp, I don't consider it fixed yet, as I think much tuning is needed to get ferror tighter
[03:00:46] <petev> SWP, I will have to check that
[03:00:53] <petev> I know the floppy is disabled
[03:01:22] <SWPLinux> petev - can you tune the drive using HAL and the motenc as the signal source, in velocity mode?
[03:01:35] <SWPLinux> I'm curious to see if any of the drive parameters would change
[03:01:49] <SWPLinux> either way, one of us will learn something :)
[03:01:56] <SWPLinux> at least one of us, actually
[03:02:00] <tomp> you do a step command to the digital drive with hal, it would be open loop, and the result would be evaluated with a tacho or hal-fu with the encoder feedback. it would calculate the lag, and thus the acceleration. higher acc is tighter and better. there would be no feedfwd in this tuning.
[03:02:00] <petev> not sure, right now the drive generates i'ts own step funtion and analyzes the result
[03:02:17] <petev> I can change the drive tuning manually, but not sure what it would accomplish...
[03:02:33] <SWPLinux> can it just give you statistics if you give it your own inputs?
[03:02:42] <SWPLinux> even if it isn't auto-tuning
[03:02:53] <petev> what kind of statistics, tuning params?
[03:03:14] <SWPLinux> hmmm - I'm not sure what statistics, actually
[03:03:35] <SWPLinux> I'm thinking of the gecko manual, with the nice little scope traces of position error
[03:03:45] <tomp> statistics like the difference between what you asked for and what you got, over time
[03:03:56] <SWPLinux> under or overdamped resopnse
[03:04:12] <petev> tomp, that would be tough since the drive is in vel mode
[03:04:13] <SWPLinux> but you need velocity error, so I'm not sure exactly how to get that
[03:04:17] <petev> It could display the vel error
[03:04:25] <petev> but not pos
[03:04:29] <petev> it has a scope of it's own ;-)
[03:04:53] <SWPLinux> yeah, if it can log command and feedback velocities, or just the vel error, then that would be the right data :)
[03:05:00] <tomp> ok, vel error changes over time due to acel, then is constant at 'cruise', then again differs during decel
[03:05:18] <petev> that's what you would expect
[03:05:22] <tomp> shortening the accel time is tuning
[03:05:40] <SWPLinux> petev, what were your ferror and min_ferror?
[03:06:01] <SWPLinux> something like 0.001 and 0.0003 or thereabouts?
[03:06:08] <petev> read back, fist num was min_ferror
[03:06:10] <SWPLinux> or was it 0.0003 and 0.0001
[03:06:17] <petev> 0.001 min
[03:06:21] <petev> 0.005 ferror
[03:06:25] <SWPLinux> that's now, or originally?
[03:06:34] <petev> I changed min to 0.005 to get home to work
[03:06:42] <SWPLinux> I thought you wanted something tighter than that
[03:06:46] <petev> so very sloppy at the moment
[03:06:49] <SWPLinux> ok
[03:08:08] <SWPLinux> I guess I could just look at the copy of boss.ini I have loaded in gedit ;)
[03:09:02] <petev> looks like the drive has a 2 chn scope and can trigger at a level or rising or falling of one of them
[03:09:06] <SWPLinux> the reason I'm asking is that I want to work through the error that EMC should expect due to the lag from the drive getting up to speed
[03:09:09] <SWPLinux> cool!
[03:09:16] <SWPLinux> what was that model number again? ;)
[03:09:19] <petev> it can sample down to 0.3 msec
[03:09:24] <petev> 1398 series
[03:10:31] <tomp> you cant >tell< the machine what ferror to use, you >report< to it what you measure in the tuning. the lag is what you measure, you will have some lag always, nothing has infinite acceleration.
[03:10:58] <SWPLinux> you can tell the drive what ferror to consider a fault, just like EMC
[03:11:00] <SWPLinux> it's a smart drive
[03:11:21] <petev> SWP, yes, for vel, accel, and pos when in that mode
[03:11:36] <SWPLinux> does it have a torque mode?
[03:11:39] <petev> yes
[03:11:41] <SWPLinux> (out of curiosity)
[03:11:43] <SWPLinux> cool
[03:12:13] <SWPLinux> like this one:
http://cgi.ebay.com/Allen-Bradley-1398-DDM-009X-Ultra-Series-Motor_W0QQitemZ330116363320QQihZ014QQcategoryZ42894QQssPageNameZWDVWQQrdZ1QQcmdZViewItem
[03:12:16] <SWPLinux> ?
[03:13:02] <petev> yes, in fact that's the model I'm using
[03:13:07] <SWPLinux> cool
[03:13:10] <tomp> (imo) you measure what is too much and report it, else you're guessing and telling the smart drive to be a cop with a rule that is just a value without meaning and to clobber anyone who exceeds that number
[03:13:18] <petev> I think they were origianlly mad by electrocraft
[03:13:26] <petev> sometimes you can find them for cheaper
[03:13:35] <petev> the color is black, but the rest is the same
[03:13:40] <SWPLinux> $20 seems pretty good :)
[03:13:53] <petev> that's not buy it now
[03:14:12] <SWPLinux> true enough
[03:14:36] <petev> I have gotten them as cheap as $45 before
[03:14:44] <petev> but have also paid $150
[03:14:50] <petev> still worth it I think
[03:15:03] <SWPLinux> it seems nice. if I had an AC motor to run with it ;)
[03:15:32] <SWPLinux> it is nic ethat it's single phase 100-240VAC
[03:15:48] <petev> Ok, I'm going to go get some dinner and make a test hal file with a ramp gen at max accel
[03:16:00] <SWPLinux> siggen should be able to help a lot
[03:16:09] <SWPLinux> sinwaves, square waves, triangles I think ...
[03:16:18] <SWPLinux> sinewaves, that was
[03:16:41] <petev> I have one with sine waves now, but I think I need something more basic first
[03:16:55] <petev> does a sin/cos circle thing on X/Y
[03:17:05] <SWPLinux> each siggen has all the outputs, just connect the signal to the different outputs as you see fit
[03:17:15] <petev> right
[03:17:21] <SWPLinux> (or use a mux and some pyvcp stuff ;) )
[03:44:16] <petev_> SWPLinux, you still there?
[03:44:27] <SWPadnos> yes
[03:44:37] <petev_> where is the label supposed to be on hal scope?
[03:45:07] <petev_> I don't see one and just built from clean and cvs up doesn't get any new files
[03:45:11] <SWPadnos> hmmm
[03:45:27] <SWPadnos> the label should be on the left of each trace
[03:45:42] <petev_> do I have to trigger it first?
[03:46:10] <petev_> ahh, it showed after the trigger
[03:46:25] <SWPadnos> ok - I think I remembere that
[03:46:27] <petev_> so I guess the make did not re-build everything
[03:47:12] <petev_> probably some time sync issue between machines
[03:47:50] <SWPadnos> something odd anyway
[03:48:19] <SWPadnos> I assume you're running it the same way as before (shell / icon / menu / whatever)?
[03:48:38] <petev_> yeah, I was just checking the code to make sure it was the latest
[03:48:56] <petev_> I will continue to run from a shell in case I see an app exit
[03:48:57] <SWPadnos> did you update after dinner?
[03:49:03] <petev_> no
[03:49:16] <SWPadnos> ok, jmk changed the soft limits to not be an error while you were away :)
[03:49:17] <petev_> did jmk put in the new soft limit code already?
[03:49:20] <SWPadnos> yep
[03:49:30] <petev_> ok, I can update and test it
[03:49:36] <cradek> it's in progress
[03:49:38] <SWPadnos> make sure it all builds :P
[03:49:41] <jmkasunich> petev_: wait a bit
[03:49:46] <petev_> ok
[03:49:52] <jmkasunich> cradek and I are testing and refining
[03:49:53] <petev_> got plenty to do ;-)
[05:23:01] <petev_> jmkasunich, you still up?
[05:24:44] <petev_> I was thinking more about the ferror behavior, and I'm wondering why it wouldn't be appropriate to just freeze the motor-pos-cmd on ferror?
[05:25:45] <petev_> this would avoid any violation of machine limits and I can't see any real downside to it
[05:27:24] <petev_> I should be more precise, it would avoid any gross violation of the machine limits
[05:33:53] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[07:27:43] <alex_joni> ce?
[07:28:27] <alex_joni> oops :)
[07:28:48] <alex_joni> I certainly expect software limits to work closely to the way the currently are
[07:29:32] <alex_joni> imagine jogging a robot in teleop mode, when the kins transformation gets applied someone needs to limit the joints
[07:29:42] <alex_joni> otherwise you'll be running into hardware limits ALL the time
[07:30:03] <alex_joni> and it would just be borken to have to release brakes, move machine by hand off the limits, etc
[07:30:24] <petev_> alex, the issue was with not being able to move all the way to the limits and not knowing where they actually were set
[07:30:34] <petev_> there was some 1% fudge factor
[07:30:37] <alex_joni> petev_: 0.1%
[07:30:59] <petev_> the best solution was to base it on cmd and not fb
[07:31:19] <petev_> if based on fb, it should at least use FE and set the limit where you say to
[07:31:46] <petev_> and no, it was 1%, not 0.1%
[07:32:02] <alex_joni> well.. different expectancies
[07:32:03] <petev_> at least thats the behavior I was seeing on my machine
[07:32:15] <alex_joni> at least on robots I seldom care about actual position (as in numbers)
[07:32:19] <petev_> I think everyone wants the limit where they set it
[07:32:35] <alex_joni> I care about tool tip position, eyeballing the workpiece
[07:32:38] <petev_> the 1% was a quick fix to avoid getting stuck from FE issues
[07:33:08] <alex_joni> btw, I'm just explaining a different thinking
[07:33:13] <petev_> so how would having the limit where you actually set it be a problem for a robot?
[07:33:21] <alex_joni> limits are factory imposed
[07:33:26] <alex_joni> nothing you can do about that
[07:33:32] <alex_joni> you jog the robot to teach positions
[07:33:40] <alex_joni> kinda like the XYZ you write in a g-code
[07:33:55] <alex_joni> but you do it by physically moving the machine to the point you want
[07:34:04] <alex_joni> some of the time you can't even get there
[07:34:12] <alex_joni> because of one or more than one joint limitations
[07:34:13] <petev_> yes, but think integrator or builder or whatever, wouldn't he want the limit where he set it?
[07:34:25] <alex_joni> yeah.. they are there
[07:34:30] <alex_joni> at some point
[07:34:38] <petev_> no, not really with the current implementation
[07:34:50] <alex_joni> I don't understand
[07:34:55] <petev_> if I say 0, 18
[07:34:59] <petev_> it's not really 0, 18
[07:35:11] <petev_> it's more like 0.125, 17.875
[07:35:12] <alex_joni> like I said.. I don't care about 0.18 for robots
[07:35:17] <petev_> which is just confusing
[07:35:19] <alex_joni> err.. 0 18
[07:35:34] <petev_> min/max
[07:35:37] <alex_joni> yeah, got that
[07:35:53] <alex_joni> I know I have about 360 degrees travel on joint 4
[07:36:01] <alex_joni> +179 deg, and -179 deg
[07:36:06] <alex_joni> that's max and min
[07:36:32] <petev_> so if you put that in the INI, isn't that what you expect to get?
[07:36:43] <alex_joni> I try to stay away from limits
[07:36:49] <alex_joni> about 30 degs at least
[07:36:58] <alex_joni> otherwise during interpolated moves it'll error
[07:37:05] <petev_> ok, so you have a large fudge factor and don't really care
[07:37:34] <petev_> on a CNC, especially a smaller machine, you don't want to waste your travel needlessly
[07:37:55] <alex_joni> maybe so..
[07:38:06] <alex_joni> I don't think I'd notice 1% on a joint of a robot though
[07:38:37] <petev_> plus it just makes it hard to know where the limits really are, then you have the problem I ran into of homing closer than the limit
[07:38:49] <petev_> the machine got stuck there and you couldn't move off of it
[07:39:00] <petev_> and the override doesn't override soft limits
[07:39:07] <petev_> so it was just stuck
[07:39:23] <petev_> I have a question you might be able to answer
[07:39:30] <petev_> when I would get errors like this
[07:39:58] <petev_> after completely shuting down emc ans starting it again, an apparently old error msg would come up
[07:40:15] <petev_> the behavior was a bit different with axis and tkemc
[07:40:38] <petev_> the soft limit error would put axis in an infinite loop on the next run, just displaying the error over and over
[07:40:54] <petev_> cradek didn't see how an error was being stored from one run to the next
[07:41:07] <petev_> is there any kind of persisten storage in the nml buffering?
[07:41:18] <petev_> maybe something getting stuck in the error channel?
[07:46:43] <petev_> galil has some decent PID info here:
http://www.galilmc.com/training/webconf.html
[07:46:54] <petev_> this one is pretty decent:
http://www.galilmc.com/training/v_advanced_tuning.html
[07:52:00] <alex_joni> I don't understand how that is possible
[07:52:12] <alex_joni> unless you have a POSITION_FILE in your ini
[07:52:19] <petev_> me eiither, but it happens consistenlty
[07:52:24] <alex_joni> and the joint position gets restored at the next run
[07:52:37] <alex_joni> which caused the error to be generated on the next run
[07:52:44] <petev_> no, just he err msg from the previous run seems to show up
[07:53:16] <petev_> it shows up on startup without even doing anything
[07:53:24] <alex_joni> that's what I was saying
[07:53:39] <alex_joni> if it restores the position of the joints it will trip the same error when it starts the next time
[07:54:02] <alex_joni> try increasing debug level
[07:54:04] <petev_> Oh, I see what your saying, but it's not just limit errors
[07:54:16] <alex_joni> and see who caused the error
[07:54:17] <petev_> it does it with FE errors also
[07:55:05] <petev_> I dont have a POSITION_FILE anyhow
[07:55:13] <petev_> so I think it's something else
[07:56:03] <alex_joni> just saw that
[07:56:12] <alex_joni> I'd increase DEBUG to 0xFFFFF
[07:56:18] <alex_joni> and see who starts with the error
[07:56:26] <petev_> I will try that
[07:56:26] <alex_joni> also do a echo 5 > /proc/rtapi/debug
[07:56:32] <alex_joni> and check dmesg
[07:56:37] <petev_> ok
[07:56:41] <alex_joni> motion will also print errors and warnings there
[07:59:20] <alex_joni> it's certainly an interesting error
[08:00:49] <petev_> has anyone looked at adding auto tuning to the PID block?
[08:01:18] <alex_joni> I think there was some perl script for emc1 a while ago
[08:01:31] <alex_joni> but I could only find references on the mailing list to it
[08:01:45] <petev_> I have found some interesting algorithms
[08:01:57] <petev_> still reading up, but I think it would be a nice feature
[08:02:25] <petev_> also, maybe and IIR low pass on the PID output before the FF gets added in
[08:16:19] <alex_joni> sounds interesting
[08:16:33] <alex_joni> a small HAL component for autotuning might not be that hard
[08:17:04] <petev_> I was thinking to add it right into PID with a pin to start an auto tune
[08:17:19] <petev_> and have some params to set it up
[08:17:26] <petev_> like the distance it could move, etc.
[08:17:32] <alex_joni> yeah, but you only use it once..
[08:17:47] <alex_joni> or a couple times when you set up the machine
[08:17:49] <petev_> actually there are also some adaptive algorithms
[08:17:56] <petev_> I still need to read up on them
[08:18:08] <petev_> but they may be able to tune constantly
[08:18:31] <petev_> so maybe if the load changes, the system could adapt
[08:19:10] <petev_> we could make a separate component, but I think some of the PID params would have to become pins for it to work
[14:49:12] <cradek> jepler: _tkinter.TclError: bad event type or keysym "KP_Return"
[14:49:44] <jepler> argh
[14:50:07] <jepler> but didn't I test before I checked it in?
[14:50:37] <cradek> actually, I wondered that too
[14:50:42] <cradek> :-)
[14:51:23] <jepler> it's called KP_Enter, though the Enter key is called Return
[14:51:34] <jepler> (I think that one is X's fault)
[15:29:22] <dmwaters> {global notice} Good day all. We had a problem with one of our rotation servers that segfaulted. We are currently working on the problem, and i will give any further updates in wallops, thank you for your time, and thank you for using freenode!
[17:50:23] <dmwaters> {global notice} Hi all! freenode is currently looking for both main rotation servers and a hub in Europe. if you are interested in sponsoring a server for freenode please see:
http://freenode.net/hosting_ircd.shtml Thank you for your patience, and thank you for using freenode!
[19:45:17] <cradek> does anyone have an opinion on how touch-off should work when tool offests are in effect?
[19:45:36] <jepler> eek
[19:45:52] <jepler> no
[19:53:40] <skunkworks> the thing that thru me off last night was that when I homed the machine - it wasn't zero. Because I had used touchoff. I am not sure about that. So the g54 offset was set. took be a bit ;)
[19:54:10] <cradek> skunkworks: that's a feature! The cyan origin shows the machine zero when there are offsets
[19:55:03] <skunkworks> Nice. will have to pay more attention.
[19:55:52] <cradek> :-)
[19:56:12] <cradek> there is/will be "zero a coordinate system" in trunk/2.2
[19:56:51] <skunkworks> I was running installed. I think it was the latest.
[19:57:13] <skunkworks> I wanted to run trunk.. but didn't get to that.
[21:25:02] <petev> cradek, not sure if I have enough data for it to be statistically meaningful yet, but I have not had EMC exit yet when started from a shell
[21:25:17] <petev> what is the diff between an icon startup and shell startup?
[21:26:14] <petev> I have launched the other apps (halshow, halscope, etc.) from the GUI with not problems when the GUI is started from the shell
[21:31:52] <cradek> no difference
[21:33:07] <petev> hmm, that's strange, I'll keep running from the shell to get more data
[21:33:35] <petev> I have spent some time on PID with a test HAL setup using a step function
[21:33:56] <petev> I can get the PID tuned so it follows the step with max accell and little overshoot
[21:34:11] <petev> P=2000, D=32, I=?
[21:34:23] <cradek> nice
[21:34:47] <petev> however, adding just a bit of I seems to cause unstability like it's killing the phase margin
[21:35:06] <petev> I can't add enough I to get the steady state to go to the correct position
[21:35:24] <petev> I can see the PID output saturate during the dynamic test
[21:35:40] <petev> and it rings quite a bit with the I term turned up
[21:36:29] <petev> I think some of my problems are coming from the fact that my drives/motors are pretty high bandwidth and this small high freq ringing is effecting them
[21:37:10] <petev> I wonder if the PID sum doesn't need a low pass filter before it's summed with the FF terms?
[21:37:18] <cradek> I've seen that too and I'm not sure how to fix it
[21:38:05] <cradek> I had trouble with I windup during the initial accel, which caused it to track badly during cruise
[21:38:24] <petev> I have looked at some other commercial PID controllers and they all seem to have a low pass filter there, and some a notch filter too
[21:38:32] <petev> windup may be cured with the I error limitter
[21:38:41] <petev> I have not tried turning that on yet
[21:38:48] <petev> do you have it set to non zero?
[21:38:50] <cradek> yeah I always meant to try that
[21:39:12] <petev> I noticed we aren't paying FF2 much attention either
[21:39:24] <petev> I think FF2 may help with initial accel
[21:39:31] <petev> but I see it's not even in the tuning GUI
[21:39:32] <cradek> I was able to crank P high enough to reach the destination
[21:39:51] <cradek> I did end up using some FF2 to help following during accel
[21:40:04] <petev> I don't understand FF0 at all, when would you want this?
[21:40:05] <cradek> I think I was happy with very little I
[21:40:21] <petev> yeah, maybe I should try some FF2 and forget I
[21:40:22] <cradek> a spring holding up an axis maybe?
[21:40:33] <cradek> seems very rarely useful
[21:40:39] <petev> yeah, that's all I could think of
[21:41:13] <petev> I'm going to look at the PID code and make a block diagram
[21:41:26] <petev> maybe it will help understand why it's tuning the way it is
[21:41:33] <petev> it's not what I'm used to seeing
[21:41:45] <petev> guess I should have started with halscope ;-)
[21:41:50] <petev> jmk was right about that
[21:42:02] <cradek> yes we'd all be lost without halscope
[21:43:11] <petev> now I need to get this wifi adapter working, just came in the mail
[21:43:48] <cradek> nice, with any luck it will just plug in and work
[21:44:11] <petev> it loads a driver and shows as a network interface
[21:44:22] <petev> but I need to config the WEP stuff and get it connected
[21:44:38] <petev> does ubuntu have anything like the kwifi manager?
[21:44:51] <petev> or do I need to just edit the files?
[21:45:07] <cradek> did you try settings/admin/network or whatever it is? (not running gnome right now)
[21:45:17] <cradek> I know little about wireless networking
[21:45:31] <petev> I didn't edit any configs yet
[21:45:44] <petev> it was detected by hotplug and loaded a driver
[21:45:49] <petev> not even sure if the drive will work
[21:45:54] <petev> but figured I try it
[21:46:17] <petev> on KDE there is an app that detects local wifi nets just like in windows
[21:46:37] <petev> then you can join one and it will save all the stuff in the kwallet if you have it installed
[21:46:43] <cradek> wouldn't surprise me if there was a gnome equivalent
[21:46:47] <petev> you don't need to manually edit the network config
[21:46:58] <petev> ok, I'll see if I can find it before I start editing
[21:47:37] <cradek> asking google often works too - lots of ubuntu forums etc
[21:47:54] <dmwaters> {global notice} hi all! I need to do some emergency maintenence on 2 rotation servers to help get more rotation servers back into the rotation. This will be mildly disruptive, and i will give more information in wallops as i go. /mode your_nick +w to see them. Thank you for your patience, and thank you for using freenode!
[21:48:04] <petev> yeah, been checking, but mostly guys using hte ndiswrapper
[22:11:20] <petev> hmm, I found the gnome wifi stuff, but it won't associate, I don't think the driver is working
[22:27:45] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[22:30:51] <dmwaters> {global notice} Good day folks. We're done with the emergency maintenence for the time being. We had this scheduled for 6am utc for the 5th but do to some dificulties it had to be pushed up a bit. I apologize for the inconvenience, and thank you for using freenode!
[23:35:39] <petev> fg
[23:47:55] <jmkasunich> petev: regarding PID internals - you are of course welcome to look at the code, but there is also a drawing, pg 83 of the hal manual at
http://www.linuxcnc.org/docs/HAL_Documentation.pdf
[23:48:34] <jmkasunich> you are also welcome to make your own PID module, but I'd rather you don't change the existing one (to avoid inconveniencing other users)
[23:48:57] <jmkasunich> the ability to do custom control loops is a major reason I pulled PID out of the core motion controller
[23:49:12] <_petev> ok, Ill take a look at the manaul
[23:49:28] <_petev> if I do make another, I will of course make it a new compononent
[23:49:35] <jmkasunich> ok
[23:49:41] <_petev> I was thinking of trying to add some auto tuning
[23:49:54] <_petev> I have the loop tuned to the utmost for a step input
[23:50:14] <_petev> but I term is still troublesome from my experience, and I still can't home
[23:50:37] <_petev> it follow the step at 1/2AT^2 rate with very little overshoot
[23:50:42] <_petev> it's slightly overdamped
[23:50:44] <jmkasunich> I was surprized at how much D you were able to use, until I remembered you have 100,000 counts per inch
[23:50:52] <_petev> yes
[23:51:03] <_petev> D was very well behaved and as expected
[23:51:05] <_petev> I was not
[23:51:16] <jmkasunich> D tends to amplify the quantization noise from the encoder counts
[23:51:21] <_petev> with less D there was much less damping and you could see the ringing
[23:51:24] <jmkasunich> small counts = small noise, and you can use more D
[23:51:34] <jmkasunich> yes, D damps the ringing that comes from too much P
[23:51:41] <_petev> right
[23:51:54] <_petev> so I was able to really crank P up with a little D
[23:52:00] <_petev> it made the loop very stiff
[23:52:07] <jmkasunich> when you add I, what happens?
[23:52:12] <_petev> but for steady state, I couldn't get the accuracy
[23:52:21] <_petev> I can't increase I enough to remove the error
[23:52:27] <_petev> without the loop getting unstable
[23:52:46] <jmkasunich> how much I did it take to get unstable?
[23:52:50] <_petev> I can increase I in the steady state and the error is removed
[23:52:59] <_petev> but with a step, it's a mess
[23:53:17] <_petev> maybe about 10 or more and it was already getting unstable
[23:53:19] <jmkasunich> do you have pid.max-output set?
[23:53:23] <_petev> I could hear the oscilations
[23:53:41] <_petev> yes, it's set to 3.333333
[23:53:46] <jmkasunich> pid.max-output and NOT the drive's limits should be what you hit when you saturate during a step
[23:53:48] <_petev> which is in ips
[23:54:06] <_petev> it definitely hits PID max output
[23:54:12] <_petev> I can see that on the scope
[23:54:16] <jmkasunich> because when you hit max output the integrator is held... otherwise it will wind up while the loop is saturated
[23:54:30] <_petev> but the motor also appears to be moving at max accel from visual calc
[23:54:47] <_petev> I don't have any I limit yet
[23:54:50] <_petev> it's 0
[23:54:58] <_petev> and I haven't tried any FF2
[23:55:01] <jmkasunich> well, when the PID output (vel cmd to the drive) hits max, the drive will be acceling balls-out to try to do that
[23:55:04] <_petev> FF1 is 0 for tuning
[23:55:09] <jmkasunich> good
[23:55:21] <_petev> yes, but I have accel limited in the drive
[23:55:36] <_petev> and motion appears to be very close to that limit
[23:55:45] <jmkasunich> any particular reason why you are limiting accel?
[23:55:55] <_petev> I can try and increase it, but it's already 25% more than the emc limit
[23:55:58] <jmkasunich> that adds lag inside the control loop
[23:56:12] <_petev> I have the limit in the drive to not abuse the motors or machine
[23:56:25] <_petev> things like the FE output much more than the limit
[23:56:49] <jmkasunich> not abusing motors is good, do you have it set based on the motor peak current rating, or is it arbitrary?
[23:57:08] <_petev> I have it set based on what the emc limit is
[23:57:11] <_petev> I added 25% margin
[23:57:16] <jmkasunich> I would base it on the motor rating
[23:57:23] <_petev> its well below what the motor can do
[23:57:31] <jmkasunich> work backwards from the motors to estabilsh your capabilities
[23:57:59] <_petev> the motors are very strong, and the accel is not based on current
[23:58:11] <_petev> so more current can be used to provide more force
[23:58:19] <_petev> if there is a large load
[23:58:31] <jmkasunich> if the motor can handle 10A, and you are limiting peak I to 1A, that puts a serious slew rate limit on the velocity loop, which adds delay/phase shift to the position loop and compromizes stability
[23:58:34] <_petev> so why would I need more than 25% padding over the emc limit?
[23:59:22] <_petev> hmm, I'm not quite sure I follow why that would be?
[23:59:26] <_petev> can you explain?
[23:59:28] <jmkasunich> is the drive accel limit literally applied to the velocity command before it gets to the drive velocity loop?
[23:59:41] <_petev> yes, from what I can tell
[23:59:49] <jmkasunich> bad bad bad, take it away!
[23:59:54] <jmkasunich> ;-)
[23:59:57] <jmkasunich> I'll try to explain
[23:59:58] <_petev> why?
