Back
[00:47:45] -sinisalo.freenode.net:#linuxcnc-devel- [freenode-info] why register and identify? your IRC nick is how people know you.
http://freenode.net/faq.shtml#nicksetup
[07:15:32] <jthornton> some time back I wrote a python program that converts a Mach xml to a Stepconf xml. It is point and click easy should I add that to master or 2.7?
[07:20:12] <jthornton> or should I just put it on the wiki?
[07:21:22] <cradek> maybe package it up separately like mesaflash/truetype-tracer/etc?
[07:21:37] <cradek> not sure what's best
[07:21:48] <jthornton> it's a single python file
[07:23:27] <jthornton> maybe post it on the forum in the converstion thread
[07:23:36] <jthornton> that might be the best spot
[07:24:13] <jthornton> conversion thread
[07:25:15] <cradek> the very best would be if stepconf had an import button that would call your script (or whatever). new users won't figure anything else out alone, I bet.
[07:25:31] <jthornton> heh that would be even better
[07:27:36] <jthornton> this is the conversion program
http://pastebin.com/A54955UF
[07:27:57] <jthornton> when you run it a file chooser pops up so you can pick the mach xml file
[07:28:38] <jthornton> I think the only modification would be to just put the .stepconf file in the correct place instead of zipping it up
[07:48:22] <jepler> an absolute *must* before putting it in linuxcnc would be to add a license statement comptible with GPLv2+.
[07:48:32] <jepler> I would also recommend only putting it in linuxcnc if you are actively interested in maintaining the software
[07:48:50] <jepler> are you the author?
[07:49:00] <jepler> ah you did say you wrote it, ok
[09:06:36] <seb_kuzminsky> i think it should go in 2.7
[09:06:40] <seb_kuzminsky> jthornton: welcome back!
[09:06:48] <seb_kuzminsky> what's left to do on docs?
[09:22:26] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 a050a89 06linuxcnc 10tests/halui/mdi/postgui.hal 10tests/halui/mdi/test-ui.py halui/mdi test: wait for halui to ack the mode changes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a050a89
[09:22:26] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 0524207 06linuxcnc 10src/emc/usr_intf/halui.cc halui: better error reporting * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0524207
[09:22:26] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 c2dbf59 06linuxcnc 10src/emc/usr_intf/halui.cc halui: increase receiveTimeout from 1 to 2 seconds * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c2dbf59
[09:22:28] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 6614ce1 06linuxcnc 10tests/halui/mdi/test-ui.py halui/mdi test: increase move timeout from 5 to 10 seconds * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6614ce1
[09:25:17] <seb_kuzminsky> so i think the halui/mdi failures we were seeing occasionally are similar to the problem rick lair has been reporting - non-realtime code is non-realtime
[09:25:38] <seb_kuzminsky> if you get unlucky, and your computer is busy doing other things, then things like halui and task can take a long to to get their things done
[09:25:44] <seb_kuzminsky> (kind of like me)
[09:26:45] <seb_kuzminsky> so those commits add error reporting when something goes wrong in halui (it used to not report errors), and it increases a couple of timeouts to make the buildbot failure more rare (though it wont make them go away entirely)
[09:32:41] <mozmck> What's left to do before 2.7 release now?
[10:01:05] <seb_kuzminsky> mozmck: merge rob's tangent branch, finish whatever's still needed on docs
[10:01:09] <seb_kuzminsky> that's all as far as i know
[10:01:31] <seb_kuzminsky> i pinged rob and asked if he thought his branch was ready
[10:01:52] <mozmck> I thought that was merged already - is that the fix for bug 424?
[10:02:11] <seb_kuzminsky> i tested the second-to-most-recent commit he made (the commit before the current tip) and it fixed the #424 violation
[10:02:23] <seb_kuzminsky> mozmck: yeah, the fix for 424, but no, it's not merged yet
[10:02:23] <mozmck> I see.
[10:02:33] <seb_kuzminsky> rob is still making commits on it (well he made one recently)
[10:03:30] <pcw_home> I think there was still the slow-down issue
[10:04:49] <mozmck> Looks like 2.7 is going to be a great release.
[10:08:12] <mozmck> seb_kuzminsky: is buildbot something I could easily set up on a machine here?
[10:08:52] <mozmck> I have a build machine and I'd like to have it automatically see git commits and pull and build.
[10:10:17] <cradek> our git server actually pokes the buildbot to tell it something new is ready
[10:11:33] <cradek> but my experience is that buildbot is neither easy nor impossible to configure :-/
[10:16:12] <mozmck> ok :)
[10:18:31] <seb_kuzminsky> pcw_home: what's the slow-down issue?
[10:18:43] <seb_kuzminsky> mozmck: you certainly can set up your own buildbot
[10:18:59] <mozmck> Many of our setups have an ohmic sensor and a micro-switch on a sliding head on the Z axis. Right now if the ohmic sensor misses (rusty metal or something), and the switch closes we just do an estop.
[10:19:23] <seb_kuzminsky> i have a pile of virtual machines, one for the buildmaster and one for each buildslave
[10:19:50] <seb_kuzminsky> the git repo post-receive hook pokes the buildbot, but you can also have the buildbot poll the repo (in case you don't have control over the repo's hooks)
[10:19:54] <mozmck> What I would like to do, is on a probe move, if the ohmic senses, then that is used for the probe input.
[10:20:09] <seb_kuzminsky> i'd be happy to send you the buildmaster config if you like
[10:20:32] <mozmck> But if it misses and the switch closes, then use that for the probe input. But if that happens, there needs to be a switch offset applied.
[10:21:16] <seb_kuzminsky> mozmck: seems like you could easily do "(ohmic OR micro) -> probe_input", but i'm not sure how to apply an offset to the probed value
[10:21:18] <mozmck> seb_kuzminsky: yes, please!
[10:21:44] <seb_kuzminsky> maybe remap g38 and have it check which of the sensors tripped, and apply an offset if it's the micro
[10:21:52] <seb_kuzminsky> (after you fix all the remapping bugs, of course)
[10:22:08] <mozmck> hah! :)
[10:23:00] <mozmck> I was thinking of a realtime component that would be like the OR component, but could set a variable to show which input tripped.
[10:23:24] <mozmck> Then in my o-word I could check that variable and apply the offset or not.
[10:24:08] <mozmck> But maybe remapping g38 could be better (if it's not too buggy)?
[10:27:20] <mozmck> I see that my fix to hal_gremlin makes gmoccapy and gaxis work like Axis - probably a good thing.
[10:28:01] <cradek> yay!
[10:28:04] <pcw_home> seb_kuzminsky: I think Samco reported that the branch that fixed 424 ran noticeably slower on some gcode
[10:29:24] <seb_kuzminsky> mozmck: buildbot config sent
[10:29:27] <seb_kuzminsky> pcw_home: ah, thanks
[10:29:29] <mozmck> thanks.
[10:30:05] <mozmck> seb_kuzminsky: could my machine be set up as a slave for your master?
[10:30:20] <seb_kuzminsky> yes, that is possible
[10:31:32] <seb_kuzminsky> for a while in the early days i was actively trying to get people to run buildslaves, paul corner ran one for a while and jeff epler ran one, but it turns out to be more convenient to administer th ewhole build cluster as one unit, and it makes it safer to hide the thing behind a firewall, so i stopped using outside buildslaves
[10:32:09] <mozmck> Ah, ok.
[10:32:24] <seb_kuzminsky> if there's a compelling reason to switch back i'm all ears
[10:33:04] <mozmck> I have a couple of dual xeon computers here I got pretty cheap. 16 logical cores each. I use one for building linuxcnc and that's about all.
[10:33:18] <seb_kuzminsky> ah, i see, spare resources
[10:33:38] <seb_kuzminsky> i recently upgraded the buildbot hardware and i have cycles to spare now
[10:33:49] <seb_kuzminsky> if you'd asked me 6 months ago i might have seen that as a compelling reason ;-)
[10:34:18] <mozmck> Auctions are great :) these are industrial rack mount siemens computers for around $60
[10:34:29] <mozmck> ok.
[10:35:00] <seb_kuzminsky> that's a good deal! do they have enough ram to keep the CPUs fed?
[10:37:09] <mozmck> 12 gig iirc
[10:38:00] <seb_kuzminsky> what about for the other 15 cores?
[10:38:03] <seb_kuzminsky> j/k...
[10:38:57] <pcw_home> I think the latest Xeons have like 18 cores...
[10:39:00] <mozmck> The cpus are E5520, but I can put faster ones in if I want. There are some with 12 logical cores each at 3.x Ghz, which would give me 24 cores.
[10:39:20] <mozmck> Yes, these are a couple years old.
[10:40:12] <mozmck> Interestingly, my desktop AMD machine with an FX8350 8-core cpu and 20G mem builds linuxcnc packages and kernel packages slightly faster.
[10:49:57] <pcw_home> the 5520 is 4 core and a slower clock so that seems likely
[10:53:34] <mozmck> yes, they say 8 logical cores, but I don't know if that really helps much.
[11:44:39] <kwallace> I have a dual Xeon server here. I have been wondering what to do with it. The latency is not very good, so it's not good for LinuxCNC, but using it for compiling sounds interesting. It has redundant everything, scsi drives, boot controller, and a pile of noisy fans. It's not my favorite machine.
[11:49:12] <JT-Shop> is there a document that has the license information you need to put in new code?
[11:50:47] <cradek> the full instructions are here:
https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#CouldYouHelpApplyGPL
[11:51:45] <cradek> if you don't have strong feelings, use the variation that says version 2 or any later version
[11:51:46] <JT-Shop> thanks
[11:53:10] <JT-Shop> I just got an email from Chris and he is going to look at adding my conversion program to stepconf so I need to get the program licensed and ready for him
[11:54:26] <cradek> that's awesome
[11:54:49] <cradek> an import function in stepconf would really be the best way for users
[11:54:52] <mozmck> kwallace: it would be nice if I could figure out how to boot it over the network. then I could leave it in the closet and just fire it up remotely when I want it.
[11:55:04] <JT-Shop> yes I think that is the best way too
[12:04:30] <seb_kuzminsky> yay
[12:05:03] <seb_kuzminsky> pcw_home: you're right. rob confirms the slowdown and says he'll address it this weekend
[12:11:12] <pcw_home> I only know what I read on IRC
[12:15:58] <skunkworks> zlog
[12:16:23] <micges> pcw_home: what latest webpack is needed to build hostmot2 sources?
[12:18:09] <Tom_itx> 14.7 is the last one
[12:18:22] <Tom_itx> i'm using it
[12:19:08] <pcw_home> for SP 6 I have been using 14.3 and thats right 14.7 is the last ISE version
[12:19:36] <micges> thanks
[12:20:18] <pcw_home> vivado would probably work but I have not bothered messing with it yet
[12:21:25] <Tom_itx> me either
[12:24:26] <micges> seems it will be needed for new chips
[12:24:55] <Tom_itx> yup
[12:42:55] <pcw_home> Hmm looks like Vivado is for 7 series chips only
[13:03:02] <ssi> yeah you need ISE for s3 or s6 parts
[13:03:18] <ssi> it's pretty stupid the way they do it
[13:04:18] <pcw_home> yeah and I think 10 or < for Spartan2
[13:14:04] <CaptHindsight> Vivado covers all the ZYNQ, only place I've used it
[13:14:21] <CaptHindsight> says Ultrascale, Virtex-7, Kintex-7, Artix-7, and Zynq -7000
[13:15:28] <CaptHindsight> I think mine might be tied to the ZYNQ/Zedboard
[13:41:03] <jepler> seb_kuzminsky: do you want to put the multiple hostmot2 ethernet card support in 2.7? it would really benefit from your review, and it does touch some core hostmot2 code
[13:42:06] <seb_kuzminsky> ah, i owe you a review
[13:42:12] <seb_kuzminsky> i'll look at it tonight, promise
[13:42:48] <seb_kuzminsky> jepler/hm2-eth-multiple, right?
[13:42:55] <jepler> seb_kuzminsky: right.
[13:43:03] <seb_kuzminsky> got it
[13:43:53] <jepler> seb_kuzminsky: I particularly want your opinions about the way I implemented the new "read-request" function
[13:44:34] <jepler> if there's something wrong in hm2_eth itself we'll just bugfix it, but we'll be stuck with a new HAL function for at least a whole release even if it turns out not to be the best idea
[13:46:17] <seb_kuzminsky> aight
[13:48:54] <jepler> I did do a quick test with pci cards and they still seem to work; the read-request function is not exported
[13:50:39] <seb_kuzminsky> i'll try it with my 5i22
[13:50:58] <seb_kuzminsky> and i think i have a 5i23 in the machine that runs my not-yet-working 3d printer
[13:51:13] <jepler> i was briefly very confused because it was all broken, but it turns out that I added a 6i24 since the last time I ran that particular halfile
[13:51:34] <jepler> so the 5i20 didn't get a bitfile at all and so loadrt hm2_pci failed
[13:52:01] <jepler> .. with multiple PCI cards, is there a defined order that they're probed in, or is it down to luck?
[13:52:03] <seb_kuzminsky> i like it when it's simple dumb stuff that causes breakage
[13:52:44] <jepler> it seems to be consistent on my system, in 3 runs back to back
[13:52:48] <seb_kuzminsky> it seems to be the same order every time, but i don't know if that's an accident or a promise
[13:53:54] <seb_kuzminsky> bbl lunch
[14:07:49] <PCW> "a promise is neither a fact nor a lie"
[14:09:25] <PCW> AFAIK its BIOs enumeration order so its will always be the same but not predictable on different machines
[14:12:42] <PCW> A better scheme might be to have a serial number in each card and have the driver assign them in ascending serial number order or some such
[14:12:43] <PCW> but the number of systems with 2 or more FPGA cards is pretty small so not sure its worth the effort
[14:14:27] <seb_kuzminsky> i think cradek has two pci fpga boards in Jr
[14:14:44] <jepler> in uspace, it's whatever order udev_enumerate works in
[14:16:24] <jepler> the documentation obliquely refers to this being in a "sorted" order, whatever that is
[14:17:08] <skunkworks> k&t has 2 cards. Never an issue with it initalizing them out of orfer
[14:17:09] <skunkworks> order
[14:17:30] <PCW> unless you swap slots
[14:21:00] <PCW> sserial cards have an optional naming scheme that allows swapping ports without trouble : 7i84.abcd.in-00
[14:21:01] <PCW> where abcd is the card unit number, but I dont think anyone has ever used it
[15:08:43] <cradek> yes I have two 5i20s in jr
[15:08:58] <cradek> using 4 plugs altogether, I think
[16:07:09] <skunkworks> zlog
[16:07:32] <skunkworks> I am using all 6
[16:12:32] <jepler> I think there's probably a good chance that uspace and rtai each enumerate in consistent orders, but different from each other
[16:13:12] <jepler> it's very likely nobody has converted a RTAI-based system with two PCI(e) cards to a uspace system
[16:13:20] <jepler> maybe with the exception of peter
[19:23:53] <PCW> More that 1 PCI card doesn't make much sense anymore with serial expansion
[19:23:55] <PCW> but more than one Ethernet card might be practical on a large machine
[19:23:57] <PCW> where I/O is more distributed
[20:26:02] <jepler> how does ethernet actually fare in an enclosure full of drives for multi-kW motors and whatnot?
[20:26:21] <jepler> better than untwisted pairs of the I/O rack ribbon cables I suppose
[22:31:52] <pcw_home> Ethernet works fairly well in electrically noisy environments because it has
[22:31:54] <pcw_home> very good common mode rejection
[22:38:55] <pcw_home> It would be better if random dropped packets were tolerable (which requires good timeout accuracy)
[22:38:57] <pcw_home> A flag from the driver that indicates invalid RXData in the current cycle or failure to write data in the previous cycle
[22:38:58] <pcw_home> would also be desirable to allow better error tolerance, For example say to tell the PID loop to skip updates if the
[22:39:00] <pcw_home> read data is invalid
[23:07:04] <seb_kuzminsky> http://journaltimes.com/news/local/drowning-victim-a-beloved-business-leader/article_d4672b60-d816-5623-88a5-7d562d240c2b.html
[23:26:29] <pcw_home> :-(