Back
[00:00:22] -!- Nick001-shop has quit [Remote host closed the connection]
[00:01:27] -!- deanputney has quit [Remote host closed the connection]
[00:02:35] -!- deanputney [deanputney!~mustardha@c-67-183-112-251.hsd1.wa.comcast.net] has joined #linuxcnc-devel
[00:03:32] <jepler> 13:23:33 < skunkworks> Bring up axis sim -> home -> run splash screen program -> hit estop -> then either hit the refresh or try to open another program.
[00:03:43] -!- Camaban has quit [Quit: Leaving]
[00:03:49] <jepler> reproduced. debugging shows axis is hung at the wait_complete call:
[00:03:56] <jepler> File "/home/jepler/src/linuxcnc/bin/axis", line 1096, in open_file_guts
[00:03:59] <jepler> ensure_mode(linuxcnc.MODE_MDI)
[00:04:02] <jepler> File "/home/jepler/src/linuxcnc/bin/axis", line 899, in ensure_mode
[00:04:04] <jepler> c.wait_complete()
[00:09:40] <jepler> emcWaitCommandComplete echo_serial_number=21 serial=21 status=RCS_EXEC
[00:10:11] <jepler> axis expects that for the command to be complete, either the echo_serial_number is bigger than serial, or status is RCS_DONE or RCS_ERROR
[00:14:08] -!- deanputney has quit [Remote host closed the connection]
[00:15:20] -!- mhaberler has quit [Quit: mhaberler]
[00:19:09] <jepler> in milltask, some of the parts of this long expression are false
[00:19:10] <jepler> 3428 } else if (!taskPlanError && !taskExecuteError &&
[00:20:15] <jepler> (gdb) p emcStatus->task.execState
[00:20:15] <jepler> $12 = EMC_TASK_EXEC_WAITING_FOR_MOTION_AND_IO
[00:20:20] <jepler> (gdb) p emcStatus->motion.status
[00:20:21] <jepler> $13 = 2
[00:20:23] <jepler> [RCS_EXEC]
[00:20:36] <jepler> (gdb) p emcTaskCommand
[00:20:36] <jepler> $10 = (NMLmsg *) 0x256dbc0
[00:20:49] <jepler> (gdb) p emcTaskCommand->type
[00:20:49] <jepler> $16 = 516
[00:21:23] <jepler> [EMC_TASK_PLAN_SYNCH_TYPE]
[00:21:59] <jepler> so IMHO this bug should be investigated as a bug in task, not ui
[00:23:17] -!- patrickarlt has quit [Quit: Leaving...]
[00:25:00] -!- Loetmichel has quit [Ping timeout: 256 seconds]
[00:25:47] <jepler> .. afk
[00:33:39] -!- FreezingCold has quit [Ping timeout: 256 seconds]
[00:45:27] -!- jerryitt has quit [Quit: Connection closed for inactivity]
[00:59:19] <cradek> ick
[01:02:34] -!- tinkerer has quit [Quit: Leaving.]
[01:03:31] -!- anth0ny_ has quit [Client Quit]
[01:22:01] -!- sumpfralle has quit [Ping timeout: 264 seconds]
[01:22:36] -!- zeeshan-- has quit [Quit: Page closed]
[01:27:43] -!- anth0ny_ has quit [Client Quit]
[01:29:04] <skunkworks> I keep meaning to create a tracker
[01:29:08] <skunkworks> *bug
[01:29:28] -!- FreezingCold has quit [Ping timeout: 272 seconds]
[01:29:28] -!- sumpfralle has quit [Read error: Connection reset by peer]
[01:33:40] -!- PetefromTn_ [PetefromTn_!~IceChat9@75-136-60-251.dhcp.jcsn.tn.charter.com] has joined #linuxcnc-devel
[01:38:09] -!- sumpfralle has quit [Read error: Connection reset by peer]
[01:38:13] -!- Vq has quit [Ping timeout: 252 seconds]
[01:44:55] -!- sumpfralle has quit [Read error: Connection reset by peer]
[01:50:13] -!- sumpfralle has quit [Read error: Connection reset by peer]
[01:51:31] -!- anth0ny_ has quit [Quit: anth0ny_]
[01:56:25] -!- sumpfralle has quit [Read error: Connection reset by peer]
[02:00:16] -!- MacGalempsy has quit [Ping timeout: 255 seconds]
[02:02:24] -!- sumpfralle has quit [Read error: Connection reset by peer]
[02:10:15] -!- sumpfralle has quit [Read error: Connection reset by peer]
[02:14:16] -!- sumpfralle has quit [Read error: Connection reset by peer]
[02:22:13] -!- sumpfralle has quit [Read error: Connection reset by peer]
[02:27:49] -!- PetefromTn_ has quit [Quit: I'm Outta here!!]
[02:30:23] -!- sumpfralle has quit [Read error: Connection reset by peer]
[02:42:19] -!- sumpfralle has quit [Read error: Connection reset by peer]
[02:50:42] -!- danylevskyi has quit [Remote host closed the connection]
[02:58:00] -!- sumpfralle has quit [Read error: Connection reset by peer]
[03:11:30] -!- crazy_imp has quit [Ping timeout: 252 seconds]
[03:12:49] -!- asdfasd has quit [Ping timeout: 244 seconds]
[03:12:49] -!- sumpfralle has quit [Read error: Connection reset by peer]
[03:16:36] -!- CaptHindsight has quit [Ping timeout: 240 seconds]
[03:16:42] -!- memfrob has quit [Ping timeout: 256 seconds]
[03:17:00] -!- MrHindsight has quit [Ping timeout: 252 seconds]
[03:28:34] -!- AR_ has quit [Ping timeout: 245 seconds]
[03:30:49] -!- ve7it has quit [Remote host closed the connection]
[03:30:54] -!- FreezingCold has quit [Ping timeout: 276 seconds]
[03:33:56] -!- MrHindsight [MrHindsight!~not_sure@adsl-75-57-144-88.dsl.emhril.sbcglobal.net] has joined #linuxcnc-devel
[03:33:56] -!- MrHindsight has quit [Changing host]
[03:33:56] -!- MrHindsight [MrHindsight!~not_sure@unaffiliated/capthindsight] has joined #linuxcnc-devel
[03:34:30] -!- memfrob [memfrob!~irc@75.57.144.88] has joined #linuxcnc-devel
[03:34:46] -!- memfrob has quit [Changing host]
[03:34:46] -!- memfrob [memfrob!~irc@unaffiliated/memfrob] has joined #linuxcnc-devel
[03:34:55] -!- CaptHindsight [CaptHindsight!~2020@unaffiliated/capthindsight] has joined #linuxcnc-devel
[04:12:01] -!- Tecan has quit [Quit: Live Long And Phosphor!]
[04:20:09] -!- dgarr has quit [Quit: Leaving.]
[04:56:34] -!- amiri_ has quit [Ping timeout: 272 seconds]
[05:11:07] -!- kriskropd has quit [Ping timeout: 264 seconds]
[05:15:06] -!- JohnyK [JohnyK!~wity@witypc.ynet.sk] has joined #linuxcnc-devel
[05:42:21] -!- kwallace [kwallace!~kwallace@tmb-214.sonnet.com] has parted #linuxcnc-devel
[06:07:06] -!- anth0ny_ has quit [Quit: anth0ny_]
[06:44:35] -!- norias has quit [Quit: Leaving]
[07:00:11] -!- KimK [KimK!~Kim__@ip68-102-30-143.ks.ok.cox.net] has joined #linuxcnc-devel
[07:28:43] -!- kanzure has quit [Ping timeout: 245 seconds]
[07:47:31] -!- eventor [eventor!~eventor@p5DDD52AE.dip0.t-ipconnect.de] has joined #linuxcnc-devel
[07:58:07] -!- Miner_48er has quit [Quit: Leaving]
[08:09:31] -!- f1oat7 [f1oat7!~f1oat@AMontsouris-553-1-113-197.w92-151.abo.wanadoo.fr] has joined #linuxcnc-devel
[08:35:25] -!- mhaberler has quit [Quit: mhaberler]
[09:19:40] -!- KimK has quit [Ping timeout: 250 seconds]
[09:39:09] Vq_ is now known as Vq
[10:07:19] -!- moorbo has quit [Ping timeout: 245 seconds]
[10:23:09] -!- danylevskyi has quit [Ping timeout: 245 seconds]
[10:51:28] -!- mhaberler has quit [Quit: mhaberler]
[11:05:06] -!- b_b has quit [Changing host]
[11:52:17] -!- danylevskyi has quit [Ping timeout: 246 seconds]
[12:12:29] <jepler> hmmm
[12:12:29] <jepler> On branch 2.7
[12:12:29] <jepler> Your branch is up-to-date with 'origin/2.7'.
[12:12:43] <jepler> but my axis identifies as 2.8.0~pre1
[12:14:54] <jepler> this stale information was stored in autom4te.cache
[12:15:30] <jepler> aha
[12:21:49] <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
[12:21:50] <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
[12:21:50] <KGB-linuxcnc> 03Jeff Epler 05master fa8867a 06linuxcnc Merge branch '2.6' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fa8867a
[12:52:44] -!- mhaberler has quit [Quit: mhaberler]
[14:26:20] -!- toastydeath has quit [Read error: No route to host]
[14:31:55] -!- tinkerer [tinkerer!~tinkerer@mail.play-pla.net] has joined #linuxcnc-devel
[14:34:17] -!- karavanjo has quit [Quit: karavanjo]
[14:40:40] -!- syyl has quit [Ping timeout: 256 seconds]
[15:19:20] -!- moorbo has quit [Ping timeout: 250 seconds]
[15:19:21] -!- kwallace [kwallace!~kwallace@smb-161.sonnet.com] has joined #linuxcnc-devel
[15:20:06] <jepler> pcw_home: what's the trick to user-controlled LEDs on the 7i80-hd?
[15:20:28] <jepler> pcw_home: also I notice the hal pins may not match the silkscreen
[15:22:13] <pcw_home> umm... let me see...
[15:23:12] <jepler> I know it has something to do with how 3 of the LEDs count up as packets are transmitted or something
[15:23:55] <jepler> er I guess they all do
[15:24:28] <jepler> one was just unchanging to the eye because I was always transmitting 2 packets per thread invocation
[15:25:00] <pcw_home> look at memory space 6 location 14
[15:25:17] <pcw_home> if thats set to 0 you get hostmot2 leds
[15:25:28] <jepler> that's not something I can write with the hm2 raw interface is it
[15:25:34] <jepler> I have that script somewhere though
[15:26:51] <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.
[15:26:59] <pcw_home> no, you need to access space 6
[15:27:01] <pcw_home> 01D914000000 shoud do
[15:27:24] <jepler> thanks, saves me figuring that out
[15:27:25] -!- b_b has quit [Remote host closed the connection]
[15:27:27] <pcw_home> sserial seems OK
[15:27:54] <jepler> oh really? I didn't test it, it was just based on reading the code
[15:28:24] <jepler> and resolver *may* only be generating extra packets at startup
[15:28:29] <pcw_home> (note thats only temporary, you would need to write the EEPROM to make the LED change presistent)
[15:28:45] <pcw_home> persistent
[15:29:49] <jepler> pcw_home: so my silkscreen has year 2002 and I don't see a revision code
[15:30:10] <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
[15:30:10] <jepler> pcw_home: and the LEDs that are controlled are silkscreened CR3..6
[15:30:22] <jepler> but hal shows them as CR01..CR04
[15:30:55] <jepler> so (A) is my silkscreen 'current' and (B) is it worth breaking configs that use the LEDs to make hal match the silkscreen?
[15:31:28] <jepler> err year 2012 of course
[15:31:52] <pcw_home> leds are the same on all revs (CR1..4) is probablycopy/pasted from some other board
[15:32:43] <jepler> it looks like it's hardcoded in the hal driver that the first LED is CR(0)0
[15:32:47] <pcw_home> not sure about 7I92, it may have different LED names
[15:32:49] -!- grummund has quit [Ping timeout: 264 seconds]
[15:32:49] <jepler> err CR(0)1
[15:33:21] <pcw_home> maybe it just means the LED LSB
[15:33:24] <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
[15:34:45] <pcw_home> I dont think many people use the LEDsm but you can see i used them fro debugging (the LED debug pointer stuff)
[15:35:25] <jepler> yeah
[15:35:56] <pcw_home> i also have conditional code to use the I/O for debugging
[15:37:53] -!- mhaberler has quit [Ping timeout: 245 seconds]
[15:37:53] mhaberler_ is now known as mhaberler
[15:38:09] -!- mhaberler has quit [Read error: Connection reset by peer]
[15:40:37] <jepler> hm2_resolver_write will generate extra packets when the excitation_khz parameter is changed, but won't in normal operation
[15:42:15] <jepler> and hm2_uart_read calls llio->read in a loop, so it'll be really bad
[15:42:34] <pcw_home> I'm pretty sure lots of setup code uses quite a few unqueued accesses
[15:42:35] <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)
[15:43:26] <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)
[15:43:50] <pcw_home> Yeah you would only change the exitation frequency when experimenting (and I doubt the UART is used by anyone)
[15:47:40] -!- KimK [KimK!~Kim__@ip68-102-30-143.ks.ok.cox.net] has joined #linuxcnc-devel
[15:51:30] <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
[15:51:30] <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
[15:51:30] <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
[15:51:33] <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
[15:51:37] <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
[15:51:43] <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
[15:51:47] <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
[15:51:52] <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
[15:51:56] <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
[15:52:01] <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
[15:52:06] <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
[15:52:10] <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
[15:52:20] <jepler> pcw_home: are you familiar enough with git to be able to test with that branch?
[15:52:44] <pcw_home> yes I think so
[15:52:47] <jepler> OK
[15:53:39] <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
[15:54:14] <pcw_home> fantastic. let me try
[15:54:29] <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.
[15:54:48] <jepler> my main test was looping a stepgen back to the encoder
[15:56:51] <pcw_home> Yeah I need to make a kitchen sink config to test a good set of modules
[15:59:18] <jepler> afk
[16:10:55] -!- KimK has quit [Ping timeout: 256 seconds]
[16:15:05] <pcw_home> Yay! that fixes that index enable extra packet
[16:24:34] <pcw_home> In the more distant future, better packet loss tolerance would be nice
[16:24:36] <pcw_home> my hacky solution is for hm2-eth to have a (non sticky) comm-error hal pin
[16:24:37] <pcw_home> (say for rx timeouts). If this is set, MOTION and PID "vamp until ready"
[16:24:39] <pcw_home> (PID freezes its output and motion skips checking ferror )
[16:24:40] <pcw_home> For velocity mode servos and the stepgen, a skipped cycle has realtively minor
[16:24:42] <pcw_home> effects on postion error (only second order errors due to missed velocity updates during accel)
[16:42:53] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[17:09:24] -!- gonzo_nb has quit [Ping timeout: 245 seconds]
[17:17:07] -!- Mr_Sheesh has quit [Disconnected by services]
[17:18:51] -!- Roguish [Roguish!~chatzilla@c-50-143-183-159.hsd1.ca.comcast.net] has joined #linuxcnc-devel
[17:20:02] -!- anth0ny_ has quit [Quit: anth0ny_]
[17:22:46] -!- tocka has quit [Quit: tocka]
[17:37:19] -!- Mr_Sheesh has quit [Ping timeout: 245 seconds]
[17:40:27] -!- messine has quit [Ping timeout: 256 seconds]
[17:40:44] -!- Mr_Sheesh has quit [Excess Flood]
[17:44:41] -!- MrHindsight has quit [Remote host closed the connection]
[17:48:27] -!- Mr_Sheesh has quit [Remote host closed the connection]
[17:50:07] -!- Mr_Sheesh has quit [Excess Flood]
[17:53:30] -!- MrHindsight [MrHindsight!~not_sure@adsl-75-57-144-88.dsl.emhril.sbcglobal.net] has joined #linuxcnc-devel
[17:53:30] -!- MrHindsight has quit [Changing host]
[17:53:30] -!- MrHindsight [MrHindsight!~not_sure@unaffiliated/capthindsight] has joined #linuxcnc-devel
[17:57:37] <jepler> ooh hal-histogram is neat
[18:08:19] -!- Mr_Sheesh has quit [Remote host closed the connection]
[18:10:04] <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
[18:10:34] <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.
[18:12:01] <jepler> (+ whatever benefit to not calling rtapi_get_time at least twice)
[18:14:16] -!- Mr_Sheesh has quit [Remote host closed the connection]
[18:26:13] -!- Mr_Sheesh has quit [Remote host closed the connection]
[18:29:42] -!- Mr_Sheesh has quit [Client Quit]
[18:33:30] -!- anth0ny_ has quit [Quit: anth0ny_]
[19:00:56] -!- zeitue has quit [Ping timeout: 240 seconds]
[19:01:29] -!- capricorn_1 has quit [Ping timeout: 245 seconds]
[19:12:31] -!- syyl_ws has quit [Quit: Verlassend]
[19:19:27] -!- anth0ny_ has quit [Quit: anth0ny_]
[19:20:12] -!- anth0ny_ has quit [Client Quit]
[19:21:59] -!- mozmck has quit [Read error: No route to host]
[19:22:30] -!- mozmck [mozmck!~moses@67.210.159.245] has joined #linuxcnc-devel
[19:41:27] -!- PCW [PCW!~chatzilla@99.88.10.65] has joined #linuxcnc-devel
[20:12:19] -!- amiri has quit [Ping timeout: 245 seconds]
[20:18:28] -!- [qube] has quit []
[20:18:41] -!- [cube] has quit [Read error: Connection reset by peer]
[20:23:16] <jepler> $ elbpcom --space 7 --size 2 --address 0 --read 7
[20:23:16] <jepler> > 875d0000
[20:23:16] <jepler> < 3749383048442d3136000000ffff
[20:23:16] <jepler> 7I80HD-16.....
[20:23:30] <jepler> yay now I won't have to remember lbp16 commands myself
[20:23:48] <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
[20:26:23] <jepler> PCW: this elbpcom is very distantly based on the one from 7i80dbman.pdf -- OK to slap a GPL on and add to linuxcnc?
[20:43:36] -!- karavanjo1 has quit [Ping timeout: 240 seconds]
[20:44:02] -!- karavanjo has quit [Ping timeout: 272 seconds]
[21:08:22] -!- anth0ny_ has quit [Quit: anth0ny_]
[21:15:40] -!- Deejay has quit [Quit: bye]
[21:36:04] <PCW> sure
[21:37:12] <PCW> the resolver works with the reduced packet branch, trying SSI next
[21:39:57] <PCW> I guess you could eliminate the size field
[21:41:12] <PCW> I notice there's a nice warning of added packets (i set the resolver excitation frequency)
[21:41:47] <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"
[21:42:46] <PCW> probably a good thing at this stage
[21:42:48] <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?
[21:43:35] <PCW> yes each space as a descriptor that specifies the data size and address range
[21:43:50] <PCW> has a descriptor
[21:44:14] <PCW> and name
[21:45:17] <PCW> on the otherhand its now a lot better than obscure backwards byte streams in hex
[21:45:34] <jepler> is there no space 5?
[21:45:45] <PCW> not ATM
[21:46:33] <jepler> ah ok
[21:46:37] <jepler> was puzzled I was getting a no-response
[21:47:11] <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)?
[21:50:11] <PCW> I think you can read the info space for space 5 but it will not have a cookie
[21:51:52] <PCW> Hmm the manual is not clear I think all sizes are bytes though (all addresses are byte addresses)
[21:53:42] <jepler> In my example above I requested to read 7 and I got 14 bytes
[21:54:46] <PCW> read write requests are in elements
[21:55:52] <PCW> info area address ranges are in log2(byte range)
[21:56:51] <jepler> ok
[21:58:17] <jepler> it looks like in practice only a single element size is supported for each space?
[22:00:43] <PCW> yes though the info area allows specifying ares that have multiple size access
[22:00:49] <PCW> areas
[22:03:00] <PCW> but there's no way currently to specify anything other than the 'native' size
[22:21:49] <jepler> elbpcom --space 4 --info --address 2 --read 4
[22:21:59] <jepler> > 82710200
[22:22:00] <jepler> < 02820400
[22:22:00] <jepler> ....
[22:22:34] <PCW> space 4 is a bit magic
[22:22:38] <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
[22:23:19] <PCW> what firmware version?
[22:23:27] <jepler> probably quite old
[22:23:34] -!- adb has quit [Ping timeout: 252 seconds]
[22:23:55] <PCW> yeah space 4 got fancy timer stuff added
[22:23:56] <jepler> before PLL I'm pretty sure
[22:24:15] <PCW> yeah timer stuff is DPLL dependent
[22:26:42] <PCW> at least the hm2 timer stuff (the usec timer is independent)
[22:37:32] -!- rob_h [rob_h!~robh@94.10.126.60] has joined #linuxcnc-devel
[22:39:40] <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
[22:40:23] -!- Miner_48er has quit [Ping timeout: 245 seconds]
[22:42:47] <PCW> hmm with the resolver interface there's a 8, a 16, and a 32 bit processor in the FPGA
[22:43:31] <PCW> resolver with sserial I mean
[22:49:01] -!- mhaberler has quit [Ping timeout: 264 seconds]
[22:49:01] mhaberler_ is now known as mhaberler
[23:00:16] -!- messine has quit [Ping timeout: 240 seconds]
[23:08:44] -!- mhaberler has quit [Quit: mhaberler]
[23:13:23] -!- eventor has quit [Ping timeout: 246 seconds]
[23:16:32] -!- JohnyK has quit [Ping timeout: 264 seconds]
[23:42:00] -!- f1oat7 has quit [Ping timeout: 272 seconds]
[23:56:50] -!- Nick001-shop has quit [Quit: ChatZilla 0.9.91.1 [Firefox 34.0.5/20141126041045]]
