Back
[00:06:13] -!- skorasaurus has quit [Ping timeout: 248 seconds]
[00:09:56] -!- bradsimantel has quit [Quit: bradsimantel]
[00:13:35] -!- bradsimantel has quit [Client Quit]
[00:28:18] -!- logger[mah] has quit [Remote host closed the connection]
[00:28:24] -!- logger[mah] [logger[mah]!~loggermah@ns1.mah.priv.at] has joined #linuxcnc-devel
[00:30:18] -!- RifRaf has quit [Remote host closed the connection]
[00:39:47] -!- Keknom has quit [Quit: Leaving.]
[00:46:51] sliptonic is now known as sliptonic_away
[00:47:33] sliptonic_away is now known as sliptonic
[01:02:11] -!- Nick001-Shop has quit [Ping timeout: 240 seconds]
[01:02:16] Nick001-Shop_ is now known as Nick001-Shop
[01:03:02] -!- Nick001-Shop has quit [Remote host closed the connection]
[01:06:11] -!- plushy has quit [Quit: Leaving.]
[01:10:09] -!- Sendoushi has quit [Remote host closed the connection]
[01:11:39] -!- MercuryRising has quit [Read error: Connection reset by peer]
[01:12:15] -!- ybon has quit [Quit: WeeChat 0.3.8]
[01:15:26] -!- RifRaf has quit [Remote host closed the connection]
[01:20:33] -!- RifRaf has quit [Remote host closed the connection]
[01:25:25] -!- mhkeller has quit [Quit: Page closed]
[01:25:55] -!- gambakufu has quit []
[01:41:21] -!- rob_h has quit [Ping timeout: 248 seconds]
[01:49:13] -!- adb has quit [Ping timeout: 276 seconds]
[02:21:28] -!- ve7it has quit [Remote host closed the connection]
[02:24:51] -!- Jakobud has quit [Ping timeout: 260 seconds]
[02:30:36] -!- Simooon has quit [Remote host closed the connection]
[02:36:22] -!- skunkworks has quit [Ping timeout: 256 seconds]
[03:17:51] -!- skunkworks [skunkworks!~yaaic@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[03:37:05] -!- Connor has quit [Ping timeout: 248 seconds]
[03:45:56] -!- herron has quit [Ping timeout: 246 seconds]
[03:47:08] -!- skunkworks has quit [Ping timeout: 255 seconds]
[03:49:38] -!- andypugh has quit [Quit: andypugh]
[03:54:52] -!- sumpfralle has quit [Quit: Leaving.]
[04:03:21] -!- FinboySlick has quit [Quit: Leaving.]
[04:06:08] -!- RifRaf has quit [Remote host closed the connection]
[04:23:47] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[04:24:16] -!- the_wench has quit [Ping timeout: 272 seconds]
[04:25:54] -!- archivist has quit [Ping timeout: 264 seconds]
[04:38:42] -!- Keknom has quit [Quit: Leaving.]
[04:49:05] <zultron> logger[mah],
[04:49:05] <logger[mah]> zultron: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2013-01-12.html
[04:52:04] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[05:15:07] -!- RifRaf has quit [Read error: Connection reset by peer]
[05:24:24] -!- vladimirek has quit [Remote host closed the connection]
[05:24:38] -!- sumpfralle has quit [Quit: Leaving.]
[05:25:51] -!- sumpfralle1 has quit [Client Quit]
[05:25:55] -!- mhaberler [mhaberler!~mhaberler@extern-185.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[05:30:32] -!- skorasaurus has quit [Ping timeout: 255 seconds]
[05:40:49] -!- sumpfralle has quit [Quit: Leaving.]
[05:49:28] -!- Gene45 has quit []
[05:57:28] -!- ve7it has quit [Remote host closed the connection]
[06:02:04] -!- Fox_Muldr has quit [Ping timeout: 260 seconds]
[06:03:11] -!- sumpfralle has quit [Ping timeout: 240 seconds]
[06:15:39] -!- RifRaf has quit [Remote host closed the connection]
[06:55:29] -!- AR__ has quit [Ping timeout: 248 seconds]
[07:23:42] -!- mhaberler has quit [Quit: mhaberler]
[07:30:49] -!- tjb1 has quit [Quit: tjb1]
[08:07:45] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[08:23:44] -!- RifRaf has quit [Ping timeout: 256 seconds]
[08:33:13] -!- kmiyashiro has quit [Quit: kmiyashiro]
[08:51:58] <KGB-linuxcnc> 03chrisinnanaimo 05master 8d9611b 06emc2 10configs/sim/gscreen_custom/ 10industrial.glade 10industrial_handler.py * gscreen config -update layout including remove mode button
[08:51:58] <KGB-linuxcnc> 03chrisinnanaimo 05master 7e0e0ee 06emc2 10configs/sim/gscreen_custom/ 10industrial.ini 03industrial_postgui.hal * gscreen config -make the industrial spindle display work
[08:52:03] <KGB-linuxcnc> 03chrisinnanaimo 05master d20b1d0 06emc2 10configs/sim/gscreen_custom/industrial_handler.py * gscreen config -make sure industrial defaults to the setup mode
[08:52:09] <KGB-linuxcnc> 03chrisinnanaimo 05master 55f1ad2 06emc2 10src/emc/usr_intf/gscreen/gscreen.py * gscreen -make the tool index and spidle preset dialogs larger
[08:52:17] <KGB-linuxcnc> 03chrisinnanaimo 05master c74eaf5 06emc2 10src/emc/usr_intf/gscreen/gscreen.py * gscreen -lower update rate of widgets
[08:52:24] <KGB-linuxcnc> 03chrisinnanaimo 05master 43ee531 06emc2 10configs/sim/gscreen_custom/ 10industrial.glade 10industrial_handler.py * gscreen config -add an unlock code dialog for the system tab
[08:59:14] <KGB-linuxcnc> 03TODO: deletor 05ferror-mode-master 1183f93 06emc2 04. * branch deleted
[08:59:22] <KGB-linuxcnc> 03TODO: deletor 05ferror-mode-master 1183f93 06emc2 04. * branch deleted
[09:00:53] -!- odogono has quit [Ping timeout: 252 seconds]
[09:14:25] -!- cmorley [cmorley!~chris@S010600c09fc019c2.no.shawcable.net] has joined #linuxcnc-devel
[09:33:44] -!- IchGuckLive [IchGuckLive!~chatzilla@95-89-101-95-dynip.superkabel.de] has joined #linuxcnc-devel
[09:34:12] <IchGuckLive> hi is linuxcnc-dev only available on a realtime pc
[09:34:28] <IchGuckLive> id like to go for a user hal component
[09:34:47] <IchGuckLive> cradek: ? online
[09:52:07] -!- skunkworks [skunkworks!~yaaic@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[09:55:00] -!- skunkworks has quit [Read error: Connection reset by peer]
[09:59:17] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 17.0.1/20121129170341]]
[10:01:33] -!- skunkworks [skunkworks!~yaaic@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[10:05:47] -!- skunkworks has quit [Ping timeout: 252 seconds]
[10:13:31] -!- odogono has quit [Read error: Connection reset by peer]
[10:26:30] -!- rob_h [rob_h!~rob_h@5e0156c0.bb.sky.com] has joined #linuxcnc-devel
[10:32:19] -!- skunkworks [skunkworks!~yaaic@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[10:45:06] -!- skunkworks has quit [Ping timeout: 276 seconds]
[10:57:20] -!- herron has quit [Ping timeout: 255 seconds]
[11:21:38] -!- syyl_ has quit [Ping timeout: 255 seconds]
[11:28:38] -!- odogono has quit [Quit: odogono]
[11:31:40] -!- theos has quit [Disconnected by services]
[11:39:58] -!- mhaberler_ [mhaberler_!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[11:42:01] -!- mhaberler has quit [Ping timeout: 265 seconds]
[11:42:01] mhaberler_ is now known as mhaberler
[12:01:56] -!- RifRaf has quit [Remote host closed the connection]
[12:13:16] -!- cmorley1 [cmorley1!~chris@S010600c09fc019c2.no.shawcable.net] has joined #linuxcnc-devel
[12:13:43] <mhaberler> IchGuckLive: what do you mean by linuxcnc-dev? a package?
[12:14:18] <mhaberler> to develop components you dont need an RT kernel, so yes it should work with a simulator
[12:16:18] -!- cmorley has quit [Ping timeout: 264 seconds]
[12:30:48] -!- dhoovie has quit [Read error: Connection reset by peer]
[13:42:16] -!- syyl__ has quit [Ping timeout: 276 seconds]
[13:52:44] <KGB-linuxcnc> 03jthornton 05v2.5_branch c6bd250 06emc2 10docs/src/common/python-interface.txt * Docs: update stat attributes
[13:59:53] -!- psha [psha!~psha@213.208.162.92] has joined #linuxcnc-devel
[14:00:31] -!- sumpfralle has quit [Quit: Leaving.]
[14:03:50] -!- Holgi has quit [Quit: Bye]
[14:06:13] -!- beawesomeinstead has quit [Quit: Planned maintenance, back soon]
[14:06:15] -!- phillipadsmith has quit [Quit: Planned maintenance, back soon]
[14:17:37] -!- sumpfralle1 has quit [Read error: Connection reset by peer]
[14:22:12] -!- sumpfralle has quit [Ping timeout: 248 seconds]
[14:23:19] -!- darkstar| has quit [Remote host closed the connection]
[14:33:11] -!- andypugh [andypugh!~andy2@cpc16-basl9-2-0-cust685.20-1.cable.virginmedia.com] has joined #linuxcnc-devel
[14:36:15] -!- skunkworks [skunkworks!~yaaic@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[14:42:32] -!- skunkworks has quit [Ping timeout: 246 seconds]
[14:54:47] -!- sumpfralle has quit [Ping timeout: 246 seconds]
[14:57:40] -!- adb [adb!~IonMoldom@178.211.237.94] has joined #linuxcnc-devel
[15:08:56] -!- sumpfralle has quit [Read error: No route to host]
[15:10:00] -!- herron has quit [Ping timeout: 252 seconds]
[15:11:55] -!- sumpfralle has quit [Read error: No route to host]
[15:15:52] -!- sumpfralle has quit [Read error: Connection reset by peer]
[15:17:07] -!- andypugh has quit [Read error: Connection reset by peer]
[15:17:26] -!- andypugh [andypugh!~andy2@cpc16-basl9-2-0-cust685.20-1.cable.virginmedia.com] has joined #linuxcnc-devel
[15:18:10] -!- sumpfralle1 has quit [Read error: No route to host]
[15:23:15] -!- sumpfralle has quit [Ping timeout: 260 seconds]
[15:28:36] -!- sumpfralle has quit [Read error: No route to host]
[15:28:55] -!- maximilian_h [maximilian_h!~bonsai@130.255.104.21] has joined #linuxcnc-devel
[15:31:39] -!- sumpfralle1 has quit [Client Quit]
[15:33:08] -!- maximilian_h has quit [Ping timeout: 248 seconds]
[15:36:00] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[15:53:37] -!- sumpfralle has quit [Ping timeout: 248 seconds]
[15:55:33] -!- IchGuckLive [IchGuckLive!~chatzilla@95-89-101-95-dynip.superkabel.de] has joined #linuxcnc-devel
[15:55:56] <IchGuckLive> hi all -> HAL: ERROR: exit called before init what i am doing wrong
[15:56:11] -!- RifRaf has quit [Remote host closed the connection]
[15:56:36] <IchGuckLive> i call the testscript from doc in halconfuguration
[16:13:48] -!- ybon has quit [Ping timeout: 252 seconds]
[16:15:05] -!- Mr_Wolfsl has quit [Ping timeout: 244 seconds]
[16:21:50] <mhaberler> what about posting the code - how should we guess what you wrote?
[16:26:24] <IchGuckLive> pyvcp_pause.hal:4: execv(dwelloncorners): No such file or directory this is the first error
[16:26:40] <IchGuckLive> loadusr dwelloncorners this is the cal
[16:26:55] <IchGuckLive> out of a hal file not postgui
[16:27:22] <IchGuckLive> the file is named dwelloncorners
[16:27:37] <IchGuckLive> there is no extencion it is chmod 755
[16:28:40] <mhaberler> now is that a module or a executable program
[16:29:02] <IchGuckLive> executalble i made
[16:29:04] <mhaberler> looks like a path problem
[16:29:12] <mhaberler> try absolute pathname
[16:29:29] <IchGuckLive> the path is in the $path var
[16:30:34] -!- pfred1 has quit [Quit: Lost terminal]
[16:30:50] <mhaberler> it is PATH, not path
[16:30:58] <IchGuckLive> B)
[16:31:17] <IchGuckLive> Program 'dwelloncorners' started in direct input but no component shown
[16:33:26] <IchGuckLive> mhaberler: you are wright
[16:33:37] <mhaberler> whew
[16:34:11] <IchGuckLive> if i tipe in a fresh terminal $PATH the path where the file is is not shown
[16:34:44] <IchGuckLive> so it is oly there till the terminal is closed
[16:35:46] <IchGuckLive> bad miss :/usr/games:.:/home/sammel/linuxcnc
[16:35:54] <IchGuckLive> there is a dot
[16:39:44] <IchGuckLive> where is the path entry located in the ubuntu 10.04
[16:40:11] <mhaberler> just install the component where other components are and halcmd will find it
[16:40:29] <IchGuckLive> and where are they
[16:40:36] <mhaberler> rtlib
[16:40:46] <IchGuckLive> on a sim mashine
[16:41:00] <mhaberler> that does not rename the directory , it is just a name
[16:41:41] <mhaberler> even components compiled in a '--enable-simulator' config are stored in rtlib
[16:57:48] <IchGuckLive> im stil searching for rtlib
[16:58:21] <IchGuckLive> find is a hell uin ubuntu
[16:59:30] -!- sumpfralle has quit [Ping timeout: 276 seconds]
[17:03:02] <mhaberler> it is right under the linuxcnc directory
[17:03:18] <mhaberler> are you building linuxcnc yourself or is it a stock installation
[17:03:55] <IchGuckLive> il find it
[17:07:34] <IchGuckLive> "/usr/lib/linuxcnc/modules" no i dont think this is writ
[17:07:42] <IchGuckLive> only so files there
[17:08:59] <IchGuckLive> no i give up
[17:09:54] <mhaberler> if you answered my question, I could help; otherwise, not
[17:10:40] <IchGuckLive> a install via synaptic fromm ppa
[17:10:49] <mhaberler> aha
[17:11:44] <mhaberler> well in that case it seems to be the /usr/lib/linuxcnc/modules directory - is there an abs.so file in there?
[17:11:57] <IchGuckLive> yes
[17:12:07] <mhaberler> you found the right directory
[17:12:29] <mhaberler> abs is one of the hal modules, and in a sim build the binary is named abs.so
[17:14:40] <IchGuckLive> permisson denight so i need sudo to work on
[17:14:48] <IchGuckLive> that is bad
[17:15:07] <IchGuckLive> better to get a free folder into path
[17:15:49] <IchGuckLive> "/home/sammel/linuxcnc/configs/halcomponent there is my work and all my components
[17:16:12] <IchGuckLive> but how to get ths into path without an error
[17:18:57] <JT-Shop> IchGuckLive: I have some code for paths in my tutorials
[17:19:00] <mhaberler> by sudo cp
[17:19:17] <IchGuckLive> mhaberler: i know that
[17:19:31] <IchGuckLive> but all the edits then need to be done under sudo
[17:19:43] <IchGuckLive> JT-Shop: where
[17:20:12] <JT-Shop> http://gnipsel.com/linuxcnc/gui/gui06c.html
[17:20:19] <IchGuckLive> the component is now the only green item in this folder
[17:20:29] <IchGuckLive> green schows executalbles
[17:20:39] <mhaberler> I think it is a compiled-in path; not sure whether you can actually changed it
[17:20:44] <mhaberler> its the module path
[17:21:31] * JT-Shop goes back to stacking firewood
[17:21:39] <mhaberler> ;)
[17:22:05] <IchGuckLive> snow here but al are in the forest with there chainsaws
[17:23:29] <IchGuckLive> mhaberler: my proble is if i now work on heeks and also got the component open and also axis
[17:23:39] <IchGuckLive> under sudo i kill my system
[17:24:06] <mhaberler> then just change the directory permission on /usr/lib/linuxcnc/modules so you can write to it without sudo
[17:24:17] <IchGuckLive> so i need to always at every line do executable and cp to the moduel folder
[17:24:21] <IchGuckLive> a hell of a miss
[17:24:46] <IchGuckLive> i need to overcome thios dot in the PATH
[17:24:53] <mhaberler> its just permissions, and with RTAI kernel modules there is a reason not to make that configurable
[17:24:54] <IchGuckLive> then all is clear
[17:25:51] <mhaberler> what is the problem in doing 'sudo chown sammel /usr/lib/linuxcnc/modules' ?
[17:26:22] <IchGuckLive> ok let me see
[17:28:19] -!- herron has quit [Ping timeout: 260 seconds]
[17:29:08] <IchGuckLive> B)
[17:31:53] <IchGuckLive> pyvcp_pause.hal:4: execv(dwelloncorners): No such file or directory no
[17:32:38] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[17:34:00] <mhaberler> what about posting the code
[17:36:20] <IchGuckLive> http://pastebin.com/DctUrNKj
[17:36:51] <IchGuckLive> loadusr dwelloncorners
[17:37:37] <IchGuckLive> the file as no ending and is named the same as the component in it
[17:39:08] <IchGuckLive> the ini calls POSTGUI_HALFILE = pyvcp_pause.hal
[17:39:22] <IchGuckLive> there is the loadusr comand
[17:39:33] -!- sumpfralle has quit [Ping timeout: 248 seconds]
[17:40:03] <mhaberler> please post pyvcp_pause.hal
[17:40:24] <mhaberler> the module loads perfectly fine if stored in the module dir
[17:41:30] -!- sumpfralle1 has quit [Ping timeout: 264 seconds]
[17:41:42] <IchGuckLive> http://pastebin.com/11U4D56v
[17:41:47] <mhaberler> if the name is shortened
[17:42:01] <mhaberler> I think your halcomp name is too long for some reason
[17:42:21] <mhaberler> if I rename it to 'foo' it works
[17:42:23] <IchGuckLive> ok
[17:42:24] -!- sumpfralle2 has quit [Ping timeout: 244 seconds]
[17:43:09] <IchGuckLive> no ending as py or whatever
[17:43:23] <mhaberler> no ending
[17:45:43] <IchGuckLive> pyvcp_pause.hal:4: execv(dwelloc): No such file or directory
[17:46:03] <IchGuckLive> let me try 3 letters
[17:46:05] <mhaberler> where did you store dwelloc
[17:46:09] <mhaberler> not needed
[17:46:37] <IchGuckLive> at the "/usr/lib/linuxcnc/modules" and with chod +x
[17:48:14] <IchGuckLive> its not in the path
[17:48:26] <IchGuckLive> "bash: /opt/paraviewopenfoam3120/bin:/home/sammel/OpenFOAM/sammel-2.1.1/platforms/linuxGccDPOpt/bin:/opt/site/2.1.1/platforms/linuxGccDPOpt/bin:/opt/openfoam211/platforms/linuxGccDPOpt/bin:/opt/openfoam211/bin:/opt/openfoam211/wmake:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:.: No such file or directory
[17:48:27] <IchGuckLive> "
[17:48:42] -!- sumpfralle3 has quit [Ping timeout: 264 seconds]
[17:48:43] <mhaberler> it need not be on the path - halcmd needs to find it which is the problem
[17:49:11] <mhaberler> I dont have rtlib on the path and it does load
[17:49:28] <mhaberler> however, I cannot help you with a binary you got from some ppa - I cannot tell how it was built
[17:49:50] <IchGuckLive> ok
[17:50:12] <IchGuckLive> i updated daily
[17:50:35] <IchGuckLive> we will see
[17:50:46] <mhaberler> which ppa
[17:52:02] <IchGuckLive> http://buildbot.linuxcnc.org/ lucid master-sim
[17:52:34] <mhaberler> ah, the linuxcnc repo
[17:52:45] <IchGuckLive> B)
[17:52:58] <mhaberler> very hard to guess from what you said
[17:55:07] <mhaberler> I think the documentation is wrong here wrt PATH:
http://www.linuxcnc.org/docs/devel/html/hal/halmodule.html
[17:57:11] <IchGuckLive> it is not wrong it is just oncomen for me to work under sudo with 2-4 differen system files open
[17:57:22] <IchGuckLive> it has to work without sudo
[17:57:26] <mhaberler> it does in fact work if you put the halcomp into rtlib (the modules diir)
[17:57:59] <mhaberler> it looks like normally user HALcomps go into the linuxcnc bin directory
[17:58:23] <IchGuckLive> let me try it under a Git
[17:58:33] <mhaberler> this will change nothing
[17:58:37] <mhaberler> try this:
[17:58:42] <IchGuckLive> "/home/sammel/xlinuxcnc/rtlib/toggle.so
[17:58:52] <mhaberler> what is that?
[17:58:57] -!- herron has quit [Ping timeout: 248 seconds]
[17:58:59] <IchGuckLive> a git pull
[17:59:05] <IchGuckLive> igot 4 of this here
[17:59:19] <mhaberler> well fine, lets get one to work, not four
[17:59:28] <IchGuckLive> "/home/sammel/xlinuxcnc-sculpA/rtlib/toggle.so
[17:59:39] <mhaberler> what are you telling me?
[17:59:48] <IchGuckLive> there all compiled runinplace no install
[18:00:06] <mhaberler> I still dont understand what that has to do with your problem
[18:00:15] <IchGuckLive> nothing
[18:00:57] <mhaberler> so recap: you have a global linuxcnc install from buildbot, and 4 local git repos. fine. Now how do you select which one you run?
[18:01:51] <IchGuckLive> by desktop sh
[18:02:40] -!- skunkworks has quit [Ping timeout: 240 seconds]
[18:04:22] <mhaberler> ok, try this:
[18:04:26] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[18:04:39] <mhaberler> create a local bin directory like /home/sammel/bin
[18:05:34] <mhaberler> add it to your PATH by editing .profile which should have a statement where PATH is set
[18:05:43] <mhaberler> start a shell window
[18:05:56] <mhaberler> now /home/sammel/bin should be on your path
[18:06:19] <mhaberler> put the halcomp there - I have no idea why that doesnt work in the global install case in rtlib
[18:08:48] <IchGuckLive> emcTaskInit: using builtin interpreter
[18:08:50] <IchGuckLive> pyvcp_pause.hal:31: Pin 'dwelloc.time_to_dwell' does not exist
[18:08:52] <IchGuckLive> pyvcp_pause.hal:4: execv(dwelloc): No such file or directory
[18:08:53] <IchGuckLive> Shutting down and cleaning up LinuxCNC...
[18:08:54] <IchGuckLive> no
[18:09:46] <IchGuckLive> let me put it into a openfoam dir
[18:13:00] -!- p0g0 has quit [Read error: No route to host]
[18:13:07] -!- kwallace [kwallace!~kwallace@smb-75.sonnet.com] has joined #linuxcnc-devel
[18:16:42] <IchGuckLive> wait i got it
[18:17:10] -!- herron has quit [Ping timeout: 240 seconds]
[18:21:52] <IchGuckLive> B) YES
[18:22:11] <IchGuckLive> its now in usr games
[18:22:18] -!- tjtr33 has quit [Ping timeout: 264 seconds]
[18:22:18] <IchGuckLive> with chanch owner
[18:22:42] -!- sumpfralle has quit [Ping timeout: 276 seconds]
[18:24:42] -!- bpuk has quit [Remote host closed the connection]
[18:25:13] -!- Sendoushi has quit [Remote host closed the connection]
[18:28:52] -!- skunkworks [skunkworks!~yaaic@207.229.236.209] has joined #linuxcnc-devel
[18:31:19] <IchGuckLive> ok it works
[18:35:31] <IchGuckLive> is the direction of the float number past forom pyvcp out pin to halcomponent in <= or =>
[18:35:39] <IchGuckLive> does this matter
[18:35:43] <IchGuckLive> from to
[18:37:17] <IchGuckLive> net dtime pyvcp.pause.f => dwelloc.timetodwell
[18:38:26] <IchGuckLive> pyvcp_pause.hal:24: Pin 'pyvcp.pause.f' does not exist
[18:38:59] Connor1 is now known as Connor
[18:41:16] -!- skunkworks has quit [Ping timeout: 276 seconds]
[18:41:26] <IchGuckLive> -f not .f i need a rest
[18:41:36] -!- gurumelo has quit [Ping timeout: 264 seconds]
[18:42:18] -!- sumpfralle has quit [Quit: Leaving.]
[18:44:19] -!- MarkusBec has quit [Read error: Connection reset by peer]
[18:46:00] <KGB-linuxcnc> 03chris 05pid-ferror-fix-try2 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"
[18:46:00] <KGB-linuxcnc> 03chris 05pid-ferror-fix-try2 645ad98 06emc2 10src/hal/components/pid.c * Make pid's idea of following error match motion's
[18:46:04] <KGB-linuxcnc> 03chris 05pid-ferror-fix-try2 52057aa 06emc2 10docs/man/man9/pid.9 * Document new pid pin
[18:51:32] -!- MarkusBec has quit [Excess Flood]
[18:52:24] -!- herron has quit [Ping timeout: 264 seconds]
[18:55:27] -!- Ranewen has quit [Quit: Leaving]
[18:56:18] <IchGuckLive> it simply does not give me a passtrue with the floats
[18:56:30] <IchGuckLive> maybe the one is loaded befor the other
[18:57:40] <mhaberler> cradek: looks like your fix makes more sense; I'm curious which results folks with torque-mode drives have; probably Peter needs to have a look, I can do that only in sim too
[18:58:34] <cradek> mhaberler: yeah I'm anxious to hear from pcw with real results too
[18:59:10] <cradek> mhaberler: I probably also need to test pid's index-enable goop too
[18:59:22] <mhaberler> there's a long thread on the forum, you might want to tell them
[18:59:23] <pcw_home> It seems cleaner in that the fix in motion may effect other things
[18:59:33] <cradek> hm, pid also has ddt inputs that I didn't think about
[18:59:34] <mhaberler> why index-enable?
[18:59:47] <cradek> mhaberler: if you could also squint at pid.c I'd appreciate it
[18:59:54] <mhaberler> sure
[19:00:25] <cradek> mhaberler: pid has special handling for when the command jumps (at index) so as to not screw up the internal ddts
[19:00:32] <mhaberler> aja
[19:00:56] <pcw_home> DDT (well everything in PID) should also be done on the pipelined data
[19:01:05] <cradek> mhaberler: aka the "index thump" problem
[19:01:17] <cradek> pcw_home: yes I think it is now
[19:01:22] <IchGuckLive> net dtime pyvcp.pause-f => dwelloc.dwtime
[19:01:24] <IchGuckLive> net ddeg dwelloc.deg <= pyvcp.edgedegre-f
[19:01:25] <IchGuckLive> non does work is there atimedelay in loading if i # hhok them out then the pins are there in hal-show
[19:01:39] <pcw_home> I can try on Monday
[19:02:14] <cradek> pcw_home: thanks, appreciate it
[19:03:39] -!- sumpfralle1 has quit [Ping timeout: 276 seconds]
[19:07:47] -!- christian___ has quit [Quit: ChatZilla 0.9.89 [Firefox 18.0/20130108033621]]
[19:08:08] <mhaberler> hm, there could be a chance of a error thump on startup when prev_cmd is zero ; maybe first time around it should be initialized to cmd or ignored
[19:09:07] -!- bpuk_ has quit [Read error: No route to host]
[19:09:14] <mhaberler> we should think about a different method of testing such processes; in continuous mode it is very easy to overlook startup issues
[19:09:17] -!- herron has quit [Read error: Operation timed out]
[19:09:54] <mhaberler> one way to do it is not to use hal threads but a python harness around it where you can call thread functions in a controlled way
[19:10:57] <mhaberler> It actually isnt that difficult, the most hairy part is the sequencing of usrmotif and thread functions
[19:11:03] <cradek> mhaberler: on the very first period when pid is being used for motion, I bet it is always disabled. does prev_cmd follow command while disabled?
[19:11:06] <mhaberler> but thats a different issue
[19:11:14] <mhaberler> letssee
[19:11:58] <cradek> yes it does
[19:12:03] <mhaberler> IMO it always follows command
[19:12:15] <mhaberler> yes, line 379
[19:13:05] <cradek> I bet startup is ok then
[19:14:38] <mhaberler> assume cmd=10, prev_cmd=0, feedback=10, dont you get a thump of 10 in the delayed scenario?
[19:14:40] <cradek> mhaberler: ooh, at line 379, D calculation is totally broken now
[19:14:54] -!- sumpfralle has quit [Ping timeout: 265 seconds]
[19:14:56] <cradek> by which I mean it's always 0
[19:15:23] <cradek> argh
[19:16:12] <mhaberler> I wonder if there is a way to halscope the initial phase
[19:16:53] <cradek> er no it's not?
[19:19:10] <IchGuckLive> ok i give up for today real hard to do on halcomponent
[19:19:23] <IchGuckLive> pyvcp to haluserpython
[19:19:34] <IchGuckLive> no way for 4hr now
[19:19:37] <mhaberler> maybe there is a different way to grind the index homing cat - leave feedback as continuous and apply an offset
[19:19:42] <IchGuckLive> BY
[19:19:47] -!- IchGuckLive [IchGuckLive!~chatzilla@95-89-101-95-dynip.superkabel.de] has parted #linuxcnc-devel
[19:20:21] <mhaberler> the jump in feedback creates all sorts of problems, but that jump aint a jump, its setting an offset between encoder and switch
[19:20:59] <mhaberler> or is there a requirement which says index switch closed must imply encoder pos 0
[19:21:00] <cradek> yeah it's a pain but it was working right (command and feedback both jump together). do you think I broke it?
[19:21:09] -!- tjb1_ has quit [Client Quit]
[19:21:22] <mhaberler> no, I'm just musing about the way to address it
[19:21:47] <mhaberler> maybe there's a way not to have it jump at all
[19:23:12] <cradek> you'd have to change every hardware encoder driver
[19:23:40] -!- tjb1 has quit [Ping timeout: 260 seconds]
[19:23:50] <mhaberler> maybe the cleaner way is to correlate index 0 with a nonzero fractional revolution
[19:24:05] <mhaberler> not index 0, switch
[19:25:30] <mhaberler> I need to read up on how that exactly works, otherwise it's thin ice
[19:25:43] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 17.0.1/20121129170341]]
[19:26:51] -!- RifRaf has quit [Remote host closed the connection]
[19:26:58] <cradek> I'm not following what you're thinking about
[19:27:24] <cradek> is this an aside from whether I've broken pid today?
[19:28:00] -!- tjb1 has quit [Client Quit]
[19:29:18] <kwallace> For front or back tool lathes, the X plus could be North or South. Should the tool orientation map also flip with the plus X direction?
[19:29:43] <mhaberler> semi - I think for keeping pid simple it would be best not to have cmd and feedback 'jump' at all; in reality there's no jump, its a continuous movement but with a re-interpretation of position; I would think achieving that makes the delayed-by-one-cycle simpler too
[19:29:53] <cradek> kwallace: look at the arrows marked +X and +Z on that map, and ignore everything else
[19:30:41] <mhaberler> but let me read up on the exact process, this is conjecture as of yet
[19:31:02] <cradek> mhaberler: that's how the encoder drivers work. the only other way they could possibly work is to have them capture the index position and present it separately
[19:31:34] <pcw_home> HostMot2 hardware works that way, not sure about others
[19:31:58] <mhaberler> then I might have misunderstood the problem - are we talking about the homing phase, or the phase until-index-first-seen?
[19:32:14] <cradek> yes inside the drivers, some of them may use capture but present reset externally to match the linuxcnc canonical encoder interface spec
[19:32:31] <pcw_home> Yep
[19:32:32] <cradek> mhaberler: the search for index phase
[19:33:06] <mhaberler> that is after startup and before the first index pulse on the encoder has been seen, correct?
[19:33:23] -!- JT-Shop has quit [Ping timeout: 260 seconds]
[19:33:29] -!- jthornton has quit [Ping timeout: 255 seconds]
[19:33:39] <cradek> not exactly - before the first index pulse that we've asked to be detected
[19:34:03] <mhaberler> because of the index-enable handshake?
[19:34:09] <cradek> yes
[19:34:14] <mhaberler> ah
[19:34:42] <cradek> indexes happen all the time and are ignored by the hardware and/or driver if you haven't requested an index search
[19:36:18] <mhaberler> ok, I stop at this point without further reading, makes no sense
[19:36:26] -!- emel has quit [Excess Flood]
[19:39:34] -!- JT-Shop [JT-Shop!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[19:41:37] -!- JT-Shop has quit [Read error: Connection reset by peer]
[19:41:47] <pcw_home> so does this mean the index enable edge detect needs to be pipelined as well?
[19:42:18] <cradek> pcw_home: I don't think so but that stuff is why I asked for mhaberler's additional eyes :-)
[19:43:47] -!- jthornton [jthornton!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[19:43:52] -!- JT-Shop [JT-Shop!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[19:43:58] <cradek> hm, servo-sim has index homing - wonder if I can manage to test it there
[19:44:49] -!- paideia has quit [Quit: Leaving]
[19:45:17] <pcw_home> thump should be pretty obvious
[19:52:42] <cradek> sim tests are inconclusive
[19:53:37] <cradek> I think it might be wrong but I had trouble identifying the thump I know should be there when I unhook index-enable.
[19:53:40] -!- paideia has quit [Quit: Leaving]
[19:53:44] <cradek> so I don't trust it
[19:53:57] <cradek> I suppose the simulated motors aren't very realistic
[19:54:12] -!- herron has quit [Ping timeout: 264 seconds]
[19:54:13] -!- JT-Shop has quit [Read error: Connection reset by peer]
[19:54:13] -!- jthornton has quit [Read error: Connection reset by peer]
[19:54:40] <pcw_home> Yeah I can try on a real motor on Monday
[19:54:57] -!- JT-Shop [JT-Shop!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[19:55:03] -!- jthornton [jthornton!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[19:55:40] <cradek> thanks, I guess there's no hurry, we only need it right before the next 2.5.x.
[19:57:14] <pcw_home> Thanks for figuring out a better place for the patch, much less invasive
[19:57:25] <cradek> welcome
[20:01:02] -!- psha has quit [Quit: Lost terminal]
[20:10:48] -!- joe9 has quit [Quit: leaving]
[20:16:21] -!- devilindisguise has quit [Quit: leaving]
[20:21:16] -!- XiXora has quit [Remote host closed the connection]
[20:24:00] <mhaberler> what is actually the point in time for which ferror is supposed to be valid? that's a tad unclear to me.
[20:27:10] -!- sumpfralle has quit [Ping timeout: 252 seconds]
[20:27:18] <mhaberler> and: why do we have it - why dont we trip on pid.error too large?
[20:27:35] -!- cmorley [cmorley!~chris@S010600c09fc019c2.no.shawcable.net] has joined #linuxcnc-devel
[20:27:37] <mhaberler> ok, not everybody has a pid, fine - but assume there were
[20:27:40] <pcw_home> PID is not universale
[20:28:37] -!- cmorley1 has quit [Ping timeout: 248 seconds]
[20:29:04] <mhaberler> assume for a moment it all were pid. What would change if a following error wouldnt be caused by motion but pid?
[20:29:40] -!- JT-Shop has quit [Ping timeout: 240 seconds]
[20:30:12] -!- jthornton has quit [Ping timeout: 264 seconds]
[20:30:58] <mhaberler> and: does ferror serve any other purpose than to trip the following error condition?
[20:31:32] <pcw_home> Not really (but it is an important safety feature)
[20:31:43] -!- JT-Shop [JT-Shop!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[20:32:30] -!- jthornton [jthornton!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[20:32:57] <mhaberler> sure. But now assume a stepper. what would be different if we tripped an ferror condition by the difference between commanded position and stepper position, just using a window of abs(cmd-pos)?
[20:33:19] -!- JT-Shop has quit [Read error: Connection reset by peer]
[20:33:20] -!- jthornton has quit [Read error: Connection reset by peer]
[20:33:24] <mhaberler> maybe the whole problem arises because this is done in the wrong place
[20:34:16] <pcw_home> maybe so
[20:36:03] <mhaberler> cradek: still around?
[20:38:46] -!- jthornton [jthornton!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[20:38:55] -!- JT-Shop [JT-Shop!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[20:43:57] -!- cmorley1 [cmorley1!~chris@S010600c09fc019c2.no.shawcable.net] has joined #linuxcnc-devel
[20:46:13] -!- JT-Shop has quit [Ping timeout: 248 seconds]
[20:46:14] -!- jthornton has quit [Ping timeout: 252 seconds]
[20:46:38] -!- jthornton [jthornton!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[20:46:45] -!- JT-Shop [JT-Shop!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[20:47:22] -!- cmorley has quit [Ping timeout: 276 seconds]
[20:49:30] <pcw_home> Actually the ferror in motion patch seems better in some ways as it does not affect the actual motion profile (PID patch delays profile one sample)
[20:51:32] <KGB-linuxcnc> 03jthornton 05v2.5_branch 6eecfd0 06emc2 10docs/src/common/python-interface.txt * Docs: update stat attributes
[20:54:16] <mhaberler> IMO there is no point in mutually fixing pid or motion to accommodate the other, the ferror computation and tripping should move elsewhere - issue closed
[20:58:11] <cradek> mostly a question for pcw since his observations drove this whole thing: is making the ferrors agree the actual goal? if we ignore motion, is there a problem in pid itself we are trying to solve? or is it entirely a problem with getting motion to not trip at weird times when the pid tuning looks good?
[20:58:28] -!- bedah has quit [Ping timeout: 248 seconds]
[20:59:01] -!- rizo has quit [Quit: Leaving]
[20:59:39] <mhaberler> I understood it to be the latter
[20:59:47] <cradek> I am positive the motion change is wrong, because it calculates ferror based on a position the system has had no time to reach because it has not yet been told to go there!
[21:00:09] <cradek> unfortunately the pid change might also be wrong because it adds delay which is always bad for tuning
[21:00:23] <pcw_home> I think making ferror agree with PID (or pretty much any feedback system) errors is the goal
[21:00:32] <mhaberler> that brings it back to my question: for which point in time ferror is meaningful?
[21:01:09] <mhaberler> by definition a change in commanded position will cause a spike in ferror, that's quantisation and there's nothing wrong with that
[21:01:23] <cradek> yes I agree
[21:02:06] <cradek> I think ferror for this period = last period's command vs this period's position is the only definition that makes any sense
[21:02:09] <mhaberler> what is ferror actually supposed to mean _different_ that abs(cmd-actual)
[21:02:54] <cradek> personally I'd like jmk to ponder that and opine
[21:03:18] <pcw_home> its tricky if you look a at it as a static sampled system, I agree with cradek
[21:03:19] <pcw_home> but for a system in high speed motion this doesnt work
[21:04:24] <cradek> the pid error is what drives motion and I bet it's true that it worked correctly before because of what andy said
[21:05:05] <cradek> I bet its internal error used to calculate gains should be as before -- but its external reported error should be the one that makes sense in the quantized world
[21:05:46] <cradek> mhaberler: what you say is right - at the beginning of the servo cycle you change position which makes ferror jump to a high value, and then pid is supposed to minimize it during the time before the next change
[21:06:00] <cradek> what we should measure is how well that succeeds
[21:07:00] <cradek> now I think my change should affect ONLY the pid.n.error output, and not any internal gain calculations
[21:07:43] <cradek> argh
[21:08:06] <cradek> what's our goal here? why not just tune pid by watching axis.n.ferror? wouldn't it all be fine then?
[21:08:35] <pcw_home> Thats what fails
[21:08:38] <mhaberler> avoiding ferror trips for certain configs
[21:08:51] <cradek> pcw_home: can you tell me why?
[21:10:03] <pcw_home> yes, because a well tuned PID loop will minimized its error and if the PID error is 0 the Ferror is
[21:10:05] <pcw_home> velocity*sampleperiod
[21:10:39] <mhaberler> ferror keeps a residual error proportional to speed
[21:11:02] <mhaberler> that's where the trips come from
[21:11:03] <pcw_home> so if you are moving at 600 IPM and 1 KHz sample ferror will show 10 mills of error
[21:12:12] -!- bpuk has quit [Quit: Leaving]
[21:14:07] <pcw_home> All this requires to go bad is using some integral term so
[21:14:09] <pcw_home> the steady state error is nulled during motion
[21:14:27] <cradek> so the practical problem is in some setups you can't come up with a tuning that minimizes axis.n.ferror, you can only tune to minimize pid.n.error?
[21:15:00] <mhaberler> that's what I understood
[21:15:00] <cradek> with velocity mode you can minimize your choice of errors by turning the ff1 knob
[21:15:21] <pcw_home> Yes thats why in some respects mhaberlers patch is better since it only affects ferror calculation
[21:17:13] <cradek> mhaberler's patch assumes the machine always moves at constant velocity. I'm sure it's not a correct fix and I bet it has other practical problems for tuning, as seen in my test plot.
[21:18:07] <pcw_home> yes if you have tuned velocity mode you can see that FF1 allows you to get an error proportional to velocity (as long as you dont use any integral term)
[21:18:59] -!- joe9 [joe9!~joe9@c-24-98-97-215.hsd1.ga.comcast.net] has joined #linuxcnc-devel
[21:19:20] <pcw_home> Its a first order approximation which Is better than nothing
[21:19:28] <mhaberler> re constant velocity: I dont see that - it changes the point in time where the max ferror happens, imo to the right moment, namely exactly when the new commanded pos is output, which coincides with the maximum of quantisation error
[21:22:13] <cradek> I don't see how it can make any sense to compare a new command to the current feedback. I don't see any reason to expect them to match. It seems like it's measuring a totally wrong thing.
[21:22:47] <mhaberler> there is no such thing as zero quantisation error in a sampled system
[21:22:49] <cradek> maybe I don't understand your change
[21:23:09] <mhaberler> I think we have a terminology issue, ferror is a dog of a term
[21:23:14] <pcw_home> But a PID loop will make them match...
[21:23:57] <pcw_home> because thats what it works on
[21:24:01] <cradek> pcw_home: if it's tuned well you hope so. but you should measure the success of that - that's the point isn't it?
[21:24:30] <mhaberler> terms which make sense in this context are: the quantisation error as the sawtooth shape between ideal path and step curve; then we have the actual curve as per feeback
[21:24:44] <pcw_home> Yes but if PID error is 0 ferror can be large
[21:27:05] <mhaberler> there is no point in viewing ferror as a constant during a cycle - it is a continuous shape, and it is offset by the following error; this is the space we're dabbling in
[21:27:18] <mhaberler> no point in looking at a pin value constant during a cycle
[21:27:20] <cradek> I think pid needs current command vs current feedback to drive its output for the upcoming time slice. I think motion needs current feedback vs last command to see how well the machine is getting to the command positions during the time slices.
[21:28:42] <mhaberler> what is wrong in taking current command minus current feedback as tracking quality indicator?
[21:29:10] <pcw_home> I think thats the best
[21:29:25] <cradek> because they are from the same time instant so you have no right to expect the machine to be there yet
[21:29:40] <cradek> that's going to have error proportional to velocity - in fact it's exactly what we have today
[21:30:02] <pcw_home> Nope not if PID is tuned
[21:31:06] <cradek> ok we have to define "current command". is it right after we change it, or is it after we changed it and then let a time slice elapse?
[21:31:08] <mhaberler> yes, you have the right to expect it there, especially if on a straight line
[21:31:54] <mhaberler> it is right in the moment it is set, and invalid infinitesimally short thereafter
[21:31:55] <cradek> mhaberler: the "on a straight line" assumption is what I was getting at earlier
[21:32:20] <cradek> er by "right" I meant "immediately", sorry for imprecision
[21:32:39] -!- Loetmichel has quit [Ping timeout: 240 seconds]
[21:33:47] <mhaberler> I think I'll parachute in Amit and have him comment, he's pretty sharp on that kind of stuff
[21:35:24] <cradek> I think both fixes are wrong, so far :-/
[21:35:41] <mhaberler> maybe the gotcha is that pid.n.error == 0 doesnt imply no motion
[21:36:09] <pcw_home> just keep in mind that a PID loop will minimize its error (and it must work on current feedback vs current command)
[21:36:10] <cradek> pid.n.error is used only by human eyeballs, right?
[21:36:19] -!- bpuk has quit [Remote host closed the connection]
[21:36:23] <pcw_home> Yes it may be 0 at full speed
[21:37:27] <pcw_home> probably only used for tuning to avoid the ferror issues
[21:37:46] <cradek> ideally at full speed, the internal pid error will spike at the beginning of a time slice, then by the end of the slice it will have been driven to zero
[21:38:02] <L84Supper> not to be a distraction in the middle of this discussion but when would we need to have a new kernel working with LTS 12.04?
[21:38:10] <cradek> we probably want to report that final value to the human eyeballs as pid.0.error
[21:38:24] <cradek> L84Supper: I don't understand your question
[21:38:24] <L84Supper> that includes xenomai support?
[21:38:31] <mhaberler> cradek: actually I dont think it is so
[21:38:35] <pcw_home> not really the intergal term works on a longer time base
[21:38:45] <pcw_home> integral
[21:38:50] <mhaberler> I think it maximizes at the edges, and tends to 0 in between
[21:38:57] <L84Supper> cradek: for the next version of the Live/installCD
[21:39:15] <cradek> L84Supper: there is no schedule for making CDs
[21:39:27] <L84Supper> that makes it easy
[21:40:06] <mhaberler> cradek: you're mixing up the sampling period and the time-to-react of the underlying system
[21:40:34] <pcw_home> with any integral term there is negligible error when the PID gets a new command because its already there
[21:41:01] <mhaberler> if that were the case, the sampling frequency were way below Nyquist limit and we'de have aliasing
[21:42:14] <pcw_home> we are making in motion corrections on the Queen Mary,
[21:42:16] <pcw_home> not taking a step at a time
[21:49:46] <andypugh> mhaberler: One problem with moving f-error out of motion. The f-error is dynamic and proportional to speed. The HAL component doesn't know the trajectory speed.
[22:00:27] -!- bpuk_ has quit [Client Quit]
[22:01:35] <mhaberler> why is deviation from a path anywhere dependent on speed? I dont see that.
[22:02:46] <pcw_home> The current ferror limit is proportional to speed
[22:03:04] <mhaberler> ah
[22:03:46] <mhaberler> the _limit_ you mean.. let me see
[22:04:01] <pcw_home> this is reasonable since the error at a fixed sample rate will increase with speed
[22:04:16] <pcw_home> (for a number of reasons)
[22:04:38] <mhaberler> speed == current velocity I assume
[22:05:11] <mhaberler> right, got it
[22:05:39] <andypugh> It interpolates between F_ERROR and MIN_F_ERROR from the INI
[22:05:47] <pcw_home> yes
[22:08:08] <mhaberler> maybe I'm repeating myself, we have a terminology issue - ferror lumps together two incompatible concepts
[22:08:29] <mhaberler> one is quantisation noise, and another is path deviation
[22:09:11] <mhaberler> path deviation makes sense looking at intervals, quantisation noise does not as it changes intra-interval
[22:09:16] <andypugh> "Following Error" is only path deviation.
[22:09:37] <mhaberler> I guess that is what it _should_ be
[22:10:15] <cradek> I see pid error and following error as separate things now
[22:11:17] -!- DJ9DJ has quit [Quit: bye]
[22:12:14] <mhaberler> but the 'at point in time is ferror valid' aspect is a quantisation noise aspect - this curve changes intra-interval
[22:15:05] -!- gmagno has quit [Quit: Enough small talk...]
[22:15:52] <mhaberler> pcw_home: which were the missing pins you referred to? vel and acc?
[22:16:08] -!- pjm has quit [Ping timeout: 246 seconds]
[22:17:19] <pcw_home> I think that was Andy
[22:17:24] -!- IchGuckLive [IchGuckLive!~chatzilla@95-89-101-95-dynip.superkabel.de] has joined #linuxcnc-devel
[22:17:47] <IchGuckLive> hi does hal somwhere hold the Gcode we are on G1 G2 G0
[22:17:55] <IchGuckLive> or only the motion line
[22:18:05] <mhaberler> only the line
[22:18:14] <mhaberler> well yes, vel would be missing for a separate comp
[22:18:17] <IchGuckLive> ok mhaberler
[22:18:34] -!- MarkusBec has quit [Ping timeout: 265 seconds]
[22:18:40] <IchGuckLive> the call of the halusr must be done in hal and the pinconnect in postgui
[22:18:47] <IchGuckLive> that wars my problem
[22:18:58] <IchGuckLive> know its working
[22:19:00] <mhaberler> good
[22:19:16] <IchGuckLive> this shoudt be in the docus
[22:19:21] <IchGuckLive> i lost 4hr on this
[22:19:54] <mhaberler> I think it is, but well hidden from casual readers;)
[22:20:55] <IchGuckLive> no it is not there in hal manual side 104..
[22:22:00] <IchGuckLive> only 2 sides are on this in the hal docu
[22:22:12] <IchGuckLive> there is no word about this
[22:23:02] <IchGuckLive> Just call your python hal component in a HAL file and connect the pins in postgui
[22:23:09] <mhaberler> well, an update to the documentation would be great and now that you are really motivated...
[22:23:42] <IchGuckLive> Frustraded !
[22:24:17] <mhaberler> you just reported success, how could you possibly be frustrated
[22:24:54] <IchGuckLive> i woudt be there where i am know at 15:00 local and now its 23:34
[22:25:25] <IchGuckLive> just open up the docus copy the Python usr example to the path and start from there
[22:25:35] <IchGuckLive> this took the hole day
[22:25:43] <IchGuckLive> no access to the path
[22:26:01] <IchGuckLive> under nonsudo as you know
[22:26:10] <mhaberler> it would clearly benefit from a bit of improvement
[22:26:24] <IchGuckLive> as you speak
[22:26:46] <IchGuckLive> but is far harder to do somthing in the docus
[22:26:57] <IchGuckLive> i will override the wiki on that
[22:27:01] <mhaberler> well such is the nature of a community project - if something really pisses you off, you fix it - even if its documentation
[22:27:15] <IchGuckLive> no not pissing
[22:27:15] <mhaberler> the wiki is useless for real documentation
[22:27:32] <mhaberler> but a bit of text for the manual would be great
[22:27:45] <IchGuckLive> its the same as the git as i dont realy anderstand enflish
[22:27:56] <IchGuckLive> im far from knowing what i do
[22:28:35] <IchGuckLive> and the sad thing on this is i got a US pasport im a teatcher to the CAD CAM stuff
[22:29:06] <IchGuckLive> and working for 90% to us companies
[22:29:16] <mhaberler> WHAT? no more excuses
[22:29:26] <IchGuckLive> LOL
[22:29:28] <IchGuckLive> sad
[22:29:40] <IchGuckLive> dont worry i keep up with it
[22:30:42] <IchGuckLive> i think as alway if i finish 2-4week of coding jep jumps in and does change 5 letters somewhere and has the same !!
[22:31:37] <IchGuckLive> ok its late BY tommorow start coding
[22:31:43] -!- IchGuckLive [IchGuckLive!~chatzilla@95-89-101-95-dynip.superkabel.de] has parted #linuxcnc-devel
[22:38:04] -!- jthornton has quit [Ping timeout: 252 seconds]
[22:38:13] -!- JT-Shop has quit [Ping timeout: 248 seconds]
[22:44:35] -!- phantoneD has quit []
[22:51:36] -!- JT-Shop [JT-Shop!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[22:51:39] -!- jthornton [jthornton!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[22:58:29] -!- JT-Shop has quit [Ping timeout: 248 seconds]
[22:58:54] -!- jthornton has quit [Ping timeout: 264 seconds]
[22:59:02] -!- JT-Shop [JT-Shop!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[22:59:06] -!- jthornton [jthornton!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[23:00:46] -!- JT-Shop has quit [Read error: Connection reset by peer]
[23:00:46] -!- jthornton has quit [Read error: Connection reset by peer]
[23:08:09] -!- JT-Shop [JT-Shop!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[23:08:09] -!- jthornton [jthornton!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[23:10:15] -!- JT-Shop has quit [Read error: Connection reset by peer]
[23:10:16] -!- jthornton has quit [Write error: Connection reset by peer]
[23:13:19] -!- JT-Shop [JT-Shop!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[23:13:24] -!- jthornton [jthornton!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[23:16:33] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[23:21:30] -!- JT-Shop has quit [Read error: Connection reset by peer]
[23:21:30] -!- jthornton has quit [Read error: Connection reset by peer]
[23:22:19] -!- JT-Shop [JT-Shop!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[23:22:27] -!- jthornton [jthornton!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[23:31:15] -!- paideia has quit [Ping timeout: 272 seconds]
[23:44:26] -!- t12 has quit [Ping timeout: 252 seconds]
[23:46:46] -!- r00t4rd3d has quit [Ping timeout: 276 seconds]
[23:53:37] -!- bpuk has quit [Quit: Leaving]
[23:57:03] -!- ybon has quit [Quit: WeeChat 0.3.8]