Back
[08:41:30] <skunkworks_> zlog
[09:45:05] <skunkworks_> https://github.com/synthetos/TinyG/wiki/Jerk-Controlled-Motion-Explained
[09:45:16] <skunkworks_> wonder what that output actually looks like
[09:46:22] <jepler> skunkworks_: sounds like you need to get one and run your motion tests again
[09:46:50] <skunkworks_> Yes - all I have here is an arduino. have to get some hardware
[09:50:11] <skunkworks_> tinyG?
[09:50:13] <jepler> ah, I see it goes with a specific $130 board
[09:51:45] <skunkworks_> ah
[09:52:07] <skunkworks_> I don't know if I care that much ;)
[09:59:00] <pcw_home> wonder why the are going beyond the third derivative? I do recall when we were messing with SoftDMC we played with
[09:59:02] <pcw_home> 5th derivative profiles since you can get a complete ramp-up/ramp-down profile without any tests (except the end)
[09:59:36] <cradek> the sonja algorithm limited all derivatives by using sine profile
[09:59:44] <cradek> which is pretty awesome
[10:00:17] <pcw_home> thats good for advertising purposed (infinite derivatives)
[10:00:42] <pcw_home> purposes
[10:05:46] <pcw_home> hmm the gantry comp works for me... sigh
[10:09:11] <skunkworks_> users! ugh ;)
[10:09:29] <skunkworks_> gantry comp doesn't have acc/dec iirc though
[10:09:38] <skunkworks_> (when it hits the limit
[10:13:51] <pcw_home> havent even got that far but the stepgen accel should take care of that
[10:14:06] <skunkworks_> oh - sure
[10:14:09] <skunkworks_> https://www.arduino.cc/en/Main/ArduinoBoardDue
[10:14:14] <skunkworks_> looks like it should run on that too
[10:14:37] <pcw_home> though stepgen accel is slightly broken
[10:15:32] <skunkworks_> ?
[10:16:51] <pcw_home> as soon as you have a control loop and you run into bounds your nice tuning goes out the window
[10:18:01] <pcw_home> really the stepgen should have its accel set to machine limits and use internal numbers with overhead for its feedback loop
[10:20:05] <pcw_home> the gantry comp will require wider ferror limits (because it adds a pipeline delay to the position )
[10:28:49] <mozmck> pipeline delay?
[10:34:34] <pcw_home> 1 servo period delay so motion sees a following error of velocity/servp-period
[10:35:43] <mozmck> Hmm, I need to look at my configs - I don't remember there being a delay, and I know I haven't changed ferror
[10:45:29] <pcw_home> you may already have fairly wide limits
[10:47:10] <mozmck> pcw_home: I have ferror set to .0002
[10:49:53] <mozmck> It does look like the offset is calculated and written in gantry.write, and position is updated in gantry.read. However, if gantry.read is placed before motion-controller in the hal file, then it should be fine because motion-controller is where the ferror is calculated (iirc!)
[11:06:11] <pcw_home> hmmm I have gantry read before motion controller and i get a error proportional to velocity (looks like 1 period delay)
[11:13:15] <pcw_home> OK its a thread order thing, I think I go t it fixed
[11:17:05] <pcw_home> ok back to .0001 .0002
[11:19:00] <mozmck> Ah, I see. I have gantry.write after motion-controller, so the position is written on one cycle, then next cycle gantry.read updates pos-fb before motion-controller reads it and calculates ferror.
[11:19:28] <mozmck> So the updates are a cycle apart, but motion-controller doesn't know that :-)
[11:24:33] <pcw_home> even in the other case the stepgen feedback is local to the path is correct (just the ferror looks bad)
[12:20:46] <KGB-linuxcnc> 03Norbert Schechner 052.7 6eeb094 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.py gmoccapy_1_5_6_2 - forgot to change release number :-( * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6eeb094
[12:21:59] <KGB-linuxcnc> 03Norbert Schechner 05master 69e87f9 06linuxcnc Merge branch '2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=69e87f9
[13:05:33] <KGB-linuxcnc> 03John Thornton 052.7 b6609bf 06linuxcnc 10(5 files in 3 dirs) Docs: fix information about opening a terminal. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b6609bf
[13:07:51] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 fe09099 06linuxcnc 10src/hal/hal_priv.h fix comments describing HAL thread & funct times * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fe09099
[13:28:03] <skunkworks_> seb_kuzminsky, Thank you!
[13:28:38] <seb_kuzminsky> see, i'm not dead, i'm just reduced to fixing bugs in comments
[13:30:08] <skunkworks_> low hanging fruit... ;)
[13:31:17] <seb_kuzminsky> :-)
[13:34:28] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 47cdd26 06linuxcnc 10src/hal/hal_priv.h Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=47cdd26
[13:59:38] <linuxcnc-build> build #1827 of 1102.rip-hardy-amd64 is complete: Failure [4failed garbage-collect git repo] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1102.rip-hardy-amd64/builds/1827 blamelist: Norbert Schechner <nieson@web.de>
[14:30:52] <jepler> the internet seems to think that an "fsync error" in "git gc" could be an out-of-disk-space problem
[14:31:07] <jepler> seb_kuzminsky: ^^ if you get a chance to peek
[14:34:24] <CaptHindsight> move the synchronized motion from a PC to a uC and then run the GUI with what a PC or an ARM SOC with GPU?
[14:35:27] <CaptHindsight> I'm trying to follow the logic from the ML if there is any to follow
[14:37:10] <CaptHindsight> for headless apps?
[14:37:30] <CaptHindsight> try to save $10 on a Spartan 6 with a $1 uC?
[14:42:28] <jepler> at some point it's just best to skip threads about goals that are not your own goals
[14:42:54] <CaptHindsight> no crime in doing it for fun
[14:43:05] <CaptHindsight> unless asking causes pain
[14:43:34] <jepler> well that is certainly the point I have reached
[14:44:36] <jepler> (that it causes me pain to read certain threads, let alone try to negotiate participants away from what I think is ultimately going to be an unproductive line of inquiry)
[14:45:05] <CaptHindsight> just asking in case I'm missing something
[14:45:14] <CaptHindsight> forest for the trees sort of thing
[14:45:39] <jepler> I haven't been reading it so I can't say ;-)
[14:48:08] <CaptHindsight> that new nvidia Tegra ARM soc looks great, unfortunately I can't find a board with it for under $500
[14:49:28] <CaptHindsight> and I don't see anyone selling the silicon
[14:49:31] <CaptHindsight> supports DirectX 12, OpenGL 4.5, CUDA, OpenGL ES 3.1, and the Android Extension Pack, in addition to Unreal Engine 4
[14:56:26] <seb_kuzminsky> /dev/sda1 8.0G 2.8G 4.8G 37% /
[14:56:38] <seb_kuzminsky> [14580417.621226] Buffer I/O error on device sda1, logical block 1818642
[14:56:38] <seb_kuzminsky> [14580417.621782] lost page write due to I/O error on sda1
[14:56:44] <jepler> uh oh
[14:56:51] <cradek> eee
[14:57:06] <jepler> is the guest saying that, or the host?
[14:57:16] <jepler> .. better check SMART errors on the host
[14:57:34] <seb_kuzminsky> that's the guest
[14:57:38] <seb_kuzminsky> nothing on the hypervisor
[14:58:57] <seb_kuzminsky> rebooted the VM
[14:59:00] <seb_kuzminsky> forced a rebuild
[14:59:14] <seb_kuzminsky> everything is falling apart
[14:59:22] * seb_kuzminsky shakes his fist at entropy
[14:59:39] <jepler> you know the fist shaking itself makes it worse right
[14:59:46] <seb_kuzminsky> everything makes it worse
[15:00:11] <seb_kuzminsky> so, has anyone tried building linuxcnc on ubuntu on windows yet?
[15:00:19] <seb_kuzminsky> surely that will make everything better
[15:02:28] <JT-Shop> for a gantry you need gantry.0.read then loadrt io... then gantry.0.write?
[15:05:14] <mozmck> No, I don't think the loadrt order really matters, but the function order in the thread does.
[15:05:25] <mozmck> addf gantry.0.read
[15:05:35] <mozmck> addf motion-command-handler
[15:05:42] <mozmck> addf motion-controller
[15:05:48] <mozmck> addf gantry.write
[15:06:25] <mozmck> then addf the pid....do-pid-calcs if you use them.
[15:07:19] <JT-Shop> ok, thanks
[15:08:09] <JT-Shop> that should be on the man page I think
[15:08:19] <linuxcnc-build> build #4049 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4049 blamelist: Norbert Schechner <nieson@web.de>
[15:18:04] <seb_kuzminsky> JT-Shop: i agree, that'd be useful to document
[15:18:22] <seb_kuzminsky> that failure is good and expected - master doesn't build on hardy
[15:18:28] <seb_kuzminsky> in fact, only 2.5 does these days
[15:18:49] <seb_kuzminsky> once that final 2.5 release is done, i can shut those VMs off and reclaim the disk space for the buildmaster...
[15:18:53] * seb_kuzminsky pokes cradek
[15:19:00] * JT-Shop makes notes for the morning
[15:19:11] <seb_kuzminsky> thanks
[15:20:01] <JT-Shop> I have some drives due here tomorrow to set up a gantry test bed :)
[15:20:19] <seb_kuzminsky> that sounds fun :-)
[15:20:40] <JT-Shop> I have a hand full of nema 17's sitting in a box so why not
[15:21:20] <seb_kuzminsky> what is this, a router for ants?
[15:21:39] <JT-Shop> could be
[15:21:41] <skunkworks> smurfs...
[15:25:35] <JT-Shop> muppets
[15:40:38] <alex4nder> anyone seen this before:
https://gist.github.com/alexanderguy/b6987f59285e421d1247380599db2425
[15:41:26] <alex4nder> I just checked out and built v2.7.4 from tag, and did a pncconf
[15:42:23] <cradek> wonder if you have an incomplete build or something
[15:42:32] <cradek> try git clean -f -x -d and then rebuild
[15:44:13] <alex4nder> alright.
[15:47:08] <jepler> the general purpose of that line is that it is transforming an axis letter into an axis (or possibly joint) number; the problem occurs because the letter is not a lowercase axis letter.
[15:47:22] <alex4nder> yah, the value of the axis is True
[15:47:35] <alex4nder> x and z work as expected though
[15:51:19] <jepler> the line numbers in your bin/axis don't match v2.7.4 src/emc/usr_intf/axis/scripts/axis.py
[15:52:07] <jepler> besides making sure you are really running what you intended, also make sure you don't have any code in ~/.axisrc. some people have taken advice to put lines of code there regarding jogging, and those lines may not be right for some other version of linuxcnc
[15:52:30] <jepler> also test with a standard simulator configuration, such as unmodified configs/sim/axis/axis.ini in the source tree
[15:54:13] <alex4nder> jepler: my local copy has a 'print' that didn't make it into the log
[15:54:55] <alex4nder> I just did a git clean -f -d -x, and rebuilt.. the git commit I'm running is 07773ede8081e172033 ..
[15:55:27] <alex4nder> jepler: thanks, I'll test the standard sim
[15:56:29] <alex4nder> jepler: ok, the standard sim does it as well
[15:56:36] <alex4nder> er axis sim
[15:57:36] <cradek> that is the release ref
[15:57:40] <cradek> jogging works in the release :-)
[15:58:21] <jepler> I followed these steps and did not reproduce the problem. system is debian wheezy.
http://paste.ubuntu.com/15767408/
[15:59:48] <alex4nder> jepler: that works, but pressing +/- with the mouse in axis triggers the error
[16:00:18] <cradek> !!
[16:01:18] <jepler> still not reproduced by: ... click "Y", click and hold "+" or "-"
[16:01:43] <jepler> or by press "Y" on keyboard, press and hold "-" or "=" on keyboard
[16:02:05] <cradek> that also works for me (that got me to build it and try)
[16:02:22] <jepler> what OS?
[16:02:27] <alex4nder> debian testing
[16:02:39] <alex4nder> if it's working for you guys, I'll dig deeper
[16:03:21] <jepler> I expect cradek and I are both testing on wheezy
[16:03:35] <jepler> I have jessie at home but never click the "+" button
[16:03:51] <alex4nder> ciik
[16:03:52] <alex4nder> er cool
[16:04:11] <alex4nder> I'm also seeinga utf8 codec error inside axis, on startup.. I have no idea if that's a different or related symptom
[16:06:52] <jepler> well now you mention it
[16:07:41] <jepler> that's something that comes up with newer libstdc++ (first reported as affecting fedora last december and ubuntu 16.04 more recently) that was our bug and is fixed at the tip of 2.7 but not back at 2.7.4
[16:08:13] <seb_kuzminsky> time for 2.7.5!
[16:11:22] <jepler> seb_kuzminsky: or wait until alex4nder finds the resolution to his trouble, that's sure to be the very last bug in 2.7.x.
[16:20:28] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky opened issue #53: reorganize isos on www.linuxcnc.org website 02
https://github.com/LinuxCNC/linuxcnc/issues/53
[16:20:33] <seb_kuzminsky> jepler: yeah
[16:20:47] <seb_kuzminsky> does anyone know of any outstanding issues that are not in the github issue tracker?
[16:21:24] <seb_kuzminsky> no? ship it!
[16:55:20] <cradek> SWPLinux: no new dns records yet...
[17:41:00] <alex4nder> ok, so the symptoms I'm seeing go away when I moved back to the tk/python-tk/blt/bwidget shipped with jessie
[17:42:08] <alex4nder> but it's still goofy.. selecting the y axis causes current_axis to be set to a _tkinter.Tcl_Obj.. but if I select x or z current_axis gets get to a string of value x or z (respectively)
[17:42:17] <alex4nder> er gets set
[17:43:34] <jepler> In Tcl, "y" can be a truthy boolean value
[17:44:17] <seb_kuzminsky> tcl y u do this
[17:44:22] <jepler> % expr {!!y}
[17:44:23] <jepler> 1
[17:44:31] <jepler> as compared to
[17:44:31] <jepler> % expr {!!x}
[17:44:31] <jepler> invalid bareword "x"
[17:44:44] <jepler> for that matter just "expr y" vs "expr x" :-/
[17:45:05] <alex4nder> jepler: that would line up with what I'm seeing,.. doing a vars.current_axis.get() when the Y axis has been selected, causes a string-converted bool to get returned
[17:45:29] <alex4nder> the string being "True"
[17:47:51] <mozmck> tcl is great ;-)
[17:48:20] <alex4nder> it looks like that's happening because radiobutton $_tabs_manual.axes.axisy -value y -variable current_axis
[17:48:49] <jepler> https://emergent.unpythonic.net/files/sandbox/0001-WIP-work-around-a-nice-fat-Tcl-wat.patch
[17:49:25] <jepler> can you test with this, using tcl/tk/python from debian testing?
[17:49:32] <alex4nder> yah, I just patched
[17:50:26] <alex4nder> jepler: by returning 1, that breaks all of the "xyzabcuvw".index(a) checks
[17:50:59] <jepler> I must still not have wrapped my head around what's happening
[17:51:50] <jepler> and when I tested it I ran the wrong linuxcnc
[17:52:17] <alex4nder> jepler: here's a good example of the symptoms..
[17:52:33] <alex4nder> jepler:
https://gist.github.com/alexanderguy/dac912e151cffdd29268fbb73b8dbd7c
[17:52:38] <jepler> if isinstance(a, (str, unicode)):
[17:52:38] <jepler> a = "xyzabcuvw".index(a)
[17:52:55] <jepler> but if a is now 1, then it shouldn't be a str or a unicode, so how does it get there?
[17:53:06] <alex4nder> because it's still a StringVar
[17:53:12] <alex4nder> so the 1 becomes "1"
[17:54:24] <alex4nder> jepler: so with that patch, working around the conversion of y -> True, everything "works"
[17:54:25] <jepler> oh so "y" is becoming the string "True"? that is horrifying.
[17:54:28] <alex4nder> yah
[17:55:27] <alex4nder> I patched Tkinter.py, and I can see that _tk.globalgetvar is returning a type bool, value True.
[17:55:36] <jepler> put a comment with an "explanation" of "why" "tcl" is ""doing"" that and turn it into a pull request
[17:56:05] <alex4nder> ok
[17:56:37] <jepler> I really suspect there's a Tkinter bug, or else an insurmountable Tcl design problem, lurking behind all this
[17:56:50] <alex4nder> Tkinter definitely changed behavior
[17:57:56] <alex4nder> jepler: I'll build a pull request with all of this info later this evening
[17:59:29] <jepler> what's this do on your system? assertion error, or is OK?
https://emergent.unpythonic.net/files/sandbox/y-means-y.py
[18:00:03] <jepler> 'y' <type 'str'>
[18:00:12] <jepler> here it prints that ^^^ (jessie)
[18:24:05] <alex4nder> jepler: on my system I get a 'y' string
[18:40:33] <linuxcnc-build> build #244 of 4017.5.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.5.deb-wheezy-armhf/builds/244 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[18:59:43] <jepler> alex4nder: ok so provoking it isn't quite that easy. not sure I'll be updating to testing anytime soon, so I'll just rely on your say-so that the bug is fixed..
[19:01:11] <JT-Shop> I got some nut saying the 7i76 field power should be able to be 5vdc "according to the manual"
[19:01:20] <JT-Shop> http://paste.ubuntu.com/15769153/
[19:06:29] <alex4nder> jepler: ok, I'll do some digging myself as well. I haven't written tcl in a long time; I don't remember any of it.
[19:08:59] <skunkworks> JT-Shop: I don't envy you...
[19:09:16] <JT-Shop> I don't know what to say to this guy
[19:10:33] <JT-Shop> only 3 more months of reconciles to be able to start my taxes lol
[19:13:27] <jepler> https://www.fsf.org/licensing/zfs-and-linux
[19:13:42] <jepler> ("duh of course you can't" stated in a lot of lawyer-vetted words)
[19:14:11] <JT-Shop> will that zap idiots?
[19:14:21] <JT-Shop> that's what I need at the moment lol
[19:18:56] <cradek> jepler: ... so canonical has lost the right to distribute the linux kernel until they ask the copyright holders to forgive them?
[19:39:58] <jepler> cradek: that seems to be part of the tl;dr
[19:40:14] <jepler> (ask and are granted by the copyright holders .. all of them)
[23:39:56] <pcw_home> JT-Shop: you can run Vfield from 5V (but you need to supply vin from a separate 8..32V source )