Back
[00:02:00] -!- Tom_L [Tom_L!~Tl@unaffiliated/toml/x-013812] has joined #linuxcnc-devel
[00:04:22] -!- Nick001-shop has quit [Quit: ChatZilla 0.9.90.1 [Firefox 30.0/20140605174243]]
[00:07:04] <jepler> > 0100a840 00000000 00000000 00000000 00000000
[00:07:04] <jepler> < aaaaaaaa 55aacafe 54534f48 32544f4d 00000400
[00:07:04] <jepler> > 040ca840 00000000 00000000 00000000 00000000
[00:07:04] <jepler> < aaaaaaaa 4153454d 33344937 00000190 00000090
[00:07:07] <jepler> the rest is easy
[00:09:19] <jepler> just looking at a few reps of those two transactions, the level translator seems to be working up to 33MHz but not at 40MHz.
[00:09:50] <jepler> which is in line with my expectations from the datasheet
[00:10:39] -!- Tom_L has quit []
[00:11:02] <jepler> PCW: it's alive ^^^
[00:11:36] <PCW> Well jolly good!
[00:13:07] -!- syyl has quit [Ping timeout: 245 seconds]
[00:17:58] -!- skunkworks has quit [Ping timeout: 264 seconds]
[00:18:10] <PCW> at 33 Mhz its not that different than target only PCI speed wise (~1 usec.transaction)
[00:18:12] <PCW> obviously bursting multiple channels of register data is better
[00:24:18] <jepler> yeah I think that'll be necessary
[00:27:41] <jepler> hmm interesting note #1: speed limit drops to ~12MHz when the logic analyzer is powered on
[00:28:08] <PCW> maybe termination issues
[00:28:55] <jepler> interesting and distressing note #2: there's a ~10us gap between the first and second word of a single transfer, and a ~75us gap between the first transfer and the second transfer
[00:29:05] <jepler> PCW: yes, this board iteration doesn't have termination, that's on the list for next board
[00:29:08] <jepler> bbiab
[00:34:22] -!- tjb1 has quit [Ping timeout: 250 seconds]
[00:37:50] -!- tjb11 has quit [Ping timeout: 250 seconds]
[00:38:13] <jepler> so the 10us gap is because I organize one read as two transactions submitted at the same time (similar to writev). apparently that's just not performant
[00:38:31] <jepler> but the 75us gap is pretty unacceptable too, so I'll need hm2_eth-style buffering
[00:38:35] <jepler> good thing somebody wrote that .. thanks, micges
[00:39:03] -!- tjb111 has quit [Ping timeout: 240 seconds]
[00:40:46] -!- tjb1 has quit [Ping timeout: 264 seconds]
[00:47:13] <jepler> int r;
[00:47:13] <jepler> r = spidev_set_mode(dev, mode);
[00:47:22] <jepler> gcc says 'r may be used uninitialized in this function'
[00:47:23] <jepler> whaaa
[00:48:56] -!- ries has quit [Quit: ries]
[00:53:17] <PCW> Yeah Ethernet/SPI even DMA type interfaces are similar
[00:54:28] <PCW> wheres the 75 usec from? is that because you are using the kernel driver for the SPI?
[00:56:04] <jepler> http://emergent.unpythonic.net/files/sandbox/delay-between-spi.png
[00:56:47] <jepler> I think some of it is due to debug prints
[00:56:56] <seb_kuzminsky> jepler: is spidev_set_mode() a macro?
[00:57:17] <jepler> seb_kuzminsky: no it's a function which says 'return ioctl(...)'
[00:57:46] <jepler> updated the scope capture with debug prints off
[00:58:15] <jepler> program just does ioctl(SPI_IOC_MESSAGE) twice back to back. it is not running at realtime speed, but I doubt that's the real deal
[00:58:27] <jepler> I mean, I doubt that's the cause
[00:58:43] <jepler> ugh, I hope there's not some other device in the system that's sharing this SPI but with a different chip select
[00:59:30] -!- tjb11 has quit [Ping timeout: 250 seconds]
[00:59:36] <jepler> int spidev_set_mode(struct spidev *dev, uint8_t mode) {
[00:59:36] <jepler> return ioctl(dev->fd, SPI_IOC_WR_MODE, &mode);
[00:59:36] <jepler> }
[00:59:48] <jepler> spidev.c:51:9: warning: ‘r’ may be used uninitialized in this function [-Wmaybe-uninitialized]
[00:59:51] <jepler> int r = spidev_set_mode(dev, mode);
[01:01:46] -!- sylphiae has quit [Ping timeout: 264 seconds]
[01:08:48] -!- anth0ny_ has quit [Quit: anth0ny_]
[01:08:50] tjb11 is now known as tjb1
[01:12:07] -!- tjb111 has quit [Ping timeout: 255 seconds]
[01:34:22] -!- Tom_L [Tom_L!~Tl@unaffiliated/toml/x-013812] has joined #linuxcnc-devel
[01:36:54] -!- Tom_L has quit [Client Quit]
[01:53:12] -!- sumpfralle has quit [Ping timeout: 260 seconds]
[01:55:19] -!- brianmorel99 [brianmorel99!~brianmore@h75-100-180-199.mgtnmi.dsl.dynamic.tds.net] has joined #linuxcnc-devel
[02:17:33] <CaptHindsight> jepler: according to the schematic the SPI pins go from the pads on the SOC right out to the headers, no passives, no other connections
[02:18:53] -!- brianmorel99 has quit [Quit: brianmorel99]
[02:42:33] -!- anth0ny_ has quit [Quit: anth0ny_]
[02:48:03] <jepler> http://paste.debian.net/116845/
[02:48:12] <jepler> stepgen steps over spi
[02:49:09] <jepler> however, the watchdog keeps biting
[02:49:23] <jepler> halcmd: setp hm2_7i43spi.0.watchdog.has_bit 0
[02:49:23] <jepler> halcmd: hm2/hm2_7i43spi.0: trying to recover from IO error or Watchdog bite
[02:49:26] <jepler> hm2/hm2_7i43spi.0: error recover successful!
[02:49:28] <jepler> hm2/hm2_7i43spi.0: Watchdog has bit! (set the .has-bit pin to False to resume)
[02:50:26] <jepler> hmm running a 2ms thread "fixes" it
[02:50:35] <jepler> not for long
[02:50:40] <jepler> Unexpected realtime delay on task 0
[02:50:40] <jepler> This Message will only display once per session.
[02:50:40] <jepler> Run the Latency Test and resolve before continuing.
[02:50:40] <jepler> hm2/hm2_7i43spi.0: Watchdog has bit! (set the .has-bit pin to False to resume)
[02:50:43] <jepler> hmmm
[02:51:08] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[02:52:41] <skunkworks> logger[psha]:
[02:54:20] -!- MoserLabs has quit [Ping timeout: 260 seconds]
[02:55:50] <skunkworks> jepler: looks like your getting close
[02:57:21] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/cleanup-src-configure fc5f833 06linuxcnc 10src/configure.in src/configure: remove --enable-run-in-place * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fc5f833
[02:57:21] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/cleanup-src-configure 83854db 06linuxcnc 10src/configure.in src/configure: use AS_HELP_STRING() everywhere * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=83854db
[02:57:21] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/cleanup-src-configure b8b7e1e 06linuxcnc 10src/configure.in src/configure: --enable-simulator deprecation warning * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b8b7e1e
[02:57:37] <jepler> bumping spi speed and lowering servo rate makes it more stable
[02:57:41] <jepler> but who wants a 2ms servo rate?
[02:58:03] -!- sirdancealot has quit [Ping timeout: 240 seconds]
[02:58:13] <seb_kuzminsky> increase the watchdog timeout for now?
[02:59:11] <pcw_home> preemt-rt?
[02:59:17] -!- AR_ has quit [Ping timeout: 272 seconds]
[02:59:59] <jepler> oh hah -- I was using a 1.2MHz SPI clock, not 12MHz
[03:00:04] <jepler> that should help
[03:00:07] <jepler> PCW: yes
[03:05:04] <jepler> http://emergent.unpythonic.net/files/sandbox/clockwork-2ms.png
[03:05:10] <jepler> now it's running like clockwork with a 2ms thread
[03:05:34] <jepler> 8MHz SPI clock (even 12MHz is marginal with the logic analyzer in the mix)
[03:05:45] <jepler> let's see what it looks like come morning...
[03:06:52] <jepler> (the keen eye will count 4 packets per cycle :-/)
[03:07:55] <pcw_home> does the logic analyser use passive (resistove divider) probes? it will really screw up the signals (especially the clock) if not
[03:09:02] <pcw_home> (a Tee connection is not allowed on the clock line)
[03:09:10] <skunkworks> that looks like it should run at 1ms - right?
[03:09:18] <jepler> skunkworks: yes probably
[03:09:18] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 6911ff5 06linuxcnc 10src/Makefile build: -fstrict-overflow is redundant with -fwrapv * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6911ff5
[03:09:18] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 50b314c 06linuxcnc 10src/emc/pythonplugin/python_plugin.cc 10src/emc/pythonplugin/python_plugin.hh pythonplugin: remove unused fields * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=50b314c
[03:09:18] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master e200957 06linuxcnc 10src/emc/task/taskclass.hh taskclass: remove unused field * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e200957
[03:09:20] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master cc52288 06linuxcnc 10src/emc/tp/tp.c tp: Remove unused functions * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cc52288
[03:09:24] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 4be68a2 06linuxcnc 10src/emc/usr_intf/axis/extensions/_toglmodule.c togl: cast to avoid warning * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4be68a2
[03:09:27] <skunkworks> jepler: nice!@
[03:09:28] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 9b133bb 06linuxcnc 10src/emc/usr_intf/axis/extensions/emcmodule.cc emcmodule: Disable invalid offsetof warnings explicitly * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9b133bb
[03:09:30] <jepler> PCW: passive probes to a buffer chip of some sort
[03:09:32] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 783203a 06linuxcnc 10src/hal/classicladder/files_project.c 10src/hal/classicladder/files_sequential.c ladder: get rid of unused dbg_printf * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=783203a
[03:09:37] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 4cb7707 06linuxcnc 10src/hal/utils/halrmt.c halrmt: If you mean NULL, say NULL * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4cb7707
[03:09:41] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master b86857c 06linuxcnc 10src/libnml/buffer/memsem.cc nml: 'register' is a deprecated keyword * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b86857c
[03:09:45] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 06241b9 06linuxcnc 10src/rtapi/uspace_rtapi_app.cc uspace: Don't call RtapiApp a struct * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=06241b9
[03:09:48] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 3fff9c0 06linuxcnc 10src/rtapi/vsnprintf.h rtapi: don't uselessly test if an unsigned is less than zero * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3fff9c0
[03:09:52] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 13a2349 06linuxcnc 10src/emc/rs274ngc/interp_convert.cc 10src/emc/rs274ngc/rs274ngc_interp.hh interp: use strings to avoid buffer hell * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=13a2349
[03:09:57] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 2c11d6f 06linuxcnc 03src/hal/drivers/mesa-hostmot2/hm2_spi.c hostmot2: support boards on spi interface * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2c11d6f
[03:10:24] <jepler> PCW: M74LCX16245DTR2G buffer
[03:10:59] <pcw_home> Yeah so not a probe
[03:11:25] <jepler> nothing like a proper probe, this is something they can chuck out at $50 a pop and make money
[03:11:59] <pcw_home> I would try without probing the clock line
[03:12:04] -!- anarchos has quit [Ping timeout: 260 seconds]
[03:12:53] <jepler> Unexpected realtime delay on task 0
[03:12:53] <jepler> This Message will only display once per session.
[03:12:53] <jepler> Run the Latency Test and resolve before continuing.
[03:12:53] <jepler> hm2/hm2_7i43spi.0: Watchdog has bit! (set the .has-bit pin to False to resume)
[03:13:04] <jepler> I think the realtime is dodgy, this happened again.
[03:13:09] <jepler> probably while I was git pushing or something :-/
[03:13:34] <skunkworks> idle=poll!
[03:13:42] <jepler> skunkworks: does that even do anything on an arm?
[03:14:18] <seb_kuzminsky> awesome jepler
[03:14:38] <jepler> it sure must indicate a real problem when I get a realtime delay followed immediately by watchdog bite
[03:15:09] <pcw_home> does the latency test have reasonable numbers?
[03:16:26] <jepler> PCW: OK if you're not stressing it, borderline if you are
[03:18:55] <pcw_home> is the "Unexpected realtime delay" message still printed with a > 20% of period delay? (400 usec at 2 ms thread rate)
[03:19:30] <skunkworks> jepler: no clue
[03:19:45] <jepler> PCW: no.
[03:20:08] <jepler> PCW: before sleeping, it checks the current time. If that's later than the target time of the next period, a realtime delay is logged.
[03:21:00] <jepler> I should probably log the target and actual times
[03:22:06] <pcw_home> is halscope working?
[03:22:41] <jepler> hmm did I bump a wire? now all reads are coming back all ones
[03:22:45] <jepler> it must be time to call it a night
[03:22:53] <jepler> PCW: yes, I should log the function times via halscope
[03:23:11] <pcw_home> plotting the read and write times is instructive
[03:23:40] <pcw_home> I suspect the low level SPI driver
[03:24:09] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 23cc00f 06linuxcnc 10src/Makefile 03src/hal/drivers/mesa-hostmot2/hm2_spi.c hostmot2: support boards on spi interface * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=23cc00f
[03:25:30] <CaptHindsight> idel=poll is x86 only iirc
[03:25:35] <pcw_home> (I suspect its where the delays are coming from)
[03:27:47] -!- Thetawaves has quit [Quit: This computer has gone to sleep]
[03:28:32] <jepler> http://emergent.unpythonic.net/files/sandbox/thread-timing.png
[03:28:52] <jepler> times are in units of 1 = 1ns
[03:29:12] -!- Tecan has quit [Quit: Live Long And Phosphor!]
[03:29:20] <jepler> so yeah, sometimes the read and write functions take a very very long time
[03:31:19] <jepler> anyway, goodnight
[03:31:24] <pcw_home> hmm just like the parallel port, might have to poke at the SPI hardware directly
[03:31:24] <jepler> it was still good progress!
[03:31:37] <jepler> yucky but possible
[03:31:57] <pcw_home> yes quite a big step
[03:34:11] <CaptHindsight> if the file /dev/cpu_dma_latency exists, open it and write a zero into it. This will tell the power management system not to transition to a high cstate (in fact, the system acts like idle=poll) When the fd to /dev/cpu_dma_latency is closed, the behavior goes back to the system default.
[03:35:02] <jepler> umm
[03:35:11] <jepler> it turns out I may have failed to "sudo make setuid" for at least this most recent test
[03:35:35] <jepler> CaptHindsight: linuxcnc does that
[03:35:46] <jepler> CaptHindsight: (is that helpful in rtai too?)
[03:37:18] <memleak> jepler, does -ffreestanding imply -fno-builtin-sin/cos?
[03:37:31] <jepler> memleak: yes
[03:37:40] <memleak> ok so i have redundant CFLAGS
[03:37:46] <jepler> hm2_eth-objs := \
[03:37:46] <jepler> hal/drivers/mesa-hostmot2/hm2_eth.o \
[03:37:48] <jepler> oops
[03:37:51] <jepler> http://emergent.unpythonic.net/files/sandbox/thread-timing-setuid.png
[03:38:03] <jepler> it's substantially better when actually running with realtime priority
[03:38:19] <jepler> (same scale per div as last image)
[03:38:37] <jepler> worst case is much less worse
[03:38:55] <jepler> 'night
[03:43:08] <memleak> night!
[03:55:05] -!- anth0ny_ has quit [Quit: anth0ny_]
[04:02:05] -!- Roguish has quit [Ping timeout: 260 seconds]
[04:03:07] -!- asdfasd has quit [Ping timeout: 255 seconds]
[04:05:59] brad_ is now known as Guest5635
[04:06:45] -!- shaun413 has quit [Ping timeout: 240 seconds]
[04:11:12] <CaptHindsight> pcw_home: we tested the Norther Islands gpu hardware accel driver with 3.14 RTAI and latency is much better without it :(
[04:11:40] <CaptHindsight> Norther/Northern
[04:14:10] <linuxcnc-build> build #2352 of 1200.rip-lucid-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/2352 blamelist: Jeff Epler <jepler@unpythonic.net>, dummy
[04:14:19] -!- patrickarlt has quit [Quit: Leaving...]
[04:15:34] <CaptHindsight> pcw_home: that BIOSTAR A68N-2100 AMD E1-2100 has a Radeon™ HD 8210 so I expect it to have the same results until there's a driver fix, but I can't confirm it
[04:18:19] <linuxcnc-build> build #2149 of 1901.clang-precise-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1901.clang-precise-amd64/builds/2149 blamelist: Jeff Epler <jepler@unpythonic.net>, dummy
[04:18:49] <CaptHindsight> the BIOSTAR A68N-5000 AMD A4-5000 Quad-Core has a HD 8330 and uses the same gpu hardware accel driver
[04:21:46] <linuxcnc-build> build #2351 of 1300.rip-precise-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/2351 blamelist: Jeff Epler <jepler@unpythonic.net>, dummy
[04:22:46] <linuxcnc-build> build #2353 of 1306.rip-precise-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/2353 blamelist: Jeff Epler <jepler@unpythonic.net>, dummy
[04:34:44] <linuxcnc-build> build #509 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/509 blamelist: Jeff Epler <jepler@unpythonic.net>, dummy
[04:34:52] <linuxcnc-build> build #700 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/700 blamelist: Jeff Epler <jepler@unpythonic.net>, dummy
[04:36:29] <linuxcnc-build> build #509 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/509 blamelist: Jeff Epler <jepler@unpythonic.net>, dummy
[04:36:48] <linuxcnc-build> build #20 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/20 blamelist: Jeff Epler <jepler@unpythonic.net>, dummy
[04:38:26] <seb_kuzminsky> for once the buildbot reports an actual error with linuxcnc of interest to developers
[04:38:40] <seb_kuzminsky> instead of the usual, false positives of interest only to seb
[04:39:49] <linuxcnc-build> build #2352 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/2352 blamelist: Jeff Epler <jepler@unpythonic.net>, dummy
[04:40:23] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master eebad1f 06linuxcnc 10src/configure.in src/configure: remove --enable-run-in-place * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=eebad1f
[04:40:23] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master c70ccc2 06linuxcnc 10src/configure.in src/configure: use AS_HELP_STRING() everywhere * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c70ccc2
[04:40:23] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master acaecf0 06linuxcnc 10src/configure.in src/configure: --enable-simulator deprecation warning * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=acaecf0
[04:40:44] <KGB-linuxcnc> 05seb/master/cleanup-src-configure b8b7e1e 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b8b7e1e
[04:45:58] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/deb-cleanup cd08a72 06linuxcnc 10debian/rules.in deb: remove unused variable in debian/rules * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cd08a72
[04:45:58] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/deb-cleanup 2d167bb 06linuxcnc 10debian/rules.in deb: debian/rules doesn't need to care about BUILD_SYS * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2d167bb
[04:45:58] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/deb-cleanup 95fdd52 06linuxcnc 10debian/.gitignore deb: dont .gitignore package-dirs we no longer build * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=95fdd52
[04:46:00] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/deb-cleanup 0d7457a 06linuxcnc 10debian/control.in deb: get rid of ancient Provides in control * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0d7457a
[04:48:04] <CaptHindsight> jepler: we are going to test /dev/cpu_dma_latency and see if it has any effect on RTAI
[04:56:16] <memleak> makes latency worse by several million
[04:56:29] <memleak> (ns)
[05:01:10] <memleak> well it did, now its not doing anything. one moment..
[05:02:26] -!- Fox_Muldr has quit [Ping timeout: 260 seconds]
[05:05:47] -!- kwallace3 [kwallace3!~kwallace@smb-41.sonnet.com] has parted #linuxcnc-devel
[05:07:23] <linuxcnc-build> build #2358 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2358 blamelist: Jeff Epler <jepler@unpythonic.net>, dummy
[05:10:42] -!- syyl has quit [Ping timeout: 245 seconds]
[05:17:57] -!- dzzig_nz has quit [Read error: Connection reset by peer]
[05:19:54] -!- ve7it has quit [Remote host closed the connection]
[05:34:51] -!- mhaberler has quit [Quit: mhaberler]
[05:42:46] -!- jerryitt has quit [Quit: Connection closed for inactivity]
[05:49:45] <memleak> after futher testing, with radeon kms on northern islands it stays around 30 microseconds
[05:50:05] <memleak> without it, it stays around 50 or 60 microseconds
[05:50:13] <memleak> referring to /dev/cpu_dma_latency 1 vs 0
[05:50:29] <memleak> (writing 0 improves latency results)
[06:00:14] -!- anth0ny_ has quit [Quit: anth0ny_]
[06:03:09] -!- kwallace [kwallace!~kwallace@tmb-219.sonnet.com] has joined #linuxcnc-devel
[06:04:44] -!- mhaberler has quit [Quit: mhaberler]
[06:04:52] -!- kwallace4 has quit [Ping timeout: 245 seconds]
[06:27:41] -!- gonzo_nb has quit [Remote host closed the connection]
[06:54:57] -!- Thetawaves has quit [Quit: This computer has gone to sleep]
[06:55:01] -!- archivist_herron has quit [Ping timeout: 255 seconds]
[06:55:08] -!- mhaberler has quit [Quit: mhaberler]
[06:57:25] -!- anarchos has quit [Ping timeout: 272 seconds]
[06:57:34] -!- jepler has quit [Ping timeout: 264 seconds]
[07:00:27] -!- jepler [jepler!~jepler@emc/developer/pdpc.professional.jepler] has joined #linuxcnc-devel
[07:07:10] -!- anarchos has quit [Ping timeout: 264 seconds]
[07:15:26] -!- archivist_herron has quit [Ping timeout: 260 seconds]
[07:36:00] -!- Komzzpa has quit [Ping timeout: 250 seconds]
[07:40:46] -!- archivist_herron has quit [Ping timeout: 264 seconds]
[07:57:45] -!- Groguard has quit [Read error: Connection reset by peer]
[08:22:22] -!- archivist_herron has quit [Ping timeout: 250 seconds]
[08:35:51] -!- FreezingCold has quit [Ping timeout: 246 seconds]
[08:46:38] -!- The_Ball has quit [Ping timeout: 250 seconds]
[08:50:54] -!- sumpfralle has quit [Ping timeout: 246 seconds]
[08:58:25] -!- archivist_herron has quit [Ping timeout: 260 seconds]
[09:05:30] -!- sylphiae has quit [Read error: Connection reset by peer]
[09:05:53] -!- The_Ball has quit [Read error: Connection timed out]
[09:09:24] -!- cradek_ [cradek_!~chris@outpost.timeguy.com] has joined #linuxcnc-devel
[09:09:47] -!- cradek has quit [Read error: Connection reset by peer]
[09:21:52] -!- archivist_herron has quit [Ping timeout: 240 seconds]
[09:26:21] -!- dudepdx has quit [Ping timeout: 240 seconds]
[09:32:38] -!- dudepdx has quit [Ping timeout: 260 seconds]
[09:39:10] -!- archivist_herron has quit [Ping timeout: 250 seconds]
[09:40:31] -!- mahtennek has quit []
[09:42:47] -!- b_b has quit [Changing host]
[10:03:07] -!- archivist_herron has quit [Ping timeout: 245 seconds]
[10:12:11] -!- Valen has quit [Quit: Leaving.]
[10:16:42] -!- ITChap has quit [Quit: Leaving.]
[10:26:28] -!- zewan [zewan!~alexx@217.76.69.31] has joined #linuxcnc-devel
[10:35:31] -!- skunkworks has quit [Ping timeout: 255 seconds]
[10:41:42] -!- archivist_herron has quit [Ping timeout: 260 seconds]
[10:50:15] -!- dudepdx has quit [Ping timeout: 246 seconds]
[10:58:03] -!- zewan has quit [Ping timeout: 240 seconds]
[11:01:11] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[11:01:37] -!- balestrino has quit [Ping timeout: 255 seconds]
[11:12:47] -!- sirdancealot has quit [Ping timeout: 245 seconds]
[11:35:08] -!- dudepdx has quit [Ping timeout: 260 seconds]
[11:36:43] -!- sirdancealot has quit [Ping timeout: 255 seconds]
[11:42:27] -!- dudepdx has quit [Ping timeout: 255 seconds]
[11:46:33] -!- karavanjo has quit [Ping timeout: 240 seconds]
[11:49:15] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 62f34ef 06linuxcnc 10src/Makefile 03src/hal/drivers/mesa-hostmot2/hm2_spi.c hostmot2: support boards on spi interface * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=62f34ef
[12:00:12] -!- Lathe_newbie has quit [Ping timeout: 245 seconds]
[12:02:58] -!- dudepdx has quit [Read error: Connection reset by peer]
[12:08:22] -!- asdfasd has quit [Ping timeout: 264 seconds]
[12:23:35] cradek_ is now known as cradek
[12:24:05] -!- cradek has quit [Changing host]
[12:24:05] -!- cradek [cradek!~chris@emc/board-of-directors/cradek] has joined #linuxcnc-devel
[12:24:05] -!- mode/#linuxcnc-devel [+v cradek] by ChanServ
[12:28:20] -!- Guest5635 has quit [Quit: Page closed]
[12:32:32] <jepler> weird, one of the SPI transactions is just the command 0000a800 with no payload
[12:32:35] <jepler> must be a bug
[12:35:05] <jepler> (I think that's 'read 0 words starting at 0000 with increment')
[12:35:09] -!- zeitue has quit [Quit: Leaving]
[12:38:22] -!- Bernd__ has quit [Quit: ChatZilla 0.9.90.1 [Firefox 11.0/20120310193829]]
[12:48:26] -!- Bernd has quit [Ping timeout: 250 seconds]
[12:58:23] Bernd is now known as LunaX
[13:08:12] <jepler> I wish I could find accurate info about what header to use to mate with the u3's 2mm-pitch headers
[13:08:49] <jepler> the part I chose does not stay snug on its own like .100 headers do
[13:09:33] <jepler> the odroid makers do not say what the part is on the u3 side, and they give inaccurate information about what it is on the side of their own i/o board
[13:09:59] <jepler> (bom gives a part number but the length of pins is obviously not what they show in the photos)
[13:10:26] <jepler> maybe they don't mate tightly anyway; they say you MUST use a metal spacer between the boards, which would also keep it from all just falling apart
[13:14:08] <jepler> pcw_home: so you think I should put 82ohm series termination resistors on all the outputs (cs/, clk, mosi) and no termination on miso?
[13:15:43] -!- dudepdx has quit [Ping timeout: 255 seconds]
[13:22:48] -!- dudepdx has quit [Ping timeout: 255 seconds]
[13:30:43] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 0d7457a 06linuxcnc fast forward * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0d7457a
[13:31:18] <KGB-linuxcnc> 05seb/master/deb-cleanup 0d7457a 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0d7457a
[13:40:48] -!- dudepdx has quit [Ping timeout: 255 seconds]
[13:41:38] -!- kwallace1 [kwallace1!~kwallace@tmb-219.sonnet.com] has joined #linuxcnc-devel
[13:49:12] -!- jduhls has quit [Ping timeout: 250 seconds]
[13:56:12] -!- Roguish [Roguish!~chatzilla@c-67-188-44-176.hsd1.ca.comcast.net] has joined #linuxcnc-devel
[14:00:18] -!- dudepdx has quit [Ping timeout: 246 seconds]
[14:10:09] -!- Roguish has quit [Ping timeout: 260 seconds]
[14:11:55] <jepler> cradek: oshpark does do 4-layer boards but they're more expensive
[14:12:43] <jepler> $10/in2 instead of $5/in2
[14:14:20] <CaptHindsight> jepler: what length are the pins on the 2mm headers? I can search by parameters
[14:14:47] <jepler> (for 3 copies, so it's really $3.33 and $1.66/in2; for "medium runs" of at least 150in2 they go down to $2 and $1/in2)
[14:15:44] <jepler> CaptHindsight: I don't know :-/ I don't have their I/O board, just a photograph
[14:16:23] <jepler> CaptHindsight: I haven't done much with 2mm headers, is it typical that they are a much looser fit than the .100 headers I'm used to?
[14:16:48] -!- dudepdx has quit [Ping timeout: 255 seconds]
[14:17:15] <CaptHindsight> jepler: if they are square post then they are friction fit just like the .100 headers you are used to
[14:17:18] -!- LunaX has quit [Quit: ChatZilla 0.9.90.1 [Firefox 26.0/20131205075310]]
[14:17:59] <jepler> I suspect that the posts on the male headers I ordered may just be too short
[14:18:14] <jepler> the ARM board has female 2mm headers but they don't publish a bom
[14:18:39] <jepler> the I/O board has male 2mm headers that they say are CON-A3B-8PA-2DSA
[14:19:32] <jepler> which has a 3.5mm height, .5x.5mm square post
[14:19:54] <jepler> but from the pictures, it can be seen that they're longer than 3.5mm
http://www.hardkernel.com/main/products/prdt_info.php?g_code=G138760240354&tab_idx=1
[14:20:20] <jepler> more on the order of 6mm, but that's just an estimate
[14:21:08] <CaptHindsight> yes, or longer
[14:21:45] <jepler> and of course we know that the spacer they use is 11mm
[14:22:47] -!- jerryitt has quit [Quit: Connection closed for inactivity]
[14:22:51] <jepler> I assume the 11mm distance was driven by needing to clear any parts on the bottom side of the U3, and they bought the headers accordingly
[14:23:37] <jepler> (top side the way they assemble it with the I/O board)
[14:26:34] <memleak> any idea why latency-test and RTAI testsuite show two completely different latency results?
[14:27:01] <jepler> memleak: we've talked about various reasons, want me to review the ones I know about?
[14:27:09] -!- dudepdx has quit [Ping timeout: 240 seconds]
[14:27:12] <memleak> yes please!
[14:27:29] <jepler> * rtai kern/latency has a different CPU selection algorithm than LinuxCNC (rtai binds to CPU 1, LinuxCNC binds to last CPU)
[14:28:15] <jepler> * rtai kern/latency measures "actual time minus nominal time", while linuxcnc latency-test measures "(this time - last time) - nominal_time"
[14:28:38] <jepler> * rtai kern/latency has 1 thread, by default linuxcnc latency-test has two threads
[14:28:46] <jepler> those are the three main items I know of
[14:28:54] <memleak> ok thanks
[14:29:08] <jepler> for the rtai we ship, it might be worth changing the kern/latency CPU selection algorithm so it's the same as LinuxCNC
[14:29:40] <jepler> in linuxcnc, we should probably change our latency-test to use (actual - nominal) like kern/latency, except rtapi has no API for "get nominal time of this thread invocation"
[14:29:59] <jepler> (rtai does, and uspace could, but rtapi has never exposed this number)
[14:30:01] <memleak> or make linuxcnc use the RTAI cpu algorithm considering results are only bad in linuxcnc
[14:31:36] <memleak> (instead of vice versa)
[14:32:10] <CaptHindsight> jepler: what I could find in stock at Digikey was only 5mm length pins
http://tinyurl.com/kjpswpl
[14:32:11] <jepler> except for how it interacts with isolcpus=, why should any choice of CPU be different than another?
[14:32:56] <memleak> thats what im wondering. it shouldnt matter. maybe its one of the other two reasons.
[14:33:29] <memleak> how difficult would it be to make it measure latency the same way and run on two threads?
[14:33:34] <jepler> CaptHindsight: what I have is 951208-8622-AR (4.4mm)
[14:33:34] -!- dudepdx has quit [Ping timeout: 255 seconds]
[14:34:07] <jepler> CaptHindsight: thanks for looking
[14:36:20] -!- anth0ny_ has quit [Quit: anth0ny_]
[14:36:21] <CaptHindsight> jepler: anything over that length is non-stock :(
[14:37:48] <CaptHindsight> you could just make some longer ones, cut square posts to length
[14:38:21] -!- thedude has quit [Ping timeout: 240 seconds]
[14:39:45] <jepler> fabricating my own pin headers doesn't sound like an enjoyable use of time
[14:42:29] <CaptHindsight> solder in the pins, snip to length
[14:44:26] -!- Roguish [Roguish!~chatzilla@c-67-188-44-176.hsd1.ca.comcast.net] has joined #linuxcnc-devel
[14:45:47] -!- anth0ny_ has quit [Client Quit]
[14:46:15] <jepler> where do I get 0.5mm square stock?
[14:46:23] <CaptHindsight> place pins into female header, place pcb onto pins, set required spacing, solder backside, snip off excess pin from backside
[14:46:32] <CaptHindsight> checking on that
[14:50:19] <jepler> and of course going that route it wouldn't be nice gold and tin plating over the contact and solder areas
[14:50:20] -!- mozmck has quit [Read error: Connection reset by peer]
[14:50:43] <jepler> mouser has some hirose, harwin, and 3m headers in stock, but none with longer pins than I got the first time
[14:51:43] -!- mozmck [mozmck!~moses@67.210.159.245] has joined #linuxcnc-devel
[14:53:32] <CaptHindsight> do 0.64mm pins fit in to the sockets?
[14:54:31] <cradek> can you just use appropriate gauge copper wire cut to length?
[14:55:27] <CaptHindsight> what I would do for a proto and just want to test ^^
[14:56:08] <jepler> the prototype is OK, but you have to take care not to bump it
[14:56:45] <jepler> CaptHindsight: I don't know (is .64mm the typical post size of .100" headers?)
[14:56:53] <CaptHindsight> jepler: yes
[14:57:43] <jepler> I initially used these jumpers which are designed for .100 and they fit
https://www.sparkfun.com/products/12795
[14:58:00] <CaptHindsight> can you temp the board in place using hot melt?
[14:58:08] <jepler> don't want to!
[14:58:16] <CaptHindsight> keep it from vibrating loose
[14:59:42] <jepler> samtec.com will let me customize post height in .005" increments
[15:00:14] <CaptHindsight> if those fit then you can use pins from longer length pin .100 headers, it's hacky but it will work for a proto
[15:03:07] <jepler> bbl, thanks for the good ideas
[15:12:43] -!- dudepdx has quit [Ping timeout: 255 seconds]
[15:21:08] -!- gene78 has quit [Remote host closed the connection]
[15:23:23] -!- dudepdx has quit [Ping timeout: 240 seconds]
[15:24:52] -!- mle has quit [Ping timeout: 240 seconds]
[15:28:48] -!- dudepdx has quit [Ping timeout: 255 seconds]
[15:32:04] -!- karavanjo has quit [Ping timeout: 255 seconds]
[15:38:33] -!- SquirrelCZECH has quit [Remote host closed the connection]
[15:45:12] -!- patrickarlt has quit [Remote host closed the connection]
[15:50:24] -!- patrickarlt has quit [Ping timeout: 260 seconds]
[15:54:32] -!- Benjamin23 has quit [Remote host closed the connection]
[15:55:54] -!- BellinganRoy has quit [Quit: Konversation terminated!]
[15:58:30] -!- `Nerobro has quit [Ping timeout: 255 seconds]
[16:05:17] -!- karavanjo_ has quit [Ping timeout: 245 seconds]
[16:12:51] <pcw_home> jepler: yes: series termination on all cable driving pins is good but the clock is by far the fussiest
[16:12:52] <pcw_home> Pretty sure MMT Machrone has 2 mm headers in ~1 mm length steps from about 2 to 18 mm post heights
[16:14:19] <jepler> pcw_home: and I don't terminate MISO / 7i90's SPIOUT simply because I'm not the driving side?
[16:14:37] <pcw_home> Yes
[16:14:48] <pcw_home> thats done in the ucf file
[16:14:55] <jepler> aha
[16:15:11] <pcw_home> (setting the drive strength to 4 ma)
[16:18:14] <pcw_home> 4 ma drive ~= 100 ohm output impedance
[16:19:52] <jepler> how does that calculation work?
[16:20:11] <pcw_home> its obscure...
[16:20:18] -!- dudepdx has quit [Ping timeout: 246 seconds]
[16:20:22] <jepler> OK, I'll go into "taking word for it" mode
[16:21:17] -!- patrickarlt has quit [Remote host closed the connection]
[16:21:32] <pcw_home> what 4 ma drive ~means is that it meets the standard TTL specs of 0.40v VOL with 4 mA pullup
[16:23:24] <pcw_home> so ~100 ohms max (I also looked at it driving cables with a scope)
[16:23:56] <pcw_home> note the the waveform on the driving end will be wonky with series termination
[16:24:35] -!- phantoxe has quit []
[16:24:42] <jepler> OK, I can fit that into my worldview, thanks
[16:24:54] <pcw_home> (1/2 amplitude until the echo from the fard enc of the cable comes back)
[16:25:02] <pcw_home> far end
[16:25:42] -!- ITChap has quit [Quit: Leaving.]
[16:28:41] -!- aude has quit [Ping timeout: 272 seconds]
[16:35:07] -!- asah has quit [Quit: asah]
[16:39:54] <jepler> pcw_home: I'd appreciate any comments on
http://emergent.unpythonic.net/files/sandbox/oddspi.pdf
[16:43:52] <pcw_home> looks good, you might want a option to get 5V from the 7I90 header pin 26 (ar an external source)
[16:44:24] <jepler> you mean to use 5V as the reference, or to power the regulator?
[16:44:41] <pcw_home> to power the regulator
[16:50:47] <jepler> if both rails aren't powered, the outputs are all disabled, so I'm not sure what the benefit would be
[16:52:21] <jepler> this is confusing: "During operation, ensure that VCCA <= VCCB at all times. During power-up sequencing, VCCA >= VCCB does not damage the device, so any power supply can be ramped up first.
[16:52:25] <jepler> "
[16:58:45] -!- thedude has quit [Ping timeout: 240 seconds]
[17:02:24] -!- dudepdx has quit [Ping timeout: 255 seconds]
[17:04:10] <pcw_home> probably just means that it wont work if VCCA>VCCB but wont damage the device
[17:05:10] -!- almccon_ has quit [Read error: Connection reset by peer]
[17:06:07] <pcw_home> OK I didn't see the the Odriod can provide 5V
[17:08:56] -!- ashcan_ has quit [Client Quit]
[17:10:41] <CaptHindsight> what is between the header pins on the 7i90 and the FPGA pads? just copper?
[17:12:07] <CaptHindsight> TXB0104 is designed to drive capacitive loads of up to 70 pF
[17:13:09] -!- thedude has quit [Ping timeout: 240 seconds]
[17:13:51] <CaptHindsight> http://www.ti.com/lit/ds/symlink/txb0104.pdf
[17:16:42] <pcw_home> Theres a quickswitch for 5V tolerance when use with EPP
[17:16:49] <pcw_home> used
[17:17:35] <pcw_home> should be no more than 15pf or so load
[17:20:36] <pcw_home> I think the quickswitch is about 5 pF, and FPGA inputs are about 8/10 pF
[17:24:43] -!- asah has quit [Quit: asah]
[17:28:13] -!- dudepdx has quit [Ping timeout: 272 seconds]
[17:48:33] -!- patrickarlt has quit [Ping timeout: 260 seconds]
[17:56:38] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[17:57:15] -!- dudepdx has quit [Ping timeout: 246 seconds]
[18:07:27] <jepler> pcw_home: yeah, odroid is supplying 5V, not taking it as an input
[18:08:28] -!- sylphiae has quit [Quit: Leaving]
[18:09:10] <pcw_home> you _could_ power the 7I90 from the adapter but one 28 ga wire is pretty spindly
[18:09:45] <jepler> pcw_home: best for any number of reasons to leave sv1.26 disconnected, I think
[18:10:48] -!- dudepdx has quit [Ping timeout: 255 seconds]
[18:10:56] <jepler> is there a more sensible way to draw the u3 connector's symbol so that it's understood as the source of the 5v and 1.8v supplies?
[18:11:28] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 20.0/20130329043827]]
[18:12:11] <jepler> put it on the side instead of the top?
[18:14:13] <pcw_home> I dont know if there are conventions for power directions
[18:14:14] <pcw_home> (on multi sheet schematics ports can often have directions)
[18:14:35] <pcw_home> maybe just a note
[18:16:48] <jepler> I think it
[18:16:59] <jepler> 's possible, though inadvisable, to power the odroid via its 5V pin
[18:17:19] <jepler> inadvisable because you lose an overcurrent protection that exists at the power jack
[18:17:22] -!- asah has quit [Ping timeout: 245 seconds]
[18:18:04] <pcw_home> yeah and a bit more current than you want going through a 2mm connection
[18:19:40] <jepler> so the last thing I need to do is put a pair of mounting holes on this, so I can secure the 2mm connector with some screws and spacers
[18:20:40] <cradek> 2mm connectors should be secured with #2 screws
[18:22:05] <jepler> I think you're making a joke
[18:24:22] -!- tronwizard has quit [Ping timeout: 240 seconds]
[18:26:46] <jepler> but the schematic says the mounting holes are 3mm diameter
[18:27:25] <jepler> which doesn't match the diameter of any of the circles on the board dxf I have
[18:28:10] <cradek> oh then use #4-40
[18:28:23] <cradek> much more common anyway
[18:28:49] <skunkworks> I tapped some 10-32 on the k&t last week
[18:28:59] <skunkworks> in cast - so that was cheating...
[18:29:10] <jepler> probably the required spacer will be some odd length
[18:32:17] <jepler> but cradek has his little lathe so he can make me some spacers to length
[18:37:26] <cradek> yes a lathe I have
[18:37:57] <cradek> but sadly I have to pull off the spindle encoder (and its mounting adapters and hardware) in order to use ww collets in it
[18:38:22] <cradek> or the 6-jaw chuck
[18:38:50] <cradek> I could fix that by making a new drawtube
[18:38:55] <cradek> but yuck
[18:40:21] -!- amiri_ has quit [Read error: Connection reset by peer]
[18:45:56] -!- patrickarlt has quit [Remote host closed the connection]
[18:48:44] <jepler> I bet I want to take care not to flex the board by tightening it down on a too-short spaer
[18:49:37] -!- dudepdx has quit [Ping timeout: 255 seconds]
[18:50:55] <jepler> spacer
[18:51:22] -!- Loetmichel has quit [Ping timeout: 240 seconds]
[19:00:15] t12_ is now known as t12
[19:02:17] -!- mhaberler has quit [Quit: mhaberler]
[19:13:32] -!- Smidge204_ has quit [Client Quit]
[19:14:57] -!- syyl has quit [Ping timeout: 246 seconds]
[19:15:30] -!- Fuchikoma has quit [Ping timeout: 250 seconds]
[19:26:45] -!- marti____ has quit [Remote host closed the connection]
[19:38:20] -!- skunkworks has quit [Read error: Connection reset by peer]
[19:39:16] -!- acdha has quit [Quit: Textual IRC Client: www.textualapp.com]
[19:44:31] Guest67691 is now known as phantoxeD
[19:50:40] -!- onyedikilo has quit [Ping timeout: 246 seconds]
[19:59:03] <jepler> I decided to get one of these. I hope the seller starts to make some headway on his back-orders!
https://www.tindie.com/products/gxti/laureline-gps-ntp-server/
[19:59:59] -!- h_maximilian has quit [Client Quit]
[20:22:09] <cradek> looks cool
[20:27:50] -!- tjb1 has quit [Ping timeout: 260 seconds]
[20:30:20] <kwallace> Are the chips in digital (capacitive) calipers something common that could be hacked or replaced? I got a bunch of calipers with cracked LCD displays from eBay. Mine look a lot like :
https://www.flickr.com/photos/50241702@N04/5227386500/ and
https://www.flickr.com/photos/50241702@N04/5153277938/
[20:43:22] <jepler> I am not worried too much about the back-ordered status, tindie issues a refund if a backorder isn't fulfilled after 90 days
[20:43:50] <jepler> has anyone but me started having the experience that "internal" flickr links don't work the first time, but clicking them again works?
[20:43:57] <jepler> this happens to me routinely
[20:46:36] <jepler> kwallace: I had never thought about how those calipers work. It looks like it's a kind of vernier scale, with a lot of narrow capacitive sensors that move against the different scale fixed to the other jaw
[20:49:45] <PCW> I think they are kind of like a capacitive resolver
[20:50:19] <jepler> capacative touch sensor chips are cheap. this one has 12 channels.
https://www.sparkfun.com/products/9604
[20:50:49] <jepler> not sure how you could re-use the electronics package, converting the lines that drive the LCD into anything sensible would be harder than just making a custom board
[20:51:18] <PCW> I think they all have serial interfaces
[20:51:37] <jepler> these cheap digital calipers have?
[20:51:43] <PCW> yes
[20:51:52] <jepler> maybe it's easy then
[20:52:07] <kwallace> It looks like the narrow lines are grouped 1,5,9... 2,6,10... 3,7... and 4,8 so maybe quadrature sensing.
[20:52:11] <PCW> funny synchronous protocol
[20:52:29] <kwallace> http://www.shumatech.com/support/chinese_scales.htm
[20:52:51] <jepler> http://www.robotroom.com/Caliper-Digital-Data-Port/Pinout-of-imported-digital-caliper.png
[20:53:56] <jepler> I didn't spot anywhere on kwallace's board that looked like that set of 4 contacts
[20:55:10] <Tom_itx> jepler got in late.. what do you want to do with the data from the calipers?
[20:55:29] <jepler> Tom_itx: kwallace is just looking for a user for ones with broken LCDs
[20:55:42] <Tom_itx> ahh
[20:55:54] <kwallace> The link isn't to my board. I'll link it in a minute.
[20:56:42] <jepler> hm you only get about 3 samples per second
[20:56:47] <jepler> not great for positioning!
[20:57:26] -!- FinboySlick has quit [Quit: Leaving.]
[20:58:00] -!- syyl_ws has quit [Quit: Verlassend]
[20:58:05] <Tom_itx> i've always wanted to try to interface my fowlers but never have
[20:58:17] -!- Deejay has quit [Quit: bye]
[20:58:22] <Tom_itx> quite frankly, i don't wanna screw em up
[20:58:55] <PCW> one problem on some is that the battery+ is connected to the metal parts
[20:59:18] <Tom_itx> yeah i think mine may be
[20:59:40] <jepler> that will make for a surprise one day
[20:59:51] <PCW> so if you want to use the serial interface you need to expect that
[21:01:57] -!- anarchos2 has quit [Read error: Connection reset by peer]
[21:01:57] -!- anarchos has quit [Read error: Connection reset by peer]
[21:02:26] <kwallace> Here is the board:
http://www.wallacecompany.com/tmp/IMG_8388-1a.jpg
[21:03:36] <kwallace> The test pads at the top may be for serial, maybe. I'll have to check with an o'scope.
[21:07:43] -!- theorbtwo has quit [Read error: Connection reset by peer]
[21:08:49] <kwallace> http://www.ebay.com/itm/181490009318
[21:09:28] -!- ve7it has quit [Ping timeout: 250 seconds]
[21:12:52] -!- JT-Shop has quit [Ping timeout: 240 seconds]
[21:13:00] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[21:13:22] <kwallace> Unfortunately, they were shipped with all the calipers in one bunch without any padding between them, so the displays got damaged more.
[21:13:22] -!- jthornton has quit [Ping timeout: 240 seconds]
[21:14:39] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[21:16:35] -!- mhaberler has quit [Quit: mhaberler]
[21:16:44] <kwallace> I did get three fairly good ones out of the bunch. I have some nice dial calipers I normally use but they are all in inch and I am using metric more these days.
[21:18:34] -!- sudobangbang has quit [Ping timeout: 264 seconds]
[21:21:29] tjb11 is now known as tjb1
[21:22:00] -!- FreezingCold has quit [Ping timeout: 246 seconds]
[21:22:04] -!- JT-Shop [JT-Shop!~john@162.72.174.234] has joined #linuxcnc-devel
[21:22:04] -!- jthornton [jthornton!~john@162.72.174.234] has joined #linuxcnc-devel
[21:23:31] -!- balestrino has quit [Ping timeout: 255 seconds]
[21:24:47] <cradek> kwallace: I have a dial caliper with inch and mm needles that I like a lot
[21:25:18] <cradek> you can measure a thing and tell right away whether it's probably an inch or mm part, because you see both numbers
[21:25:22] -!- mozmck has quit [Quit: Leaving.]
[21:26:06] -!- Tom_itx has quit [Ping timeout: 255 seconds]
[21:26:25] <cradek> like this:
http://ecx.images-amazon.com/images/I/51vF%2BYxO9kL.jpg
[21:26:35] -!- mozmck [mozmck!~moses@67.210.159.245] has joined #linuxcnc-devel
[21:26:59] -!- zlog has quit [Ping timeout: 272 seconds]
[21:27:46] <kwallace1> I got these calipers "by mistake". They will probably take up too much of my time.
[21:28:12] <jepler> 9 s32 RW 6461142 hm2_7i43spi.0.read.tmax
[21:28:12] <jepler> 9 s32 RW 4762570 hm2_7i43spi.0.write.tmax
[21:28:30] <jepler> that's not good :-/
[21:29:12] <jepler> even pet_watchdog's tmax is up to .5ms after ~18 hours testing
[21:29:29] -!- zlog [zlog!~zlog@ip68-102-196-57.ks.ok.cox.net] has joined #linuxcnc-devel
[21:29:33] <jepler> but that's juts about the preempt-rt kernel, not really the driver's fault
[21:30:42] -!- JT-Shop has quit [Ping timeout: 250 seconds]
[21:30:42] -!- jthornton has quit [Ping timeout: 250 seconds]
[21:33:36] <PCW> well maybe the SPI drivers fault
[21:34:34] <jepler> point taken
[21:35:46] <PCW> (if the latency test is not that bad)
[21:36:19] <jepler> the mounting holes actually measured 3.35mm, I guess that's a clearance hole for an M3 screw.
[21:36:51] <jepler> I haven't let the latency test run for even 10% as long as I let hm2_spi; that's a good point.
[21:37:05] <jepler> it'll tell me if it's SPI or "just anything"
[21:37:39] <jepler> I notice in the kernel SPI driver source, it does things like turn a clock on or off in the CPU
[21:37:48] <jepler> god knows what it actually takes to do that
[21:38:00] <PCW> Yuck
[21:38:15] <jepler> I think it's a clock for an internal bus to the spi unit
[21:38:34] <jepler> but maybe it's the SPI clock itself
[21:39:05] <jepler> great if you want to add seconds and seconds to battery life .. a bad idea if you want lowest latency
[21:39:34] <PCW> yeah
[21:39:59] -!- arvidkahl has quit [Client Quit]
[21:40:28] <PCW> well now to see if I can patch the resolver code so it runs in Spartan6 with twice the clock rate
[21:40:30] <PCW> I only vaguely remember how it works
[21:44:35] <jepler> it's sensitive to its clock, then?
[21:45:41] <PCW> well the wavegen, dacrate, spiclock rates etc are all proportional to ClockLow
[21:46:45] <jepler> another monstrosity in d8?
[21:46:47] <PCW> SSLBP read the Clocklow value from a register and calculates all its baudrate,timersettings etc but the resolver code is cruder
[21:47:11] <PCW> no its B32
[21:47:46] <PCW> 32 bit with DSP MAC
[21:48:15] <jepler> I suppose all those fpgas have got DSPs to spare
[21:48:23] <PCW> Yes
[21:49:00] <PCW> B32 is just a wider D8 really
[21:49:15] <jepler> still 16-bit instructions?
[21:49:24] <PCW> 24 bit
[21:49:33] <jepler> wider constants mostly
[21:49:34] <jepler> ?
[21:50:18] <jepler> (the design of ptasm is to store instrucions as integers, so it's just a matter of your rules whether they all happen to fit in 8, 16, or whatever number of bits)
[21:50:26] <jepler> (so that shouldn't pose a particular problem)
[21:50:47] <PCW> Yes basically
[21:51:27] <PCW> the Ethernet stuff uses a 16 bit processor with 24 bit instructions
[21:51:56] <PCW> all very similar
[21:52:29] <PCW> the resolver stuff uses no macros at all
[21:52:31] <PCW> (since I wrote it)
[21:53:12] <PCW> not even to cover up a glaring assembler limitation
[21:53:18] -!- jthornton [jthornton!~john@162.72.174.234] has joined #linuxcnc-devel
[21:53:18] -!- JT-Shop [JT-Shop!~john@162.72.174.234] has joined #linuxcnc-devel
[21:53:33] -!- anarchos has quit [Ping timeout: 240 seconds]
[21:53:52] <jepler> I wonder why the one case they designed for the odroid allows absolutely no access to the I/O headers
[21:54:08] <jepler> grumble
[21:54:19] <PCW> (notice the funny jmpz somewhere/2 insts)
[21:54:45] <jepler> eew
[21:54:57] <PCW> cuz you'd be crazy to connect to that 1.8V stuff
[21:56:28] <jepler> well there's that
[21:56:50] <jepler> hey wait, did you just call me crazy?
[21:57:56] <jepler> I feel like I learned a lot, if only in a trite "now I know that I don't know much" sort of way :-P
[21:59:21] <PCW> how much I/O stuff is available on the Odroid?
[21:59:50] <PCW> maybe just not targeted to DIY types
[21:59:53] <jepler> PCW: not much. 3 GPIOs, 2 serial ports, and SPI.
[22:00:12] <jepler> oh the 3 GPIOs can be used as I2C too
[22:00:24] <PCW> is there decent documentation of the SPI hardware?
[22:00:33] <jepler> they have a daughterboard that has SPI EEPROM, an I2C port expander, and an AVR on the serial
[22:01:19] <jepler> (the port expander and avr are all running at more typical voltage, dunno whethre 3.3v or 5v)
[22:01:32] <jepler> PCW: I found a register-level document about it, but it's pretty opaque. and of course there's the kernel source itself.
[22:01:55] <CaptHindsight> the SPI connector wasn't even on the earlier rev board
[22:01:59] <PCW> not sure what a SPI EEPROM gets you if you already have a file system
[22:02:29] <jepler> PCW: it's an inexpensive device that lets you show that the SPI works?
[22:03:04] <PCW> thats true enough even our 16 Mbit chips are about $0.60 now
[22:03:15] <jepler> a 2mbit serial flash is just a waste of board space when you tend to have an 8GB+ main storage
[22:03:57] <jepler> hm, seb wanted one of these boards, but I think we established his u3 was the earlier revision without the spi header :(
[22:04:04] -!- brianmorel99 [brianmorel99!~brianmore@h75-100-180-199.mgtnmi.dsl.dynamic.tds.net] has joined #linuxcnc-devel
[22:04:09] <PCW> oops
[22:04:20] <jepler> won't do him much good
[22:05:49] <PCW> what kind of numbers do you get with the latency test?
[22:06:32] <jepler> let me get this thing put back together and start one
[22:07:04] <jepler> here's when I was optimistic, but note it's only a 5-minute run:
http://media.unpythonic.net/emergent-files/01407410572/latency-odroid.png
[22:09:37] <PCW> that does look promising
[22:13:54] <jepler> well I'll let this go overnight
[22:14:03] <jepler> with spi, it was enough to just wait and the bad latencies would show up
[22:15:02] <jepler> from the point of view of trying to drive the SPI from userspace the clock activation/deactivation thing is a concern again
[22:15:26] <jepler> I think devices may share the clock, so the whole kernel would have to agree when the clock has to be running and when it may be stopped
[22:16:25] <PCW> is this all power related?
[22:16:42] <jepler> let me go look at the code and refresh my memory
[22:17:47] -!- Lathe_newbie has quit [Ping timeout: 245 seconds]
[22:17:49] -!- brianmorel99 [brianmorel99!~brianmore@h75-100-180-199.mgtnmi.dsl.dynamic.tds.net] has parted #linuxcnc-devel
[22:18:14] -!- patrickarlt has quit [Remote host closed the connection]
[22:22:55] <jepler> it looks like the clock's status only changes when changing the transfer details (rate or width), or in response to PM events
[22:23:37] <jepler> CONFIG_PM=y
[22:23:44] <jepler> hm CONFIG_PM is on in my kernel though
[22:25:47] <jepler> yup it will runtime-suspend the spi
[22:25:49] <seb_kuzminsky> jepler: my current u3 is dedicated to the buildbot
[22:26:02] <seb_kuzminsky> i'd buy another for driving my little 3d printer with your board
[22:26:19] <jepler> supposedly I can touch files in /sys to disable that
[22:27:09] <jepler> seb_kuzminsky: aha. well, I dunno if that's a good idea yet or not
[22:27:16] <jepler> how well do you require that it work?
[22:27:29] <seb_kuzminsky> yeah i'll hold off until you show me the awesome
[22:28:53] <jepler> they'll probably stop manufacturing the u3 by then :-/
[22:29:50] <seb_kuzminsky> i won't lose any sleep over that possibility
[22:30:07] <CaptHindsight> anyone have an imx6 board with a PCIe slot?
[22:31:22] -!- patrickarlt has quit [Ping timeout: 240 seconds]
[22:33:51] <jepler> wow if you really want your latency graph to look good, uncheck ylogscale
[22:35:50] <CaptHindsight> PCW: do you see any issues getting a
http://www.imx6rex.com/ with a PCIe-mini to PCIe adapter to the 6i25 to work?
[22:37:19] aude_ is now known as aude
[22:37:25] <PCW> probably not (Ive run PCIE over a short bit of cat5)
[22:38:14] <CaptHindsight> anything x86 specific in the drivers?
[22:39:14] <PCW> Not sure, I kind of doubt it though
[22:41:04] -!- kfoltman has quit [Quit: Ex-Chat]
[22:41:33] <PCW> ok resolver code patched, but will it blend?
[22:49:37] <jepler> this connection is getting extremely moody
[22:50:08] <jepler> I hope I haven't actually damaged the contacts in the u3's female header by having the connected pins waggling back and forth
[22:50:21] <jepler> last night it worked mostly, now it doesn't work unless I press down firmly all the time
[22:51:11] -!- ve7it has quit [Remote host closed the connection]
[22:52:44] <CaptHindsight> jepler: longer pins will probably fix it, durability on headers is <100 cycles insertion removal until the contacts start losing their spring
[22:53:25] <jepler> I guess I should order some spare headers and be prepared to desolder these ones
[22:54:02] <PCW> 2mm female headers are pretty fragile
[22:54:40] * jepler thinks back to the "# insertions vs pins remaining" graph in the famous write-only-memory datasheet
[22:55:33] <jepler> anyway, after minutes and minutes of good latency-histogram output I switched to testing the spi driver again
[22:55:41] -!- tinkerer [tinkerer!~tinkerer@mail.play-pla.net] has joined #linuxcnc-devel
[22:55:49] <jepler> and it immediately got a watchdog error followed by realtime error
[22:56:28] <jepler> so it's possible that the dodgy connection causes watchdog error causes relatime error
[22:56:39] <jepler> or that the kernel spi driver is not realtime
[22:56:57] <jepler> until I have a reliable physical connection I don't think I'll be making a determination about any of that
[22:57:15] <jepler> so this is on hold again at least until I get a new board and maybe replace the u3-side connectors
[22:57:32] <jepler> back to running latency-histogram
[22:57:36] <jepler> afk
[23:09:01] <seb_kuzminsky> still awesome progress jepler, it's been fun to read along with
[23:10:26] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master bc3ea43 06linuxcnc 10debian/configure 10debian/control.in deb: stop referring to the old "emc2" packages * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bc3ea43
[23:11:55] -!- tinkerer has quit [Quit: Leaving.]
[23:14:53] -!- GJdan has quit [Remote host closed the connection]
[23:16:46] -!- anarchos has quit [Ping timeout: 250 seconds]
[23:17:11] -!- Lathe_newbie has quit [Ping timeout: 272 seconds]
[23:22:22] -!- Tom_itx [Tom_itx!~Tl@unaffiliated/toml/x-013812] has joined #linuxcnc-devel
[23:25:52] -!- patrickarlt has quit [Remote host closed the connection]
[23:26:26] <memleak> jepler, your math redistributable commit has undefined references in RTAI
[23:27:04] <memleak> if you want when i get back i can look more into it and remove the references to the symbols entirely
[23:28:30] <memleak> fpmacros.c and rndint are a pain anyway to work with so i think its best to remove those
[23:41:15] -!- patrickarlt has quit [Remote host closed the connection]
[23:44:33] <PCW> resolvers now work with Ethernet cards and 7I90, that were ugly
[23:49:43] -!- PetefromTn_ has quit [Quit: I'm Outta here!!]
[23:56:52] <kwallace> BTW the top test pads on my caliper board have data on them.
http://www.wallacecompany.com/tmp/IMG_8388-1a.jpg
[23:58:49] <PCW> all the Chinese one may all use the same chip
[23:58:58] <PCW> ones
