Back
[00:00:34] -!- voxadam_ has quit [Remote host closed the connection]
[00:01:10] -!- dgarr [dgarr!~dgarrett@71-223-71-237.phnx.qwest.net] has joined #linuxcnc-devel
[00:02:04] -!- mhaberler has quit [Quit: mhaberler]
[00:03:52] -!- i_tom has quit [Remote host closed the connection]
[00:04:18] -!- SpeicusZ has quit [Ping timeout: 252 seconds]
[00:06:46] -!- mhaberler [mhaberler!~mhaberler@extern-177.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[00:07:28] -!- rob_h has quit [Ping timeout: 240 seconds]
[00:09:30] -!- voxadam has quit [Remote host closed the connection]
[00:10:27] -!- garfong has quit [Ping timeout: 272 seconds]
[00:13:02] -!- heyman has quit [Ping timeout: 246 seconds]
[00:13:03] -!- y3pp3r has quit [Read error: Connection reset by peer]
[00:16:36] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[00:17:08] -!- matheus_ has quit [Ping timeout: 240 seconds]
[00:20:58] <dgarr> cradek: any objections or comments for this touchy mod:
http://www.panix.com/~dgarrett/stuff/0001-touchy-allow-alternate-gladefile.patch
[00:23:47] -!- rob_h has quit [Quit: Leaving]
[00:23:53] -!- ve7it has quit [Remote host closed the connection]
[00:25:00] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[00:31:32] -!- asdfasd1 has quit [Ping timeout: 252 seconds]
[00:38:02] -!- y3pp3r has quit [Ping timeout: 264 seconds]
[00:43:27] -!- mhaberler has quit [Quit: mhaberler]
[00:44:05] -!- voxadam has quit [Remote host closed the connection]
[00:49:04] -!- voxadam has quit [Ping timeout: 240 seconds]
[00:57:27] NickParker|2 is now known as NickParker
[01:01:03] -!- ravenlock has quit [Ping timeout: 240 seconds]
[01:01:04] -!- terabyte- has quit [Quit: terabyte-]
[01:03:51] -!- voxadam has quit [Ping timeout: 240 seconds]
[01:10:47] -!- skorasaurus has quit [Quit: WeeChat 0.4.2]
[01:10:58] -!- grummund has quit [Ping timeout: 246 seconds]
[01:21:50] -!- gmag has quit [Ping timeout: 264 seconds]
[01:30:19] -!- Tecan has quit [Ping timeout: 260 seconds]
[01:34:42] -!- patrickarlt has quit [Remote host closed the connection]
[01:34:57] -!- voxadam has quit [Remote host closed the connection]
[01:42:01] -!- lucashodge has quit [Quit: Goodbye all.]
[01:47:44] -!- jazzy has quit [Ping timeout: 246 seconds]
[01:53:54] -!- voxadam has quit [Remote host closed the connection]
[01:53:54] -!- wboykinm has quit [Read error: Connection reset by peer]
[01:56:13] -!- zzolo has quit [Quit: zzolo]
[01:58:12] -!- heathmanc has quit [Ping timeout: 272 seconds]
[02:00:11] -!- ve7it has quit [Remote host closed the connection]
[02:07:44] -!- patrickarlt has quit [Quit: Leaving...]
[02:12:39] -!- voxadam has quit [Ping timeout: 240 seconds]
[02:17:52] -!- Komzzzpa has quit [Ping timeout: 240 seconds]
[02:22:08] -!- Tom_L has quit []
[02:22:43] -!- c-bob|afk has quit [Ping timeout: 246 seconds]
[02:22:49] c-bob is now known as c-bob|afk
[02:23:27] -!- The_Ball has quit [Ping timeout: 272 seconds]
[02:28:23] -!- lyzidiamond has quit [Quit: lyzidiamond]
[02:32:40] -!- zzolo has quit [Client Quit]
[02:36:02] -!- eric_unterhausen [eric_unterhausen!~eric@c-71-58-221-203.hsd1.pa.comcast.net] has parted #linuxcnc-devel
[02:36:12] -!- eric_unterhausen [eric_unterhausen!~eric@c-71-58-221-203.hsd1.pa.comcast.net] has joined #linuxcnc-devel
[02:38:40] -!- wboykinm has quit [Remote host closed the connection]
[02:47:05] -!- NickParker has quit [Read error: Connection reset by peer]
[02:53:03] -!- voxadam has quit [Ping timeout: 240 seconds]
[03:08:48] -!- R2E4 has quit [Read error: Connection reset by peer]
[03:10:19] -!- voxadam has quit [Remote host closed the connection]
[03:18:29] -!- voxadam has quit [Read error: No buffer space available]
[03:18:36] -!- futurisk has quit [Ping timeout: 260 seconds]
[03:20:21] -!- likewhoa has quit [Remote host closed the connection]
[03:21:39] -!- dgarr has quit [Ping timeout: 246 seconds]
[03:28:55] <skunkworks> or if you could put something like a clonezilla image up somewhere... :)
[03:36:06] -!- voxadam has quit [Read error: Connection reset by peer]
[03:38:35] -!- somenewguy has quit [Remote host closed the connection]
[03:54:17] -!- garfong has quit [Ping timeout: 240 seconds]
[03:55:40] -!- mozmck has quit [Read error: Connection reset by peer]
[03:55:52] -!- voxadam_ has quit [Ping timeout: 240 seconds]
[03:58:39] -!- mozmck [mozmck!~moses@client-67.210.159.209.dfwtx.partnershipbroadband.com] has joined #linuxcnc-devel
[04:02:41] -!- lyzidiamond has quit [Quit: lyzidiamond]
[04:03:06] -!- voxadam has quit [Remote host closed the connection]
[04:05:21] -!- zzolo has quit [Client Quit]
[04:16:12] -!- voxadam has quit [Remote host closed the connection]
[04:16:15] -!- AR__ has quit [Ping timeout: 246 seconds]
[04:24:12] -!- voxadam_ has quit [Remote host closed the connection]
[04:29:27] -!- Tecan has quit [Changing host]
[04:34:48] -!- skorasaurus has quit [Ping timeout: 246 seconds]
[04:43:26] -!- skorasaurus has quit [Ping timeout: 264 seconds]
[05:01:51] -!- garfong has quit [Ping timeout: 240 seconds]
[05:06:45] -!- zzolo has quit [Quit: zzolo]
[05:21:23] -!- voxadam has quit [Remote host closed the connection]
[05:22:36] -!- JerAgon_ [JerAgon_!~IceChat77@216.238.244.90] has joined #linuxcnc-devel
[05:24:58] -!- tjb1 has quit [Ping timeout: 240 seconds]
[05:24:58] -!- JerAgon has quit [Ping timeout: 240 seconds]
[05:28:27] -!- wboykinm has quit [Remote host closed the connection]
[05:34:33] -!- terabyte- has quit [Quit: terabyte-]
[05:50:50] -!- NickParker has quit [Read error: Connection reset by peer]
[05:57:16] -!- Mr_Mayhem has quit [Ping timeout: 246 seconds]
[05:59:14] -!- dhoovie has quit [Read error: Connection reset by peer]
[06:02:13] -!- FinboySlick has quit [Quit: Leaving.]
[06:02:52] -!- Fox_Muldr has quit [Ping timeout: 246 seconds]
[06:08:49] -!- morfic has quit [Remote host closed the connection]
[06:11:03] -!- NickParker has quit [Ping timeout: 240 seconds]
[06:11:08] -!- NickParker|2 has quit [Client Quit]
[06:11:18] -!- Fox_Muldr has quit [Quit: Serverwechsel]
[06:11:25] -!- wboykinm has quit [Remote host closed the connection]
[06:12:29] -!- ReadError has quit [Read error: Connection timed out]
[06:18:10] -!- voxadam has quit [Remote host closed the connection]
[06:33:20] -!- matheus_ has quit [Ping timeout: 240 seconds]
[06:41:46] -!- MacGalempsy has quit [Quit: No Ping reply in 180 seconds.]
[06:57:53] -!- kwallace [kwallace!~kwallace@smb-185.sonnet.com] has parted #linuxcnc-devel
[07:04:39] -!- voxadam has quit [Ping timeout: 240 seconds]
[07:21:50] -!- voxadam has quit [Ping timeout: 240 seconds]
[07:21:50] -!- MacGalempsy has quit [Ping timeout: 240 seconds]
[07:49:42] -!- JerAgon_ has quit [Ping timeout: 240 seconds]
[07:54:17] -!- Tecan has quit [Quit: new kernel time]
[08:13:27] -!- voxadam_ has quit [Ping timeout: 240 seconds]
[08:20:46] -!- voxadam has quit [Ping timeout: 240 seconds]
[08:21:26] -!- lyzidiamond has quit [Quit: lyzidiamond]
[08:23:03] -!- tjb11 has quit [Ping timeout: 240 seconds]
[08:43:52] -!- voxadam has quit [Ping timeout: 240 seconds]
[08:55:03] -!- voxadam_ has quit [Ping timeout: 240 seconds]
[08:57:48] -!- KimK has quit [Ping timeout: 252 seconds]
[09:00:17] -!- i_tarzan has quit [Ping timeout: 252 seconds]
[09:04:20] -!- futurisk has quit [Remote host closed the connection]
[09:04:44] -!- lbl has quit [Quit: lbl]
[09:12:51] -!- h0st1le has quit [K-Lined]
[09:15:45] -!- archivist_herron has quit [Ping timeout: 272 seconds]
[09:21:03] -!- Thetawaves has quit [Ping timeout: 240 seconds]
[09:21:32] -!- Thetawaves has quit [Remote host closed the connection]
[09:22:05] -!- i_tarzan_ has quit [Ping timeout: 241 seconds]
[09:23:56] -!- uw has quit [Quit: Leaving]
[09:45:08] -!- gmag has quit [Quit: Enough small talk...]
[09:56:35] -!- syyl has quit [Ping timeout: 245 seconds]
[09:56:37] -!- phillc54 [phillc54!~phillc54@206.260.dsl.syd.iprimus.net.au] has joined #linuxcnc-devel
[10:29:19] -!- FreezingCold has quit [Ping timeout: 260 seconds]
[10:47:45] -!- norbert [norbert!~norbert@a89-182-73-63.net-htp.de] has joined #linuxcnc-devel
[11:04:21] -!- archivist_herron has quit [Ping timeout: 246 seconds]
[11:16:25] -!- lbl has quit [Quit: lbl]
[11:17:10] -!- skunkworks has quit [Remote host closed the connection]
[11:29:51] -!- moonlite has quit [Ping timeout: 240 seconds]
[11:32:11] -!- moonlite_ has quit [Client Quit]
[11:32:45] moonlite is now known as moonlite_
[11:33:03] moonlite_ is now known as moonlite
[11:50:39] -!- matheus_ has quit [Ping timeout: 240 seconds]
[11:53:51] -!- cwmma has quit [Ping timeout: 240 seconds]
[11:53:51] cwmma_ is now known as cwmma
[11:56:02] -!- i_tarzan has quit [Ping timeout: 264 seconds]
[11:57:20] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[12:15:04] -!- b_b has quit [Changing host]
[12:42:01] <KGB-linuxcnc> 03Chris Morley 05stepconf-GTK-builder 9312b0b 06linuxcnc 10(19 files in 2 dirs) stepconf -refactor to use GTK Builder and Notebook * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9312b0b
[12:42:01] <KGB-linuxcnc> 03Chris Morley 05stepconf-GTK-builder 6ea4bbe 06linuxcnc 10src/emc/usr_intf/stepconf/base.glade 10src/emc/usr_intf/stepconf/pages.py 10src/emc/usr_intf/stepconf/stepconf.py stepconf -have stepconf reset the axis defaults on unit change * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6ea4bbe
[12:42:01] <KGB-linuxcnc> 03Chris Morley 05stepconf-GTK-builder e59adb1 06linuxcnc 10src/emc/usr_intf/stepconf/finished.glade 10src/emc/usr_intf/stepconf/main_page.glade 10src/emc/usr_intf/stepconf/pages.py 10src/emc/usr_intf/stepconf/stepconf.py stepconf -make the navigation buttons direct the user * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e59adb1
[12:42:05] <KGB-linuxcnc> 03Chris Morley 05stepconf-GTK-builder 871a13b 06linuxcnc 10(6 files) stepconf -add a second parallel port signal selection page * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=871a13b
[12:43:03] -!- i_tarzan has quit [Ping timeout: 240 seconds]
[12:55:14] -!- md-2 has quit [Remote host closed the connection]
[12:56:08] <linuxcnc-build> build #830 of precise-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/830 blamelist: dummy, John Thornton <jthornton@gnipsel.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant
[12:56:09] <linuxcnc-build> <tissf@free.fr>, Norbert Schechner <nieson@web.de>, Dewey Garrett <dgarrett@panix.com>
[12:57:01] <linuxcnc-build> build #1627 of precise-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-sim/builds/1627 blamelist: dummy, John Thornton <jthornton@gnipsel.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant <tissf@free.fr>,
[12:57:01] <linuxcnc-build> Norbert Schechner <nieson@web.de>, Dewey Garrett <dgarrett@panix.com>
[12:58:15] <linuxcnc-build> build #1629 of precise-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim/builds/1629 blamelist: dummy, John Thornton <jthornton@gnipsel.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant <tissf@free.fr>,
[12:58:15] <linuxcnc-build> Norbert Schechner <nieson@web.de>, Dewey Garrett <dgarrett@panix.com>
[12:59:00] <linuxcnc-build> build #1629 of lucid-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1629 blamelist: dummy, John Thornton <jthornton@gnipsel.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant
[12:59:00] <linuxcnc-build> <tissf@free.fr>, Norbert Schechner <nieson@web.de>, Dewey Garrett <dgarrett@panix.com>
[12:59:07] <linuxcnc-build> build #1626 of lucid-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1626 blamelist: dummy, John Thornton <jthornton@gnipsel.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant <tissf@free.fr>, Norbert
[12:59:07] <linuxcnc-build> Schechner <nieson@web.de>, Dewey Garrett <dgarrett@panix.com>
[13:00:14] -!- md-2 has quit [Ping timeout: 264 seconds]
[13:00:50] <linuxcnc-build> build #1630 of hardy-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1630 blamelist: dummy, John Thornton <jthornton@gnipsel.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant <tissf@free.fr>, Norbert
[13:00:50] <linuxcnc-build> Schechner <nieson@web.de>, Dewey Garrett <dgarrett@panix.com>
[13:01:04] <linuxcnc-build> build #1628 of lucid-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1628 blamelist: dummy, John Thornton <jthornton@gnipsel.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant <tissf@free.fr>, Norbert
[13:01:04] <linuxcnc-build> Schechner <nieson@web.de>, Dewey Garrett <dgarrett@panix.com>
[13:01:14] <linuxcnc-build> build #1625 of hardy-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1625 blamelist: dummy, John Thornton <jthornton@gnipsel.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant
[13:01:14] <linuxcnc-build> <tissf@free.fr>, Norbert Schechner <nieson@web.de>, Dewey Garrett <dgarrett@panix.com>
[13:01:24] <linuxcnc-build> build #1628 of hardy-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1628 blamelist: dummy, John Thornton <jthornton@gnipsel.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant <tissf@free.fr>, Norbert
[13:01:24] <linuxcnc-build> Schechner <nieson@web.de>, Dewey Garrett <dgarrett@panix.com>
[13:01:41] <linuxcnc-build> build #1625 of lucid-rtai-i386-clang is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-rtai-i386-clang/builds/1625 blamelist: dummy, John Thornton <jthornton@gnipsel.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant
[13:01:41] <linuxcnc-build> <tissf@free.fr>, Norbert Schechner <nieson@web.de>, Dewey Garrett <dgarrett@panix.com>
[13:02:28] -!- dgarr [dgarr!~dgarrett@71.223.71.237] has joined #linuxcnc-devel
[13:07:51] <linuxcnc-build> build #1424 of precise-amd64-sim-clang is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim-clang/builds/1424 blamelist: dummy, John Thornton <jthornton@gnipsel.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant
[13:07:51] <linuxcnc-build> <tissf@free.fr>, Norbert Schechner <nieson@web.de>, Dewey Garrett <dgarrett@panix.com>
[13:07:51] <linuxcnc-build> build #1630 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1630 blamelist: dummy, John Thornton <jthornton@gnipsel.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant <tissf@free.fr>, Norbert Schechner
[13:07:51] <linuxcnc-build> <nieson@web.de>, Dewey Garrett <dgarrett@panix.com>
[13:09:06] -!- ju-emb [ju-emb!~jgnoss@190.222.162.62] has parted #linuxcnc-devel
[13:10:57] -!- KimK [KimK!~Kim__@24.255.223.153] has joined #linuxcnc-devel
[13:19:49] -!- moonlite has quit [Quit: moonlite]
[13:20:40] -!- KimK has quit [Ping timeout: 240 seconds]
[13:30:32] -!- md-2 has quit [Ping timeout: 240 seconds]
[13:30:52] <skunkworks> I did a ./mesaflash --device 7i80 --ip=10.10.10.10 I then rebooted the board with jumpers w1,w1 down,up. it still pings at the 192.168.1.121 address
[13:46:03] <skunkworks> ok - I did a ./mesaflash --device 7i80 --ip 192.168.1.121 ip=10.10.10.10 an now it doesn't ping when I have the jumpers set down,up but when I change the nic's address to 10.10.10.1 I can't find the card
[13:46:34] -!- Loetmichel has quit [Ping timeout: 265 seconds]
[13:51:45] <skunkworks> heh - rfm.. set ip=10.10.10.10
[13:58:10] -!- TekniQue has quit [Read error: Connection reset by peer]
[14:00:26] <skunkworks> (didn't help)
[14:01:36] eric_unterhausen is now known as sanyo_denki_sale
[14:02:08] sanyo_denki_sale is now known as eric_unterhausen
[14:05:02] -!- balestrino has quit [Ping timeout: 264 seconds]
[14:16:39] <skunkworks> dxfin
[14:16:47] <skunkworks> heh
[14:19:08] -!- b_b has quit [Changing host]
[14:47:32] -!- dgarr has quit [Quit: Leaving.]
[14:48:44] -!- kiw has quit [Ping timeout: 246 seconds]
[14:51:58] -!- chillly has quit [Quit: Leaving]
[14:59:04] -!- uwe_mobile__ has quit [Ping timeout: 246 seconds]
[15:05:59] -!- kwallace [kwallace!~kwallace@smb-140.sonnet.com] has joined #linuxcnc-devel
[15:25:09] -!- skorasaurus has quit [Quit: WeeChat 0.4.2]
[15:27:53] -!- i_tarzan has quit [Read error: Operation timed out]
[15:28:49] <pcw_home> you need a set command to set the ip address
[15:30:38] <pcw_home> --set
[15:32:24] <pcw_home> ./mesaflash --device 7I80 --set ip=x.y.z.t
[15:33:42] <pcw_home> (and of course you will need to change your network setup to access x.y.z.t)
[15:40:32] -!- bedah has quit [Quit: Ex-Chat]
[15:43:21] -!- i_tarzan has quit [Ping timeout: 272 seconds]
[15:44:13] <skunkworks> yep - got it working. - just didn't help the watchdog issue. (trying everyting I can think of)
[15:51:06] -!- mshaver [mshaver!~mshaver@c-68-50-233-206.hsd1.md.comcast.net] has parted #linuxcnc-devel
[16:01:25] -!- zzolo has quit [Quit: zzolo]
[16:02:33] -!- mackerski has quit [Ping timeout: 246 seconds]
[16:02:33] mackerski_ is now known as mackerski
[16:09:02] -!- archivist_herron has quit [Ping timeout: 240 seconds]
[16:17:51] <pcw_home> you can get it to work and I cant get it to fail...
[16:17:53] <pcw_home> (Ive had a 7I80DB running under linuxcnc on a D525 for a week now with nary a glitch)
[16:18:22] <cradek> skunkworks: take your parts, put them in a box, and send them to pcw
[16:18:50] <skunkworks> That is a good idea!
[16:19:11] <cradek> then he can use science! to troubleshoot!
[16:19:22] <cradek> using science! is good!
[16:19:34] <pcw_home> Or I can send you the 7I80DB thats been running all week
[16:19:38] <skunkworks> wait - are you saying I am just flailing aimlessly?
[16:19:45] <cradek> you have to say "science" in that radio-announcer voice
[16:19:57] <cradek> no, I meant he has working parts to swap around
[16:20:14] <cradek> and probably logic-analyzer thingies and other wizardry
[16:20:34] <skunkworks> (I am flailing around aimlessly)
[16:20:53] <skunkworks> I have a good voice for science
[16:20:57] <skunkworks> ;)
[16:24:11] <pcw_home> I suspect its some subtle memory corruption issue in the driver (how can 0xFFFFFF00 .and. 0x00000001) = true
[16:25:40] <skunkworks> I could send you a hd and the card.. (I have tried it in enough ssytems that it has to be either the install or card...
[16:25:47] <cradek> I always suspect byte-order problems when I see all those void* and words broken up into char arrays and /4 and *4 counts in the driver. it's all baffling to me, which might be the code or it might be me
[16:30:14] <pcw_home> Yes it could well be an alignment issue, but why only on Skunkworks system remains a mystery
[16:30:26] <cradek> yeah
[16:30:56] <cradek> skunkworks: if you're going to do it, do it only once - I'd send everything just exactly as it is
[16:32:14] <skunkworks> sure - the atom board doesn't take up much space
[16:32:42] <cradek> [I used to do hardware and software support...]
[16:34:07] <pcw_home> however its done, a binary search through components seems in order
[16:37:55] <pcw_home> skunkworks: did you say you've seen that bug in the latency test when the latency decreases?
[16:38:03] <skunkworks> yes
[16:38:16] <pcw_home> only on preemt_rt?
[16:38:25] <pcw_home> I ve never seen it on RTAI
[16:38:59] <skunkworks> popped up to like 80us then back down to 60us. I have only seen it in the rtpreempt
[16:44:51] -!- PetefromTn has quit [Remote host closed the connection]
[16:53:19] -!- patrickarlt has quit [Remote host closed the connection]
[16:58:28] -!- terabyte- has quit [Quit: terabyte-]
[17:02:38] -!- norbert has quit [Quit: Verlassend]
[17:03:21] -!- terabyte- has quit [Client Quit]
[17:06:01] crib- is now known as crib
[17:17:04] <skunkworks> pcw_home, you say you tried the d945gclf2?
[17:17:58] <skunkworks> one of these?
http://www.mini-itx.com/reviews/atoms/?page=6
[17:20:00] -!- b_b has quit [Changing host]
[17:23:22] <pcw_home> Yes, that one
[17:25:29] -!- patrickarlt has quit [Read error: Connection reset by peer]
[17:25:41] <skunkworks> ok. would you have a problem if I packed up the HD, 7i80, and motherboard and sent it to you?
[17:26:27] -!- kiw has quit [Ping timeout: 260 seconds]
[17:28:32] -!- sekyms has quit []
[17:33:21] -!- mackerski has quit [Quit: mackerski]
[17:38:21] -!- terabyte- has quit [Quit: terabyte-]
[17:40:16] -!- syyl_ws has quit [Quit: Verlassend]
[17:47:13] -!- patrickarlt has quit [Ping timeout: 272 seconds]
[17:53:14] Cylly is now known as Loetmichel
[17:57:59] -!- patricka_ has quit [Ping timeout: 272 seconds]
[17:58:24] -!- arvidkahl has quit [Ping timeout: 246 seconds]
[17:58:26] -!- matheus_ has quit [Ping timeout: 264 seconds]
[18:03:22] <pcw_home> No problem if you dont mind. since I have a copy of 7I80/NM/HD is can swap one at a time
[18:11:35] -!- andypugh [andypugh!~andy2@cpc14-basl11-2-0-cust436.20-1.cable.virginm.net] has joined #linuxcnc-devel
[18:11:53] <skunkworks> andypugh, !
[18:12:41] <andypugh> We are too cautious about Gantrykins. By stressing the flaws, we seem to be persuading people that Mach3 (which does exactlty the same slightly wrong thing when homing) or wierd HAL-munging is better.
[18:15:11] <mozmck> what is slightly wrong about the homing?
[18:15:28] -!- md-2 has quit [Quit: Leaving...]
[18:16:00] <andypugh> One side of the gantry can be doing a rapid-to-home while the other is still doing a slow latch move.
[18:16:16] <andypugh> They can even possibly be moving in different directions.
[18:17:18] <mozmck> hmm, I've never seen that with Mach - ever.
[18:17:20] <andypugh> It gets hard to decide what to do with index-homng, especially if the encoders are not aligned.
[18:18:20] <andypugh> I have never seen Mach do anything at all, so I am basing my opinion on a description from the forum. Maybe Mach does home gantries better than LinuxCNC does.
[18:18:50] <mozmck> and we use and sell Mach with dual-drive gantry setup almost exclusively, so we would have heard of that.
[18:19:28] <andypugh> But the Mach3 solution to gantry homing seems to be to wire the home-all button to home both axes at the same time, which certainly sounds like it will have the same issue with the two sides potentially being at different points in the sequence.
[18:19:44] <mozmck> But I don't know about index-homing as nothing we use has that.
[18:20:07] <andypugh> Well, if Mach does it correctly, then _how_ does it do it?
[18:20:47] -!- matheus__ has quit [Ping timeout: 272 seconds]
[18:21:02] <mozmck> When you have a "slaved" axis as mach calls it, the 2 axes both move to the home switches at the same speed, and as each switch closes that side stops.
[18:22:00] <mozmck> when they have both closed the gantry backs off until the switches open again.
[18:22:12] <andypugh> So, it stops and waits for it's "friend" before starting the latch move?
[18:22:43] <mozmck> what is a latch move? where it backs off the switch?
[18:23:28] <andypugh> Yes, or when it moves slowly back on to the switch, depending on how homing is configured.
[18:23:31] <mozmck> but yes, if the gantry is out of square then the side that hits the switch first stops until the other side hits it's switch.
[18:23:39] <mozmck> Ok, yes.
[18:24:22] <pcw_home> with index you can align before you get home (assuming you are never racked more than 1/2 a turn)
[18:25:19] <andypugh> We did talk about tryiing a spaghetti gantry to test things out :-)
[18:25:39] <pcw_home> and with absolute you can unrack optimally
[18:25:44] <andypugh> pcw_home: How do you configure for non-aligned indexes?
[18:25:45] <mozmck> I guess so, but how would you make sure you are not out more than that? It doesn't happen much but it can happen if something goes wrong.
[18:26:13] <pcw_home> you need the offset as a setup constant
[18:26:23] <mozmck> Well, my router table is gantry but only single drive. I need to convert it because at 4 ft wide it really needs 2 drives.
[18:26:39] <andypugh> I think it is safest to move to the switches first, that way at least the racking won't get worse before it gets better.
[18:27:15] <pcw_home> if something goes that wrong its arguable that you need to fix before homing anyway
[18:27:36] <mozmck> One thing we do is turn the power to the motors off and if the gantry is racked much it is stiff enough to pull back close to right before powering back on and homing.
[18:28:30] <andypugh> That should work even better with servos.
[18:28:41] -!- zzolo has quit [Quit: zzolo]
[18:29:06] -!- mozmck has quit [Read error: Connection reset by peer]
[18:30:40] -!- mozmck [mozmck!~moses@client-67.210.159.209.dfwtx.partnershipbroadband.com] has joined #linuxcnc-devel
[18:31:04] <archivist> with some strain gauges one can measure the twist
[18:32:11] <mozmck> anyhow, I don't know if Mach's method is great, but the axes always move at the same speed and direction no matter what happens (assuming it is set up correctly!)
[18:32:13] -!- arvidkahl has quit [Ping timeout: 265 seconds]
[18:32:51] <mozmck> Axes may not be the correct terminology for LinuxCNC - joints maybe?
[18:35:06] <pcw_home> so crab toward home till you hit both switches, decell and stop together and then back off both at once (stopping individually) ?
[18:35:52] -!- Deejay has quit [Quit: bye]
[18:36:34] -!- cwmma has quit [Quit: cwmma]
[18:37:50] <mozmck> Unless I have something wrong, that's how Mach does it, although I think it stops at each switch as it hits it.
[18:38:23] <mozmck> The homing movement is slow so it can stop quickly.
[18:38:26] <mozmck> bbl
[18:55:13] -!- zzolo has quit [Quit: zzolo]
[19:00:24] <mozmck> From the forum: "I hope it is going to be on the a gender for the future" :)
[19:01:12] <mozmck> it's on my a-gender to look at the gantry stuff for sure.
[19:01:32] -!- terabyte- has quit [Quit: terabyte-]
[19:02:28] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 20.0/20130329043827]]
[19:02:56] -!- gonzo__ has quit [Read error: Connection reset by peer]
[19:08:12] <skunkworks> pcw_home,
http://imagebin.org/285024
[19:08:37] <skunkworks> so - it will run without the watchdog enabled?
[19:09:06] <skunkworks> I suppose the outputs are not enabled..
[19:09:17] <skunkworks> but internally - everthing is running?
[19:10:42] -!- GuShH_ has quit [Ping timeout: 240 seconds]
[19:10:49] <pcw_home> must be
[19:11:38] <skunkworks> if I set the hasbit to false. it instantly goes to true and I get the encoder count error
[19:12:04] <skunkworks> >| |< close...
[19:13:01] <skunkworks> well - I think I have the system setup to run. I will throw it in a box and send it out.
[19:13:16] <pcw_home> yeah but whats the difference? watchdog all all my test machines works just as expected
[19:13:33] <skunkworks> sure.. No clue..
[19:14:18] <skunkworks> I used your config - it ran right off the bat.. (last install - I could not get it to run without a following error.)
[19:14:35] <skunkworks> (but I had changed so much stuff - who knows)
[19:14:44] <cradek> I will send my spaghetti servos/switches/encoders+index gantry to anyone who's serious about getting gantry homing working in a sane way and committed to our git
[19:15:17] <skunkworks> This is a fresh updated 12.04, rtpreempt, linuxcnc installed.
[19:16:03] <mozmck> cradek: I may get serious before too long here, but we have some gantry machines I can test on.
[19:16:24] <cradek> do they have dual switches and encoders with index?
[19:16:29] <mozmck> I plan to convert my router to dual drive and I will have motivation then for sure.
[19:16:45] <mozmck> dual switches? You mean one for each side? yes.
[19:16:54] <cradek> (it seems to me that index reset is the hardest part)
[19:16:57] <mozmck> encoders, but no index.
[19:17:55] <mozmck> I may need some encoders with index, or I might have that and just need to use the index. I have small DC servos.
[19:18:16] <cradek> I think index is an important part of doing the project in a complete way (handling all the homing models and states)
[19:18:49] <mozmck> I'm sure it is.
[19:18:51] <cradek> ok, also let me know if digging in my encoder junkbox would help you
[19:18:56] <mozmck> ok, thanks.
[19:19:08] -!- terabyte- has quit [Quit: terabyte-]
[19:19:42] <cradek> I'm a little dejected because I've started that project at least twice and never finished it...
[19:22:33] <cradek> my silly attempt that was never quite right:
http://timeguy.com/gitweb?p=linuxcnc.git;a=log;h=refs/heads/synchronized-homing
[19:23:01] <cradek> I didn't have the heart to brute-force it by adding a new state after each existing state, but I think that would probably actually work
[19:23:10] <mozmck> heh, I know the feeling!
[19:24:40] <mozmck> Does it already handle syncronizing the rest of the motion?
[19:24:48] <cradek> this attempted to use the existing homing sequence to determine which joints were slaved
[19:25:16] <cradek> I don't understand what you are asking there. what rest of motion?
[19:25:49] <mozmck> If two joints are slaved they should move together all the time. I presume homing is the only thing that is not quite right?
[19:27:09] <cradek> well assuming you can use kins for making joints move together correctly after homing, homing is the only remaining thing
[19:27:52] <cradek> you could also perhaps slave joints at the hal level, and I think it could be done entirely with a hal component, but that component would need to be intimate with the homing state machine, so the whole approach feels wrong
[19:28:29] <cradek> if I were working on this today (for the 4th time) I'd certainly start on top of joints_axes4
[19:28:45] <mozmck> ok, I'll have to dig into it later.
[19:28:46] <cradek> [tell me if I have not yet answered your question...?]
[19:28:55] <mozmck> I think you have :)
[19:29:40] <mozmck> is joints_axes4 close to being merged into master?
[19:29:43] <cradek> I'm surprised my branch is not on top of ja3 but I think it's not...
[19:30:12] <cradek> my opinion is that if ja4 doesn't go into 2.6 [and I think it won't] that we must merge it right after making v2.6_branch
[19:30:22] <mozmck> ok
[19:30:39] <cradek> and I would be a bit surprised if anyone strongly disagrees with that
[19:30:59] <cradek> so the answer is it's sorta close, I think
[19:31:11] <mozmck> ok
[19:31:25] <cradek> closer than ever! (just like you're older than you've ever been)
[19:31:37] <mozmck> :)
[19:31:46] <cradek> that's a great song
[19:34:58] <pcw_home> I wonder if there any way for motion to provide forward differences to HAL
[19:34:59] <pcw_home> (rather then the current backward differences)
[19:35:23] <cradek> pcw_home: the current-vel outputs are not it?
[19:35:43] <pcw_home> nope
[19:36:09] <cradek> explain?
[19:36:44] <pcw_home> http://imagebin.org/283659
[19:38:18] <pcw_home> for this to be right, velocity must be calculated for next next waypoint, not the last one
[19:38:26] <pcw_home> the next
[19:39:07] <cradek> does that mean the same as latching and delaying the target position by one period?
[19:39:25] <pcw_home> Yes
[19:39:41] <pcw_home> (and all that entails)
[19:39:42] <cradek> that sounds easy; you can do it in hal
[19:39:50] <cradek> but sorry about homing :-/
[19:40:06] <pcw_home> except ferror
[19:41:23] <cradek> the position command (I think) means this is where I want you to be at the end of this period (right?)
[19:41:58] <cradek> but what is the vel command? at the end of this period you should be moving this fast (through the command position)?
[19:43:07] <pcw_home> motion hardware (to be correct) needs to know the current desired position and how to get to the next waypoint
[19:45:43] <pcw_home> (how to get to the next waypoint for a PID velocity mode control is FF1)
[19:45:44] <pcw_home> FF2 is broken as well in the same way
[19:46:34] <cradek> could you doodle what you think is wrong on that plot (draw what the right thing would be)?
[19:46:58] <cradek> the scales on pos and vel are different by 2/5 but it's still fairly clear
[19:48:03] <cradek> I assume the red is there but flatlined?
[19:48:47] <pcw_home> yeah but its pretty basic, to have "perfect" velocity mode you need the velocity to get to the next position
[19:48:49] <pcw_home> not how you got to the current position (you need to extrpolate)
[19:48:57] <pcw_home> red is the same as white
[19:48:59] <cradek> is the error-previous-target fix not right?
[19:49:25] <pcw_home> the fix is required or its hopeless
[19:51:10] <cradek> I don't really understand how current/next command/feedback position/vel all fit together
[19:51:37] <cradek> when you quantize it in time, it gets all crazy and I don't understand what's "right"
[19:51:52] <pcw_home> imagine a perfect velocity mode drive (the stepgen is very close to perfect)
[19:52:03] <cradek> what does that mean?
[19:52:16] <cradek> I don't know how a perfect velocity mode drive behaves
[19:52:31] <pcw_home> i have no feedback just FF1
[19:53:02] <cradek> ok once a second I give it a new velocity command. what does it do?
[19:53:31] <cradek> jumps instantly to that velocity and moves at that velocity for the coming second?
[19:53:41] <pcw_home> Yes
[19:53:47] <cradek> ok then, imagined
[19:55:42] <pcw_home> so starting from 0 velocity if my velocity command for the first 1 second segment is one second late
[19:55:43] <pcw_home> I will miss my first waypoint by VT
[19:57:10] <pcw_home> in other words I need the velocity required to get to the next waypoint
[19:57:12] <pcw_home> not the velocity that got us to the current one
[19:57:29] <pcw_home> (which is what we have now)
[19:57:31] <cradek> if the first command position is 1, the first command vel should also be 1, right? because it'll go 1in/sec for 1sec and get to 1in
[19:58:23] <pcw_home> yes but currently the first command velocity will be 0
[19:58:25] <cradek> but I think that's what I see in the green and cyan lines in your plot
[19:58:33] <cradek> are you sure?
[19:58:49] <cradek> the green and cyan lines jump at the same time to (I think) the same value
[19:59:25] <pcw_home> thats the problem
[19:59:29] <cradek> I'm lost
[19:59:37] <cradek> you just said that was correct with my example of all 1s
[20:01:26] <cradek> in your plot the first period's vel is 200u/period and and first period's position is 200u
[20:01:36] <pcw_home> the cyan would have to lead the green by one sample to be correct
[20:01:38] <pcw_home> (current pos is 0 but velocity must be 1 to instruct the hardware how to get to the next waypoint)
[20:01:54] <pcw_home> (with your numbers)
[20:02:22] <cradek> but that doesn't agree with how you said a perfect velocity mode amp works
[20:02:59] <pcw_home> ?
[20:03:05] <cradek> rereading
[20:04:57] -!- ekolojik has quit [Changing host]
[20:06:38] <pcw_home> looked at another way, starting at 0 velocity the only way
[20:06:39] <pcw_home> I can get to the first waypoint correctly the first sample after
[20:06:41] <pcw_home> motion starts is by having the velocity lead the position
[20:07:35] <mozmck> makes sense, at 0 vel you go nowhere
[20:07:41] <cradek> I'm still missing something. do our two commands, set at the same time, mean "move at this velocity during the coming period" and "at the end of that period I expect you to be at position"
[20:08:46] <pcw_home> I would think so
[20:09:22] <cradek> then the plot looks right to me, and is just like my example with 1s, and I don't yet follow your objection
[20:10:05] <cradek> you are saying "move at velocity 1 during the coming period" but "at the end of that period I expect you to STILL BE at 0"
[20:10:13] <cradek> which is clearly wrong
[20:10:24] <cradek> what am I missing?
[20:11:17] <cradek> you are saying [by proposing we change vel a period earlier]
[20:12:37] <cradek> brb, I will read back
[20:15:32] <pcw_home> if you look at the plot again
[20:15:34] <pcw_home> at one sample, position and velocity are 0
[20:15:35] <pcw_home> at the next the position has changed to 200u
[20:15:37] <pcw_home> but the velocity command which applies for the next period told it to stay still
[20:15:38] <pcw_home> (hence the following error)
[20:20:16] <cradek> if this from earlier is true (do our two commands, set at the same time, mean "move at this velocity during the coming period" and "at the end of that period I expect you to be at position") then they should change from zero simultaneously in your plot, and they do
[20:20:34] adfa is now known as voxadam
[20:20:35] <mozmck> Looks to me like the position changes to 200u at the same time the vel changes to about 100m.
[20:20:57] <cradek> I think they both change to 200u
[20:21:15] <cradek> the scale is 2 vs 5
[20:21:47] <mozmck> So position should not be at 200u, but that's where it should be moving next period at the new vel.
[20:22:18] <mozmck> you're right.
[20:24:24] <cradek> yes 200u of position is expected after this 1ms period if you move at 200m/inch for 1 ms
[20:25:38] <cradek> my understanding of how a perfect velocity mode amp would work (above) and what our two commands mean (not so far above) seem to me to match
[20:26:08] <cradek> hm, I notice after the first period the ferror is zero
[20:26:19] <pcw_home> ferror is delayed
[20:26:41] <mozmck> Is the error because it takes actual time to accelerate to vel-cmd?
[20:26:52] <cradek> but error-previous-target means "Use previous invocation's target vs. current position" which also matches our model
[20:27:00] <pcw_home> This is a stepgen (no inertia)
[20:27:10] <mozmck> oh.
[20:28:33] <cradek> are you sure you don't just have your thread misordered or something? or is one of my understandings above wrong? I tried to spell them out.
[20:29:01] <pcw_home> the error that error-previous-target fixed for the PID loop is basically the same error
[20:29:04] <pcw_home> (backward differences) in motion. to get to the next waypoint, velocity must lead position
[20:30:04] <cradek> you keep saying that, but I think it is not true if my stated assumptions about what the commands mean are correct.
[20:30:38] -!- voxadam has quit [Ping timeout: 240 seconds]
[20:32:02] <cradek> I'm not being dense on purpose [it comes naturally] but please tell me which assumption is wrong
[20:32:27] <pcw_home> if the hardware is handed 0 vel and 0 position and at the next sample period position is 200u, this is simply wrong
[20:32:49] -!- skunkworks has quit [Read error: Connection reset by peer]
[20:32:55] <cradek> but we agreed that's not what the commanded position means
[20:33:19] <cradek> we agreed that the commanded position means: after the coming cycle, I expect you to be here
[20:33:32] <pcw_home> then commanded position is wrong
[20:33:33] <cradek> after you move at [vel] for a period I expect you to be at [pos]
[20:34:06] <pcw_home> (as illustrated by the PID hack)
[20:34:07] <cradek> now on the next cycle, feedback pos is read and compared to that remembered value, to see how we did
[20:34:13] <cradek> motion and pid both do it (now)
[20:35:13] <cradek> I think it is a consistent model and it matches your ideal velocity mode amp
[20:36:26] <pcw_home> well it results in unfixable errors so is just wrong so far as I am concerned
[20:37:08] <cradek> I think you must disagree with:? (do our two commands, set at the same time, mean "move at this velocity during the coming period" and "at the end of that period I expect you to be at position")
[20:37:43] <pcw_home> thats correct
[20:38:03] <cradek> um, I'm correct that you disagree?
[20:38:13] -!- GuShH_ has quit [Excess Flood]
[20:38:14] <pcw_home> position being _current_ desired position
[20:38:40] <pcw_home> not next not last but current
[20:38:55] <cradek> ok that is not what motion or pid (now) do. is that what stepgen does?
[20:39:08] <mozmck> If there is a velocity command but the position command is not until the next period then won't it possibly overshoot?
[20:39:09] -!- patrickarlt has quit [Remote host closed the connection]
[20:39:36] <pcw_home> no it will get to the position at the next sample
[20:39:41] <cradek> perhaps stepgen is mistaken about the consistent model we finally have in motion and pid
[20:40:08] <pcw_home> this is with motion an PID
[20:41:09] <pcw_home> the stepgen illustrates the error well because its a "perfect" velocity mode servo
[20:42:15] <mozmck> Is the error an error in position?
[20:42:53] <pcw_home> Yes
[20:43:25] <cradek> does the stepgen calculate ferror internally and use it for something?
[20:43:55] -!- arvidkahl has quit [Ping timeout: 272 seconds]
[20:44:19] <mozmck> So if the position is not what it should be then do you adjust velocity? If so I can see your point I think.
[20:44:20] <pcw_home> not in velocity mode
[20:45:46] <cradek> I think it is wrong to think of the commanded position to mean "I expect you are already here even before this period runs"
[20:45:56] <cradek> I think this is our model mismatch
[20:45:59] <pcw_home> This is running the stepgens in velocity mode in a PID loop (FF1 = 1.00 FF2= period, P= ~150)
[20:46:50] <pcw_home> but you can see that that model already requires some ugly patching around
[20:46:54] <cradek> neither motion nor pid think the commanded position means that (now)
[20:47:25] <cradek> well no, the "ugly patch" in pid was a simple bugfix IMO, and we made it optional so we didn't "break" existing (mis)tunings
[20:47:38] <cradek> it made it match what motion always meant
[20:49:19] <cradek> FF1=1 P=150 would not be a perfect tuning for our perfect amp, would it?? FF1=1 P=0 would be.
[20:49:48] <cradek> hm or would it matter
[20:50:00] <cradek> [maybe pid is still wrong]
[20:50:31] <pcw_home> yes P=0 if its was perfect
[20:50:41] <cradek> does that fix your plot?
[20:51:08] <pcw_home> its unfixable
[20:51:08] <cradek> er, make it better? (jitter will still make it drift)
[20:52:11] <pcw_home> P is low enough that is just slowly corrects for errors
[20:54:34] <pcw_home> Probably the existing HM2 stepgen driver should be tossed and replaced with a PID loop
[20:54:36] <pcw_home> since the existing one has trouble with jitter and th ePID loop scheme works much better
[20:55:34] <pcw_home> (and can use fixed tuning)
[20:56:08] <pcw_home> and avoids the need to set stepgen maxaccel or stepgen maxvel
[21:00:53] <cradek> if a fixed tuning works fine, that sounds great
[21:01:19] -!- matheus_ has quit [Ping timeout: 246 seconds]
[21:01:19] -!- davc has quit [Ping timeout: 246 seconds]
[21:02:05] -!- i_tarzan_ has quit [Ping timeout: 245 seconds]
[21:02:55] <pcw_home> yeah FF1 at 1 is obvious but FF2 at servo thread period was not
[21:06:38] <pcw_home> best thing is that the PID controlled stepgen works OK with 100s of usec of jitter
[21:07:25] <pcw_home> (set the PID max_error and jitter caused error peaks are just clipped)
[21:08:26] <pcw_home> (so they dont cause wild bogus corrections as they do with the stepgen driver)
[21:09:14] <cradek> a win! time to change the hm2 sample configs and pncconf?
[21:09:26] <cradek> (or is it stepconf?)
[21:10:24] <pcw_home> its doable now with stepgen code thats more like servo code, so just different hal boilerplate
[21:11:24] <pcw_home> but at some point the hm2 driver could be updated to be compatible but use PID inside
[21:11:49] <cradek> I think this is how the pico stepper configs work - I wonder why we(?) changed systems?
[21:12:14] <pcw_home> I think Seb started with the software stepgen as a model
[21:12:41] <cradek> I think the wisdom with the pico configs was that you had to tune their pids. this might have just been mistaken.
[21:13:07] <cradek> I don't remember if there were FF in emc1 - that would have been a big difference
[21:13:21] <pcw_home> AFAICT its basically fixed
[21:13:30] <cradek> that's great
[21:14:32] <pcw_home> in a way the difference is that the PID scheme can be set to "trust" the short term accuracy of the stepgen more
[21:15:28] <cradek> like just don't freak out, it'll be ok on average?
[21:15:35] <pcw_home> (rely mainly on FF1 and low pass filter the errors)
[21:15:38] <cradek> yeah
[21:15:52] -!- cwmma has quit [Quit: cwmma]
[21:16:12] <cradek> it does sound pretty easy to build that in if there's one optimal tuning
[21:16:26] <cradek> that would fix everyone's existing setups
[21:16:44] -!- i_tarzan has quit [Ping timeout: 252 seconds]
[21:16:57] <pcw_home> yeah the current stepgen is like pig on stilts
[21:19:22] <pcw_home> as long as everything is cool it hobbles along
[21:19:24] <pcw_home> (I remember the first problems showed up when Linuxcnc moved from 8.04 to 10.04)
[21:19:25] <pcw_home> probably somewhat worse jitter
[21:20:47] <pcw_home> setting a reasonable stepgen_maxaccel works around the problem but not that well
[21:22:29] <pcw_home> I guess I should do some work today
[21:22:35] <pcw_home> bbl
[21:26:29] -!- wboykinm has quit [Remote host closed the connection]
[21:40:48] -!- ler_hydra has quit [Remote host closed the connection]
[21:44:31] -!- matheus_ has quit [Ping timeout: 260 seconds]
[21:49:55] -!- davc has quit [Ping timeout: 245 seconds]
[22:04:11] -!- motioncontrol has quit [Remote host closed the connection]
[22:04:25] <seb_kuzminsky> hey zultron_ , i just tried to build a deb from ubc3 on a non-realtime machine, and it failed:
[22:04:28] <seb_kuzminsky> http://highlab.com/~seb/linuxcnc/ubc3-deb-bug
[22:05:06] -!- lyzidiamond has quit [Quit: lyzidiamond]
[22:05:11] <seb_kuzminsky> it looks like it's using the realtime (non-sim) .files file, looking for files that don't get installed when building without realtime support
[22:05:57] <seb_kuzminsky> i'm not sure how you guy have things set upfor building debs with various levels of realtime support in that branch, could you clue me in? i'll help with the deb part if you tell me what the right behavior should be
[22:06:04] -!- davc has quit [Ping timeout: 246 seconds]
[22:10:18] -!- voxadam_ has quit [Quit: quit]
[22:10:34] -!- Deejay has quit [Quit: bye]
[22:15:28] -!- tinkerer [tinkerer!~tinkerer@mail.play-pla.net] has joined #linuxcnc-devel
[22:17:25] -!- roloid has quit [Quit: Konversation terminated!]
[22:27:17] -!- ekolojik has quit [Quit: Konversation terminated!]
[22:37:55] -!- matheus__ has quit [Ping timeout: 272 seconds]
[22:38:27] -!- davc has quit [Ping timeout: 272 seconds]
[23:04:53] -!- `Nerobro has quit [Quit: Leaving]
[23:09:21] -!- chillly has quit [Quit: Leaving]
[23:09:27] -!- matheus_ has quit [Ping timeout: 260 seconds]
[23:18:43] -!- i_tarzan_ has quit [Ping timeout: 272 seconds]
[23:20:28] -!- afiber__ has quit [Quit: Konversation terminated!]
[23:25:34] -!- rob_h [rob_h!~robh@94.12.189.14] has joined #linuxcnc-devel
[23:32:23] -!- JT-Shop_ [JT-Shop_!~john@75.106.20.181] has joined #linuxcnc-devel
[23:32:26] -!- jthornton_ [jthornton_!~john@75.106.20.181] has joined #linuxcnc-devel
[23:33:04] -!- jthornton has quit [Read error: Connection reset by peer]
[23:33:23] -!- arkgis has quit [Remote host closed the connection]
[23:33:41] -!- JT-Shop has quit [Ping timeout: 252 seconds]
[23:49:48] -!- Komzzzpa has quit [Ping timeout: 246 seconds]
[23:51:24] JT-Shop_ is now known as JT-Shop
[23:51:57] -!- terabyte- has quit [Quit: terabyte-]
[23:53:01] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[23:56:53] -!- tjb1 has quit [Quit: Leaving.]