Back
[00:02:14] <jepler> the end of the last pass of the smp one looks different, but it looks like it is literally the last pass -- vel goes to 0 and stays there
[00:02:38] <jepler> (that's the only difference I spot, a more pronounced "V" in the velocity profile at the end)
[00:04:50] <cradek> it's the beginning of the sync that bothers me
[00:04:57] <cradek> notice how on the vanilla, they are all the same
[00:05:23] <jepler> maybe I'm confused about where the synchronized move begins
[00:06:07] <jepler> is the thing in major divs 7 and 8 a synchronized move?
[00:06:23] <jepler> and what's in 3 and 6 is returning to the starting point?
[00:07:52] <jepler> if so, that's the thing I thought was different too, but my understanding of what part was the synchronized move was wrong
[00:07:54] <cradek> in the cyan above the number 11 button is the downward point I think is wrong
[00:08:29] <cradek> yes 3,6 is returning, rapid unsynced
[00:08:55] <cradek> yeah the end of the last pass is an abort or the end of the program
[00:09:07] <cradek> beginning of the last pass is the odd one
[00:09:31] <cradek> if we had more here, I think we'd see 1/3 or so wrong, which is what it seemed like he has always had
[00:10:06] <SWPadnos> that's not exactly rapid
[00:10:15] <SWPadnos> err, yes it is
[00:10:22] <SWPadnos> * SWPadnos should line up the images better
[00:10:48] <cradek> looks like about 15/sec
[00:11:18] <SWPadnos> yeah - somehow I was associating the slow negative vel with the return movement
[00:11:25] <SWPadnos> rather than the fast positive
[00:11:27] <cradek> no, that's the synced move
[00:11:32] <SWPadnos> right
[00:12:02] <SWPadnos> and presumably the little bump near the end of the synced move is due to an angled exit?
[00:12:17] <cradek> yes it loses position a bit because of the corner
[00:12:37] <cradek> if you make the angled exit longer, you see it catch right back up (I did that in one of the ones I sent to the list)
[00:13:24] <cradek> it seems like it could be better, but it really doesn't matter much
[02:38:02] <jepler> I played with hm2 probing some more but I remain unenlightened
[02:38:07] <jepler> 'night all
[02:38:17] <cradek> darn, goodnight
[03:51:10] <cradek> wooo, what luxury it is to be able to use cutter comp on the mill, and have it be smart and predictable and actually work right
[13:53:15] <Dave911> Newb compile question.. I did a git clone to a local directory emc-dev as per the example in the online manual
[13:53:16] <Dave911> So now I have clone of the online repository on my PC. I do an apt-get remove to remove my existing CD install of Hardy Heron EMC2.
[13:53:18] <Dave911> I run the compile and end up with EMC2 compiled code in the emc-dev directory. This doesn't seem quite right. I can run the software - by changing the desktop shortcut to point to the
[13:53:19] <Dave911> new emc starting script location and it loads the profile that I configured before no problem. But what it I want to compile a different branch of the repository. If I recompile the way I am currently setup
[13:53:21] <Dave911> I will overwrite the files I just compiled. How can I set this put so I can multiple versions of EMC2 loaded at the same time - like a master, and a branch etc. I thought I could do a git pull from my local repository to another directory and then compile there but that didn't seem to work. Sorry for writing this book on the IRC!
[13:53:51] <Dave911> I asked this same question on the email forum - so ignore one of them! :-)
[13:55:21] <Dave911> Correction > How can I set this put >> How can I set this up....
[13:55:48] <cradek> compiling in the git clone is the usual way to work. if you want another branch in another directory, just get another clone
[13:56:02] <cradek> I think you are right that you can do that by cloning your own clone, but you could also just download another one.
[13:56:32] <SWPadnos> there's probably some clever way of making a "cheap" local copy, but I'm not clever enough to know it
[13:57:32] <SWPadnos> Dave911, to use multiple copies, you need to be sure to configure with --enable-run-in-place, and when you want to use one version or another, you need to source the scripts/emc-environment script from the correct directory
[14:00:18] <mozmck> Dave911, you can use the --depth option with git clone to get only recent history for a faster download or a "cheap" local copy.
[14:00:48] <Dave911> I don't follow you ..... right now I did a clone and then I set it to use the master and then I did a compile... I did not set a enable-run-in-place but I saw through the compile process that it automatically set that for me.. (surprise!) If I wanted to compile a branch wouldn't I just use Git to set to the branch and then compile? -- depth option - I need to look that up..
[14:01:09] <mozmck> man git-clone
[14:01:13] <Dave911> Git is a very interesting tool
[14:01:56] <SWPadnos> cradek:
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=150222679742
[14:02:02] <SWPadnos> note the comparison chart
[14:02:11] <mozmck> you can also use -l for a local copy, and -s for a shared copy
[14:02:26] <mozmck> see the examples at the bottom of the man page for git-clone
[14:03:01] <SWPadnos> the B model may also work for you, though the K is faster
[14:03:30] <cradek> thanks
[14:04:31] <Dave911> I think I read through most of the online Git book and I tried to do a pull off the local clone of the repository and that didn't work.. I thought it should have... perhaps I am making this too difficult...
[14:04:33] <Dave911> >>-1 for local copy and -s for shared copy ......... ok I think I have more to read! :-) To make this simple, is the suggestion to just do a clone of what you want to a unique directory and then do a run in place?? Simple is good..
[14:05:02] <cradek> yep
[14:05:04] <SWPadnos> run-in-place is required. how you get multiple versions of the source is up to you
[14:06:37] <Dave911> >>run-in-place is required Do you know what exactly is run-in-place is ?? I tried to find some definition of that but I must have missed it. I tried without it and it set it anyway...
[14:07:37] <mozmck> it means emc2 is not installed system wide, but can be run from the directory where it is compiled
[14:08:54] <SWPadnos> which is necessary if you want to be able to switch between different versions, unless you want to install them over each other every time you want to change
[14:10:01] <Dave911> OK, that is what I was thinking it was. So when I ran the live CD and installed it on my PC, was that a system wide install vs a local (run in place) installs ---- or are all EMC2 installs - local installs?
[14:10:11] <mozmck> SWPadnos: I guess you could have one version installed for normal use and the others run-in-place?
[14:10:16] <SWPadnos> sure
[14:10:50] <SWPadnos> Dave911, the CD installs the entire operating system, the realtime kernel, and a certain version of EMC2
[14:11:02] <mozmck> Dave911: that would be system wide. emc2 was installed in /usr/bin and other main directories
[14:11:27] <SWPadnos> that installed version is managed by the package manager, and can be updated only when a new release is made
[14:11:31] <SWPadnos> and it is systemwide
[14:11:53] <mozmck> with run-in-place nothing is outside of the directory tree where you compiled emc2 - eg. emc-dev or whatever you called it.
[14:12:10] <SWPadnos> if you want to run different versions of EMC2, you need to compile them, but you don't want to install them systemwide, since the files will overwrite the ones from the systemwide installation
[14:12:26] <SWPadnos> (dunno if that made sense - still digesting coffee :) )
[14:12:52] <mozmck> heh, time for another cup here! see you later.
[14:13:02] <SWPadnos> so to have "side-by-side" versions on your system, you need to compile them such that they can run from the place they're compiled, hence "run in place"
[14:13:12] <Dave911> Oh... so the big difference is whether or not the package manager manages the installs or not??
[14:13:21] <SWPadnos> (note that you can only run one instance of EMC2 at a time)
[14:13:29] <SWPadnos> yes, more or less
[14:14:37] <SWPadnos> nothing you compile will be managed by the package manager, but if you "make install" a locally compiled version, it will install files into the same places as the packaged version
[14:14:58] <SWPadnos> so they stomp on each other, and you'll still have only one version usable at a time
[14:15:57] <SWPadnos> but that gets confusing, because the package manager still thinks that version x.y.z is installed, but when you run EMC2, you may see version p.q.r running, since "make install" overwrites the actual executable files
[14:16:12] <SWPadnos> but doesn't mess with the package database
[14:18:26] <Dave911> OK... I get that ....
[14:18:28] <Dave911> Right now I am doing:
[14:18:30] <Dave911> make
[14:18:32] <Dave911> sudo make setuid
[14:18:33] <Dave911> So if I wanted to do a system install I would do: sudo make install ??
[14:19:07] <SWPadnos> if you configure without --enable-run-in-place, then you shouldn't be able to run the version you compiled
[14:19:17] <SWPadnos> unless you make install
[14:19:39] <SWPadnos> if you use --enable-run-in-place, then you must make setuid, then source scripts/emc-environment
[14:20:10] <SWPadnos> that source (or ".") statement must be run in every shell you wish to use the RIP (run-in-place) version
[14:25:15] <Dave911> I deliberately left out the --enable-run-in-place and the compile turned it back on by itself and I can run the "master" version... ??
[14:25:17] <Dave911> I didn't know about "make install"
[14:25:19] <Dave911> What I did last night was to do the run in place - since it turned it on anyway. It all compiled into the source directory - and I just modified the desktop launcher/shortcut to point to the new "emc" location and I left the tail end of the command the same (in the shortcut/launcher) so it loaded up the proper INI file for my config.
[14:25:22] <Dave911> Does this make sense??
[14:27:13] <SWPadnos> no
[14:31:22] <jepler> it *is* OK to run the emc command from a run-in-place install without doing the ". scripts/emc-environment" first. It is the only exception.
[14:31:41] <jepler> If you want to e.g., open up a terminal and run halscope from it, then you have to ". scripts/emc-environment"
[14:32:22] <SWPadnos> oh. is that a (relatively) new change?
[14:32:28] <Dave911> Sorry..... What I ended up with last night from what you guys have told me is a run-in-place install that is running out of the emc2-dev/src directory. The emc2-dev directory was the target location on my pc for the git clone.
[14:32:30] <Dave911> In order to make this work. I went to the shortcut that was on desktop already (from the live cd install and machine configure) and I went into the properties and I put a prefix in front of the command line so it would go to the \emc2-dev\src directory to find the emc script file and start to run emc2
[14:32:31] <Dave911> so the command line in the launcher looks something like \home\emc2-dev\src\emc \desktop\ \ \ \__.ini etc
[14:32:41] <jepler> SWPadnos: no, it's been that way for quite some time
[14:33:05] <SWPadnos> huh. I thought there were path issues for things like halcmd and modules
[14:33:12] <SWPadnos> but if it works now, great!
[14:33:20] <jepler> SWPadnos: if you're aware of problems, let me know about them
[14:33:39] <SWPadnos> ok. I thought it was a "feature" before :)
[14:33:59] <cradek> the only problem I've seen is CL saves its file in the cwd, not the config dir
[14:34:38] <skunkworks_> the only time I do the . scripts/emc.... is when I want to tinker with hal. Otherwise I don't bother for normal running.
[14:36:13] <jepler> incidentally, I was useing haltcl + tclreadline last night trying to figure out the hostmot2 encoder latch thing
[14:36:30] <Dave911> If I just keep using the shortcut on the desktop to get to my config files including the custom.hal file etc, I should still be ok to run the scope tools shouldn't I???
[14:36:57] <jepler> it is pretty nice -- I could define a tcl procedure to strobe a pin and another to read the encoder control register and parse each bit
[14:37:28] <jepler> s/useing/using/
[14:38:04] <cradek> neato
[14:38:11] <skunkworks_> Dave911: from the emc menus - should work (I think)
[14:38:28] <skunkworks_> jepler: still getting random data?
[14:38:53] <Dave911> skunkworks: OK, thanks
[14:39:07] <cradek> I'm sad my spare m5i20 got used in Jr...
[14:39:26] <jepler> skunkworks_: my test setup must be wrong -- I was getting no latches
[14:39:41] <jepler> http://pastebin.ca/1647825
[14:39:53] <skunkworks_> if you guys need a 5i20 to test - I have a spare that I don't see getting used for a while...
[14:39:59] <cradek> oh, a different wrong than we had before?
[14:41:14] <SWPadnos> don't the flags get reset every servo cycle?
[14:41:28] <SWPadnos> (assuming they're read in the servo thread)
[14:42:46] <cradek> skunkworks_: thanks, but jepler already has one and I'm not smart enough to work on the driver
[14:42:47] <Dave911> As usual - you guys are awesome!! - I really appreciate the help. I don't think I could have figured this out without your assistance...
[14:42:52] <jepler> SWPadnos: in my testing I was looking for two things: for LatchOnProbe to be cleared (what this test did primarily) but also for the (new) hal signal rawlatch to be updated with a nonzero value
[14:44:03] <SWPadnos> I haven't looked at the 5i20 code recently - do you know if reading the flags register automatically clears the flags?
[14:44:16] <jepler> it may be true that write is setting LatchOnProbe true every cycle (I think it's not; there's code to write the encoder control registers only when the desired value is different from the last written (read?) value) but it should still be getting a new rawlatch
[14:44:49] <cradek> SWPadnos: wow, the normal opto22 are 5ms? that's much worse than I thought
[14:44:54] <SWPadnos> heh
[14:44:56] <jepler> SWPadnos: no, as far as I can tell from the firmware source the act of reading the ccr doesn't change the ccr
[14:44:56] <SWPadnos> or 10
[14:45:57] <SWPadnos> ok. then again, even if it's not automatic, the index handling code would presumably run before the "raw read" code, so the flags would have been cleared by the time you see them
[14:46:10] <jepler> cradek: I did realize one thing that could cause repeated spurious probes, though-- switching probe polarity makes it look like there's an edge
[14:48:11] <cradek> I don't follow
[14:51:56] <jepler> cradek: as I interpret the vhdl, the way probe polarity is done is by inverting the input to the noise filter (probesrc). the output of the noise filter is used to detect a rising edge.
[14:52:29] <jepler> so suppose probe = '0' and probepol = '1' (active high) initially. The output of the noise filter will be '0' and no edge will be detected.
[14:53:01] <jepler> Now set probepol = '0'. The input to the noise filter will change from '0' to '1', and 3 or 15 cycles later the output from the noise filter will change to '1', giving a rising edge of the probe signal
[14:53:15] <SWPadnos> you effectively have two probe inputs which are XORed together. one is hardware, the other controlled by software
[14:53:29] <cradek> ok, I get it, thanks
[14:54:13] <jepler> I think that the way I wrote the driver we actually were testing on jr I wrote probepol='0' most of the time, and probepol='1' at the same time as I wrote latchonprobe='1'
[14:54:21] <jepler> it seems like that could cause spurious latches
[14:54:49] <cradek> and when you fixed that you get no latches at all?
[14:56:12] <jepler> one time I got the spurious "keep latching" behavior; the rest of the time I got no latches
[14:56:18] <jepler> hmm
[14:56:28] <jepler> [3319559.880984] hm2/hm2_5i20.0: IO Pin 071 (P4-47): Encoder #0, pin Probe (Input)
[14:56:44] <jepler> I wonder if this means it's the latch only for encoder 0
[14:57:20] <cradek> hmmm
[14:58:11] <jepler> .. looking at hostmot2.vhd I think maybe not
[14:58:30] <jepler> in the entity declaration of the quadrature counters, the pins that are different for each instance look like
[14:58:33] <jepler> quada => QuadA(i),
[14:58:38] <jepler> and the ones that are common look like
[14:58:43] <jepler> clk => clklow
[14:58:48] <jepler> and that's how probe looks:
[14:58:48] <jepler> probe => Probe,
[14:59:17] <jepler> I think there's no way in the idrom to specify "this pin corresponds to all instances"
[14:59:28] <jepler> -- Quadrature counter input signals
[14:59:30] <jepler> signal Probe : std_logic; -- only 1!
[16:00:10] <jepler> hi pcw_home
[16:00:20] <skunkworks_> it was only a matter of time!
[16:00:22] <pcw_home> Hi Jepler
[16:00:51] <jepler> any troubleshooting suggestions when I'm back at my system with the 5i20 ?
[16:00:59] <pcw_home> I was thinking of usng 0x40 as a "global pin" flag
[16:01:30] <pcw_home> the current driver would report that as some pin on encoder 64
[16:02:59] <jepler> I didn't even look at how many bits are available, but using the highest value would make sense if there are plenty of bits
[16:05:43] <pcw_home> I just poked at the registers, didn't see any trouble but I can do a more thorough test
[16:05:44] <pcw_home> when i get a chance I could change the edge detection so you could change ProbePol
[16:05:47] <pcw_home> dynamically without generating a latch signal
[16:05:47] <pcw_home> (I just copied the index logic that assumes index polarity is a static setup option)
[16:05:49] <pcw_home> 8 bits for each pin of a given module but bit 7 is already used as =outout
[16:06:08] <pcw_home> (output)
[16:24:20] <mozmck_work1> mozmck_work1 is now known as mozmck_work
[16:26:31] <jepler> hm, what raw register writes would I use to enable the encoder module if I load hm2 with encoders=0?
[16:26:40] <jepler> just so I know that all of the hal driver is staying out of my way
[16:34:17] <pcw_home> I dont think you need to do anything (encoder module is all inputs and defaults are reasonable)
[16:38:09] <jepler> ok
[16:43:38] <pcw_home> I can make a new bitfile with ability to dynamically change probe polarity if that would help
[16:43:39] <pcw_home> but it may be that the driver is messing with the probe bits
[16:44:02] <jepler> I think that ultimately that will be needed
[16:44:13] <jepler> but I can structure my testing now to avoid the problem
[16:45:37] <jepler> actually, I could probably structure the hostmot2 driver to avoid the problem
[16:46:19] <jepler> by making sure to write the polarity before the enable
[16:49:44] <pcw_home> Its a trivial change in the encoder
[16:49:46] <pcw_home> I would only change rev 3 counters (now compiled in only when a probe pin is found)
[16:49:47] <pcw_home> as some existing configs are very close to not fitting
[16:49:49] <pcw_home> I would probably change it for index as well
[16:51:31] <jepler> the other alternative we'd talked about is having separate bits for "on rising edge" and "on falling edge" (so we could turn on both), but the way I'm structuring emc that won't be needed.
[16:51:50] <jepler> the motion controller will have an output that tells you which edge (just one) is desired
[17:00:48] <pcw_home> Yes, I wish I'd done that at the beginning.
[17:00:49] <pcw_home> I kind of dont want the mechanism to be different for probe and index
[17:00:51] <pcw_home> but doing it for both would cause pain and suffering unless the driver
[17:00:52] <pcw_home> checked the encoder rev and DTRT
[17:12:36] <jepler> bbl
[17:32:39] <pcw_home> bye
[18:41:27] <CIA-48> EMC: 03cradek 07random_toolchange * r5fa491d570d9 10/src/emc/ (9 files in 5 dirs): Merge branch 'master' into random_toolchange
[19:00:12] <cradek> (this code already does what I want; how can I make it do enough of what everyone else wants that I can merge it adequately in good conscience?)
[19:08:24] <cradek> currently in nonrandom toolchanger machines, we have a column in the tool table that does nothing. if I continue to have a column that does nothing on those machines, all tool tables can have the same number of columns. (In a random machine, that extra column is the pocket number.)
[19:08:57] <cradek> is this the least bad of all possible worlds? it doesn't break any existing tool tables, but they still have extra crap in them.
[19:09:29] <robh_> how did you mark which tool is in the spindle ?
[19:10:48] <cradek> today on nonrandom machines, that information is not kept in the tool table.
[19:10:56] <SWPadnos> I think that leaving the crap in there is the best thing to do
[19:11:23] <cradek> restarting emc makes it forget what tool is in the spindle, which might be considered a feature, if you want T[that tool]M6 to cause a tool change operation subsequently
[19:11:37] <SWPadnos> there's no sense having multiple tool table (or anything else) formats if it's avoidable, unless we put in a method of determining the revision of the tool table (or whatever) format
[19:11:54] <cradek> I had "improved" this (to my eye) but the changes are universally reviled
[19:11:58] <SWPadnos> heh
[19:12:05] <SWPadnos> not universal - you like it
[19:12:09] <cradek> now I just want to merge it but not have people bother me
[19:12:24] <SWPadnos> use someone else's account
[19:12:26] <SWPadnos> :)
[19:12:55] <cradek> I've been meaning to introduce a new developer - he's not from around here - his name is yabzsucy
[19:13:34] <cradek> he's interested in merging my changes, and he doesn't seem to care what you guys think
[19:13:35] <SWPadnos> heh
[19:14:13] <cradek> but seriously, leave the extra crap in the file and maintain compatibility? and forget trying to add the remembered-tool-in-spindle feature?
[19:14:21] <robh_> i just thinking if u have a 20ATC u can have 21 tools in the machine so i wunderd how on turn on or other you knew which tool out of the 21 was in spindle at the time or ud never find tool 21 in the ATC as it would be in the spindle
[19:14:57] <SWPadnos> you can't necessarily have an extra tool in the machine
[19:14:58] <cradek> with random_toolchange you can have 21 tools in a 20ATC machine just fine
[19:15:08] <SWPadnos> there has to be an empty space to put the one in the spindle back into
[19:15:22] <cradek> that's nothing special - just a consequence of how it works
[19:15:23] <SWPadnos> (depending on the mechanics)
[19:15:26] <robh_> only on a unbrella, random has swing arm so u can keep pocket near spindle full
[19:15:28] <cradek> SWPadnos: no, because they always swap between spindle and a pocket
[19:15:42] <cradek> the spindle is just like another pocket
[19:16:18] <SWPadnos> true, I suppose this change is only necessary/desirable on machines that swap the tools
[19:16:47] <cradek> yes that has been done and working for months - now I want to make it sane on non-swapping machines too
[19:17:40] <cradek> on those, if you shut down without putting all the tools away, you're screwed, and I'm going to not change that
[19:18:22] <SWPadnos> you can still scribble on the FMS column in non-random tool files
[19:18:38] <cradek> to what end?
[19:18:40] <SWPadnos> so you can write "-1" or whatever to the FMS value for the tool in the spindle
[19:18:52] <SWPadnos> and when it's put back, write the pocket number again
[19:19:04] <cradek> as I understand it, it's a misfeature to remember what tool is in the spindle
[19:19:17] <SWPadnos> at tool table load, look at all the FMS numbers, and if exactly one is -1, set that as the one in the spindle
[19:19:27] <SWPadnos> sure, like everything, there's no guarantee that things haven't changed
[19:20:04] <cradek> seems like I/we can't seem to say how it SHOULD work so the only sane thing I can do is not change how it currently works for those machines
[19:20:13] <SWPadnos> also, there are potential HAL issues with the initial tool number
[19:20:26] <SWPadnos> yeah, that's probably the best thing
[19:20:36] <cradek> one thing I do want to keep is arbitrary tool number allowance
[19:20:55] <cradek> "can't have tool numbers over 54" is just stupid
[19:21:07] <SWPadnos> well, that depends
[19:21:22] <SWPadnos> the current code doesn't differnetiate between pockets and tool numbers, right?
[19:21:32] <cradek> wrong
[19:21:37] <SWPadnos> oh
[19:21:37] <cradek> well which current code?
[19:21:39] <cradek> sorry
[19:21:40] <SWPadnos> heh
[19:21:44] <SWPadnos> the current non-random code
[19:22:05] <SWPadnos> the tool number is the number output on the HAL pin when a tool prep is requested
[19:22:05] <cradek> yes on master it swirls them together
[19:22:09] <cradek> right
[19:22:33] <SWPadnos> so there may be assumptions about tool numbers in the HAL/CL setup for existing machines
[19:22:43] <SWPadnos> since they can't be above 54 now
[19:22:54] <cradek> yes today using master, the user has no choice but to assume pocket/tool are the same number
[19:23:18] <cradek> maybe I should also preserve that swirliness
[19:23:42] <SWPadnos> so there would have to be some HAL changes, even if it's just to connect a different HAL pin to the toolchange logic
[19:24:04] <cradek> in the random branch, you get two hal pins so you have pocket and tool# both
[19:24:07] <SWPadnos> since you need two pins to support both modes - tool number and pocket number
[19:24:09] <SWPadnos> rigth
[19:24:11] <SWPadnos> rright
[19:24:13] <SWPadnos> -r
[19:24:44] <cradek> even today, someone could use the random branch and ignore the pocket# everywhere
[19:25:07] <cradek> the lines would move around in the tool table - who cares
[19:25:12] <SWPadnos> unless they get a file with a tool number 759
[19:25:14] <cradek> they would get the spindle-remember feature
[19:25:26] <cradek> no, that WOULD work
[19:25:28] <SWPadnos> (assuming it's even practical to email tool files around ...)
[19:25:58] <SWPadnos> well, they'd need the toolchange code to be able to get to pocket 759
[19:25:59] <cradek> in the random branch you can have tool 9999999999 as long as you stick it in a pocket <54
[19:26:08] <cradek> no no no
[19:26:22] <cradek> 14:24 <cradek> even today, someone could use the random branch and ignore the pocket# everywhere
[19:26:26] <SWPadnos> ok, so they'd have to change to use the pocket # pin
[19:26:31] <SWPadnos> um
[19:26:47] <SWPadnos> are those incorrectly named then?
[19:26:54] <cradek> well it depends what their tool changer wants. if it has barcodes they might want the tool#
[19:26:59] <SWPadnos> sure
[19:27:13] <SWPadnos> I'm talking about existing machines, which by definition do not have tool numbers above 54
[19:27:41] <cradek> if they assume tool=pocket they could use the random branch and consider the tool hal pin the pocket# for their changer to use
[19:28:09] <SWPadnos> so the tool pin gets the pocket number?
[19:28:14] <SWPadnos> (sorry if I'm being dense here)
[19:28:17] <cradek> no
[19:28:40] <SWPadnos> is it an error now to specify a tool number > 54?
[19:28:43] <cradek> in the random branch, you have tool# and pocket# in the tool table. when you prep a tool you get both those numbers in hal.
[19:28:55] <cradek> if your tc is random, you want the pocket
[19:28:55] <SWPadnos> yes, OK
[19:29:06] <cradek> if your tc is nonrandom, you might use the tool
[19:31:22] <cradek> hm, nonrandom kind of sucks
[19:31:59] <cradek> there is no ability/need to prep
[19:32:03] <robh_> surly if its non random the tool# and pocket# will always match only the tool in use (in the spindle) will be marked as inspindle within the TBLK untill put back no?
[19:32:27] <cradek> what is TBLK?
[19:33:04] <robh_> tbl sorry too many letters
[19:33:05] <cradek> maybe in nonrandom, you just trust the carousel/umbrella to not have turned, and you cram the old tool in the nearest pocket
[19:34:15] <skunkworks_> * skunkworks_ has 60 pockets...
[19:34:40] <cradek> skunkworks_: you'll never get it running at this rate, so it doesn't matter
[19:34:47] <skunkworks_> ouch
[19:34:52] <skunkworks_> ;)
[19:34:55] <robh_> i say depends what u want there, for me the unbrella has a index switch so u know when it has indexed or not
[19:38:23] <cradek> skunkworks_: sorry... :-)
[19:38:38] <cradek> skunkworks_: are your motor drivers ready for it?
[19:39:08] <skunkworks_> all I can say is I have not blown one up yet...
[19:39:19] <skunkworks_> (and I only have one made atm)
[19:40:26] <skunkworks_> dad raised a section of roof in the polebulding to put a car lift in - so he has been busy with that. (and I have been just busy)
[19:40:28] <skunkworks_> sucks
[19:40:54] <skunkworks_> so there mister 'I can convert a machine in less than a month'
[19:41:00] <cradek> man that would be nice...
[19:41:19] <cradek> skunkworks_: it did go pretty fast, didn't it
[19:41:25] <skunkworks_> very impressive
[19:41:47] <cradek> for as many bad parts as I had... if it had been a running machine it would have been very fast.
[19:42:07] <skunkworks_> are you still runnig the original style servo amps?
[19:42:25] <cradek> I think the Y tach has a problem - sometimes it goes thunk thunk thunk when jogging - plotted it - exactly once per screw turn
[19:42:28] <skunkworks_> (to replace the bad ones?)
[19:42:35] <cradek> yes identical to the originals
[19:42:58] <skunkworks_> yeck - do you have any extras?
[19:43:18] <cradek> I have two dead-ish ones
[19:44:43] <skunkworks_> the 200 amp sevice gets hooked up next tuesday to the garage..
[19:45:30] <skunkworks_> That will be nice. I need to get a corner of it setup for a shop - need to get all my tools in one spot.
[19:51:03] <cradek> dangit I haven't made any progress
[19:51:13] <cradek> maybe coffee will help
[19:56:04] <skunkworks_> http://cgi.ebay.com/ADVANCED-MOTION-CONTROLS-SERVO-AMPLIFIER-100A25H_W0QQitemZ110392339038QQcmdZViewItemQQptZLH_DefaultDomain_0?hash=item19b3e56a5e
[19:56:11] <skunkworks_> too expensive
[19:56:49] <skunkworks_> 100a250v though
[19:57:10] <skunkworks_> peak
[19:57:48] <skunkworks_> 50a continous
[20:22:30] <cradek> did you see where it says "I don't expect to get this much" in the auction text?
[20:22:51] <skunkworks_> heh - no
[20:22:58] <skunkworks_> I should make him an offer...
[20:32:17] <alex_joni> cradek: literally?
[20:32:30] <cradek> close enough, if you read it right
[20:33:49] <jepler> > Feel free to make an offer and ill consider it.
[20:34:00] <jepler> an ill-considered offer?
[20:35:22] <SWPadnos> maybe he has swine flu
[20:35:40] <skunkworks_> heh