I think it's less than 1000
it's this: http://www.siegind.com/CNC_MACHINE/KC6_SIEG.html
of course they can only do 79"/min :)
if I get it to work right, I should be able to thread down to 13tpi at 300rpm (max spindle speed)!
for some reason I thought matt was working on an HNC
looks like a similar size machine though
ok, similar travel :-)
wow, that's some poor English
I wonder what they're substituting for mass?
he was working on an HNC at one point, it's not on his page anymore though
I wonder if that's with the stand/box
oh right, I wondered why it had steppers on it
now this makes more sense
I wonder what 'Max pitch of strand (Z) = 4 Nm' means
it says it has a 10" swing, but X can move 4.3"
I bet they mean maximum thread pitch is 4mm
$ units '(500mm/min)/100rpm' 'mm/revolution'
doesn't quite match their feed numbers
cutting force in x and z?
it could be a control issue - other stuff there sure is
strand has just got to be a bad translation of thread
just having a hard time with threads along the x axis...
there are lots of hits for "max pitch of strand"
Air Wrenches Products from Manufacturers & Suppliers, Air Wrenches ...
Features: 1) Free speed: 7000rpm2) Average air consumption: 4.00cfm3) Max. pitch of strand: 230ft-lb4) Rotation type: rocking dog
also this datasheet has "max strand" for the mill: http://emergent.unpy.net/index.cgi-files/sandbox/kx3a-kc6a.jpg
google translate Chinglish->English
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
holy crap a chinglish dictionary
everything on that page contains "itch"
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=
it so consistently comes up with torque units near it that it must be torque
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=
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=力
oh well, the world may never know
it's amazing how difficult it is to get one freaking wire through the firewall on my Jeep
the fact that they spec'd "Motor of X axis" is in N, rather than Nm points to some confusion between force and torque.
SWPadnos: have a safe trip tomorrow.
thanks. I sure hope (a) I go and (b) I'm safe :)
EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/firmware/src/ (IDParms.vhd kubstepgeny.vhd): fixed stepgen from pcw
that thing with hostmot2 stepgen must be the last thing we had to finish
let's release 3.0 today
yep, we're all done
the last bug is squished
ship it nao!
[20:33:34] <skunkworks> http://www.cnczone.com/forums/showthread.php?p=540778#post540778
^ must not have chosen wisely
i replied to the guy on cnczone
It may be possible to get Netmos chips to work
Just need a CPM
Clairvoyant Processing Module
oh, I thought maybe you meant the thing with PIP.COM
No, need to guess when the read strobe is about to come along
"Anything that advertises EPP support, and that doesnt use a NetMos/MosChip chip" might leave you with no cards at all
(not that that makes your answer bad)
there are a couple of other ones on newegg
Actually the NetMos chips do seem to read the bus in EPP mode, so there may be some hope
non-netmos ones i mean
ITE based cards (rare) should work as would Lava cards (expensive)
oh really, I'm surprised they say EPP
yay for the PCI alternatives.
(also OxSemi cards(Hens teeth) are known to work
PeterW: netmos cards can read epp but not write it?
Netmos write timing is fine
They _seem_ to read the data at (or before) the leading edge of the strobe
Could be just a polarity error in an edge detector, but you would have thought they would have tested it...
... tested it *before* advertising it
Well it half works...
one thing i like about usb, wifi, etc, is that there's a standards body that performs testing before you can brand your product
Their suggested workaround is ECP mode but its much more complicated
The bad thing is that NetMos chips seem to be so cheap that 99% of the PCI parallel cards out there are NetMOS based
yeah, that sucks :-(
Seb: making bitfiles now, will send some a bit later today
ok, i'll commit them
jepler, jmkasunich: what's the status of the command-line .BIT-building tools?
seb_kuzminsky: I get a 5i20_SVST8_4.bit that loads and seems to work
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
that's great :-)
I had e-mailed jmkasunich some automatically split spec files, but they haven't gone into cvs yes
something about converting the pin specification from a number to a structure that went over my head..
welcome back PeterW ;-)
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
jepler: makes sense
in the awesome future we'll have a buildslave build all the bitfiles on demand
seb_kuzminsky: that would be neat
PeterW is now known as PeterWalrus
koo koo atchoo
I saw that coming...
Making a pindesc for the 7I47 (mshaver is going to use)
what is 7i47?
Its a breakout board with 12 RS-422 outputs and 12 RS-422 inputs
mShaver is using the 422 outs for differential step+dir
speaking of that, is it presently possible to use 7i64 with emc2's hostmot2 driver?
* seb_kuzminsky greps for 7i64
(that's the 48-I/O card on SPI bus, for those who aren't reading mesanet.com right now)
Its part of a new version of cards with Phoenix contact clone
pluggable terminal blocks instead of Weidmueller
The clones are cheap enough that we can now include the pluggable
screw terminals with the breakout boards ant the same price as before
jepler: i think the answer is no
current hm2 doesnt do spi
No, theres firmware but no driver support yet
Same goes for 7I65
The firmware(BSPI) has been tested with the 7I65 and 7I64 but thats as far as it goes
just wondering -- I don't have a need for it myself
Theres alway USB...
is the xilinx chip on it a cpld?
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
if that's right, hm2 configuration is about to become even uglier than it is now... :-(
is vhdl programming of cplds much different than fpgas, or is it just that chip resources are much more limited?
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)
Jepler, same just different constraints
on CPLDs you have all the gates (and speed) you need but few registers
and in contrast to fpgas they are typically non-volatile
this use of SPI makes me start to understand the desire for realtime ethernet
Yep though there are some non-volatile FPGAs
do the spi daughterboards have a register-file interface (like hm2) or a message-passing interface?
Dont think I'd want to write code for a 16V8 in VHDL however
SPI daughter cards are either extremely simple (7I64 = 32 bit data 24 I/O + R/W bit + cookie)
Or a mix of this or that (whatever the D-A/A-D chips look like)
how does the spi daughter tell the mother what kind it is? 7i64 vs 7i65 etc
Some of this is hidden by the BSPI interface
where the bits, shiftrate, CS pinstate
CPOL CPHA and whether to push the return data on the FIFO
is all preset an a per channel basis in the channel descriptor
Right now the 7I64 will echo a cookie, the 7I65 has an on card EEPROM you can read
But firmware configurations would likely be mad specifically for the 7I65 and 7I64, hence the "virtual" module ID
for a minute there I thought you were calling it a crazy idea
It may be...
PeterWalrus: so there'd be a module called "spi-to-7i65", and the user would hook up a 7i65 to that particular spi port?
A 7I65 connects to a whole 24 I/O connector It uses a BSPI interface, 8 (Muxed) q counters and a few GPIO bits
The muxed q counters are transparent (no different from normal except the filter rate needs to be slower,and default is slower
hi seb_kuzminsky PeterWalrus
was out when you were discussing auto-builds
the infrastructure is there and seems to work
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
if the neccessary vhdl changes are going to take a while, I'll go ahead and check in what we have
jepler: I agree that this stuff (and locally built rathern than mesa-built bitfiles) should be for trunk, not 2.2.9
Might also be a bit cleaner if there was a separate top level file for each board type 5i23hostmot2.vhd,4i68hostmot2.vhd etc
with a generic moduleID and pindesc name, then you could do the selection step by including the appropriate moduleid+pindesc file in the
Then there would be no changes to the top level files, and the GUI build could use the same files
It will take me a while to change to the record structure anyway (after holidays)
Making bitfiles now, tedious but OK
* jmkasunich tries to parse what you just said
I'm not sure I can either but I know what I mean.
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
current (GUI) build system gets config specific stuff from IDParms.vhd
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
makeing the top level file on the fly is the only part that doesn't work in the gui I think
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
see you guys later
I'm open to being proven wrong tho
OK 2 things. One is to copy the top level files around so there is just on per board type
Two is for me to break the IDParms file into many file like SVST4_4_72.vhd 7I65x2_72.vhd etc
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
Theres not much in the top level files anyway, and whats there is pretty stable so the duplication is not too painful
the top level being the ones called I20HostMot.vhd, I22HostMot2.vhd, I43hostmot2.vhd, etc?
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?
Yes, i22hostmot2 is used for 5i23 and 4I68 as well
yeah, I figured that out when it failed my first attempt to build it
I added some substition tags in there so now it works for all three without editing
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
but I guess it isn't GUI friendly
Thats good for now, It will take me a while to get the record pindesc stuff fixed, so anything fancier could be deferred
the thing that worries me is that I don't want to diverge from what you are doing
I would like it if EMC users don't have to pester you for custom bitfiles
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
I think it can be made to accommodate both build methods with a little tweaking
I need to talk to a VHDL guru. I'm sure there are better ways to organize this...
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
especially if either of us spends hours before we figure that out
vhdl guru? I thought you were the vhdl guru
(I'm pretty lost on what is going on in those files, unfortunately)
Just an old hardware guy
same here, but you are already doing stuff for the config that I don't have a clue about
VHDL has so much in it that one person may not understand anothers dialect
whatever we wind up with, it will need a README that describes how all the pieces play totether
I can help with that
The real pain is testing all the bitfiles
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
once that works, I bet I can build a prj file that will work from the cmd line using python without much trouble