Back
[01:01:26] <petev> any NML experts out there?
[01:01:59] <petev> can anyone explain why emc.nml only has process entries for xemc and keystick and not the other GUIs?
[01:03:11] <petev> also, why does the client.nml file define SHMEM buffers on another host? It also doesn't define the IO controller buffers which leads me to beleive these lines are not being used anyhow
[01:03:46] <cradek> I think the guis all call themselves xemc
[01:03:50] <cradek> the rest I have no clude
[01:03:54] <cradek> or clue either
[01:03:57] <petev> hmm
[01:37:56] <jmkasunich> hi guys
[01:38:14] <cradek> hi jmk
[01:44:10] <petev> jmkasunich, I read your gpio email
[01:44:16] <jmkasunich> good
[01:44:30] <jmkasunich> I'm submitting a bug report to SF rignt now, let me finish it up
[01:44:38] <petev> ideally the HW config and HAL view would be checked against the VHDL somehow
[01:44:43] <petev> ok
[01:45:56] <petev> cradek, take a look here:
[01:45:56] <petev> http://www.isd.mel.nist.gov/projects/rcslib/NMLcfg.html
[01:46:21] <petev> looks like the host name on a buf line is where the process looks for the buf
[01:46:29] <petev> the host name on the proc line is something else
[01:46:36] <petev> where the proc is expected to run
[01:46:45] <petev> not sure why that is even needed
[01:47:20] <petev> so the client.nml file probably needs to define the tool buffers too
[01:47:26] <petev> proabably hasn't been tested
[01:53:51] <SWPadnos> I don't know that we're using that recent a version of NML
[01:54:06] <SWPadnos> I see that there are updates to the doc from Feb. 2005
[01:58:05] <jmkasunich> there, that chore finished
[01:58:39] <jmkasunich> anybody want to bet on how long it takes SF to fix it
[01:58:52] <jmkasunich> I bet at least a month
[01:58:55] <SWPadnos> I'm betting on 2011 - June
[01:59:24] <SWPadnos> or whenever IPV6 beomes mandatory, whichever is sooner
[02:01:14] <jmkasunich> http://pastebin.ca/496116
[02:01:42] <petev> I think it would be ideal if the tool could automatically extract info from the VHDL to error check the HW config and HAL view config, but I think that's asking a lot of the tool
[02:01:55] <jmkasunich> yep
[02:01:56] <petev> I think the burden should be put on the type 4 user
[02:02:14] <petev> he will proabably have to write some type of description file that is easier for the tool to parse
[02:02:22] <jmkasunich> I was thinking the other way around - start with a much simpler format, and generate the vhdl from it
[02:02:45] <petev> but that make it hard to handle the case for new VHDL modules
[02:02:51] <jmkasunich> "other way around" refers to "extracting the info from the VHDL"
[02:03:14] <petev> ideally the info is only in one place
[02:03:23] <jmkasunich> as you say, a new vhdl module means some work for a type 4 user
[02:03:44] <petev> but in lieu of that, the type 4 user should create the module spec files
[02:03:56] <SWPadnos> I'mn not sure it would be possible to have a tool that could extract config info from arbitrary new VHDL modules
[02:04:08] <jmkasunich> he has to write the vhdl, write the driver code (a source file that is linked to the driver, and an entry in a switch in the main driver file), and something that helps the tool understand the new module
[02:04:10] <petev> it would be difficult at best
[02:04:22] <petev> right
[02:04:33] <petev> the thing that helps the tool understand is what I was talking about
[02:04:40] <petev> it's some type of module spec
[02:04:48] <jmkasunich> its the type 4 guys job to verify the "tool hints" for his module with the VHDL and C for that module
[02:04:50] <petev> that gives the HW and HAL config options
[02:04:58] <petev> yes
[02:05:20] <SWPadnos> now, if there's a very standard interface to a port pin and to several data types that are accessible to software, then the inner workings of the block are immaterial, since you have the interface to it in VHDL
[02:05:37] <SWPadnos> (the HAL driver interface on one side, and port pins on the other)
[02:05:39] <jmkasunich> I really don't want to be parsing VHDL
[02:05:53] <SWPadnos> only the top level, I think
[02:05:53] <petev> I know jmk will cringe at this, but ADI has a DSP dev environment called Visual Audio
[02:05:57] <jmkasunich> the number of blocks is small, and the class 4 guys work only needs to be one once
[02:06:02] <petev> it has similar requirements
[02:06:12] <petev> components are made with pins for connection
[02:06:21] <SWPadnos> that's true - once you write the spec, the only work is making sure it stays in sync with changes to the VHDL ;)
[02:06:22] <jmkasunich> SWPadnos: I'd much rather autogenerate the top level VHDL than parse it
[02:06:33] <petev> they use an XML description that goes with each module implementation
[02:06:33] <SWPadnos> sure - that's the other way to do it
[02:06:50] <SWPadnos> (take out the term XML until later in the conversation ... :)
[02:06:57] <petev> I can post some examples of the XML, and maybe we can get ideas from it
[02:06:58] <jmkasunich> the type 4 guy writes the low-level VHDL and the C, and adds knowledge of it to the tool
[02:07:07] <SWPadnos> "each module has a description file associated with it ... "
[02:07:14] <petev> right, so we need a format for the tool knowledge
[02:07:27] <petev> and that's what VA uses xml for
[02:07:29] <jmkasunich> then the tool reads a spec and writes the top level and the 1K of config data, based on the spec
[02:08:28] <petev> http://www.analog.com/processors/sharc/evaluationDevelopment/VisualAudioGraphicalDevSoftware.html
[02:08:39] <petev> take a look at this, and the documentation
[02:09:12] <petev> there are some online tutorials that might be worth the time too
[02:09:27] <jmkasunich> shudder
[02:09:29] <petev> I think it's very close to what we would want for HAL
[02:09:41] <SWPadnos> hmmm. the C driver code raises another questin - where does it go?
[02:09:45] <petev> it's a schematic like GUI environement
[02:10:08] <jmkasunich> pete: my goal is to get the 5i20 driver working, not to come up with a schematic tool for HAL
[02:10:11] <SWPadnos> so is this, but that doesn't mean we want it:
http://www.ni.com/labview/
[02:10:17] <jmkasunich> we all want that tool, but not at the moment
[02:10:28] <petev> I understand, I was suggesting we look at their XML format for ideas
[02:10:32] <SWPadnos> heh
[02:10:58] <petev> it may be able to be used almost as is if there isn't too much objection to XML ;-)
[02:11:00] <jmkasunich> SWPadnos: the C code goes in src/hal/drivers/mesa_5i2x
[02:11:05] <jmkasunich> right now there are three files in there
[02:11:24] <jmkasunich> a .h file, the "core" driver, and the stepgen specific C code
[02:12:10] <jmkasunich> the core driver reads the 1K ram and invokes module specific code to export the pins, etc for a stepgen (or whatever)
[02:12:23] <SWPadnos> ok. if I add a 3-phase PWM to the FPGA, I write the driver functions, put them in another file, modify the SubMakefile, and then fix up the core driver (somehow) to invoke my functions
[02:12:33] <jmkasunich> yeah
[02:12:42] <jmkasunich> the "somehow" is "add an entry to a switch"
[02:12:45] <SWPadnos> hmmm. lemme look at that part
[02:12:47] <jmkasunich> and a line to the .h
[02:13:39] <jmkasunich> http://cvs.linuxcnc.org/cvs/emc2/src/hal/drivers/mesa_5i2x/hal_5i2x.c?annotate=1.3
[02:13:43] <SWPadnos> ok - I'm thinking there should be something more like the kernel filesystem driver interface - you have a struct with some ID info and a list of functions for detect, init, diagnose, export, read, write ...
[02:13:56] <jmkasunich> line 461
[02:13:59] <SWPadnos> or maybe that was character devices - I don't recall
[02:14:15] <jmkasunich> there is only one function: export_foo()
[02:14:37] <SWPadnos> ok, and that exports the right functs, so read/write are taken care of
[02:14:42] <jmkasunich> yep
[02:14:58] <SWPadnos> there should also be "init_foo" (which is in export now), and "shutdown_foo"
[02:15:33] <SWPadnos> unless you have requirements that every module has a global enable input
[02:15:56] <jmkasunich> at the VHDL level, I plan an enable signal for every module
[02:16:04] <SWPadnos> I wish C were a little more like assembly here ;)
[02:16:04] <jmkasunich> and a global enable in the fpga, driven by a watchdog
[02:16:08] <SWPadnos> ok
[02:16:21] <SWPadnos> that could suffice for cleanup functions
[02:16:53] <SWPadnos> re: assembly. I'd love to be able to populate individual elements of an array from header files, similar to declaring data segments in asm files
[02:16:59] <jmkasunich> I feel better about doing in the hardware
[02:17:20] <SWPadnos> which would reduce the changes needed to the core files as functions are added
[02:17:49] <SWPadnos> yes, there should be a hardware watchdog, I'm not sure if a cleanup func would still be needed
[02:17:50] <jmkasunich> you mean to avoid the addition of the new case to the switch?
[02:18:02] <SWPadnos> that's easy - but you need a struct
[02:18:10] <jmkasunich> the cleanup thing is a SMOP
[02:18:23] <SWPadnos> I'd like to populate the struct easier, but it's not easier ;)
[02:18:30] <jmkasunich> export_foo() could add cleanup_foo to a linked list
[02:18:42] <SWPadnos> sure
[02:18:47] <jmkasunich> we're multiplexing conversations
[02:18:51] <jmkasunich> what struct do you refer to?
[02:19:01] <SWPadnos> export_foo() is really "initialize and export foo"
[02:19:16] <SWPadnos> the struct I'd probably use to get rid of the switch :)
[02:19:34] <jmkasunich> I guess I'm not seeing that
[02:19:56] <SWPadnos> you make a struct with the function code and export (and any other) function pointer in it
[02:20:18] <SWPadnos> the switch becomes a scan through an array of structs, and that code never changes
[02:20:26] <SWPadnos> you just add a new one for your module
[02:20:46] <SWPadnos> {MY_MODULE_ID, my_module_init, my_export_module ...}
[02:20:52] <jmkasunich> oh
[02:21:09] <jmkasunich> that is very much an implementation detail IMO
[02:21:12] <SWPadnos> sure
[02:21:20] <SWPadnos> that's why the smilies instead of frownies ;)
[02:21:41] <SWPadnos> but it's much more important when you may have multiple entry points, as I was thinking originally
[02:22:02] <jmkasunich> I'm pretty sure that a single entry point is adequate
[02:22:17] <SWPadnos> so you can have driver code that gets run for each module type, before anything is exported (init / detect code, for example)
[02:22:17] <jmkasunich> that point sets up anything else that is needed
[02:22:36] <SWPadnos> unless you want to do all the HW init before any of the exports
[02:22:37] <jmkasunich> exports the RT functions, and can set up a callback kind of thing for cleanup if we decide its needed
[02:23:16] <SWPadnos> in any case, it is an implementation detail, but I think it's more extensible to use a table-driven system there
[02:23:19] <jmkasunich> I don't see a need for that, but if so, its not a fundamental change
[02:23:27] <SWPadnos> nope
[02:24:01] <SWPadnos> is the config RAM very pressed for space yet?
[02:24:02] <jmkasunich> a couple more tabs for your browser
[02:24:03] <jmkasunich> http://cvs.linuxcnc.org/cvs/emc2/src/hal/drivers/mesa_5i2x/hal_5i2x.h?annotate=1.1
[02:24:10] <jmkasunich> http://cvs.linuxcnc.org/cvs/emc2/src/hal/drivers/mesa_5i2x/5i2x_stepgen.c?annotate=1.2
[02:24:27] <jmkasunich> those are the other two files in the driver directory, I think we're gonna be pointing at them
[02:24:34] <SWPadnos> heh
[02:24:39] <jmkasunich> (those URLs are annotated with line numbers, very handy)
[02:24:52] <SWPadnos> indeed. and that revision is in bold
[02:25:10] <jmkasunich> the most recent changes are bold, that file is ver 1.1
[02:25:17] <SWPadnos> I think with annotate only, there's no version hilighting (and it might syntax hilight)
[02:25:45] <SWPadnos> hmmm - no syntax hilighting there, but no bold either
[02:25:50] <jmkasunich> yeah
[02:25:52] <jmkasunich> anyway
[02:26:05] <jmkasunich> in the stepgen file:
[02:26:26] <jmkasunich> line 57 is the start of some stuff the the level 4 guy needs to match up with the VHDL
[02:26:34] <jmkasunich> line 97 is a stepgen struct
[02:26:41] <jmkasunich> it is never seen outside this file
[02:27:00] <jmkasunich> export_foo allocates one, exports some of its fields as pins and params, etc
[02:27:40] <jmkasunich> the only thing about a stepgen that is public is in the .h file, lines 58, 73, and 82
[02:27:41] <SWPadnos> that is a lot of pins/params
[02:27:53] <jmkasunich> stepgens are complex
[02:28:16] <jmkasunich> the old_ things aren't exported, they and many other fields are driver private data
[02:28:34] <SWPadnos> sure
[02:28:53] <jmkasunich> regardless, that stuff is all local to that file, which would be written by the same guy who writes the VHDL
[02:29:03] <jmkasunich> its his job to make sure the C and the VHDL play nice together
[02:29:31] <jmkasunich> lets switch over to the .h file
[02:29:53] <jmkasunich> the comments at lines 76-80 aren't strictly neccessary in that file, they could be in the stepgen file
[02:30:10] <jmkasunich> but they are as close as I have at the moment to "tool hints"
[02:30:29] <SWPadnos> hmmm. OT, but I may have figured out how to do table-driven type-safe pin/param exports
[02:30:57] <SWPadnos> though it has to do with nasty C macro-foo
[02:31:06] <SWPadnos> ok - I'll think about that later
[02:31:08] <jmkasunich> lets not go there right now
[02:31:10] <jmkasunich> ;-)
[02:31:24] <SWPadnos> lines 76-80 are some defines - are those what you're talking about?
[02:31:41] <jmkasunich> are you looking in the .h file?
[02:31:45] <SWPadnos> ah - duh
[02:31:45] <jmkasunich> hal_fi2x.h?
[02:32:23] <petev> the tool hints require too much knowledge of the module
[02:32:45] <jmkasunich> please clarify, starting with "which module"
[02:32:59] <petev> the VHDL module
[02:33:10] <petev> and the HAL driver
[02:33:56] <jmkasunich> the only knowledge in the stepgen tool hints are the I/O pins that the module is connected to, and the address that its decoded at
[02:34:02] <jmkasunich> how can you get much less than that?
[02:34:05] <petev> if the tool is going to work for yet un-created modules, the hints have to have all the info it needs
[02:34:16] <SWPadnos> do you get some resource / type usage output from any of the intermediate steps in the VHDL -> FPGA process?
[02:34:33] <jmkasunich> SWPadnos: you mean how many FFs, LUTs, etc?
[02:34:36] <petev> yes, but the tool needs to know that those fields are pin numbers, etc.
[02:34:55] <jmkasunich> damn, two conversations going on again
[02:34:56] <petev> so it would need built in knowledge of the module to use hints in the format shown
[02:35:08] <SWPadnos> no, like if you were to define a custom data type called a HAL_INT (or whatever), can you tell how many you used and where they are in the RAM?
[02:35:37] <jmkasunich> SWPadnos: if foo.vhd is a top level vhdl, make foo.bit does the whole build (place, route, etc), and make foo.usage does the first step and makes a usage report
[02:35:50] <SWPadnos> that's LUT/FF usage though, isn't it?
[02:35:54] <jmkasunich> yes
[02:36:10] <SWPadnos> ok - I'm not sure that would be useful
[02:36:14] <jmkasunich> I can't answer questions from two people when they're goin at 90 degrees
[02:36:20] <SWPadnos> heh
[02:36:41] <jmkasunich> petev: I'm not at all suggesting that lines 76-80 of the .h file are the input to the tool
[02:36:46] <SWPadnos> I'm thinking of the kind of output you get from an assembler/linker - lists of "variables" and their addresses
[02:36:49] <jmkasunich> I shouldn't have used the term tool hints for that
[02:36:57] <jmkasunich> those lines define the 1K format
[02:37:05] <jmkasunich> the tool would output that info, not read it
[02:37:24] <jmkasunich> SWPadnos: I have no idea where you are going with this
[02:37:29] <SWPadnos> or at least the VHDL equivalent - a map of which RAM spaces are used by this type or that type
[02:37:46] <jmkasunich> aaaaggggghhhh
[02:37:50] <SWPadnos> ok - I'm not sure either, and I should probably look at some output from the toolchain before confusing everyone
[02:38:00] <SWPadnos> (VHDL toolchain)
[02:38:04] <jmkasunich> when you say RAM space, there are so many things that could mean
[02:38:08] <SWPadnos> he
[02:38:10] <SWPadnos> h
[02:38:16] <SWPadnos> the 1k config RAM
[02:38:24] <SWPadnos> and also the PCI address space
[02:38:38] <SWPadnos> since those are the only things the HAL driver interacts with (AFAIK)
[02:38:46] <jmkasunich> at present (subject to change after this discussion) the 1K config ram is a stream of blocks like the one described at lines 76-80 of the .h
[02:38:56] <SWPadnos> understood
[02:38:58] <jmkasunich> the 1K ram is at the beginning of the 64K PCI space
[02:39:09] <jmkasunich> everything else is elsewhere in that space
[02:39:17] <jmkasunich> where depends on the decode logic in the top level VHDL file
[02:39:31] <jmkasunich> and is passed to the hal driver thru the 1K entries
[02:40:02] <jmkasunich> the output of the xilinx toolchain is totally opaque to us
[02:40:26] <jmkasunich> ( we can't twiddle or even read the bitstream and deduce anything usefull from it)
[02:40:33] <jmkasunich> we have the 1K block....
[02:41:33] <SWPadnos> I'm trying to thikn of how we can either automatically extract that data or at least check the definitions somewhat, without having to parse VHDL
[02:41:51] <petev> thats what the tool hint file is for
[02:42:00] <jmkasunich> theres no way in a million years I want to parse VHDL
[02:42:08] <SWPadnos> and I want to make that ideally superfluous, or at least somewhat verifiable
[02:42:26] <SWPadnos> I understand - that's why I'm wondering if any of the reports output by the VHDL chain can help us
[02:42:34] <jmkasunich> the C in export_foo needs to know how to interpret the block as defined in lines 76-80
[02:42:41] <SWPadnos> or the intermediate files, which probably have a much simpler syntax
[02:42:51] <jmkasunich> but instead of defining that block as comments in a .h, we want to define it in a tool
[02:43:05] <jmkasunich> and the tool would always generate a properly formatted and checked block
[02:43:27] <petev> I think we want the tool to ouput it, but the tool would read another tool hint file and then some user config file
[02:43:31] <SWPadnos> yes - I'm thinking at the level of checking the type 4 user's work
[02:43:31] <jmkasunich> I really don't understand what you are talking about when you bring the VHDL into the picture
[02:43:47] <jmkasunich> checking a type 4 user?
[02:43:49] <jmkasunich> why?
[02:44:06] <SWPadnos> so we can detect mismatches, or make their work easier
[02:44:09] <petev> he's the guru, let him test/debug just like any other programmer
[02:44:25] <petev> yeah, but then we'll be wriiting tools for years
[02:44:28] <jmkasunich> we're talking about literally a few dozen bits (not bytes, bits) of info, out of all the details that he needs to make sure the C and the VHDL play nice together
[02:44:40] <SWPadnos> eh - ok. we can move on then
[02:45:16] <SWPadnos> someone had made a comment about auto-generating either the top-level VHDL from some other file, or generating some specs for hte driver automatically
[02:45:29] <petev> so tool input is hint file (module spec) and user config, output is 1K FPGA segment
[02:45:39] <jmkasunich> specs for the driver are that block of stuff that goes in the 1K
[02:45:41] <SWPadnos> I was thinking of possible approaches that I think wouldn't be as hard as writing a VHDL interpreter ;)
[02:46:26] <jmkasunich> top level VHDL is something that says "gimme a foo module, decode it at address X, and connect its I/O to pins A, B and C"
[02:46:46] <jmkasunich> both of those things (the 1K stuff and the top vhdl) should be autogeneratable from the same input
[02:47:00] <jmkasunich> that would ensure a match, and be tons easier than parsing arbitrary vhdl
[02:47:23] <petev> if the tool hint stuff had the VHLD instantiation code in it, it wouldn't be that hard
[02:47:46] <jmkasunich> it could
[02:48:02] <petev> so lets talk about the different data the tool hint file needs
[02:48:22] <petev> lets call that file a module spec file
[02:48:53] <jmkasunich> module spec because it describes one particular thing, like a stepgen?
[02:49:08] <petev> so it needs VHDL instantiation info, HAL export info, and 1K FPGA config output info
[02:49:13] <petev> yes
[02:49:32] <jmkasunich> I question the "HAL export info" part of that
[02:49:51] <SWPadnos> hmmm
[02:49:51] <jmkasunich> but lets deal with higher level stuff first, just to make sure we're all on the same page
[02:49:57] <petev> so you want to take the export everything approach?
[02:50:12] <SWPadnos> actually, you can stick the driver code in that file, and autogenerate the header and/or C files for the block as well
[02:50:15] <jmkasunich> maybe its terminology, can we defer a minute?
[02:50:28] <SWPadnos> s/block/module/
[02:50:36] <jmkasunich> lets not go too far now ;-)
[02:50:39] <SWPadnos> heh
[02:50:53] <petev> so give us the terms you want to use for things
[02:51:33] <jmkasunich> the module author is responsible for three things: VHDL file(s) for the module, C file(s) for the driver (rt code, and export function), and a "module spec file"
[02:51:41] <petev> yes
[02:51:51] <jmkasunich> ok - so we agree on that much (terminology)
[02:51:57] <petev> yes
[02:52:19] <jmkasunich> cramming the C and/or vhdl into the spec seems weird to me, but even that is just an implementation detail
[02:52:32] <jmkasunich> lets assume they are three unique files for now
[02:52:43] <petev> I agree
[02:53:44] <jmkasunich> lets also assume that the author is responsible for making sure they agree - that the RT code works with the HW as defined by the VHDL, and that the export function can read the 1K stuff that the tool exports based on the spec, and that the toplevel invocations of the VHDL entity exported by the tool based on the spec also match the VHDL
[02:54:08] <jmkasunich> damn, thats a long sentence
[02:54:19] <jmkasunich> does it make sense?
[02:54:34] <SWPadnos> sure
[02:55:07] <jmkasunich> I want to pastebin one more thing
[02:55:59] <jmkasunich> http://pastebin.ca/496176
[02:56:12] <jmkasunich> thats a top level VHDL for 16 stepgens (and nothing else)
[02:56:33] <jmkasunich> I know a real VHDL dude would use generate loops instead of copy/paste, but I'm not a real VHDL dude yet
[02:56:48] <jmkasunich> and actually, if we do auto-generated code, this way might be better
[02:57:06] <jmkasunich> up thru 97 is boilerplate
[02:57:24] <jmkasunich> 99 thru 118 is decode logic
[02:57:33] <jmkasunich> 119 thru 132 is an instance
[02:58:02] <jmkasunich> the code in 119 thru 132 could easily be in a hint file, with $FOO, $BAR, etc for the few pins that don't have standard connections
[02:58:22] <jmkasunich> in this case, the stepgen_cs (addressing) and IOBits (I/O mapping)
[02:58:24] <SWPadnos> I think the decode logic is the kind of thing that will be difficult to auto-generate
[02:58:41] <SWPadnos> just a hunch though
[02:58:46] <jmkasunich> efficient decode logic might be hard to generate
[02:58:51] <SWPadnos> yes
[02:58:59] <SWPadnos> but inefficient yet orthogonal may not be so bad
[02:59:13] <jmkasunich> right
[02:59:15] <petev> what about canned decode of fixed sized blocks?
[02:59:23] <jmkasunich> see that "match16 entity"?
[02:59:27] <petev> then each module uses some number of decodes
[02:59:53] <SWPadnos> that probably qualifies as "inefficient yet orthogonal" ;)
[02:59:58] <jmkasunich> it compares bits "lobit" thru "hibit" of "addr" to "value", and sets matched when they match
[03:00:20] <jmkasunich> invocations of match16 to decode any block at any address would be easy to autogen
[03:00:45] <jmkasunich> decode16 is like the good old 74154
[03:00:56] <petev> thats a lot of duplicated decode logic that may be more than needed with the huge PCI address space
[03:01:08] <jmkasunich> there is also decode8 (74138) and decode4 (74139) and decode2 (for completeness)
[03:01:21] <jmkasunich> a cascade of match16 and decodeN can do pretty efficient decoding
[03:01:36] <petev> I think something more like a good old 74138 would be better
[03:01:41] <jmkasunich> sorry, now I'm the one diving into details
[03:02:03] <jmkasunich> petev: I just said decode8 is a 138
[03:02:10] <petev> yes
[03:02:30] <jmkasunich> and you said a 138 would be better
[03:02:34] <petev> so what is wrong with fixed size high level decodes?
[03:02:35] <jmkasunich> than a 138
[03:02:35] <jmkasunich> ?
[03:02:55] <jmkasunich> oh, you mean cascade 138's as needed?
[03:02:57] <dmwaters> {global notice} Good day all! It's that time again, I've got 4 major rotation servers to upgrade. They've been out of rotation for a while so shouldn't be too noisey, but will cause some major disturbence as this effects the tor servers to. I will give further notice in wallops, so /mode your_nick +w if you are interested. Thank you for your patience, and thank you for using freenode!
[03:02:57] <SWPadnos> there are two things to keep in mind here (while thinking about the details): 1) do we have enough address space? (I think yes, unless we get really overloaded pins on a 5i22 or something) 2) are we going to screw up PCI access times if we have widely separated addresses for the modules?
[03:02:59] <petev> I was refereing to decoding the high order address bits into equal size blocks
[03:03:03] <petev> for use by all modules
[03:03:32] <jmkasunich> well, if a stepgen needs 4 regsiters, and a "foo" needs 64 we might have issues
[03:03:46] <petev> why not just waste some address space?
[03:03:48] <SWPadnos> right, so you decide that a stepgen needs 10 blocks of 4 words (or whatever)
[03:03:56] <jmkasunich> if you can have a bunch of stepgens and only a few foos, you'll run out of address space if you give everybody 64
[03:04:05] <SWPadnos> consecutive addressing has several advantages, though that is a micro-optmiization
[03:04:07] <petev> say the top level decode is 16/32 or whatever makes the mose sense for most modules
[03:04:24] <jmkasunich> crap, we're diving down into details again
[03:04:27] <petev> then larger modules can use several top level blocks
[03:04:50] <petev> it's not so much a detail here, it's the decode architecture and how it relates to the tool
[03:04:54] <SWPadnos> I think we may need to get into some details to nail down a good format for some of this stuff
[03:05:17] <jmkasunich> can we stop talking about decode except to agree that "it is poissible to autogenerate decode logic"
[03:05:25] <petev> ok
[03:05:30] <SWPadnos> sure
[03:05:37] <jmkasunich> I agree that we need to discuss decode
[03:05:41] <jmkasunich> but not "how"
[03:05:53] <jmkasunich> what info is needed to tell the tool about a modules decode requirements?
[03:06:00] <jmkasunich> how many registers?
[03:06:02] <jmkasunich> anything else?
[03:06:11] <jmkasunich> (all registers are 32 bits wide)
[03:06:16] <petev> will each module do it's own sub-decode?
[03:06:38] <jmkasunich> yeah, each module has a select input
[03:06:49] <jmkasunich> see line 126 in that vhdl
[03:06:54] <petev> and takes some address lines?
[03:07:01] <jmkasunich> line 129
[03:07:03] <petev> ok
[03:07:22] <petev> so that is a bit enefficient in terms of fpga usage
[03:07:39] <SWPadnos> can we make some common "address spaces" available, that the top-level generator can use to combine things from multiple instances of a module type
[03:07:41] <jmkasunich> if the hint says "this module needs 8 registers, that tells the tool both how many address lines, and how big the block
[03:07:44] <petev> but we would have to discuss decode architecture details to get past this
[03:07:46] <SWPadnos> ie, bit addresses, word addresses ...
[03:07:48] <jmkasunich> petev: not really inefficient
[03:08:07] <SWPadnos> so a bunch of stepgens can have their enables all in one register, for example
[03:08:08] <petev> I think it is
[03:08:12] <jmkasunich> ultimately you need a single wire for every register
[03:08:16] <petev> you wouldn't use 7400 series parts like that
[03:08:28] <petev> you would share the minor decode with all modules
[03:08:40] <SWPadnos> right, and use chip selects for the high addresses
[03:08:45] <petev> right
[03:08:56] <jmkasunich> oh really?
[03:09:12] <petev> I sure would, how would u do it?
[03:09:16] <jmkasunich> using real hardware is NOT a good example, in fact it goes the other way
[03:09:49] <petev> well it may not be an issue at the moment, but at some point we will be stuffing more than what fits into that FPGA
[03:09:52] <jmkasunich> when you buy a MSI periphial chip (UART, 8254 counter, 8255, etc), it has its own local decode, a few address lines, and a chip select
[03:10:16] <jmkasunich> I'm treating a VHDL stepgen like an 8254
[03:10:16] <petev> yes, but you are looking outside the ASIC, not inside
[03:10:19] <jmkasunich> for better or worse
[03:10:35] <petev> do you think they don't have one decoder inside and use it for all registers and sub blocks?
[03:11:00] <jmkasunich> if you put 5 8254s on a board, each has its own CS, and each decodes its own subregisters
[03:11:08] <petev> you are treating the FPGA more like a PCB with mutiple ASICs
[03:11:10] <jmkasunich> lets not argue over this, its not relevant
[03:11:13] <petev> ok
[03:11:33] <jmkasunich> I grant you that shared decode is more efficient
[03:11:47] <petev> so how do you want to specify the base address?
[03:11:53] <jmkasunich> but we're building an inherently modular system, so the PCB with ASICs model helps there
[03:12:09] <jmkasunich> heh, back on topic, great
[03:12:22] <petev> that has to get into the VHDL and C code somehow. Presumably the C code reads it from the 1K config
[03:12:22] <jmkasunich> I don't think the module spec actually specifies the address
[03:12:28] <jmkasunich> it specifies the size
[03:12:35] <jmkasunich> and the tool figures out the address
[03:12:39] <petev> so the tool determines the address map?
[03:12:42] <jmkasunich> yes
[03:12:58] <petev> ok
[03:13:15] <jmkasunich> the tool could be simple and just append blocks, or it could be smart and put like blocks together, etc
[03:13:28] <petev> will each module type only be allowed to appear once in the config?
[03:13:27] <jmkasunich> it could use the fixed size blocks you were discussing, or not
[03:13:41] <jmkasunich> I dunno
[03:13:51] <jmkasunich> there certainly would be more than one entry of each type
[03:13:51] <petev> it would helpt he tool I think
[03:13:58] <petev> sure
[03:14:13] <petev> but then it would be easier to use generate and build a nice address map
[03:14:15] <jmkasunich> ok, you mean if there are 4 stepgens, you don't want encoders stuck in betwen them
[03:14:23] <SWPadnos> you need multiple instances of each type if you're allowed to specify pin connections
[03:14:32] <petev> but then on the other hand, it might be nice for the user to be able to have control of the address map
[03:14:35] <SWPadnos> it could be an array though
[03:14:58] <jmkasunich> we were talking about the module spec, not the user's input to the tool
[03:15:03] <petev> the user may want it both ways, maybe he wants to organize groups as axis, etc.
[03:15:06] <SWPadnos> yes - consider someone who wants to put each axis on a single 24-pin connector: encoder input, limit inputs, PWM outputs, enables ...
[03:15:13] <petev> or maybe all encoders together
[03:15:16] <SWPadnos> right
[03:15:31] <petev> so the user may want some control over the decode
[03:15:36] <SWPadnos> err - the module spec in the 1k RAM?
[03:15:42] <jmkasunich> nope
[03:15:53] <jmkasunich> heh, I thought we had agreed on what module spec means
[03:15:53] <petev> nope what?
[03:15:57] <jmkasunich> lemme scroll back
[03:16:01] <SWPadnos> the module spect he user writes so they (hopefully) get auto-generated VHL to-level files?
[03:16:05] <petev> yes, it's tool input
[03:16:05] <SWPadnos> argh
[03:16:12] <SWPadnos> please add in all appropriate letters there
[03:16:14] <petev> 1K is tool output
[03:16:38] <SWPadnos> man 0I guess my typoing hasn't improved today
[03:16:38] <jmkasunich> the module author is responsible for three things: VHDL file(s) for the module, C file(s) for the driver (rt code, and export function), and a "module spec file"
[03:17:15] <petev> right, so the tool will get fed multiple module specs as input
[03:17:30] <petev> and will generate a top level VHDL from that
[03:17:34] <jmkasunich> right - the module specs are written by the module author, and essentially become part of a library
[03:17:44] <jmkasunich> the real input to the tool is a user spec
[03:17:56] <jmkasunich> that says "gimme 3 of this module and 2 of that"
[03:18:11] <petev> the user spec could call out the modules and the tool could open them itself, but they are still input
[03:18:12] <jmkasunich> and the last few minutes I think we've been confusing the user spec with the module spec
[17:36:16] <alex_jon1> alex_jon1 is now known as alex_joni
[18:51:33] <skunkworks> does this sound ok?
[18:51:35] <skunkworks> http://pastebin.ca/497272
[18:52:53] <alex_joni> galil is not supported
[18:53:17] <alex_joni> galil is a card with some motion controller inside
[18:53:46] <skunkworks> right - sort of what I said
[19:23:32] <SWPadnos> ah - thanks for fixing the logger Alex
[19:23:39] <alex_joni> SWPadnos: no problem
[19:23:50] <SWPadnos> I wish my memory was better :)
[19:24:06] <alex_joni> yeah ;)
[19:27:52] <jmkasunich> hi guys
[19:28:14] <SWPadnos> hi
[19:28:20] <cradek> hi
[19:32:28] <alex_joni> hi
[19:33:10] <jmkasunich> so how's things?
[19:33:26] <alex_joni> * alex_joni is kinda busy :)
[19:33:50] <alex_joni> getting ready for next week :)
[19:33:56] <jmkasunich> wedding?
[19:34:41] <alex_joni> yup
[20:46:16] <skunkworks> SWPadnos: Jerry Jankura on the cad_cam_edm_dro was one of the developers on turbocnc.
[20:47:09] <SWPadnos> ah - interesting
[20:49:07] <skunkworks> http://tech.groups.yahoo.com/group/turbocnc/message/18276
[20:50:43] <SWPadnos> maybe someone should correct him on the threading thing ;)
[20:50:52] <skunkworks> I did
[20:51:20] <SWPadnos> ok, good :)
[20:52:11] <skunkworks> * skunkworks did actually purchase the source for turbocnc quite a few years ago
[21:01:33] <skunkworks> what was the max step rate ray was getting when he was experimenting? I can't seem to get to the mail archives.
[21:02:17] <SWPadnos> on the Jetway board?
[21:02:50] <skunkworks> No - printer port.
[21:03:23] <SWPadnos> I meant the mini-ITX board he has
[21:03:35] <skunkworks> ah - yes -
[21:03:57] <skunkworks> I think though he was getting the highest pulse rates with a pci printer board
[21:04:00] <SWPadnos> I'm not sure I've seen numbers from that. Alex had an athlon 1800 down to 7000 BASE_PERIOD or thereabouts
[21:04:12] <SWPadnos> ~70 KHz
[21:05:16] <skunkworks> what was the link to jeplers mail archive
[21:05:35] <SWPadnos> uhh - damfino. I have all that stuff locally
[21:05:41] <skunkworks> :)
[21:06:12] <SWPadnos> one sec - searching for p"pci parallel port" in my archive
[21:06:28] <alex_joni> http://news.gmane.org/gmane.linux.distributions.emc.user
[21:07:26] <SWPadnos> 12/13/06, title "EMC2 Stepper Report"
[21:07:32] <skunkworks> alex_joni: thanks :)
[21:07:33] <SWPadnos> 6:16 PM
[21:07:41] <SWPadnos> (here, anyway)
[21:08:04] <SWPadnos> and he had BASE_PERIOD down to 8000
[21:08:15] <alex_joni> ray?
[21:08:23] <SWPadnos> yep
[21:08:30] <SWPadnos> on the Jetway, I Believe
[21:08:34] <alex_joni> nice
[21:08:41] <SWPadnos> he said he got to 30 IPM but stopped because of leadscrew whipping
[21:08:44] <SWPadnos> 360
[21:09:15] <SWPadnos> "I could probably get to 400 but it would require a better setup than a pile of stuff on a desk."
[21:10:06] <SWPadnos> oh wait - that was an E-Machines Sempron 3300, not the Jetway
[21:10:06] <skunkworks> nice
[21:14:05] <skunkworks> alex_joni: what was your machine that did 7us?
[21:14:37] <alex_joni> athlon xp 1600+
[21:14:45] <alex_joni> msi mobo I think
[21:14:50] <SWPadnos> oh - my bad. I thought it was an 1800+
[21:15:03] <alex_joni> 1600+ actually running 1400MHz
[21:15:03] <skunkworks> that was onboard printer port?
[21:15:13] <alex_joni> yeah
[21:15:38] <alex_joni> but I tried a PCI parport too
[21:15:39] <alex_joni> same speed
[21:15:50] <SWPadnos> one day, when I retire this Windows PC, I'll see how good this Athlon XP 1800 is (using way old 133 MHz SDRAM, and the KT133 chipset)
[21:16:02] <alex_joni> mine is KT400 I think
[21:16:11] <alex_joni> using 400MHz DDRAM iirc
[21:16:17] <SWPadnos> I may try the LiveCD before then even, but I'm not sure I'll even get a display with the Parhelia card in here
[21:16:19] <alex_joni> but it's been 3 years since i got it.. or more
[21:16:26] <SWPadnos> heh - 6 for this one
[21:16:39] <alex_joni> maybe 4?
[21:16:43] <alex_joni> who knows..
[22:38:29] <cradek> jmkasunich: backlash comp works fine on the lathe
[22:38:58] <jmkasunich> cool
[22:39:39] <cradek> X works great with .06 - Z is a little sloppy with .15
[22:40:05] <jmkasunich> x is the most critical anyway
[22:40:16] <cradek> on X, looking at the dial indicator and not the pulley, jogging .01mm back and forth, it looks almost perfect
[22:41:37] <jmkasunich> what's 0.01mm in real people units?
[22:42:20] <cradek> jmkasunich, meet units(1), units(1) meet jmkasunich
[22:42:31] <cradek> .0003937
[22:42:43] <jmkasunich> I know how to convert
[22:42:47] <jmkasunich> I'm just too damned lazy
[22:43:00] <cradek> .06mm is about 2 mil
[22:43:35] <cradek> I know, I'm just being that way I am
[22:44:33] <jmkasunich> that makes two of us
[22:45:19] <cradek> do you want the old lathe driver board to play with parport servos?
[22:45:35] <cradek> I can even stick the quadrature divider chip back on it
[22:45:46] <jmkasunich> ask me at the workshop
[22:45:57] <jmkasunich> * jmkasunich is feeling harried at the moment
[22:46:07] <cradek> ok I'll bring it
[22:46:10] <cradek> harried why?
[22:46:18] <jmkasunich> 5i20 driver stuff
[22:46:33] <jmkasunich> and at this very moment I have a headache, that isn't helping
[22:46:48] <jmkasunich> I did enjoy my trip to HGR today
[22:46:49] <cradek> yuck
[22:47:00] <cradek> yeah I'm very jealous of your proximity to HGR
[22:47:10] <cradek> they have several mills I'd like to check out
[22:47:34] <jmkasunich> darn, I could have looked at them for you
[22:47:47] <cradek> I really have no clue how to get them here anyway.
[22:47:55] <cradek> I should call and ask them - they obviously would know how
[22:48:01] <jmkasunich> they are only open one saturday a month, and today was it
[22:48:15] <cradek> ah, must've been a weekday I was there before
[22:48:33] <SWPadnos> if it's relatively small, I can tow it for you :)
[22:48:33] <jmkasunich> getting a decent sized mill (manual bp or larger) to your place will cost several hundred bucks
[22:48:49] <cradek> sure, that's no problem
[22:48:50] <SWPadnos> like 2500 poundsor less
[22:48:57] <SWPadnos> pounds or
[22:49:10] <jmkasunich> you posted a link to a horribly rusted mill the other day
[22:49:13] <cradek> my reading says they're more like 3000-4000 lb
[22:49:19] <jmkasunich> I saw it - it had a sold tag!
[22:49:19] <cradek> yeah, that was a joke
[22:49:23] <cradek> hahaha
[22:49:24] <cradek> wtf
[22:49:40] <SWPadnos> well, I can do 3000-4000 pounds, but it's a little harder
[22:49:40] <jmkasunich> the marked price was 499, I bet it sold for half that
[22:49:59] <jmkasunich> surprisingly the X crank turned smoothly and the axis moved OK
[22:50:07] <SWPadnos> hmmm. I wonder if I can get a road-worthy trailer for not too much money there
[22:50:07] <cradek> SWPadnos: oh I didn't read what you typed
[22:50:31] <jmkasunich> "there?"
[22:50:41] <cradek> SWPadnos: what exactly are you offering? I don't follow
[22:50:42] <SWPadnos> HGR or "not Vermont"
[22:50:55] <jmkasunich> I've never seen vehicles or trailers at HGR
[22:51:03] <jmkasunich> at least not things you'd drive/tow on the roadf
[22:51:13] <jmkasunich> forklifts and in-the-factory vehicles yes
[22:51:17] <SWPadnos> heh - with a suitable trailer (which I think I want to buy), I can tow a relatievly large piece of machinery
[22:51:43] <SWPadnos> I now have a 6500 pound tow capacity
[22:51:45] <SWPadnos> yay!
[22:51:54] <cradek> I was assuming it would get to lincoln on truck or train - the last couple miles will be the real problem
[22:52:07] <jmkasunich> truck would come to your driveway
[22:52:08] <SWPadnos> heh -that's why I got the Jeep
[22:52:13] <jmkasunich> its the last 50 feet that is the provlem
[22:52:15] <jmkasunich> problem
[22:52:23] <SWPadnos> it's the last 50 feet or so that's the real - what he said ;)
[22:52:33] <cradek> jmkasunich: driveway? heh
[22:52:35] <SWPadnos> heh - and I almost did the same typo, even
[22:53:24] <cradek> wonder if I could get someone local with a forklift to come here
[22:53:47] <SWPadnos> you can often rent them at Rent-all type places
[22:53:49] <cradek> they sit flat on the ground - I don't even see how you'd get a fork under them
[22:54:03] <SWPadnos> generally a machine would be moved on a palette
[22:54:07] <cradek> I've got a substantial slope down (gravel/dirt) to the building too
[22:54:21] <cradek> so that would make it even more exciting
[22:54:23] <jmkasunich> the traditional way for fork a bport is under the ram
[22:54:26] <SWPadnos> so you'd need a hoist in the building or something
[22:54:38] <SWPadnos> yep - done that too :)
[22:54:46] <jmkasunich> is the building floor also gravel? or is that concrete?
[22:54:58] <SWPadnos> it's possible to move a BPT around with a tailhook tow truck as well
[22:55:02] <cradek> hard flat dirt
[22:55:15] <jmkasunich> and how substantial is the slope? scary to drive on, or just scary to maneuver a machine on?
[22:55:20] <jmkasunich> dirt sucks
[22:55:20] <cradek> I'd have to get wood or metal to set it on
[22:55:31] <jmkasunich> no dirt is hard
[22:55:32] <SWPadnos> but it's best if the hydraulics work - much harder when you can't lift the boom
[22:56:15] <cradek> the table saw is on 2' square concrete pavers, I could do that again, or something like it
[22:56:38] <cradek> I'm pretty clueless about this as you can see
[22:56:57] <SWPadnos> I don't think that's best for a full size milling machine
[22:57:06] <SWPadnos> then again, I shouldn't talk - mine's on wheels
[22:57:11] <jmkasunich> http://www.ahtrolley.org/photos/Mvc-084f.html
[22:57:19] <cradek> yeah it should probably be one solid piece of 'something'
[22:57:22] <jmkasunich> tilt bed truck
[22:57:31] <SWPadnos> heh - I almost bought one of those :)
[22:57:56] <SWPadnos> but then I realized that I can move things 20 or 30 times for the price of buying it
[22:58:13] <SWPadnos> (at $100-200 a pop)
[22:58:27] <jmkasunich> find someone local who has one, have the long-haul truck deliver to their shop (the "someone" should be someone with forklifts and such)... transfer to the tilt-bed and let them tilt and deposit it where you want it
[22:58:29] <cradek> jmkasunich: the slope is perfectly drivable
[23:00:20] <jmkasunich> or find a place that will rent you one of these:
http://www.tufindustries.com/images/redtilt14.jpg
[23:00:52] <cradek> is that stout enough?
[23:00:58] <jmkasunich> its made to haul cars
[23:01:00] <cradek> ray said something about u-haul car trailers
[23:01:09] <cradek> ok, that must be it
[23:01:24] <cradek> I guess if you centered the mill over the wheels it would be ok
[23:03:19] <cradek> 1700 miles round trip to HGR
[23:03:25] <jmkasunich> http://reveg-catalog.tamu.edu/images/13-Transport/10-Rollback%2028.jpg
[23:03:29] <SWPadnos> hmmm - they probably shouldn't have that tilted up on the trailer hitch
[23:03:36] <cradek> 10 mpg in the truck, $3.50/gal, ...
[23:03:44] <cradek> maybe I should have it shipped
[23:03:44] <jmkasunich> find someone who owns one of those, and he's probably already good at moving machines
[23:03:59] <jmkasunich> you definitely don't want to drive it all they way yourself
[23:04:47] <jmkasunich> have it shipped to your local freight terminal, then pick it up with a tilt-bed trailer (they'll load with a forklift), or have somebody with a tilt-bed truck pick it up
[23:05:04] <SWPadnos> hmmm - 850 miles one way is quite a haul (no pun intended)
[23:05:34] <jmkasunich> the rollback truck is definitely the easy way, the kind of folks who have those things know how to use them
[23:05:37] <SWPadnos> bummer - I wish they had a few of these:
http://www.hgrindustrialsurplus.com/search-products/product-detail.aspx?id=30-285-142
[23:05:50] <SWPadnos> those connectors look very familiar
[23:05:53] <jmkasunich> and as that pic shows, they can reach quite a way to place the machine
[23:06:03] <cradek> yeah that looks really useful
[23:06:30] <SWPadnos> the boom-type tow trucks are similarly useful, and they can even stick things inside doors
[23:06:37] <SWPadnos> (as done with a 2500-pound lathe ...)
[23:06:58] <cradek> can a regular palette jack move that kind of weight over a suitable surface?
[23:07:02] <jmkasunich> yeah
[23:07:18] <jmkasunich> our pallet jack at work is a mainstream one, nothing special
[23:07:23] <cradek> so after the hill it might not be too hard
[23:07:24] <jmkasunich> its rated either 4500 or 5000 lbs
[23:07:37] <jmkasunich> but you won't be able to move it on dirt
[23:07:43] <cradek> no of course not
[23:07:45] <jmkasunich> the wheels are small, and they'd dig in
[23:07:49] <cradek> "over a suitable surface"
[23:07:57] <jmkasunich> how to buy a mill:
[23:08:03] <jmkasunich> step 1: pour a concrete slab
[23:08:27] <cradek> hmm
[23:08:30] <SWPadnos> step 2: move closer to a shop
[23:08:39] <cradek> step 3: don't buy a mill
[23:08:43] <jmkasunich> lol
[23:09:03] <jmkasunich> so, what mill at HGR were you looking at?
[23:09:13] <jmkasunich> (got a URL bookmarked?)
[23:09:49] <jmkasunich> I'm quite pleased with the wire cutters I got for $2.99 today
[23:09:49] <cradek> http://www.hgrindustrialsurplus.com/search-products/product-detail.aspx?id=01-910-014
[23:10:00] <cradek> comes with servos and encoders I suspect
[23:10:22] <cradek> http://www.hgrindustrialsurplus.com/search-products/product-detail.aspx?id=06-211-004
[23:10:29] <cradek> this one I'd like to look at for fun, probably not to buy
[23:10:33] <jmkasunich> crank knee, servos form x and y
[23:10:47] <cradek> there are also several of the series 1 stepper machines
[23:10:52] <cradek> all about the same price
[23:11:16] <cradek> don't they all generally have a crank knee?
[23:11:21] <jmkasunich> dunno
[23:11:36] <jmkasunich> I haven't looked at CNC bports except in passing, because I know I don't have room for one
[23:11:58] <jmkasunich> its a real shame you are so far away
[23:12:01] <cradek> http://www.hgrindustrialsurplus.com/search-products/product-detail.aspx?id=30-319-008
[23:12:03] <jmkasunich> it would be fun just to go visit HGR
[23:12:11] <cradek> they have two of these - with tool changers
[23:12:17] <jmkasunich> yeah, sort of
[23:12:21] <jmkasunich> I did see those today
[23:12:25] <jmkasunich> they are beat up
[23:12:27] <cradek> I don't know how much heavier/larger they are
[23:12:32] <cradek> yeah I figured, considering the price
[23:12:47] <jmkasunich> the one I looked at appeared to be missing the turret part of the changer
[23:12:59] <jmkasunich> look at the sheet metal around the bottom
[23:13:04] <cradek> yeah
[23:13:12] <cradek> maybe lifted inappropriately?
[23:13:20] <jmkasunich> no maybe about it
[23:13:47] <jmkasunich> the folks at HGR do everything with forklifts, and they're level of skill and attention to the task varies
[23:13:51] <jmkasunich> their
[23:13:53] <jmkasunich> duh
[23:14:12] <cradek> can't tell from any of their photos whether it's "looks like hell" (fine with me) or "destroyed" (not fine)
[23:14:24] <jmkasunich> right
[23:14:37] <jmkasunich> there is no substitute for getting up close and personal with the machine
[23:14:45] <cradek> http://www.hgrindustrialsurplus.com/search-products/product-detail.aspx?id=06-211-004
[23:14:55] <cradek> "how much extra to leave the controller there?"
[23:15:03] <jmkasunich> heh
[23:15:18] <jmkasunich> they wouldn't care if you left it
[23:15:48] <jmkasunich> they have really big dumpsters where the "this has been around for a year and nobody bought it" stuff goes
[23:15:52] <cradek> do you guys know - would that first one have encoders or resolvers?
[23:16:15] <jmkasunich> no idea
[23:16:27] <jmkasunich> I've heard that bport used resolvers for some of their machine
[23:16:29] <jmkasunich> s
[23:16:49] <jmkasunich> but considering the existance of US digital, that in itself isn't a show-stopper
[23:16:59] <cradek> right
[23:17:08] <cradek> nothing's a show-stopper - it just adds trouble
[23:17:16] <SWPadnos> holy cow - is this a big bin of encoders?
http://www.hgrindustrialsurplus.com/search-products/product-detail.aspx?id=12-272-102
[23:17:25] <jmkasunich> I would consider encoders on any used machine to need replacing anyway
[23:17:43] <jmkasunich> they're delicate, and stuck on the ends of motors where they can get bashed
[23:17:45] <cradek> sure looks like
[23:17:56] <jmkasunich> yep
[23:18:15] <jmkasunich> they have a couple aisles that are full of bins of you-name-it small stuff
[23:18:26] <SWPadnos> sigh. maybe I should stop by on the way to Fest
[23:18:37] <jmkasunich> what day are you driving?
[23:18:41] <SWPadnos> that servo cable looks quite good for me
[23:18:44] <cradek> the place is really great
[23:18:46] <SWPadnos> I think the day after you
[23:18:52] <jmkasunich> oh, thats sunday
[23:18:53] <SWPadnos> whichever day that is
[23:18:54] <jmkasunich> they won't be open
[23:19:00] <jmkasunich> what day are you driving back?
[23:19:18] <jmkasunich> the next saturday sale is the last day of the workshop
[23:19:19] <SWPadnos> the day after you :)
[23:19:31] <jmkasunich> I'm driving out sat and back sun
[23:19:42] <SWPadnos> right - I think I'm leaving on Monday
[23:19:46] <cradek> looks like you'll have to go monday
[23:19:54] <jmkasunich> if you want the servo cables and won't be there on a weekday, I could pick them up
[23:20:06] <jmkasunich> I'm thinking about taking the friday before off to load the truck, etc
[23:20:08] <SWPadnos> well, I'd love to know if they have the right connector
[23:20:13] <SWPadnos> right.
[23:20:20] <SWPadnos> I could actually go out a day earlier
[23:20:37] <jmkasunich> I need to get my cell working before then anyway... if I go on the friday before, I can call you from there
[23:20:46] <SWPadnos> cool
[23:21:15] <SWPadnos> I think the connectors I need are those circular type, in the 24-7P or 24-7M configuration
[23:21:25] <SWPadnos> err - 24-7S
[23:21:31] <SWPadnos> or 24-7P
[23:21:44] <SWPadnos> (plug / socket, not male / female)
[23:21:59] <jmkasunich> I should have let you guys know I was going today
[23:22:12] <jmkasunich> I could have at least checked those cables
[23:22:13] <cradek> 20/20 hindsight
[23:22:16] <SWPadnos> heh
[23:22:24] <cradek> you didn't know we were interested in stuff there
[23:22:26] <SWPadnos> the retrospectograph is a very accurate machine
[23:22:51] <jmkasunich> I didn't know you were interested in stuff there that could be picked up by a single human being
[23:22:57] <SWPadnos> heh
[23:23:06] <SWPadnos> the GOVERNATOR!
[23:23:16] <cradek> is that $39.99 for the whole bin of encoders?
[23:23:21] <jmkasunich> probably each
[23:23:36] <SWPadnos> heh - I was wondering the same thing about a bin of servo cables
[23:23:40] <cradek> ok that makes more sense
[23:23:45] <jmkasunich> they sometimes do a lot price for a bin, but never that good
[23:23:45] <SWPadnos> ok - gotta go for a walk with the wife. bbl
[23:24:27] <cradek> jmkasunich: the edge-triggered "exceeded soft limit (bug?)" error works
[23:24:39] <jmkasunich> is that a good thing?
[23:24:47] <cradek> it's easy to get by turning off the motors and cranking them past the limit
[23:24:56] <jmkasunich> oh, ok
[23:25:09] <cradek> I can't decide whether it should say (bug?)
[23:25:31] <jmkasunich> feel free to change it
[23:25:44] <cradek> no, I really meant "can't decide"
[23:25:49] <cradek> I wasn't just being nice :-)
[23:25:52] <jmkasunich> I think when we were discussing it we said you should never be able to hit the limit uniess there is a bug
[23:26:00] <jmkasunich> you've demonstrated that there is a way
[23:26:06] <cradek> under control I think that's true
[23:27:46] <jmkasunich> I'm very pleased with my $2.99 wire cutters
[23:28:02] <cradek> are they special?
[23:28:16] <jmkasunich> from HGR, nice high quality small cutters
[23:28:43] <jmkasunich> a few burs on the edges, but I spend 20 mins with a little diamond file, and they will now cut hairs anywhere along the blades
[23:28:47] <cradek> sometimes the smallest commonest tools are the ones where you appreciate high quality the most
[23:29:23] <jmkasunich> I hate cutters that squish a wire-wrap sized wire without cleanly cutting it
[23:29:47] <cradek> those are called wire strippers
[23:30:14] <jmkasunich> did you see my other purchase at HGR?
[23:30:24] <cradek> yes, very nice
[23:31:45] <jmkasunich> that was one of those "will I really use this" things
[23:32:01] <jmkasunich> I saw it when I first got there... they were asking $50
[23:32:19] <jmkasunich> and I said "if its gone when I'm done looking around, so be it"
[23:32:34] <jmkasunich> went back 10 mins before closing, it was still there, offered $25 and they took it
[23:32:42] <cradek> nice
[23:33:20] <jmkasunich> btw, thats another reason why if you buy a machine you want to be there in person
[23:33:28] <jmkasunich> you can negotiate that way
[23:33:37] <cradek> yeah
[23:33:42] <cradek> too bad about the 1700 miles though
[23:33:45] <jmkasunich> yeah
[23:34:04] <jmkasunich> there's gotta be other similar places
[23:34:11] <cradek> the thing is, that's probably the closest place
[23:34:13] <jmkasunich> of course, they're probably 1700 miles the other way
[23:34:29] <cradek> 1700 miles the other way is desert
[23:34:29] <jmkasunich> what about the chicago area?
[23:34:45] <cradek> true, that's half as far
[23:36:05] <cradek> I suspect there's nothing else quite like HGR in the US
[23:36:51] <cradek> if not for jepler along, I'd be tempted to go there after fest, since I'd be halfway there
[23:37:01] <cradek> the drive back would suck though.
[23:37:19] <jmkasunich> I wonder if there are cheap airfairs CLE to lincoln
[23:37:31] <jmkasunich> catch a ride from galesburg to cle with me or swp, and fly home
[23:37:58] <cradek> interesting
[23:38:07] <jmkasunich> actually, the other way would make more sense
[23:38:31] <jmkasunich> fly out, then if you see something (small) that you want, toss it in the truck for the drive to galesburg and then home
[23:40:28] <cradek> I would probably be foolish to buy a mill before asking Roland for advice about nearer stuff
[23:40:39] <jmkasunich> yeah
[23:40:49] <jmkasunich> what about his mills? nothing suitable?
[23:41:17] <cradek> he was giving away one huge machining center, nothing else was a mill (on that list he sent)
[23:41:41] <jmkasunich> http://www.mckeanmachinery.com/inventory/detail.php3?TheKey=MT9557
[23:41:59] <jmkasunich> better:
http://www.mckeanmachinery.com/inventory/detail.php3?TheKey=BM8456
[23:42:08] <jmkasunich> we already know how to retrofit that one
[23:43:22] <cradek> nice, except I'd like to finish under that price, not start at it
[23:43:36] <cradek> (way under, preferably)
[23:43:38] <jmkasunich> shipping would suck too
[23:43:53] <jmkasunich> I was joking about both of those
[23:44:13] <jmkasunich> mckean is the other dealer in town tho
[23:46:13] <jmkasunich> lol
[23:46:14] <jmkasunich> http://www.mckeanmachinery.com/inventory/detail.php3?TheKey=CB507
[23:46:30] <jmkasunich> I dunno what the two big bays on the right are, but I was a key designer of the drive in the left bay
[23:46:37] <cradek> cool
[23:46:53] <cradek> "EXTEXTION INDUCTER"!
[23:49:06] <jmkasunich> bbl
