Back
[00:00:25] <seb_kuzminsky> heh
[00:01:58] <seb_kuzminsky> KimK: i dont know much about manufacturing, but my impression is that generally gcode is written by cam software, not machinists
[00:02:57] <seb_kuzminsky> how much control do the operators on the machine floor have over what happens on their machines? i assume they set the tool table, touch off, and then run a giant opaque g-code program that they got from some guy who works on a cam station in an office
[00:03:41] <seb_kuzminsky> at least that's how it was done at the University of Colorado machine shop that i worked at a couple of years ago
[00:04:44] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 46564b3 06linuxcnc 10docs/src/getting-started/Getting-LinuxCNC.txt docs: better "Getting LinuxCNC" intro * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=46564b3
[00:05:24] <kwallace> When I worked in a real machine shop, the operator set up the tool changer and work holding, loaded the program, did a quick check, pushed GO, then deburred parts for the rest of the run.
[00:06:08] <KimK> Yes, this is generally true, but sometimes the operators have to make last minute changes, and that's fine, but some may a want a record kept of the changes. Maybe an exotic material work-hardens more/less than the programmers thought, and the operator has to make lots of feed/speed changes for different cuts.
[00:06:39] <seb_kuzminsky> KimK: good point, there might be twiddling of FO & SO
[00:06:47] <KimK> kwallace: Hi Kirk! Yes, that's the way it's *supposed* to work, lol. But sometimes it doesn't.
[00:07:11] <seb_kuzminsky> and that'd be valuable feedback to the programmer (the guy who runs the CAM software & produces giant g-code files)
[00:07:31] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master f3ca26a 06linuxcnc 10scripts/linuxcnc.in Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f3ca26a
[00:07:39] <KimK> Nice to have some kind of record of what was done too, as far as ISO9000, and other paperwork baloney.
[00:07:50] <seb_kuzminsky> but it's not really something the operator could change in the program, is it? they'd need to tweak the CAM settings and re-generate the toolpaths, and they dont have access to that on the machine floor i think
[00:08:36] <kwallace> In the shop I worked at, the job would go back to the CAM room, to be fixed.
[00:09:19] <KimK> If it's contouring (often the case), then the feed and speed is set at the beginning of some sub-operation.
[00:10:12] <KimK> Anyway, it's an idea, and git seems made for it.
[00:11:39] <pcw_home> seb_kuzminsky: I'll try to duplicate the calibrate bug tommorow
[00:12:15] <seb_kuzminsky> KimK: i certainly keep all my interesting g-code programs in a git repo, and tweak them as i go
[00:12:55] <seb_kuzminsky> and i use this, because i'm too poor to afford CAM software so i write most of my g-code by hand:
https://github.com/SebKuzminsky/lib-gcode
[00:13:03] <seb_kuzminsky> pcw_home: that'd be great, thanks
[00:25:57] <kwallace> I suppose real shops have some sort of version control somewhere in the work flow. It used to be in the corner of the velum.
[00:40:26] <kwallace> I wonder if Git could be used in the background with a controller's file utility?
[00:43:00] <kwallace> It would need to be tied in with anything that could change a file, so sounds more like the controller should be a slave to a file server.
[00:46:52] <kwallace> Along with the tool manager and material acquisition system. Damn, my glass is empty.
[00:54:18] <kwallace> And now ends another broad cast day ... beeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
[02:23:00] <linuxcnc-build> build #2786 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/2786 blamelist: Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[02:23:47] <linuxcnc-build> build #2796 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2796 blamelist: Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[04:50:22] <andypugh> Bob’s article claims benefits for drip-feed that can equally well be achieved by keeping the programs on a networked drive, which is pretty easy with both LinuxCNC and Mach.
[05:41:13] <skunkworks> although with mach - your not supposed to use network because it could cause problems with the printer port. Maybe it is better with motion control cards.
[07:08:59] <KGB-linuxcnc> 03Dewey Garrett 052.7 1992591 06linuxcnc 10lib/hallib/hookup_moveoff.tcl hookup_moveoff.tcl: fix fb connections * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1992591
[08:08:21] <skunkworks> http://www.thecooltool.com/en/accessories/details/sandybox/
[09:23:46] <seb_kuzminsky> that master runtests failure is unexpected and interesting
[09:28:39] <seb_kuzminsky> oh, looks like a bug in the test
[09:29:35] <seb_kuzminsky> # give linuxcnc a second to finish
[09:29:35] <seb_kuzminsky> sleep 1.0
[09:29:44] <seb_kuzminsky> note to self: sleep is not a synchronization primitive
[09:30:37] <cradek> ~/emc/tests$ grep -r sleep .|wc -l
[09:30:37] <cradek> 35
[09:31:02] <cradek> it's not a good one, but it's a popular one
[09:31:15] * seb_kuzminsky hides
[09:35:54] <skunkworks> seb_kuzminsky, your comment hasn't shown up yet...
[09:36:48] <seb_kuzminsky> skunkworks: yeah, i noticed that
[09:37:01] <seb_kuzminsky> it's still "awaiting moderation"
[09:37:20] <seb_kuzminsky> here's a paste of it, in case it disappears:
http://pastebin.com/aVm1mNCn
[09:40:12] <seb_kuzminsky> cradek: i think most of those sleeps are not the kind of bug that caused the build failure above
[09:40:43] <seb_kuzminsky> in fact, the toolchanger/toolno-pocket-differ test is the only one that looks like a real bug
[11:13:23] <KimK> skunkworks: I don't see the price of "SandyBox", do you know?
[11:13:42] <skunkworks> no.. they posted it on the machinekit list.
[11:14:31] <KimK> Just curious what they're getting for the thing.
[11:15:16] <skunkworks> https://groups.google.com/forum/#!topic/machinekit/ea2ik1Gr61s
[11:21:30] <pcw_home> look like a beaglebone and DB25 adapter
[11:21:50] <skunkworks> I would assume that is what it is..
[11:23:34] <andypugh> I don’t think that they are claiming anything else of it. However it is interesting that it seems to be doing some sort of remote X-session over USB.
[11:24:46] <skunkworks> right - untill the rest of the machinetalk gets worked out.. Then they should be able to connect to it using socket or whatever it is called.
[11:25:34] <pcw_home> Wonder why they chose USB?
[11:25:59] <skunkworks> I think alex_joni had a system setup using linuxcnc in a similar way.
[11:26:11] <skunkworks> (over usb)
[11:26:52] <pcw_home> Yeah, that may even be Alex's adapter
[11:27:00] <skunkworks> oh - sure
[11:27:11] <skunkworks> iirc he had done some work with them..
[11:27:15] <skunkworks> maybe
[11:33:36] <seb_kuzminsky> when people complained about jeff and me starting to write lui, we looked in to machinekit's new communication system a little
[11:34:09] <seb_kuzminsky> they have a server that speaks nml to their controller, just like our and their guis do, but this server accepts network connections (iirc) and translates them to nml
[11:34:20] <seb_kuzminsky> so it's a bit like linuxcncrsh, but with a smarter protocol on the front end
[11:35:21] <andypugh> I believe that is a half-way house to a system that doesn’t use NML
[11:36:44] <seb_kuzminsky> i think so too
[11:37:45] <skunkworks> do you constanly have the louie louie song in your head?
[11:38:00] <pcw_home> I do now
[11:41:01] <seb_kuzminsky> my comment on the CNC Cookbook article got posted:
http://blog.cnccookbook.com/2014/12/16/10-features-pros-hobby-cnc-controllers-dont/
[11:42:42] <skunkworks> awesome!
[11:47:49] <bjmorel_work> seb_kuzminsky: Very well written comment.
[11:48:38] <bjmorel_work> seb_kuzminsky: Did you put ballscrews in your Bridgeport?
[11:49:04] <seb_kuzminsky> thanks!
[11:49:09] <seb_kuzminsky> it already had ballscrews
[11:49:37] <seb_kuzminsky> it's an R2E3, which was built by Bridgeport as a full CNC machine originally
[11:49:49] <seb_kuzminsky> cradek and i replaced the old controller with LinuxCNC
[11:50:06] <seb_kuzminsky> but the amps and iron are original
[11:51:41] <cradek> > The tool compensation feature includes support for multiple simultaneous offsets, typically used for nominal tool diameter and wear compensation.
[11:51:46] <cradek> I don't think this is true
[11:52:18] <seb_kuzminsky> isnt that what g43.2 does?
[11:52:26] <cradek> that's length/offset, not diameter
[11:52:39] <seb_kuzminsky> oops
[11:52:58] <cradek> people often stir together the ideas of length and diameter
[11:54:49] <seb_kuzminsky> i see now that you are right
[11:54:57] <seb_kuzminsky> darn
[11:55:23] <cradek> eh it's close enough
[11:56:02] <cradek> I think his problem #8 assumes all (both?) hobby controllers have the same bugs in their cutter comp implementations
[11:56:25] <archivist> seb_kuzminsky, straightness compensation, you could mention stuarts cinci
[11:56:26] <cradek> I assume the PCNC1100 manual is talking about working around mach bugs
[11:56:58] <cradek> who knows - they may still use the old emc algorithm which was pretty limited
[11:57:21] <cradek> uhh file:///C:/Users/BobWarfield/Downloads/PCNC1100-3-3-UM_0712A_web.pdf
[11:57:25] <cradek> that ain't gonna work
[11:57:41] <cradek> why am I still reading this
[11:57:44] <pcw_home> I dont think he is at all familiar with linuxcnc and assumed it was more similar to Mach than it is
[11:57:52] <cradek> yes
[11:58:06] <cradek> he doesn't seem to know what he doesn't know
[11:58:32] <jepler> like I'd get anything right if I wrote about Mach
[11:58:50] <cradek> you'd know not to, because you know what you don't know
[11:58:57] <andypugh> http://youtu.be/cm2gZh5k4F0 : How to fiddle the machine parameters to make your point.
[12:00:02] <andypugh> Bob did subscribe to the forums a year or more ago. (I saw the name go past).
[12:00:12] <cradek> andypugh: wow what a video
[12:03:10] <cradek> although a reversing tapping head is always going to be faster than accelerating a spindle a bunch of times, they're sure a pain
[12:03:15] <cradek> bbl
[12:05:14] <archivist> I dont like the thread force needed to reverse the tapmatic
[12:14:59] <bjmorel_work> I was quoting a customer a ball screw assembly this morning & noticed that Rockford has ball screw kits for Bridgeport & clones.
[12:15:02] <bjmorel_work> http://www.rockfordballscrew.com/products/retrofit-kits/
[12:18:07] <skunkworks> andypugh, wow. that machine might also have some sort of acurate depth control that you are seeing.. (although the up pause doesn't make any sense...)
[12:18:57] <skunkworks> eh - I think andy is right - crappy machine setup.
[14:04:39] <skunkworks> seb_kuzminsky, bob replied..
[14:29:19] <cradek> > Rather than delve into the excruciating detail of exactly which controls do what
[14:29:52] <cradek> but that's what the original post was ABOUT
[14:30:15] <cradek> it's what the TITLE says
[14:31:41] <cradek> in better news, I booted our rtai kernel live (because it's what I had on my stick) to test a usb-connected tape drive, and it worked fine, shows up as st0 like normal
[14:31:45] <cradek> that's pretty cool
[14:32:08] <cradek> yes there are usb tape drives - you don't need scsi anymore
[14:33:30] <PCW> Probably SCSI protocol somewhere
[14:36:35] <cradek> oh sure
[14:37:23] <cradek> I'm sure scsi gets encapsulated in at least a layer or two
[14:37:32] <cradek> I meant you don't need scsi hardware
[14:40:59] <PCW> Is their modern SCSI hardware?
[14:41:34] <cradek> last I bought a (new) tape drive it was available in both scsi and sas
[14:42:12] <cradek> so I think so
[14:42:43] <PCW> hmm that last tape drive I used was a TK50 :-)
[14:42:53] <seb_kuzminsky> i feel hm2_scsi coming on
[14:43:19] <cradek> you're not the first one to suspect scsi would be a better realtime interface than parport
[14:44:06] <PCW> Even IDE/SATA
[14:46:37] <cradek> yeah it's all the same
[14:46:52] <cradek> any interface anyone has stuck a tape drive or scanner on is probably fine
[14:47:03] <cradek> epp, floppy, scsi, ide
[14:48:21] <KimK> I've wondered about using SATA for things too, since they're fast, and motherboards anymore seem to have three to six of them(!)
[14:48:39] <PCW> Wish Xilinx would put a hard 1G EMAC in a cheap FPGA
[14:48:41] <PCW> Intels new PCIE 1G MAC/PHYs are only ~$3 dollarish
[14:48:46] <cradek> more importantly you can add them with cheap-or-free pci cards
[14:51:00] <PCW> I wonder what the SATA--PATA bridge latencies are like (we only pay about $1.60 for the ones we use)
[14:54:47] <PCW> I'd use the Intel MAC but the Xilinx PCIE root node uses 10000 LE's
[14:57:12] <andypugh> Thunderbolt?
[14:59:32] <PCW> Still pretty uncommon (plus Intel specs need NDA)
[15:00:59] <cradek> the physical scsi bus is better than epp, floppy, ide, sata, etc: supports multiple targets, and can easily drive nice long wires
[15:01:10] <cradek> see also, gpib
[15:01:46] <andypugh> I have two in this room, They must be very common :-)
[15:01:56] <cradek> which?
[15:02:06] <andypugh> Thunderbolt.
[15:02:12] <andypugh> GPIB is upstairs.
[15:02:19] <PCW> plus Ethernet has Isolation which is nice (PCIE could have had it except for a stupid beacon spec)
[15:02:24] <cradek> yeah I might have to go into the next room to find gpib stuff
[15:02:49] <cradek> I bet ethernet is the clear winner in today's world
[15:03:53] <PCW> USB3 might be decent
[15:04:16] <PCW> full duplex, interrupt driven etc
[15:04:24] <cradek> no isolation
[15:04:32] <PCW> well sure
[15:05:28] <PCW> Not sure if its possible ( a tiny xfrmer could isolate PCIE except for the stupid beacon)
[15:06:29] <cradek> I used a connector pried off an ethernet card for something the other day, and was surprised to find the tiny transformer in it that made my stuff ... not connect
[15:06:33] <cradek> obvious in retrospect
[15:07:23] <PCW> yeah most use "integrated magnetics"
[15:07:40] <cradek> it was so tiny it looked like it couldn't be that much isolation
[15:07:43] <PCW> good ones have 4 cores
[15:07:54] <MarkusBec> hacking fw vor a gbic optical fiber transiver?
[15:07:59] <cradek> I don't remember how many I pried out
[15:08:09] <PCW> they depend entirely on the wire insulation
[15:08:43] <MarkusBec> http://de.wikipedia.org/wiki/Gigabit_Interface_Converter#mediaviewer/File:Finisar_GBIC_SX_2.jpg
[15:09:05] <MarkusBec> ony a transiver and some logic magic
[15:10:17] <MarkusBec> only
[15:14:19] <PCW> didn't look like this did it?
[15:14:20] <PCW> http://leaksource.files.wordpress.com/2013/12/nsa-ant-cottonomouth-iii.jpg
[15:26:11] <kwallace> Tormach has released their LinuxCNC version only for the lathe so Bob W's comments may need to be considered in that context. Also I think Tormach LinuxCNC is based on 2.6.4/10.04 with a lot of Tormach changes from there.
[15:27:19] <seb_kuzminsky> the GPL requires them to publish any changes they distribute, but i have not seen much of anything from them
[15:29:44] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 219ec4a 06linuxcnc 10tests/t0/shared-test.sh tests: simplify t0 test and increase task queue usage * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=219ec4a
[15:29:44] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 2eaf794 06linuxcnc 10tests/toolchanger/toolno-pocket-differ/shared-test.sh tests: fix a race condition in the toolchanger/toolno-pocket-differ test * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2eaf794
[15:30:06] <seb_kuzminsky> that fixes the race condition that caused the master build failure last night
[15:30:50] <PCW> Naturally I cannot duplicate the calibrate bug :-(
[15:32:33] <PCW> maybe the bug is a mousepad bug (replacing random EOLs with the filename)
[15:33:22] <kwallace> seb_kuzminsky, Yes, but the powers that be are using the "if asked for" clause. It's not that they want to withhold anything, but dealing with competitors doing a wholesale rip-off hasn't been addressed yet.
[15:33:58] <seb_kuzminsky> i did ask them for it
[15:34:19] <seb_kuzminsky> they said "yes later" and then never published anything
[15:35:07] <seb_kuzminsky> zlog:
[15:37:54] <kwallace> Well... at that time they didn't want to have unrefined code that could be attributed to Tormach going out. It's probably not an issue not that the lathe is released, but only just.
[15:38:13] <kwallace> now that
[15:41:27] <KimK> On the (earlier) subject of demo videos, I forgot to say that this is one of my favorite "linuxcnc got it right" motion-sync videos (not strictly rigid tapping, actually lathe threading, but very similar). He's not cutting new threads here, but using a previously-cut thread to show the re-threading (he slightly repositions the workpiece early on).
[15:41:48] <KimK> It's my favorite for two reasons: (1) he mounted the camera on the tool, so motion sync is clearly visible when it occurs (it's a large workpiece), and (2), he turns the first pass or two by hand, spindle in neutral, and the tool stops/slows exactly when he does, showing that it's not RPM-dependent and that it's not "guessing" where the spindle is "estimated" to be.
[15:41:51] <KimK> https://www.youtube.com/watch?v=pxXGN2SVrhU
[15:41:55] <seb_kuzminsky> kwallace: what is the "if asked for" clause?
[15:43:47] <seb_kuzminsky> do you mean section 3.b?
[15:43:49] <seb_kuzminsky> bbl
[15:47:33] <andypugh> There has been a suggestion on the Forum that my lathe macro config should be one of the demo configs.
[15:47:46] <andypugh> Opinions?
[15:51:36] <kwallace> seb_kuzminsky, I am not at all knowledgeable about GPL. I avoid these issues if possible. I can get better if I have to.
[16:00:22] <PetefromTn_> KimK that is a really neat video. I remember the first time I saw Andypugh's similar video showing synchronized motion on his 3 in 1 machine setup. Really cool.
[16:11:27] <KimK> PetefromTn_: Yes, Andy's excellent motion-synchronized gear hobbing video also deserves mention, but in this specific case (the 10-point article), the significance of gear hobbing might be lost on the average Mach user who is having trouble rigid-tapping (or threading) and looking for alternatives.
[16:14:09] <Tom_itx> i notice the spindle speeds upon rapid return of the tool to the start
[16:14:43] <Tom_itx> in reality it should stay constant and pick up the next index pulse for the return path
[16:16:33] <Tom_itx> if one wasn't careful while threading the barstock could start whipping around and pull the tailstock out of the floor
[16:16:48] <PetefromTn_> I just happend upon the conversation so I was not sure of the intent. It is interesting how it works. I am unsure exactly how a MACH3 driven machine would do the same thing if it even can...
[16:17:02] <KimK> I didn't notice that, I'll look at it again. He may have been fiddling with the engage lever?
[16:17:10] <Tom_itx> lcnc stays in sync during the whole cuting process
[16:17:40] <Tom_itx> i'm not sure what would happen if you turned that off on each rapid return and back on for the next pass
[16:17:46] <Tom_itx> it should still pick up the index pulse
[16:19:02] <Tom_itx> other than that it's a wonderful feature
[16:19:28] <Tom_itx> it could also just be the camera's perspective
[16:19:41] <Tom_itx> but i swear i see the spindle speed up
[16:20:59] <andypugh> In CSS mode the spindle will speed up when the tool retracts.
[16:20:59] <jepler> kwallace: you should probably read up on the GPL. When someone ships GPL software, particularly in binary form as part of a business model, it's very important to comply with the GPL. Noncompliance terminates your GPL rights including the rights to distribute the software.
[16:21:27] <jepler> kwallace:
http://www.softwarefreedom.org/resources/2008/compliance-guide.html may be a helpful article, it even includes sample language to include with a product to help comply with the GPL2 section 3(b) requirements
[16:21:55] <Tom_itx> it's hard to tell with the flourescents pulsing against the chuck fingers and the video frames
[16:22:22] <kwallace> Yes, I understand that, now may be the time to start working in that direction.
[16:25:03] <kwallace> I glanced through GPL2 and got the feeling that I can weed out any files that are not derived from LinuxCNC proper.
[16:25:06] <jepler> and fwiw even though the GPLv2's requirement is to distribute the software on media for a fee, a company which doesn't also offer the software for download without fee is seriously out of step with the norms of Free Software.
[16:25:25] <jepler> I don't understand what you mean when you say "weed out"
[16:36:10] <kwallace> We (but I'm not a legal we) have a body of files of which LinuxCNC is a part of. It seems prudent to only provide work that satisfies the license. Once that is out of the way we can go from there.
[16:36:48] <jepler> .. and I'm certainly not giving legal advice, and I am not a lawyer
[16:37:25] <jepler> in the GPL the relevant term is 'a "work based on the Program" [meaning] either the Program or any derivative work under copyright law"
[16:38:23] <jepler> at one extreme, a program which incorporates no source files from LinuxCNC and works entirely identically if installed on a computer without LinuxCNC is probably clearly not a derivative of LinuxCNC in the copyright law sense, even if it (say) produces a .ini file or a .ngc file that is useful to LinuxCNC
[16:38:49] <jepler> at the other extreme, a program which requires a LinuxCNC shared library in order to function at all is probably a derivative in the copyright law sense
[16:47:28] <kwallace> I need to take some time to get a handle on this. If there are conflicts, does LinuxCNC have an official person to deal with?
[16:50:30] <cradek> in the past we've had good luck asking a fsf lawyer for help/advice. but nothing that I see so far shows that your situation is complicated in any way - you can read the license and figure out what you need to do. I'm not sure what you would want from any/one of us.
[16:51:08] <cradek> jepler's link earlier is a really good one
[16:51:39] <cradek> and the text of the gpl2 is really quite short and easy to understand. it's only a few paragraphs.
[16:57:39] <jepler> kwallace: there's no linuxcnc legal entity for you to talk to, but there are any number of us here who are willing to offer our opinions about GPL compliance (as several of us have been doing this afternoon)
[16:57:43] <jepler> BBL
[17:21:40] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 88e0886 06linuxcnc Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=88e0886
[17:22:34] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master fa35947 06linuxcnc Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fa35947
[17:59:35] <memfrob> It's really annoying when the xenomai and RTAI devs copy all my work and never credit me..
[18:01:01] <memfrob> Whenever I bump IPIPE they just push my patch in, no mention of me whatsoever.
[18:09:05] <PCW> Not one of the righteous?
[18:09:59] <memfrob> hmm?
[18:11:01] <memfrob> 3 days ago I bumped IPIPE to 3.14 then this dumbass, Jan, over at xenomai does the same thing, I expect this kind of crap from Paolo, not the xen team.
[18:11:25] <memfrob> *3.14.26
[18:12:53] <memfrob> six hours ago when he committed that patch, he could have done his own 3.14.27 at least to be different, but nope.
[18:15:46] <andypugh> Open Source is a game for the _very_ thick-skinned
[18:24:39] <seb_kuzminsky> memfrob: that sucks man
[18:25:57] <memfrob> Kinda funny how I notice this stuff going on though while everyone is talking about GPL...
[18:26:06] <memfrob> XD
[19:05:33] <seb_kuzminsky> memfrob: did you put a copyright notice on it? did it get propagated when they copied it?
[19:06:25] <memfrob> you cant really stick a copyright notice on a git merge / ipipe.patch
[19:24:01] <mozmck> jepler: you mention that "a program which requires a LinuxCNC shared library in order to function at all is probably a derivative in the copyright law sense". This would not apply to a hal component as I read things, since the hal library is LGPL - right?
[19:39:06] <KimK_unit1> Lately I have resumed work on my classicladder simulator, and I have been looking at larger amounts of DCIO. So I ran across a minor issue, and I was wondering if it can be improved, and how best to. First I used AXIS's HAL viewer here:
http://imagebin.org/326014 Then I just used halcmd here:
http://pastebin.com/6X2qVCZE So AXIS is just following the output from halcmd.
[19:40:07] <KimK_unit1> Clearly this is a sorting issue, so what do you think? Is it better to (1) change the sorting method, (2) add leading zeros and keep the sorting method, or (3) shut up and learn to live with it?
[19:43:31] <KimK_unit1> Advice and suggestions appreciated as always.
[19:46:44] <jepler> mozmck: I should have said something more like "a program which requires a *GPL'd* LinuxCNC shared library".
[19:52:23] <jepler> It is the expressed intent of the original author of HAL (John Kasunich) that the intent is to allow non-GPL hal components to be incorporated into a system based on HAL, when those components use the public APIs of HAL.
[19:53:50] <jepler> The intent, as I understand it, is that the implementor of a HAL component has LGPL-like obligations when using those public APIs.
[19:58:08] <jepler> additionally, by EXPORT_SYMBOL and EXPORT_SYMBOL_GPL we express our intent/belief that use of some APIs but not others are intended not to create GPL-like "work based on the Program" situations.
[19:58:39] <jepler> (something which is actually enforced by a standard kernel when using rtai-based rtapi but unfortunately not when using uspace-based rtapi)
[20:15:06] <jepler> https://lh5.googleusercontent.com/-v4zprc0QgDQ/VIu0U--f_DI/AAAAAAAAOrs/8dX0qUW2puw/w460-h259-no/14%2B-%2B1.gif
[20:16:35] <mozmck> ok, thanks jepler. that's what I had gathered from my reading. I guess the EXPORT_SYMBOL is something in rtapi?
[20:39:24] <mozmck> Is motion.feed-inhibit the same as motion.feed-hold except that it does not care if M53 is active?
[21:00:29] <cradek> mozmck:
http://linuxcnc.org/docs/html/man/man9/motion.9.html
[21:01:00] <cradek> mozmck: not sure, because I don't know (from the docs) how feed-hold works with spindle-sync moves
[21:03:15] <mozmck> thanks cradek. after some more digging I saw a couple of forum posts which gave a little more information. Here is one:
http://linuxcnc.org/lucid/index.php/italian/forum/24-hal-components/27736-suggested-pin-for-vfd-error-input
[21:03:44] <mozmck> http://www.linuxcnc.org/emc2/index.php/english/forum/24-hal-components/27004-multiple-instances-of-feed-hold?start=10
