Back
[00:22:26] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/new-tp-tests 13092e2 06linuxcnc 10tests/trajectory-planner/circular-arcs/nc_files/quick-tests/arc-arc-sawtooth.ngc add missing M2 to ngc file * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=13092e2
[01:16:49] <asah> any ideas why my rtlib dir is only full of .so and not .ko ?
[01:17:01] <asah> spinning up a new 32 bit 12.04 ubu box.
[01:17:11] <asah> rsynced accross my linuxcnc git repo.
[01:17:15] <asah> make clean.
[01:17:30] <asah> have the rt preempt kernel built fine.
[01:18:04] <asah> for some reason hostmot2.ko is not being built at all.
[01:51:23] <memleak> asah, modbus support enabled w/ libmodbus installed?
[01:51:55] <memleak> ./configure output should tell you
[01:52:14] <asah> yes
[01:52:35] <asah> I have no .ko files in rtlib
[01:52:44] <asah> and hostmot2 does not build
[01:53:51] <memleak> post output of config.log to pastebin or similar
[01:57:11] <asah> http://pastebin.com/iM568PdF
[02:00:23] <memleak> ah!
[02:00:24] <memleak> checking whether to build usermode PCI hardware drivers... no; depends on libudev
[02:00:25] <memleak> configure: WARNING: Usermode PCI drivers will not be available
[02:00:59] <memleak> are you using debian based distro?
[02:01:58] <asah> ubuntu
[02:02:48] <memleak> what version?
[02:03:28] <asah> 12.04
[02:03:51] <asah> looks better: checking whether to build usermode PCI hardware drivers... default enabled for userland RT threads
[02:03:59] <memleak> sudo apt-get install libudev-dev && sudo apt-get build-dep libudev0
[02:03:59] <asah> (installed libudev-dev)
[02:05:13] <memleak> yeah that was why
[02:05:24] <asah> thanks!
[02:05:39] <memleak> i dont understand why debian based distros dont just include the headers..
[02:05:50] <memleak> they're not that big on HDD space
[02:23:43] <asah> yay!! thanks… worked...
[09:06:26] <seb_kuzminsky> memleak: you dont need to install the build-deps for libudev0
[09:06:50] <seb_kuzminsky> installing libudev-dev provides everything you need to compile stuff that uses libudev
[09:44:09] <skunkworks_> logger[psha]:
[09:44:10] <logger[psha]> skunkworks_: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-04-24.html
[13:08:39] <asah> so, thanks to memleak, and pcw I now have the 7i80 up and running off my small crummy laptop.
[13:09:18] <asah> my max servo jitter is 50000 or so.
[13:09:28] <asah> on a 1 ms servo thread.
[13:09:45] <asah> using rt preempt
[13:10:25] <asah> getting lots of weird results from ssi reads.
[13:10:35] <asah> thinking pll is the issue.
[13:10:58] <asah> any thoughts on ways to improve latency?
[13:11:13] <asah> 50000 seems high compared to the latency test dataset.
[13:13:00] <pcw_home> actual latency seen by the 7I80 will be higher, can you plot the latencty the DPLL sees?
[13:13:16] <pcw_home> latency
[13:13:51] <asah> yep
[13:14:03] <asah> its peaking at 60-70 or so
[13:16:18] <pcw_home> you should get a 15 to 1 or so noise reduction in the DPLL so SSI sampling
[13:16:19] <pcw_home> jitter should be maybe 5 usec max, what issue to you see in the SSI?
[13:16:25] <asah> a few spikes to like 80 or 130
[13:16:36] <asah> (in the dpll)
[13:16:45] <asah> ssi is pushing out really really large numbers.
[13:16:56] <asah> so thought it may not be reading the whole thing.
[13:17:04] <pcw_home> luckily the spikes dont affect the DPLL much
[13:17:09] <asah> ok.
[13:17:40] <pcw_home> (though a forest of spikes will cause baseline wander)
[13:18:04] <pcw_home> (you can see this in the plot)
[13:19:37] <pcw_home> with the current tuning the DPLL has a ~ 1 Hz bandwidth so pretty good at rejecting jitter
[13:20:01] <asah> the count values in the ssi position.count are really large and negative.
[13:20:08] <asah> this is a 32bit system now.
[13:20:17] <pcw_home> sounds like a bug
[13:20:27] <asah> looks like potentially 64bit - > 32 bit int issue?
[13:22:06] <pcw_home> maybe, there are definitely some bugs remaining in hm2_eth or maybe UBC
[13:22:42] <pcw_home> (this is of the same vintage UBC with the latency test bug)
[13:23:19] <asah> in theory this is your same rt.config
[13:23:23] <asah> untouched.
[13:23:46] <asah> you have not perhaps used ssi in this env though.
[13:24:36] <pcw_home> No, this is the first time this has been tried
[13:25:05] <asah> schweeet
[13:25:08] <pcw_home> I somewhat suspect a math library issue
[13:25:48] <pcw_home> Do the numbers change appropriately
[13:25:52] <pcw_home> ?
[13:25:54] <asah> there is this section of the code in sserial.c where the u32 buffer gets pushed into a uint 64. looking there.
[13:26:04] <asah> the numbers do seem to increase and decrease on movement.
[13:26:23] <asah> (agwn is sitting next to me as well as we work on this, so he may chime in on this)
[13:26:45] <pcw_home> sserial is not involved
[13:26:55] <asah> crossing zero is a bad thing.
[13:27:05] <asah> sserial is the ssi interface we are using.
[13:27:50] <pcw_home> ? sserial is not related
[13:27:57] <asah> around 1400
[13:28:03] <asah> I promise you it is.
[13:28:15] <asah> this is where the ssi read code lives.
[13:28:46] <asah> around 1440 there is a comment // sign extend buff into buff64
[13:29:14] <pcw_home> Oh Andy reused some of the code (its not really related to sserial at all)
[13:29:47] <pcw_home> sign extension is a likely culprit
[13:38:33] <asah> looks like it may be greycode differences? the graycode may be bad.
[13:39:32] <asah> ok… I am an idiot… yet again.
[13:39:35] <asah> bad config.
[13:39:45] <asah> =)
[13:40:02] <pcw_home> OK well thats good news!
[13:40:57] <asah> yes it is!
[14:24:33] <KGB-linuxcnc> 03Norbert Schechner 052.6 e5db028 06linuxcnc 10lib/python/gladevcp/offsetpage_widget.py gladevcp - offsetpage-widget converted line delimiter to UNIX standard * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e5db028
[14:27:23] <KGB-linuxcnc> 03Norbert Schechner 05master df92a97 06linuxcnc Merge branch '2.6' of ssh://norbert@git.linuxcnc.org/git/linuxcnc.git * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=df92a97
[14:31:42] <cradek> jthornton: is
https://sourceforge.net/p/emc/bugs/348/ fixed?
[14:36:14] <KGB-linuxcnc> 03Chris Radek 052.6 2374e3e 06linuxcnc 10scripts/linuxcnc.in 10src/emc/task/emctask.cc More removal of noise from nonerrors, following todo-2.6 #26 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2374e3e
[14:59:29] <seb_kuzminsky> i think all bug reports should include a phrase like "it goes *donk*"
[15:06:15] <cradek> are you making fun of my bug-reporting skills?
[15:06:33] <seb_kuzminsky> no!
[15:06:34] <seb_kuzminsky> yes...
[16:10:25] <memleak> XD
[16:24:37] <seb_kuzminsky> cradek: yeah, i didn't realize we had threads.0 when i openend #349
[16:29:47] <seb_kuzminsky> it was sloppy of me, but it's nice to find out something i want is already there
[17:21:13] <cradek> it may not be as perfect a test as you'd like, but it sure does detect that problem
[17:21:43] <cradek> something slow in the slow thread (between those two functions) would make it trigger in no time
[17:21:53] <cradek> er in the fast thread, I mean
[17:38:09] <seb_kuzminsky> yeah