Back
[00:50:48] <linuxcnc-build> build #117 of 4017.deb-wheezy-armhf is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/117 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[01:05:31] <linuxcnc-build> build #130 of 1401.rip-wheezy-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-amd64/builds/130 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[01:08:06] <linuxcnc-build> build #129 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/129 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[01:40:46] <linuxcnc-build> build #1973 of 1200.rip-lucid-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/1973 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[01:41:03] <linuxcnc-build> build #1972 of 1300.rip-precise-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/1972 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[01:42:18] <linuxcnc-build> build #1974 of 1306.rip-precise-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/1974 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[01:45:46] <linuxcnc-build> build #1176 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/1176 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[02:00:36] <linuxcnc-build> build #1974 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/1974 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[02:04:30] <linuxcnc-build> build #1975 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/1975 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[02:04:30] <linuxcnc-build> build #1976 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/1976 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[06:17:21] <memleak> i have the root filesystem with gnome 2 down to 2.1GB
[12:45:58] <Connor> okay, so who maintains the hostmot2 drivers ?
[12:47:46] <Connor> Need a new feature.. need to add a index_mask to encoder -- defaults to HIGH.. value gets ANDED with z-index input pin..
[12:49:28] <seb_kuzminsky> hi connor
[12:49:39] <Connor> seb_kuzminsky: Hello.
[12:50:09] <Connor> Talking with pcw_home, we have a machine with a 2:1 motor / encoder arrangement.
[12:50:18] <Connor> Uses a 180 out sensor to "mask" the z-index
[12:50:35] <Connor> this could be handled with hardware, or software..
[12:50:50] <Connor> if in software, would be available to others to use, for this type of setup..
[12:51:30] <seb_kuzminsky> do you just use the index for homing? or is it for spindle orientation? or something else?
[12:51:35] <Connor> 01:26:53 PM) Connor: pcw_home: Wouldn't we need some sort of pin or parameter to enable z-index mask ?
[12:51:36] <Connor> (01:27:34 PM) pcw_home: it could default to enabled
[12:51:41] <Connor> spindle orientation
[12:51:45] <Connor> (01:28:04 PM) Connor: so, default it to high.. then no need to have a enable pin..
[12:51:45] <Connor> (01:30:07 PM) pcw_home: but its a bit tricky since the drive would have to enable and disable
[12:51:45] <Connor> (01:30:09 PM) pcw_home: the hardware index enable bit in the CCR and not report index detected status if masked
[12:52:13] <Connor> He lost me the enable bit and CCR and not report index detected....
[12:52:30] <seb_kuzminsky> hmm, yeah i dont understand that either
[12:52:54] <Connor> put, the reset of it is pretty straight forward.. add a new pin.. default it to high..
[12:53:06] <Connor> AND it against the z_index pin
[12:53:19] <Connor> and, bob's your uncle..
[12:54:22] <Connor> we would the tie the index_mask pin to a GPIO or Encoder pin used for the 180 sensor.. and it should work.
[12:54:57] <Connor> Is this something that could easily be done?
[12:55:36] <Connor> The machine this is running on is already running master branch.. so, once it's coded could be tested rather quickly.
[12:56:35] <seb_kuzminsky> are you proposing an index-mask input pin to the hm2 encoder driver, driven by the 180 sensor on your encoder? so that the hm2 encoder would mask out any index pulses while the 180 sensor said to, and allow index pulses when the 180 sensor says to?
[12:56:53] <Connor> that's exactly what I'm proposing.
[12:57:51] <seb_kuzminsky> hmm, dont we already have that? i'm looking at the hostmot2 manpage, encoder section, and it describes what i think i said above
[12:58:21] <seb_kuzminsky> (bit r/w) index-mask
[12:58:22] <seb_kuzminsky> If set to True, the Index input pin only has an effect if the Index-Mask input pin is True (or False, depending on the index-mask-invert pin below).
[12:59:11] <seb_kuzminsky> so there's an input on the screw terminal that would take the output of the 180 sensor, then you'd tell the hm2 driver to pay attention to that input by using the index-mask hal pin
[12:59:35] <seb_kuzminsky> i think that feature needs special firmware support that's maybe not present in all the hm2 firmwares we ship currently
[12:59:43] <seb_kuzminsky> peter might know about that part
[12:59:48] <seb_kuzminsky> bbl
[13:04:29] <pcw_home> Well yes but this is a sort of funny situation where the mask is a 24V prox so it the driver had a mask pin it would be more convenient
[13:29:37] <memleak> looks like gentoo disk might have to be a live dvd..
[14:20:47] <KGB-linuxcnc> 03Francis Tisserant 05v2.5_branch b73e4d5 06linuxcnc 10docs/src/config/ini_homing_fr.txt French doc. update to follow John * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b73e4d5
[14:54:14] <seb_kuzminsky> pcw_home: is that because the servo interface daugter boards do not have 24V-tolerant inputs?
[15:25:42] <PCW> seb_kuzminsky: yes basically there is a 24V proximity sensor on the spindle shaft that's
[15:25:44] <PCW> on for 1/2 turn that is needed to mask the index of the encoder on the motor (which runs at 2X spindle speed)
[15:27:03] <PCW> probabl level shifting could be used to connect to a encoder input but since 7I77 encoder inputs are muxed this would require driver support of muxed index masks
[15:27:46] <seb_kuzminsky> PCW: the 7i33 doesn't even have a mask input afaict
[15:28:18] <PCW> Yeah it would have to steal a existing encoder pin
[15:28:28] <seb_kuzminsky> dont you publish firmwares with index mask inputs? how do those work? they run the mask into another 50-pin connector?
[15:28:49] <PCW> Yes the existing ones do
[15:31:08] <PCW> but this particular problem is on a 7I77
[15:31:09] <PCW> (I figured out a squirrely workaround by looping back a GPIO pin to the index mask pin on a unused FPGA connector)
[15:32:04] <seb_kuzminsky> if we bring the index mask input up into hal and then back down to the fpga, the speed tops out at 1 revolution per 2 servo cycles, right? 500 rps in the common case, i guess that's fine for a spindle...
[15:32:59] <PCW> Yeah not many encoders will spin that fast
[15:33:12] <seb_kuzminsky> you'd define a new encoder firmware module that would have an index-encoder-is-masked register somewhere, that'd be poked from hal?
[15:33:58] <PCW> thats one way (its possible without new firmware but ugly)
[15:36:13] <PCW> (the driver would have to enable/disable the hardware index enable based on the software mask (and ignore index state when masked because it would look like index had occurred )
[15:36:31] <seb_kuzminsky> or the mask gpio input from the sensor could twiddle the index-enable input to the driver? sensor-input AND (whatever the motion pin is that looks for index) => hm2.encoder.index-enable?
[15:36:58] <seb_kuzminsky> right, i think we just said the same thing
[15:38:49] <PCW> Yeah a bit ugly (better would be a added software settable bit that actually masked the index so you have a software and hardware mask bit)
[15:39:43] <PCW> and avoid messing with any state sensitive logic
[15:40:08] <PCW> well i think the loopback method will work for now
[15:40:48] <PCW> (now if hm2 only had some internal loopback I/O ports)
[15:45:04] <linuxcnc-build> build #118 of 4017.deb-wheezy-armhf is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/118 blamelist: Francis Tisserant <tissf@free.fr>
[15:52:14] <memleak> RTAI 3.10 support added to github
[15:52:44] <memleak> most of livecd completed but will not be finished until some time next week to ensure stability
[15:53:08] <memleak> will work on 3.12 kernel after i take a break for a moment
[15:53:57] <andypugh> Good work
[15:54:52] <memleak> was up until about 6 last night because i'll be taking off for the weekend
[15:54:59] <memleak> thanks andypugh :)
[15:56:40] <memleak> micges was asking about it so if you see him.
[16:07:51] <PCW> Thanks memleak its really great that you are doing this
[16:09:53] <PCW> well and all thanks to all linuxcnc developers
[17:56:58] <memleak> micges, hello!
[17:57:10] <micges> hi
[17:57:43] <memleak> 3.10 support added to github tree
[17:59:26] <micges> cool
[17:59:44] <memleak> zultron, you fixed RTAI 64-bit support too: mail.rtai.org/pipermail/rtai/2014-March/026296.html
[18:00:07] <memleak> you know your stuff :)
[18:02:17] <zultron> Heh, I can find my way around google. Glad you're getting that to work.
[18:14:41] <memleak> wow cloning the linuxcnc tree with --depth 1 really speeds it up
[18:51:20] <KGB-linuxcnc> 03Robert W. Ellenberg 05circular-blend-arc-rc3 b792020 06linuxcnc 10src/emc/tp/tp.c Refactored vLimit into target velocity calculation * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b792020
[18:51:20] <KGB-linuxcnc> 03Robert W. Ellenberg 05circular-blend-arc-rc3 aa33487 06linuxcnc 10src/emc/ini/initraj.cc Added default max feed scale value * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=aa33487