Back
[00:02:51] -!- logger[mah] has quit [Remote host closed the connection]
[00:02:58] -!- logger[mah] [logger[mah]!~loggermah@ns2.mah.priv.at] has joined #linuxcnc-devel
[00:03:12] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[00:19:54] <kwallace1> I'm not in my shop right now, or I would check. If I call tool 3, then tool 33, the current LinuxCNC will go to pocket 3 on both tools?
[00:22:07] <kwallace1> or I recall using tools 31, 32, 33 for tools on pocket 3.
[00:28:12] <andypugh> I think that depends on the tool changer code. ie you can make it happen, but it is not default
[00:32:09] <kwallace1> That kind of rings a bell. LinuxCNC passes 31 or 32, but the tool comp could int(T/10) to get the pocket.
[00:32:32] <kwallace1> or rather, tool changer comp
[00:36:29] -!- micges has quit [Read error: Connection reset by peer]
[00:38:06] -!- racycle has quit [Quit: racycle]
[00:43:25] -!- Valen has quit [Quit: Leaving.]
[00:49:16] -!- servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[00:51:43] <kwallace1> Playing with a sim config, the tool prepare pocket number follows the table line number rather than the number in the pocket data cell, so pocket really isn't used it seems.
[00:56:33] <cradek> kwallace1: I think both pins are available
[00:57:17] <cradek> whether it all works right though, I have my doubts after what seb has said
[01:00:06] <kwallace1> Yes, and I can live with just using the tool number. I was just trying to get a better idea of how the tool business works. There has been a lot of talk about what the table and change routines can and can't do, and it gets a little confusing.
[01:00:55] <andypugh> pocket number is exactly mapped to row of the software array.
[01:01:28] <andypugh> But that is the number you should see in HAL
[01:02:50] <kwallace1> That's what I found out with the sim. Entering a pocket number makes no difference.
[01:03:40] <andypugh> That's very strange.
[01:04:18] <andypugh> Table row ought to be irrelevant. Something sounds broken,
[01:06:04] <kwallace1> http://www.wallacecompany.com/tmp/pocket.png
[01:10:42] <andypugh> Things seem even worse than I thought then.
[01:11:22] <andypugh> That's just wrong.
[01:12:43] <kwallace1> For my HNC, I can just add my own pocket logic, but I'm also trying to get a handle on Rogge's FANUC tool system.
[01:13:16] -!- PCW has quit [Quit: ChatZilla 0.9.89 [Firefox 18.0.1/20130116073211]]
[01:15:08] -!- zlog has quit [Ping timeout: 256 seconds]
[01:15:21] -!- Tom_itx has quit [Disconnected by services]
[01:15:26] Tom_garage is now known as Tom_itx
[01:15:38] <kwallace1> Pocket has been broken as long as I can remember, so it may not matter.
[01:15:47] -!- zlog_ has quit [Remote host closed the connection]
[01:23:18] <andypugh> I am not fond of Rogge's patch. And it can all be done in mah's remap code if folk want it.
[01:32:57] -!- adb has quit [Ping timeout: 245 seconds]
[01:34:20] -!- rob_h has quit [Ping timeout: 246 seconds]
[01:49:25] <cradek> kwallace1: I understand this nonrandom case is what seb is fixing
[01:51:16] -!- mhaberler has quit [Quit: mhaberler]
[01:58:32] <kwallace1> Seb has been busy.
[02:00:58] -!- joe9 [joe9!~joe9@c-24-98-97-215.hsd1.ga.comcast.net] has joined #linuxcnc-devel
[02:01:56] -!- andypugh has quit [Quit: andypugh]
[02:12:53] -!- micges has quit [Quit: Leaving]
[02:14:54] -!- plushy has quit [Quit: Leaving.]
[02:16:30] -!- LeelooMinai has quit [Remote host closed the connection]
[02:19:27] -!- Servos4ever has quit [Quit: ChatZilla 0.9.89 [SeaMonkey 2.14.1/20121129191050]]
[02:50:57] -!- kmiyashiro has quit [Quit: kmiyashiro]
[02:54:49] -!- KimK [KimK!~Kim__@wsip-184-176-200-171.ks.ks.cox.net] has joined #linuxcnc-devel
[03:02:38] -!- joe9 has quit [Quit: leaving]
[03:04:22] -!- paideia has quit [Quit: Leaving]
[03:04:31] -!- joe9 [joe9!~joe9@c-24-98-97-215.hsd1.ga.comcast.net] has joined #linuxcnc-devel
[03:29:25] -!- cmorley [cmorley!~chris@S010600c09fc019c2.no.shawcable.net] has joined #linuxcnc-devel
[03:57:40] -!- sumpfralle has quit [Ping timeout: 276 seconds]
[04:09:09] -!- Tom_L has quit [Client Quit]
[04:20:07] -!- joe9 has quit [Quit: leaving]
[04:23:25] -!- cmorley1 [cmorley1!~chris@S010600c09fc019c2.no.shawcable.net] has joined #linuxcnc-devel
[04:26:09] -!- cmorley has quit [Ping timeout: 256 seconds]
[04:28:53] -!- LeelooMinai has quit [Quit: Ex-Chat]
[04:31:38] -!- shurshur has quit [Ping timeout: 252 seconds]
[04:40:37] -!- LeelooMinai has quit [Remote host closed the connection]
[04:41:18] <seb_kuzminsky> kwallace1: in general, pocket numbers are not important to gcode
[04:41:36] <seb_kuzminsky> pocket numbers are important to the toolchanger hardware
[04:43:08] <seb_kuzminsky> programming Tx in gcode requests tool x, and io exposes both the tool number and the pocket number in hal
[04:43:46] <seb_kuzminsky> regarding your question above, tool 3 and tool 33 are different
[04:43:53] <seb_kuzminsky> each toolnumber is its own tool
[04:44:28] <seb_kuzminsky> with a nonrandom toolchanger, the pocket number in the tool table file is almost totally unused inside linuxcnc
[04:45:40] <seb_kuzminsky> with nonrandom, you should really ignore the pocket number and just use the tool number
[04:46:02] <seb_kuzminsky> with random, the pocket number is meaningful, and the pocket number from the tool table file is used in hal
[04:46:29] <seb_kuzminsky> kwallace1: i don't think pocket is "broken", it's just not meaningful on nonrandom tool changers
[04:47:42] -!- skorasaurus has quit [Ping timeout: 256 seconds]
[04:58:46] -!- L84Supper2 has quit [Ping timeout: 276 seconds]
[05:00:59] -!- L84Supper2 [L84Supper2!~TheLarch@unaffiliated/l84supper] has joined #linuxcnc-devel
[05:03:45] -!- Loetmichel has quit [Ping timeout: 244 seconds]
[05:19:32] -!- FinboySlick has quit [Quit: Leaving.]
[05:22:11] -!- dgarr [dgarr!~dgarrett@75-171-116-105.phnx.qwest.net] has parted #linuxcnc-devel
[05:23:46] -!- cmorley [cmorley!~chris@S010600c09fc019c2.no.shawcable.net] has joined #linuxcnc-devel
[05:26:17] -!- cmorley1 has quit [Ping timeout: 245 seconds]
[05:49:23] -!- cmorley1 [cmorley1!~chris@S010600c09fc019c2.no.shawcable.net] has joined #linuxcnc-devel
[05:51:23] -!- Gene34 has quit []
[05:52:02] -!- cmorley has quit [Ping timeout: 256 seconds]
[05:56:57] -!- ve7it has quit [Remote host closed the connection]
[06:00:48] <kwallace1> Seb_kuzminsky: I frame my tool changing opinons with respect to one application I have, my HNC lathe turret, which can have more than one tool at each turret face. Ideally, I would think, I'll define a tool then assign it to a pocket.
[06:01:01] <kwallace1> The tool ID sets up the offsets, tip radius, etc, the pocket sets a method to get the tool out from where it is being stored. Several tools could share the same retrieval method. I considered pocket broken over the years because it has changed behavior, but has never matched my expectation.
[06:01:20] <kwallace1> Andy helped me see that I could just use my changer comp to have tool IDs in the 10s for pocket 1, 20s in pocket 2, etcetera.
[06:01:33] <kwallace1> This should be easy to program, but it would be cleaner and more intuitive to be able to use the pocket feature in the tool table and editor. In fact it would be nice if a pocket ID of M could be manual and Gx for a gang position.
[06:01:49] -!- cmorley [cmorley!~chris@S010600c09fc019c2.no.shawcable.net] has joined #linuxcnc-devel
[06:03:25] -!- Fox_Muldr has quit [Ping timeout: 260 seconds]
[06:03:41] -!- cmorley1 has quit [Ping timeout: 244 seconds]
[06:04:51] -!- Keknom has quit [Quit: Leaving.]
[06:08:20] -!- morfic has quit [Ping timeout: 244 seconds]
[06:40:10] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[06:54:56] -!- AR__ has quit [Ping timeout: 246 seconds]
[07:04:39] -!- kwallace1 has quit [Read error: Connection reset by peer]
[07:05:28] -!- kwallace [kwallace!~kwallace@smb-72.sonnet.com] has joined #linuxcnc-devel
[07:23:50] -!- L84Supper2 has quit [Ping timeout: 256 seconds]
[07:32:03] -!- L84Supper2 [L84Supper2!~TheLarch@unaffiliated/l84supper] has joined #linuxcnc-devel
[07:35:25] -!- tjb1 has quit [Quit: tjb1]
[07:58:49] -!- racycle has quit [Quit: racycle]
[08:35:00] -!- L84Supper2 has quit [Ping timeout: 256 seconds]
[08:38:03] -!- L84Supper2 [L84Supper2!~TheLarch@unaffiliated/l84supper] has joined #linuxcnc-devel
[08:45:44] Cylly is now known as Loetmichel
[08:48:03] -!- mhaberler [mhaberler!~mhaberler@extern-180.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[09:17:45] -!- plushy has quit [Quit: Leaving.]
[09:19:52] -!- kmiyashiro has quit [Quit: kmiyashiro]
[09:37:55] <KGB-linuxcnc> 03chrisinnanaimo 05master af2b830 06emc2 10src/emc/usr_intf/gscreen/gscreen.py * gscreen -fix plot not being reloaded after an origin change.
[09:37:55] <KGB-linuxcnc> 03chrisinnanaimo 05master 16ebe5e 06emc2 10configs/sim/gscreen_custom/ 10industrial.glade 10industrial_handler.py * gscreen config -have the edit button change text
[09:37:59] <KGB-linuxcnc> 03chrisinnanaimo 05master 63fd07e 06emc2 10src/emc/ 10usr_intf/gscreen/gscreen.py 10usr_intf/gscreen/preferences.py * gscreen -optionally get the preference file path from the INI
[09:38:07] <KGB-linuxcnc> 03chrisinnanaimo 05master f8a783e 06emc2 10lib/python/gladevcp/tooledit_widget.py * gladevcp -fix apply button not applying
[09:39:13] -!- rob_h [rob_h!~rob_h@5e0860c9.bb.sky.com] has joined #linuxcnc-devel
[10:06:28] -!- L84Supper2 has quit [Ping timeout: 256 seconds]
[10:09:52] -!- vladimirek has quit [Ping timeout: 256 seconds]
[10:11:00] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[10:19:51] -!- aude has quit [Remote host closed the connection]
[10:23:09] -!- kwallace [kwallace!~kwallace@smb-72.sonnet.com] has parted #linuxcnc-devel
[11:28:40] -!- syyl__ has quit [Ping timeout: 244 seconds]
[11:51:30] -!- kmiyashiro has quit [Quit: kmiyashiro]
[11:52:26] -!- mikegg has quit [Ping timeout: 246 seconds]
[11:57:19] -!- theos has quit [Disconnected by services]
[12:09:33] <KGB-linuxcnc> 03tissf 05v2.5_branch 9169437 06emc2 10docs/html/gcode_fr.html * French doc. best graphic references page
[12:09:33] <KGB-linuxcnc> 03tissf 05v2.5_branch 3a54f20 06emc2 10docs/ 10(5 files in 5 dirs) * French doc. update: fix broken links
[12:37:18] -!- karavanjoW has quit [Quit: KVIrc 4.0.4 Insomnia http://www.kvirc.net/]
[12:52:41] -!- mackerski has quit [Quit: mackerski]
[12:55:24] -!- holgi has quit [Quit: ChatZilla 0.9.89 [Firefox 18.0.1/20130116073211]]
[12:58:17] -!- cncbasher_ [cncbasher_!~quassel@cpc15-hart9-2-0-cust101.11-3.cable.virginmedia.com] has joined #linuxcnc-devel
[13:00:56] -!- Valen has quit [Quit: Leaving.]
[13:57:17] -!- odogono has quit [Read error: Connection reset by peer]
[13:57:17] odogono_ is now known as odogono
[14:22:42] -!- mhaberler has quit [Quit: mhaberler]
[14:24:19] -!- roycroft has quit [Quit: Leaving]
[14:25:24] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[14:56:55] <KGB-linuxcnc> 03tissf 05v2.5_branch 8354fc8 06emc2 10docs/ 10src/gcode/machining_center_fr.txt 10src/gcode/other-code_fr.txt * French doc. update: fix broken links
[15:01:37] -!- dgarr has quit [Quit: Leaving.]
[15:14:40] toudi_ is now known as micges
[15:17:46] -!- micges [micges!~toudi@acwf53.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[15:23:56] -!- capricorn_one has quit [Ping timeout: 252 seconds]
[15:27:42] -!- Gabe_W [Gabe_W!~Gabe_W@99-195-115-155.dyn.centurytel.net] has joined #linuxcnc-devel
[15:28:41] <Gabe_W> Im writing a hal wrapper in cython, but i'm having trouble with the shared memory pointer, could anyone explain how this is required?
[15:28:59] <Gabe_W> Do i need to include hal_priv.h?
[15:30:02] <micges> Gabe_W: did you look at halmodule.cc ?
[15:30:38] <Gabe_W> yes, extensively but my c++ knowledge is zero, i really only know C and python
[15:31:11] -!- Tecan has quit [Quit: live long and phosphor]
[15:31:32] <Gabe_W> i have most of the functions wrapped, but receive a data pointer error
[15:31:58] <Gabe_W> i am debugging right now, comparing it to the _hal.so thats provided
[15:33:55] <micges> I've never used cython, so I can only say that you should follow halmodule
[15:33:58] <mhaberler> do you want to call hal_priv functions from python?
[15:34:41] <micges> I don't think so
[15:34:51] <Gabe_W> no i don't think i will need to
[15:35:08] <mhaberler> just hal functions then?
[15:35:26] <Gabe_W> basically the purpose is i have linuxcnc working with a gui framework called kivy
[15:35:33] <Gabe_W> :)
[15:36:02] <mhaberler> have you considered using the existing boost::python wrapper which is already in the package requirements? there are some usage examples in canonmodule.cc interpmodule.cc taskmodule.cc
[15:36:12] <mhaberler> (master, that is)
[15:36:15] <Gabe_W> i have used that extensively already
[15:36:21] <mhaberler> ah, ok
[15:36:24] <mhaberler> dont like it?
[15:36:36] <Gabe_W> oh no, its great
[15:36:55] <Gabe_W> here is what i want to try and do, i want to tick the gui framework from inside hal
[15:37:27] <mhaberler> 'tick' - what does that mean?
[15:37:43] <mhaberler> signal in some way?
[15:37:44] <Gabe_W> tick the event loop, probing pins and changing values
[15:37:56] <Gabe_W> instead of using a python loop
[15:38:14] <mhaberler> you mean a C or C++ event loop then?
[15:38:33] <Gabe_W> yes gladevcp uses gobject i believe
[15:38:38] <mhaberler> right
[15:38:50] <Gabe_W> i getting away from all gtk dependencies
[15:38:53] <Gabe_W> i am*
[15:38:57] <mhaberler> so like gladevcp but in C or C++?
[15:39:19] <mhaberler> just curious - which GUI framework are you using?
[15:39:24] <Gabe_W> yes, essentially i want to export a function in hal that is called at an interval, but it doesn't wait for a return value
[15:40:06] <Gabe_W> kivy, i already have hal working, using the _hal.so library
[15:40:23] <Gabe_W> its a cython based gui framework
[15:40:29] <Gabe_W> its really neat
[15:40:36] <Gabe_W> more for touch based controlls
[15:40:39] <Gabe_W> controls&
[15:40:42] <Gabe_W> controls*
[15:40:45] <mhaberler> interesting, need to have a look
[15:41:07] <Gabe_W> it supports multiple touch, also works on all frameworks
[15:41:08] <mhaberler> so the gui is c/c++ and using layer is python?
[15:41:43] <Gabe_W> no its all written in cython and python, so basically wrapped c code compiled and called from python
[15:41:57] <mhaberler> its LPGPL3.. aargh. again..
[15:41:58] <Gabe_W> its extremely effecient
[15:42:11] <Gabe_W> whats wrong with LGPL3?
[15:42:31] <mhaberler> incompatible with LinuxCNC as currently licensed
[15:43:02] <Gabe_W> not all linuxcnc code is GPL
[15:43:14] <Gabe_W> the hal module is LGPL
[15:44:02] <mhaberler> right.. well if you get away without linking it might be doable ; anyway thats another issue
[15:44:46] <mhaberler> make me understand: your code is python or C? and you need to call a HAL function not covered in _hal.so ?
[15:45:05] <Gabe_W> yes, im interested in the hal export function
[15:45:26] -!- andypugh [andypugh!~andy2@cpc16-basl9-2-0-cust685.20-1.cable.virginmedia.com] has joined #linuxcnc-devel
[15:45:55] <mhaberler> that's hal_export_funct() ?
[15:46:19] <Gabe_W> yes i could be extremely wrong thoug
[15:46:25] <Gabe_W> lol
[15:46:42] <mhaberler> waht is the goal? give me a simple example
[15:47:26] <mhaberler> hal_export_funct() really associates a name with an RT thread function; I dont think it is meant as an API interface
[15:47:43] <Gabe_W> i want to call a c function from a real time thread
[15:47:45] <mhaberler> sorry 'makes visible'
[15:48:08] <mhaberler> is that C function doing net or file I/O
[15:48:14] <Gabe_W> no
[15:48:32] <mhaberler> any system calls from that function?
[15:48:50] <Gabe_W> it will simply advance the gui framework one frame
[15:49:00] <Gabe_W> or the event loop
[15:49:08] <mhaberler> why dont you use a HAL usercomp?
[15:49:11] -!- micges has quit [Read error: Connection reset by peer]
[15:49:24] toudi_ is now known as micges
[15:49:38] -!- micges [micges!~toudi@acwf53.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[15:49:55] <mhaberler> what do you gain by hooking a HALcomp function with the GUI?
[15:50:21] <mhaberler> I dont understand the linkage between the two
[15:50:32] <Gabe_W> a partnership best friends for life
[15:50:35] <Gabe_W> just kidding
[15:50:53] <Gabe_W> consider it like a gui interrupt
[15:51:02] -!- i_tarzan has quit [Read error: Connection reset by peer]
[15:51:24] <mhaberler> you mean signal an event to the gui such that it can react?
[15:51:44] <Gabe_W> yes, instead of polling pins and parameter's for changes and dispatching a signal
[15:52:02] <mhaberler> I see
[15:52:39] <Gabe_W> is this possible to achieve?
[15:52:54] <mhaberler> well polling is the preferred method because any of the event signaling mechanisms is likely to involve a system call one way or the other, and that will screw RT behavior for good
[15:53:41] <mhaberler> have a look at the HAL widgets python code; it is all polling and very hard to measure in terms of overhead
[15:54:16] <Gabe_W> I have, basically read and know all of the gladevcp source :), i have been using it for a while now. extensively
[15:54:54] <mhaberler> I know; personally I would prefer events/messages over polling state if I could, but I've come around on that question in a realtime context
[15:55:49] <Gabe_W> what if it emits a signal but doesn't care about the return status
[15:55:55] <mhaberler> I have looked into the question extensively - any messaging scheme which involves a system call on the sender side (= RT thread) is likely to be unfeasible
[15:56:05] <mhaberler> the question is how you communicate the signal
[15:56:13] <Gabe_W> it doesn't have to be real time
[15:56:43] <Gabe_W> could be when ever the real time task has time to get to it
[15:56:50] <Gabe_W> not at a set interval
[15:57:16] <mhaberler> slow - who is communicating what to whom here - GUI to hal, hal to GUI or both directions?
[15:57:25] <Gabe_W> hal to gui
[15:57:29] <mhaberler> I see
[15:57:41] <Gabe_W> once the gui recieves the signal it will poll the pins
[15:57:45] <mhaberler> well my recommendation is to use a lock-free queue
[15:57:51] <mhaberler> let me dig out an example
[15:57:55] <Gabe_W> or the function could queue the pin that changed
[15:58:14] <Gabe_W> thank you for your help
[15:58:27] <mhaberler> is that a performance consideration? or functional?
[15:59:32] <Gabe_W> just functional i guess, although i think there would be performance gains especially if implemented in the gui as an interrupt that would stop all non critical task to check the changed state
[15:59:50] <Gabe_W> then return to the gui loop
[16:00:24] <mhaberler> idle event hal polling - is that an option?
[16:01:46] -!- mikegg has quit [Ping timeout: 256 seconds]
[16:01:50] <Gabe_W> yes, im trying to achieve the impossible, not the easy way :)
[16:03:20] <Gabe_W> i already have it polling pins and it works great, but i don't see the point in having a loop running when there is already a task scheduler running. So i thought it would be nice to eliminate the gui polling and fire signals from hal
[16:03:47] <Gabe_W> i guess i could send msgs
[16:03:55] <Gabe_W> and pick them up from stdin
[16:04:01] <mhaberler> so it _is_ a performance theme afterall
[16:05:23] <Gabe_W> yes, i realize the gui can never be real time and if it misses a signal or cant keep up thats wouldn't be an issue. it could just keep pulling them off of the queue
[16:05:25] <mhaberler> note that a lock-free queue does not alleviate the need to poll on the recipient end; it is very fast on both sides but not event based - in which case you'd be back to system calls
[16:06:01] <mhaberler> what would be the message contents? something like 'pin x changed to value y' ?
[16:06:26] <Gabe_W> it doesn't even have to be that much, just the pin name or some identifier. the gui could then poll that pin
[16:07:32] <Gabe_W> but if no pins have changed why should the gui keep polling the pins?
[16:07:37] <Gabe_W> thats what im getting at
[16:08:05] <Gabe_W> seems like a waste of resources to me
[16:08:28] <mhaberler> I suggest you code both alternatives and take timings; pretty sure is's surprising
[16:09:02] <Gabe_W> by that you mean, no gains?
[16:09:19] <mhaberler> you dont get around fetching the value so its just change detection, which is very cheap on integral types - but you incur the signal overhead
[16:09:47] <mhaberler> NB - each system call will add at least a few hundred instructions if not lots more
[16:09:57] <mhaberler> performance gains
[16:10:09] <KGB-linuxcnc> 03andy 05master 5f6cd02 06emc2 10(5 files in 2 dirs)
[16:10:09] <KGB-linuxcnc> Adding the "flash" command to setsserial to allow updating of sserial remote firmware
[16:11:41] <mhaberler> there is no such thing as 'zero overhead messaging' - it just looks conceivably so; it can in fact be quite costly if it goes through the kernel, and most schemes do
[16:12:26] <Gabe_W> i follow
[16:12:50] -!- mikegg has quit [Ping timeout: 244 seconds]
[16:13:13] <Gabe_W> so in the end it could help the gui performance but add to the overall system performance
[16:13:22] <mhaberler> yes, I think so
[16:13:47] <Gabe_W> well damn, i needed a project
[16:14:12] <mhaberler> kivy gladevcp port?
[16:14:26] <Gabe_W> thats virtually done
[16:14:33] <mhaberler> cool
[16:15:43] <Gabe_W> i think it could help with the raspberry pi people too, as kivy will run on that it uses opengl ES
[16:16:11] <Gabe_W> ES stands for Extra Special
[16:16:12] <Gabe_W> lol
[16:16:15] <Gabe_W> just kidding
[16:16:19] <andypugh> I keep meaning to see if the Pi works with Keystick.
[16:16:39] <mhaberler> you mean if it works?
[16:17:06] <Gabe_W> i did get a strictly hal based port of linuxcnc working also
[16:17:26] <andypugh> But I have only even booted my Pi once, so you can probably guess how high up the project queue that is.
[16:17:37] <mhaberler> how did you do replace NML ?
[16:18:32] <Gabe_W> i didn't, but i removed all of the gui's, and components. I have a Machine_Builder program i use that assembles with only the hal components i need
[16:18:54] <Gabe_W> still need Rtapi and NML
[16:19:49] <mhaberler> well actually a remote HAL API with NML out of the looo between motion and the rest is on my project list
[16:20:08] <Gabe_W> i would love to help
[16:20:25] <Gabe_W> i only use HAL in the machines i design and build for customers
[16:20:36] <mhaberler> thats the overall idea with rpi and beaglebone like hardware - make them a motion/HAL/RTAPI machine and driver over network
[16:22:34] <Gabe_W> i agree
[16:23:13] <Gabe_W> a port for rtai to the 3.0 kernel would be a great leap for them
[16:23:35] <Gabe_W> as more and more arm based drivers get added to the kernel
[16:23:38] <mhaberler> however, that is another project stuck at LGPL3 incompatibility - it would use zeromq and protobuf or json
[16:24:07] <mhaberler> the linuxcnc xenomai arm ports exist and work fine
[16:24:20] <Gabe_W> so you can't in no way shape or form use GPL with LGPL?
[16:25:30] <mhaberler> I'm really not the right person to ask; I guess it needs a consensus and quite some work
[16:33:33] <mhaberler> andypugh: keystick sim config comes up fine on the raspberry
[16:37:10] -!- joe9 [joe9!~joe9@c-24-98-97-215.hsd1.ga.comcast.net] has joined #linuxcnc-devel
[16:42:40] <andypugh> Sounds promising
[16:43:13] <andypugh> Probably an adequate UI for a reprap, or similar.
[16:48:59] -!- kwallace [kwallace!~kwallace@smb-1.sonnet.com] has joined #linuxcnc-devel
[16:58:25] <mhaberler> hm, milltask+keystick is < 10% CPU on the rpi, might actually be doable
[17:04:30] -!- Gabe_W has quit [Ping timeout: 244 seconds]
[17:06:40] <cradek> mhaberler: I'm planning to try to release 2.5 this weekend or early next week. After pcw's successful testing of -try2 ferror fix, I'm going to merge that branch, which reverts your changes. I didn't want you to be surprised. For master, maybe we can work together to come up with what we both think is the best fix later.
[17:07:27] <mhaberler> where do you see the improvement?
[17:08:37] <cradek> he says it allows his torque mode test setup to tune up properly
[17:09:07] <mhaberler> and that failed with my patch?
[17:09:23] <pcw_home> Both fixes work
[17:09:50] <mhaberler> there are a few things I'd consider before reverting
[17:10:44] <mhaberler> first, false positives on following error. Since you touch pid exclusively, that is still in place, and cannot be fixed your way - so ferror has to remaing larger than it could be
[17:10:50] -!- mackerski has quit [Quit: mackerski]
[17:11:08] <pcw_home> the PID fix is marginally more correct in that mixed systems (some velocity some torque)
[17:11:10] <pcw_home> both track last commanded position
[17:11:39] <cradek> mhaberler: did you try it? I don't think what you say is true.
[17:11:50] <pcw_home> Actually the ferror problem is fixed via the PID patch
[17:12:30] <mhaberler> does it make the velocity-dependent residual go away?
[17:12:36] <pcw_home> Yes
[17:12:48] <mhaberler> ah, ok, then it's all glorious - go ahead
[17:13:12] <mhaberler> fine with me
[17:13:22] <pcw_home> just a different place t to patch it
[17:13:53] <mhaberler> I wish it could be done in one comp only, but if its an overall improvent, fine
[17:14:39] <pcw_home> yeah thats the tradeoff
[17:15:06] <cradek> what do you mean one comp only?
[17:15:25] <cradek> the -try2 change is like six lines in one place
[17:15:59] <mhaberler> well yes, but you're really compensating for an issue in motion, I think - thats what i meant
[17:16:46] <mhaberler> I dont know if anybody thought through what this means for non-PID configs, if anything
[17:17:02] <cradek> ok, I don't agree with you, I think motion is correct
[17:17:09] <pcw_home> I may be arguable that its an issue in PID behavior (If you have I term it tracks current position not last)
[17:18:21] <cradek> I'm not sure the pid fix is right, but I am sure the problem is with pid, not motion
[17:18:53] <pcw_home> Well index handling is probably a motion problem
[17:19:37] <cradek> yeah the index-enable design does cause pid grief, but that's a totally different issue.
[17:19:43] <pcw_home> (should not need to patch around it in PID)
[17:19:52] <mhaberler> pcw_home: do you see any potential for the current motion code having a detrimental effect on say stepper configs of one sort or the other?
[17:20:58] <mhaberler> that was my point - it is maybe less LOC, but not necessarily minimal interdepence. That's what I dont like about it, but my feelings arent strong enough to do something about it;)
[17:21:10] <pcw_home> I dont really Know. I do know the PID fix will help on stepper-encoder systems
[17:21:59] <mhaberler> not sure a vel mode non-PID setup is possible at all?
[17:22:28] <pcw_home> right
[17:22:44] -!- cncbasher has quit [Ping timeout: 248 seconds]
[17:24:01] -!- cncbasher [cncbasher!~quassel@cpc15-hart9-2-0-cust101.11-3.cable.virginmedia.com] has joined #linuxcnc-devel
[17:25:15] <mhaberler> anyway, I think it's fine; there are much more interesting issues than the this-patch-versus-that-patch question. For instance, what I'd really like to discuss in more depth is motion jitter compensation
[17:25:24] <pcw_home> I do know the current stepper code is not really right for hardware stepgens but thats another can-O-worms
[17:27:42] <cradek> pcw_home: any thoughts about what the pid manpage should say about this option in 2.5? currently it is pretty minimal:
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commitdiff;h=52057aac1ef46c895798b61507d4f2eb2539deef
[17:28:10] <pcw_home> yes for beaglebone or FPGA hardware stepgens or servo/PID systems jitter theoretically can be made unimportant
[17:30:45] <mhaberler> given that motion takes the time anyway for RT delay detection, it is more a question of finding the proper place and method to apply the delta; that I havent found yet
[17:31:46] <mhaberler> not sure it is pre-interpolator or in-interpolator
[17:32:55] <mhaberler> actually we could ask Curtis Wilson; he is interested how linuxcnc develops even if their motion controllers address a diferent space
[17:34:12] <KGB-linuxcnc> 03chris 05v2.5_branch 4e2e667 06emc2 10docs/man/man9/motion.9 10src/emc/motion/control.c 10src/emc/motion/mot_priv.h 10src/emc/motion/motion.c * Revert "motion: introduce motion.ferror-mode"
[17:34:13] <KGB-linuxcnc> 03chris 05v2.5_branch 645ad98 06emc2 10src/hal/components/pid.c * Make pid's idea of following error match motion's
[17:34:17] <KGB-linuxcnc> 03chris 05v2.5_branch 52057aa 06emc2 10docs/man/man9/pid.9 * Document new pid pin
[17:34:23] <KGB-linuxcnc> 03chris 05v2.5_branch df552d0 06emc2 10src/hal/components/pid.c * Fix index thump for pid's previous_target mode
[17:34:29] <KGB-linuxcnc> 03chris 05v2.5_branch 5f7a0bd 06emc2 10src/hal/components/pid.c * make sure the new pid mode defaults to off
[17:34:30] <pcw_home> cradek maybe the use case (tunings with large I term will tend to track current position resulting in large velocity dependent following errors)
[17:34:36] <KGB-linuxcnc> 03chris 05v2.5_branch 0e448bc 06emc2 10docs/man/man9/pid.9 * Merge branch 'pid-ferror-fix-try2' into v2.5_branch
[17:37:16] <cradek> pcw_home: ??
http://pastebin.com/raw.php?i=JiECuTU7
[17:37:49] -!- racycle has quit [Quit: racycle]
[17:39:47] <pcw_home> Yeah thats short and sweet
[17:41:16] <cradek> thanks
[17:41:24] <KGB-linuxcnc> 03chris 05v2.5_branch 879303e 06emc2 10docs/man/man9/pid.9 * use-case for the new pid mode will help explain better.
[17:41:46] -!- martin-_ has quit [Quit: Leaving]
[17:45:05] <pcw_home> Ideally motion would provide P/V/A for the next segment )
[17:45:07] <pcw_home> I think A calculated in PID is one sample late
[17:45:38] <cradek> it does provide P/V currently, but I don't think anyone has tried hooking that to pid
[17:46:13] <cradek> you'd have to make sure motion does it right for jogging/homing, since the vel output was mostly a tp debugging thing
[17:46:49] <pcw_home> That would be the ideal : motion provide forward P/V/A (patched for index) for PID/stepgen/etc
[17:46:52] <cradek> and then fix pid to use V instead of dP/dt for the FF gains
[17:47:15] <pcw_home> and A
[17:47:45] <cradek> not sure if motion really has A natively in the same way it has V
[17:48:24] <cradek> everything's pretty much planned in V-space
[17:49:48] <mhaberler> yes, all three come out of the interpolator
[17:57:09] -!- Gabe_W [Gabe_W!~Gabe_W@99-195-115-155.dyn.centurytel.net] has joined #linuxcnc-devel
[18:04:24] <pcw_home> mhaberler: thanks for your work on getting linuxCNC running under xenomai
[18:04:26] <pcw_home> micges was really struggling to get our Ethernet FPGA cards running with RTAI
[18:04:27] <pcw_home> but says its much easier under xenomai
[18:05:01] <mhaberler> yes, he just told me - I'm very curious on the 7i80 with it, I got me one
[18:05:15] <pcw_home> (so they will probably be xenomai only)
[18:06:19] <mhaberler> could be; it helps a lot that the RTnet key author also works closely on Xenomai, otherwise it'd be a bit out on a branch, yes
[18:06:38] <pcw_home> Yes
[18:06:39] <mhaberler> curious: why RTnet and not EtherCAT? (not that I'm very clueful in this space)
[18:07:03] <pcw_home> Ethercat requires non free firmware on the slave
[18:07:11] <mhaberler> uh
[18:07:25] <mhaberler> Beckhoff stuff?
[18:07:30] <pcw_home> Yes
[18:07:50] <mhaberler> wasnt aware of that, good to know
[18:07:57] <pcw_home> master is free slaves no
[18:08:28] <mhaberler> give away heroin for free in front of the school ;)
[18:09:02] <mhaberler> that suddenly makes me understand why a Siemens guy works on RTnet
[18:09:18] <pcw_home> Ethercat is technically sweet and is probably the future for big interlinked systems
[18:10:24] <pcw_home> but we had a lot less lofty goals (basically a cheap universal pci/parallel port replacement)
[18:11:10] <pcw_home> that still has decent real time capabilities
[18:11:26] <mhaberler> semi-related because it mentioned ethernet as an alternative - really interesting controll application: pulling up the Kursk;
http://www.igh-essen.com/pdf/kursk-nluug.pdf
[18:11:49] <cradek> mhaberler: how close are you guys to a xenomai kernel package that can run the variety of PCs our current kernel runs?
[18:12:21] <mhaberler> very close - John is in polishing mode; actually he might be around - zultrun?
[18:12:34] <cradek> that's awesome
[18:12:37] <mhaberler> debs and rpms fro RHEL
[18:12:52] <mhaberler> zultron - around?
[18:13:52] <mhaberler> he really suffered with this packaging, I dont envy him - he initially laughed when I called it 'Operation Leatherbutt' ; he's come around on it;)
[18:13:54] <cradek> do you have minimal xenomai-enabling changes that we could put on a branch off of 2.5? (wondering what it would take to roll a new cd of ubuntu12 with 2.5.x and 3.x kernel)
[18:14:11] <mhaberler> I had been thinking about that too
[18:14:12] <cradek> yes, packaging kernels is hell
[18:14:26] <pcw_home> Wow raising the Kursk was an incredible project
[18:14:41] <mhaberler> the wave compensators are incredible, yes
[18:15:25] <mhaberler> not sure if its in this article or the german version, but he says zipping a cable releases spring energy to throw a 40t truck 50m into the air
[18:15:49] <zultron> Hi
[18:15:57] <zultron> Reading backlog....
[18:16:27] <mhaberler> cradek: try the rtos-integration-preview3 branch - I'm fairly sure it wont rock the boat
[18:16:32] <Gabe_W> is there a tutorial of installing xenomai on 3.x kernel. I guess i have been out of the loop for a while
[18:16:44] <mhaberler> xenomai.org
[18:17:08] <pcw_home> Sort of reminds me of the tug of war accidents with nylon rope
[18:17:21] <cradek> eek
[18:18:06] <mhaberler> there are two commits still coming which ease on build requirements, like for instance the userland builds dont require kernel headers at all, but thats minor
[18:19:01] <mhaberler> the only thing missing which I am asking for help on is patching up the debian directory, I'm deer in the headlight there
[18:20:25] <zultron> Gabe_W, as for tutorial, check
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?XenomaiKernel
[18:20:57] <Gabe_W> found it thanks to google lol
[18:21:06] <zultron> Cool. ;)
[18:21:19] <zultron> Also, I'm finally going to have a PPA online today.
[18:21:46] <zultron> I think they finally baked up how I wanted them....
[18:23:01] <Gabe_W> good news
[18:23:24] <Gabe_W> i have been developing for a gui framework for a couple months so i haven't been on the up and up with linuxcnc.
[18:23:33] <Gabe_W> but i have integrated it into the gui framework :)
[18:24:30] -!- Holgi has quit [Quit: Bye]
[18:25:05] <cradek> mhaberler: --enable-simulator doesn't appear to give me sim-only. what do I need?
[18:25:27] <mhaberler> yes it should?
[18:25:34] <mhaberler> what does it say?
[18:26:01] <cradek> checking for libudev usability since USERMODE_PCI=yes... configure: error: no -- please install libudev by sudo apt-get install libudev-dev
[18:26:29] <cradek> previous line: checking whether to compile PCI drivers with usermode PCI support... using defaults: platform PC - enable USERMODE_PCI for userland thread styles
[18:26:45] <mhaberler> aja, libudev-dev is linked intp rtapi but drivers arent built I think
[18:26:55] <cradek> I think enable-simulator should mean no pci stuff at all
[18:27:25] <cradek> --enable-simulator --disable-usermode-pci lets configure continue
[18:27:28] <mhaberler> it means no setuid root for rtapi_app so no I/O - but give it a spin first
[18:27:40] <cradek> trying a build
[18:31:02] <mhaberler> are the scripts for the last LivCD build online somwhere? the stuff in the repo is 8.04 I think
[18:32:14] <cradek> mhaberler: I thought you had already talked to moses about that
[18:32:36] <mhaberler> no, that was rtai kernel build we talked about
[18:33:22] <mhaberler> I meant this stuff:
http://git.linuxcnc.org/gitweb?p=infrastructure.git;a=tree;f=livecd;h=e83cd486dd53350fcb3b846bad967526b63e113a;hb=3ad2ac085b99afa5d0938e53aadd82b9a7f4600d
[18:33:44] <cradek> when I have to tweak it, I've always used
https://help.ubuntu.com/community/LiveCDCustomization as a cheat sheet
[18:34:43] <cradek> oh yeah, same kind of stuff. maybe ubuntu didn't have that documentation themselves back in the 8 days.
[18:35:19] <cradek> that page in our git looks like a copy of their wiki page, which is silly
[18:36:07] <mhaberler> any idea how much space was left on the CD last time around?
[18:37:11] <mhaberler> it might make sense to add an RT-PREEMPT kernel too ; it's too early for the universal binary though
[18:37:41] <cradek> http://linuxcnc.org/iso/
[18:37:47] <cradek> here it says 695MB
[18:37:52] <cradek> so some, but not much
[18:38:41] <cradek> err, 693MB
[18:38:53] <mhaberler> hm, the rt kernel has a 41MB deb
[18:39:01] <cradek> that's probably actually quite a bit of uncompressed space
[18:39:36] -!- tjb1 has quit [Read error: Connection reset by peer]
[18:39:41] <mhaberler> what's the limit, 730 MB or so?
[18:39:45] <cradek> well you won't base it on lucid anyway, so this is moot
[18:39:48] <cradek> 700
[18:39:53] <mhaberler> duh
[18:40:52] <mhaberler> have you tried removing stuff from the LiveCD? havent looked at it in ages
[18:41:09] <cradek> sure, it's possible to do that
[18:41:25] <cradek> I don't remember if I removed something last time I tweaked it
[18:41:54] <cradek> probably not if there are 7MB free
[18:42:39] <cradek> very soon we're not going to have to care about 700MB, maybe targeting 1GB sticks is fine
[18:42:52] <cradek> I'm not sure if precise is <700 or not
[18:42:56] <pcw_home> LiveDVD
[18:43:12] <cradek> sticks are better in every way
[18:43:20] <pcw_home> well yes
[18:43:24] <cradek> I bet I don't own a dvd drive
[18:44:25] <cradek> mhaberler: anyway, I suggest not worrying about size until you're sure you have to
[18:44:48] <cradek> worry about making one kernel that boots on lots of PCs and runs linuxcnc+stepgen acceptably
[18:44:56] <cradek> leave the rest to others :-)
[18:45:42] <mhaberler> architectural supervision is advised on some activities..
[18:52:13] <mhaberler> bbl
[18:55:34] -!- tlab has quit [Quit: Leaving]
[19:07:56] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 18.0/20130108033621]]
[19:28:36] -!- mattions has quit [Ping timeout: 256 seconds]
[19:29:48] -!- Tom_L has quit []
[19:33:21] -!- bedah has quit [Quit: Ex-Chat]
[19:43:21] <mhaberler> got it to work?
[19:47:06] -!- tlab has quit [Quit: Leaving]
[20:04:13] -!- sumpfralle has quit [Read error: Operation timed out]
[20:26:26] <Gabe_W> Im going to build a live cd with xenomai today
[20:27:35] <Gabe_W> with the added goodies from the distro i have built for my machines, featuring the linuxcnc logo on boot instead of ubuntu :)
[20:28:16] <zultron> mhaberler, you listening? :)
[20:28:25] <mhaberler> yess
[20:28:34] <mhaberler> oh, ah, all ears
[20:28:37] <zultron> Gabe_W, In about an hour, the xenomai PPA should have finished uploading. See this link for using them:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?XenomaiKernel
[20:28:59] <Gabe_W> i have the build environment awaiting the kernel and patches
[20:29:02] <mhaberler> that was the right answer! (what was the question again.. ;-?)
[20:29:34] <Gabe_W> i am going to rebuild the live cd i made for my customers with xenomai
[20:29:52] <mhaberler> oh, existing work! super
[20:29:52] <Gabe_W> featuring ubuntu 12.04 and no ubuntu logo's :)
[20:30:04] <mhaberler> no unity?
[20:30:31] <zultron> That sounds great. Can you say what's on the live CD? LCNC, I assume? ;)
[20:30:32] <Gabe_W> do you want unity?
[20:30:48] <mhaberler> only looking down a gun barrel
[20:30:53] <Gabe_W> yes its titled LCNC i put some screen shots up about 5 months ago
[20:30:56] <mhaberler> well great, let me know f I can help in any way
[20:31:15] <Gabe_W> my build runs without X
[20:31:22] <Gabe_W> but i will do a stock image
[20:31:36] <mhaberler> hm, what does zjaz
[20:31:47] <mhaberler> that mean - no X, no gui?
[20:31:54] <Gabe_W> i use kivy for gui ontop of the frame buffer via sdl for input
[20:32:30] <mhaberler> do you do preview/progress display in some way?
[20:33:01] <Gabe_W> yes the logo has a progress bar showing ubuntu progress, the boots straight into the software i write
[20:33:15] <Gabe_W> or the kivyvcp if you will
[20:33:33] <mhaberler> I mean linuxcnc preview like in axis or gremlin
[20:33:45] <Gabe_W> no
[20:33:46] <zultron> Ok, so no X desktop like we're used to.
[20:33:57] <Gabe_W> i won't do that on this image though
[20:34:04] <mhaberler> ah
[20:34:05] <Gabe_W> i'll put XORG on it
[20:34:21] <Gabe_W> and im not a fan of unity but if thats what people want
[20:34:52] <zultron> Is unity that funny-looking desktop on Precise?
[20:34:56] <Gabe_W> yes
[20:35:20] <Gabe_W> how about Enligtenment ?
[20:35:25] <Gabe_W> E17
[20:35:26] <mhaberler> well it really doesnt matter, its just a colorfull boot rom for linuxcnc
[20:35:28] -!- mattions has quit [Ping timeout: 256 seconds]
[20:35:38] <mhaberler> minimise non-linuxcnc surprises ;)
[20:35:45] <mhaberler> enough there
[20:35:48] <zultron> I installed Precise for building kernels and testing. Tried out unity for about 2 minutes, ran away, and have been sshing in ever since. :)
[20:36:20] <Gabe_W> then why even use a WM just launch axis on xinit
[20:36:44] <Gabe_W> use slim for login and straight into axis
[20:37:23] <Gabe_W> i needed my machines to be self booting into the software similar to a kiosk
[20:38:28] <mhaberler> its just for evaluation
[20:38:30] <zultron> That's probably good for many users. There are a lot of folks in this community who don't want to compile their own RT kernels, and thus use the LiveCD for install, but still like to build LCNC.
[20:39:00] <mhaberler> right, build-essential git-core etc would be great
[20:39:06] <Gabe_W> yeah i have spent many of hours compiling RTAI
[20:39:16] <zultron> So something with an option for a WM would be especially welcome around here (this is all what I gather, haven't actually asked anyone ;)
[20:39:47] * zultron needs to be careful about speaking for others.
[20:39:54] * micges needs sth like this
[20:40:04] <Gabe_W> i proposed this to people a while ago and know one really seemed that interested in a desktop-less linuxcnc
[20:40:36] <Gabe_W> by desktop i mean the environment of course not the physical machine
[20:40:39] <zultron> Yeah, that's what I would guess, at least for the folks on emc-dev and #linuxcnc-devel.
[20:41:06] <Gabe_W> plus who really puts there tower on the desk any way?
[20:41:52] Gabe_W is now known as WillenCMD
[20:42:38] <WillenCMD> i have been reading licensing info mhaberler
[20:43:07] -!- JT-Shop has quit [Remote host closed the connection]
[20:43:08] <mhaberler> so, whats your take?
[20:43:24] <WillenCMD> the only real difference i can tell is GPLV2 requires you to distribute the source with what you write
[20:43:34] <WillenCMD> LGPL allows you do package binary's
[20:43:57] <WillenCMD> Sell them without providing the source, but only if everything is LGPL
[20:44:28] <WillenCMD> i believe that you can combine the two just have to distribute the source for the GPL code
[20:44:46] <mhaberler> the issue is GPL3 compatibility
[20:45:09] <zultron> Actually, any LGPL source code must be provided, too.
[20:46:03] <mhaberler> we're in col1, row9:
http://www.gnu.org/licenses/gpl-faq.html - see the matrix
[20:46:05] <zultron> However, if you want to *link* to LGPL binaries from your own proprietary software, you may ship binaries without providing your own software's source.
[20:46:36] <mhaberler> 9 or 12, depending on other package
[20:47:08] <zultron> The main diff between GPL and LGPL is the 'linking exception'. Wikipedia or google has more info.
[20:47:36] -!- Gene34 has quit []
[20:48:05] <WillenCMD> I read that , just read the part about GPL plugins
[20:48:13] <zultron> Is there a new issue with licensing?
[20:48:17] <andypugh> I think I should try Unity just so I can claim to like it :-)
[20:48:43] <WillenCMD> what a pain in the A$$
[20:49:06] <WillenCMD> so as long as you provide source for everything you could use both
[20:49:37] <mhaberler> Gabe is iusing a LGPL3 package with linuxcnc, kivy
[20:50:14] <WillenCMD> Haven't paid much attention to the licensing honostly i thought as long as i included the source it would be compliant
[20:50:17] <zultron> Ah, just figured that out, got it.
[20:50:34] <zultron> So yeah, can't distribute binaries at all, period.
[20:50:42] <WillenCMD> thats not a problem
[20:50:50] <WillenCMD> i give everything away
[20:50:52] <zultron> Unless they're not linked. :)
[20:50:55] <cradek> WillenCMD: the problem is combining into one work (binary) incompatible licenses (like GPLv2 and GPLv3) and then you are not allowed to distribute that binary.
[20:51:18] <zultron> Well, probably nobody will try to sue you, so in that sense it's not a problem.
[20:51:20] <cradek> USING them together is fine, combining them for your own use
[20:51:34] <WillenCMD> well i haven't combined anything yet anyway because linuxcnc is GPLV2 so nothing will change
[20:51:45] <zultron> But it's actually violating the license to ship binaries, even if you ship source code along with them.
[20:52:12] -!- vladimirek has quit [Remote host closed the connection]
[20:52:14] <WillenCMD> i don't follow, it has to be compiled in order for it to be allowed?
[20:52:20] <zultron> However, you CAN ship the source without binaries, and users CAN compile it themselves (but they may not then ship the binaries!).
[20:52:49] <WillenCMD> what if i distribute the machine its on lol?
[20:53:04] <WillenCMD> not that it matters i don't charge for the software anyway
[20:53:12] <cradek> WillenCMD: the gplv2 faq has some questions about what it means to "distribute"
[20:53:21] <cradek> whether you charge for the distribution makes no difference
[20:53:41] <WillenCMD> fine they are just borrowing the computer
[20:53:49] <WillenCMD> its a loner
[20:54:07] <WillenCMD> so its mine and i compiled it the source is on it. they are just using it
[20:55:03] <cradek> I thought you were asking questions and I was trying to help you get the right answers. Did I misread the situation?
[20:55:13] <WillenCMD> no i am just kidding
[20:55:31] <WillenCMD> i should probably speak to a lawyer
[20:55:43] <WillenCMD> i have only made 3 machines thus far though
[20:56:23] <zultron> The biggest legal risk would be if you disappeared, and the customers thought they were using something free/libre, but found out that they couldn't find someone else to give them pre-compiled binaries. If they really depended on the software, were really pissed, and thought you were rich, they might sic their lawyers on you.
[20:57:22] <zultron> ('pissed' in the American sense, not the British sense ;)
[20:57:31] <WillenCMD> sometimes i feel open source is more complicated than proprietary
[20:57:41] <WillenCMD> to many licenses to keep track of
[20:58:12] <cradek> there is a reason some people choose to avoid the gpl :-/
[20:58:15] <zultron> Well, there's been a lot of backlash against GPLv3 for this reason, and even v2.
[20:58:26] <cradek> (but that doesn't make proprietary any better imo)
[20:58:53] <cradek> the biggest misfortune we have to deal with for our project is the incompatibility of gplv2 and gplv3.
[20:59:10] <WillenCMD> is gplv2 no longer supported or allowed?
[20:59:18] <WillenCMD> or is gplv3 better?
[20:59:41] <cradek> gplv2 is alive and well and is perfectly fine and is used for lots of projects, including the linux kernel.
[20:59:56] <zultron> GPLv2 *only* (that is, not 'GPLv2 (or later, at your option)') is incompatible with GPLv3.
[21:00:02] <cradek> whether gplv3 is better is a matter of opinion
[21:00:12] <cradek> zultron: yes that is correct, and that's our situation
[21:00:13] <andypugh> I think GPLV3 is aimed squarely at the likes of Tivo, to try to get rid of proprietary hardware running embedded linux
[21:00:14] <zultron> That's the basic issue.
[21:00:43] <zultron> That's one of the claims, yes, 'tivoization'.
[21:01:20] <WillenCMD> can i choose not to license? and allow anyone to do whatever they want, though anything i write in python and use a module would be licensed
[21:01:42] <cradek> WillenCMD: you can certainly put your work in the public domain
[21:02:19] <WillenCMD> I don't really care what anyone does with it... i write it for myself and if it just so happens to benefit someone else thats great
[21:02:20] <cradek> WillenCMD: PD work can be combined with any GPL license and conveyed under that GPL version
[21:02:36] <cradek> sounds like PD is what you want, then
[21:03:40] <zultron> That's right. However, if your software is linking GPLv2 only and GPLv3 software, it doesn't matter what your license is; it is still prohibited by those licenses to distribute binaries.
[21:03:51] <cradek> correct
[21:06:43] <WillenCMD> according to what i read about python psl license it can be distributed as binaries
[21:08:34] -!- HFT has quit [Read error: Connection reset by peer]
[21:10:38] <zultron> I don't know that one. The important thing to consider, and where we're getting in trouble here, is what happens when two licenses are combined in a single project.
[21:11:37] <zultron> For example, if a BSD-like license and a GPLv3 license are combined, the whole work must be conveyed as GPLv3.
[21:12:20] <WillenCMD> yeah i'll talk to the kivy dev's
[21:12:44] WillenCMD is now known as Gabe_W
[21:13:27] <mhaberler> about relicensing?
[21:13:40] <zultron> relicensing what?
[21:13:41] <Gabe_W> yes
[21:13:49] <mhaberler> kivy I assume
[21:14:03] <zultron> Oh, ha ha! Good luck.
[21:14:13] <zultron> That looks like a big project.
[21:14:29] <Gabe_W> im in pretty good with the devs
[21:15:13] <mhaberler> I tried a few: libmodbus, openscam. zeromq, rpcz. One man shows - usually fine. Zeromq - Zero chance. rpcz: Google Lawyers - no chance either.
[21:15:31] <zultron> And because it's perfect for embedded systems, I bet andypugh hit the nail on the head: they want to avoid 'tivoization', where a GPLv2 loophole could be exploited to put kivy on an effectively closed box.
[21:16:01] <mhaberler> you might not get the ones you really need - so that's not a likely succesful approach, and doesnt scale either
[21:16:03] <zultron> Really, LCNC needs to be relicensed.
[21:16:47] <andypugh> There are bits of LCNC where the devs are no longer contactable. (Or, in one case, probably insane)
[21:16:58] -!- joe9 has quit [Quit: leaving]
[21:17:10] <Gabe_W> lol
[21:17:20] <Gabe_W> you shouldn't talk about your self like that andy
[21:17:35] <zultron> Yes, I've heard about some of those problems. However, we should still do what we can, and see what we have left in the end.
[21:17:36] <Gabe_W> ndy
[21:17:38] <Gabe_W> Andy
[21:18:56] -!- joe9 [joe9!~joe9@c-24-98-97-215.hsd1.ga.comcast.net] has joined #linuxcnc-devel
[21:23:42] <Gabe_W> should i include all of the kernel modules?
[21:24:34] <Gabe_W> i think its going to be larger than a cd when im done
[21:24:49] <zultron> Yes, needs to run on everyone's machine.
[21:25:54] <Gabe_W> i have had linuxcnc running on a machine 116 days with no down times yet... pretty damn good
[21:25:59] <andypugh> You don't need _all_ kernel modules to run on every machine, I don't think.
[21:26:24] <zultron> No, but how do you decide what to turn off?
[21:28:54] <zultron> The approach I took, to play it safe, was to take the upstream Ubuntu kernel config, known to support a tremendous variety of hardware, and apply minimal changes to enable Xenomai.
[21:29:57] <zultron> That was after mhaberler and I spent a bunch of time diagnosing why a kernel image ran on three but not four of one user's machines.
[21:30:49] <andypugh> zultron: Yes, that was a complication I chose to ignore :-)
[21:31:42] -!- Gabe_W has quit [Quit: Leaving]
[21:36:03] -!- Gabe_W [Gabe_W!~Gabe_W@99-195-115-155.dyn.centurytel.net] has joined #linuxcnc-devel
[21:46:19] <Gabe_W> build was successful adding other software now
[21:46:36] <Gabe_W> should i compile linuxcnc-dev or use the buildbot?
[21:47:00] <mhaberler> there is no buildbot build for these branches yet
[21:47:29] <mhaberler> there's something missing in the debian dir
[21:47:43] <mhaberler> so - straight from repo, yes
[21:48:53] <Gabe_W> got it
[21:55:05] <andypugh> It might be interesting to see if that LiveCD boots the NCBOX (Vortex86 cpu)
[22:06:15] <Gabe_W> Should i strip everything except for the essentials or leave ubuntu alone and just add xenomai and linuxcnc?
[22:06:42] <Gabe_W> also live installer? and boot to ram option?
[22:08:10] <zultron> Straight from the repo is the only way to get a LCNC that supports Xenomai. But we have no packages yet. How will that work?
[22:14:49] <mhaberler> I would think with your packages it should become very easy to setup a buildbot VM
[22:15:41] <zultron> Yep. I meant, though, how will LCNC be included on Gabe_W's LiveCD if it is not in packaged form?
[22:17:45] <Gabe_W> i can preinstall it
[22:17:56] <Gabe_W> for live use only though
[22:18:01] <Gabe_W> i believe
[22:23:19] -!- DJ9DJ has quit [Quit: bye]
[22:29:56] -!- adb [adb!~IonMoldom@178.211.237.94] has joined #linuxcnc-devel
[22:33:25] -!- mackerski has quit [Quit: mackerski]
[22:53:30] -!- JT-Shop [JT-Shop!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[22:58:44] uwe__ is now known as uwe_
[23:01:57] -!- Gabe_W has quit [Ping timeout: 276 seconds]
[23:02:37] -!- Gabe_W [Gabe_W!~Gabe_W@99-195-242-130.dyn.centurytel.net] has joined #linuxcnc-devel
[23:08:52] <Gabe_W> is there an xenomai python extension?
[23:09:47] -!- odogono has quit [Ping timeout: 252 seconds]
[23:29:03] <mhaberler> to do what, something like rt_task_create or so?
[23:30:02] <zultron> Real time python....
[23:30:19] <mhaberler> yeah right, hot icecream
[23:30:50] <zultron> Well, maybe that means it's possible? Fried icecream is delicious.
[23:31:29] <mhaberler> there are some RTAI python bindings; not sure what state that is in. Maybe it can be warped to xenomai.
[23:31:41] <mhaberler> the API is very similar
[23:37:08] -!- sumpfralle has quit [Read error: Connection reset by peer]
[23:41:19] <Gabe_W> really
[23:41:23] <Gabe_W> i have used the rtapi bindings
[23:41:28] <Gabe_W> took some work to fix them
[23:46:39] -!- ravenlock has quit [Quit: Leaving]
[23:47:38] <skunkworks> So - I should do more xenomai testing?
[23:53:44] -!- bedah has quit [Quit: bye]
[23:55:35] -!- tlab has quit [Quit: Leaving]
