Back
[00:00:47] <Roguish> just for fun;
http://itvision.altervista.org/why.linux.is.not.ready.for.the.desktop.current.html
[00:03:49] -!- Deejay has quit [Quit: Deejay]
[00:05:58] -!- Patang has quit [Read error: Connection reset by peer]
[00:07:30] -!- tinkerer has quit [Remote host closed the connection]
[00:14:26] -!- Patang [Patang!~freenode@cm-84.208.100.218.getinternet.no] has joined #linuxcnc-devel
[00:19:56] -!- Camaba has quit [Read error: Connection reset by peer]
[00:28:42] -!- Roguish has quit [Quit: ChatZilla 0.9.92 [Firefox 43.0.3/20151223140742]]
[00:30:31] <CaptHindsight> https://www.youtube.com/watch?v=lfDwDOAwtnw M61 20mm Cannon
[00:36:08] <CaptHindsight> woops
[00:36:43] -!- bkboggy has quit [Quit: For Narnia!]
[00:43:17] -!- rob_h has quit [Ping timeout: 246 seconds]
[00:58:27] -!- sumpfralle has quit [Remote host closed the connection]
[01:00:48] -!- PetefromTn_ [PetefromTn_!~IceChat9@75-136-59-160.dhcp.jcsn.tn.charter.com] has joined #linuxcnc-devel
[01:04:35] -!- Loetmichel2 has quit [Ping timeout: 260 seconds]
[01:12:00] -!- Duc has quit [Ping timeout: 250 seconds]
[01:12:20] -!- andypugh [andypugh!~andypugh@cpc14-basl11-2-0-cust1010.20-1.cable.virginm.net] has joined #linuxcnc-devel
[01:16:54] -!- cheetah2 has quit [Remote host closed the connection]
[01:30:48] -!- JT-Shop- [JT-Shop-!~john@172.243.171.57] has joined #linuxcnc-devel
[01:30:50] -!- jthornton- [jthornton-!~john@172.243.171.57] has joined #linuxcnc-devel
[01:31:16] -!- jthornton has quit [Read error: Connection reset by peer]
[01:32:42] -!- JT-Shop has quit [Read error: Connection reset by peer]
[01:36:33] -!- cheetah2 has quit [Remote host closed the connection]
[01:40:56] -!- cheetah2 has quit [Remote host closed the connection]
[01:46:00] -!- gentoognuhurd has quit [Ping timeout: 260 seconds]
[01:47:13] -!- cheetah2 has quit [Remote host closed the connection]
[01:52:59] -!- andypugh has quit [Quit: andypugh]
[02:00:55] -!- Loetmichel has quit [Ping timeout: 240 seconds]
[02:16:26] -!- asdfasd has quit [Ping timeout: 272 seconds]
[02:21:00] -!- JT-Mobile has quit [Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )]
[02:25:03] -!- cheetah2 has quit [Remote host closed the connection]
[02:34:43] <linuxcnc-build> build #3826 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3826 blamelist: dummy, John Morris <john@zultron.com>, Chris Radek <chris@timeguy.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>,
[02:34:43] <linuxcnc-build> John Thornton <bjt128@gmail.com>, chris morley <chrisinnanaimo@hotmail.com>, Dewey Garrett <dgarrett@panix.com>
[02:35:18] amnesic_away is now known as amnesic
[02:50:53] amnesic is now known as amnesic_away
[02:56:24] -!- PetefromTn_ has quit [Quit: I'm Outta here!!]
[03:13:11] -!- ve7it has quit [Remote host closed the connection]
[03:13:48] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[03:27:54] <linuxcnc-build> build #10 of 4023.deb-jessie-rtai-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4023.deb-jessie-rtai-i386/builds/10 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:30:43] -!- cheetah2 has quit [Ping timeout: 265 seconds]
[03:39:37] <linuxcnc-build> build #968 of 1903.clang-wheezy-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1903.clang-wheezy-amd64/builds/968 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:42:28] <linuxcnc-build> build #77 of 1505.rip-jessie-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1505.rip-jessie-rtai-i386/builds/77 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:51:34] <linuxcnc-build> build #968 of 1902.clang-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1902.clang-wheezy-rtai-i386/builds/968 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:54:52] <linuxcnc-build> build #3816 of 1306.rip-precise-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/3816 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:55:42] -!- AR__ has quit [Ping timeout: 260 seconds]
[03:56:45] <linuxcnc-build> build #2007 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/2007 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:57:23] <linuxcnc-build> build #3814 of 1300.rip-precise-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/3814 blamelist: Jeff Epler <jepler@unpythonic.net>
[04:01:16] <linuxcnc-build> build #3025 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/3025 blamelist: Jeff Epler <jepler@unpythonic.net>
[04:16:02] <linuxcnc-build> build #1974 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/1974 blamelist: Jeff Epler <jepler@unpythonic.net>
[04:18:49] <linuxcnc-build> build #1975 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/1975 blamelist: Jeff Epler <jepler@unpythonic.net>
[04:31:10] -!- cheetah2 has quit [Ping timeout: 260 seconds]
[04:34:49] <linuxcnc-build> build #2167 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/2167 blamelist: Jeff Epler <jepler@unpythonic.net>
[04:39:06] -!- almostworking has quit [Ping timeout: 240 seconds]
[04:39:20] -!- cheetah2 has quit [Remote host closed the connection]
[04:41:13] <linuxcnc-build> build #1485 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/1485 blamelist: Jeff Epler <jepler@unpythonic.net>
[04:52:59] <linuxcnc-build> build #442 of 1520.rip-jessie-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1520.rip-jessie-amd64/builds/442 blamelist: Jeff Epler <jepler@unpythonic.net>
[04:55:58] <linuxcnc-build> build #1640 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/1640 blamelist: Jeff Epler <jepler@unpythonic.net>
[04:58:25] <linuxcnc-build> build #442 of 1530.rip-jessie-rtpreempt-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1530.rip-jessie-rtpreempt-amd64/builds/442 blamelist: Jeff Epler <jepler@unpythonic.net>
[04:58:37] <linuxcnc-build> build #442 of 1500.rip-jessie-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1500.rip-jessie-i386/builds/442 blamelist: Jeff Epler <jepler@unpythonic.net>
[04:59:42] <linuxcnc-build> build #442 of 1510.rip-jessie-rtpreempt-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1510.rip-jessie-rtpreempt-i386/builds/442 blamelist: Jeff Epler <jepler@unpythonic.net>
[04:59:42] <linuxcnc-build> build #3828 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3828 blamelist: Jeff Epler <jepler@unpythonic.net>
[05:12:59] -!- cheetah2 has quit [Remote host closed the connection]
[05:27:12] newbie is now known as Guest29054
[05:29:46] -!- pink_vampire has quit [Ping timeout: 240 seconds]
[06:09:11] -!- AR__ has quit [Ping timeout: 264 seconds]
[06:16:01] -!- Duc has quit [Ping timeout: 265 seconds]
[06:42:26] -!- DaPeace1 has quit [Read error: Connection reset by peer]
[06:43:30] -!- cheetah2 has quit [Remote host closed the connection]
[06:49:11] -!- cheetah2 has quit [Remote host closed the connection]
[07:03:20] -!- AR__ has quit [Ping timeout: 272 seconds]
[07:19:29] -!- kwallace1 [kwallace1!~kwallace@142.147.85.210] has parted #linuxcnc-devel
[07:22:13] -!- Patang has quit [Read error: Connection reset by peer]
[08:03:37] -!- ve7it has quit [Remote host closed the connection]
[08:04:32] -!- SEL [SEL!~SEL@net77-43-27-64.mclink.it] has joined #linuxcnc-devel
[08:05:19] -!- SEL has quit [Client Quit]
[08:17:01] -!- PCW_ [PCW_!~chatzilla@99.88.10.65] has joined #linuxcnc-devel
[08:18:35] -!- PCW has quit [Ping timeout: 260 seconds]
[08:18:40] PCW_ is now known as PCW
[08:31:32] -!- swarfer has quit [Client Quit]
[08:41:04] -!- Patang [Patang!~freenode@cm-84.208.100.218.getinternet.no] has joined #linuxcnc-devel
[08:57:04] -!- cheetah2 has quit [Remote host closed the connection]
[09:28:03] -!- cheetah2 has quit [Remote host closed the connection]
[09:44:02] -!- choonway has quit [Read error: Connection reset by peer]
[09:45:30] -!- rob_h [rob_h!~robh@2.217.97.201] has joined #linuxcnc-devel
[09:52:48] -!- tylerm has quit [Ping timeout: 252 seconds]
[10:09:46] -!- jthornton- has quit [Ping timeout: 240 seconds]
[10:10:48] -!- JT-Shop- has quit [Ping timeout: 272 seconds]
[10:37:25] -!- cheetah2 has quit [Remote host closed the connection]
[10:51:31] -!- unfy has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
[11:00:15] -!- micges_ [micges_!~micges@elw108.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[11:04:05] -!- micges has quit [Ping timeout: 265 seconds]
[11:05:55] micges_ is now known as micges
[11:12:01] Guest29054 is now known as pink_vampire
[11:26:26] -!- Camaban has quit [Ping timeout: 240 seconds]
[11:38:58] -!- pink_vampire has quit [Read error: Connection reset by peer]
[11:43:09] -!- jthornton [jthornton!~john@172.243.171.57] has joined #linuxcnc-devel
[12:02:46] -!- JesusAlos has quit [Client Quit]
[12:09:09] -!- erve has quit [Remote host closed the connection]
[12:14:42] -!- tinkerer [tinkerer!~tinkerer@mail.play-pla.net] has joined #linuxcnc-devel
[13:21:35] -!- erve has quit [Ping timeout: 240 seconds]
[13:48:32] <KGB-linuxcnc> 03John Thornton 052.7 8233e35 06linuxcnc 10docs/src/index_es.tmpl Docs: fix broken link * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8233e35
[14:23:41] -!- erve has quit [Ping timeout: 246 seconds]
[14:25:39] <jthornton> don't think I'll get done with mb2hal docs this morning but got a good start...
[14:28:06] -!- rob_h has quit [Ping timeout: 240 seconds]
[14:28:48] -!- rob_h [rob_h!~robh@2.127.21.53] has joined #linuxcnc-devel
[14:32:28] -!- chris_99 has quit [Quit: Leaving]
[14:37:20] -!- CaptHindsight has quit [Ping timeout: 246 seconds]
[14:44:52] -!- SEL [SEL!~SEL@net77-43-27-64.mclink.it] has joined #linuxcnc-devel
[14:45:32] -!- SEL has quit [Client Quit]
[14:48:12] -!- skunkworks has quit [Ping timeout: 272 seconds]
[15:04:11] -!- JT-Shop [JT-Shop!~john@172.243.171.57] has joined #linuxcnc-devel
[15:25:10] -!- erve has quit [Ping timeout: 276 seconds]
[15:26:15] -!- zeeshan [zeeshan!~kvirc64@CPE0018e7cea342-CM5039555db2cc.cpe.net.cable.rogers.com] has joined #linuxcnc-devel
[15:29:20] -!- neverbuya_subaru has quit [Ping timeout: 256 seconds]
[15:41:44] -!- jthornton has quit [Ping timeout: 246 seconds]
[15:41:50] -!- jthornton- [jthornton-!~john@172.243.171.57] has joined #linuxcnc-devel
[15:41:50] -!- JT-Shop- [JT-Shop-!~john@172.243.171.57] has joined #linuxcnc-devel
[15:42:05] -!- JT-Shop has quit [Ping timeout: 246 seconds]
[15:46:12] -!- cncbasher [cncbasher!~Sarah@cpc8-hart9-2-0-cust254.11-3.cable.virginm.net] has joined #linuxcnc-devel
[16:01:09] -!- CaptHindsight [CaptHindsight!~2020@unaffiliated/capthindsight] has joined #linuxcnc-devel
[16:13:25] JT-Shop- is now known as JT-Shop
[16:15:12] -!- kwallace [kwallace!~kwallace@142.147.85.210] has joined #linuxcnc-devel
[16:25:40] -!- erve has quit [Ping timeout: 260 seconds]
[16:28:58] -!- Roguish [Roguish!~chatzilla@c-50-143-183-159.hsd1.ca.comcast.net] has joined #linuxcnc-devel
[16:33:14] -!- floppydiskph has quit [Ping timeout: 265 seconds]
[16:45:41] -!- swarfer has quit [Quit: swarfer]
[17:10:23] -!- bensbenz has quit [Quit: Leaving]
[17:20:54] -!- cncbasher [cncbasher!~Sarah@cpc8-hart9-2-0-cust254.11-3.cable.virginm.net] has parted #linuxcnc-devel
[17:25:45] -!- tobias47n9e_ has quit [Ping timeout: 260 seconds]
[17:41:52] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[18:00:59] -!- erve has quit [Read error: Connection reset by peer]
[18:02:08] <jepler> http://idlewords.com/talks/website_obesity.htm
[18:03:29] -!- cheetah2 has quit [Ping timeout: 245 seconds]
[18:03:29] -!- Patang has quit [Read error: Connection reset by peer]
[18:05:10] -!- chupacabra has quit [Ping timeout: 256 seconds]
[18:11:53] -!- Patang [Patang!~freenode@cm-84.208.100.218.getinternet.no] has joined #linuxcnc-devel
[18:14:01] <archivist> hehe and his page is 104 resources 1.01MB 988.9kB
[18:14:15] <archivist> good article though
[18:17:37] -!- andypugh [andypugh!~andypugh@cpc14-basl11-2-0-cust1010.20-1.cable.virginm.net] has joined #linuxcnc-devel
[18:18:01] <KGB-linuxcnc> 03andypugh 052.7 03d2d11 06linuxcnc 10configs/sim/axis/vismach/VMC_toolchange/spindle.hal Connect the orient mode pin to allow rotation direction to be controlled in the VMC Vismach model * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=03d2d11
[18:25:57] -!- Eric______ has quit [Client Quit]
[18:27:08] -!- gentoognuhurd has quit [Ping timeout: 255 seconds]
[18:28:40] <mozmck> I don't understand some things in the PID component. There is a command-deriv pin for velocity, (pid->commandv internally), and a pointer commadvds which is set to pid->commandv after creating the pin.
[18:29:58] <mozmck> This commandvds is set in calc_pid(): *(pid->commandvds) = (command - pid->prev_cmd) * periodrecip;
[18:31:48] <mozmck> ...if index_enable is not true. It seems like this will override the value in pid->commandv - which is an IN pin. Is that true? If so I guess the command-deriv input pin is not used unless index-enable is true.
[18:36:06] <andypugh> pid knows to ignore the last delta when the encoder resets. As far as I know that works.
[18:37:17] <andypugh> But what you might be seeing is some clever code that detects if a pin has been connected in HAL by roundabout means.
[18:40:19] -!- chris_99 has quit [Quit: Leaving]
[18:40:22] -!- motioncontrol has quit [Quit: Sto andando via]
[18:40:45] <andypugh> The pid inputs are described here:
http://sourceforge.net/p/emc/mailman/message/26498770/
[18:41:37] <andypugh> The way that the component detects if the inputs are “wired” is here:
http://sourceforge.net/p/emc/mailman/message/26519176/
[18:41:51] <pcw_home> I know feedback-deriv works that way ( feedback velocity is calculated internally if not connected)
[18:42:40] <mozmck> Interesting. The code seems to look at the index-enable pin to know if it should calculate internally
[18:44:23] <andypugh> That seems odd, you would expect it to look at feedback-deriv
[18:45:23] <mozmck> if(!(pid->prev_ie && !*(pid->index_enable)))
[18:47:22] <andypugh> That looks to be saying “if index enable has not just gone fromtrue to false”
[18:47:23] <pcw_home> for command derivative I dont think there would be any difference between
[18:47:25] <pcw_home> DDT of position and the external joint velocity connected to command-deriv
[18:48:05] <andypugh> So, it’s refusing to calculate a new derivative if there is reason to belive that encoder position has changed.
[18:48:22] <andypugh> (step change, that is)
[18:48:25] <pcw_home> in any case you need to skip calculating the DDT on index-enable falling edge
[18:48:51] <mozmck> what is DDT?
[18:49:12] <mozmck> derivative of distance over time?
[18:49:22] <andypugh> discrete differential wrt time
[18:56:24] -!- erve_ has quit [Remote host closed the connection]
[18:57:15] -!- Contract_Pilot has quit [Ping timeout: 240 seconds]
[18:59:17] <pcw_home> arguably this ( dealing with position steps) should not be done in the PID component
[18:59:19] <pcw_home> ( if machine and encoder coordinates were kept separate, there would never be a step at the control loop level )
[18:59:20] <pcw_home> This would require smart encoder logic that does _not_ reset at index (HM2 encoders are like this, not sure about others)
[19:01:33] <andypugh> Yes, I rather agree. Certainly a PID component looking for index-enable seems too specialised.
[19:12:02] -!- sumpfralle has quit [Ping timeout: 276 seconds]
[19:19:52] -!- PetefromTn_ [PetefromTn_!~IceChat9@75-136-59-160.dhcp.jcsn.tn.charter.com] has joined #linuxcnc-devel
[19:26:30] zeeshan is now known as neverbuya_subaru
[20:03:31] -!- cheetah2 has quit [Remote host closed the connection]
[20:09:49] -!- cheetah2 has quit [Remote host closed the connection]
[20:09:52] <andypugh> So, I am looking into what it takes to add spindle homing to the homing sequence. And it is one of those things that could be done quickly and dirtily in homing.c, or properly by inventing a new spindle_t to match the joint_t and an ini_spindle code in src/emc/ini to read the INI file, and then consider the future possibility of multiple spindles… and then it looks iike a big job.
[20:17:22] -!- Akex_ has quit [Quit: Connection closed for inactivity]
[20:21:45] <mozmck> Does spindle homing refer to orienting the spindle?
[20:23:43] <andypugh> Yes. If the spindle encoder is quadrature then you need to turn it once to find the index before you can orient.
[20:25:28] <mozmck> So is that something that might be needed for a multi-spindle machine?
[20:25:57] <mozmck> What kind of spindle needs that anyhow? Lathe?
[20:26:03] <andypugh> I have no idea :-)
[20:26:26] <andypugh> But every time I assume that nobody will need anything, along comes someone needing it.
[20:26:32] <mozmck> Well, if it never gets used then the quick and dirty method should suffice :-)
[20:26:44] <andypugh> Which reminds me….
[20:26:51] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[20:28:08] -!- rkj has quit [Ping timeout: 265 seconds]
[20:30:11] -!- motioncontrol has quit [Remote host closed the connection]
[20:32:38] <KGB-linuxcnc> 03andypugh 05master b2553ce 06linuxcnc 10src/hal/components/carousel.comp Astonishingly at least one manufacturer thought that BCD was a good way to encode a tool carousel * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b2553ce
[20:34:39] <pcw_home> BCD was very common on old instruments (60's and 70's)
[20:34:40] <pcw_home> Don't X86s have BCD instructions?
[20:35:23] <andypugh> The Z80 certainly has.
[20:35:59] <andypugh> But how many tool carousels need the second digit?
[20:36:45] <pcw_home> A _long_ time ago I made a thermocouple simulator from a TI SR52 calculator
[20:36:46] <pcw_home> I used the printer interface (which used nibble serial BCD) and a 4 digit BCD DAC
[20:36:56] <andypugh> You need 5 sense lines for 10 tools with BCD, whereas yoy can have 15 (or 16) with 4 sense lines and binary.
[20:37:22] <andypugh> A four digit carousel would be a think to see
[20:37:26] <pcw_home> Yeah decimal thinking
[20:38:26] <pcw_home> All this metric stuff has me wondering when they will metrify time
[20:38:52] <pcw_home> Tempits and millitempits
[20:39:14] <andypugh> 1 day = 1 megasecond? (for a smaller second)
[20:40:15] <andypugh> I saw a fairly sensible suggestion to have 13 months of 28 days. And for New Years Day to not belong to any month. (and to have two of them on a leap year)
[20:41:42] <seb_kuzminsky> andypugh, pcw_home: about the pid thing, motion has 'motor-pos-{cmd,fb}' as well as 'joint-', isn't motor-pos what you're looking for? it's unaffected by backlash and screw compensation and home offset
[20:43:36] -!- hm2-buildmaster has quit [Remote host closed the connection]
[20:43:39] -!- linuxcnc-build has quit [Remote host closed the connection]
[20:43:56] -!- hm2-buildmaster [hm2-buildmaster!~hm2-build@174-29-70-49.hlrn.qwest.net] has joined #linuxcnc-devel
[20:43:56] -!- skunkworks has quit [Ping timeout: 255 seconds]
[20:44:15] <andypugh> I was just explaining why pid had index-enable to mozmck. I am not sure what else was being discussed
[20:44:25] -!- linuxcnc-build [linuxcnc-build!~linuxcnc-@174-29-70-49.hlrn.qwest.net] has joined #linuxcnc-devel
[20:45:46] <pcw_home> seb_kuzminsky, maybe... not sure what happens to motor-pos-fb when index is hit
[20:48:57] <pcw_home> maybe the split needs to be done at the encoder level (and motion is OK)
[20:52:35] <pcw_home> For example, the encoder comp (and all hardware encoder drivers I think) reset position on index so you have a step there
[20:52:37] penpen1 is now known as penpen
[20:55:16] <pcw_home> just saying these position steps are patched around in various places when it
[20:55:18] <pcw_home> should be possible to eliminate the steps at the control loop level though
[20:55:19] <pcw_home> this may be difficult with some encoder hardware that only has the option of clearing the count on index
[20:55:38] -!- teepee has quit [Ping timeout: 255 seconds]
[20:56:22] -!- teepee [teepee!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[20:59:25] <mozmck> would there still be an index pulse?
[20:59:53] <pcw_home> sure
[21:00:31] <mozmck> I would think that could be used to keep track of the count internally then
[21:02:07] <pcw_home> To avoid all the PID/motion hacking around pos. fb and pos.cmd thumps the encoder component/driver
[21:02:09] <pcw_home> would have two position outputs one thats reset by index and one thats not
[21:02:57] <mozmck> why one that's reset by index?
[21:03:07] <pcw_home> but as I said this may not work with some encoder hardware thats hardwired to reset on index
[21:04:22] <pcw_home> thats the one that the joint position uses to get a accurate 0 on index (the motor pos fb is never "stepped")
[21:04:44] <pcw_home> just thinking out loud
[21:05:24] <mozmck> I guess I don't understand why the encoder driver can't just see the index pulse and see the 0 count as one more than 4096 (or whatever the max count is)
[21:06:00] <mozmck> I see. Your thinking helps me learn ;-)
[21:10:21] <pcw_home> Some encoder hardware can only reset the count on index (there's no way to avoid a position FB step with this)
[21:10:23] <pcw_home> the Hm2 encoder counter can reset on index or latch on index, with the latch on index option you can have a
[21:10:24] <pcw_home> stepless motor feedback position in addition the a position that was zeroed at the index event (by subtracting the latched offset at index)
[21:18:05] <mozmck> So for that hardware (no index pulse), maybe the driver can be told the max count so when it is on max count and the next goes back to 0 it knows it just moved one step forward.
[21:21:06] <pcw_home> You mean to simulate an index if you dont have one?
[21:21:34] -!- almostworking has quit [Quit: Textual IRC Client: www.textualapp.com]
[21:22:00] <andypugh> mozmck: No help on the first index.
[21:24:18] <cradek> remember the first count you read after an index reset isn't necessarily 0 or 1, it can be 7 or 700, depending on how many counts you happen to be able to move in one servo cycle
[21:24:35] -!- C_P-Away has quit [Ping timeout: 240 seconds]
[21:25:06] <cradek> your servo cycle readings might be 7000 9000 120[with index reset] 2120
[21:26:27] <cradek> the naive ddt would be ... 2000 -8880 (ouch) 2000 ...
[21:26:54] <cradek> with this current pid algorithm of skipping ddt calculations when index resets, you get ... 2000 2000[saved value from last time] 2000 ...
[21:27:01] <andypugh> What are we talking about again? The pid component sees float position feedback. Unless you tell the pid what the encoder scale is, it can’t see counts, raw or otherwise.
[21:27:43] <andypugh> The PID component could usefully reject step changes in feedback position when computing velocity, though.
[21:27:51] -!- cheetah2 has quit []
[21:28:02] <cradek> yes, and it does
[21:28:16] <cradek> I thought that was the question (why does it care)
[21:28:29] <andypugh> So, it probably doen’t need to see the index enable then?
[21:28:47] <cradek> that's how it tells there was (potentially) a position step
[21:29:19] <andypugh> I am saying it could reject position steps based on their amplitude.
[21:29:48] <cradek> yes, if you want to make guesses, I bet you could often get it right
[21:29:55] <cradek> usually, even :-)
[21:30:16] <cradek> but in the homing situation we don't have to guess, and I think that's about the only time we get steps...?
[21:30:21] <andypugh> I don’t even know if you are agreeing with me or arguing with me
[21:31:40] <cradek> I agree with you that it's possible to throw out big steps in joint position on a real machine because you know some things are unreasonable
[21:32:32] <cradek> I'd argue if you said we should replace pid's algorithm with a heuristic, because pid currently doesn't guess and it gets it right even if the unwanted steps are small
[21:32:46] <andypugh> Yes, and that seems like a generic “PID”-ish thing to do. Looking at encoder index isn’t a “PID”-ish thing, it’s a LinuxCNC thing.
[21:34:08] <cradek> I agree, and the more generic the domain the less I'd feel confident saying what inputs are reasonable
[21:35:05] <andypugh> I am not suggesting that we change anything, it’s too late now, but passing the PID an unrelated LinuxCNC-only signal looks inelegant.
[21:35:36] <cradek> I agree it has a bit of a bad smell to it
[21:36:15] <cradek> the ignition coils in my car are failing one at a time. I wish I could remember how many are still original, and which ones they are
[21:36:46] <cradek> last time I bought two and kept a new one in the car - needed it today (a holiday of course)
[21:37:02] <seb_kuzminsky> cradek: i feel like you've taught me before why using motor-pos-cmd instead of joint-pos-cmd as the pid input is not an alternative to having pid see index-enable
[21:37:03] <andypugh> Rejecting any step bigger than maxerrorD would look like it was intentional, and I bet nobody has ever used that pin ;-)
[21:37:19] <seb_kuzminsky> but i dont remember the reason
[21:37:44] <mozmck> Oops, I stepped away - reading back...
[21:38:59] <pcw_home> My modest suggestion is that its the encoder comps/drivers problem (and if fixed there, no one else (motion, PID) need deal with it)
[21:40:27] <cradek> brb
[21:40:44] <pcw_home> the fly in that particular ointment is that it may not be easily fixable with encoder hardware that only has clear -on-index capability
[21:41:41] <mozmck> For a hardware encoder that resets on index, I'm assuming you mean there is no index pulse. When the encoder is first powered up and it is in the middle of a turn, does it know that? Or does it start counting from where it is?
[21:46:01] <pcw_home> No, I mean hardware that resets the raw position count on index
[21:47:33] <mozmck> By index pulse - I mean one that gets back to linuxcnc. If linuxcnc can see the index pulse then it can know that the count was just reset.
[21:49:22] <pcw_home> Typically this is done by either latching the count or reseting the count on index, and setting/clearing a
[21:49:24] <pcw_home> flag to indicate this has happened
[21:49:26] <andypugh> pcw_home: If such an encoder existed, would LinuxCNC actually see the index-enable go false?
[21:50:09] <pcw_home> yes, it needs this for homing and spindle synchronized moves
[21:50:36] <pcw_home> just sayin the position with the step need not be the one used for PID
[21:51:28] <andypugh> So, you set a hardware line high to request an index reset, then a separate hardware line is taken high to indicate that the encoder complied? It would be fune to interface that to a HAL bidirectional pin.
[21:52:27] <pcw_home> none of that need change
[21:52:50] <pcw_home> (though I really dont care for the bidirectional pin)
[21:54:19] <pcw_home> All I am saying is that there are a fair amount of workarounds for the step in position
[21:54:21] <pcw_home> feedback at index which might all be avoided by eliminating that step up stream
[21:59:03] <andypugh> Oh, I agree, but we are caught in the age-old problem, changing it now would break working machines.
[22:00:26] -!- anomynous has quit [Ping timeout: 250 seconds]
[22:02:11] <pcw_home> Yeah, and the work-arounds do work...
[22:03:05] <seb_kuzminsky> i think it's ok to break working machines, on major releases (eg 2.6 -> 2.7), and with documentation (eg our "Updating your configs" section in "Upgrading LinuxCNC")
[22:03:22] <seb_kuzminsky> if it makes things better/simpler in the long run, i say bring it on
[22:03:40] <andypugh> It just makes things prettier in a layer users never see.
[22:03:44] -!- anomynous_ has quit [Ping timeout: 256 seconds]
[22:04:15] <seb_kuzminsky> true
[22:04:28] <seb_kuzminsky> but it's a layer developers and integrators see, so it still has value
[22:04:35] <seb_kuzminsky> bbl
[22:10:24] -!- anomynous has quit [Ping timeout: 250 seconds]
[22:11:15] -!- anomynous_ has quit [Ping timeout: 240 seconds]
[22:15:35] -!- anomynous has quit [Ping timeout: 240 seconds]
[22:17:28] -!- chillly has quit [Remote host closed the connection]
[22:29:20] -!- Deejay has quit [Quit: bye]
[22:45:09] <jepler> I got no negative feedback about the idea of transferring linuxcnc-mirror to the linuxcnc organization on github. I think we should go ahead and do it,
[22:45:21] <jepler> I think there was also a consensus to open the bugtracker there and close the sf tracker to new requests
[22:45:54] <jepler> .. as a further step, we should also install a hook on glo to update github immediately instead of with a hour delay
[22:45:58] <JT-Shop> sounds good to me
[22:47:08] <jepler> I think that as cradek is the creator of the linuxcnc github organization I'll need his time to do the transfer & rename step. so I've sent him a ping privately as well.
[22:47:10] -!- tannewt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
[22:49:50] <jepler> as far as encoder index goes, I think that there's a better design that would work for encoder with latch (like hostmot2) but I think that not all encoders have this. I think pico is an example of this type
[22:50:21] <jepler> so we do need room for both kinds of index, even if we find a way to integrate latch-based (rather than reset-based) index pulse to homing and threading
[22:50:59] <jepler> way back in the day, 24 bit floats meant that reset on index was good design so you didn't totally lose precision on your spindle -- you got back to best possible precision at the beginning of each thread
[22:53:38] <jepler> 24-bit-mantissa floats
[22:54:40] <archivist> reset on index seems to assume the encoder will keep the width within an amount, do ALL encoders do that
[22:55:35] <jepler> I'm not sure what you mean by "width".
[22:56:32] <archivist> number of edges from AB during the index
[22:57:06] -!- tlab has quit [Quit: Leaving]
[22:57:29] <jepler> oh
[22:57:38] <pcw_home> not sure about other designs but the HM2 encoder latches or resets only once
[22:57:50] <jepler> so you mean, if you made your "Z" track half a rotation is it useless?
[22:58:55] <jepler> an index pulse that is "wide" in that way would still be useful for homing or threading as long as you consistently approach it from the same direction
[22:59:45] <jepler> but I think that in a traditional commercial encoder, the index pulse is narrow, 1 cycle or less of A or B
[22:59:47] <archivist> solid tapping is both directions, I hope the code is right :)
[23:00:05] <pcw_home> doesn't index detection clear index enable?
[23:00:18] <jepler> pcw_home: yes
[23:00:40] <pcw_home> so it will just detect the leading edge
[23:00:53] <jepler> yes
[23:01:10] <Roguish> hey, we're all obsolete now:
http://build.slashdot.org/story/15/12/31/2212240/2016-is-the-year-of-buying-cnc-tools-instead-of-building-them
[23:02:11] <jepler> heh
[23:02:26] <archivist> clueless slashdotters
[23:02:36] <jepler> I'm primarily a software guy, so if my next toy to be driven by linuxcnc comes nearly assembled that's fine by me
[23:02:58] buna is now known as A_Nub
[23:03:11] <jepler> some of my least favorite things include dealing with crimp tools and making nice permanent installations of circuit boards and cabling
[23:03:27] <archivist> I only build, I cannot buy in my price range usually
[23:05:15] -!- anomynous_ has quit [Ping timeout: 240 seconds]
[23:06:26] <jepler> sounds sensible
[23:07:14] <jepler> I'm just buying AND building less than I once did
[23:07:56] <jepler> though 2015 may have been a record for *number of* complete linux computers purchased, it certainly was no where near the maximum dollars spent per year on linux computers
[23:07:59] <jepler> (for me)
[23:10:17] -!- almostworking has quit [Quit: Textual IRC Client: www.textualapp.com]
[23:14:57] <andypugh> I rather like crimp tools. I have lots of them.
[23:15:24] <andypugh> I kike to have the right tool for every connector. I need to find one for the small-yellow pre-insulated size
[23:16:26] <jepler> it may be a case where I don't have good enough tools
[23:19:01] <andypugh> Well, I don’t spend lots, which is why I don’t have the small-yellow crimper. The only one I found was £400
[23:26:16] -!- Camaba has quit [Read error: Connection reset by peer]
[23:34:35] -!- Tristitia has quit [Ping timeout: 246 seconds]
[23:35:30] -!- Einherjer has quit [K-Lined]
[23:36:35] <jepler> the only way I'd own that expensive a crimper is by inheritance
[23:39:14] -!- basiclaser has quit [Quit: Connection closed for inactivity]
[23:50:02] -!- JT-Shop has quit [Read error: Connection reset by peer]
[23:50:06] -!- jthornton- has quit [Read error: Connection reset by peer]
[23:51:03] -!- jthornton- [jthornton-!~john@172.243.171.57] has joined #linuxcnc-devel
[23:52:29] -!- JT-Shop [JT-Shop!~john@172.243.171.57] has joined #linuxcnc-devel
[23:57:00] -!- CP-KG7AMV has quit [Ping timeout: 250 seconds]
[23:57:26] -!- MacGyverX has quit [Ping timeout: 250 seconds]
[23:59:24] -!- logger[mah] [logger[mah]!~loggermah@mah2.mah.priv.at] has joined #linuxcnc-devel