Back
[01:48:14] <KGB-linuxcnc> 03chrisinnanaimo 05gmoccapy_install_fix 14a3bfc 06linuxcnc 10debian/linuxcnc.files.in * install gmoccapy - here we go again
[14:56:09] <alex_jon1> 'lo
[15:31:17] <alex_jon1> can someone else confirm the wiki works now?
[15:33:07] <alex_jon1> cradek, skunkworks, CaptHindsight, archivist_: ^^
[15:48:47] <andypugh> alex_jon1: I just tried logging in, and it worked (unlike last time I tried)
[16:23:52] <alex_jon1> andypugh: good, so it's fixed
[16:24:41] <andypugh> Seems ot be. I would need to try again from the PC at work to be completely sure.
[16:25:00] <alex_jon1> it was a pretty stupid bug
[16:25:25] <alex_jon1> who wrote the wiki sftware had a cookie that expired on 8 sept 2013
[16:25:42] <alex_jon1> so trying after that date didn't work anymore, since the cookie was already expired..
[16:40:02] <andypugh> I wonder why that date?
[17:15:52] <CaptHindsight> alex_jon1: works for me now as well
[17:20:10] <micges> skunkworks: around?
[17:20:31] <micges> pcw_home: around?
[17:44:27] <skunkworks> micges: yes>
[17:44:27] <skunkworks> ?
[17:44:41] <micges> tell me what hardware you used to run 7i80
[17:48:02] <skunkworks> computer wise?
[17:48:04] <micges> I mean what mb and eth board
[17:48:05] <skunkworks> or nic?
[17:48:09] <pcw_home> I have a D525
[17:48:17] <micges> and what system
[17:48:23] <skunkworks> I was using the pro/100 pci card
[17:48:24] <pcw_home> it has a 8139 nic in it also
[17:48:40] <pcw_home> ubuntu 12.04
[17:48:41] <skunkworks> I don't know the motherboards - but I could look monday
[17:48:51] <skunkworks> 12.04 also
[17:49:56] <micges> skunkworks: ok, ping me then
[17:50:34] <micges> why both of you choose 12.04 for tests?
[17:51:44] <pcw_home> In my case I already had it running
[17:53:29] <micges> here I have 10.04 + rt8139 + 7i80DB run perfectly for few hours
[17:53:36] <micges> no encoder errors
[17:53:55] <micges> 7i80.read.time is about 250us
[17:54:07] <micges> 7i80.write.time is about 50us
[17:54:23] <pcw_home> is read still made up of multiple packets?
[17:55:13] <micges> no
[17:55:17] <micges> one read for all
[17:55:35] <skunkworks> I tried 10.04 with xenomai and it acted the same.
[17:55:47] <micges> but few random reads left (hard to fix)
[17:56:28] <micges> skunkworks: I odn't have pro/100 board but I can test on e1000
[17:57:02] <micges> maybe problem is sth about eth data flow on different boards
[17:58:01] <pcw_home> Thats seems strange though, I wouls not expect any difference with MAC or OS except maybe timing
[17:58:50] <micges> yes timing is my first suspect
[17:59:40] <pcw_home> I do have V14 firmware but I still need to test it
[18:00:17] <micges> ok, I'm trying again port it to rtai (got new data), then port driver to unified biuld and then fix and improve driver
[18:00:35] <micges> in between rt-preempt kernel is cooking
[18:01:47] <pcw_home> someone (memleak) was possible looking into RTNet on RTAI (I think it was originally written for RTAI)
[18:02:18] <micges> rtnet for rtai is working
[18:02:37] <micges> rtai have lack of part of interface I'm using to boot driver
[18:03:16] <pcw_home> it the timing stuff is robust enough, the read packet should be send-able one wire time before the servo thread on the host
[18:03:26] <pcw_home> if the
[18:03:33] <micges> and I spoke with him and anothr guy how to fix it, at least temporary
[18:04:35] <pcw_home> so the startup scripts/other infrastructure are missing?
[18:05:31] <micges> for now rt_task_join doesn't work
[18:06:17] <micges> it is used to wait after creating rt task to init board
[18:06:46] <micges> any other wait scheme goes into hang or dead loop
[18:09:29] <pcw_home> if there were only a simple synchronous Ethernet hardware access method.
[18:09:31] <pcw_home> Even interrupts are unnecessary overhead for this type of application
[18:14:19] <pcw_home> I'm am surprised at how robust the 7I80 because of its
[18:14:21] <pcw_home> simple 1 thread synchronous design (too stupid to screw up)
[18:14:22] <pcw_home> I often forget I have some test loopback running on the 7I80 in one window and
[18:14:24] <pcw_home> then run mesaflash in the other to reprogram the 7I80, works flawlessly!
[18:15:13] <micges> great
[18:16:07] <pcw_home> Not that its intended to have multiple masters, it just happens to work
[18:17:24] <micges> it seems it have enough atomic and simple interface for it
[18:19:30] <pcw_home> Im really curious what the jitter statistics will be in a real system
[18:21:00] <pcw_home> if they have a small std-deviation, the DPLL filter can do a really good job of filtering the jitter out
[18:24:07] <pcw_home> I did learn that Windows has some very peculiar Ethernet timing
[18:24:09] <pcw_home> (at certain update rates the I/O cycle gets locked to 64 Hz)
[18:33:51] <micges> heh
[18:34:58] <micges> another windows odd behavoiur
[19:04:45] <pcw_home> I made use of the strange regularity for testing the DPLL
[19:12:16] <micges> how mesaflash is working under windows for 7i80?
[19:12:24] <micges> any adress problems?
[20:17:48] <pcw_home> Not that I've seen
[20:18:12] <pcw_home> and we use it all the time.
[20:18:58] <pcw_home> Windows does have a bug with UDP you have to be aware of however
[20:21:00] <pcw_home> if it decides to time out an entry in its ARP cache, it will silently drop the first packet sent to the address it dropped
[20:21:01] <pcw_home>
[20:21:58] <pcw_home> so you are better with static ARP entries if you run stuff continuously