Back
[01:01:20] <linuxcnc-build_> build #403 of 1902.clang-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1902.clang-wheezy-rtai-i386/builds/403 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[01:40:01] <linuxcnc-build_> build #2453 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/2453 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[01:47:46] <linuxcnc-build_> build #3253 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/3253 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[01:58:32] <linuxcnc-build_> build #1072 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/1072 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[02:09:57] <linuxcnc-build_> build #3260 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3260 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[07:06:54] <jepler> hm, no, rtapi_delay isn't available in ULAPI..
[07:10:15] <KGB-linuxcnc> 03Jeff Epler 05jepler/hal-streams 7ca658a 06linuxcnc 10(10 files in 3 dirs) hal: factor out streamer/sampler * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7ca658a
[07:10:15] <KGB-linuxcnc> 03Jeff Epler 05jepler/hal-streams 97ef8ef 06linuxcnc 03docs/man/man3/rtapi_stream.3rtapi hal: document the new C API * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=97ef8ef
[07:14:29] <KGB-linuxcnc> 03Jeff Epler 05jepler/aarch64 aa18ad4 06linuxcnc 10src/configure.in 10src/rtapi/rtapi_io.h 10src/rtapi/rtapi_pci.cc 10src/rtapi/uspace_rtapi_app.cc rtapi: accommodate systems without sys/io.h * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=aa18ad4
[07:14:29] <KGB-linuxcnc> 03Jeff Epler 05jepler/aarch64 f1c84aa 06linuxcnc 10src/Makefile 10src/Makefile.modinc.in build: remove unused IS_POWERPC * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f1c84aa
[07:17:55] <linuxcnc-build_> build #3254 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/3254 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[07:21:25] <linuxcnc-build_> build #1073 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/1073 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[07:22:13] <KGB-linuxcnc> 03Jeff Epler 05jepler/hal-streams d116f3c 06linuxcnc 10(10 files in 3 dirs) hal: factor out streamer/sampler * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d116f3c
[07:22:14] <KGB-linuxcnc> 03Jeff Epler 05jepler/hal-streams d6a73ca 06linuxcnc 03docs/man/man3/rtapi_stream.3rtapi hal: document the new C API * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d6a73ca
[07:22:38] <linuxcnc-build_> build #2454 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/2454 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[07:30:24] <linuxcnc-build_> build #404 of 1902.clang-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1902.clang-wheezy-rtai-i386/builds/404 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[07:35:57] <jepler> huh, apparently clang rtai builds usually have piles of messages that say "error", but they are not actually fatal errors e.g.,
[07:36:00] <jepler> /usr/src/linux-headers-3.4-9-common-rtai/arch/x86/include/asm/thread_info.h:190:24: error: global register variables are not supported
[07:36:03] <jepler> register unsigned long current_stack_pointer asm("esp") __used;
[07:36:05] <jepler> ^/usr/src/linux-headers-3.4-9-common-rtai/arch/x86/include/asm/thread_info.h:190:24: error: global register variables are not supported
[07:36:08] <jepler> register unsigned long current_stack_pointer asm("esp") __used;
[07:38:37] <linuxcnc-build_> build #3261 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3261 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[08:52:07] <linuxcnc-build_> build #406 of 1902.clang-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1902.clang-wheezy-rtai-i386/builds/406 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[09:13:04] <jepler> this time I can't spot the real error
[09:13:52] <linuxcnc-build_> build #2456 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/2456 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[09:15:15] <linuxcnc-build_> build #3252 of 1300.rip-precise-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/3252 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[09:15:40] <linuxcnc-build_> build #3254 of 1306.rip-precise-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/3254 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[09:31:01] <linuxcnc-build_> build #3256 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/3256 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[09:39:50] <linuxcnc-build_> build #1075 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/1075 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[09:51:44] <linuxcnc-build_> build #3263 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3263 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[11:18:38] <KGB-linuxcnc> 03Jeff Epler 05jepler/hal-streams b3afc5e 06linuxcnc 10(10 files in 3 dirs) hal: factor out streamer/sampler * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b3afc5e
[11:18:38] <KGB-linuxcnc> 03Jeff Epler 05jepler/hal-streams 9b87adf 06linuxcnc 03docs/man/man3/rtapi_stream.3rtapi hal: document the new C API * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9b87adf
[12:07:08] <jepler> pcw_home: I have a 7i92 from a pile of boards you sent to cradek. as far as I can see, there are no jumpers W5/W6 for controlling IP address selection. They're not by the power input block as shown in the pdf. did I get an early revision that omitted them?
[12:09:17] <pcw_home> Yes, senior moment during schematic capture...
[12:09:44] <jepler> OK, I'll stop looking
[12:09:45] <pcw_home> it works, you just can't set the IP address mode
[12:11:06] <pcw_home> (well you can by changing bitfile to have pullups or pulldowns on the pins that were supposed to read the jumpers)
[12:16:18] <Tom_itx> pcw_home, incidentally i was trying to find those ISL32274 online and none of the vendors stock them. Would it be possible to get those and that other act04 from you some time so i can repair this 7i47s as a backup?
[12:16:51] <Tom_itx> i'd be more than happy to pay for em
[12:22:57] <jepler> pcw_home: in 7i92man page 25 and 7i80dbman page 27, the command to change the eeprom ip address is given as 82C9200072000A8C0. On a later page, a different command is given: 82C920000100a8C0
[12:23:06] <jepler> the IP addresses are different, but i think the first one has had a spurious "7" inserted
[12:33:32] <pcw_home> yeah wrong length
[12:38:08] <jepler> http://paste.ubuntu.com/11873365/
[12:39:39] <jepler> ^^ two hm2_eth cards on one hardware interface
[12:45:27] <jepler> I don't immediately see a way to send both read requests and then wait for both of them, which is a pity.
[12:45:50] <jepler> surprising to me is that the variability of the second read function is higher
http://emergent.unpythonic.net/files/sandbox/hm2-eth-multiple.png
[13:02:07] <skunkworks> is that through a switch?
[13:07:12] <jepler> skunkworks: yes, PC to gigabit switch to 2x7i90s
[13:21:14] <skunkworks> cool
[13:29:56] <PCW> That's neat (though to gain the most advantage from the switch as a concentrator you need to send the N read requests and then wait for the N responses)
[13:31:32] <PCW> well sending all the requests and then waiting on them in sequence is probably good enough
[13:32:12] <PCW> allowing most of the response/wire times to overlap
[13:32:26] <PCW> (100BT wire times that is)
[13:35:05] <PCW> My test setup has been up about 3 weeks now at 3 KHz though the switch (my $20 switch was TPLink not DLink, basically bottom of the barrel)
[13:36:19] <jepler> yeah I'm working on that but something's wonky
[13:40:56] <PCW> Not surprising, its not simple...
[13:42:49] <PCW> if the scatter/gather can be made to work, it may actually be a case where receive interrupt coalescing helps performance
[13:44:30] <PCW> (since the response packets will come very close together on the 1G link)
[13:45:18] <jepler> pcw_home: should hostmot2 stepgen position feedback be 0 at powerup?
[13:45:40] <jepler> or is the position undefined?
[13:46:06] <PCW> I think it would default to that
[13:48:00] <PCW> you can write it with any value
[13:51:56] <PCW> Its not specifically initialized in the VHDL but the default for uninitialized registers is 0
[13:53:00] <jepler> in that first halcmd show I pastebinned, the stepgen position-fbs were all 0 as expected
[13:54:22] <jepler> in my working version where I am overlapping the reads it looks like the "power-on" value is different and nonzero on each run, though commanding a position seems to work
[13:55:34] <PCW> hmm, an errant write to the rate registers might cause that
[13:56:18] <PCW> (they also default to 0 but are not readable)
[13:59:03] <PCW> I dont know if the driver clears the position register at linuxcnc startup (so a full power cycle would be needed for the actual position registers to be cleared)
[13:59:24] <PCW> (7I80 power cycle)
[14:02:29] <jepler> a little more testing and it is clear that it's something to do with my overlapped read code
[14:02:44] <jepler> reverting just that part makes the stepgens be at 0 at linuxcnc startup
[14:03:54] <PCW> random numbers?
[14:07:00] <PCW> maybe read the cookie at the end of the read request as an alignment sanity check
[14:08:01] <jepler> some of the .position-fb vary widely from run to run, others are rather stable
[14:08:13] <jepler> http://paste.debian.net/282003/
[14:08:19] <PCW> weird...
[14:09:05] <jepler> I am assuming I am either managing to read uninitialized memory, or read from the other packet. I'll figure it out after lunch.
[14:09:23] <PCW> Yeah
[14:10:39] <PCW> adding alignment and sequence checks might not be a bad idea to help debug these types of issues
[14:15:48] <jepler> hm2_eth: enqueue_read ERROR: reading packet: recv() -> -1 Resource temporarily unavailable (expected to read 116 bytes)
[14:16:00] <jepler> ah well this would explain why the numbers are nonsense
[14:16:05] <jepler> .. it happens just once at startup
[14:16:46] <PCW> ahh first transfer is bolluxed-up
[14:18:11] <mozmck> Is there a way to show the state of a pin using gladevcp whether it is tied to a signal or not?
[14:18:22] <mozmck> The way halshow does it...
[14:19:57] <PCW> lot of gnarly things happen at startup (why it would be nice to skip-cycle the first 100 or so transfers and defer initiliazing the tmaxes or checking overruns until things are running smoothly)
[14:21:37] <jepler> Period FP Name ( Time, Max-Time )
[14:21:38] <jepler> original: 1000000 YES thread1 ( 791768, 951596 )
[14:21:38] <jepler> overlapped: 1000000 YES thread1 ( 407579, 479038 )
[14:21:38] <jepler> whee
[14:25:30] <PCW> Nice
[14:26:50] <jepler> one board: 1000000 YES thread1 ( 411977, 442396 )
[14:27:15] <PCW> overlap is a good thing
[14:27:20] <jepler> it sure is
[14:29:34] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-multiple 8188768 06linuxcnc 10docs/man/man9/hm2_eth.9 10src/hal/drivers/mesa-hostmot2/hm2_eth.c 10src/hal/drivers/mesa-hostmot2/hm2_eth.h hm2_eth: allow multiple instances (up to 4) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8188768
[14:29:34] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-multiple 67393ca 06linuxcnc 10(6 files in 2 dirs) hostmot2: support split reads * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=67393ca
[14:29:34] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-multiple 500e905 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: in case of failed recv(), show an error * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=500e905
[14:29:48] <jepler> seb_kuzminsky: this is another one I'd like your review on, since it adds some stuff to hostmot2 (the new "read-request" hal function, mostly)
[14:29:52] <PCW> I never thought to mess with switches because I mistakenly believed that the smallest 1G packet size was 522 bytes
[14:29:54] <PCW> Turns out thats only for half duplex links
[14:30:21] <jepler> now really off to lunch this time
[14:30:33] <PCW> ( full duplex 1G is 64 byte minimum like 100 BT )
[14:52:45] <linuxcnc-build_> build #925 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/925 blamelist: Jeff Epler <jepler@unpythonic.net>
[15:09:34] <linuxcnc-build_> build #3265 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3265 blamelist: Jeff Epler <jepler@unpythonic.net>
[15:45:21] <jepler> I verified my device is full duplex to the switch
[15:45:35] <jepler> the pc that is
[15:48:55] <jepler> wow, wikipedia days optical versions of gigabit are good for terms of km
[15:49:01] <jepler> says
[15:50:55] <jepler> hm and that auto mdi-x is optional
[15:58:51] <PCW> Half duplex is rare/old AFAICT
[16:03:21] <cradek> Do NOT include the apostrophe for contractions. For example, search for the word DON'T by searching DON T.
[16:03:38] <cradek> someone is new at database
[16:04:30] <jepler> pcw_home: if you get a chance to test it, let me know any trouble you run into
[16:08:32] <PCW> I will test later this week
[16:11:56] <jepler> PCW: ok
[16:12:04] <PCW> Great to know that you can overlap a lot of the 100BT wiretime/slave response overhead with multiple channels (I thought its was possible but didn't know for sure)
[16:25:49] <PCW> multiple channels with little overhead is also great for distributed I/O (but I need to see what happens to jitter with some long term banging on it)
[16:43:59] <jepler> 3 boards:
[16:44:00] <jepler> Period FP Name ( Time, Max-Time )
[16:44:00] <jepler> 1000000 YES thread1 ( 453198, 588867 )
[16:45:01] <jepler> trying to power 3 of them from one VUSB: not the best idea.
[16:57:36] <PCW> We had a (non linuxcnc) customer with a problem claiming 7I80HD was losing register settings
[16:57:37] <PCW> (turn on all outputs --> add ~100 mAa more drain from pullups, Pull USB power out or reg --> reset 7I80HD)
[16:58:11] <jepler> I removed the rtapi_delay from the receive loop, and it makes for a very distinctive signature in the thread1 (servo thread) time:
http://emergent.unpythonic.net/files/sandbox/thread-time-stairstep.png
[16:58:55] <PCW> what CPU?
[16:59:15] <jepler> core2duo
[16:59:31] <jepler> hmm possibly with CPU frequency scaling turned on (!)
[16:59:34] <jepler> no isolcpus
[16:59:41] <jepler> wheezy, kernel 3.14-rt
[17:00:06] <PCW> isolcpus seems to hurt latency on Preemt-RT in my limited testing
[17:00:32] <PCW> what MAC?
[17:00:44] <micges> PCW: what application did this non linuxcnc user use to access 7i80?
[17:01:23] <jepler> PCW: 04:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
[17:01:28] <PCW> Their own code (ground test equipment AFAICT)
[17:02:07] <PCW> do you IRQ coalescing turned off?
[17:02:16] <PCW> do you have
[17:05:40] <jepler> I don't think I have changed any irq stuff from defaults
[17:07:08] <jepler> default seems to be rx-usecs 3
[17:07:54] <jepler> changing it to 0 files off the peaks a bit
[17:09:02] <PCW> probably about 3 usec :-)
[17:12:07] <PCW> would like to know why the sawtooth is there (~30 usec on a 3 GHz machine)
[17:12:26] <jepler> yeah that is what I found interesting
[17:13:39] <PCW> it should show up in the DPLL error if its in the request packet
[17:16:33] <kwallace_shiz> This is suppose to be round and _not_ look like a gear:
http://wallacecompany.com/machine_shop/fanuc_mpg/IMG_1539-1a.JPG
[17:18:32] <jepler> looking at individual function .times, 0.read.time has a nice sawtooth and 1.read.time has a peak everyhwere 0.read.time is its lowest, otherwise it's negligible everywhere else
[17:19:33] <jepler> .. with the delays removed, it's also rather crashy, particularly while running halscope. at least, I hope it's removing the delays (not pushed anywhere) that has made it unreliable, not just the multiple interfaces stuff
[17:20:14] <jepler> whatever is happening, I can see from the fpga boards that packets are being sent rather slowly, probably hitting that hard-coded maximum timeout
[17:20:17] <PCW> I think its known to be crashy without the delays
[17:20:31] <jepler> but surprisingly the whole system becomes unresponsive even though the other CPU shuold be free of RT tasks
[17:21:53] <PCW> removing the dalys has been tried a couple times without success :-(
[17:22:38] <PCW> delays
[17:22:48] <jepler> groan
[17:24:06] <jepler> We set up rtapi_app to be at a higher RT priority than the IRQ. Is it priority inversion?
[17:27:20] <PCW> possibly... the Ethernet interrupt must interrupt the running thread of course
[17:29:25] <PCW> you could poke around with chrt (I have not noticed any remarkable improvements with uneducated priority futzing)
[17:31:53] <jepler> http://emergent.unpythonic.net/files/sandbox/sawtooth2.png
[17:32:17] <jepler> this is what I was trying to describe in prose a minute ago
[17:32:23] <jepler> not correlated with phase-error much
[17:36:43] <jepler> at 1kHz (vs 667Hz) servo thread, it's still typically 4 thread-executions per sawtooth
[17:37:39] <jepler> and same at 1.05kHz, 4 thread-executions per sawtooth
[17:50:13] <PCW> that is really strange, wonder if its some characteristic of the switch
[17:53:27] <PCW> you do have all rx packets coming back at roughly the same time so the order is not known
[17:54:35] <PCW> (determined by the request order but also the request and reply sizes)
[17:59:53] <PCW> does the code that waits for the replies do first come/first serve?
[18:01:01] <jepler> no, it processes them in the same order as they were sent
[18:01:46] <jepler> well, more accurately, the processing is in hal's thread order and "same order as sent" seems most sensible
[18:03:50] <jepler> hm, running with 2 boards enabled instead of 3, it's just a square-ish wave instead of a sawtooth
[18:16:00] <seb_kuzminsky> argh, it's that halui/mdi test bug again
[18:16:40] <seb_kuzminsky> i was debugging that, where did i put my branch...
[18:58:15] <PCW> wonder if its missing cycles somehow (a scope on TP1 or TP2 might help)
[19:08:02] <PCW> sorry TP0 and TP1. TP0 is high for PktRX time TP1 is high for PktTX time
[19:31:55] <jepler> https://github.com/polysome/aggregate-1 "An open source Xilinx Spartan 6 miniPCIe development board. "
[19:32:58] <jepler> not a lot more information available, boo
[19:34:25] <PCW> cute but no I/O?
[19:35:15] <PCW> Oh theres's some flat cable I/O on the bottom
[19:43:39] <PCW> Cryptography coprocessor?
[19:44:13] <PCW> (thats a $100+ FPGA)
[19:45:48] <jepler> yeah I can't quite figure out what they're into
[19:46:03] <jepler> "Free, open and verifiable security architecture." -- polysome.io
[19:49:26] <jepler> but I think I could watch the pick & place video on their front page just about all day
[20:07:41] <cradek> kwallace_shiz: so you got a bunch that are fine, and this one that had an incorrectly hardened part?
[20:21:43] <KGB-linuxcnc> 03Robert W. Ellenberg 05feature/tangent-improvement-2.7 0e6f404 06linuxcnc 10src/emc/tp/tp.c tp: internally limit kink ratio to the range [0.001,0.7071] * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0e6f404
[20:41:49] <PCW> Ive seen some the use a very small ball bearing for the detent
[20:43:05] <cradek> as often as you spin those things it's no surprise they get some wear.
[20:44:38] <linuxcnc-build_> build #1607 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/1607 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[20:58:30] <skunkworks> I don't get any failures
[21:00:01] <linuxcnc-build_> build #3266 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3266 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[21:00:37] <skunkworks> Runtest: 158 tests run, 158 successful, 0 failed + 0 expected
[21:31:49] <kwallace_shiz> cradek, "so you got a bunch that are fine ^^^" I got three MPGs. One has a nice detent feel, the second has a nice feel but is a tad light, the third had a light double detent which turned out to have a completely worn roller. There is too much grease in the second to see any wear and it works so I may just leave it for now. I'll probably make a few rollers and tape one inside each MPG.
[21:33:51] <kwallace_shiz> I have some drill rod on the material rack which I plan on using, but I'll leave the rollers unhardened to protect the rotor teeth.
[21:53:32] <jepler> hm. bug or feature? hm2_eth counts cards from 0, so if you configure 3 cards you can get e.g., hm2_7i80.0 hm2_7i80.1, hm2_7i92.2 instead of hm2_7i92.0.
[21:56:13] <mozmck> can the numbering change based on the switch port it's on?
[21:57:17] <jepler> no, it's based on loadrt board_ip= ordering
[21:57:38] <mozmck> ok
[21:57:55] <jepler> loadrt hm2_eth config="num_encoders=1 num_pwmgens=1 num_stepgens=1 enable_raw=1,enable_raw=1" board_ip=192.168.1.123,192.168.1.122,192.168.1.121
[21:58:26] <jepler> in my case, .123 is a 7i80hd, .122 is a 7i90db (or maybe vice versa) and .121 is a 7i92
[21:58:39] <mozmck> So does the config string apply to all boards?
[21:59:00] <jepler> no
[21:59:07] <jepler> the first board gets num_encoders=1 num_pwmgens=1 num_stepgens=1 enable_raw=1
[21:59:12] <jepler> the second one gets just enable_raw=1
[21:59:15] <jepler> and the third board gets nothing
[21:59:30] <mozmck> ah, I missed the comma.
[22:56:31] <pcw_home> I think PCI cards are like 5i20.0, 5i23.0, 5i23.1
[22:56:33] <pcw_home> though the numbers are a nice independent enumeration
[23:22:21] <skunksleep> https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/148237
[23:22:28] <skunksleep> Yikes
[23:23:15] <pcw_home> 7i73 is in the mail...
[23:25:36] <skunksleep> Yay. Wait. What do you mean?
[23:30:47] <skunksleep> Wow 30 in stock :)
