Back
[07:24:23] <ikcalB> hey RTAI gurus: in the lcec HAL module, to cancel the jitter of the RT thread, I'm trying to use timer functions to get the actual time instead of just adding the nomincal cycle time.
[07:26:48] <ikcalB> using any of `rt_get_time_ns()` `rt_get_real_time_ns()` `gettimeofday()` does mess up sth I have not been able to localize. ATM I'm sending an incrementing counter to EC slaves, but some cycles do not show increments or increment by 2. Does anyone have a reasonable explanation / solution at hand?
[08:20:43] <jepler> I don't know offhand
[08:20:55] <jepler> we provide rtapi_get_time, and on rtai realtime it's implemented like this:
[08:20:58] <jepler> long long int rtapi_get_time(void)
[08:21:01] <jepler> {
[08:21:04] <jepler> return rt_get_cpu_time_ns();
[08:21:06] <jepler> }
[08:22:47] <jepler> .. but for many years that code had a comment that
[08:22:47] <jepler> - /* this is a monstrosity that seems to take several MICROSECONDS!!!
[08:22:48] <jepler> - on some boxes. Why the RTAI folks even bothered I have no idea!
[08:22:48] <jepler> - If you have any need for speed at all use rtapi_get_clocks()!!
[08:22:48] <jepler> - */
[08:24:18] <ikcalB> jepler: many tnx. when sniffing packets from a tap, there seems to be no additional delta time / jitter introduced by using that function. going to take a look at `rtapi_get_clocks()` though!
[08:26:24] <jepler> .. that comment and the API rtapi_get_clocks() were added in 2006(!) at ed4089d02a7b
[08:28:54] <ikcalB> afaik rt_get_time_ns is now implemented using the tsc, if it exists. it's improbable that it still takes that long to execute - still worth having a look!
[08:30:20] <jepler> RTIME rt_get_cpu_time_ns(void)
[08:30:20] <jepler> {
[08:30:20] <jepler> return rtai_llimd(rtai_rdtsc(), 1000000000, tuned.clock_freq);
[08:30:20] <jepler> }
[08:31:55] <jepler> RTIME rt_get_time_ns(void)
[08:31:55] <jepler> {
[08:31:55] <jepler> int cpuid = rtai_cpuid();
[08:31:55] <jepler> return oneshot_timer ? rtai_llimd(rtai_rdtsc(), 1000000000, tuned.clock_freq) :
[08:31:58] <jepler> rtai_llimd(rt_times.tick_time, 1000000000, TIMER_FREQ);
[08:32:01] <jepler> }
[08:32:15] <jepler> so for rt_get_time_ns it looks like one code path is the same as rt_get_cpu_time_ns, but the other code path is some time that was measured in the past
[08:32:40] <jepler> /* +++++++++++++++++++++++++++ SECRET BACK DOORS ++++++++++++++++++++++++++++ */
[08:32:49] <jepler> ^^^^ things you never want to see in source code you're reading
[08:35:10] <jepler> I hope you can sort out your problem, best of luck.
[09:38:26] <jepler> well that's cute! any lxrt syscall returns -1 and sets errno to "Function not implemented".
[09:38:36] <jepler> .. even when it is implemented and does work
[09:51:54] <ikcalB> nice one :D. I'll remember that, when I'm haking sth evil...
[09:53:12] <ikcalB> many tnx for your support, I might be getting there... calling any those timing functions (and using the value for an if statement) only, does not mess up. actually using the correct time instead of the monotonic increasing `+period_time` does make problems anywhere
[09:56:17] <ikcalB> will be calling back, on that one. have a nice day ;)
[11:01:29] <JT-Shop> I'm making a 2.8 configuration wizard, I hope I'm not duplicating anyone's work...
[11:04:44] <archivist> stepconf/pncconf?
[11:13:40] <jepler> maybe the third effort will actually be good :-/
[11:14:23] <archivist> and actually read the hal and ini after any hand edits
[11:14:45] <jepler> looking further at lxrt, the ABI compatibility will at least be good for a particular RTAI release, regardless of the underlying kernel. so that's something.
[11:15:37] <JT-Shop> archivist: I'm working on one that does it all for 2.8
[11:16:12] <archivist> for what definition of all :)
[11:16:32] <jepler> archivist: it's just a text editor
[11:16:45] <jepler> but jt's phone number is shown in the corner at all times
[11:16:58] <JT-Shop> well my pea brain thinks parallel port, Pico, Mesa
[11:19:02] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 8bea6b4 06linuxcnc Merge remote-tracking branch 'hazelnusse/Issue105' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8bea6b4
[11:27:03] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky commented on issue #106: Merged. Thanks for this patch!... 02
https://github.com/LinuxCNC/linuxcnc/pull/106#issuecomment-231399005
[11:52:32] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15hazelnusse commented on issue #106: I'm on Gentoo ~amd64 so bleeding edge stuff all over the place :) Right now just a laptop but eventually for a real machine that will run a 3-axis mill. 02
https://github.com/LinuxCNC/linuxcnc/pull/106#issuecomment-231405428
[11:54:42] <linuxcnc-build> build #4337 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4337 blamelist: Norbert Schechner <nieson@web.de>
[11:56:26] <jepler> 44 hours -- I guess buildbot was out to lunch again?
[13:34:01] <seb_kuzminsky> jepler: yeah, one of the wheezy-rtpreempt buildslaves was locked up again
[13:34:24] <seb_kuzminsky> i apt-get dist-upgraded it and one of the things it got was a new kernel, we'll see if that helps
[14:12:39] <jepler> seb_kuzminsky:
https://github.com/LinuxCNC/linuxcnc/pull/102 OK for 2.7?
[14:18:46] <seb_kuzminsky> jepler: you want to cherrypick a6ebc471e2b194c8a2e66bfa54da6af3a5c49078 into 2.7?
[14:19:00] <seb_kuzminsky> that's fine by me
[14:19:07] <jepler> seb_kuzminsky: right
[14:19:17] <jepler> assuming that's the right ref
[14:19:35] <seb_kuzminsky> it's not the ref of the PR, but it seems to have the same commit contents
[14:34:33] <jepler> hm it may be the case that boost has fixed this, in 1.59.0. but still, the affected version is in ubuntu 16.04 and the fedora that came out last winter soo
[14:38:52] <jepler> stretch has 1.58.0, is likely to be affected
[14:39:43] <jepler> well stretch has 1.58 and 1.60, and 1.58 is default
[14:44:25] <seb_kuzminsky> yeah, i've been running on 1.60 because i've been too lazy to fix it
[14:44:37] <seb_kuzminsky> so thanks for figuring that one out :-)
[14:47:18] <jepler> seb_kuzminsky: so you can confirm it affects 1.58 on debian?
[14:47:36] <jepler> if I wasn't tired I'd file a bug. I just slogged through filing
https://bugs.launchpad.net/ubuntu/+source/boost1.58/+bug/1600345 for all the good it'll do
[14:49:01] <seb_kuzminsky> jepler: i'll double check, but i'm pretty sure
[14:49:51] <seb_kuzminsky> i know it does not affect 1.60 on stretch
[14:49:53] <seb_kuzminsky> bbl
[15:54:04] <seb_kuzminsky> jepler: yeah, boost 1.58 in stretch fails, 1.60 works
[15:54:14] <seb_kuzminsky> *** /home/seb/linuxcnc-2.7/tests/interp/value-returned: FAIL: test run exited with 134
[15:54:17] <seb_kuzminsky> etc
[16:04:25] <jepler> seb_kuzminsky: thanks for checking
[16:15:47] <jepler> I guess we have a workaround, so no need to code up a configure test to alert for the problem
[16:52:23] <seb_kuzminsky> jepler: i cherry-picked a6ebc471e2b194 into 2.7 & built it with boost 1.58 and it's passing the tests
[16:52:32] <seb_kuzminsky> when it finishes i'll push it to glo
[16:52:42] <jepler> seb_kuzminsky: also excellent news, thanks very much
[17:02:13] <KGB-linuxcnc> 03Jeff Epler 052.7 b3ec66b 06linuxcnc 10src/emc/pythonplugin/python_plugin.cc rs274: work around boost::python bug * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b3ec66b
[17:34:02] <tinkerer> 'n evening!
[17:35:47] <tinkerer> seb_kuzminsky: a short question about your comment on the devel list concerning the man page
[17:38:20] <tinkerer> in docs/src/man does "*.in" mean "component.9.in" or "component.in"?
[17:40:06] <tinkerer> and is this the preferred way or putting the man page in "/docs/man/..."?
[17:40:25] <jepler> the example of that in our source tree is docs/src/man/man1/linuxcnc.1.in
[17:41:00] <jepler> you would use that sort of file if you needed to show values determined by src/configure in your manpage. In linuxcnc.1, it is to show the configured value of LINUXCNC_CONFIG_PATH:
[17:41:04] <jepler> \fB@LINUXCNC_CONFIG_PATH@\fR
[17:42:33] <tinkerer> Ok
[17:46:14] <tinkerer> Thanks
[18:23:43] <tinkerer> a pull request question:
[18:24:56] <tinkerer> is there a way to hand in later a commit or must I make a new pull request?
[18:25:42] <andypugh> I have to admit I was wondering the same thing, about your pull request. I actually don’t know.
[18:26:12] <andypugh> ( I have never made a pull request nor have I acccepted a pul request)
[18:26:48] <tinkerer> hmmm....
[18:28:07] <tinkerer> nobody with a clue?
[18:34:23] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15tinkercnc commented on issue #107: Is there a way to hand in later a commit or must I make a new pull request? 02
https://github.com/LinuxCNC/linuxcnc/pull/107#issuecomment-231493266
[20:57:19] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #107: @tinkercnc you can push again to your hm2_raspi branch, and the new commits on that branch will be reflected in this pull request. 02
https://github.com/LinuxCNC/linuxcnc/pull/107#issuecomment-231506831