Back
[14:25:02] <Tom_itx> sure it is
[14:25:29] <pcw_mesa> Amazing how cheap FO transceivers have become $6.50 for 1.25 GB/S 20 KM dual wavelength full duplex
[14:31:51] <jepler_> pcw_mesa: planning daughtercards that use FO in lieu of copper?
[14:33:11] <pcw_mesa> I have though about it in the past but the transceiver cost was prohibitive
[14:37:50] <pcw_mesa> These are not baseband so wont work for serial replacement (you need a no-DC modulation like 8/10)
[14:44:09] <pcw_mesa> but they will work for Ethernet
[14:44:18] <jepler_> 8b/10b doesn't look too hard
[14:44:47] <jepler_> a couple of fiddly tables to implement, and tracking the running disparity, and handling the punctuation
[14:45:12] <pcw_mesa> no its not (and its built-in to the low speed SerDes in newer Xilinx FPGAs)
[14:46:03] <jepler_> sounds too easy. make it complicated by going up to 128b/130b.
[14:46:26] <pcw_mesa> more efficient
[14:46:45] <jepler_> if you've got 1.25GB/s to work with, efficient won't matter that much for linuxcnc-like uses
[14:47:55] <pcw_mesa> 1.25 Gbps at 20 KM no less
[14:48:39] <jepler_> hm 120us round trip, starting to matter
[17:57:25] <mozmck1> It appears that elbpcom may not enable writes when you tell it to write data.
[18:43:42] <mozmck1> jepler_: elbpcom does not properly enable writes when you send a write command.
[18:45:52] <mozmck1> I modified the make_write_request() function by prepending this to the command: struct.pack("<HHH", (1<<15) | (1<<14) | (6<<10) | (1<<8) | 1, 0x001A, (0x5a<<8) | space)
[18:46:27] <mozmck1> And that works. I'm not sure if all writes need this yet, but writes to eeprom and flash do (what else is there?)
[18:51:02] <mozmck1> Hmm, I guess writing hostmot2 registers does not need that. So the function should be smarter I guess and only do the enable on spaces that need it.
[19:15:48] <pcw_mesa> Only EEPROM/Flash writes are protected
[19:18:03] <pcw_mesa> + unpublished write enable for MAC address etc
[19:36:41] <skunkworks> zlog
[20:05:27] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15robEllenberg commented on issue #68: I have an experimental branch here that will fix this issue, and improve blending performance with G33 motion: ... 02
https://github.com/LinuxCNC/linuxcnc/issues/68#issuecomment-250340744
[20:08:28] <mozmck1> pcw_mesa: yeah, I think I'll have the write function check the space and insert the code to enable writes if the space is eeprom or flash
[20:09:12] <mozmck1> pcw_mesa: looks like that is only space 2 and 3?
[20:09:45] <jepler_> mozmck1: yes it's quite likely I only ever tried it for writes in the hostmot space
[20:11:40] <jepler_> > For some tasks, such as updating FPGA
[20:11:40] <jepler_> bitfiles and setting IP addresses, mesaflash(1) is a more appropriate
[20:11:43] <jepler_> tool.
[20:12:52] <andypugh> Hey, jepler.. Interesting question on the forum about compiling a sim on OSX…
[20:13:10] <jepler> andypugh: yes I saw it since the initial post needed approval
[20:13:14] <jepler> I didn't keep following
[20:13:34] <andypugh> It appears to be getting further than I might have expected
[20:13:50] <andypugh> OSX is a BSD.
[20:13:52] <jepler> yes
[20:14:11] <jepler> this summer we had "trasz" commit a number of things that get us closer to building on freebsd (in master branch)
[20:14:40] <jepler> and freebsd ports actually has the rest of what is needed, some of it was not suitable to put in linuxcnc and some of it I was probably too conservative about at the time..
[20:14:55] <andypugh> If LinuxCNC + OSX + Ethernet hardware worked then we would be the only ones..
[20:16:23] <jepler> mozmck1: if you want strongly to do something about elbpcom --write of IP address not working, my first preference would be to expand the docs to say that this explicitly doesn't work because the write-enable is not sent by --write; and if that still doesn't make you fully happy, to add an extra flag that would send the write-enabling sequence.
[20:16:51] <jepler> mozmck1: senidng the write-enabling sequence unconditionally feels like it would make it easier to put the device in a state that is harder to recover from
[20:17:03] <andypugh> Now, I am not at all sure we can handle, or want, any more market share (and try explaining that to anyone else) but there are folk who would like to run a CNC machine with a Mac. I guess the missing part is any sort of realtime capability at all.
[20:17:16] <andypugh> But, sim would be a start.
[20:18:30] <andypugh> I may be the only developer interesed, I do all my LinuxCNC work sat in front ot a Mac.
[20:18:50] <jepler> we'll move our primary website to
http://increasingly-misnamed.linuxcnc.org/ and start selling licenses at $650 a pop
[20:18:55] <jepler> direct to your paypal, naturally
[20:20:39] <andypugh> Whatever! (quoth he, aiming for maximally annoying answer)
[20:24:57] <andypugh> I am curious now, about how far from do-able, a sim version is in OSX. Because I am not actually a real programmer, I have no real feel for how LinuxCNC kernel modules would work when compiled under OSX. It’s the same CPU, and (I think) the same bridge chips, and a similar, but different OS. I really have no feel for where the mis-matches are.
[20:26:49] <andypugh> Anyway, there is a more relevant question on the mailing list. Threading unthreadable threads.
[20:37:59] <cradek> I'd think a sim version would be not too hard on another bsd, if freebsd already works [but I know nothing about macs]
[20:48:49] <jepler> Charles might come to Wichita?!
[20:51:49] <cradek> cool!
[20:56:04] <andypugh> Yeah, he said he wanted to
[20:56:23] <andypugh> He is keen to push some mixed-encoder stuff to Hostmot2
[20:56:35] <pcw_mesa> write enables only work till the end of the current packet
[20:56:48] <cradek> pcw_mesa: are you coming again this year?
[20:57:16] <pcw_mesa> I'd like to if i can work it in
[20:57:21] <cradek> that would be awesome
[21:00:33] <pcw_mesa> I'd probably have to return Stuarts Cincinnati Millicron PLC backplane to be welcome
[21:00:52] <cradek> heh
[21:01:06] <pcw_mesa> forgotten how many years Ive had it here
[21:01:11] <jepler> is it .. at least 3?
[21:01:28] <jepler> seems like we had wichita, then houston, then a gap, and here we are...
[21:01:41] <pcw_mesa> might be Ill have to look at when I built the interface card
[21:02:01] <cradek> so you accomplished the thing that was the reason you had it?
[21:02:34] <pcw_mesa> I got it to work enough that I could blink the Neon lights on the ACO board but ran out of time
[21:05:26] <andypugh> i suspect that Stuart may no longer be affiliated to the technical owner of the backplane
[21:05:36] <pcw_mesa> I did understand the bus interface well enough to do that at one time (and I think I have a demo program)
[21:05:37] <pcw_mesa> And I wrote some Docs for the IBA that are probably close to right
[21:06:56] <jepler> [security updates] pidgin: mysterious vulnerabilities
[21:07:38] <jepler> I think the summarizing author means that the vulnerabilities are not well explained in the official announcement
[22:00:09] <mozmck1> jepler: I don't have any strong feelings on elbpcom. just started playing with it to try and write an IP address and found that out.
[22:01:36] <mozmck1> I think it would make sense to either send the write enable if you try to write to eeprom or flash, or error with a message saying that writing to eeprom or flash is not supported.
[22:02:39] <mozmck1> Now it outputs the command happily and wags it's tail like it did a good job, but when you read you find out the write failed :-)
[22:18:43] <pcw_home> I think I have done it with elbpcom by including the write enable in the command hex but mesaflash is more appropriate for writing the IP address
[22:19:33] <pcw_home> (I mainly use elbpcom for testing new parser features)
[22:20:50] <jepler> I was motivated to add elbpcom because it might occasionally be useful for troubleshooting (like an easy way that would already be installed to check if the board is talking to linux)
[22:21:27] <jepler> and then it got out of control and sprouted flags that were not in pcw_home's version, like --read and --write to format messages itself...
[22:26:18] <mozmck1> yeah.
[22:27:01] <mozmck1> speaking of the 2.8 release, I feel bad I have not done anything about that yet.
[22:28:09] <jepler> we're here to help^Wall have different, conflicting opinions about what you should do
[22:28:33] <jepler> except not right now, I'm headed for bed
[22:28:46] <mozmck1> Do you think it is time to make a pre-release jepler?
[22:30:10] <jepler> I know there's still some fallout from the task abort change, which was reverted in 2.7 and older but remains in master. there are at least a couple of github issues outstanding about it. That's the main thing I know of that makes me feel the master branch is not stable
[22:30:55] <jepler> I don't right offhand know what we've done in the past, fixing the last major known issues vs making the first release candidate package vs making the git branch
[22:31:00] <mozmck1> Ok. It seemed like several bugs were found and fixed, and I was not sure if anything was outstanding.
[22:32:01] <mozmck1> I look forward to the meeting - looks like I'm going to make this one.
[22:32:10] <jepler> https://github.com/LinuxCNC/linuxcnc/issues/138 is the one I find right off the bat I think
[22:32:13] <jepler> afk and goodnight
[22:32:17] <jepler> are you bringing your musical instrument this time?
[22:32:30] <mozmck1> hmm, I can do that.
[22:32:44] <mozmck1> or two even
[22:32:58] <jepler> I know you and cradek both threatened to the next time..
[22:33:11] <jepler> geez I'm bad at quitting for the night
[22:33:22] <mozmck1> me too. later.