Back
[02:37:53] <SWPLinux> oops - bbiab
[02:48:46] <jmkasunich> where was I
[02:48:57] <jmkasunich> oh, thats right... enable seems inverted
[02:49:09] <jmkasunich> and the mode bits are borked too
[02:49:24] <jmkasunich> I get quadrature when I ask for step type 0
[03:34:10] <SWPLinux> hmm
[03:34:45] <SWPLinux> sorry about the pause there - I heard something like "My whole family is stupid - how can anybody talk to these people" after a phone call between my wife and her sister ..
[03:35:30] <cradek> sounds like a bad omen
[03:35:56] <cradek> yet strangely familiar
[03:36:06] <SWPLinux> heh
[19:41:51] <petev> cradek, u there?
[19:43:23] <petev> a few days ago I disabled 4 services (hplip, bluez-utils, laptop-mode, and nvidia-kernel)
[19:43:40] <petev> since then, I have not had any strange behavior with emc apps
[19:44:06] <petev> not sure if this was the cause, or just coincidence, but the system seems much more stable now
[19:44:57] <petev> I'm running a 5 KHz servo rate with 1 KHz TP as well with no RT issues on the slow VIA board
[19:45:45] <cradek> wow, 5kHz servo is really fast
[19:45:54] <cradek> is that motenc?
[19:45:57] <petev> maybe services that arent't absolutely required should be disabled by default in the live install?
[19:46:03] <petev> yes, motenc 100
[19:46:28] <petev> my drives are pretty fast, and the built in filter doesn't have a high enough corner freq
[19:46:50] <petev> with 1KHz servo, the drives were too quick to get good response for both large and small error
[19:47:05] <petev> with the 5 KHz servo rate, all problems went away
[19:47:33] <cradek> you have no base (faster) thread right?
[19:47:42] <petev> base is at servo rate
[19:48:00] <cradek> cool.
[19:50:30] <petev> how's your machine coming?
[19:52:33] <cradek> excellent, it moved and homed last night, and everything seems to work right
[19:52:42] <cradek> more testing tonight
[19:52:48] <petev> did u try the auto tune yet?
[19:53:13] <cradek> not yet, and after reading the manpage, I'm not very clear on how to use it
[19:53:32] <petev> what part wasn't clear? I'll try and explain it better
[19:53:49] <cradek> it doesn't really answer the question `what procedure do I use to autotune'
[19:53:58] <petev> the at_pid functions as a normal pid and auto-tune
[19:54:11] <petev> when the tune-mode pin is false, it's in normal pid mode
[19:54:15] <cradek> I did figure that out (since it has all the pid pins)
[19:54:20] <cradek> err params
[19:54:24] <petev> when tune-mode is true, it's in tune mode
[19:54:36] <petev> the run a tune cycle, you set the start-tune pin
[19:54:44] <petev> there are only 2 params
[19:54:58] <petev> the number of cycles, which you can probably leave at the default of 50
[19:55:04] <petev> and the tune-effort
[19:55:17] <cradek> do I know how far it will move? I wonder how to know if it's safe, how to abort etc
[19:55:25] <petev> tune-effort is how much output is will use to create the limit cycle
[19:55:41] <petev> that is determined by the machine and tune-effort
[19:55:52] <petev> that's why you want to start with a small effor
[19:55:58] <petev> to see what the reaction is
[19:56:12] <petev> then build up until a good portion of the motor current is used
[19:56:28] <petev> on my machine it only moves about 50 mil on Z
[19:56:41] <petev> but my drives are pretty quick, and Z is light
[19:57:11] <petev> I pretty much just replaced pid with at_pid in my test hal and bypassed motion pos fb
[19:57:28] <petev> then all the other checks are still in place for limits, e-stop, etc.
[19:57:49] <petev> it would be nice to have soft limits in effect too, but that would require more work
[19:58:24] <petev> the state machine for the auto-tune does obey the enable pin and will abort mid cycle
[19:58:23] <cradek> so command stays constant, and it moves around that value to tune?
[19:58:29] <petev> yes
[19:58:42] <petev> so you want to be in the middle of your travel when you first run it
[20:00:03] <cradek> are the params all ignored during this, or do you need an initial setup of those terms?
[20:00:22] <petev> no, all PID params are not used
[20:00:31] <petev> when the cycle completes, they will be filled in
[20:01:55] <cradek> ok great, I'll try it
[20:02:10] <petev> ok, let me know how it works
[20:02:18] <skunkworks> That actally sounds pretty easy ;)
[20:02:25] <cradek> did my questions help for improving the docs?
[20:02:48] <petev> I added a refresh button to the tcl script to see the values after a tune cycle
[20:03:08] <petev> yeah, I'll add some more to the man page
[20:03:23] <cradek> thanks, I'll read that too before I start
[20:03:28] <petev> ok
[23:32:07] <jepler> anybody have ideas about what should go on the back side of a 1-page quick reference? (the first side is assumed to be the gcode quick reference)
[23:32:36] <SWPadnos> maybe some diagrams like the image skunkworks posted
[23:32:54] <SWPadnos> http://www.electronicsam.com/images/KandT/conversion/cheatsheet.JPG
[23:33:14] <jepler> yeah in fact that's why I asked about it earlier -- but most of it did not seem directly applicable to emc
[23:33:22] <jepler> for instance, you don't have to specify arc feed rate in that nutty way...
[23:33:27] <SWPadnos> sure
[23:33:51] <SWPadnos> just the M02 / M03 directions, G17/18/19 plane orientation, G2/G3 directions ...
[23:34:22] <jepler> yeah -- arc directions and maybe some images related to cutter comp were suggested by cradek
[23:34:36] <SWPadnos> hmmm. is it supposed to be a G-code quick ref or an EMC2 quick ref?
[23:34:49] <skunkworks> I was wondering why you wanted that - was wondering if you where doing something with punchtapes ;)
