Back
[09:54:38] <jepler> what linuxcnc must need is yet another latency tester
[10:04:38] <pcw_home> seb_kuzminsky: if you write "base thread" code for a PRU I would make the modest suggestion
[10:04:40] <pcw_home> that you have the PRU trigger the servo thread via an interrupt (at base_frequency/N)
[10:04:41] <pcw_home> so that any OS jitter is removed from position sampling (I think brand M is doing something similar now with PCI/Zynq HostMot2)
[10:13:49] <seb_kuzminsky> pcw_home: thanks for the suggestion
[10:22:50] <pcw_home> also solves the atomicity issue for shared read data
[10:33:40] <seb_kuzminsky> there's still the interrupt handling jitter of that scheduling interrupt, right?
[10:44:35] <pcw_home> Sure but the "base thread" has already sampled the stepgen and encoder positions so those have almost 0 jitter
[10:47:53] <pcw_home> so you now only have second order errors caused by the servo thread jitter (variable delay from read to write)
[10:55:04] <pcw_home> so the PRU "base thread" runs the stepgen and encoder (and whatever other high speed integer only modules)
[10:55:05] <pcw_home> every cycle at say 100 KHz and every 100 cycles, it copies the servo thread read data from the modules to the
[10:55:07] <pcw_home> transfer area and issues the servo thread interrupt
[11:00:51] <pcw_home> You could also have a fixed delay for write data if you know your worst case latency
[11:00:53] <pcw_home> (say always do the servo thread write at tic 40 of the base thread,
[11:00:54] <pcw_home> assuming the servo thread latency and run time is always < 400 usec)
[11:03:43] <pcw_home> using the worst case latency for delaying writes lowers control system noise but also lowers
[11:03:45] <pcw_home> average bandwidth since the average latency will be much better than the worst case peaks
[12:31:57] <Tom_itx> what's the latest ubuntu lcnc runs on reliablly?
[12:53:43] <pcw_home> I'm running it on 14.04 and master will run on 16.04
[12:53:44] <pcw_home> (I've not seen any reliability issues, just bleeding edge incompatibilities from TCL version differences I think)
[12:54:54] <Tom_itx> did you have to build it for 14.04 or is there an iso?
[12:56:14] <pcw_home> I built it, There's no ISO I know of
[13:42:10] <jepler> Tom_itx: unless canonical changes their position on the ubuntu trademark there will never be a new ubuntu-based operating system image distributed by linuxcnc.org.
[13:43:25] <jepler> > Any redistribution of modified versions of Ubuntu must be approved, certified or provided by Canonical if you are going to associate it with the Trademarks. [
http://www.ubuntu.com/legal/terms-and-policies/intellectual-property-policy]
[13:43:47] <jepler> > If you need us to approve, certify or provide modified versions for redistribution you will require a licence agreement from Canonical, for which you may be required to pay. For further information, please contact us (as set out below).
[13:46:30] <jepler> Canonical has repeatedly declined high profile requests for a list of things that must be changed so that they will agree a modified version will not be "associate[d] with the Trademarks"
[13:47:14] * cradek sends the fsf some more money
[13:48:15] <jepler> > The trademark policy should be revised to provide better guidance to downstream distributors so that they can be confident they know exactly where and when trademarks need to be removed in order to comply with the policy.
https://www.fsf.org/news/canonical-updated-licensing-terms
[14:10:14] <cradek> I'm sure FUD serves their purposes much better than clarity would
[14:12:31] <jepler> sad but true
[14:16:32] <jepler> anyway that's why I direct all my efforts at Debian
[14:16:57] <cradek> same
[14:19:11] <jepler> https://wiki.debian.org/Derivatives/Guidelines#Trademark
[15:07:19] <andypugh> Tommylight is being very helpful on the forums. He is also new enough that he remembers what is hard for a newbie. (I can tell I have forgotten)
[15:07:32] <andypugh> I suggest that he might usefully be made a moderator.
[15:09:44] <andypugh> Though perhaps Norbert (gmoccapy) is a better candidate if we want a German-speaking mod.
[15:17:05] <jepler> let me know and I'll make the appropriate changes in the administrator interface
[15:21:12] <andypugh> I think that making both newbynobi and tommylight mods and “giving” them international/Deutsch makes sense.
[15:22:46] <jepler> have you asked them if they want the job?
[15:22:51] <jepler> if not, will you?
[15:23:10] <jepler> we don't really have a process for this afaik, but asking before giving them a job seems curteous
[15:23:13] <jepler> ich bin ein berliner
[15:24:47] <andypugh> Yes, Good point. I will ask.
[16:44:25] <JT-Shop> what should motion_type and motion_mode return in the python interface?
[16:44:37] <JT-Shop> or where can I look in the code to see?
[16:46:33] <jepler> {(char*)"motion_mode", T_INT, O(motion.traj.mode), READONLY},
[16:46:43] <jepler> from this line in emcmodule.cc you can learn that it is an int
[16:46:51] <jepler> {(char*)"motion_mode", T_INT, O(motion.traj.mode), READONLY,
[16:46:52] <jepler> "I wish this were documented"},
[16:47:09] <jepler> it would be great for someone to add docstrings like this; they will appear in pydoc
[16:47:27] <jepler> src/emc/task/emctask.cc:343: if (emcStatus->motion.traj.mode == EMC_TRAJ_MODE_FREE) {
[16:47:41] <jepler> by grepping around, you can learn that in C++ this is assigned values from the EMC_TRAJ_MODE_xxx family
[16:47:48] <jepler> ENUMX(4, EMC_TRAJ_MODE_FREE);
[16:48:08] <JT-Shop> thanks, let me see what I can learn
[16:48:09] <jepler> which are available as members of the Python module, with the first 4 characters ("EMC_") removed
[16:48:45] <jepler> def joints_mode():
[16:48:45] <jepler> return s.motion_mode == linuxcnc.TRAJ_MODE_FREE
[16:48:51] <jepler> of course you can also learn a lot from how it's used
[16:49:11] <jepler> as long as you don't look at poorer examples
[16:49:14] <jepler> src/emc/usr_intf/gmoccapy/gmoccapy.py: if self.stat.motion_mode == 1:
[16:49:23] <jepler> or irrelevant examples that use the same identifier name
[16:49:24] <jepler> src/emc/rs274ngc/rs274ngc_pre.cc: _setup.motion_mode = G_80;
[16:49:44] <JT-Shop> If I do s.poll() then print getattr(s,'motion_mode') I get an integer back
[16:51:24] <jepler> yup, that is correct
[16:51:39] <jepler> but that integer will be equal to linuxcnc.TRAJ_MODE_FREE, or one of the other TRAJ_MODE_xxx constants
[16:54:16] <JT-Shop> ok that makes sense. need to check out a copy on this pc
[17:23:00] <JT-Shop> sweet it makes sense now... if s.motion_type == linuxcnc.TRAJ_MODE_FREE: do stuff
[17:27:39] <seb_kuzminsky> jepler: somewhere i have a branch where i started adding docstrings to emcmodule
[17:27:49] <seb_kuzminsky> i'll see if i can dig it up
[17:33:03] <seb_kuzminsky> oh heh oops, it's in my wip branch for issue #96, that i should probably get back to...
[17:37:53] <seb_kuzminsky> guess i didn't get very far on that particular tangent
[17:38:34] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 3cb7d93 06linuxcnc 10src/emc/usr_intf/axis/extensions/emcmodule.cc linuxcnc python module: add documentation for jog() * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3cb7d93
[17:48:45] <pcw_mesa> These look like pretty nice hm2_eth hosts: (elite 8300 USDT)
[17:48:47] <pcw_mesa> http://freeby.mesanet.com/elite8300-preempt-rt.png
[17:48:48] <pcw_mesa> seems OK at 3 KHz servo thread with Ethernet
[17:49:36] <pcw_mesa> had to turn off "Turbo" mode
[18:07:42] <linuxcnc-build> build #2650 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/2650 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[18:12:02] <seb_kuzminsky> wat
[18:15:54] <seb_kuzminsky> hm, there's even a FIXME in that test that calls it out for being lame, right where i expect this test problem is
[18:20:13] <linuxcnc-build> build #4505 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4505 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[18:21:09] <seb_kuzminsky> the startup transient of the stat buffer is a mess, here's what i did in the startup-state test to work around it:
https://github.com/LinuxCNC/linuxcnc/blob/master/tests/startup-state/test-ui.py#L16
[18:41:22] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 ccd8c0c 06linuxcnc 10tests/startup-state/test-ui.py startup-state test: throw a valid exception on timeout * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ccd8c0c
[18:41:22] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 c7e4c36 06linuxcnc 10tests/rs274ngc-startup/test-ui.py rs274ngc-startup test: wait for Task to start up * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c7e4c36
[19:54:41] <linuxcnc-build> build #3173 of 4004.deb-lucid-amd64 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4004.deb-lucid-amd64/builds/3173 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:57:05] <linuxcnc-build> build #582 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/582 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[20:14:08] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 2a2804d 06linuxcnc 10src/emc/rs274ngc/rs274ngc_pre.cc Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2a2804d
[20:18:06] <seb_kuzminsky> i just finally built some pru firmware with the gnu binutils toolchain and wiggled a pin on the beagle bone black
[20:18:27] <seb_kuzminsky> next milestone will be to have a blob of shm between the pru and some linux code
[20:20:51] <seb_kuzminsky> but not this weekend, i'm going camping
[20:22:27] <linuxcnc-build> build #7 of 4025.deb-jessie-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4025.deb-jessie-armhf/builds/7 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[21:03:14] <jepler> seb_kuzminsky: happy camping!
[21:11:56] <skunkworks> Nice
https://www.youtube.com/watch?v=EqnvMwOS0BA
[21:42:53] <jepler> yay the gtk+ people have seen sense and will *NOT* be ruining their API compatibility every 3-6 months as they had previously promised.
https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/
[22:00:26] <linuxcnc-build> build #3174 of 4004.deb-lucid-amd64 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4004.deb-lucid-amd64/builds/3174 blamelist: John Morris <john@zultron.com>, Sebastian Kuzminsky <seb@highlab.com>
[22:02:51] <mozmck> jepler: that's a change from what they have been doing with 3.x, and they basically admit so in that article: "From the perspective of the community, on the other hand, following GTK+ development has been more painful."
[22:15:23] <jepler> mozmck: exactly
[22:19:48] <mozmck> That's a good thing. I have never liked gtk+ very well though compared to other toolkits I've used. They seem to overly complicate a lot of things.
[22:24:13] <skunkworks> \\
[22:29:33] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master f1cc2ae 06linuxcnc 10src/emc/rs274ngc/interp_o_word.cc 10src/emc/rs274ngc/rs274ngc_pre.cc 10tests/startup-state/test-ui.py Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f1cc2ae
[22:29:34] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master f4cb01b 06linuxcnc 10lib/python/linuxcnc_util.py 10tests/rs274ngc-startup/test-ui.py 10tests/startup-state/test-ui.py tests refactor: consolidate wait_for_linuxcnc_startup() * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f4cb01b
[23:56:10] <cradek> Cpk of 2 means process yield is 99.9999998%. that seems good...?
