Back
[03:36:03] <pink_vampire> hi
[08:09:24] <skunkworks> zlog
[09:05:22] <skunkworks> stupid question - when say a thread is looking for an input - how long does it scan? does it scan the whole period?
[09:05:47] <skunkworks> (say the encoder hal componant)
[09:06:31] <seb_kuzminsky> the encoder samples its inputs instantaneously when it runs
[09:06:41] <archivist> scan, methinks a nanosecond peek
[09:06:54] <seb_kuzminsky> yeah
[09:07:15] <seb_kuzminsky> it reads once when the component's function runs, then ignores the input until the next time the function runs
[09:07:15] <skunkworks> ha
[09:07:17] <skunkworks> ah
[09:08:05] <seb_kuzminsky> the comp might access its input pin multiple times during the function's run, each one is a separate sampling of the input
[09:08:15] <archivist> it is what I hate about software polling
[09:08:46] <seb_kuzminsky> yeah that's a drawback for sure
[09:12:19] <pcw_home> doesn't the encoder hal component work on static data? (sampled just once by the parport read function)
[09:19:24] <JT-Shopp> yea gantry homing is working on dgar_home_something based on ja
[09:21:26] <JT-Shop> now to figure out what I did on this pc so apt-get install could find mesaflash and didn't do on the other pc's
[09:22:13] <JT-Shop> I bet it is deb
http://linuxcnc.org/ precise base 2.7-rtai
[09:22:45] <seb_kuzminsky> JT-Shop: yeah, mesaflash is in the "base" component of each supported dist in our debian archive
[09:23:25] <JT-Shop> thanks
[09:23:50] <seb_kuzminsky> pcw_home: you're right, of course: the parport.N.read samples the pins, then the encoder uses those sampled values until next time the parport comp reads them
[09:28:33] <seb_kuzminsky> hm, our hal_parport component is lacking a manpage
[09:31:40] <seb_kuzminsky> we have asciidocs on the parport comp, just no manpage,
http://linuxcnc.org/docs/2.7/html/hal/parallel-port.html
[09:35:49] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky opened issue #58: Add a manpage for the hal_parport component 02
https://github.com/LinuxCNC/linuxcnc/issues/58
[10:11:26] <skunkworks_> jepler, so far so good powering the 7i92 differently. (usb instead of wall wart)
[10:17:54] <skunkworks_> seems to be staying at about 180us over 24 hours (tmax servo period)
[10:18:23] <skunkworks_> (626808/3.4ghz)
[11:22:54] <seb_kuzminsky> how you set rtapi's msg_level in uspace?
[11:23:33] <skunkworks_> where does the initial messages get put when debian is booting? Like where it says the drive is clean
[11:23:42] <seb_kuzminsky> uspace_rtapi_app doesn't read the ini so it doesnt even know what [EMC]DEBUG is
[11:23:46] <skunkworks_> there is a message after that that I cannot catch
[11:24:33] <seb_kuzminsky> skunkworks_: install bootlogd
[11:25:23] <jepler> seb_kuzminsky: I don't think you can
[11:25:43] <seb_kuzminsky> bummer
[11:25:44] <cradek> I've always just edited the code :-/
[11:25:48] <skunkworks_> Hmm I think I found it. The error was Error not error. Grep'ed it
[11:26:26] <skunkworks_> 'pcspkr' is already registered, aborting.
[11:26:36] * seb_kuzminsky hands skunkworks_ 'grep -i'
[11:27:04] * skunkworks_ takes it and promptly forgets it.
[11:27:22] <skunkworks_> cradek, did you see my rigid tapping comment last night?
[11:27:33] <cradek> nope
[11:27:40] <jepler> 20:55:47 <skunksleep> Rigid tapping works in air... (Using the gear tooth sensors)
[11:27:43] <jepler> 20:57:55 <skunksleep> Ran into the 'too many turns before stopping' issue at 2000rpm... ;)
[11:27:47] <jepler> 20:59:38 <skunksleep> Certainly puts linuxcnc in an odd spot
[11:27:47] <cradek> yay
[11:27:49] <cradek> boo
[11:27:51] <cradek> yeah
[11:28:04] <skunkworks_> it seems you have to exit to set it right
[11:28:21] <skunkworks_> but 69 teeth seems smooth enough
[11:28:44] <skunkworks_> and the index works
[11:28:48] <cradek> eww, exiting is unfortunate
[11:28:58] <cradek> I guess that's a bug
[11:29:33] <skunkworks_> I was thinking I could issue a bug report with sim example (really slow accelleration of the virtual spindle)
[11:30:37] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky opened issue #59: make it easier to change uspace rtapi_app 02
https://github.com/LinuxCNC/linuxcnc/issues/59
[11:31:04] <jepler> what's the way to do it with RTAI realtime?
[11:31:11] <cradek> something in /proc
[11:32:02] <seb_kuzminsky> yeah that's not great either
[11:32:08] <jepler> #if defined( CONFIG_PROC_FS ) && LINUX_VERSION_CODE < KERNEL_VERSION(3,10,0)
[11:32:11] <jepler> #define RTAPI_USE_PROCFS
[11:32:17] <jepler> and it also doesn't work with kernels from this decade
[11:32:34] <jepler> "Linux 3.10 has been released on Sun, 30 Jun 2013. "
[11:33:05] <seb_kuzminsky> maybe Motion could handle the msg_level of the realtime context, and we could set it via a new nml command
[11:33:17] <seb_kuzminsky> task would initialize it at startup
[11:33:29] <jepler> Committer: Jeff Epler <jepler@unpythonic.net> Sun Aug 24 11:58:49 2014
[11:33:29] <jepler> rtapi: disable /proc for kernel 3.10+
[11:33:44] <jepler> seb_kuzminsky: or if 'halcmd' could do it somehow
[11:33:58] <seb_kuzminsky> like with a pin? that'd work too
[11:33:59] <jepler> is it a bug that there's no way to do it for a non-realtime componet too?
[11:34:16] <seb_kuzminsky> mmmaybe
[11:39:02] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky commented on issue #59: RTAI's realtime logging is controlled through /proc, which is also awkward.... 02
https://github.com/LinuxCNC/linuxcnc/issues/59#issuecomment-217198056
[11:42:44] <mozmck> Where is this logging logged?
[11:43:12] <seb_kuzminsky> in uspace it goes to stdout (and maybe stderr)
[11:43:16] <seb_kuzminsky> in rtai it goes to dmesg
[11:43:19] <mozmck> One thing I did here was modify show_errors.tcl to not show dmesg output.
[11:53:21] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #59: .. and that /proc code is disabled for kernels 3.10 and greater too 02
https://github.com/LinuxCNC/linuxcnc/issues/59#issuecomment-217201593
[14:10:27] <seb_kuzminsky> urgh
[14:11:02] <seb_kuzminsky> motion's checkAllHomed() is broken, but if i fix it, it exposes a bug in Axis :-(
[14:11:51] <seb_kuzminsky> https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/motion/command.c#L85
[14:12:31] <seb_kuzminsky> at startup, motion knows how many joints there are, but none of them have been set to "active" yet, so the allHomed flag gets set even though none of the joints are homed
[14:12:51] <seb_kuzminsky> the flag only gets cleared on unhome, not on joint activation, so it never gets cleared
[14:14:27] <seb_kuzminsky> then, on EMCMOT_COORD or EMCMOT_TELEOP (
https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/motion/command.c#L478), it always looks like checkAllHomed() passed, even when it shouldnt have
[14:15:33] <seb_kuzminsky> Axis sometimes wants the interpreter variables synced, and it uses task mode switch (which causes motion mode switch) to trigger var-file write as a side effect:
https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/usr_intf/axis/scripts/axis.py#L1097
[14:15:49] <seb_kuzminsky> this happens, for example, when loading the splash-screen gcode, long before any homing has happened
[14:16:26] <seb_kuzminsky> if i fix checkAllHomed(), Motion rightfully complains about Axis switching it to coord/teleop at startup
[14:16:40] <seb_kuzminsky> bugs upon bugs
[14:17:27] <seb_kuzminsky> i guess i'll... add a Task NML command to sync the vars file without any weird side effects, switch Axis to use that, then fix checkAllHomed() (by removing emcmotDebug->allHomed entirely)
[14:17:35] <seb_kuzminsky> unless someone sees a better way
[14:18:22] <seb_kuzminsky> the thing that set me on this goose chase was a 2-line change to motion to switch from Free to Teleop when the last joint finishes homing, fwiw
[14:22:29] <KGB-linuxcnc> 03Sebastian Kuzminsky 05ja13-teleop-after-homing f37f7b5 06linuxcnc 10src/emc/motion/command.c 10src/emc/motion/motion_debug.h remove the useless and broken emcmotDebug->allHomed flag * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f37f7b5
[14:22:29] <KGB-linuxcnc> 03Sebastian Kuzminsky 05ja13-teleop-after-homing 609d7ff 06linuxcnc 10src/emc/motion/command.c 10src/emc/motion/mot_priv.h 10src/emc/motion/motion.c motion: move handling of EMCMOT_TELEOP to a function, for reuse * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=609d7ff
[14:22:29] <KGB-linuxcnc> 03Sebastian Kuzminsky 05ja13-teleop-after-homing f0b1089 06linuxcnc 10src/emc/motion/homing.c motion: switch to Teleop mode when the final joint finishes homing * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f0b1089
[14:22:33] <KGB-linuxcnc> 03Sebastian Kuzminsky 05ja13-teleop-after-homing 7b79ac7 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py FIXME: add a bug note to Axis * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7b79ac7
[14:22:42] <seb_kuzminsky> it's based on ja13, but it's the same in master
[14:43:57] <linuxcnc-build> build #4082 of 1300.rip-precise-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/4082 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[14:44:44] <linuxcnc-build> build #4084 of 1306.rip-precise-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/4084 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[14:47:35] <linuxcnc-build> build #3293 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/3293 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[14:47:37] <linuxcnc-build> build #2242 of 1400.rip-wheezy-i386 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/2242 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[14:47:50] <linuxcnc-build> build #1753 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/1753 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[14:48:16] <linuxcnc-build> build #2243 of 1403.rip-wheezy-amd64 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/2243 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[14:50:04] <linuxcnc-build> build #2439 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/2439 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[14:50:22] <linuxcnc-build> build #710 of 1520.rip-jessie-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1520.rip-jessie-amd64/builds/710 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[14:50:34] <linuxcnc-build> build #710 of 1530.rip-jessie-rtpreempt-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1530.rip-jessie-rtpreempt-amd64/builds/710 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[14:50:57] <seb_kuzminsky> well that didnt work
[14:51:09] <linuxcnc-build> build #710 of 1510.rip-jessie-rtpreempt-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1510.rip-jessie-rtpreempt-i386/builds/710 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[14:51:24] <linuxcnc-build> build #710 of 1500.rip-jessie-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1500.rip-jessie-i386/builds/710 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[14:52:17] <linuxcnc-build> build #1908 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/1908 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[14:57:07] <linuxcnc-build> build #2276 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/2276 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[14:57:07] <linuxcnc-build> build #4096 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4096 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[14:59:58] <JT-Shop> YIKES
[15:06:29] <JT-JA13> testing Dewey's homing branch based on JA and if I set my HOME_SEARCH_VEL = 0.1 and my HOME_LATCH_VEL = 0.05 I get Home switch active before start of latch move
[15:07:05] <JT-JA13> I remember Andy saying something once about needing more search velocity for certain homing
[15:07:37] <JT-JA13> So I tried HOME_SEARCH_VEL = 0.5 and HOME_SEARCH_VEL = 0.5 and it worked
[15:13:14] <seb_kuzminsky> JT-JA13: that sounds like a bug
[15:14:16] <JT-JA13> I also tested in 2.7.4
[15:14:39] <JT-JA13> just to make sure it was in both
[15:15:05] * JT-JA13 goes to fix the tractor I hope
[15:40:01] <seb_kuzminsky> zlog_:
[15:40:45] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky opened issue #60: homing bug in 2.7.4 02
https://github.com/LinuxCNC/linuxcnc/issues/60
[17:39:26] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 14d06d8 06linuxcnc 10src/emc/motion/homing.c homing.c provision to sync final move to home JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=14d06d8
[17:39:26] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 55b81ce 06linuxcnc 10docs/src/config/ini-config.txt 10docs/src/config/ini-homing.txt 10docs/src/getting-started/updating-linuxcnc.txt docs homing: udate for negative HOME_SEQUENCEs JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=55b81ce
[17:39:26] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 d8c891a 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis.py always joint mode for unhome defs JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d8c891a
[17:50:29] <seb_kuzminsky> we should definitely switch to joint mode after unhoming, but i think that should happen in Motion, not in the GUI
[18:02:54] <mozmck> For a gantry, it should never be in joint mode.
[18:06:17] <mozmck> That's one thing I like about gantry.comp - it's not possible to get it into a mode where it moves or jogs one side independently of the other - except when homing. And no gui support needed.
[18:10:15] <seb_kuzminsky> everyone has to home in joint mode
[18:10:23] <seb_kuzminsky> so if you're not homed, you should be in joint mode
[18:10:24] <seb_kuzminsky> imo
[18:11:05] <seb_kuzminsky> having motion switch to teleop immediately after it finishes homing seems like the best we can do
[18:19:50] <PCW> looks like its possible to get < 0.1 mill accuracy at 20 IPS 1/2 G with ~ 1 packet /5 seconds lost
[18:19:51] <PCW> just by PID tuning (eth-packet-loss branch)
[18:19:53] <PCW> Could do better if the PID comp could be taught to "vamp-til-ready"
[18:21:32] <PCW> (freeze output until valid position FB data)
[18:28:41] <mozmck> seb_kuzminsky: if a gantry machine is not homed, jogging should still always move both sides together.
[18:29:13] <seb_kuzminsky> mozmck: interesting!
[18:29:45] <cradek> ... unless you want to move them independently, right?
[18:29:54] <mozmck> So I think there should be a way to make it so motion only switches to joint mode while homing, and back to teleop otherwise.
[18:30:01] <cradek> heh always unless that's not what you want
[18:30:02] <JT-Shop> dgarr got jogging in joint mode to obey the jog slider for those times when you need to jog for maintenance etc.
[18:30:14] <seb_kuzminsky> i've been totally stuck in the current assumption that joint-mode jogging is always in free mode, where each joint is totally independent of all others
[18:30:38] <cradek> can you jog in world before homing?
[18:30:51] <cradek> and, um, regardless of that, should you be able to?
[18:31:14] <mozmck> Well, for any gantry I've seen (and that's about all we deal with), you never jog a side independently. Homing will remove any racking that might happen accidentally.
[18:31:23] <seb_kuzminsky> i think you can't switch non-identity kins to teleop/world mode unless you're homed
[18:31:33] <cradek> seb_kuzminsky: oh right!
[18:31:33] <seb_kuzminsky> i was just nosing around in that code
[18:31:40] <mozmck> What is the difference between world and teleop again?
[18:31:45] <seb_kuzminsky> same thing
[18:31:47] <mozmck> ok
[18:32:13] <seb_kuzminsky> there is no world mode, there is only teleop, but world mode has a more obvious meaning, so we sometimes use that word instead
[18:32:13] <cradek> "teleoperating" is what emc1 called manual jog-like motion in world mode
[18:32:41] <mozmck> A gantry is essentially one joint with two motors - unlike a robot.
[18:32:44] <cradek> it didn't have wheel or incremental motion, and in linuxcnc/ja it's very much now just like jogging
[18:32:57] <andypugh> “teleoperarting” is what I do when I turn on the TV
[18:33:06] <cradek> ... so it's an old term I don't use because I think it's unclear
[18:33:22] <seb_kuzminsky> i didn't realize how much i loved incremental jogging until i didn't have it (on our gantry machine)
[18:33:26] <mozmck> ok, world mode does make more sense
[18:34:11] <seb_kuzminsky> i can imagine a gantry that's somehow gotten skewed, and wanting to manually jog one of the joints to square it up a little, manually, before homing to fix it for real
[18:34:51] <andypugh> We should call them joint mode and axis mode :-)
[18:34:59] <seb_kuzminsky> andypugh: +1
[18:35:15] <mozmck> Well, if it gets really out of whack - which rarely occurs - we simply power off the motors and it will self adjust mostly, or you can do it by hand.
[18:35:37] <mozmck> yeah, +1 here!
[18:36:01] <andypugh> (Actually, joint mode and cartesian mode might cause less confusion. Except if usig polar coordinates)
[18:36:22] <mozmck> My thought is that it could be an option. Those who want the ability to jog each side could set things that way.
[18:37:40] <mozmck> The problem is that if the machine is ever in a state where you can jog one side, then people will go to jog and can damage the gantry quickly.
[18:38:25] <mozmck> I just got one of these in:
http://vocore.io/wiki/index Now I need to figure out something to do with it!
[18:38:45] <seb_kuzminsky> mozmck: i'm having a hard time thinking about what you're suggesting
[18:39:29] <mozmck> :-) Well, except for the acceleration issue, the gantry component is perfect.
[18:40:00] <seb_kuzminsky> i think you're talking about three manual modes now: free/joint like we have now, teleop/world/axis like we have now, and a new one where you run through kins (to enfore joint relationships) but you're not homed?
[18:40:21] <JT-JA13> this is cool you can set your home offset to different values when the switches are not perfect
[18:40:41] <andypugh> JT-JA13: In what?
[18:40:41] <seb_kuzminsky> JT-JA13: yeah, that's a great software hack :-)
[18:41:08] <JT-JA13> in dgarr_home_final which is from ja13
[18:41:25] <seb_kuzminsky> but it means you can't use the synchronized-homing trick to maintain/improve squareness throughout the homing sequence
[18:41:30] <andypugh> I seem to recall that non-identical index locations and home-to-index was a real bug-bear of the last time we talked about this.
[18:41:36] <JT-JA13> I've tried every homing test I can think of
[18:43:04] <seb_kuzminsky> andypugh: yeah, i think you'd have to make the hardware be tuned to communicate when it's square, using home switches and index pulses and things, in order to make that work as intended
[18:43:20] <JT-JA13> as near as I can tell all it does is not move to the home position until all joints with - are homed
[18:43:45] <mozmck> In my thinking, motion could go into joint mode when it starts homing, and otherwise would be in world mode. I'm not sure how kins plays in with such a case right now.
[18:44:06] <mozmck> bbl
[18:44:33] <seb_kuzminsky> mozmck: non-identity kins won't let you switch to world mode wiuthout homing
[18:44:53] <JT-JA13> all the joints with a home sequence that is -n home at the same time
[18:45:07] <JT-JA13> the first one just waits for the rest to home
[18:45:42] <JT-JA13> so it is as synchronized as you can get until you home all the joints on that axis
[18:45:56] <seb_kuzminsky> JT-JA13: and they wait after latching the home switch, before doing the final traverse to the home location?
[18:46:04] <JT-JA13> yes
[18:46:17] <JT-JA13> so you can have the home location anywhere
[18:46:22] <seb_kuzminsky> right
[18:46:57] <andypugh> I am still curious what the home function in all the kins modules is for.
[18:47:11] <JT-JA13> I had an encoder adapter for a nema 17 but used the encoder on the BP spindle
[18:47:44] <seb_kuzminsky> but if the home switches are in locations that don't indicate "square", then the gantry would have no choice but to rack a bit during any kind of synchronized-home/home-final scheme, right?
[18:47:53] <seb_kuzminsky> andypugh: no clue!
[18:48:22] <JT-JA13> that sounds right
[18:48:39] <andypugh> seb_kuzminsky: I wonder who would know?
[18:48:46] <seb_kuzminsky> i've sometimes daydreamed about letting kins control homing, instead of having motion do it in free mode (optionally with some joints homing simultaneously)
[18:48:56] <seb_kuzminsky> seb_kuzminsky: "git blame"
[18:49:00] <seb_kuzminsky> err, andypugh
[18:49:20] <seb_kuzminsky> a stewart platform, for example, needs kins-aware homing
[18:49:41] <seb_kuzminsky> bbl
[18:49:56] <JT-JA13> time to cook!
[18:50:02] <seb_kuzminsky> yep :-)
[18:50:03] <JT-JA13> bbitm
[19:12:57] <PCW> Lesson of the day, never let the stepgens PID loop output be acceleration limited (by stepgen maxaccel)
[19:27:56] <jepler> same here
[19:28:05] <jepler> er hi
[19:30:19] <PCW> Hi!
[19:38:20] <PCW> http://freeby.mesanet.com/stepgen-overshoot.png
[19:38:22] <PCW> http://freeby.mesanet.com/nomajorovershoot.png
[19:40:37] <jepler> the first is a case of hitting stepgen limit I take it?
[19:40:44] <PCW> both in response to dropped (= timed-out) packets
[19:40:46] <PCW> last one has more stegen accel margin
[19:41:48] <jepler> hm
[19:42:08] <PCW> Yeah if you ever hit the accel limit in your control loop your nice first order velocity loop turns into a second order loop
[19:42:11] <jepler> MAX_ACCELERATION = 300
[19:42:14] <jepler> STEPGEN_MAX_ACC = 360
[19:42:35] <jepler> this is what I have but I haven't looked at the error lately
[19:44:15] <jepler> I mostly just was happy that when I opened up my ferror it worked at all
[19:44:38] <PCW> that works fine until until something tickles the control loop enough that the velocity command exceeds the stepgen accel
[19:45:18] <PCW> (like the huge ferror from the missing packet)
[19:46:34] <PCW> It seems its much better to bound the PID maxerror rather than the stepgen maxaccel
[19:47:26] <jepler> if we know one thing it's that the loop inside hostmot.ko's stepgen isn't making us happy
[19:47:52] <PCW> There is of course a limit to how low you can make the PID maxerror (until timebase errors cause loss of control)
[19:48:11] <jepler> and it gets a lot worse when the position is wrong
[19:49:09] <PCW> I ran into the stepgen accel instability hing with someone on the forum
[19:49:19] <PCW> s/hing/thing/
[19:49:42] <PCW> hmm isnt hing a Indian spice?
[19:49:52] <PCW> must be dinner time
[19:49:58] <jepler> mmmm
[19:50:02] <jepler> already ate but thanks
[19:52:13] <PCW> Without big errors caused by dropped packets its pretty easy to get < 20 u inch max FE at high speeds and accelerations
[19:52:55] <PCW> but the accel thing is troubling
[19:58:15] <PCW> I think if the position mode driver was revamped (so the PID is internal) I would probably bound
[19:58:17] <PCW> the stepgen maxaccel to machine accel (just wire its pins to the same ini variable)
[19:58:19] <PCW> and do any needed bounding internally
[20:00:51] <PCW> Currently the stepgen maxaccel does not work well in the control loop for PID controlled stepgens
[20:00:52] <PCW> so if you use it to limit (say by using the gantry component that has steps in its postions) you will get some ringing
[20:06:13] <PCW> Anyway, it is possible to tune the stepgen so it copes quite well with occasional dropped packets
[20:06:14] <PCW> (it would be better of course if the PID comp could freeze its outputs if theres no new FB data)
[20:09:01] <PCW> a perhaps slightly better solution than freezing the output is feeding the command to both PID inputs if no FB data is available
[20:10:59] <PCW> for example with a velocity loop, this would allow the output command to follow acceleration when FB is not present
[20:11:51] <PCW> (basically runs open-loop but with up-to-date feed forward)
[20:13:55] <PCW> bbl dinner
[20:14:13] <jepler> so this could be tested by having pid feedback come from a mux, with inputs of command and feedback, and select being hm2_7i92.0.packet-error
[20:15:06] <PCW> yeah great idea, I'll try it tommorow
[20:15:56] <jepler> have a good dinner
[20:16:12] <PCW> thanks, bye
[20:27:19] <skunkworks> zlog
[20:31:54] <jepler> I think this config I got from skunkworks doesn't count as well tuned, even absent errors it is getting errors of about .003 during accel/decel
[20:32:34] <jepler> FF1=1 FF2=.0015 P=50, others zero
[20:33:20] <jepler> 1ms thread
[20:35:00] <skunkworks> that was probably a pretty realy pid stepper config
[20:35:09] <skunkworks> ugh
[20:35:52] <skunkworks> that was probably a pretty early pid stepper config
[20:37:51] <jepler> also not using dpll
[20:44:12] <jepler> with dpll and modified pid settings, now getting much better following .. absent packet loss
[20:45:20] <jepler> last trace I captured had .013 of imaginary error and then -.0053 of real error after it overcorrected
[20:53:25] <pcw_home> P should be about 1/servo thread period
[20:54:23] <pcw_home> PID maxerror should be about .0005 or even .0001
[20:55:05] <jepler> with the mux as I suggested, I get a quickly-decaying error of the same sign as the false error
[20:55:53] <jepler> hm maybe not consistently. the next capture had opposite-sign error
[20:57:28] <jepler> magnitude -.00005, magnitude .00022
[20:58:24] <jepler> so yes it is better in magnitude
[20:58:41] <jepler> and if I resolve the problem that it almost always detects two errors in a row it should be better still
[20:58:55] <jepler> now I'll stop touching it and let it run overnight with .01% packet loss
[21:24:34] <pcw_home> One nice thing about the timeout is not blowing up with occasional net delays
[21:24:36] <pcw_home> so you can get away with a higher servo thread rate
[22:11:45] <jepler> apparently if I start a high-graphics video game (talos project) I get a realtime delay. oops!
[22:12:24] <jepler> I should change the missed write detection to work like the missed read detection, reading back a just-written value instead of looking at the hostmot2's idea of packet counts
[22:13:23] <jepler> .. that's the core reason that it usually detects 2 errors at a time, it doesn't make the right packet-count prediction the next cycle after a lost packet
