Back
[06:50:30] <skunkworks_> this looks odd to say the least.
https://www.youtube.com/watch?v=sCW1vRKl3AE
[06:52:05] <archivist> looks like he does not give it room and seemed to hit something
[06:52:37] <skunkworks_> http://linuxcnc.org/index.php/english/forum/40-subroutines-and-ngcgui/29451-rigid-tapping-fail-advice-and-qdiscriminantq-err?limitstart=0
[06:53:06] <skunkworks_> it almost seems like it pulls the spindle out for a second
[06:53:55] <archivist> it is pulled out the collet a bit
[06:54:39] <skunkworks_> I asked for the all his config files. almsost seems mis-configured.
[06:55:15] <archivist> and wrong type of tap for blind hole
[06:58:41] <archivist> I hate the latency in youtube videos, you lose detail
[07:00:12] <archivist> he should start further away to allow the spindle to get up to speed before the tap touches
[07:53:05] <Tom_itx> skunkworks, the work pulls out of the collet
[07:53:21] <Tom_itx> err nm archivist figured it out first
[08:00:59] <skunkworks_> so - either missing steps or misconfigured..
[08:30:19] <cradek> it'd be nice to see a plot of motion.spindle-pos vs Z pos over the whole cycle
[08:30:42] <cradek> both reversals look wrong to me
[08:33:03] <cradek> and the gcode, of course
[08:41:48] <skunkworks_> zlog,
[08:42:17] <skunkworks_> this is the gcode
[08:42:18] <skunkworks_> http://pastebin.com/GJpsCA3W
[09:00:41] <cradek> looks fine, doesn't it
[09:02:08] <cradek> I bet the spindle feedback is bogus somehow
[09:02:39] <skunkworks_> he is going to post the configs later..
[09:02:42] <cradek> although I don't know what that error means - it might be a bug, I dunno
[09:03:05] <cradek> yeah the configs and a plot would be great
[09:03:15] <skunkworks_> rob thought that was a red hearing - that small of a discriminat error would not cause and issue.
[09:03:35] <skunkworks_> (and it doesn't happen all the time)
[09:03:43] <cradek> I thought for tapping it just switched to the old planner
[09:04:02] <skunkworks_> I think the error was for one of the pre-post movements.
[09:04:09] <cradek> aha
[09:04:38] <skunkworks_> (I could not get it to do it in sim - playing with the spindle mass.
[09:05:36] <cradek> yeah I don't trust his spindle encoder until I see a plot
[09:06:41] <skunkworks_> so a plot of spindle position vs z axis?
[09:07:15] <cradek> is it motion.spindle-revs? spindle-pos? the one right from the encoder
[09:07:26] <cradek> yeah vs Z position
[09:07:35] <archivist> or both :)
[09:07:50] <cradek> there's only one - I forget its name
[09:08:33] <skunkworks_> motion.spindle-revs
[09:08:41] <cradek> you're faster than me :-)
[09:08:53] <skunkworks_> google is awesome fast
[09:09:25] <archivist> cheat
[09:10:06] <cradek> 21 float IN 0 motion.spindle-revs <== spindle-pos
[09:10:11] <cradek> 21 float OUT 0 axis.2.motor-pos-cmd ==> Zpos
[09:32:31] <skunkworks_> rob pushed some fixes to his branch. testing now.
[10:56:16] <skunkworks_> dad had a 1hp motor burn up on the k&t.. may have been slightly undersize.. (but it has been running that way for years)
[10:56:31] <skunkworks_> he is replacing it with a 1.5hp motor
[10:57:01] <skunkworks_> (the whole machine originally ran on 1 25hp motor. Now it runs on 2 <5hp motors
[11:02:00] <skunkworks_> omg... It is christmas
[11:06:22] <skunkworks_> http://electronicsam.com/images/KandT/testing/mesanew.jpg
[11:24:36] <jepler> skunkworks_: are you going to test those two 7i92s on the same computer?
[11:25:30] <jepler> if so, use branch (origin/)jepler/hm2-eth-startup for the latest fixes .. which I need to make sure are in shape for seb to review and get into 2.7.
[11:25:50] <skunkworks_> jepler, I can sure do some testing.
[11:28:24] <jepler> skunkworks_: you should use a gigabit hub if available
[11:30:02] <skunkworks_> I also have a motherboard with 2 nics if that would help
[11:33:10] <skunkworks_> again - 2.7 is going to be awesome
[11:34:10] <skunkworks_> So far the fixes rob put in are 99.9% there was a 3% overage in acceleration. (still better than the current tp... heh heh heh)
[11:40:54] <jepler> > Project IceStorm aims to change that by reverse-engineering some Lattice FPGAs to produce an open-source toolchain, and today it passed a milestone. The J1 open-source CPU is building under IceStorm, and running on real hardware.
[11:48:37] <seb_kuzminsky> jepler: i saw that, very cool
[11:50:47] <jepler> website seems to be
http://www.clifford.at/icestorm/
[12:05:06] <skunkworks_> I don't understand what that is.
[12:07:00] <seb_kuzminsky> it's an open-source tool chain for building vhdl into fpga bitstreams
[12:07:23] <skunkworks_> huh
[12:07:23] <seb_kuzminsky> it was on HaD today:
http://hackaday.com/2015/07/28/open-source-fpga-toolchain-builds-cpu/
[12:08:10] <seb_kuzminsky> unfotunately their dev board only has a few pins brought out, and some of them would probably have to be used for a SPI port
[12:10:46] <skunkworks_> ah - so instead of using say xilinx's software - you could use some open source
[12:10:56] <skunkworks_> (if that was mapped)
[12:14:36] <skunkworks_> jepler, your branch also does the iptables/disabling ip6 and such?
[12:15:06] <skunkworks_> hmm - almost looks like it does it in 2.7 already looking at the man page
[12:15:25] <skunkworks_> cool
[12:16:47] <skunkworks_> 2.7 says it only supports the 7i80 varients. Is that true? is the 7i92 supported?
[12:17:21] <seb_kuzminsky> skunkworks_: the iptables/ipv6 stuff went in to 2.7 already
[12:18:43] <seb_kuzminsky> skunkworks_: yep, micges added support for 7i92 almost a year ago
[12:19:42] <skunkworks_> did I mention 2.7 is going to be epic!?
[12:20:48] <seb_kuzminsky> heh
[12:21:07] <seb_kuzminsky> yeah, it's going to be pretty sweet, if we ever get it released ;-)
[12:22:19] <mozmck> yeah, people should quit finding bugs!
[12:23:37] <seb_kuzminsky> heh
[12:23:51] <seb_kuzminsky> i heard someone found the last bug the other day, i was relieved
[12:24:01] <mozmck> oh, yes, that's good ;)
[12:25:28] <skunkworks_> :)
[12:26:16] <skunkworks_> so far so good with robs fixes.. A violation popped up but I think it could be let passed..
[12:26:35] <mozmck> Or we could just do like some other software I've heard of, and just release bugs and all.
[12:27:02] <seb_kuzminsky> well we *do* have like 400 open bug reports on the SF tracker...
[12:27:10] <mozmck> Or just quit having releases - it's too much work. People can just compile master and install it.
[12:27:16] <skunkworks_> 300 in/s^2 peaked at 309...
[12:27:17] <seb_kuzminsky> haha
[12:28:11] <mozmck> Kicad did that for a while, and it has not helped anything :)
[12:28:29] <seb_kuzminsky> bet it helped the developers' sanity
[12:28:43] <seb_kuzminsky> or free time or something
[12:29:00] <mozmck> Well, until everyone starts complaining and wondering what's going on.
[12:29:26] <seb_kuzminsky> yep
[12:30:02] <mozmck> The next release will have major updates and usability gains.
[12:30:38] <seb_kuzminsky> i agree, the 2.7 branch has some really sweet stuff from lots of people, and it's going to be really good for our users
[12:30:53] <seb_kuzminsky> we'll finish polishing it up and get it out soon, i'm not really as depressed as i sound ;-)
[12:31:09] * seb_kuzminsky <-- complainer
[12:34:43] <mozmck> :) I was being facetious - you didn't sound too depressed
[12:35:40] <mozmck> I rather like that we try and fix major bugs in a program that moves tons of machinery and sharp spinning things at high speeds.
[12:36:16] <seb_kuzminsky> yeah, i like that pattern in our community as well
[12:36:21] <mozmck> Makes me glad the *other* software seems to focus mostly on 3d printers and desktop stuff :)
[12:40:33] <seb_kuzminsky> i guess we can bask in the reflected light from this:
http://www.tormach.com/blog/6-things-we-didnt-expect-pathpilot/
[12:43:58] <mozmck> Nice!
[12:45:33] <seb_kuzminsky> yeah, yay for happy users making things easily & reliably
[12:46:31] <Tom_itx> skunkworks, i wonder if that lathe rigid tap video is a case of a loose collet
[12:46:54] <Tom_itx> using the wrong tap would cause extra strain on the material grip
[12:49:21] <cradek> a solid 4/6 of those are linuxcnc features, not pathpilot features
[12:52:24] <Tom_itx> Customers have been telling us about their lowered inhibitions to trying new operations, thanks to the responsiveness of PathPilot.
[12:52:40] <Tom_itx> i'd hate to own software i couldn't trust to do it's job
[12:54:15] <seb_kuzminsky> the responsiveness thing is a huge confidence-booster for cnc software, and that makes me hope norbert/niemand fixed
http://sourceforge.net/p/emc/bugs/427/ soon
[12:55:14] <mozmck> Not linuxcnc specific here: I just tried to change the IP to 10.10.10.1 for a computer in /etc/network/interfaces using the exact same config that has worked in several other computers, but this one tells me it couldn't configure the network and ifup says "Cannot find device "eth0"
[12:56:07] <Tom_itx> did you do a restart?
[12:56:18] <mozmck> any ideas why that might be? I have only the onboard network card, and it worked fine connected to the network getting an address via dhcp
[12:56:20] <mozmck> Yes
[12:56:42] <mozmck> That's when it told me it couldn't configure the network fully
[12:56:49] <Tom_itx> what's the hardware list show for eth?
[12:56:51] <seb_kuzminsky> "ifconfig -a" will list all the network interfaces, maybe it has a different name than the expected eth0
[12:57:06] <mozmck> oh, eht1
[12:57:09] <mozmck> eth1
[12:57:21] <mozmck> I ran ifconfig, didn't know about the -a option
[12:57:48] <seb_kuzminsky> ifconfig by default only shows interfaces in the "up" state
[12:58:14] <mozmck> That is a problem. I need to force the name to stay the same somehow. Can have the name changing if someone puts another network card in or changes something minor like that.
[12:58:24] <mozmck> Can't have it that is...
[12:58:33] <mozmck> I see, thanks!
[12:59:12] <seb_kuzminsky> mozmck: there's a mechanism to assign persistent names to interfaces based on their mac, instead of their hardware enumeration order
[12:59:29] <mozmck> I have seen something about that in the past - looking it up now.
[12:59:37] <seb_kuzminsky> look in /etc/udev/rules.d/70-persistent-net.rules
[12:59:39] <seb_kuzminsky> if you're on wheezy
[13:00:02] <mozmck> Nope, wheezy is... too wheezy. I'm running Xubuntu 14.04
[13:00:20] <seb_kuzminsky> it might be similar? i dont know
[13:00:41] <mozmck> probably - I've seen that rule name before.
[13:01:02] <mozmck> http://www.cyberciti.biz/faq/howto-linux-rename-ethernet-devices-named-using-udev/
[13:01:28] <cradek> yeah it's a feature that the interface name sticks to the particular interface
[13:01:45] <mozmck> a missing feature?
[13:01:58] <cradek> to the *hardware*
[13:02:26] <cradek> if you want it to forget, just remove the lines from 70-persistent-net.rules
[13:03:18] <mozmck> Or install a new card, or change to a static IP apparently.
[13:03:43] <cradek> I must not being clear
[13:03:47] <cradek> the name sticks to the hardware address
[13:03:59] <cradek> if you change the hardware, you get a new name; if you put the old hardware back, you get the same name it had before
[13:04:12] <mozmck> But it did not just now for me.
[13:04:26] <cradek> say what you did again?
[13:04:58] <cradek> ok I read back
[13:05:18] <mozmck> Yeah, basically 3 lines in interfaces to make a static IP
[13:05:30] <cradek> this machine previously had a network card in it, that old card that is now gone got named eth0, and that's remembered in 70-persistent-net.rules
[13:05:49] <cradek> so the card that's in it now got named the next free name
[13:06:13] <mozmck> Ah, that could be.
[13:06:37] <cradek> so if you want it to forget the old eth0 card that's now gone, remove its line from that file
[13:06:39] <mozmck> I see two lines in 70-persistent-net.rules
[13:06:53] <cradek> yes one for the old card at eth0, one for the new card at eth1
[13:07:01] <cradek> remove them both and reboot and you'll get a new eth0 entry
[13:07:39] <cradek> haha: cradek> I must not being clear
[13:08:21] <mozmck> I just deleted the eth1 line and changed the other to match the card.
[13:08:56] <cradek> I've only ever deleted lines
[13:09:12] <cradek> that feature hurts me more than it helps me, but that's probably because I don't really use laptops/hotplug/etc
[13:09:13] <mozmck> That looks better! Thanks for the help again.
[13:09:16] <cradek> welcome
[13:09:56] <mozmck> Before they had that on debian I had the order change on me sometimes seemingly randomly, and it was a pain.
[13:10:05] <mozmck> I about forgot about those days :)
[13:10:24] <cradek> yeah that's what it's meant to avoid
[13:17:53] <cradek> huh, now tormach has a smaller mill with 10krpm spindle
[14:56:48] <skunkworks_> jepler, your branch loaded a 7i92+5i25
[14:56:52] <skunkworks_> so far
[14:56:53] <skunkworks_> :)
[15:13:45] <skunkworks_> http://pastebin.com/bQy3rM0M
[15:14:20] <skunkworks_> that is if I do a Board_ip"10.10.10.10,192.168.1.121" (paraphrasing)
[15:14:36] <skunkworks_> I have the 2 cards hooked to 2 nics
[15:14:42] <skunkworks_> I can ping both
[15:15:38] <seb_kuzminsky> hm
[15:18:44] <seb_kuzminsky> do you know if it's the first or second board that fails?
[15:19:47] <seb_kuzminsky> i wonder if hm2_eth is prepared to deal with two nics?
[15:21:57] <skunkworks_> i may not have the nic setup correctly
[15:21:58] <skunkworks_> hold on
[15:23:09] <PCW> wonder if the iptables setup stuff works with two MACs
[15:23:44] <seb_kuzminsky> PCW: +1
[15:26:06] <skunkworks_> yah - I can load one - or the other. not both
[15:26:48] <skunkworks_> you only have 1 mac when hooked to a switch?
[15:27:57] <seb_kuzminsky> skunkworks_: you're on master, it doesn't have hm2-eth-multiple in it yet
[15:28:01] <seb_kuzminsky> go to 2.7
[15:28:06] <seb_kuzminsky> i'll merge it
[15:28:14] <PCW> thats what i have been testing MAC -->GE switch --> 2 cards
[15:28:35] <PCW> but yes 2.7
[15:29:04] <skunkworks_> seb_kuzminsky, I am on jepler (origin/)jepler/hm2-eth-startup
[15:29:29] <skunkworks_> which should have all that..
[15:29:40] <skunkworks_> if I understand it
[15:29:57] <PCW> dont think 2 MACS was tested
[15:30:54] <skunkworks_> going to have to wait until tomorrow.
[15:30:55] <skunkworks_> bbl
[15:31:40] <seb_kuzminsky> huh
[15:31:53] <seb_kuzminsky> you're right, it does have the hm2-eth-multiple stuff in it
[15:32:14] <seb_kuzminsky> but your pasted output says 2.8.0~pre1, which is master
[15:32:23] <seb_kuzminsky> are you sure you're running the version you think you are?
[15:32:27] <seb_kuzminsky> i'm talking to myself
[15:50:44] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 77eb37d 06linuxcnc 10(6 files in 4 dirs) Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=77eb37d
[16:02:48] <skunkworks> zlog
[16:04:30] <skunkworks> seb_kuzminsky: when I do git branch - it shows jepler/hm2-eth-startup (asteric next to it)
[16:04:49] <skunkworks> I did a git checkout -b jepler/hm2-eth-startup
[16:05:23] <seb_kuzminsky> skunkworks: something is wrong on your side i think
[16:05:38] <seb_kuzminsky> in that checkout dir, what does your /VERSION file say?
[16:05:42] <seb_kuzminsky> i bet 2.7.0~pre6
[16:06:02] <seb_kuzminsky> but in the text you pasted, it says you're running 2.8.0~pre1, which is master
[16:06:23] <skunkworks> I will have to check tomorrow
[16:06:38] <seb_kuzminsky> ok
[21:32:57] <dgarr> seb_kuzminsky: re path search for emccalib etc., i added one more patch for consistency of path search, let me know if you want these in 2.7
http://www.panix.com/~dgarrett/stuff/28jul15.mbox
