Back
[00:02:44] <mshaver> I think it's less than 1000
[00:04:15] <mshaver> it's this:
http://www.siegind.com/CNC_MACHINE/KC6_SIEG.html
[00:05:09] <mshaver> of course they can only do 79"/min :)
[00:16:00] <mshaver> if I get it to work right, I should be able to thread down to 13tpi at 300rpm (max spindle speed)!
[00:17:01] <mshaver> 3000rpm
[01:22:08] <cradek> for some reason I thought matt was working on an HNC
[01:22:22] <cradek> looks like a similar size machine though
[01:23:25] <jtr> 395 Kg?
[01:23:48] <cradek> ok, similar travel :-)
[01:24:19] <cradek> wow, that's some poor English
[01:24:49] <jtr> I wonder what they're substituting for mass?
[01:25:57] <fenn> he was working on an HNC at one point, it's not on his page anymore though
[01:26:09] <fenn> using PPMC
[01:26:10] <cradek> I wonder if that's with the stand/box
[01:26:21] <cradek> oh right, I wondered why it had steppers on it
[01:26:24] <cradek> now this makes more sense
[01:28:51] <cradek> I wonder what 'Max pitch of strand (Z) = 4 Nm' means
[01:29:36] <cradek> it says it has a 10" swing, but X can move 4.3"
[01:32:19] <cradek> ohhh
[01:32:29] <cradek> I bet they mean maximum thread pitch is 4mm
[01:34:20] <jepler> $ units '(500mm/min)/100rpm' 'mm/revolution'
[01:34:21] <jepler> * 5
[01:34:56] <jepler> doesn't quite match their feed numbers
[01:37:54] <jtr> cutting force in x and z?
[01:40:12] <cradek> it could be a control issue - other stuff there sure is
[01:40:47] <cradek> strand has just got to be a bad translation of thread
[01:43:37] <jtr> just having a hard time with threads along the x axis...
[01:47:25] <cradek> well yeah.
[01:51:05] <jepler> there are lots of hits for "max pitch of strand"
[01:51:37] <jepler> #
[01:51:37] <jepler> #
[01:51:37] <jepler> Air Wrenches Products from Manufacturers & Suppliers, Air Wrenches ...
[01:51:37] <jepler> Features: 1) Free speed: 7000rpm2) Average air consumption: 4.00cfm3) Max. pitch of strand: 230ft-lb4) Rotation type: rocking dog
[01:52:15] <jepler> also this datasheet has "max strand" for the mill:
http://emergent.unpy.net/index.cgi-files/sandbox/kx3a-kc6a.jpg
[01:52:19] <jepler> "datasheet" ha
[01:57:08] <fenn> google translate Chinglish->English
[01:58:07] <jepler> well the chinese that they translate "pitch of strand", google translates "from the twisted rope".
http://translate.google.com/translate?hl=en&sl=zh-CN&u=http://www.eruipu.com/html/2007-07/499.htm&sa=X&oi=translate&resnum=9&ct=result&prev=/search%3Fq%3D%2522pitch%2Bof%2Bstrand%2522%2B%2522torque%2522%26hl%3Den
[01:59:28] <fenn> holy crap a chinglish dictionary
[02:02:10] <fenn> everything on that page contains "itch"
[02:02:37] <fenn> well, "itc"
[02:03:44] <jepler> I wish I knew somebody who knew chinese.
[02:04:21] <jepler> http://www.mandarintools.com/cgi-bin/charlook.pl?searchmode=standard&printtype=utf8&chartype=all&ordering=frequency&display=char&display=radstroke&display=strokes&display=pinyin&display=english&display=variants&display=unicode&english=&pinyin=&cantonese=&enctype=utf8&whatchar=绳索绞距&searchchar=Search+by+Character&lowerb=&upperb=
[02:05:52] <jepler> it so consistently comes up with torque units near it that it must be torque
[02:08:02] <jepler> but that's none of the same letters as what google translates (forward and back) as torque:
http://www.mandarintools.com/cgi-bin/charlook.pl?searchmode=standard&printtype=utf8&chartype=all&ordering=frequency&display=char&display=radstroke&display=strokes&display=pinyin&display=english&display=variants&display=unicode&english=&pinyin=&cantonese=&enctype=utf8&whatchar=扭矩&searchchar=Search+by+Character&lowerb=&upperb=
[02:10:18] <jepler> and that translation website gives a different translation for torque:
http://www.mandarintools.com/cgi-bin/charlook.pl?searchmode=standard&printtype=utf8&chartype=all&ordering=frequency&display=char&display=radstroke&display=strokes&display=pinyin&display=english&display=variants&display=unicode&english=&pinyin=&cantonese=&enctype=utf8&whatchar=力 矩&searchchar=Search+by+Character&lowerb=&upperb=
[02:10:29] <jepler> oh well, the world may never know
[02:27:50] <SWPadnos> it's amazing how difficult it is to get one freaking wire through the firewall on my Jeep
[02:30:40] <jtr> the fact that they spec'd "Motor of X axis" is in N, rather than Nm points to some confusion between force and torque.
[02:31:30] <jtr> SWPadnos: have a safe trip tomorrow.
[02:31:47] <SWPadnos> thanks. I sure hope (a) I go and (b) I'm safe :)
[05:28:27] <CIA-42> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/firmware/src/ (IDParms.vhd kubstepgeny.vhd): fixed stepgen from pcw
[20:29:59] <jepler> quiet today
[20:30:12] <jepler> that thing with hostmot2 stepgen must be the last thing we had to finish
[20:30:15] <jepler> let's release 3.0 today
[20:30:51] <seb_kuzminsky> yep, we're all done
[20:30:54] <cradek> hm.
[20:30:55] <seb_kuzminsky> the last bug is squished
[20:30:59] <seb_kuzminsky> ship it nao!
[20:33:34] <skunkworks> http://www.cnczone.com/forums/showthread.php?p=540778#post540778
[20:33:51] <skunkworks> ^ must not have chosen wisely
[20:34:34] <cradek> yuck
[20:47:53] <seb_kuzminsky> i replied to the guy on cnczone
[20:48:24] <seb_kuzminsky> hi peter
[20:48:39] <PeterW> Hi Sebastian
[20:49:20] <PeterW> It may be possible to get Netmos chips to work
[20:49:22] <PeterW> Just need a CPM
[20:49:34] <jepler> cpm?
[20:49:46] <PeterW> Clairvoyant Processing Module
[20:50:00] <jepler> oh, I thought maybe you meant the thing with PIP.COM
[20:50:26] <PeterW> No, need to guess when the read strobe is about to come along
[20:50:27] <skunkworks> seb_kuzminsky: thanks
[20:51:23] <cradek> "Anything that advertises EPP support, and that doesnt use a NetMos/MosChip chip" might leave you with no cards at all
[20:51:33] <cradek> (not that that makes your answer bad)
[20:51:39] <seb_kuzminsky> there are a couple of other ones on newegg
[20:51:41] <PeterW> Actually the NetMos chips do seem to read the bus in EPP mode, so there may be some hope
[20:51:43] <seb_kuzminsky> non-netmos ones i mean
[20:52:22] <PeterW> ITE based cards (rare) should work as would Lava cards (expensive)
[20:52:25] <cradek> oh really, I'm surprised they say EPP
[20:52:55] <cradek> yay for the PCI alternatives.
[20:53:11] <PeterW> (also OxSemi cards(Hens teeth) are known to work
[20:54:54] <seb_kuzminsky> PeterW: netmos cards can read epp but not write it?
[20:56:08] <PeterW> Netmos write timing is fine
[20:56:10] <PeterW> They _seem_ to read the data at (or before) the leading edge of the strobe
[20:56:27] <seb_kuzminsky> strange
[20:57:16] <PeterW> Could be just a polarity error in an edge detector, but you would have thought they would have tested it...
[20:57:33] <seb_kuzminsky> ... tested it *before* advertising it
[20:57:51] <PeterW> Well it half works...
[20:57:54] <seb_kuzminsky> one thing i like about usb, wifi, etc, is that there's a standards body that performs testing before you can brand your product
[20:59:17] <PeterW> Their suggested workaround is ECP mode but its much more complicated
[21:00:13] <PeterW> The bad thing is that NetMos chips seem to be so cheap that 99% of the PCI parallel cards out there are NetMOS based
[21:00:25] <seb_kuzminsky> yeah, that sucks :-(
[21:01:33] <PeterW> Seb: making bitfiles now, will send some a bit later today
[21:01:44] <seb_kuzminsky> ok, i'll commit them
[21:12:31] <seb_kuzminsky> jepler, jmkasunich: what's the status of the command-line .BIT-building tools?
[21:16:53] <jepler> seb_kuzminsky: I get a 5i20_SVST8_4.bit that loads and seems to work
[21:17:06] <jepler> seb_kuzminsky: but before we can rebuild all the bit files we have to do more work on getting the .board and .spec files ready
[21:17:36] <seb_kuzminsky> that's great :-)
[21:17:50] <jepler> I had e-mailed jmkasunich some automatically split spec files, but they haven't gone into cvs yes
[21:17:53] <jepler> yet
[21:18:10] <jepler> something about converting the pin specification from a number to a structure that went over my head..
[21:18:29] <seb_kuzminsky> hm
[21:19:06] <seb_kuzminsky> welcome back PeterW ;-)
[21:19:55] <jepler> so for a 2.2.9 I'd be just as happy to take bitfiles built by PeterW, and not hurry that "new tech" out of TRUNK into the branch
[21:20:04] <seb_kuzminsky> jepler: makes sense
[21:20:23] <seb_kuzminsky> in the awesome future we'll have a buildslave build all the bitfiles on demand
[21:20:35] <jepler> seb_kuzminsky: that would be neat
[21:21:14] <PeterW> PeterW is now known as PeterWalrus
[21:21:25] <seb_kuzminsky> koo koo atchoo
[21:21:37] <PeterWalrus> I saw that coming...
[21:22:44] <PeterWalrus> Making a pindesc for the 7I47 (mshaver is going to use)
[21:27:11] <cradek> what is 7i47?
[21:28:29] <PeterWalrus> Its a breakout board with 12 RS-422 outputs and 12 RS-422 inputs
[21:28:31] <PeterWalrus> mShaver is using the 422 outs for differential step+dir
[21:32:01] <jepler> speaking of that, is it presently possible to use 7i64 with emc2's hostmot2 driver?
[21:32:17] <seb_kuzminsky> * seb_kuzminsky greps for 7i64
[21:32:24] <jepler> (that's the 48-I/O card on SPI bus, for those who aren't reading mesanet.com right now)
[21:32:30] <PeterWalrus> Its part of a new version of cards with Phoenix contact clone
[21:32:32] <PeterWalrus> pluggable terminal blocks instead of Weidmueller
[21:32:33] <PeterWalrus> The clones are cheap enough that we can now include the pluggable
[21:32:35] <PeterWalrus> screw terminals with the breakout boards ant the same price as before
[21:33:01] <seb_kuzminsky> jepler: i think the answer is no
[21:33:10] <seb_kuzminsky> current hm2 doesnt do spi
[21:33:10] <PeterWalrus> No, theres firmware but no driver support yet
[21:33:44] <PeterWalrus> Same goes for 7I65
[21:35:40] <PeterWalrus> The firmware(BSPI) has been tested with the 7I65 and 7I64 but thats as far as it goes
[21:36:15] <jepler> just wondering -- I don't have a need for it myself
[21:36:55] <PeterWalrus> Theres alway USB...
[21:39:40] <jepler> is the xilinx chip on it a cpld?
[21:40:11] <seb_kuzminsky> PeterWalrus: iirc, the 7i64 and 7i65 cannot be detected over spi - you can't sense that it's a 7i64 connected to SPI port 0
[21:40:33] <seb_kuzminsky> if that's right, hm2 configuration is about to become even uglier than it is now... :-(
[21:43:56] <PeterWalrus> Jepler: Yes
[21:45:07] <jepler> is vhdl programming of cplds much different than fpgas, or is it just that chip resources are much more limited?
[21:45:30] <PeterWalrus> Actually you can detect them. But I was thinking that maybe we need a "virtual" component listed in the Module IDs for complicated things (like the 7I65)
[21:46:49] <PeterWalrus> Jepler, same just different constraints
[21:46:51] <PeterWalrus> on CPLDs you have all the gates (and speed) you need but few registers
[21:47:46] <jepler> and in contrast to fpgas they are typically non-volatile
[21:47:46] <jepler> ?
[21:48:05] <seb_kuzminsky> this use of SPI makes me start to understand the desire for realtime ethernet
[21:48:36] <PeterWalrus> Yep though there are some non-volatile FPGAs
[21:48:36] <seb_kuzminsky> do the spi daughterboards have a register-file interface (like hm2) or a message-passing interface?
[21:48:38] <PeterWalrus> Dont think I'd want to write code for a 16V8 in VHDL however
[21:50:17] <PeterWalrus> SPI daughter cards are either extremely simple (7I64 = 32 bit data 24 I/O + R/W bit + cookie)
[21:50:18] <PeterWalrus> Or a mix of this or that (whatever the D-A/A-D chips look like)
[21:51:41] <seb_kuzminsky> how does the spi daughter tell the mother what kind it is? 7i64 vs 7i65 etc
[21:52:52] <PeterWalrus> Some of this is hidden by the BSPI interface
[21:52:54] <PeterWalrus> where the bits, shiftrate, CS pinstate
[21:52:56] <PeterWalrus> CPOL CPHA and whether to push the return data on the FIFO
[21:52:57] <PeterWalrus> is all preset an a per channel basis in the channel descriptor
[21:53:32] <PeterWalrus> Right now the 7I64 will echo a cookie, the 7I65 has an on card EEPROM you can read
[21:54:43] <PeterWalrus> But firmware configurations would likely be mad specifically for the 7I65 and 7I64, hence the "virtual" module ID
[21:54:45] <PeterWalrus> idea
[21:54:54] <PeterWalrus> (made)
[21:55:14] <jepler> for a minute there I thought you were calling it a crazy idea
[21:55:32] <PeterWalrus> It may be...
[21:56:44] <jepler> bbl
[21:57:39] <seb_kuzminsky> seeya jeff
[21:58:40] <seb_kuzminsky> brb
[22:01:08] <seb_kuzminsky> PeterWalrus: so there'd be a module called "spi-to-7i65", and the user would hook up a 7i65 to that particular spi port?
[22:03:00] <PeterWalrus> A 7I65 connects to a whole 24 I/O connector It uses a BSPI interface, 8 (Muxed) q counters and a few GPIO bits
[22:06:24] <PeterWalrus> The muxed q counters are transparent (no different from normal except the filter rate needs to be slower,and default is slower
[22:13:23] <PeterWalrus> bbl
[23:23:56] <jmkasunich> hi seb_kuzminsky PeterWalrus
[23:24:06] <jmkasunich> was out when you were discussing auto-builds
[23:24:21] <jmkasunich> the infrastructure is there and seems to work
[23:25:02] <jmkasunich> I didn't check in the 27 .spec files, because I think a change from concatenating numbers to some kind of vhdl structures/records is imminent
[23:26:48] <jmkasunich> if the neccessary vhdl changes are going to take a while, I'll go ahead and check in what we have
[23:27:14] <jmkasunich> jepler: I agree that this stuff (and locally built rathern than mesa-built bitfiles) should be for trunk, not 2.2.9
[23:35:12] <PeterWalrus> Might also be a bit cleaner if there was a separate top level file for each board type 5i23hostmot2.vhd,4i68hostmot2.vhd etc
[23:35:14] <PeterWalrus> with a generic moduleID and pindesc name, then you could do the selection step by including the appropriate moduleid+pindesc file in the
[23:35:16] <PeterWalrus> .PRJ file
[23:35:17] <PeterWalrus> Then there would be no changes to the top level files, and the GUI build could use the same files
[23:35:19] <PeterWalrus> It will take me a while to change to the record structure anyway (after holidays)
[23:35:21] <PeterWalrus> Making bitfiles now, tedious but OK
[23:36:04] <jmkasunich> * jmkasunich tries to parse what you just said
[23:36:44] <PeterWalrus> I'm not sure I can either but I know what I mean.
[23:37:24] <jmkasunich> right now, there is I20HostMot2.vhd and friends, (top level, I tweak it a bit and use it as a template) and hostmot2.vhd which has a lot of common stuff in it
[23:37:53] <jmkasunich> current (GUI) build system gets config specific stuff from IDParms.vhd
[23:38:33] <jmkasunich> cmd line build system breaks IDParms.vhd into many .spec files, and builds a top-level file on the fly from a template and the .spec
[23:39:32] <jmkasunich> makeing the top level file on the fly is the only part that doesn't work in the gui I think
[23:40:12] <jmkasunich> I can't see any way to make the gui happy without either massive duplication of code, or hand editing at least a few lines in a vhd file for each build
[23:40:27] <seb_kuzminsky> see you guys later
[23:40:35] <jmkasunich> I'm open to being proven wrong tho
[23:41:16] <PeterWalrus> OK 2 things. One is to copy the top level files around so there is just on per board type
[23:41:18] <PeterWalrus> Two is for me to break the IDParms file into many file like SVST4_4_72.vhd 7I65x2_72.vhd etc
[23:41:19] <PeterWalrus> All of these file have a generic module ID and Pindesc name, and your created .PRJ file just include the one with the proper filename
[23:43:21] <PeterWalrus> Theres not much in the top level files anyway, and whats there is pretty stable so the duplication is not too painful
[23:44:03] <jmkasunich> the top level being the ones called I20HostMot.vhd, I22HostMot2.vhd, I43hostmot2.vhd, etc?
[23:44:15] <PeterWalrus> Yes
[23:44:33] <jmkasunich> seems they are already split per board - or are you referring to the the tricks in 5i22 that lets it be used for 5i23 and a couple others?
[23:45:09] <PeterWalrus> Yes, i22hostmot2 is used for 5i23 and 4I68 as well
[23:45:23] <jmkasunich> yeah, I figured that out when it failed my first attempt to build it
[23:45:43] <jmkasunich> I added some substition tags in there so now it works for all three without editing
[23:46:13] <jmkasunich> for me, substitution is simple, easy, and means that when something else in that file changes, the change doesn't need to be done in 3 files
[23:46:22] <jmkasunich> but I guess it isn't GUI friendly
[23:47:02] <PeterWalrus> Thats good for now, It will take me a while to get the record pindesc stuff fixed, so anything fancier could be deferred
[23:47:37] <jmkasunich> the thing that worries me is that I don't want to diverge from what you are doing
[23:48:30] <jmkasunich> I would like it if EMC users don't have to pester you for custom bitfiles
[23:48:51] <jmkasunich> but at the same time, I want to make sure that the files that we or they generate aren't drifting away from what you generate
[23:48:56] <PeterWalrus> I think it can be made to accommodate both build methods with a little tweaking
[23:48:58] <PeterWalrus> I need to talk to a VHDL guru. I'm sure there are better ways to organize this...
[23:49:32] <jmkasunich> if we have a bug report (like matt's), it would suck to have it turn out to be a difference between your version and ours
[23:49:48] <jmkasunich> especially if either of us spends hours before we figure that out
[23:49:59] <jmkasunich> uh-oh
[23:50:07] <PeterWalrus> Yep
[23:50:18] <jmkasunich> vhdl guru? I thought you were the vhdl guru
[23:50:32] <jmkasunich> (I'm pretty lost on what is going on in those files, unfortunately)
[23:50:35] <PeterWalrus> HaHa
[23:51:07] <PeterWalrus> Just an old hardware guy
[23:51:28] <jmkasunich> same here, but you are already doing stuff for the config that I don't have a clue about
[23:52:10] <PeterWalrus> VHDL has so much in it that one person may not understand anothers dialect
[23:56:02] <jmkasunich> whatever we wind up with, it will need a README that describes how all the pieces play totether
[23:56:05] <jmkasunich> together
[23:56:42] <PeterWalrus> I can help with that
[23:57:20] <PeterWalrus> The real pain is testing all the bitfiles
[23:57:25] <jmkasunich> yeah
[23:58:03] <jmkasunich> as far as the build system goes, I think making it build under the GUI (without editing any vhdl files) will be the hard part
[23:58:35] <jmkasunich> once that works, I bet I can build a prj file that will work from the cmd line using python without much trouble
