Back
[08:45:44] <jthornton> I downloaded wheezy I thought yesterday via bittorrent and got jessie again! Seems no matter what you select to start with you end up on the jessie page to download
[08:49:22] <archivist> I think there is an unfortunate upgrade frenzy these days so people are forcing later versions on users not realising how silly that can be (although version names mean even less to me)
[08:50:16] <JT-Shop> I thought I was stupid for downloading the wrong version twice...
[08:50:27] <JT-Shop> but now I realize what happened
[09:55:46] <jepler> maybe make sure to put an accurate download link in the eventual documentation then
[10:42:01] <JT-Shop> as soon as I can find one I will
[10:42:19] <JT-Shop> I think Roguish found one the other day
[10:42:41] <Roguish> waz up? JT-Shop?
[10:43:50] <mozmck> https://forum.linuxcnc.org/forum/pathpilot/30215-pathpilot-hardware-recommendations#68462
[10:44:24] <mozmck> as someone quite familiar with mach3 - I found gmoccapy to be anything but close.
[10:52:29] <JT-Shop> looking for a link for the vanilla debian wheezy, didn't you find one the other day?
[10:53:21] <Roguish> yeah, hang a minute or so....
[10:53:41] <Roguish> it takes a bit of digging around
[10:55:55] <Roguish> https://www.debian.org/releases/
[10:55:57] <Roguish> https://www.debian.org/releases/wheezy/
[10:55:59] <Roguish> https://www.debian.org/releases/wheezy/debian-installer/
[10:56:35] <JT-Shop> thanks
[11:01:21] <Roguish> so many different iso's.... see this:
https://www.debian.org/CD/faq/#which-cd
[12:22:15] <mozmck> cncbasher: have you used mach3?
[12:22:59] <cncbasher> yea
[12:23:42] <mozmck> hmm, I am quite familiar with it, but I sure didn't think gmoccapy was close or similar to it - except maybe for ugliness :-)
[12:24:03] <cncbasher> yea know what you mean
[12:24:40] <mozmck> Took me a while to figure out how to even load Gcode - seems like they went out of their way to make simple things difficult in gmoccapy from my perspective.
[12:24:44] <cncbasher> people like colours that blink and flash and have pictures because they can't read
[12:24:54] <mozmck> :-) probably so.
[12:27:46] <skunkworks> glad I am not the only one that had problems figuring out how to load gcode
[12:28:25] <mozmck> you have to stand on one hand, cross your eyes, and say a secret password to get it in the gcode-loading-mode.
[12:32:11] <skunkworks> zlog
[16:21:23] <andypugh> Am I right that “Using POSIX realtime” means no realtime kernel was found? What is the message for preempt-rt?
[16:28:00] <jepler> rtapi_print_msg(RTAPI_MSG_ERR, "Note: Using POSIX non-realtime\n");
[16:28:03] <jepler> rtapi_print_msg(RTAPI_MSG_ERR, "Note: Using POSIX realtime\n");
[16:28:15] <jepler> the messages should probably be changed until a human can guess which one's which without seeing them both
[16:28:39] <andypugh> Ah, so it has found rt-preempt, and the leatency really is awful on the Pi…
[16:28:50] <andypugh> (this is someone’s forum query)
[16:30:06] <jepler> I don't know much about the state of RT on rpis
[16:30:32] <jepler> somebody should probably change the latency testing UIs to never run with base threads in uspace
[16:31:02] <andypugh> Nor I. I tried something on the Pi2 when it first came out for fun, but soon concluded it was a waste of effort.
[16:32:56] <jepler> http://www.frank-durr.de/?p=203 seems to be one recent effort, though it mentions the "B", not the "2"
[16:33:19] <jepler> and I honestly don't know what he's saying about clock_nanosleep(TIMER_ABSTIME) vs sys_nanosleep
[16:33:53] <jepler> rtapi/uspace_rtapi_app.cc: int res = clock_nanosleep(RTAPI_CLOCK, TIMER_ABSTIME, &task->nextstart, NULL);
[16:34:07] <jepler> though fwiw we do clock_nanosleep + TIMER_ABSTIME
[16:37:29] <andypugh> He is saying 166uS, which is worse than the Forum guy is getting in the LinuxCNC base thread, but his servo thread is showing 1500uS latency, which is clearly nonsense in a 1000uS thread.
[16:37:43] <andypugh> https://forum.linuxcnc.org/forum/38-general-linuxcnc-questions/30223-latency-2-7-2-install-on-raspberry-pi#68479
[16:51:35] <PCW> I suspect the overhead of the basethread is messing things up
[16:52:36] <PCW> A basethread is fine on a fast PreemptRT machine
[17:10:51] <KGB-linuxcnc> 03Jeff Epler 05jepler/uspace-nobase fb76722 06linuxcnc 10src/hal/utils/halsh.c hal package: provide useful constants * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fb76722
[17:10:51] <KGB-linuxcnc> 03Jeff Epler 05jepler/uspace-nobase 22b69a0 06linuxcnc 10scripts/latency-histogram latency-histogram: no base thread in uspace * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=22b69a0
[17:10:52] <KGB-linuxcnc> 03Jeff Epler 05jepler/uspace-nobase a2ce971 06linuxcnc 10scripts/latency-test latency-test: no bsae thread in uspace * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a2ce971
[17:11:25] <KGB-linuxcnc> 03Jeff Epler 05jepler/uspace-nobase a928026 06linuxcnc 10scripts/latency-test latency-test: no base thread in uspace * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a928026
[17:11:45] <jepler> .. turns out that latency-plot can't easily be changed to get rid of its base thread, unfortunateyy
[17:11:48] <jepler> ly
[17:13:29] <PCW> not sure it should be removed, its fine on fast machines:
[17:13:30] <PCW> http://freeby.mesanet.com/h97-g3258-preemt-rt.png
[17:18:28] <PCW> not that hard to
[17:18:30] <PCW> latency-histogram --nobase
[17:56:25] <jepler> I strongly suspect it's a better default, and in both cases you can still request the base thread.
[17:56:42] <jepler> (nice latency tho, I didn't know preempt-rt got that good)
[18:17:53] <PCW> on fast machines I dont see a lot of difference between Preempt-RT and RTAI
[20:37:59] <jepler> https://github.com/Jack000/SVGnest
[20:56:38] <mozmck> that looks very interesting
[20:59:00] <mozmck> except maybe for the "browser based" part.
[21:38:40] <jepler> kids these days
