Back
[00:05:47] -!- Camaban has quit [Quit: Leaving]
[00:13:39] -!- ganzuul has quit [Ping timeout: 250 seconds]
[00:23:38] -!- Tom_L [Tom_L!~Tom@ip68-102-196-57.ks.ok.cox.net] has joined #linuxcnc-devel
[00:23:38] -!- Tom_L has quit [Changing host]
[00:23:38] -!- Tom_L [Tom_L!~Tom@unaffiliated/toml/x-013812] has joined #linuxcnc-devel
[00:33:29] -!- choonway has quit [Quit: Leaving]
[00:49:41] -!- Tecan has quit [Changing host]
[01:14:07] -!- Loetmichel2 has quit [Ping timeout: 246 seconds]
[01:20:36] -!- tocka has quit []
[01:31:00] -!- Tom_L has quit [Quit: Quit]
[01:38:31] -!- rob_h has quit [Ping timeout: 256 seconds]
[01:43:52] -!- Audioburn has quit [Ping timeout: 246 seconds]
[02:00:09] <jepler> http://hackaday.com/2015/10/18/fpgas-for-the-raspberry-pi/ -- "hat" with Lattice iCE-HX8K and open source toolchain based on reverse engineering of the FPGA's bitstream
[02:06:50] -!- skunksleep has quit [Ping timeout: 272 seconds]
[02:07:32] -!- tinkerer has quit [Remote host closed the connection]
[02:08:52] <jepler> somebody ported xenomai to that 64-bit arm board I have.
https://www.96boards.org/forums/topic/announcement-xenomai-on-410c/
[02:09:34] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[02:12:22] <andypugh> It’s been several days, where is the LinuxCNC port?
[02:13:02] <andypugh> (More seriously, that probably makes the Machinekit guys happy)
[02:13:15] <jepler> possibly. 64 bit machines don't really have much going for them when it comes to cnc
[02:13:38] <jepler> though 64-bit ARMs stand a slightly higher chance of not garbling doubles between threads like the 32-bit ARMs do
[02:14:23] <andypugh> We do use 64-bit types in several important places, but only to make sure we don’t roll over this millenium
[02:14:24] -!- tannewt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
[02:14:33] <jepler> sure
[02:14:42] <jepler> you could do that on an 8-bit CPU depending on the performance requirements
[02:14:52] <andypugh> Otherwise, yes, it could all be 16 bit really.
[02:15:24] <andypugh> I lost time chaning from 8bit to 16 bit, and you won :-)
[02:16:35] <andypugh> Is there any fundamental reason that an 8-bit CPU can’t have a 64-bit memory bus?
[02:17:13] <andypugh> I have worked with Z80 and paged memory, but that was a kludge
[02:17:20] <jepler> it's probably just a bad idea, not impossible
[02:18:23] <skunksleep> jepler: did the zenbot move?
[02:18:34] <jepler> most 8-bit CPUs have 16-bit addressing with an 8-bit data bus, right?
[02:19:14] <andypugh> I do recall that on the z80 there was an interupt routine that could be set to call the code at a specific memory location. But on the Sinclair machines that turned out to take the MSB from a register and the LSB from the address bus. So you could choose your 256byte block to be called, but not where in the block
[02:20:05] <andypugh> Now, you might think that was a show-stopper. And when I read the docs, that was my assumption
[02:20:39] <jepler> you just need to waste a whole page with a NOP slide, right?
[02:21:04] <andypugh> But someone with more determination than me noticed that FF was a jump. And FFFFFF was jump to FFFF…
[02:21:32] <andypugh> NOP slide might have worked too, now you mention it.
[02:21:35] <jepler> ah that's better than taking a variable amount of time to reach the real isr
[02:22:44] <andypugh> I can’t recall what you had to put at FFFF, it could clearly only be a single byte
[02:23:25] <andypugh> Maybe it was FEFE? It’s been a few decades
[02:24:19] -!- skunksleep has quit [Ping timeout: 268 seconds]
[02:25:19] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[02:25:28] <andypugh> Anyway, there is nothing to be gained from reminscing about the old days when I could completely understand a computer.
[02:25:46] <andypugh> And a lot more to be gained from some sleeping.
[02:25:57] <andypugh> Night all
[02:26:02] -!- andypugh has quit [Quit: andypugh]
[02:27:44] <jepler> night
[02:29:07] -!- Akex_ has quit [Quit: Connection closed for inactivity]
[02:33:07] <jepler> you geek trapped me but I failed to chase down the details :-/
[02:33:11] <jepler> time to call it a night here too
[02:34:03] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[02:35:28] <KGB-linuxcnc> 03Dewey Garrett 05master 9511573 06linuxcnc 10scripts/sim_pin sim_pin: make ivalue name consistent * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9511573
[02:35:29] <KGB-linuxcnc> 03Dewey Garrett 05master bf578d3 06linuxcnc 10docs/man/man1/sim_pin.1 10docs/src/hal/tools.txt 10scripts/sim_pin sim_pin: support cmdline mode for bit items * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bf578d3
[02:42:38] -!- _nexxus_ has quit [Quit: Leaving.]
[02:46:26] -!- MacGalempsy has quit [Read error: Connection reset by peer]
[02:47:34] -!- tannewt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
[02:59:49] -!- sumpfralle1 has quit [Ping timeout: 246 seconds]
[03:04:47] -!- il has quit [Quit: github.com/audioburn]
[03:08:09] <seb_kuzminsky> i tested out g81 in 2.7 by drilling the 14(!) mounting holes for a 7i43 + 7i54 in the scrounged enclosure for the robot arm, all worked as expected
[03:08:19] <seb_kuzminsky> though the tests are more thorough than i
[03:18:00] <Tom_itx> did it work as advertised?
[03:19:00] <Tom_itx> err no.. it was the G84 i was wondering about a while back
[03:21:29] <Tom_itx> yeah G81 works fine here
[03:27:04] <Tom_itx> as does G83
[03:31:10] -!- bilboquet has quit [Quit: Quitte]
[03:33:05] -!- AR_ has quit [Ping timeout: 252 seconds]
[03:39:28] -!- amiri has quit [Read error: Connection reset by peer]
[04:00:58] -!- PetefromTn_ has quit [Quit: I'm Outta here!!]
[04:06:22] -!- skunksleep has quit [Ping timeout: 260 seconds]
[04:07:01] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[04:40:56] -!- FinboySlick has quit [Quit: Leaving.]
[05:02:30] -!- Tecan has quit [Ping timeout: 255 seconds]
[05:09:50] -!- anomynous_ has quit [Ping timeout: 244 seconds]
[05:33:18] -!- Contract_Pilot has quit [Ping timeout: 260 seconds]
[05:46:36] -!- kwallace [kwallace!~kwallace@142.147.85.210] has parted #linuxcnc-devel
[05:51:29] -!- jerryitt has quit [Quit: Connection closed for inactivity]
[06:30:32] -!- Komzpa has quit [Remote host closed the connection]
[06:43:24] -!- jthornton has quit [Read error: Connection reset by peer]
[06:43:46] -!- jthornton [jthornton!~john@172.242.222.19] has joined #linuxcnc-devel
[07:44:32] -!- bkboggy has quit [Quit: Leaving]
[07:49:10] -!- ink has quit [Remote host closed the connection]
[07:57:45] -!- tannewt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
[07:58:29] -!- tannewt has quit [Client Quit]
[08:15:22] -!- ve7it has quit [Remote host closed the connection]
[08:24:42] -!- alex_jon1 has quit [Remote host closed the connection]
[08:36:28] -!- rob_h [rob_h!~robh@94.10.122.197] has joined #linuxcnc-devel
[09:17:10] -!- b_b has quit [Changing host]
[10:22:06] -!- skunkworks has quit [Ping timeout: 240 seconds]
[10:54:40] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[11:20:42] -!- rkj has quit [Quit: Leaving]
[11:29:49] <skunkworks> interesting..
http://www.cnczone.com/forums/linuxcnc-formerly-emc2-/285606-cnc-tormach.html
[11:30:19] <skunkworks> sounds like the gui stops but the machine keeps on running?
[11:32:26] <skunkworks> the computer hardware seems decent..
[11:32:56] <archivist> I have had the gui slow to a crawl on my 5 axis, does also mean it fails to see key presses for a while
[11:33:59] -!- tinkerer [tinkerer!~tinkerer@mail.play-pla.net] has joined #linuxcnc-devel
[11:34:31] <archivist> ask him if he has enough ram to avoid swapping
[11:39:11] -!- chris_99 has quit [Quit: Leaving]
[11:42:30] <micges> looks like memory leak
[11:58:26] <jthornton> a guy wanted me to make a configuration change to his Path Pilot until I found out it takes over your computer competently when installed
[11:59:00] <jthornton> seems to be very heavily modified and nothing like what we know
[12:15:18] -!- jthornton has quit [Read error: Connection reset by peer]
[12:22:33] -!- jthornton [jthornton!~john@172.242.222.19] has joined #linuxcnc-devel
[12:33:53] -!- jthornton has quit [Remote host closed the connection]
[12:48:27] -!- chris_99 has quit [Quit: Leaving]
[12:53:37] -!- Valen has quit [Remote host closed the connection]
[12:56:38] -!- md-2 has quit [Remote host closed the connection]
[13:11:18] <jepler> makes it hard to offer good advice about it even if you wanted to
[13:58:12] <mozmck> Interesting, I ran across this while looking up php vs other web languages:
http://blog.websecurify.com/2014/08/hacking-nodejs-and-mongodb.html
[14:01:46] <jepler> the state of security is pretty depressing. two systems developed years after we knew about SQL injection in CGI scripts have exactly the same class of bug
[14:04:04] <mozmck> apparently the newer technologies are not really any better even though a lot of people apparently think so.
[14:04:07] <archivist> it is the idiots thinking $laguage/library/prepared statements will wipe their butt and provide security, wrong, check incoming data is in range and does not contain something you dont expect
[14:08:52] -!- SEL_ [SEL_!~SEL@net77-43-27-64.mclink.it] has joined #linuxcnc-devel
[14:09:27] -!- SEL_ has quit [Client Quit]
[14:11:00] <ssi> mozmck: I have some opinions about that class of technology :P
[14:11:14] <mozmck> nodejs and mongo?
[14:11:16] <ssi> yeah
[14:11:25] <mozmck> I know nothing about it really.
[14:11:31] <ssi> that world has come about because web developers want to be backend developers now,
[14:11:50] <ssi> and companies would rather pay web developers to be "full stack" than pay honest to god backend developers, who are 3x more expensive
[14:12:00] <mozmck> ah, I see.
[14:12:45] <mozmck> maybe that's because web "developers" at least historically were basically document editors :)
[14:12:48] <ssi> so you have a generation of kids who have never touched a language like C or C++, and never properly learned relational databases
[14:12:53] <archivist> also they are shoving processing onto the clients to waste your battery and not their power costs
[14:13:15] <ssi> and they're trying to solve all the problems that they think are brand new, and things like nosql and nodejs are the result
[14:13:21] <mozmck> relational - isn't that old?!? old is bad....
[14:13:24] <ssi> yep
[14:13:41] <archivist> relational still works!....best
[14:14:14] <ssi> there are use cases where nosql makes a lot of sense
[14:14:20] <ssi> but you can't shoehorn every problem into one or the other
[14:14:46] -!- vapula has quit [Ping timeout: 240 seconds]
[14:16:12] <mozmck> We often drastically underestimate the intelligence of those who came before us - probably because we don't fully understand the scope of the problem or their solution.
[14:16:48] <ssi> indeed
[14:17:00] <archivist> the stupidity of a 900k js page on google images to show an 90k jpg
[14:17:15] <mozmck> ouch!
[14:17:45] <archivist> and I get a white screen at that with a few bits on
[14:17:53] <jepler> it seems to be the nature of computer systems that we effortlessly use up 99% of all performance increases without improving anything
[14:18:28] <mozmck> That's the kind of reason I use fltk for small utilities. Pickit2 is a tiny utility that required a 60+Mbyte .net download to install and run.
[14:18:58] -!- sumpfralle has quit [Ping timeout: 272 seconds]
[14:19:23] <mozmck> fltk statically linked adds ~400kbytes to the executable - and it's fast and cross platform
[14:20:31] <jepler> if everyone just agreed on which 60MB runtime all the software would use, it wouldn't matter
[14:21:01] <mozmck> hah! seems like every time I needed a .net program, it required a different .net than I had.
[14:21:25] <archivist> I think boost is as bad as .net for that
[14:21:53] -!- dimas has quit [Read error: Connection reset by peer]
[14:22:08] <jepler> oh don't get me started about C++
[14:22:08] <mozmck> that may be, and seems like boost is pretty buggy too
[14:22:36] <jepler> mozmck: which compilers are you using boost with?
[14:23:03] <jepler> at $DAY_JOB we use it with gcc (4.6) and while it makes the compiler dog slow, we rarely encounter runtime bugs that we trace back to boost
[14:23:10] <mozmck> :) I like c++ - some of the c++11 features do make things nicer.
[14:23:45] <ssi> I never really got deep into c++, never liked it much
[14:23:49] <archivist> jepler, but do they break the api regularly
[14:23:54] <ssi> did a lot of C, lot of Java, some objc, and mostly golang these days
[14:24:08] <mozmck> jepler: I've not personally run into boost problems, but the kicad project has had to maintain several boost patches for bugs.
[14:24:55] <mozmck> I think some of them have been fixed in the latest boost, but iirc it took quite a while to get them fixed.
[14:25:31] -!- dimas has quit [Read error: Connection reset by peer]
[14:28:05] -!- Roguish [Roguish!~chatzilla@c-50-143-183-159.hsd1.ca.comcast.net] has joined #linuxcnc-devel
[14:34:27] -!- dimas has quit [Ping timeout: 255 seconds]
[14:56:34] -!- KimK_laptop has quit [Ping timeout: 260 seconds]
[15:07:02] <pcw_home> jthornton: when people ask me PathPilot config questions I just try and steer them to LinuxCNC
[15:07:04] <pcw_home> I dont mind making our hardware work with PathPilot on non Tormach equipment but thats about
[15:07:05] <pcw_home> as far as I feel like going
[15:09:46] -!- KimK_laptop [KimK_laptop!~Kim@wsip-70-186-238-216.ks.ks.cox.net] has joined #linuxcnc-devel
[15:09:55] -!- Demiurge has quit [Quit: Demiurge]
[15:21:05] -!- md-2 has quit [Remote host closed the connection]
[15:25:24] <skunkworks> I installed the probing screen from the forum this weekend. that is as far as I got - looks cool.
[15:25:39] <skunkworks> That and features and I think I have everything I would want.
[15:26:11] <skunkworks> (I haven't tried features yet..)
[15:27:42] -!- kwallace [kwallace!~kwallace@142.147.85.210] has joined #linuxcnc-devel
[15:31:43] -!- dimas has quit [Read error: Connection reset by peer]
[15:32:03] -!- Simonious has quit [Remote host closed the connection]
[15:36:06] -!- Tecan has quit [Ping timeout: 255 seconds]
[15:36:57] -!- persina has quit [Ping timeout: 246 seconds]
[15:48:15] -!- KimK_laptop has quit [Ping timeout: 252 seconds]
[16:01:06] -!- KimK_laptop [KimK_laptop!~Kim@wsip-70-186-238-216.ks.ks.cox.net] has joined #linuxcnc-devel
[16:15:53] <seb_kuzminsky> skunkworks: you got farther than me
[16:17:33] <seb_kuzminsky> i feel like we have a policy decision to make - should we aim to absorb other projects like Features and build/test/package/distribute them along with LinuxCNC, or should we encourage those other projects to build/test/package/distribute them by themselves? (or should we do something else that i haven't thought of?)
[16:18:23] <seb_kuzminsky> i lean towards the "absorb them and make them part of linuxcnc" side, because it lowers the activation energy of getting them into the hands of users
[16:19:16] <jepler> let me start off by saying something that I hope is obvious: we shouldn't absorb what doesn't want to be absorbed
[16:19:35] <seb_kuzminsky> yes
[16:20:07] <seb_kuzminsky> and we should be wary of absorbing code that doesn't come with a maintainer who wants to join our project
[16:21:53] <jepler> the code needs to be high quality, it needs to be properly licensed, it EITHER needs to build on all platforms we support OR degrade gracefully (such as by not building/installing at all) when a dependency isn't met
[16:22:12] <jepler> I also really don't want building linucnc to pull in every GUI toolkit, which is what happens after you absorb one project using each toolkit
[16:22:58] <jepler> and the maintainers need to be content with our release cycle and our generally high requirements for forward compatibility
[16:23:45] <jepler> and even more than now (cough, tklinuxcnc and mini) about what happens when these absorbed projects don't keep pace with the rest of linuxcnc
[16:25:26] -!- patrickarlt has quit [Remote host closed the connection]
[16:26:16] <jepler> ... personally, I wish that the thing we could do was facilitate putting debs of these other projects on wlo
[16:26:52] <jepler> oh yeah I didn't mention that debian packaging is mandatory in the pull request to absorb the other project
[16:27:11] <seb_kuzminsky> and documentation
[16:27:53] <seb_kuzminsky> i agree that facilitating separate projects building separated debs would be awesome, but i dont want to be a launchpad/ppa
[16:28:16] <jepler> I know
[16:28:23] <seb_kuzminsky> i feel like a can barely keep up with building/testing/packaging/distributing *one* project
[16:28:51] <jepler> am I setting a needlessly high bar for contributions? the perfect being the enemy of the good and all
[16:29:07] <seb_kuzminsky> your point about toolkits is good
[16:29:57] <seb_kuzminsky> maybe along with "we'd like to absorb your code" we should have some kind of schedule of deprecating and removing unmaintained code (tklinuxcnc, mini, etc?)
[16:31:53] <jepler> we have never removed anything as big as a whole UI before to my recollection
[16:32:22] <seb_kuzminsky> aachooo*redis*ooo
[16:32:30] -!- patricka_ has quit [Remote host closed the connection]
[16:32:52] -!- quiqua has quit [Quit: quiqua]
[16:33:02] <jepler> that was never a part of a stable release though
[16:33:10] <jepler> was it?
[16:33:14] <seb_kuzminsky> no it wasnt
[16:33:28] <seb_kuzminsky> you removed that usrmotintf program, that's the only 'git rm' of consequence i remember
[16:33:33] <seb_kuzminsky> for some definition of consequence
[16:33:47] <jepler> in my mind: if no maintainer steps forward, then deprecate in one major release and remove in the next
[16:34:06] <seb_kuzminsky> sounds about right
[16:34:34] <jepler> where "major" means 2.x -> 2.(x+1)
[16:34:42] <jepler> which is a funny definition of major
[16:34:47] <jepler> we should just call the next one "linuxcnc 8"
[16:34:48] <seb_kuzminsky> if enough users say they use a UI without a maintainer, i can imagine taking on maintainership of it
[16:34:53] <jepler> sure
[16:35:09] <seb_kuzminsky> jepler: i agree about dropping one set of digits frmo the release number
[16:35:36] <seb_kuzminsky> i proposed that mozmck call his stable release "3", but i'm fine with "8" too
[16:35:59] <seb_kuzminsky> actually i dont care what the number is, as long as it's "X" instead of "Y.Z", and X is clearly larger than 2.7
[16:36:29] <jepler> well we've got to get ahead of m-ch in version number </troll>
[16:36:58] <seb_kuzminsky> because numbers are more important than features & stability?
[16:37:10] <skunkworks> heh
[16:37:36] <jepler> because numbers are easier to give a total ordering to than "features & stability"
[16:37:40] <seb_kuzminsky> yeah
[16:38:21] -!- Daerist has quit [Quit: Leaving]
[16:38:39] <mozmck> does mk even do version numbering anymore?
[16:38:45] <seb_kuzminsky> i dont care
[16:38:47] <jepler> aaannnyyywwaaaayyyy if the developer(s) of features (or any other linuxcnc-adjacent project) think it would serve everyone better to get it into linuxcnc.git then I think we should have that discussion with them.
[16:39:22] <seb_kuzminsky> we talked about it on emc-developers back on September 14
[16:39:35] <seb_kuzminsky> i immediately derailed the conversation by complaining about the name :-(
[16:39:39] <seb_kuzminsky> bad seb
[16:39:59] <mozmck> I think it would be very nice to have a central location of some sort for all linuxcnc related projects, but would that mean they have to be in the same git repo?
[16:40:07] <jepler> it's easy to be snarky and negative, just look at me
[16:40:55] <skunkworks> maybe it is just me - but jepler has mellowed over the years..
[16:40:58] <jepler> (as the release manager for the next linuxcnc major version, it occurs to me that mozmck has an outsized stake in this issue)
[16:40:59] <mozmck> Maybe a separate deb for "features" and it could be in the apt repo, and also linked on the website?
[16:41:27] <jepler> mozmck: yes I was sort of suggesting that; seb rightly said that it creates more work for whoever maintains the apt repo (and also buildbot)
[16:41:37] <seb_kuzminsky> well lets be careful here
[16:41:45] <seb_kuzminsky> separate deb != separate git
[16:41:57] <mozmck> that's true too
[16:42:15] <jepler> one git = one source package
[16:42:16] <seb_kuzminsky> features could live in our git repo and build along with our code into a separate deb, like we currently do with docs
[16:42:21] <seb_kuzminsky> jepler: right
[16:42:24] <mozmck> Perhaps things like features would not need to be built on the buildbot though.
[16:42:57] <skunkworks> has anyone looked at it? (what it is using, build dependencies and such..)
[16:43:05] <jepler> one source package = one set of build dependencies, and back to the tookit issue (which I don't know if it exists with features) that impacts all users who use the mk-build-deps way of preparing to build RIP builds of linuxcnc
[16:43:33] <seb_kuzminsky> skunkworks: speaking sense, as always
[16:43:45] <seb_kuzminsky> i sure havent cloned their git repo and looked at it
[16:43:53] <seb_kuzminsky> i think it runs inside gladevcp?
[16:44:01] <skunkworks> maybe it would 'just work' ;)
[16:44:09] <seb_kuzminsky> https://github.com/cnc-club/linuxcnc-features
[16:44:49] <seb_kuzminsky> is that the one?
[16:44:59] <seb_kuzminsky> that was the git repo that was mentioned in our email thread
[16:45:08] <jepler> > sudo gedit /usr/share/pyshared/gladevcp/hal_pythonplugin.py
[16:45:23] <jepler> ow ow ow
[16:46:08] <seb_kuzminsky> that's solved by merging it into linuxcnc.git
[16:46:10] <jepler> I don't know the answer, but I hope there's a better way to accomplish whatever adding that import is accomplishing
[16:47:16] <seb_kuzminsky> i would greatly prefer if the Features developer did the job of merging it with linuxcnc in some sane way and offered us a pull request to discuss
[16:47:39] <seb_kuzminsky> rather than offering a stand-alone repo (with "sudo edit this installed linuxcnc file") and us doing the merge/cleanup
[16:47:55] <jepler> yes
[16:48:38] <jepler> and it's easy to see why, without a policy about this sort of thing, no one would spend the time preparing that pull request
[16:48:47] <seb_kuzminsky> yeah
[16:48:57] <jepler> you'd go to all that effort and then .. ???
[16:49:46] -!- patrickarlt has quit [Ping timeout: 250 seconds]
[16:50:47] <seb_kuzminsky> i will email nick and tell him that if he makes a clean PR and offers to maintain it in our git repo, we'll merge it for the next stable release
[16:51:00] <seb_kuzminsky> does anyone mind? mozmck?
[16:52:21] <jepler> - deb packaging - autoconf checks (for lxml?) - documentation - tests ? - license compatibility - promise to maintain
[16:52:35] <seb_kuzminsky> i wonder what our "Contributing to LinuxCNC" document has to say about this kind of thing
[16:52:59] <jepler> oh ugh, they will be unable to actually merge their git repository's history with ours due to the SOB requirement
[16:53:07] <seb_kuzminsky> tests might be hard (i dont know how to test guis, but maybe there's underlying code that can be tested stand-alone)
[16:53:22] <jepler> they would have to either squash their history or rewrite it all to introduce SOB
[16:53:24] <seb_kuzminsky> jepler: are you sure? i merged the non-SoB huanyang vfd driver
[16:53:51] <jepler> IIRC we check the author-date of a commit and if it's older than a threshold we don't require SOB
[16:54:08] -!- msantana has quit [Ping timeout: 272 seconds]
[16:54:16] <jepler> so that might be how it worked in that case, but features has recent commits
[16:54:37] <seb_kuzminsky> July 2015 is the most recent one, hrm
[16:54:53] <jepler> I don't know how important their history is to them
[16:55:06] <mozmck> sorry, had to step out, reading back now.
[16:57:00] <seb_kuzminsky> haha, the cnc-club github avatar is a stick figure leaning back drinking a beer while a cnc mill makes a part
[16:57:40] -!- msantana [msantana!~darkstar@unaffiliated/darkstar] has joined #linuxcnc-devel
[16:57:46] <mozmck> seems like there was a different repo from fernv...
[16:58:04] <jepler> afk, in search of lunch..
[16:58:23] <seb_kuzminsky> https://github.com/FernV/linuxcnc-features
[16:58:29] <seb_kuzminsky> This branch is 31 commits ahead, 9 commits behind cnc-club:master
[16:58:46] <seb_kuzminsky> mozmck: good point, that'll have to be figured out first
[16:59:39] -!- tocka has quit [Ping timeout: 240 seconds]
[17:01:43] <mozmck> This fernv seems to be making releases:
http://www.linuxcnc.org/index.php/english/forum/40-subroutines-and-ngcgui/26578-linuxcnc-features-a-kind-of-ngcgui?start=260
[17:02:22] -!- patrickarlt has quit [Remote host closed the connection]
[17:02:44] -!- Tecan has quit [Changing host]
[17:03:40] <seb_kuzminsky> but nick drobchenko is the one that replied on emc-developers
[17:04:09] <seb_kuzminsky> (grr, github search for "linuxcnc-features" does not find FernV's fork)
[17:04:12] <mozmck> yes, so I don't know which one is "official", or what. I think nick started the thing.
[17:04:21] <mozmck> github search :)
[17:04:38] <jepler> on another note, this is interesting --
https://blog.mister-muffin.de/2015/10/25/unshare-without-superuser-privileges/
[17:05:10] <jepler> it looks like by unsharing net and ipc namespaces it might be possible to make runtests go in parallel
[17:06:23] -!- patrickarlt has quit [Remote host closed the connection]
[17:07:26] -!- patrickarlt has quit [Remote host closed the connection]
[17:09:51] <jepler> I think mah had actually achieved something similar to this
[17:10:03] <seb_kuzminsky> bbl
[17:24:31] <CaptHindsight> I've been thinking about some mods to sync motion to SVG files to sync video/images to motion
[17:24:46] <CaptHindsight> yikes let me restate that
[17:25:33] <mozmck> you want your machine to dance to music videos?
[17:25:46] <CaptHindsight> I've been thinking about some mods to sync video/motion (svg files) to motion
[17:26:08] <CaptHindsight> mozmck: that could be another application :)
[17:26:14] <seb_kuzminsky> is this for one of those dlp 3d printers?
[17:26:40] <CaptHindsight> this is for more advanced versions of DLP printers
[17:26:57] <CaptHindsight> where you have more than just DLP or a laser
[17:27:20] <seb_kuzminsky> the only "motion" you need is to raise the print one layer after each exposure, right?
[17:27:21] <CaptHindsight> nozzles, inkjet, laser and DLP
[17:27:44] <CaptHindsight> https://github.com/andypugh/SVG_Slicer
[17:27:46] <seb_kuzminsky> oh, that sounds like more motion than just 1 Z-step per image
[17:28:15] <CaptHindsight> seb_kuzminsky: or you never stop the Z at all, except at the finish of the print
[17:28:54] <CaptHindsight> you can do continuous Z motion while just changing the video as the Z reaches the next slice
[17:29:35] <seb_kuzminsky> what i'm trying to say is, if you just need "one Z step per image" as your only motion, or "move Z continuously while changing images", then you probably don't want motion and interp and all that, you can probably do it easier just using hal
[17:30:19] <jepler> what z velocity might be used in this case? >1in/min?
[17:30:35] <CaptHindsight> but you might want to move Z while changing the video, then stop the Z and perform other operations like move a printhead, spindle, nozzle etc
[17:31:08] <CaptHindsight> then move Z again while synchronizing video
[17:31:44] <CaptHindsight> the printers are DLP/SLA hybrids with inkjet, FDM, spindles etc
[17:31:53] <seb_kuzminsky> wow
[17:32:30] <CaptHindsight> I've been doing it all with separate controllers until now
[17:32:53] <CaptHindsight> but I'd like to unify it all under Linuxcnc
[17:33:40] <CaptHindsight> andy has that python routine for HAL
[17:34:04] <CaptHindsight> so you can have a slideshow of SVG layers synced to Z motion
[17:36:00] <CaptHindsight> but I need to stop the part after some layers are built with a DLP and photopolymer and then have say and inkjet head make a few passes over the part then go back to DLP+resin for some 1 or more layers
[17:36:14] <CaptHindsight> and/an
[17:37:31] -!- KimK_laptop has quit [Ping timeout: 252 seconds]
[17:39:24] <CaptHindsight> maybe use Andy's way of synchronizing video while Z is moving and maybe custom m-codes to trigger images when just straight DLP printing is not occurring
[17:43:16] <CaptHindsight> I've used m-codes to trigger the start and stop of inkjet scans where the printheads were using the X and Y encoders for position
[17:49:46] -!- KimK_laptop [KimK_laptop!~Kim@wsip-70-186-238-216.ks.ks.cox.net] has joined #linuxcnc-devel
[17:50:03] anth0ny_ is now known as anth0ny
[17:54:27] -!- skunkworks_ [skunkworks_!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[17:55:27] -!- skunkworks has quit [Ping timeout: 256 seconds]
[17:56:41] <skunkworks_> Just replaced 8 blown caps on a mission critical motherboard. Sucess!
[17:57:15] <skunkworks_> (after blowing up a new psu because I forgot the machine was italian and runs 220...)
[17:57:32] <skunkworks_> it went BANG!
[18:02:48] <skunkworks_> If I would have grabbed one of the new psu's that don
[18:03:02] <skunkworks_> 't have the switch - I would have been golden...
[18:03:18] <seb_kuzminsky> nice recovery tho
[18:05:23] <CaptHindsight> done that myself
[18:05:59] <CaptHindsight> but it's usually been a 120V 60hz supply on 240V 50hz when traveling
[18:19:45] <skunkworks_> it was a hack job.. I just pull them off the top of the board and soldered them to tails left over.
[18:20:36] <skunkworks_> I don't have good luck pulling the caps through the board..
[18:21:12] <ssi> once you pop 'em off desoldering the tails should be pretty easy
[18:21:29] <ssi> I revived my tek tds420 scope years ago by replacing all the surface mount caps in it
[18:23:14] <skunkworks_> I tried that on 1 or 2 just to see. I have pulled them through and then drilled the holes back out before.
[18:24:17] <archivist> good hot iron and a solder sucker
[18:24:45] <ssi> yep
[18:25:11] <archivist> and asbestos fingers
[18:25:18] <ssi> or tweezers :)
[18:25:28] * ssi has asbestos fingers though
[18:25:36] <archivist> fresh blob of solder on both pins
[18:25:46] <ssi> or some flux
[18:27:39] <skunkworks_> next time
[18:28:11] <ssi> tonight I have to pull and replace a qfp64 arm
[18:28:15] <CaptHindsight> I've worked at places where the standard operating procedure was to just tack the new caps onto the opposite side of the pcb if there was room
[18:28:54] <skunkworks_> thought about that.. ;) not enough room between the botom of the board and the case..
[18:30:01] <CaptHindsight> funny thing is about it is that those shops are still in business where the ones that did a good job got bought out by the hacks
[18:36:11] -!- patrickarlt has quit [Remote host closed the connection]
[18:45:47] -!- patrickarlt has quit [Remote host closed the connection]
[18:50:16] -!- skunkworks [skunkworks!~chatzilla@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[19:08:06] -!- gambakufu has quit [Ping timeout: 260 seconds]
[19:46:42] -!- maxcnc has quit [Quit: ChatZilla 0.9.92 [Firefox 38.0/20150511103818]]
[19:51:38] -!- DaPeace has quit [Quit: Leaving.]
[19:55:01] -!- patrickarlt has quit [Remote host closed the connection]
[19:56:24] -!- skunkworks_ has quit [Read error: Connection reset by peer]
[20:00:50] -!- skunkworks has quit [Ping timeout: 240 seconds]
[20:01:36] -!- pcw_home has quit [Ping timeout: 255 seconds]
[20:07:41] -!- PetefromTn_ [PetefromTn_!~IceChat9@75-136-59-160.dhcp.jcsn.tn.charter.com] has joined #linuxcnc-devel
[20:15:41] -!- Simonious has quit [Remote host closed the connection]
[20:15:47] <mozmck> Is there a way to unload a gcode file so there is nothing loaded?
[20:15:58] <seb_kuzminsky> alt-ctrl-del
[20:16:14] <mozmck> power button? :)
[20:16:30] <seb_kuzminsky> i dont think there's a gentler way
[20:16:36] <seb_kuzminsky> you could load an empty file maybe?
[20:16:44] <seb_kuzminsky> err, one consisting of just m2
[20:16:50] <seb_kuzminsky> or maybe that will crash the system, i dont know
[20:17:01] * seb_kuzminsky <-- very helpful
[20:17:13] <mozmck> Hmm, I'll see if I can tell it to load an empty file.
[20:17:56] <mozmck> We need to close it because if we have a file open, we apparently cannot overwrite it with an external CAM program.
[20:17:57] -!- b_b has quit [Remote host closed the connection]
[20:42:52] -!- Simonious has quit [Remote host closed the connection]
[20:42:55] -!- andypugh [andypugh!~andypugh@cpc14-basl11-2-0-cust1010.20-1.cable.virginm.net] has joined #linuxcnc-devel
[20:43:01] <micges> mozmck: file with just m2 works fine
[20:43:25] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[20:43:32] <mozmck> micges: thanks.
[20:46:26] -!- asdfasd has quit [Ping timeout: 260 seconds]
[20:49:02] -!- micges_ [micges_!~micges@abpp98.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[20:50:57] -!- amiri has quit [Read error: Connection reset by peer]
[20:52:14] -!- micges has quit [Ping timeout: 244 seconds]
[20:54:28] micges_ is now known as micges
[20:55:28] -!- bjmorel_work has quit [Read error: Connection reset by peer]
[20:55:30] -!- bjm_ [bjm_!~brianmore@71-13-81-38.static.bycy.mi.charter.com] has joined #linuxcnc-devel
[21:00:08] <seb_kuzminsky> mozmck: there is an EMC_TASK_PLAN_CLOSE message (from the GUI to Task), which sounds related to the EMC_TASK_PLAN_OPEN that opens a gcode file, but Task does not implement EMC_TASK_PLAN_CLOSE, so who knows whats up with that
[21:00:37] <mozmck> Hmm, somebody thought of it but never finished?
[21:00:50] <seb_kuzminsky> mmmaybe
[21:01:43] <mozmck> where is the code that becomes the linuxcnc.so python module?
[21:02:21] -!- sumpfralle has quit [Ping timeout: 255 seconds]
[21:02:22] <mozmck> I find emcmodule.cc under usr_intf/axis/extensions - and it seems to have the right stuff in it
[21:02:41] <mozmck> But that's a rather odd location?
[21:02:50] -!- FinboySlick has quit [Quit: Leaving.]
[21:02:56] <seb_kuzminsky> yep, that's the one
[21:03:00] <seb_kuzminsky> and yep, that's an odd location
[21:03:08] <mozmck> well, ok.
[21:03:29] <micges> probably it's from times when axis was standalone program
[21:04:15] <mozmck> makes sense. would it be hard to move to a more obvious location?
[21:05:17] <seb_kuzminsky> another odd thing about the python module: it makes a status object in python that is like the status struct in shared memory that C uses, but it renames a bunch of the fields
[21:05:34] <mozmck> oh, interesting.
[21:05:45] <seb_kuzminsky> it would not be that hard to move it, and it would probably be a good cleanup to do in master
[21:06:13] -!- patrickarlt has quit [Remote host closed the connection]
[21:06:14] <micges> also opengl stuff could be factored out
[21:06:33] <mozmck> I wonder if all the python module code could go in their own subdirectory. canonmodule.cc, gcodemodule.cc, etc.
[21:06:53] <seb_kuzminsky> oh yeah, theres a bunch of gremlin(?) stuff in the linuxcnc.so python module
[21:07:08] <mozmck> interesting.
[21:07:16] <seb_kuzminsky> mozmck: that would make sense to me
[21:07:41] <seb_kuzminsky> is that all jepler code? i suggest you let him weigh in, he may think of something you and i dont
[21:08:19] <mozmck> I'm pretty ignorant so that would not be hard on my part :)
[21:11:57] amnesic_away is now known as amnesic
[21:14:37] -!- sumpfralle has quit [Ping timeout: 246 seconds]
[21:15:52] <mozmck> seb_kuzminsky: sounds like you made eric happy
[21:16:11] -!- dimas_ has quit [Read error: Connection reset by peer]
[21:17:58] <jepler> you can't take away names from Python without breaking code
[21:18:22] <mozmck> take away names?
[21:18:35] <jepler> "it renames a bunch of fields"
[21:18:47] <mozmck> oh, that, yes.
[21:18:48] <jepler> if you change the names so that they match C++, you break the software that uses the current names
[21:19:08] <mozmck> what about moving the python module files to different locations?
[21:19:15] <seb_kuzminsky> you could make new names that match the C field names, without taking away the old backwards-compatible renamed names
[21:19:34] <jepler> seb_kuzminsky: yes if the C++ names are better
[21:20:07] <seb_kuzminsky> i dont know if one's better than the other, but if they're the same i wont be surprised when i switch languages ;-)
[21:20:30] <jepler> yes
[21:20:42] <jepler> younger me thought each name he was choosing in Python was better than the one in C++
[21:21:09] <jepler> similarly, removing opengl related stuff from linuxcnc module to a new module will break code in the wild
[21:21:12] -!- patrickarlt has quit [Remote host closed the connection]
[21:21:18] <jepler> because the name linuxcnc.logger or whatever it is will be gone
[21:21:33] <seb_kuzminsky> i won't get involved in a fight between young-jepler and old-jepler
[21:21:42] <jepler> so you will at least need to deprecate first and move later
[21:22:09] <seb_kuzminsky> maybe add the external opengl module, mark the internal one as deprecated, wait a release cycle for out-of-tree guis to catch up, then remove the internal one
[21:22:13] <jepler> i.e., create new module linuxcnc.gl, and have linuxcnc module import linuxcnc.gl.* during the deprecation period
[21:22:21] <seb_kuzminsky> heh
[21:22:57] <jepler> and another thing: if we think we're going to get back to the lui project, then why have churn now that we're going to re-churn soon
[21:23:17] <seb_kuzminsky> oh yeah
[21:23:19] <mozmck> hmm.
[21:23:23] <seb_kuzminsky> i was thinking about that just earlier today
[21:23:30] <mozmck> I wouldn't mind helping on that project.
[21:24:05] <seb_kuzminsky> i think it's an easy project to jump in and help with now - just pick one of the NML-interface commands and convert it
[21:24:32] <seb_kuzminsky> but part of the linuxcnc.so cleanup can happen in parallel with lui: the move to a less axis-centric place
[21:24:34] <mozmck> What is it being converted to? I saw discussion here about a "wire" protocol vs API
[21:24:53] <seb_kuzminsky> an API for now
[21:24:56] <jepler> stage 1 is to define a "C" API
[21:24:58] <mozmck> ok
[21:25:06] <jepler> the implementation will be NML
[21:25:10] <seb_kuzminsky> if you look at the liblinuxcnc-ui branch you'll see where it's all taking place
[21:25:30] <mozmck> I pulled it the other day but haven't looked yet :(
[21:25:44] <seb_kuzminsky> there's individual commits that move each NML command from a hodge-podge of duplicated, hand-coded C to a single copy of hand-coded C
[21:26:14] <seb_kuzminsky> plus jeplers auto-generated functions to access status fields
[21:26:50] <mozmck> thinking of status, is there a HAL pin to indicate a probing move?
[21:27:13] <jepler> mozmck: probably, did you read the motion manpage?
[21:27:38] <mozmck> I see a motion.motion-type mentioned under debugging and subject to arbitrary removal
[21:27:49] -!- JT-Shop has quit [Remote host closed the connection]
[21:28:01] <jepler> anyway, in a second stage a developer can replace the lui-to-task communication with something besides NML, like json or whatever is fashionable now
[21:28:11] <mozmck> and the note at the bottom "This manual page is horribly incomplete."
[21:28:17] <seb_kuzminsky> haha
[21:28:22] <seb_kuzminsky> we rock
[21:28:29] <mozmck> oh, and the date of 2007
[21:28:36] <mozmck> :)
[21:29:00] <jepler> then I guess there's not
[21:29:01] amnesic is now known as amnesic_away
[21:29:02] <mozmck> I'll look more.
[21:29:53] <seb_kuzminsky> "it probably wouldn't be hard to add" he said, not having looked at the relevant code
[21:32:42] -!- tocka has quit []
[21:41:29] -!- jerryitt has quit [Quit: Connection closed for inactivity]
[21:43:49] -!- motioncontrol has quit [Quit: Sto andando via]
[21:47:55] -!- jthornton [jthornton!~john@172.242.222.19] has joined #linuxcnc-devel
[21:48:03] -!- patrickarlt has quit [Remote host closed the connection]
[21:48:44] -!- Deejay has quit [Quit: bye]
[21:52:08] -!- patrickarlt has quit [Read error: Connection reset by peer]
[21:58:01] -!- sumpfralle has quit [Ping timeout: 246 seconds]
[22:01:46] -!- chris_99 has quit [Quit: Leaving]
[22:02:05] -!- chillly has quit [Quit: Ex-Chat]
[22:12:45] -!- patrickarlt has quit [Remote host closed the connection]
[22:13:51] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[22:30:39] -!- patrickarlt has quit [Remote host closed the connection]
[22:34:10] -!- JT-Shop [JT-Shop!~john@172.242.222.19] has joined #linuxcnc-devel
[22:35:19] amnesic_away is now known as amnesic
[22:42:02] -!- md-2 has quit [Remote host closed the connection]
[22:46:59] -!- rkj has quit [Quit: Leaving]
[22:56:12] -!- Tecan has quit [Ping timeout: 255 seconds]
[23:15:02] -!- jthornton has quit [Read error: Connection reset by peer]
[23:15:03] -!- JT-Shop has quit [Read error: Connection reset by peer]
[23:15:38] -!- jthornton [jthornton!~john@172.242.222.19] has joined #linuxcnc-devel
[23:15:38] -!- JT-Shop [JT-Shop!~john@172.242.222.19] has joined #linuxcnc-devel
[23:39:51] -!- anth0ny has quit [Quit: anth0ny]
[23:54:50] Wolf_MillCrsh is now known as Wolf_Mill