Back
[07:34:09] <jepler> hmmm
[07:34:10] <jepler> On branch 2.7
[07:34:10] <jepler> Your branch is up-to-date with 'origin/2.7'.
[07:34:23] <jepler> but my axis identifies as 2.8.0~pre1
[07:36:35] <jepler> this stale information was stored in autom4te.cache
[07:37:11] <jepler> aha
[07:43:30] <KGB-linuxcnc> 03Jeff Epler 052.6 d7ed33c 06linuxcnc 10src/autogen.sh configure: clean up cache files * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d7ed33c
[07:43:30] <KGB-linuxcnc> 03Jeff Epler 052.7 ecc16a3 06linuxcnc Merge branch '2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ecc16a3
[07:43:30] <KGB-linuxcnc> 03Jeff Epler 05master fa8867a 06linuxcnc Merge branch '2.6' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fa8867a
[10:41:47] <jepler> pcw_home: what's the trick to user-controlled LEDs on the 7i80-hd?
[10:42:09] <jepler> pcw_home: also I notice the hal pins may not match the silkscreen
[10:43:54] <pcw_home> umm... let me see...
[10:44:53] <jepler> I know it has something to do with how 3 of the LEDs count up as packets are transmitted or something
[10:45:36] <jepler> er I guess they all do
[10:46:08] <jepler> one was just unchanging to the eye because I was always transmitting 2 packets per thread invocation
[10:46:40] <pcw_home> look at memory space 6 location 14
[10:46:57] <pcw_home> if thats set to 0 you get hostmot2 leds
[10:47:08] <jepler> that's not something I can write with the hm2 raw interface is it
[10:47:15] <jepler> I have that script somewhere though
[10:48:31] <jepler> pcw_home: anyway, I've made some good progress. encoder and raw were relatively easy to fix. however, resolver, sserial and uart look like they will be substantially more difficult.
[10:48:40] <pcw_home> no, you need to access space 6
[10:48:41] <pcw_home> 01D914000000 shoud do
[10:49:05] <jepler> thanks, saves me figuring that out
[10:49:07] <pcw_home> sserial seems OK
[10:49:34] <jepler> oh really? I didn't test it, it was just based on reading the code
[10:50:04] <jepler> and resolver *may* only be generating extra packets at startup
[10:50:09] <pcw_home> (note thats only temporary, you would need to write the EEPROM to make the LED change presistent)
[10:50:25] <pcw_home> persistent
[10:51:29] <jepler> pcw_home: so my silkscreen has year 2002 and I don't see a revision code
[10:51:50] <pcw_home> I keep meaning to write a Cyclon LED thing so when the packet rate is high you get cyclon eyes instead of a count
[10:51:50] <jepler> pcw_home: and the LEDs that are controlled are silkscreened CR3..6
[10:52:02] <jepler> but hal shows them as CR01..CR04
[10:52:35] <jepler> so (A) is my silkscreen 'current' and (B) is it worth breaking configs that use the LEDs to make hal match the silkscreen?
[10:53:09] <jepler> err year 2012 of course
[10:53:33] <pcw_home> leds are the same on all revs (CR1..4) is probablycopy/pasted from some other board
[10:54:23] <jepler> it looks like it's hardcoded in the hal driver that the first LED is CR(0)0
[10:54:27] <pcw_home> not sure about 7I92, it may have different LED names
[10:54:29] <jepler> err CR(0)1
[10:55:02] <pcw_home> maybe it just means the LED LSB
[10:55:05] <jepler> I won't touch it. I don't know if people are using the LEDs but I wouldn't want to break their configs
[10:56:26] <pcw_home> I dont think many people use the LEDsm but you can see i used them fro debugging (the LED debug pointer stuff)
[10:57:05] <jepler> yeah
[10:57:37] <pcw_home> i also have conditional code to use the I/O for debugging
[11:02:18] <jepler> hm2_resolver_write will generate extra packets when the excitation_khz parameter is changed, but won't in normal operation
[11:03:56] <jepler> and hm2_uart_read calls llio->read in a loop, so it'll be really bad
[11:04:14] <pcw_home> I'm pretty sure lots of setup code uses quite a few unqueued accesses
[11:04:16] <pcw_home> (the read tmax for example is quite large and in some cases limits the maximum servo thread rate even though you only get errors at the start)
[11:05:07] <jepler> I think one of my changes will ameliorate that, it basically makes all writes queued when they happen in a realtime context (as opposed to in the setup function)
[11:05:30] <pcw_home> Yeah you would only change the exitation frequency when experimenting (and I doubt the UART is used by anyone)
[11:13:10] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-packetreduction 7cdfb0a 06linuxcnc 03docs/man/man3/rtapi_task_self.3rtapi 10src/rtapi/rtapi.h rtapi: document that rtapi_task_self may be called from init/cleanup * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7cdfb0a
[11:13:11] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-packetreduction 2ec4a89 06linuxcnc 10src/rtapi/rtapi_uspace.hh 10src/rtapi/uspace_rtapi_app.cc uspace: implement rtapi_task_self * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2ec4a89
[11:13:11] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-packetreduction f8e5a2b 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: In realtime context, complain about llio->read * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f8e5a2b
[11:13:13] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-packetreduction 037cc19 06linuxcnc 10src/hal/drivers/mesa-hostmot2/encoder.c hm2: encoder: use already-read latch register * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=037cc19
[11:13:17] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-packetreduction 01bb688 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2.c 10src/hal/drivers/mesa-hostmot2/hostmot2.h 10src/hal/drivers/mesa-hostmot2/tram.c hostmot2: split hm2_finish_write from hm2_tram_write * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=01bb688
[11:13:23] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-packetreduction 0edc52a 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: in realtime context, queue all writes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0edc52a
[11:13:27] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-packetreduction 063ed6a 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2.c 10src/hal/drivers/mesa-hostmot2/hostmot2.h 10src/hal/drivers/mesa-hostmot2/tram.c hostmot2: split hm2_finish_read from hm2_tram_read * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=063ed6a
[11:13:32] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-packetreduction 2b6f34f 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2.c 10src/hal/drivers/mesa-hostmot2/hostmot2.h 10src/hal/drivers/mesa-hostmot2/raw.c hostmot2: make 'raw' queue its read * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2b6f34f
[11:13:37] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-packetreduction 23a5f61 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2.c 10src/hal/drivers/mesa-hostmot2/hostmot2.h 10src/hal/drivers/mesa-hostmot2/tp_pwmgen.c hostmot2: make tp_pwmgen use queue_read * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=23a5f61
[11:13:41] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-packetreduction a0a6c72 06linuxcnc 10docs/man/man9/hm2_eth.9 10src/hal/drivers/mesa-hostmot2/resolver.c 10src/hal/drivers/mesa-hostmot2/uart.c hostmot2: comment about functions that don't work well on hm2_eth * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a0a6c72
[11:13:47] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-packetreduction c969b30 06linuxcnc 10src/hal/drivers/mesa-hostmot2/ioport.c hostmot2: comment on a llio->read that doesn't hurt hm2 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c969b30
[11:13:51] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-packetreduction 1b7bcdf 06linuxcnc 10docs/man/man9/hm2_eth.9 hm2_eth: note some LED gotchas * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1b7bcdf
[11:14:00] <jepler> pcw_home: are you familiar enough with git to be able to test with that branch?
[11:14:25] <pcw_home> yes I think so
[11:14:28] <jepler> OK
[11:15:19] <jepler> I believe I've fixed extra packets from the raw interface and encoder when index / latch are used, and for most conditional writes that happen when parameters are updated
[11:15:55] <pcw_home> fantastic. let me try
[11:16:10] <jepler> but I don't have a very good testing setup and I worry a bit that the way I changed all writes to be queued writes could cause a regression because of something I simply am not thinking through.
[11:16:28] <jepler> my main test was looping a stepgen back to the encoder
[11:18:32] <pcw_home> Yeah I need to make a kitchen sink config to test a good set of modules
[11:20:59] <jepler> afk
[11:36:46] <pcw_home> Yay! that fixes that index enable extra packet
[11:46:15] <pcw_home> In the more distant future, better packet loss tolerance would be nice
[11:46:16] <pcw_home> my hacky solution is for hm2-eth to have a (non sticky) comm-error hal pin
[11:46:18] <pcw_home> (say for rx timeouts). If this is set, MOTION and PID "vamp until ready"
[11:46:19] <pcw_home> (PID freezes its output and motion skips checking ferror )
[11:46:21] <pcw_home> For velocity mode servos and the stepgen, a skipped cycle has realtively minor
[11:46:22] <pcw_home> effects on postion error (only second order errors due to missed velocity updates during accel)
[13:19:18] <jepler> ooh hal-histogram is neat
[13:31:45] <jepler> this merits some more testing, it may be a slight improvement.
http://emergent.unpythonic.net/files/sandbox/0001-hm2_eth-use-poll-to-wait-for-socket-ready-to-read.patch http://emergent.unpythonic.net/files/sandbox/read-time-delay.png http://emergent.unpythonic.net/files/sandbox/read-time-poll.png
[13:32:15] <jepler> I would have expected it to decrease the average by 1/2 * READ_PCK_DELAY_NS = 5us but it's not actually what I measured.
[13:33:41] <jepler> (+ whatever benefit to not calling rtapi_get_time at least twice)
[15:44:56] <jepler> $ elbpcom --space 7 --size 2 --address 0 --read 7
[15:44:57] <jepler> > 875d0000
[15:44:57] <jepler> < 3749383048442d3136000000ffff
[15:44:57] <jepler> 7I80HD-16.....
[15:45:10] <jepler> yay now I won't have to remember lbp16 commands myself
[15:45:29] <jepler> I'd still have to look up that e.g., led control is in space 6, address 0x14 but it's still a step in the right direction
[15:48:04] <jepler> PCW: this elbpcom is very distantly based on the one from 7i80dbman.pdf -- OK to slap a GPL on and add to linuxcnc?
[16:57:45] <PCW> sure
[16:58:53] <PCW> the resolver works with the reduced packet branch, trying SSI next
[17:01:38] <PCW> I guess you could eliminate the size field
[17:02:52] <PCW> I notice there's a nice warning of added packets (i set the resolver excitation frequency)
[17:03:28] <jepler> yes. it's only printed one time per run, so you can't tell the difference between "a couple extras after setup" and "extras every servo cycle"
[17:04:27] <PCW> probably a good thing at this stage
[17:04:29] <jepler> yes, if I understand properly I *could* get rid of size by reading it out of the information space, which always reads with size 2. is that what you mean?
[17:05:16] <PCW> yes each space as a descriptor that specifies the data size and address range
[17:05:31] <PCW> has a descriptor
[17:05:55] <PCW> and name
[17:06:57] <PCW> on the otherhand its now a lot better than obscure backwards byte streams in hex
[17:07:15] <jepler> is there no space 5?
[17:07:26] <PCW> not ATM
[17:08:13] <jepler> ah ok
[17:08:18] <jepler> was puzzled I was getting a no-response
[17:08:52] <jepler> so I guess I would pick the biggest size which is supported and which evenly divides the requested length (which would now be in bytes, not elements)?
[17:11:52] <PCW> I think you can read the info space for space 5 but it will not have a cookie
[17:13:33] <PCW> Hmm the manual is not clear I think all sizes are bytes though (all addresses are byte addresses)
[17:15:23] <jepler> In my example above I requested to read 7 and I got 14 bytes
[17:16:27] <PCW> read write requests are in elements
[17:17:33] <PCW> info area address ranges are in log2(byte range)
[17:18:31] <jepler> ok
[17:19:57] <jepler> it looks like in practice only a single element size is supported for each space?
[17:22:24] <PCW> yes though the info area allows specifying ares that have multiple size access
[17:22:30] <PCW> areas
[17:24:40] <PCW> but there's no way currently to specify anything other than the 'native' size
[17:43:30] <jepler> elbpcom --space 4 --info --address 2 --read 4
[17:43:40] <jepler> > 82710200
[17:43:40] <jepler> < 02820400
[17:43:40] <jepler> ....
[17:44:15] <PCW> space 4 is a bit magic
[17:44:19] <jepler> my program gets address range 0 .. 16 bytes from this, but the manual I have says that space 4 has scratch registers at 0x0010 .. 0x001e
[17:45:00] <PCW> what firmware version?
[17:45:07] <jepler> probably quite old
[17:45:36] <PCW> yeah space 4 got fancy timer stuff added
[17:45:37] <jepler> before PLL I'm pretty sure
[17:45:56] <PCW> yeah timer stuff is DPLL dependent
[17:48:23] <PCW> at least the hm2 timer stuff (the usec timer is independent)
[18:01:21] <PCW> I may drop/change space 1 as there's no real reason for low level access to the Ethernet chip unless doing some pretty low level hardware debugging
[18:04:27] <PCW> hmm with the resolver interface there's a 8, a 16, and a 32 bit processor in the FPGA
[18:05:11] <PCW> resolver with sserial I mean
[19:54:20] <jepler> PCW: did you identify any problems with my branch? does it cover what you wanted to see in 2.7?
[19:54:42] <jepler> seb_kuzminsky: if PCW feels good about it, how do you feel about me pushing it to 2.7? (jepler/hm2-eth-packetreduction)
[19:55:01] <PCW> no new problems
[19:55:24] <KGB-linuxcnc> 03Jeff Epler 05jepler/elbpcom 45cf42e 06linuxcnc 03docs/man/man1/elbpcom.1 10src/hal/utils/Submakefile 03src/hal/utils/elbpcom.py elpbcom: communicate directly with mesa ethernet cards * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=45cf42e
[19:55:30] <PCW> found a problem but master has the same issue
[19:55:53] <jepler> also for your review I put my elbpcom on another independent branch
[19:56:21] <PCW> Great, Ill try it when i get a chance
[19:56:42] <PCW> trying to track down a crash bug
[19:57:02] <jepler> ugh, want me to try reproducing it here?
[19:57:33] <PCW> probably need to wait until Ive narrowed it down a bit
[19:58:15] <PCW> resolver and DPLL in same config = crash
[19:58:37] <PCW> need to try on PCI first
[19:58:49] <jepler> ok, I wouldn't have a firmware to test with anyhow
[19:59:18] <jepler> you can attach gdb to rtapi_app, which will let you stop at the crash site. as long as you don't mind totally missing all your realtime deadlines.
[19:59:39] <jepler> depends if you're the type who likes debuggers or printfs :-P
[20:02:01] <PCW> freeby.mesanet.com/7i80hd_16_rmesvss6_6d.bit crash
[20:02:03] <PCW> freeby.mesanet.com/7i80hd_16_rmesvss6_6.bit no crash
[20:02:48] <PCW> but I probably need to make a 5i23 of other PCI card version to see if its hm2_eth specific
[20:03:09] <PCW> and I'm burnt out for today
[20:03:21] <jepler> see ya
[20:04:29] <PCW> time for dinner and a nice dog walk
[20:04:34] <PCW> bbl
[20:27:43] <KGB-linuxcnc> 03Chris Morley 052.7 89dbd1b 06linuxcnc 10src/emc/usr_intf/pncconf/pncconf.py pncconf -fix sserial combobox not select-able * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=89dbd1b
[21:10:38] <seb_kuzminsky> jepler: in "hostmot2: split hm2_finish_write from hm2_tram_write", it's weird to me that you move the tram_write_iteration++ out of hm2_tram_write(), but i guess it doesn't substantially change the behavior
[21:14:30] <seb_kuzminsky> jepler: in "hm2_eth: In realtime context, complain about llio->read", do you want a similar warning for llio->write?
[21:14:50] <seb_kuzminsky> other than those minor nitpicks, looks fine for 2.7
[21:25:45] <jepler> seb_kuzminsky: I can move the increment to a more sensible place
[21:26:02] <jepler> seb_kuzminsky: llio->read becomes a complaint, llio->write becomes llio->queue_write
[21:26:47] <jepler> seb_kuzminsky: llio->read has to be satisfied immediately, while I think all llio->writes can safely be queued as long as we fire the pending writes before finishing the hal function
[21:26:53] <jepler> seb_kuzminsky: thanks for the review.
[21:44:34] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-packetreduction 1ff8d47 06linuxcnc 03docs/man/man3/rtapi_task_self.3rtapi 10src/rtapi/rtapi.h rtapi: document that rtapi_task_self may be called from init/cleanup * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1ff8d47
[21:44:34] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-packetreduction e1811b5 06linuxcnc 10src/rtapi/rtapi_uspace.hh 10src/rtapi/uspace_rtapi_app.cc uspace: implement rtapi_task_self * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e1811b5
[21:44:34] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-packetreduction 68aed55 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: In realtime context, complain about llio->read * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=68aed55
[21:44:37] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-packetreduction 7725e39 06linuxcnc 10src/hal/drivers/mesa-hostmot2/encoder.c hm2: encoder: use already-read latch register * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7725e39
[21:44:41] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-packetreduction b1d6518 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2.c 10src/hal/drivers/mesa-hostmot2/hostmot2.h 10src/hal/drivers/mesa-hostmot2/tram.c hostmot2: split hm2_finish_write from hm2_tram_write * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b1d6518
[21:44:46] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-packetreduction 6b52f68 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: in realtime context, queue all writes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6b52f68
[21:44:50] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-packetreduction 63704a3 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2.c 10src/hal/drivers/mesa-hostmot2/hostmot2.h 10src/hal/drivers/mesa-hostmot2/tram.c hostmot2: split hm2_finish_read from hm2_tram_read * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=63704a3
[21:44:55] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-packetreduction 4a1b81d 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2.c 10src/hal/drivers/mesa-hostmot2/hostmot2.h 10src/hal/drivers/mesa-hostmot2/raw.c hostmot2: make 'raw' queue its read * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4a1b81d
[21:45:00] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-packetreduction 1e7a4d2 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2.c 10src/hal/drivers/mesa-hostmot2/hostmot2.h 10src/hal/drivers/mesa-hostmot2/tp_pwmgen.c hostmot2: make tp_pwmgen use queue_read * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1e7a4d2
[21:45:05] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-packetreduction 067b8f7 06linuxcnc 10docs/man/man9/hm2_eth.9 10src/hal/drivers/mesa-hostmot2/resolver.c 10src/hal/drivers/mesa-hostmot2/uart.c hostmot2: comment about functions that don't work well on hm2_eth * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=067b8f7
[21:45:10] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-packetreduction 6246ac6 06linuxcnc 10src/hal/drivers/mesa-hostmot2/ioport.c hostmot2: comment on a llio->read that doesn't hurt hm2 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6246ac6
[21:45:14] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-packetreduction da07d64 06linuxcnc 10docs/man/man9/hm2_eth.9 hm2_eth: note some LED gotchas * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=da07d64
[22:18:57] <jepler> huh, the wolfram "rule 30" CA makes a not-bad PRNG. Apparently it has long been used in Mathematica for that purpose.
[22:20:44] <jepler> I didn't find an exact description of the Mathematica algorithm, but my program runs rule 30 in a 64-bit circular buffer starting with a single "1" bit; the output of the RNG is each successive value of bit 0 of the buffer after applying the CA rule
[22:21:47] <jepler> it failes .07% of rngtest (FIPS) tests, which is comparable to /dev/urandom
[22:41:56] <jepler> ooh it's bedtime
