Back
[00:07:52] <cradek> yay!
[00:08:06] <cradek> I better get to work [digging through their website]
[00:13:37] <seb_kuzminsky> later guys
[00:18:42] <cradek> http://www.hgrindustrialsurplus.com/search-products/product-detail.aspx?id=12-182-248&searchtable=2&sortExpression=&SortASC=&pageSize=50¤tPageIndex=3
[00:18:45] <cradek> wonder what these are
[00:19:19] <jmkasunich> gold things
[00:19:32] <cradek> oh, thought you were gone
[00:19:53] <jmkasunich> found food, ate it, returned
[00:19:55] <cradek> could you check one thing for me when you go? I think this might be a QC30-ER40 chuck:
http://www.hgrindustrialsurplus.com/search-products/product-detail.aspx?id=05-583-013&searchtable=2&sortExpression=&SortASC=&pageSize=50¤tPageIndex=0
[00:20:28] <jmkasunich> sure
[00:20:38] <jmkasunich> only the chuck, right?
[00:20:39] <cradek> I'm looking for the measurements again...
[00:20:42] <cradek> yeah
[00:22:39] <cradek> flange is dia 1.811 thickness .344 gauge diameter is 1.250
[00:23:29] <jmkasunich> ok
[00:24:51] <cradek> ER40 means there is a snap ring in the nut, and the large measurement of the taper is 40mm (1.575")
[00:25:13] <jmkasunich> snap ring? or just an offset lip?
[00:25:34] <jmkasunich> my ER20 holder has the "ring" machined integral with the nut
[00:25:48] <cradek> oh really - mine is a separate springy metal part
[00:26:07] <jmkasunich> might be two different ways of making them, or just something different between 20 and 40
[00:26:15] <cradek> there must be some variation
[00:26:34] <cradek> yeah I bet the only requirement is that the nut pulls the collet out somehow - there are probably many ways to do that
[00:27:29] <jmkasunich> wow, they have a LOT of ballscrews
[00:28:28] <jmkasunich> 262 records found, and a quick scan doesn't show any mistaken hits
[00:29:11] <cradek> wow
[00:29:45] <skunkworks> also a bit expensive (well for a hobbie)
[00:29:59] <jmkasunich> what? buying ballscrews from HGR?
[00:30:13] <jmkasunich> beats the heck out of buying them from anywhere else
[00:30:17] <skunkworks> wow - maybe not.
[00:30:20] <skunkworks> cool stuff
[00:30:58] <jmkasunich> about a third of those hits are under $50 - they must have decided they were getting too many
[00:31:13] <cradek> wow, cheap cheap cheap
[00:31:25] <jmkasunich> (they used to be mostly marked $99 and up, although they took $75 a couple times
[00:31:41] <skunkworks> http://www.hgrindustrialsurplus.com/search-products/product-detail.aspx?id=12-393-847&searchtable=2&sortExpression=&SortASC=&pageSize=50¤tPageIndex=0
[00:31:43] <jmkasunich> http://www.hgrindustrialsurplus.com/search-products/product-detail.aspx?id=14-115-366&searchtable=2&sortExpression=wbprice&SortASC=Yes&pageSize=all¤tPageIndex=0
[00:32:33] <cradek> wow
[00:32:34] <cradek> http://www.hgrindustrialsurplus.com/search-products/product-detail.aspx?id=14-115-429&searchtable=2&sortExpression=&SortASC=&pageSize=50¤tPageIndex=0
[00:32:38] <cradek> that's a heavy duty screw
[00:32:52] <jmkasunich> yeah, they have some huge ones
[00:33:03] <cradek> looks like each race has about 10 turns of balls
[00:33:26] <jmkasunich> if swp gets that lathe, and comes here to pick it up, he'll have a chance to browse
[00:34:31] <jmkasunich> in the past when I've been looking at screws there, the hardest part is finding small ones
[00:34:44] <jmkasunich> average diameter seems to be 1 to 1.5"
[01:10:30] <jmkasunich> is seb around?
[01:10:35] <jmkasunich> guess not
[01:11:01] <jmkasunich> darn - got a question about bitfiles, naming and storage location
[01:28:49] <jepler> hi PeterW
[01:28:57] <PeterW> Hi all
[01:29:04] <jepler> thanks for joining us
[01:30:11] <jmkasunich> hi peter
[01:30:28] <jmkasunich> making fairly good progress on the autobuild stuff, but I have some questions
[01:30:29] <PeterW> Hi
[01:30:50] <SWPadnos> jmkasunich, I'll be back in a bit - we're building A-frames to go over some plants
[01:30:58] <jmkasunich> things like "SVST8_4" are configs, which may be buildable for more than one board, like 5i20 and 7i43, etc
[01:31:00] <jmkasunich> SWPadnos: ok
[01:31:03] <PeterW> Thats good news. I hope I can be of help...
[01:31:13] <PeterW> Yes
[01:31:39] <jmkasunich> originally I was thinking that we'd create "SVST8_4_5i20.spec" and "SVST8_4_7i43.spec", etc
[01:32:32] <jmkasunich> but it doesn't really make sense to duplicate the pin_desc and module_id info in multiple places
[01:32:32] <jmkasunich> and to duplicate the board specific stuff in other places
[01:32:59] <jmkasunich> so now I'm leaning towards a build command like "spec2bit SVST8_4.spec 5i20.board" which would produce SVST8_4_5i20.bit
[01:33:19] <jmkasunich> to make it for a differnet board, just reissue the command calling out a different .board file
[01:33:30] <PeterW> Yes, that would save some duplication
[01:33:54] <jmkasunich> right now Seb has the bitfiles in separate directories per board
[01:34:15] <jmkasunich> SVST8_4.bit appears in each directory (but of course are not the same stuff)
[01:34:35] <jmkasunich> I need to ask him about the pros and cons of having longer unique names, with both config and board in the name
[01:34:47] <jmkasunich> I know there is a length limit in the driver infrastructure
[01:35:07] <jmkasunich> I was wondering how you manage the differnet versions? names, directories, or something else?
[01:35:45] <PeterW> At this point it might make sense to expand the names to be more descriptive -
[01:35:47] <PeterW> the short names are just an artifact of my lazyness since I still test bitfiles under DOS
[01:36:50] <jmkasunich> it isn't out of the question to have the build system use short names and put the files in appropriate directories
[01:37:11] <jmkasunich> it makes things a bit more compelx, because all the intermediate files will want to use long names, since they all wind up in the src directory
[01:37:23] <jmkasunich> (intermediate = NGC and all that)
[01:37:41] <PeterW> Including the board type is a really good idea.
[01:37:43] <PeterW> I think I would just go for longer names now
[01:37:58] <jmkasunich> what happens when you try to test?
[01:38:16] <jmkasunich> does dos barf on long names, or is it just a typing saver?
[01:38:24] <PeterW> I rename the bitfile 5i20-123.bit...
[01:38:31] <jmkasunich> ah, ok
[01:38:52] <PeterW> dos is8.3 only
[01:39:05] <jmkasunich> btw, jepler tested my first pass build program on a windows install of the xilinx tools, and it worked (I was slightly astonished, and very pleased)
[01:39:22] <jmkasunich> all you need is python for windows, which is readily available
[01:39:44] <PeterW> Neat. If i had to rebuild all the bitfiles, it would take me all day
[01:40:01] <jmkasunich> so far I've only got it working up thru the synthesis step, but that includes all the tricky stuff like dependency management and merging config and board data
[01:40:25] <jmkasunich> jeff also wrote a program that extracted all 27 configs (sets of pin_desc and module_id) out of IDParms.vhd
[01:40:39] <jmkasunich> we'll be committing them to CVS as independent files shortly
[01:41:05] <PeterW> The rest of the steps should be a POC, but you need to pass some map and bitgen parameters
[01:41:28] <jmkasunich> yeah, that is pretty much plug-n-chug
[01:41:51] <jmkasunich> a file like "5i20.board" will define things like the device, constraints file, and any other stuff that is board specific
[01:41:55] <PeterW> Thanks Jepler!
[01:42:06] <jmkasunich> and the python program plugs those things into the command lines for the xilinx tools
[01:43:09] <jmkasunich> is there a straightforward way to determine which configs can be built on which boards?
[01:43:41] <jmkasunich> something like SVST8_4 needs 72 pins, so it can only go on a 72 pin board (can it go on a 96, leaving some pins empty?)
[01:43:54] <PeterW> Could Jeplers Python wizardy perhaps convert the pindesc concatinations into records?
[01:44:24] <jmkasunich> he'll have to answer that
[01:44:42] <jepler> well .. right now the stuff in the "spec" file is suitable for copying verbatim into a vhd file
[01:44:42] <jmkasunich> I suspect the answer is "you'll have to splain the syntax of the existing and new formats first"
[01:45:02] <jepler> I assume that if there was a better way to write it in the vhd file you would
[01:45:17] <PeterW> No a 72 pin config has to go with a 72 pin board
[01:45:21] <jmkasunich> jepler: he started, but the grunt work of conversion slowed it down
[01:45:50] <PeterW> Perhaps the names could have the number of pins added
[01:45:51] <jmkasunich> see line 282 in IDParms.vhd
[01:45:59] <jepler> looking
[01:46:26] <jepler> ok, how wold a PinDescRecord look in vhdl?
[01:46:39] <jmkasunich> PeterW: the nice thing about the .spec format is that we can add any additional info we want
[01:46:41] <jepler> let's say this one specifically: IOPortTag & x"01" & QCountTag & x"02",
[01:49:59] <PeterW> Jepler: currently each pindesc is a 32 bin number thats a concatenation of 4 bytes
[01:50:01] <PeterW> it would be better for the rest of the vhdl source that read this if it were a record (structure)
[01:50:03] <PeterW> so the the fields were accessible by name instead of by index subranges
[01:50:20] <PeterW> (that the)
[01:51:38] <jmkasunich> are both pin_desc and module_id concatenations right now, or are you using the ModuleRecord structure already?
[01:52:12] <jmkasunich> (it doesn't look like you are)
[01:53:35] <jepler> pin_desc = """
[01:53:35] <jepler> (
[01:53:35] <jepler> ( IOPortTag, x"01", QCountTag, x"02")
[01:53:35] <jepler> ( IOPortTag, x"01", QCountTag, x"01")
[01:53:35] <jepler> ( IOPortTag, x"00", QCountTag, x"02")
[01:53:40] <jepler> so does it end up looking like this ^^^ ?
[01:53:46] <PeterW> Module IDs are a record, the main difference is the comma instead of the concatenation operator
[01:54:09] <jmkasunich> and the order gets reversed?
[01:54:12] <jepler> I can permute the order easily
[01:54:29] <jmkasunich> 02, QcountTag, 01, IO_PortTag ?
[01:54:34] <jepler> ( x"02", QCountTag, x"01", IOPortTag)
[01:54:35] <jepler> ( x"01", QCountTag, x"01", IOPortTag)
[01:54:38] <PeterW> Yes the order is reversed
[01:56:06] <jepler> I can send jmkasunich another set of spec files that look like this instead
[01:56:10] <jepler> oh is there a trailing ","?
[01:56:37] <jepler> hm, what about emptypins
[01:56:38] <jmkasunich> outside the ()? I bet so
[01:58:09] <PeterW> This would make the DoPinout section in HostMot2.VHD much nicer
[01:58:11] <PeterW> I _think_ the trailing , is a typo
[01:58:31] <jmkasunich> there are commas in the module_id section
[01:58:55] <jmkasunich> (WatchDogTag,x"00",ClockLowTag,x"01",WatchDogTimeAddr&PadT,WatchDogNumRegs,x"00",WatchDogMPBitMask),
[01:58:55] <jmkasunich> (IOPortTag,x"00",ClockLowTag,x"02",PortAddr&PadT,IOPortNumRegs,x"00",IOPortMPBitMask),
[02:00:30] <PeterW> No, Its correct because its an array of records
[02:03:46] <jepler> I can easily strip off the commas if they're wrong. Here's the next version of the autosplit spec files:
http://emergent.unpy.net/index.cgi-files/sandbox/mesa-autogenerated-specfiles-record.tar.gz
[02:04:47] <jmkasunich> got it, thanks
[02:05:13] <jmkasunich> one or more VHDL files will need to be tweaked to use the new records, I'll leave that in Peter's capable hands
[02:05:31] <jmkasunich> PeterW: can you extract files from that tar.gz?
[02:05:49] <jmkasunich> this is gonna get interesting
[02:06:01] <jmkasunich> peter has his source file tree, and we have ours in CVS
[02:06:02] <PeterW> Yes
[02:06:15] <jmkasunich> ours is a snapshop of his, as sent thru seb a few days ago
[02:06:34] <jmkasunich> now we're committing a pile of .spec files, and a few minor mods to other files, into our CVS
[02:06:48] <jmkasunich> to use these tools, peter needs to get our versions of the files
[02:06:59] <jepler> yeah -- it's about to get complicated
[02:07:02] <PeterW> Yes there are a couple of vhdl file I need to change use the records
[02:07:52] <jmkasunich> up till now, the only change I've made to your vhdl is in I20Hostmot2.vhd, and it is only 3 lines IIRC
[02:08:31] <jmkasunich> here is the diff:
http://cvs.linuxcnc.org/cvs/emc2/src/hal/drivers/mesa-hostmot2/firmware/src/I20HostMot2.vhd.diff?r1=1.2;r2=1.3
[02:08:40] <jmkasunich> I lied about the 3 lines, I changed some comments too
[02:09:29] <jmkasunich> but what matters is changing the entity name from I20Hostmot2 to ${prefix}_I20HostMot2 (so there will be a unique top level entity for each config)
[02:09:56] <jmkasunich> and replacing PinDesc_JDosa66 with ${pin_desc}, ditto for ModuleID
[02:10:30] <jmkasunich> my tools replace the ${} with the actual info from the spec file, to generate a new top-level VHDL, and then build using that new file
[02:11:18] <PeterW> Oh ok I though you actually split up the IDParms file
[02:11:23] <jmkasunich> not yet
[02:11:34] <jmkasunich> it is still being used, but only the top portion matters
[02:11:52] <jmkasunich> the 2000 or so lines after the record descriptions can be deleted, I just haven't done it yet
[02:12:02] <jmkasunich> jepler is using that file as input for his "splitter" program
[02:12:26] <jmkasunich> once we know everything works (new spec files, record based vhdl), then we can trim the tail off of that file
[02:13:18] <PeterW> Yes sounds like a good plan
[02:13:56] <jmkasunich> minor nitpick question, but since you are here.... what name is better:
[02:14:15] <jmkasunich> SVST8_4_5i20.bit, or 5i20_SVST8_4.bit ?
[02:14:32] <jmkasunich> IOW, when you look at a directory, do you want it sorted by board, or by config?
[02:16:11] <PeterW> Board first would be my preference
[02:16:35] <jmkasunich> done
[02:17:40] <jmkasunich> I'm adding one more field to the .spec file
[02:17:46] <jmkasunich> config_pins = 72
[02:17:51] <jmkasunich> (or 48, or whatever)
[02:18:09] <jmkasunich> then in the .board file, I'll have "board_pins = 72"
[02:18:18] <PeterW> Jepler: The pindesc records look ok! Ill take these and patch the source to work with the records
[02:18:19] <jmkasunich> and the program will verify that they match
[02:24:09] <SWPadnos> hi guys
[02:24:53] <SWPadnos> so, you need the correct number of pins in the pindesc, can a "pindesc generator" fill in "unused" for any left over?
[02:25:18] <PeterW> jmkasunich: on your earlier question about which configs will build on which boards,
[02:25:20] <PeterW> There is really no way to know what will fit unless you try it...
[02:25:34] <jmkasunich> fit meaning gate count, etc...
[02:25:45] <PeterW> Yes
[02:25:50] <jmkasunich> if you try a 72 pin config on a 48 pin board, it is guaranteed to fail, right?
[02:25:56] <PeterW> Yes
[02:26:19] <SWPadnos> it may fit gate wise, but the pins wouldn't be there in the IOport array
[02:26:33] <jmkasunich> I test for the pin count mismatch right off the bat, before I do much else
[02:26:40] <jepler> anything else I should work on right now?
[02:26:57] <PeterW> Synthesis would error-out
[02:26:59] <jmkasunich> jmkasunich@mahan:~/emcdev/emc2head/src/hal/drivers/mesa-hostmot2/firmware/src$ ./spec2bit.py SVST8_4.spec 5i20.board
[02:26:59] <jmkasunich> prefix is: 5i20_SVST8_4
[02:26:59] <jmkasunich> ERROR: config needs 73 pins, board has 72 pins
[02:27:22] <jmkasunich> this was a quick test, I modified one line in the .spec file to force it to fail
[02:27:28] <SWPadnos> phew :)
[02:27:53] <jmkasunich> here is what it looks like normally:
[02:27:56] <jmkasunich> jmkasunich@mahan:~/emcdev/emc2head/src/hal/drivers/mesa-hostmot2/firmware/src$ ./spec2bit.py SVST8_4.spec 5i20.board
[02:27:56] <jmkasunich> prefix is: 5i20_SVST8_4
[02:27:57] <jmkasunich> removing old generated files
[02:27:59] <jmkasunich> removing '5i20_SVST8_4.vhd'
[02:28:01] <jmkasunich> removing '5i20_SVST8_4.prj'
[02:28:01] <PeterW> Thanks Jepler, you saved me some ugly editing...
[02:28:03] <jmkasunich> removing '5i20_SVST8_4.scr'
[02:28:05] <jmkasunich> removing '5i20_SVST8_4.log.syn'
[02:28:07] <jmkasunich> generating top-level file '5i20_SVST8_4.vhd'
[02:28:09] <jmkasunich> calculating dependencies
[02:28:11] <jmkasunich> generating project file '5i20_SVST8_4.prj'
[02:28:13] <jmkasunich> top level entity is '5i20_SVST8_4_I20HostMot2'
[02:28:17] <jmkasunich> generating synthesis script '5i20_SVST8_4.scr'
[02:28:19] <jmkasunich> invoking XST for synthesis
[02:28:52] <jmkasunich> SWPadnos: is Tortise Free software?
[02:28:56] <SWPadnos> yes
[02:29:13] <SWPadnos> I haven't gotten it set up with ssh yet, so I don't know about committing from it
[02:29:25] <jmkasunich> PeterW: you need to get Tortise for your windows machine - it is a CVS client, that will let you check out our source
[02:29:32] <SWPadnos> and I'm not sure I have it set up for anon checkout either, since that also uses ssh
[02:29:49] <SWPadnos> http://www.tortoisecvs.org/
[02:30:27] <jepler> PeterW: happy I could help
[02:30:35] <SWPadnos> free as in beer, not necessarily as in speech
[02:30:38] <jmkasunich> I suspect we'd have no problem giving you commit access so you could write changes to your vhdl back into our repository
[02:30:42] <PeterW> OK ill get it
[02:30:52] <jmkasunich> side benefit, you'd have off-site backup of your source code ;-)
[02:31:07] <SWPadnos> there's a little bit of work you need to fo to be able to use Tortoise with SSH though
[02:31:11] <PeterW> Jepler. I was avoiding that change because of the re-ordering...
[02:31:23] <SWPadnos> you have to get PuTTY or something similar, and their keyring software as well
[02:31:42] <PeterW> Already use putty
[02:31:50] <SWPadnos> ok, good
[02:32:07] <SWPadnos> I think you need Pageant as well
[02:32:15] <SWPadnos> from the PuTTY people
[02:33:01] <SWPadnos> oh:
http://www.tortoisecvs.org/ssh.shtml
[02:34:21] <jmkasunich> PeterW: do you know if there is an identifier length limit in vhdl?
[02:34:37] <jmkasunich> "entity 5i20_SVST8_4_I20HostMot2 is" pretty long
[02:34:48] <SWPadnos> 1024 characters
[02:34:52] <jmkasunich> lol
[02:34:59] <SWPadnos> shouldn't be an issue ;)
[02:35:11] <PeterW> Not that Ive run into
[02:35:28] <jmkasunich> ok, I think I've got the changes needed to use separate .spec and .board files
[02:36:08] <jmkasunich> right now I have one old-style spec file - I'll test with this, and defer committing the 27 spec files until the new style is working
[02:37:07] <jmkasunich> the toolchain is non-determinisitic isn't it? I can't just do a compare between a bitfile I generate and one that peter generated to see if they are the same
[02:37:28] <PeterW> No
[02:37:49] <PeterW> They use random seeds for place&route
[02:38:07] <jmkasunich> so one challenge in this whole process will be doing enough testing on the generated files to have some confidence in them
[02:40:12] <SWPadnos> incidentally, the FIRMWARE_NAME_MAX is 30 characters, and that includes the fill path under /lib/firmware/, so "hm2/file_name.bit\0" has to be 30 chars or less
[02:40:19] <SWPadnos> s/fill/full/
[02:40:40] <jmkasunich> yeah, that is gonna be a bit of a challenge - I wanted to talk to seb about that
[02:40:41] <SWPadnos> PeterW, is there still a way to specify the seed value?
[02:40:53] <jmkasunich> right now, we have the bitfiles in subdirectories by board
[02:40:53] <PeterW> Yep. But I dont think Ive had a bad one yet
[02:41:09] <jmkasunich> we're now planning to put the board name in the bitfile name
[02:41:19] <jmkasunich> so things are getting long
[02:41:23] <PeterW> I think there is but its been a while
[02:41:26] <SWPadnos> well, it's useful so you can tell if you've screwed anything up - using the same seed should give you the same result
[02:41:38] <SWPadnos> ("should")
[02:41:39] <jmkasunich> assuming the same version of the tools
[02:41:44] <SWPadnos> yes
[02:42:49] <PeterW> Boardname is good so if you have a random baifile you can dump its IDROM and get ts exact configuration
[02:43:16] <jmkasunich> by loading it into the proper board?
[02:44:31] <PeterW> Yes. Bu there is another way, If I use a LOC contraint in the UCF file (havent yet)
[02:44:31] <PeterW> you could extract it from the bitfile without hardware
[02:45:00] <jmkasunich> ah, neat
[02:45:12] <jmkasunich> you'd need a magic decoder ring to make sense of that data, right?
[02:45:21] <SWPadnos> the driver has that
[02:45:27] <SWPadnos> so it can tell what to export
[02:45:57] <jmkasunich> but the driver doesn't have a way to feed it the idrom contents (except for reading them directly out of the board after loading the firmware)
[02:46:04] <PeterW> No I dont think so, at least I think the source of DATA2MEM is available
[02:46:44] <SWPadnos> sure - I'm just pointing out that a magic decoder is mostly written already - just use the same headers the driver uses and change things to printf instead of hal_pin_new (you know - more or less :) )
[02:46:58] <jmkasunich> PeterW: I don't mean the tool that extracts the memory data from the bitstream, I mean a decoder ring to interpret the pin_desc and module_id data
[02:47:02] <jmkasunich> a hostmot specific decoder
[02:47:13] <jmkasunich> SWPadnos: gotcha
[02:47:38] <PeterW> I have the program that creates the .PIN files
[02:48:20] <SWPadnos> I think jmkasunich has some tools to read out various sections of them, but I don't think it does the decoding that the chip does (those are compressed/encrypted, right?)
[02:48:40] <PeterW> I'm sure Jepler could recode it into about 5 lines of python :-)
[02:48:48] <jmkasunich> SWPadnos: all I can do is get the bitstream as a huge binary blob
[02:48:49] <SWPadnos> heh
[02:48:53] <SWPadnos> right
[02:49:00] <jmkasunich> extracting something specific from that blob is a xylinx tool job
[02:53:21] <PeterW> The bitstreams are are not compressed or encrypted (fancier FPGAs support this) so getting at blockram data is not hard
[02:53:23] <PeterW> We use DATA2MEM for debugging ROM firmware since its faster than rebuilding bitfiles
[02:54:00] <jmkasunich> data2mem puts data into FPGA memory blocks, or takes it out? or both?
[02:54:48] <PeterW> Not sure if it can take out we just use it to write, but the data is just sitting there
[02:56:41] <jmkasunich> jepler: you still here?
[02:57:03] <jmkasunich> it seems your tarball has "SVST8_4_5i20.spec" in it
[02:57:20] <jmkasunich> that wasn't generated by your program was it? (I bet you just tarred up *.spec)
[03:01:55] <PeterW> OK Data2MEM goes both ways (insert/extract)
[03:03:50] <jepler> jmkasunich: that's right
[03:04:26] <jmkasunich> I was sanity checking, the tarball had 28 specs in it
[03:05:07] <jmkasunich> arg
[03:05:31] <jmkasunich> vhdl identifiers can't start with numbers
[03:05:37] <jmkasunich> entity 5i20_SVST8_4_I20HostMot2 is
[03:05:53] <SWPadnos> m5i20...
[03:06:04] <jmkasunich> yean
[03:06:21] <jmkasunich> or Hostmot2_5i20_SVST8_4
[03:06:34] <jmkasunich> the I20 part is redundant now anyway
[03:06:37] <SWPadnos> yeah, the bitfile won't have that 1024 character name :)
[03:07:02] <SWPadnos> maybe reshuffle those also
[03:07:10] <jmkasunich> the bitfile will have "5i20_SVST8_4", I can either use it as a prefix or suffix for the entity
[03:07:14] <SWPadnos> hostmot2_5i20_sv4_st4
[03:07:38] <jmkasunich> that is the convention PeterW is using, I'm not planning to change it
[03:07:44] <SWPadnos> ok
[03:10:03] <jmkasunich> better: entity HM2_5i20_SVST8_4 is
[03:10:34] <PeterW> Feel free to change the names, eventually there will be more supported modules
[03:10:36] <PeterW> so you may have SVSTUARTSPI...
[03:10:36] <jmkasunich> WARNING:Xst:1336 - (*) More than 100% of Device resources are used
[03:10:37] <PeterW> Did Sebastian upload the last source (as of a couple of days ago)
[03:10:39] <PeterW> It has the (Horrors!) USB version of HostMot2
[03:10:42] <jmkasunich> that isn't encouraging
[03:10:56] <jmkasunich> yes, there is USB stuff
[03:11:17] <jmkasunich> SVST8_4 fits in a 5i20, doesn't it?
[03:11:26] <SWPadnos> should
[03:11:37] <jmkasunich> Selected Device : 2s200pq208-5
[03:11:37] <jmkasunich> Number of Slices: 2395 out of 2352 101% (*)
[03:11:45] <jmkasunich> is that the right device for a 5i20?
[03:12:15] <SWPadnos> yep
[03:12:18] <PeterW> YEp, righjt device and Yes, fits for me
[03:12:30] <jmkasunich> what did I break :-(
[03:12:41] <SWPadnos> PeterW, what version of the Xilinx tools are you using?
[03:13:05] <PeterW> 9.2 Ill do a compile now and see what I get
[03:14:22] <jmkasunich> here is my top level:
http://www.pastebin.ca/1283231
[03:14:41] <jmkasunich> does the module_id look right?
[03:15:14] <SWPadnos> http://pastebin.ca/1283231
[03:15:19] <SWPadnos> no www
[03:15:39] <SWPadnos> (at least, Mozilla couldn't find it on this machine)
[03:15:39] <jmkasunich> both work here
[03:16:03] <SWPadnos> it's text only here, using FF
[03:16:22] <SWPadnos> ok, now it works in Moz. strange
[03:18:54] <PeterW> Module ID looks fine
[03:19:10] <jmkasunich> I wonder how big a file pastebin will take
[03:19:16] <jmkasunich> the synthesis log is 206K
[03:19:44] <jmkasunich> 150K is the limit
[03:22:04] <PeterW> Logic Distribution:
[03:22:06] <PeterW> Number of occupied Slices: 2,350 out of 2,352 99%
[03:22:08] <PeterW> Number of Slices containing only related logic: 2,001 out of 2,350 85%
[03:22:09] <PeterW> Number of Slices containing unrelated logic: 349 out of 2,350 14%
[03:22:32] <jmkasunich> so its very tight, and apparently my version of the tools didn't pack it in quite as well as yours
[03:22:32] <SWPadnos> wow. that's pretty full :)
[03:22:47] <SWPadnos> 99.9% :)
[03:23:00] <PeterW> Did you actually try running map?
[03:23:01] <PeterW> It will often fit if no more than 105%
[03:23:12] <jmkasunich> no, I haven't gotten that far
[03:23:30] <PeterW> 101% will likely fit -- new math
[03:23:39] <jmkasunich> I guess that explains why it was an warning instead of an error
[03:23:52] <jmkasunich> time for me to tack a few more steps onto the end of this python program
[03:25:14] <PeterW> Also packing density depends on synthesis and map options...
[03:26:09] <jmkasunich> set -tmpdir ./tmp_syn
[03:26:09] <jmkasunich> set -xsthdpdir ./work_syn
[03:26:09] <jmkasunich> run
[03:26:09] <jmkasunich> -ifmt VHDL -ifn 5i20_SVST8_4.prj
[03:26:09] <jmkasunich> -top HM2_5i20_SVST8_4
[03:26:10] <jmkasunich> -ofmt NGC -ofn 5i20_SVST8_4.ngc
[03:26:12] <jmkasunich> -p xc2s200-5pq208
[03:26:17] <jmkasunich> synthesis options ^^^^^^
[03:26:40] <SWPadnos> hi seb
[03:26:55] <SWPadnos> damn. I need to order a 7i43 some time soon
[03:27:23] <seb_kuzminsky> hello
[03:27:27] <cradek> hi all
[03:27:39] <seb_kuzminsky> SWPadnos: dont you have one of the pci anyio cards?
[03:27:43] <seb_kuzminsky> hi cradek :-)
[03:27:48] <SWPadnos> several ;)
[03:28:06] <seb_kuzminsky> any last-second feedback on the encoder velocity stuff i've been hacking on before i merge it into 2.2?
[03:28:08] <SWPadnos> 3 5i20 and a 5i22
[03:28:21] <SWPadnos> plus another 5i22 I get to use for a long time
[03:28:28] <jmkasunich> seb_kuzminsky: sorry, I haven't made time to look at it
[03:28:36] <PeterW> OK got to go home...
[03:28:38] <PeterW> Thanks all!
[03:28:38] <jmkasunich> elbows deep in fpga build stuff
[03:28:45] <SWPadnos> see ya PeterW
[03:28:48] <jmkasunich> goodnight peter, thanks for the input
[03:28:59] <seb_kuzminsky> hi peter! goodnight
[03:29:16] <PeterW> Hi and Bye!
[03:29:54] <seb_kuzminsky> SWPadnos: is one of your 5i22's the 1.5Mgate model?
[03:30:00] <SWPadnos> yes, both
[03:30:15] <seb_kuzminsky> cool... do you know if hm2_pci detects them?
[03:30:22] <SWPadnos> no, I haven't tried it
[03:30:34] <cradek> are you guys making it easy for me to move encoder pins around?
[03:30:43] <jmkasunich> somewhat
[03:31:00] <jmkasunich> start downloading the xilinx tools, you might have them by the time this code is working
[03:31:05] <seb_kuzminsky> heh
[03:31:25] <cradek> I have luxuriously avoided learning anything about FPGAs so far...
[03:31:56] <jmkasunich> you'll be able to keep your learning to a minimum if all you want to do is move around some pins
[03:31:58] <seb_kuzminsky> it's good that we can lean on each other's work :-)
[03:32:05] <cradek> jmkasunich: oh good
[03:32:10] <cradek> seb_kuzminsky: so very true
[03:33:42] <seb_kuzminsky> jmkasunich: when preparing for 2.2 releases, i've been merging all of src/hal/drivers/mesa-hostmot2 from trunk to 2.2, including the firmware directory (to get the new .BITs)
[03:33:48] <seb_kuzminsky> you mind if i merge your stuff?
[03:33:50] <cradek> is it ISE Webpack that I want?
[03:33:55] <SWPadnos> yep
[03:34:02] <jmkasunich> seb_kuzminsky: I'd kind of rather not
[03:34:06] <SWPadnos> that's all you can get for free (that will continue to work after 90 days)
[03:34:10] <cradek> ugh, create an account
[03:34:16] <jmkasunich> it is in a state of extreme flux at the moment
[03:34:26] <SWPadnos> oh, on that note:
[03:34:37] <jmkasunich> (a file I added yesterday is being deleted today, for example)
[03:34:49] <seb_kuzminsky> jmkasunich: how about if i leave firmware/src out of it, but merge the rest
[03:35:08] <jmkasunich> sure - I believe everything I'm doing is in firmware/src
[03:35:24] <seb_kuzminsky> ok
[03:35:37] <SWPadnos> jepler, I think the GS2 code shouldn't go into 2.2 yet. I haven't confirmed that it works after the command line options were added (and I have no hardware to test), and the documentation isn't done - and I can't really finish it without a unit (at least, not very easily)
[03:36:15] <jepler> SWPadnos: ok, that's fine
[03:36:16] <jepler> there's no rush
[03:36:40] <SWPadnos> I'd like to get it in, but I think it's not quite right at the moment
[03:37:06] <jepler> SWPadnos: I sure don't want to push you
[03:37:24] <jepler> either there'll be a 2.2.9, or we'll finally do 2.3..
[03:37:27] <SWPadnos> heh
[03:37:35] <SWPadnos> we'll run out of numbers :)
[03:37:48] <jmkasunich> 2.2.834
[03:38:07] <seb_kuzminsky> when i first got started it confused me that x.10 > x.2
[03:38:08] <SWPadnos> ewww, we don't like no 3-digit minor-minor revisions
[03:38:14] <jepler> apt and dpkg know that 2.2.10 is after 2.2.9, I hope our users can figure it out too
[03:38:19] <SWPadnos> hah
[03:38:20] <jmkasunich> seb_kuzminsky: me too
[03:38:21] <SWPadnos> I mean, yeah
[03:38:36] <SWPadnos> lots of people don't get that Ubuntu is 8.10, not 8.1
[03:38:42] <SWPadnos> (for example)
[03:38:55] <seb_kuzminsky> really confuse them and count in hex 2.2.a
[03:39:01] <jmkasunich> when you put a second . in the version number, it helps a lot
[03:39:08] <jepler> has anybody tried to create an arithmetic over version numbers? perhaps we can find out if there is a way to compute sqrt(2.2.10) or the like
[03:39:15] <jmkasunich> makes people turn off their "this is a floating point number" parser
[03:39:59] <seb_kuzminsky> ok i'mma go do some cleanup for 2.2.9
[03:47:02] <jmkasunich> Logic Distribution:
[03:47:02] <jmkasunich> Number of occupied Slices: 2,382 out of 2,352 101%
[03:47:02] <jmkasunich> (OVERMAPPED)
[03:47:15] <jmkasunich> I guess I need to pick a less demanding one to test
[03:47:23] <jmkasunich> or a bigger board - maybe a 5i23?
[03:47:30] <SWPadnos> bummer
[03:47:34] <SWPadnos> do a 5i22-1.5
[03:47:45] <jmkasunich> 5i22 has 96 pins, not 72
[03:48:05] <SWPadnos> yes
[03:48:50] <jmkasunich> I dunno if a 72 pin config will be happy in a 96 pin chip (I know it will fit, but I think peter's pin-mapping VHDL wants an exact match, not >=
[03:48:59] <SWPadnos> right
[03:49:02] <SWPadnos> hmm
[03:49:15] <jmkasunich> there is a constraints file for the 5i23 in CVS
[03:49:22] <jmkasunich> I just need to make a .board file
[03:49:35] <jmkasunich> for which I need the device - that will be the trick I think
[03:49:38] <SWPadnos> ok, yeh - the 5i23 should be OK
[03:49:52] <SWPadnos> 3s400
[03:50:02] <SWPadnos> I can't quitw read the -blahblah on it
[03:50:04] <jmkasunich> does the 23 come in multiple flavors, like -1.5?
[03:50:12] <SWPadnos> doesn't look it
[03:50:16] <jmkasunich> good
[03:50:34] <SWPadnos> it's basically a 5i22-like spartan-3 unit - a 5i22/5i20 hybrid
[03:50:52] <jmkasunich> hmm, we don't have an I23HostMot2.vhd
[03:51:01] <jmkasunich> I20, I22, I43
[03:51:31] <SWPadnos> you could just tell the tools that the 5i22 has a 300k gate chip instead
[03:51:52] <SWPadnos> XC2S300-6PQ208C or something
[03:52:00] <jmkasunich> if I'm gonna create a .board file, I'd like to create an accurate one
[03:52:19] <jmkasunich> entity I22HostMot2 is -- also for 5I23 and 4I68
[03:52:25] <jmkasunich> ah-ha!
[03:52:41] <SWPadnos> heh
[03:53:27] <garage_seb> the chips used on each board is recorded in hm2_pci.c
[03:53:33] <garage_seb> (in case you care)
[03:53:42] <jmkasunich> I believe I do - thanks
[03:53:56] <garage_seb> it's in hm2_pci_probe()
[03:54:29] <garage_seb> the chips used on the 7i43 are in hm2_7i43.c
[03:55:30] <garage_seb> i'm going to make a hal parameter to control how long the encoder velocity estimator waits for another edge if the encoder is moving slow
[03:55:45] <cradek> yay, I came to my senses and didn't download that over the wireless
[03:55:57] <garage_seb> i'm thinking to call it encoder.XX.velocity-smoothing-timeout
[03:56:06] <garage_seb> sound ok?
[03:56:44] <jmkasunich> barely
[03:56:53] <SWPadnos> I have smoothing :)
[03:56:54] <SWPadnos> hate
[03:56:59] <jmkasunich> I think the name length limit is 40 chars
[03:57:06] <jmkasunich> filter-timeout?
[03:57:20] <SWPadnos> encoder.xx.motion-timeout
[03:57:21] <garage_seb> it's not really filtering, how about vel-timeout
[03:57:28] <jmkasunich> that works
[03:57:48] <garage_seb> it'll be in the manpage so i guess it's not too crucial
[03:57:49] <garage_seb> ok
[04:00:23] <jmkasunich> 70% usage
[04:00:33] <SWPadnos> huh
[04:00:44] <jmkasunich> wtf, mapping still failed
[04:00:48] <SWPadnos> lots of extra routing I guess
[04:01:07] <jmkasunich> Number of bonded IOBs: 147 out of 141 104% (OVERMAPPED)
[04:01:11] <SWPadnos> hmmm. it's a spartan3, not a spartan2 - you got the xc3s part, right?
[04:01:28] <jmkasunich> Using target part "3s400pq208-5".
[04:02:01] <jmkasunich> Applying constraints in "5i23.ucf" to the design...
[04:02:09] <jmkasunich> I assume that the constraints file is correct
[04:03:12] <jmkasunich> 123 pins identified in the .ucf file
[04:03:30] <SWPadnos> 24 extras sounds suspicious
[04:04:06] <jmkasunich> fsck
[04:04:23] <jmkasunich> IOPorts: integer := 4;-- 5I22
[04:04:23] <jmkasunich> IOWidth: integer := 96;-- 5I22
[04:04:23] <jmkasunich> --IOPorts: integer := 3;-- 5I23,4I68
[04:04:23] <jmkasunich> --IOWidth: integer := 72;-- 5I23,4I68
[04:04:38] <jmkasunich> peter hand edits things in the top level file depending on what he is building
[04:05:01] <jmkasunich> there are a half-dozen fields like that
[04:05:26] <jmkasunich> fortunately, I'm already doing substitution into that file
[04:05:43] <jmkasunich> soI can store the board specific values in the .board file
[04:06:10] <SWPadnos> right
[04:09:35] <SWPadnos> I'm not sure there's any way to use something like a DEFINE to get that information in there
[04:10:10] <jmkasunich> don't need to
[04:10:47] <jmkasunich> IOPorts: integer := ${ioports}; -- 5I22 = 4, 5i23, 4i38 = 3
[04:12:10] <SWPadnos> http://www.velocityreviews.com/forums/t24099-vhdl-has-no-define-like-verilog.html
[04:12:15] <SWPadnos> heh - see post #5 :)
[04:12:36] <SWPadnos> more or less what you're doing, but using the c preprocessor
[04:13:19] <jmkasunich> heh
[04:43:21] <jmkasunich> ok, that seems to have worked
[04:43:29] <jmkasunich> I now have 4 more .board files
[04:43:43] <jmkasunich> and the program works up thru the mapping phase
[04:43:50] <jmkasunich> place/route/bitgen next, but tomorrow
[04:44:30] <SWPadnos> cool
[04:49:13] <CIA-42> EMC: 03jmkasunich 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/firmware/src/ (11 files): more progress on autobuilding FPGA firmware - config data and board data are now independent
[04:49:31] <jmkasunich> I just gotta say, Python rocks
[04:49:36] <SWPadnos> heh
[04:49:55] <SWPadnos> I was thinking how much easier a lot of stuff (like completion) would be if halcmd were python
[04:50:12] <jmkasunich> spec2bit isn't exactly a work of art, but doing it in C would be a total nightmare (and about 10x as long)
[04:50:15] <SWPadnos> "source" becomes trivial
[04:50:19] <SWPadnos> yeah
[04:50:33] <SWPadnos> if you really knew the libraries well, you might get it into only 2x the amount of c++
[04:50:37] <SWPadnos> maybe 3x
[04:50:57] <jmkasunich> dicts and sets really saved a lot of code
[04:51:03] <SWPadnos> yep
[04:51:05] <jmkasunich> dunno if C++ has that in the libs or not
[04:51:07] <SWPadnos> yep
[04:51:38] <SWPadnos> various kinds of container, maps (indexing by non-integer types, like strings), etc
[04:51:54] <SWPadnos> in the STL anyway
[04:52:59] <garage_seb> jmkasunich: agreed, python is good stuff
[04:54:09] <jmkasunich> well, that's it for me tonight.....
[05:11:25] <garage_seb> have a good one
[07:48:17] <CIA-42> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/ (ChangeLog hostmot2.h): hostmot2 0.15!
[07:52:54] <CIA-42> EMC: 03seb 07v2_2_branch * 10emc2/configs/hm2-servo/ (README emc.nml m7i43.tbl m7i43.var m7i43_th.hal m7i43_th.ini): add some files i missed
[07:52:57] <CIA-42> EMC: 03seb 07v2_2_branch * 10emc2/src/hal/drivers/mesa-hostmot2/firmware/5i20/ (SVST8_4IM2.BIT SVST8_4IM2.PIN): add some files i missed
[07:53:01] <CIA-42> EMC: 03seb 07v2_2_branch * 10emc2/src/hal/drivers/mesa-hostmot2/firmware/7i43/ (SVST4_12.PIN SVST4_12B.BIT SVST4_6S.BIT): add some files i missed
[11:36:11] <micges> I was using hal_joystick today and:
[11:36:21] <micges> there is problem in ubuntu 8.04
[11:36:42] <micges> at first loadusr everything is ok
[11:37:09] <micges> but second and after will not create any hal pins after load
[11:44:42] <micges> when I "unload hal_joystick" it says that hal_joystick is not loaded
[11:45:22] <alex_joni> can you pastebin halcmd show all, after only loading hal_joystick ?
[11:52:41] <micges> when I use show all in hal file hal_joystick is loading properly
[11:53:25] <micges> and when loading only it in halcmd everything is ok also
[11:53:59] <micges> some delay issues ?
[11:58:01] <micges> here it is:
http://www.pastebin.ca/1283500
[12:06:30] <alex_joni> you need to wait for it to finish loading
[12:06:40] <alex_joni> -w or -W check the manpage from halcmd
[12:06:54] <alex_joni> the problem you are seeing is:
[12:07:01] <alex_joni> 3 User hal_joystick-22747
[12:07:10] <alex_joni> the name assigned is hal_joystick-22747
[12:07:54] <alex_joni> so if you want to unload hal_joystick, you can't by issuing unloadusr hal_joystcik
[12:14:07] <micges> alex_joni:
http://www.pastebin.ca/1283503
[12:14:29] <micges> after waiting 30 sec I pressed ctrl-c
[12:47:18] <micges> after adding two show all commands in hal file joy will not load in 1 for 4 runs
[12:47:40] <micges> except this everything is ok
[13:02:19] <jepler> because hal_joystick chooses an unpredictable component ID, it's not possible to write a hal file that uses -W or -Wn to wait for it. That is one reason it's deprecated in favor of hal_input, which does not have that problem.
[13:04:05] <jepler> (in trunk you can set the component name, but there's another problem: in violation of the hal convention, it never calls hal_ready)
[13:04:52] <jepler> (er, I take that back: it calls hal_ready, but creates pins after that)
[13:05:45] <jepler> so anyway you shouldn't use hal_joystick due to its bugs. you should use hal_input. if there's a bug that keeps you from using hal_input, you should report it.
[13:09:31] <BigJohnT> does the man page for hal_joystick need to be updated to indicate that it is deprecated?
[13:09:39] <jepler> BigJohnT: I am doing that
[13:10:12] <BigJohnT> ok
[13:12:54] <CIA-42> EMC: 03jepler 07TRUNK * 10emc2/docs/man/man1/hal_joystick.1: deprecated
[13:14:07] <CIA-42> EMC: 03jepler 07v2_2_branch * 10emc2/docs/man/man1/hal_joystick.1: deprecated
[13:16:03] <jepler> BigJohnT: my sympathies for your loss
[13:16:12] <jepler> * jepler heads to work
[13:16:15] <BigJohnT> thank you
[13:21:39] <micges> jepler: thanks I'll do it
[13:41:15] <micges> I've just installed our epp io interface card with original EMC 2.3 CVS from today to reproduce our problems
[13:43:10] <micges> and here they are:
[13:45:07] <micges> when I'm jogging in two direction and accidentally press any other key for 1 sec or more, and then release arrow keys machine will be still jogging and Escape button will not work
[13:49:14] <alex_joni> what GUI?
[13:49:32] <micges> axis
[13:49:58] <alex_joni> can you quickly check if it happens on one of the sim configs?
[13:50:05] <alex_joni> (it probably should..)
[13:50:22] <CIA-42> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/components.lyx: note that hal_joystick as depreciated
[13:51:32] <CIA-42> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/hal/components.lyx: note that hal_joystick as depreciated
[13:53:19] <micges> so that button was SHIFT and second try was L key and he locks axis
[13:53:44] <micges> oh it happend also in sim
[13:55:44] <micges> sim_mm.ini to be specific
[14:03:56] <alex_joni> ok, that's a report that helps
[14:04:11] <alex_joni> it would be even better if you submit a bugreport on SF so we don't forget about it :)
[14:05:35] <micges> hehe ok
[14:10:22] <micges> bug 2005158 can be closed thanks to cradek
[14:17:35] <alex_joni> jepler: didn't you fix 1650938 recently?
[14:23:03] <SWPadnos> micges, if you tap the jogging keys after releasing the other key, does jogging stop?
[14:27:27] <BigJohnT> * BigJohnT heads out to noodlehead around
[14:27:43] <SWPadnos> noodlehead :)
[14:27:51] <BigJohnT> :)
[14:29:49] <micges> SWPadnos: jog press -> key press -> key -release -> jog release -> jog is working -> jog key press -> jog in pressed direction is stopping
[14:30:03] <SWPadnos> ok
[14:30:29] <SWPadnos> I think the main problem is in X / the keyboard (not enough rollover)
[14:31:10] <SWPadnos> I don't know whether there's also a bug in EMC because ESC doesn't stop the motion though, when it's "jogging away"
[14:32:08] <micges> when L is pressed ESC doesn't work
[14:32:27] <micges> L is functional in AXIS
[14:32:47] <micges> so something is working so esc doesn't work
[14:33:03] <micges> L - override soft limits
[14:33:04] <SWPadnos> what does L do?
[14:33:06] <SWPadnos> ok :)
[14:33:43] <micges> I have this issue becouse my AXIS have jogging with max_vel with shift + arrow
[14:34:15] <micges> so sometimes was very noisy stop :)
[14:34:20] <SWPadnos> heh
[14:39:13] <CIA-42> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: this wait_complete caused the gui to become unresponsive after "L" was pressed in sim/axis_mm.ini
[14:46:23] <micges> ok so with shift key issue is on X ?
[14:46:53] <micges> maybe some watchdog for jogging
[14:47:09] <micges> ok another issue:
[14:47:32] <SWPadnos> I'm not sure, but I know that some keyboards don't work correctly with more than 2 or 3 keys pressed simultaneously
[14:48:48] <CIA-42> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: stop jogging when an arrow is released, no matter what modifier keys are pressed
[14:49:54] <micges> when I'm load axis and run program, after some joint following errors or hitting emergency stop blending mode will be enabled after reenable and rerun
[14:50:13] <micges> even if gcode_init in ini file has G61
[14:50:18] <SWPadnos> looks like this was an AXIS problem ;)
[14:52:27] <SWPadnos> the RS274_STARTUP_CODES only get executed at EMC startup, not before every program (AFAIK)
[14:52:33] <jepler> micges: if you want a modal code, specify it in your part program.
[14:52:54] <jepler> for the reason SWPadnos says
[14:54:58] <jepler> http://linuxcnc.org/docs/html/config_ini_config.html#RS274NGC%20STARTUP%20CODE http://linuxcnc.org/docs/html/gcode_main.html#r3_4
[14:58:15] <micges> ok correct
[14:59:08] <micges> emc startup-> execute G61 => run program with G61 => emergency stop => enable machine => run program (now it is in G64 PN mode)
[14:59:11] <SWPadnos> then again, if you never set G64 in your program, I don't see why it would be set after an E-Stop
[14:59:54] <micges> jepler SWPadnos: problems with keyb fixed
[15:00:00] <alex_joni> SWPadnos: I think it gets reset to the default way
[15:00:16] <alex_joni> micges: but if you put G61 as the first thing in your program it should be ok
[15:00:31] <SWPadnos> is G64Pn the default?
[15:00:42] <alex_joni> I think G64 is default, but might be wrong
[15:00:46] <SWPadnos> huh
[15:04:10] <jepler> I put the following in an ngc file ("/" representing line breaks): G61 / G20 / G0 X0 Y0 Z0 / G1 X1 F999 / G1 Y1 F999 / M2
[15:04:24] <jepler> I turned down my acceleration so that in G64 mode the blend is quite obvious
[15:04:47] <jepler> If I hit R ESC R, it still operates in G61 mode.
[15:05:27] <SWPadnos> is ESC equivalent to external e-stop?
[15:05:42] <jepler> if I hit R F1 F1 F2 R it still operates in G61 mode
[15:05:51] <SWPadnos> ok :)
[15:05:59] <alex_joni> ESC is abort, F1 is equivalent to ext estop
[15:06:24] <SWPadnos> I thought they were different, but that isn't the problem :)
[15:07:17] <micges> ok more info in monday, its weekend for me
[15:07:29] <micges> thanks for you all
[15:07:32] <jepler> bye
[15:07:44] <SWPadnos> see you
[15:07:50] <micges> see you all
[15:21:46] <CIA-42> EMC: 03jepler 07TRUNK * 10emc2/docs/src/hal/components.lyx:
http://www.dailywritingtips.com/deprecate-depreciate/
[15:22:03] <CIA-42> EMC: 03jepler 07v2_2_branch * 10emc2/docs/src/hal/components.lyx: from TRUNK
[15:22:06] <SWPadnos> heh
[15:22:22] <SWPadnos> its value has depreciated because it has been deprecated
[15:25:08] <jepler> now I just have to hope I never screw it up myself
[15:25:13] <SWPadnos> heh
[15:25:25] <SWPadnos> especially with a link in the commit message
[15:31:03] <seb_kuzminsky> heh:
http://github.com/ "git repository hosting: no longer a pain in the ass!"
[15:31:11] <SWPadnos> heh
[15:43:46] <seb_kuzminsky> later
[15:51:29] <jmkasunich> hello world!
[15:52:35] <jepler> hi jmkasunich
[15:52:38] <jepler> enjoying your freedom?
[15:52:57] <jmkasunich> yep, starting with the freedom to sleep till 10am
[16:01:40] <skunkworks_> * skunkworks_ loves sleeping late..
[16:01:50] <skunkworks_> it's the little things in life
[16:02:06] <jmkasunich> ;-)
[16:06:47] <SWPadnos> heh
[16:20:21] <cradek> that's not a little thing! (and I did it too)
[16:20:32] <cradek> well, 9 anyway
[16:22:01] <skunkworks_> what - did everyone including my wife take today off?
[16:25:02] <SWPadnos> no, I'm at work
[16:25:06] <SWPadnos> but I sleep in anyway :)
[16:35:45] <CIA-42> EMC: 03jepler 07v2_2_branch * 10emc2/src/po/ (sv_axis.po se_axis.po): rename swedish translation to match gettext standard
[16:36:18] <CIA-42> EMC: 03jepler 07v2_2_branch * 10emc2/debian/ (changelog emc2.files.in): package partial swedish translation properly. note fixes.
[16:37:39] <jepler> hi seb
[16:37:45] <jepler> thanks for working on hostmot in 2.2
[16:41:02] <seb_kuzminsky> hi jeff, i just realized i emailed you my changelog instead of checking it in my self, sorry about that!
[16:41:08] <seb_kuzminsky> i know you're not my secretary...
[16:41:28] <jepler> no problem
[16:41:43] <jepler> didn't take me 2 minutes to do it, and it made me find something in my 2.2 tree that needed to be committed anyway
[16:41:55] <seb_kuzminsky> re: micges' bug report
[16:42:14] <seb_kuzminsky> dont you love it when they come in the days before the release, instead of the days after? ^_^
[16:42:44] <jepler> I didn't make the fixes in 2.2 anyway
[16:42:55] <seb_kuzminsky> oh
[16:42:59] <seb_kuzminsky> why not?
[16:43:15] <jepler> not sure I'll have time to test them adequately
[16:43:42] <seb_kuzminsky> makes sense
[16:44:16] <seb_kuzminsky> i was finishing up encoder velocity earlier this week in preparation for merging something sensible into 2.2
[16:44:27] <seb_kuzminsky> i thought i had it all figured out, it'd been running flawlessly for a while
[16:44:55] <jepler> particularly the one where I removed a 'wait_complete' -- it must have been there for a reason in the first place, but today it was causing a problem...
[16:45:09] <seb_kuzminsky> then as i shut down emc last night to work on the merge, i noticed warning messages from a "should never happen" sanity check... :-(
[16:45:10] <jepler> the other one I feel better about, because it just turns off some code that would cause the arrow keys to be ignored
[16:45:17] <jepler> uh oh!
[16:45:50] <seb_kuzminsky> it recovers and there's a one-servo-cycle glitch in velocity estimation, but no other bad effects
[16:46:08] <seb_kuzminsky> 2.2 is fine, i'll catch this one later...
[16:46:12] <jepler> ok
[17:10:44] <SWPadnos> hmmm
[17:11:14] <SWPadnos> for the hostmot2 stepgens, what's the "recommended" I/O interface?
[17:11:54] <SWPadnos> the turn-on/turn-off times on the 7i37 are pretty long, and you have to add those to the step/dir limits of the drive to get reliable operation
[17:12:18] <SWPadnos> (or maybe you add 2x the difference - I'd have to think about it)
[17:12:29] <skunkworks_> whichever is larger?
[17:12:34] <SWPadnos> no
[17:13:00] <jepler> when I get around to trying it I'll just use direct connection
[17:13:12] <jepler> which should also be fine for stepper drives that have their own isolation
[17:13:47] <SWPadnos> yeah, that makes sense, though it's not trivial - there's no "pass-through" connection on the 7i37, and you'd probably want some of your I/Os to be isolated or conditioned somehow
[17:14:12] <SWPadnos> so you'd want to be able to connect a Mesa interface card and have the direct connects at the same time ...
[17:15:02] <skunkworks_> does anyone make a pass-thru breakout board?
[17:15:04] <skunkworks_> :)
[17:15:07] <SWPadnos> $$$$
[17:15:21] <SWPadnos> you're better off spending the extra bucks on the next higher gate count Mesa card ;)
[17:15:46] <SWPadnos> though I suppose a 3-connector SCSI cable would do in a pinch ;)
[17:15:47] <jtr> use a ribbon cable with three connectors and add a breakout board?
[17:16:02] <jtr> timiing is everything...
[17:16:06] <jtr> -i
[17:16:11] <SWPadnos> 50-pin breakouts are $35 or so for the cheapest you can find
[17:16:30] <SWPadnos> and $100+ for "high quality" ones, like Phoenix Contact or Weidmuller
[17:16:32] <skunkworks_> or - a scsi 50 pin cable with 3 connectors..
[17:16:41] <SWPadnos> echo echo?
[17:16:47] <skunkworks_> jeez
[17:16:50] <SWPadnos> heh
[17:16:56] <skunkworks_> I have to read before typing.
[17:17:02] <SWPadnos> multitasking
[17:17:59] <SWPadnos> the 7i37 can only go to ~140 kHz, surprisingly (and that's without taking driver timing into account)
[17:18:04] <jepler> there's also the 7i42, a non-isolated card that adds some overvoltage and esd protection without limiting signal bandwidth too much (10MHz, it says)
[17:18:27] <jepler> "diode clamps and 50 Ohm current limit resistors in series with all I/O pins"
[17:19:06] <SWPadnos> ah yes. thanks
[17:20:19] <jepler> but yeah I'd be tempted to run a 3-connector SCSI cable to both a 7i42 and a 7i37 if I needed both on one connector
[17:20:57] <SWPadnos> yeah. that would be better than a berg-stick with wires dangling off
[17:24:32] <jepler> spent yesterday trying to "port" this to the atmega168 (should just be a matter of different register names), but failed to get a blinking LED. :(
http://www.cq.cx/ladder.pl
[17:25:21] <jepler> but at least I got the winelib version working (code generation tests pass and gui works)
[17:26:44] <jepler> (atmega168 is the chip on the trendy arduino board, so I think a lot of people would be interested in it)
[17:27:54] <skunkworks_> very cool!
[17:28:50] <jepler> it would be cooler if it worked!
[17:29:57] <skunkworks_> After lurking here for so long - I don't think that is an issue. (it will work soon) :)
[17:31:53] <jepler> heh
[17:32:01] <jepler> there's at least a 50-50 chance that I lose interest and never mention it again
[17:33:04] <SWPadnos> do you have any assembly code, or does that generate a flash image?
[17:33:13] <jepler> SWPadnos: it generates a .HEX
[17:33:17] <SWPadnos> bummer
[17:33:22] <SWPadnos> I guess I could disassemble it
[17:33:40] <SWPadnos> actually, the better thing to do would be to look at the code they generate in the source :)
[17:33:42] <jepler> I've reviewed the hex in avr-objdump but there's enough code even for a simple ladder that my eyes went crossed
[17:33:58] <SWPadnos> simple like out1=in1 ?
[17:34:24] <jepler> well that might be worth trying -- I was doing a "blink led every 200ms" program
[17:34:48] <jepler> but I *think* that the problem is with how it initializes the timers, not in the ladder logic itself
[17:34:53] <SWPadnos> if you could stick an objdump somewhere, I'd like to take a look at it
[17:34:56] <SWPadnos> yeah, probably
[17:35:08] <SWPadnos> if so, out=in won't work either
[17:35:16] <jepler> "how" including what register numbers and bits are involved
[17:35:24] <SWPadnos> yep
[17:35:47] <jepler> I suspended the laptop where I'm working on it, so I can't get you a hex or an objdump at the moment
[17:35:56] <SWPadnos> ok, no rush :)
[17:36:31] <SWPadnos> I'm not sure which of the mega162 or the mega16 is closest to the 168 (I'm assuming it's one of those)
[17:36:59] <jepler> the family is atmega48/88/168
[17:37:15] <jepler> the registers are not very compatible with atmega16 or atmega8 as far as I could tell
[17:37:26] <SWPadnos> hmm
[17:41:15] <jepler> probably I should read this:
http://www.atmel.com/dyn/resources/prod_documents/doc2553.pdf
[17:41:20] <jepler> since ldmicro is supposed to work on mega8
[17:41:44] <SWPadnos> ldmicro?
[17:41:52] <jepler> that ladder software
[17:41:57] <SWPadnos> oh, right :)
[17:42:09] <SWPadnos> I was wondering where that extra instruction came from
[17:47:02] <jepler> extra instruction?
[17:49:08] <jepler> oh, you mean you thought 'ldmicro' was an avr instruction
[17:49:22] <jepler> I think we can all agree that we're both confused
[17:51:12] <SWPadnos> yeah :)
[17:51:15] <SWPadnos> I know I am
[17:51:29] <SWPadnos> in other news - woohoo! the lathe is mine :)
[17:51:40] <seb_kuzminsky> yay new lathe for SWPadnos
[17:51:45] <SWPadnos> well, actually jmk's, but it'll be mine when I pay him for it
[17:51:58] <SWPadnos> yep, kinda like cradeks
[17:54:50] <jepler> SWPadnos: congrats
[17:55:00] <SWPadnos> thanks
[17:55:07] <SWPadnos> now all I have to do is get it here :)
[18:20:56] <seb_kuzminsky> hi mshaver
[18:21:04] <mshaver> hey seb!
[18:21:53] <skunkworks_> Road Trip!
[18:22:08] <mshaver> To?
[18:23:24] <skunkworks_> hgr ( SWPadnos has a new toy he needs to pick up)
[18:24:32] <mshaver> I've never been there, they tell me it's nice
[18:33:27] <seb_kuzminsky> mshaver: hm2 still working well for you? anything missing or any other feedback? (i'm guessing not since i havent heard anything)
[18:41:49] <SWPadnos> I'll bet HGR is only "nice" under special circumstances :)
[19:27:27] <cradek> SWPadnos: neato
[19:27:38] <SWPadnos> yeah. woohoo!
[19:27:53] <SWPadnos> now I'm trying to find out what HGR's holiday hours are
[19:27:55] <cradek> need to borrow my tape punch?
[19:27:59] <SWPadnos> heh
[19:28:07] <SWPadnos> no, need an extra tape reader? :)
[19:28:36] <cradek> nope, thanks though
[19:29:18] <SWPadnos> sure, any time
[19:29:53] <SWPadnos> unfortunately my lathe-moving friend isn't available next week, so now I'm looking into backup "general purpose" friends
[19:31:31] <cradek> what kind of help do you need?
[19:31:34] <SWPadnos> and unfortunately, my best prospect isn't really available until Dec. 29-30 or so
[19:31:51] <SWPadnos> well, I'd like to have someone else in the car for the 700 mile drive with 4000 pounds of stuff on the trailer
[19:32:09] <SWPadnos> plus, it's better to have two drivers, since it will probably be a 12 hour drive (or more)
[19:32:13] <cradek> ah, just general driving help
[19:32:38] <SWPadnos> yep, that plus a little extra thought power when securing the load, watching the load, ...
[19:33:05] <SWPadnos> then again, I might be able to convince my wife to go with me next Friday - Sunday, which could be fun :)
[19:33:21] <SWPadnos> (since Dec. 20 is the Saturday they're open)
[19:53:55] <cradek> ouch, 700/55 = 13 hours
[19:54:14] <cradek> I thought my trip was long...
[19:55:33] <SWPadnos> google says it's 600 miles (exactly!) from where we'd meet to HGR
[19:55:50] <SWPadnos> but I don't expect to make 55 miles/hour with a trailer, in the winter
[19:56:13] <SWPadnos> going through Buffalo and the rest of upstate NY, plus Vermont
[19:56:56] <cradek> oh you think you will be going even slower than that?
[19:57:04] <SWPadnos> I'm not sure
[19:57:15] <cradek> I think I'd plan 4 days, not 3 :-)
[19:57:31] <SWPadnos> the trailer is 1800 pounds, and the machinery will come close to the 6500 pound tow capacity
[19:57:32] <SWPadnos> heh
[19:57:56] <SWPadnos> so I'll probably take it easy on the interstate. I do so love being able to actually stop
[19:58:16] <cradek> does your trailer have electric brakes (and your truck knows how to run them?)
[19:58:20] <SWPadnos> yes
[19:58:23] <cradek> oh good
[19:58:25] <SWPadnos> it's just the Jeep ...
[19:58:38] <SWPadnos> so the load will be more than the vehicle weight
[19:59:24] <alex_joni> hi all
[19:59:30] <cradek> hi
[19:59:39] <SWPadnos> hi
[19:59:54] <alex_joni> http://www.probotix.com/FireBall_v90_cnc_router_kit/ <- cool machine
[20:00:01] <alex_joni> and AXIS in the vid
[20:00:55] <SWPadnos> yeah, but does it work with EMC? :)
[20:00:57] <SWPadnos> oh, right
[20:01:48] <skunkworks_> there is a group on yahoo for the fireball
[20:01:57] <alex_joni> http://www.probotix.com/cnc_software/
[20:06:02] <cradek> bbl
[20:06:13] <cradek> two hours of daylight not to waste
[20:10:16] <jmkasunich> I almost bought this:
http://www.hgrindustrialsurplus.com/search-products/product-detail.aspx?id=12-182-233
[20:10:22] <jmkasunich> (or at least one very much like it)
[20:10:41] <fenn> why didnt you?
[20:10:48] <jmkasunich> overall diameter maybe 8", rotating part about 6", low or no backlash
[20:11:04] <jmkasunich> because it would probably sit in my basement for a long time
[20:11:55] <SWPadnos> heavy, I imagine
[20:12:00] <jmkasunich> not really
[20:12:07] <SWPadnos> I wonder what the ratio is
[20:12:10] <jmkasunich> lift with one hand
[20:12:15] <SWPadnos> hmm
[20:12:17] <SWPadnos> cool
[20:12:28] <SWPadnos> ok, yeah. about like a small rotary table
[20:12:28] <jmkasunich> its only about 3" thick
[20:12:38] <SWPadnos> (the cheapo 6" ones on ebay)
[20:12:48] <jmkasunich> yeah, except the input shaft is concentric with output (on the back)
[20:13:03] <SWPadnos> hmmm
[20:13:06] <jmkasunich> I suspect better backlash too
[20:13:08] <SWPadnos> 8" you say
[20:13:10] <jmkasunich> it is a robot arm joint
[20:13:15] <jmkasunich> roughly
[20:13:33] <jmkasunich> that is the dia of the stationary part, the rotating part is probably 5-6"
[20:13:51] <skunkworks_> is that this style?
http://www.harmonicdrive.net/reference/operatingprinciples/
[20:13:53] <SWPadnos> right. sounds about right for an AC motor reducer
[20:14:16] <jmkasunich> skunkworks_: not a harmonic reducer
[20:14:20] <skunkworks_> ok
[20:14:30] <jmkasunich> "cyclo reducer" it says, I think planetary gears, but not sure
[20:15:11] <jmkasunich> http://www.industrysearch.com.au/Products/Fine_Cyclo_Speed_Reducers-5122
[20:16:45] <skunkworks_> heh - they spec them for robotics
[20:16:56] <jmkasunich> these are definitely robot arm joints
[20:17:03] <jmkasunich> the one I was looking at was labeled "JT4"
[20:21:17] <skunkworks_> jmkasunich: I think this is the final for testing. I think the layout is a little better thought out. Time will tell :) (still think it looks sexy)
http://imagebin.ca/img/mHeU8Hih.png
[20:23:36] <jmkasunich> fancy
[20:24:22] <skunkworks_> Eagle is pretty powerful. I really am impressed with the free version.
[20:49:13] <SWPadnos> skunkworks_, what are the trace/space widths?
[20:50:34] <SWPadnos> specifically, the long horizontal traces between PAD4 and PAD5, above the ground tie point (I think) look pretty close together
[20:51:31] <SWPadnos> (the trace connects the + side of C20 and C13)
[20:53:14] <jmkasunich> there's no reason the blue flood below that bundle of traces needs to "bump up" the way it does
[20:53:29] <jmkasunich> if it went straight across, there'd be room to spread out those horizontal traces
[20:53:37] <SWPadnos> right. I was thinking the same thing
[20:54:06] <SWPadnos> the flood above also doesn't need to "bump down" quite as far
[20:55:52] <SWPadnos> I'm curious to see if a machined and non-plated-through version of this board works as well as a plated-through board, especially if the non-machined board uses a heavier copper pour (like 2 oz)
[20:58:19] <SWPadnos> wow. copper clad board isn't cheap
[21:00:54] <fenn> depends where you get it
[21:01:29] <fenn> seller abcfab on ebay has random cutoffs for $1/lb
[21:02:22] <SWPadnos> oh, I was checking DIgiKey, 2oz copper clad
[21:03:39] <SWPadnos> hmmm. I guess I should go snow-blow the driveway before it gets dark
[21:03:43] <SWPadnos> and cold
[21:03:55] <jmkasunich> already is cold
[21:04:00] <jmkasunich> hence the snow
[21:05:10] <SWPadnos> colder
[21:13:03] <micges> jepler: I've checked that external stop execute different code path than hitting F1, maybe this is the problem that you not see blending
[21:16:16] <skunkworks_> .04, .08, .032, .032. (top down)
[21:17:00] <SWPadnos> space width is more importnat than trace width
[21:17:09] <SWPadnos> in this case anyway :)
[21:17:15] <skunkworks_> I was trying to keep all power traces .5 inch
[21:17:21] <micges> SWPadnos: what was the command for making patch ? (bad memory I have)
[21:17:28] <SWPadnos> diff -u ?
[21:18:08] <skunkworks_> But with the wrap around of the bottom blue trace I could make the bottom bump-up less. (total trace width would still be above .5")
[21:18:20] <micges> thanks
[21:18:24] <SWPadnos> it's the spacing that makes me wonder ...
[21:18:40] <SWPadnos> if that top trace is .040, then the spacing must be 0.008 or so
[21:18:45] <SWPadnos> from the graphic anyway
[21:19:02] <jmkasunich> IMO spacing should be 0.015 minimum
[21:19:04] <SWPadnos> you should probably have .015 or more there
[21:19:06] <SWPadnos> heh
[21:19:31] <SWPadnos> especially if anything in that area is supposed to have high voltages on it
[21:19:50] <skunkworks_> it is .015
[21:19:56] <SWPadnos> arc voltage is ~8V per mil, in dry air
[21:20:04] <SWPadnos> ok, it looks narrow - could just be the screenshot
[21:20:28] <SWPadnos> now to snowblow :)
[21:20:44] <skunkworks_> none of those should have high voltage. That is why the gap is wider between the top trace and the bump down
[21:21:29] <skunkworks_> it is 15v,gnd,rightpwm,enable. (top to bottom)
[21:21:54] <skunkworks_> *12v
[21:24:27] <skunkworks_> I am shooting for .05 isolation for everything HV. (max limit as the driver ic has HV and +VCC right next to each other.)
[21:30:05] <skunkworks_> * skunkworks_ has no clue how they can rate the chip for 800v
[21:30:42] <skunkworks_> * skunkworks_ has no clue how they can rate the chip for 600v
[21:31:11] <micges> in emctask.cc in line 198: duplicate call to emcSpindleAbort()
[21:32:15] <jepler> cvs diff -u filename.c
[21:32:26] <jepler> isn't this on the wiki?
[21:32:51] <alex_joni> micges: I don't see that
[21:32:52] <alex_joni> http://cvs.linuxcnc.org/lxr/source/src/emc/task/emctask.cc#198
[21:33:01] <jepler> "Generate patches with "cvs diff -up" (or "cvs diff -u" if -p is not supported)"
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?CVS#Patch_Submission
[21:33:37] <micges> 190 and 198 in that file
[21:34:22] <skunkworks_> maybe potted.
[21:35:52] <jepler> I created an external estop condition by unlinking iocontrol.0.emc-enable-in and then using 'setp ...-in 0' to stop the machine. I still didn't see any blending problem.
[21:37:45] <micges> ok, I will be trying to reproduce, thanks jepler
[21:39:38] <jepler> but not right now -- remember that it's your weekend!
[21:40:41] <micges> jepler: yes I it, beer is coming (just last try before release)
[21:41:03] <jepler> bottoms up
[21:41:25] <alex_joni> jepler: no answer from max (the guy who said he's going to test the stg driver change)
[21:42:03] <alex_joni> so I guess we'll leave it out of 2.2.8 then
[21:43:34] <micges> good night
[22:01:13] <SWPadnos> hey cradek, if you have a chance, I'm curious as to how you secured your lathe for transport
[22:01:30] <alex_joni> duct tape
[22:01:39] <SWPadnos> ooooh, good idea!
[22:03:26] <skunkworks_> I would be a little leary of ratchet straps... chains and come-alongs or binders.
[22:03:44] <SWPadnos> yeah. I have big ratchet straps. 10k or 12k load rating
[22:04:06] <SWPadnos> chains and come-alongs can be problematic because they mar things
[22:04:07] <skunkworks_> ok - better.
[22:04:21] <SWPadnos> so lots of grooved wood
[22:04:49] <SWPadnos> and maybe chains also, to the floor mounts
[22:25:59] <SWPadnos> heh. hotels around Niagara Falls are cheap this time of year :)
[22:26:03] <jmkasunich> does the trailer have a wood floor?
[22:26:09] <SWPadnos> yes, I think so
[22:26:32] <SWPadnos> I'm not sure what the girder spacing is underneath
[22:26:35] <jmkasunich> 2x4s and spikes, nail them around the base of the machine so it can't slide
[22:26:45] <SWPadnos> yep, true
[22:26:48] <jmkasunich> then you can focus the straps on securing the upper parts
[22:27:12] <skunkworks_> I think the copper I have (atleast bought as) 4oz - but I have not measured it.
[22:28:13] <SWPadnos> wow. I didn't even notice that the rates are in Canadian dollars
[22:29:39] <skunkworks_> ok - 2oz
[22:29:55] <SWPadnos> heh
[22:29:56] <skunkworks_> (found the email)
[22:30:17] <SWPadnos> 4 oz isn't too common (for proto houses anyway)
[22:30:39] <SWPadnos> you usually get charged a bit more for it, and it increases the minimum feature size
[22:31:23] <skunkworks_> remember my cutter makes a minimum isolation of .008-.010 to begin with.
[22:31:41] <SWPadnos> it would be funny to pull into the Hilton Niagara Falls with a big greasy lathe on a big greasy trailer :)
[22:31:47] <SWPadnos> yep
[22:31:55] <skunkworks_> heh
[22:31:58] <SWPadnos> it's not as much of a problem when milling
[22:32:14] <skunkworks_> I would tarp it...
[22:32:17] <SWPadnos> at $79/night( O_O ), it's actually not a bad deal
[22:32:30] <skunkworks_> your going to get tons of road crap on it
[22:32:40] <SWPadnos> not tub, sauna, 10000 square foot pool ...
[22:32:40] <skunkworks_> *salt
[22:32:42] <SWPadnos> yep
[22:32:46] <SWPadnos> there will be a tarp
[22:32:59] <SWPadnos> straps, then tarp, then big bungees
[22:33:10] <skunkworks_> straps work good for tarps also.
[22:33:17] <SWPadnos> then rocks and more straps :)
[22:33:32] <SWPadnos> yeah, but I want to see what I'm going to break if I hit a bump
[22:33:52] <SWPadnos> Steve S also suggested spraying oil or grease on the thing
[22:34:24] <SWPadnos> actually, I think he said the best thing is to coat it with grease, wrap it in palette wrap (plastic), then strap it down and throw a tarp on it
[22:34:26] <skunkworks_> when we brought the puma arm home - it looked like we had a dead body wrapped up in a tarp. back of the pickup.
[22:34:33] <SWPadnos> then, you can drive through rain and stuff
[22:34:38] <SWPadnos> heh
[22:34:42] <skunkworks_> bbl
[22:34:44] <SWPadnos> help ... me
[22:34:47] <SWPadnos> see you
[23:32:20] <cradek> SWPadnos: I got it where I wanted it on the trailer (measured tongue weight), then screwed 4x4 to the trailer so it couldn't move, then chains over wood over the ways to hold it down, then tarp etc.
[23:32:24] <cradek> oops
[23:32:35] <cradek> oh, this is the right channel, -oops
[23:33:01] <SWPadnos> ok
[23:33:05] <SWPadnos> thanks
[23:33:14] <SWPadnos> I assume you didn't test its crash-worthiness
[23:33:15] <cradek> moving an inch back would change the tongue weight from 'correct' to 'negative'
[23:33:20] <SWPadnos> heh
[23:33:35] <cradek> so make positive the base of it can't move
[23:34:05] <SWPadnos> I think I may have a little more leeway - what was the tongue weight limit of the tow vehicle fo ryou?
[23:34:44] <cradek> not sure of the limit, but it said tongue weight should be 10% of the load, so 4-600 lb
[23:35:12] <SWPadnos> ok
[23:35:27] <SWPadnos> did you have a dual-axle trailer?
[23:35:31] <cradek> yes
[23:35:47] <SWPadnos> ok (probably necessary at that weight)
[23:36:03] <cradek> I ended up with the lathe mostly over the axles and the control behind it
[23:36:18] <cradek> headstock forward iirc
[23:36:37] <SWPadnos> ok
[23:36:53] <SWPadnos> I'll have to look at the positioning of the wheels on this trailer
[23:37:06] <SWPadnos> it's a tandem axel as well, 18' IIRC
[23:37:17] <jmkasunich> big trailer
[23:37:33] <SWPadnos> the Jeep has a 700 pound tongue weight limit, so 10% to 700 pounds should be easy to hit
[23:37:44] <SWPadnos> yeah, it's a little bigger than I'd like, but it should be big enough :)
[23:38:02] <SWPadnos> I guess if I can't move the lathe to a good spot I'll have to buy other junk and stick it in the front :)
[23:39:50] <SWPadnos> ok, now to actually leave for dinner :)
[23:39:56] <cradek> it's true that it will be rare that you will make this drive...
[23:40:13] <SWPadnos> with a trailer
[23:40:21] <SWPadnos> I go by a couple of times a year actually :)
[23:44:27] <jmkasunich> but usually on weekends
[23:44:57] <jmkasunich> oh, btw - when I arrived at HGR, they were just finishing hanging a big banner on the outside - open _every_ saturday in 2009
[23:45:26] <cradek> wow
[23:46:01] <jmkasunich> they get a lot of traffic on saturdays
[23:46:13] <jmkasunich> I'm sure there will be some drop-off when it is every sat, but still
