Back
[00:00:19] <PeterWalrus> testing will be a big advantage of auto-building, less likely for errors to creep in
[00:00:20] <PeterWalrus> I spent 20 minutes yesturday with matts config not working because somehow the
[00:00:22] <PeterWalrus> GUI dropped the UCF file, built fine, but of course random pinout...
[00:00:50] <jmkasunich> nice ;-(
[00:01:21] <jmkasunich> thats why I want things like the device and the bitfile to be embedded somewhere
[00:01:30] <jmkasunich> right now I stuck them in the .spec file
[00:01:48] <jmkasunich> if we wind up doing a .vhd per config, then maybe I'll use special comments in that file
[00:01:58] <jmkasunich> --- device 2s200pq208
[00:02:09] <jmkasunich> --- constraints 5i20.ucf
[00:09:20] <PeterWalrus> Yes. make sense
[00:09:21] <PeterWalrus> Have you figured out where the configuration startup options are specified?
[00:09:34] <jmkasunich> which options?
[00:09:45] <jmkasunich> that means, probably not
[00:13:20] <jmkasunich> do you mean this stuff:
[00:13:20] <jmkasunich> set -tmpdir ./tmp_syn
[00:13:20] <jmkasunich> set -xsthdpdir ./work_syn
[00:13:20] <jmkasunich> run
[00:13:20] <jmkasunich> -ifmt VHDL -ifn 5i20_SVST8_4.prj
[00:13:21] <jmkasunich> -top HM2_5i20_SVST8_4
[00:13:21] <PeterWalrus> The last few configuration clocks do selectable things:
[00:13:23] <jmkasunich> -ofmt NGC -ofn 5i20_SVST8_4.ngc
[00:13:24] <PeterWalrus> remove global reset
[00:13:25] <jmkasunich> -p xc2s200-5pq208
[00:13:25] <PeterWalrus> enable writes
[00:13:27] <PeterWalrus> set DONE
[00:13:28] <PeterWalrus> etc
[00:13:29] <PeterWalrus> 7I43 requires that setting DONE be the very last thing
[00:13:31] <PeterWalrus> as it has to switch from the CPLD handling the EPP handshake during configuration
[00:13:33] <PeterWalrus> to the FPGA handling EPP seamlessly
[00:14:19] <jmkasunich> no, I haven't done any of that
[00:14:25] <jmkasunich> (didn't know it was needed)
[00:15:17] <PeterWalrus> Default config options set DONE before the FPGA is working
[00:15:19] <PeterWalrus> so will not work for the 7I43
[00:15:20] <PeterWalrus> This is not an issue on any other card
[00:15:49] <jmkasunich> do you know which tool gets that info? bitgen? or is it used earlier, like synthesis or mapping?
[00:16:41] <PeterWalrus> I would guess that its bitgen
[00:17:05] <jmkasunich> I generate all the command lines in the python program - so I can do just about anything, as long as I know what info to use
[00:17:25] <jmkasunich> that info can be either in a .spec file, or a .board file (with my existing system)
[00:17:32] <jmkasunich> of course I'd put it in the board file
[00:17:49] <jmkasunich> if we dispense with those so the GUI can build, then I'd probably put it in comments
[00:18:02] <PeterWalrus> Did you look at the log files I sent for bitgen options? may be there. I can look here as well
[00:19:19] <jmkasunich> that logfile is for a 5i20, so it might not be in there
[00:19:36] <jmkasunich> the bitgen line: bitgen -ise "C:/ISE9/5i22/hostmot2/hostmot2.ise" -intstyle ise -f I20HostMot2.ut I20HostMot2.ncd
[00:19:57] <jmkasunich> I dunno what that .ise file is - probably some GUI thang
[00:20:44] <jmkasunich> what is "trce" ?
[00:21:10] <PeterWalrus> OK its in the .UT file
[00:21:14] <jmkasunich> the log does xst, ngdbuild, map, par, trce, and bitgen
[00:21:28] <jmkasunich> my system does xst, ngdbuild, map, par, and bitgen
[00:23:40] <PeterWalrus> the bitgen command line points to a GUI created file: i43hostmot2.ut (just a simple text file)
[00:23:41] <PeterWalrus> bitgen get its options from this file so it must be in the bitgen docs
[00:24:34] <jmkasunich> yeah
[00:25:13] <jmkasunich> just like in other places, the problem isn't going to be how to specify the options in the cmd line build system - that will be easy with some manual reading
[00:25:24] <jmkasunich> the problem will be making sure that the gui and the cmd line version do it the same
[00:26:40] <PeterWalrus> -w
[00:26:42] <PeterWalrus> -g DebugBitstream:No
[00:26:43] <PeterWalrus> -g Binary:no
[00:26:45] <PeterWalrus> -g CRC:Enable
[00:26:46] <PeterWalrus> -g ConfigRate:6
[00:26:48] <PeterWalrus> -g CclkPin:PullUp
[00:26:49] <PeterWalrus> -g M0Pin:PullUp
[00:26:51] <PeterWalrus> -g M1Pin:PullUp
[00:26:53] <PeterWalrus> -g M2Pin:PullUp
[00:26:55] <PeterWalrus> -g ProgPin:PullUp
[00:26:57] <PeterWalrus> -g DonePin:PullUp
[00:26:58] <PeterWalrus> -g TckPin:PullUp
[00:27:00] <PeterWalrus> -g TdiPin:PullUp
[00:27:01] <PeterWalrus> -g TdoPin:PullUp
[00:27:03] <PeterWalrus> -g TmsPin:PullUp
[00:27:04] <PeterWalrus> -g UnusedPin:PullDown
[00:27:06] <PeterWalrus> -g UserID:0xFFFFFFFF
[00:27:07] <PeterWalrus> -g DCMShutdown:Disable
[00:27:09] <PeterWalrus> -g DCIUpdateMode:AsRequired
[00:27:10] <PeterWalrus> -g StartUpClk:CClk
[00:27:12] <PeterWalrus> -g DONE_cycle:6
[00:27:14] <PeterWalrus> -g GTS_cycle:5
[00:27:15] <PeterWalrus> -g GWE_cycle:4
[00:27:17] <PeterWalrus> -g LCK_cycle:NoWait
[00:27:19] <PeterWalrus> -g Match_cycle:Auto
[00:27:21] <PeterWalrus> -g Security:None
[00:27:23] <PeterWalrus> -g DonePipe:No
[00:27:25] <PeterWalrus> -g DriveDone:No
[00:27:30] <jmkasunich> lots
[00:27:52] <PeterWalrus> Most probably dont-care
[00:29:41] <jmkasunich> it wouldn't be a big deal to send that list to bitgen
[00:30:03] <jmkasunich> what will be a big deal is when you find out that one needs changed, change it in the GUI, and that change doesn't make it into our CVS
[00:30:16] <jmkasunich> (have I mentioned lately how much I hate GUIs ;-)
[00:30:55] <PeterWalrus> I should probably send you the .ut files for each top level (they may be the same)
[00:31:42] <jmkasunich> at the moment I'm a bit overwhelmed (I have some parts to make, and I feel like trying to do any more on the build system at this point is trying to hit a moving target)
[00:32:21] <PeterWalrus> I'm beginning to with these revisions, first with 7I43 EPP timing and then the stepgen
[00:33:47] <jmkasunich> if I may ask, what percentage of any-io sales have anything to do with EMC?
[00:34:00] <PeterWalrus> Doinf special file sis no big deal for me, whats bad are revisions that effect a lot of firmware :-(
[00:34:03] <jmkasunich> you support us remarkably well, for what seems to me to be a niche marked
[00:34:38] <jmkasunich> market
[00:34:41] <jmkasunich> I wish I could typoe
[00:34:48] <jmkasunich> :-/
[00:35:25] <PeterWalrus> Its small (but we're small) maybe 3% but more fun than most of the other business we do
[00:35:27] <PeterWalrus>
[00:35:50] <jmkasunich> I figured it was
[00:36:26] <jmkasunich> thats why I want to make sure that what I/we do is helpful to you - I can't exoect you to keep in sync with us, its gotta be the other way around
[00:36:40] <PeterWalrus> Also we have other non EMC customers using HostMot2
[00:36:55] <jmkasunich> yeah
[00:37:18] <jmkasunich> on that note - when we do finish splitting IDParms.vhd, and have 20-some individual files
[00:37:33] <jmkasunich> we should probalby not put every single one in emc cvs
[00:37:36] <PeterWalrus> I think keeping in sync will be pretty easy
[00:37:59] <PeterWalrus> Right thats one good reason to split them
[00:37:59] <jmkasunich> I know your customer pinouts aren't a big secret, but I suspect at least some of those customers don't expect that data to be in a public server
[00:43:18] <PeterWalrus> That reminds me, I dont know if Sebastian uploaded the USB interface source code
[00:43:20] <PeterWalrus> I included the USB HostMot2 stuff because its part of HostMot2. Dont want PaulC
[00:43:22] <PeterWalrus> complaining about binaries with no source.
[00:44:07] <jmkasunich> you can see what is in cvs here:
http://cvs.linuxcnc.org/cvs/emc2/
[00:44:42] <jmkasunich> firmware dirs:
http://cvs.linuxcnc.org/cvs/emc2/src/hal/drivers/mesa-hostmot2/firmware/
[00:44:50] <jmkasunich> source files are in src/
[00:45:30] <PeterWalrus> No ASM source
[00:47:50] <jepler> jmkasunich: yeah, we only need the specs for the bit files we inted to ship
[00:54:02] <PeterWalrus> Currently the ROM is for our LBP protocol over USB but were thinking of doing a ModBus ROM as well
[00:54:04] <PeterWalrus> than might work as-is with EMC
[00:56:08] <jepler> modbus interface to .. hostmot2? usb access to hostmot2 isn't very useful for emc, since usb accesses aren't realtime
[00:57:45] <PeterWalrus> They could be use for slow I/O or user interface (handwheels etc)
[00:58:02] <PeterWalrus> (used)
[00:58:08] <jepler> that's true
[00:59:44] <jepler> I've been thinking it would be neat to put ladder in the AnyIO card, then it can do a lot of integrator-determined stuff
[01:00:02] <jmkasunich> actually put the evaluation of the ladder logic in there?
[01:00:07] <jepler> right
[01:00:11] <PeterWalrus> That A USB application :-)
[01:00:28] <jepler> compile ladder to bytecode and execute it on the fpga
[01:00:33] <jepler> and yeah that'd work nicely over usb
[01:00:50] <jmkasunich> I've never met a ladder program that needs that kind of performance
[01:01:36] <PeterWalrus> If its not too much code, theres a really nice and small 32 bit processor with GCC toolchain call ZPU available
[01:01:40] <jepler> no, it's not about performance -- first, it would be as an exercise for my own enrichment. second, it'd be robust against certain kinds of failures in the PC.
[01:01:56] <jmkasunich> understood
[01:02:25] <jmkasunich> but a good ladder compiler could reduce rungs to a few instructions each, even for an 8-bit cpu
[01:02:48] <jmkasunich> so any old microcontroller can execute many rungs many times/second
[01:03:32] <jepler> but unlike any old microcontroller, it's not plug-compatible with a wide range of useful I/O boards with appropriate protection like the AnyIO boards are
[01:03:53] <jmkasunich> true
[01:04:48] <jmkasunich> I still think of an FPGA as a massivly parallel chunk of hardware, for stuff that would suffer if serialised for a normal processor
[01:05:38] <jmkasunich> ladder is drawn as if it were parallel, but it serialises so easily, and the performance requirements are so low,that it seems a waste
[01:06:14] <jepler> but you can put that ladder next to the parallel stuff like encoder reading in the same package
[01:07:07] <jepler> (there are approximately zero microcontrollers I know of that include two proper encoder readers; there are a few dsPICs that have one, apparently)
[01:07:42] <jmkasunich> sure, if there are other things that want hw support, it makes sense
[01:08:22] <jmkasunich> but the USB looks less attractive then, unless you are doing some standalone thing, like an electronic cam-switch squencer or something
[01:12:40] <jepler> and then the only reason you'd need the PC is to send the fpga bitfile up the wire
[01:13:41] <jmkasunich> right
[01:14:18] <jepler> well I guess PeterWalrus (hmm, I thought the walrus was Paul) to make a board with a platform flash on it
[01:14:44] <jmkasunich> platform flash?
[01:14:50] <PeterWalrus> 7I43 has flash
[01:19:00] <jepler> oh really, for fpga configuration?
[01:19:20] <jepler> jmkasunich: I thought that was the name of the special flash rom for configuring xilinx fpgas
[01:19:59] <jmkasunich> I hadn't heard that term used
[01:20:16] <PeterWalrus> Yes. Theres a jumper that selects host config or auto config
[01:20:17] <jepler> "also has the capability of local configuration storage in an on card EEPROM" oh look it's right there
[01:20:21] <jmkasunich> some use serial memory, some parallel, some can do multiple config methods
[01:20:43] <jmkasunich> my only real experience with config hardware dates from the Xilinx 3000 series, early 90s
[01:20:51] <jepler> I dunno what's special about it, but
http://www.xilinx.com/products/config_mem/pf.htm
[01:21:03] <jepler> "The competitively priced Xilinx Platform Flash configuration memory devices reduce the amount of board space required for configuration."
[01:21:14] <PeterWalrus> Newer (spartan 3E and >) can config from SPI EEPROMS without any additional hardware
[01:21:16] <jmkasunich> they could do serial, master parallel (fpga drives address bus of rom), slave parallel (cpu stuffs data to fpga), and a few other flavord
[01:22:02] <jmkasunich> zoiks, times sure have changed
[01:22:17] <jmkasunich> config data speed 800Mbs, density 128Mb
[01:28:04] <jepler> 160ms to program? an eternity!
[01:30:48] <PeterWalrus> Still making bitfiles... Screed up the 7I43 ones so need to do them again :=(
[01:31:17] <jmkasunich> the ones I worked on would program in less than 160mS, with a serial bitclock of a Mhz (or maybe less, too long to remember)
[01:31:30] <PeterWalrus> Screed? Screwed
[01:31:55] <PeterWalrus> scrod?
[02:00:32] <PeterWalrus> Sebastian, just sent 5I20, 4I65, 7I43 bitfiles
[02:00:34] <PeterWalrus> will send others tomorrow
[02:10:32] <jepler> hah I'd forgotten about this oldie but goodie:
http://stuffucanuse.com/fake_moon_landings/moon_landings.htm
[02:24:36] <PeterWalrus> bye
[03:17:26] <CIA-42> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/firmware/7i43/ (5 files): new 7i43 bitfiles from Peter, with fixed stepgens
[03:20:40] <CIA-42> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/firmware/5i20/ (SVST8_4.BIT SVST8_4IM2.BIT): new 5i20 bitfiles from Peter, with fixed stepgens
[03:26:45] <CIA-42> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/firmware/4i65/ (SVST8_4IM2.BIT SVST8_4.BIT): new 4i65 bitfiles from Peter, with fixed stepgens
[14:42:50] <micges> hello all
[14:43:45] <micges> I'm trying to add tool_changer to emc and have problem
[14:58:46] <micges> my tools are placed linear and I have eight different TOOL_CHANGE_POSITION
[15:01:46] <micges> bbl
[15:19:11] <SWPLinux> hey jmkasunich, it looks like I may not make it in time to load today
[15:24:43] <skunkworks> we just got dumped on - 5 or more inches
[15:25:11] <cradek> we had ice rain with thunder and lightning! it was pretty cool.
[15:25:22] <skunkworks> yikes
[15:28:31] <SWPLinux> nice
[15:28:59] <SWPLinux> it's kind of funny - there was no snow from BUrlington to Buffalo (except a dusting for about 10 minutes in one spot)
[15:29:12] <SWPLinux> now I wake up, and the snow is blowing sideways
[15:29:29] <cradek> uh-oh
[15:29:37] <SWPLinux> the weather forecast says "currently heavy snow ... winter storm warning until 10 PM"
[15:29:41] <cradek> do you have some extra days to spare?
[15:29:48] <cradek> (where are you?)
[15:29:53] <SWPLinux> Buffalo
[15:29:59] <SWPLinux> 180 miles from HGR :)
[15:30:08] <cradek> dang.
[15:30:31] <SWPLinux> I don't mind bad weather. I do mind other drivers who don't know how to drive in bad weather
[15:31:07] <cradek> yeah that's the bigger problem.
[15:33:00] <cradek> hgr is open tomorrow right?
[15:33:50] <SWPLinux> yep
[15:34:01] <SWPLinux> I have an interesting trailer issue too
[15:34:08] <cradek> 'interesting'
[15:34:18] <SWPLinux> http://www.stengelbros.com/UtilityTrailerSuspensions.htm
[15:34:36] <SWPLinux> I have essentially the HK-105 setup
[15:35:17] <SWPLinux> except those hangers (labeled 3 in the diagram) aren't all pointing in the right direction
[15:35:25] <SWPLinux> one up, one down
[15:35:39] <cradek> oh, that doesn't seem right
[15:35:43] <SWPLinux> no
[15:35:58] <cradek> can you take out some pin 5 and fix it?
[15:36:03] <SWPLinux> I happened to notice that the front trailer tire wasn't on the ground (luckily in front of my house)
[15:36:05] <CIA-42> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/halui.cc: count-enable pins let one MPG be used for FO, SO, MV and other purposes
[15:36:11] <CIA-42> EMC: 03jepler 07TRUNK * 10emc2/docs/man/man1/halui.1: pins added since last doc update
[15:36:25] <cradek> jepler: yay! now I don't have to do that!
[15:36:26] <cradek> thanks!
[15:36:35] <SWPLinux> yeah, removing something would probably help
[15:36:35] <jepler> cradek: now you get to test it :-P
[15:36:41] <cradek> I will...
[15:36:44] <SWPLinux> then testing it with a 180 mile drive
[15:38:20] <cradek> hope you got a good deal on your screwy trailer...
[15:38:26] <SWPLinux> free!
[15:38:37] <cradek> heck it's probably worth twice that
[15:38:38] <jepler> anybody else taken a look at the second patch from micges?
[15:39:00] <SWPLinux> actually, it was fine until I tested out the brakes, when they locked up I think it made the trailer bounce
[15:39:19] <SWPLinux> then again, a lot of things make the empty trailer bounce
[15:39:30] <SWPLinux> so there's probably not much point fixing it until Ohio
[15:39:36] <cradek> jepler: I wish I understood better what problem he is trying to fix: "In some cases controlling with couter/scale was cousing bouncing of value."
[15:39:42] <SWPLinux> I'm sure it won't bounce a lot with the lathe/control on it
[15:40:28] <SWPLinux> this is for the "absolute override input"?
[15:40:45] <cradek> yes
[15:40:48] <jepler> yes
[15:41:01] <SWPLinux> you have to reset the "last count" value from the count input whenever there's a change on the float input. I don't remember if that's in the patch
[15:41:40] <cradek> + if (floatt != old_halui_data.fo_cmd) {
[15:41:40] <cradek> + sendFeedOverride( floatt );
[15:41:40] <cradek> + old_halui_data.fo_cmd = floatt;
[15:41:53] <SWPLinux> nope
[15:41:57] <SWPLinux> there should be another one
[15:42:03] <SWPLinux> like when the count input is disabled
[15:42:23] <SWPLinux> you track the count so there's no jump when it gets re-enabled
[15:42:41] <cradek> oh, hmm
[15:44:44] <cradek> jepler: does yours get that right (no jump when enabling)?
[15:45:13] <jepler> cradek: yes
[15:45:43] <cradek> neat. I will use yours with my 3 position switch and one encoder (fo, so, mv)
[15:45:52] <SWPLinux> heh
[15:46:02] <SWPLinux> the code is also in motion, for the selective axis jogging
[15:46:10] <cradek> right
[15:46:26] <cradek> for me, those are separate knobs, but it's nice if you could use just one.
[15:46:45] <SWPLinux> or make the scales adjustable by another knob, and allow off-axis jogging
[15:47:04] <SWPLinux> (by jogging X as cos(t) and Y as sin(t))
[15:47:27] <cradek> SWPLinux: oh hey, #4 in that diagram pivots
[15:47:27] <jepler> as far as incrementally changing FO/SO/MV is concerned: you can incrementally change them in axis by clicking in the trough of the scale
[15:47:39] <SWPLinux> yes
[15:47:44] <cradek> if you could jack it up and you have a prybar, maybe you could put it back in order without removing any #5 bolts
[15:47:54] <SWPLinux> yeah, that's how I did it at home
[15:47:57] <cradek> jack up the trailer bed, not the axles
[15:48:02] <jepler> to get that to work "right", AXIS has logic that displays the recently-commanded value if a new value was commanded recently, otherwise the value from the stat buffer
[15:48:03] <cradek> oh it's done it before?
[15:48:08] <jepler> before this you could see a kind of "bouncing"
[15:48:11] <SWPLinux> but I fixed it in the wrong direction, so it was half right within 10 miles :)
[15:48:21] <cradek> oh, haha
[15:48:23] <jepler> so cradek may be right that micges is just saying that .counts is buggy
[15:48:35] <cradek> maybe you could have looked at the other side... :-)
[15:48:49] <SWPLinux> same problem ;)
[15:49:02] <SWPLinux> strangely, in the opposite direction
[15:49:16] <cradek> huh, seems like a design bug
[15:49:25] <cradek> jepler: thanksf or asking.
[15:49:32] <SWPLinux> in other news, I also love the added tolls for vehicles with trailers
[15:49:37] <jepler> * jepler is not sure at any given moment whether cradek is talking about trailers or feed overrides
[15:49:41] <SWPLinux> heh
[15:49:50] <cradek> well that one was about the trailer
[15:51:25] <cradek> am I evil if I think I could make a grid tool changer pretty easily by adding some hal pins to task?
[15:52:04] <cradek> that is possible, isn't it? like kinematics can have hal pins?
[15:52:12] <skunkworks> cradek: that sounds interesting..
[15:52:33] <cradek> skunkworks: well, it would suck actually
[15:53:06] <SWPLinux> there should be "external joint position inputs" or something like that for motion
[15:53:47] <SWPLinux> the positions would get treated as G0 moves from the current position, with accel/vel limits
[15:54:14] <SWPLinux> so an external toolchanger or profiler could take over, but motion would know what's happening and wouldn't throw following errors all the time
[15:54:24] <skunkworks> when I was in school - goto statements where concidered bad... When I got to college - one instructor said 'do what ever it takes to get the job done' :)
[15:54:53] <cradek> well tool change is a somewhat special case where after it's over, the machine can be left anywhere and things resync
[15:55:06] <cradek> so with a bit of handshaking between task and hal, maybe hal could move the machine at tool change time
[15:56:57] <SWPLinux> wow. there are a lot of commercials, even on the weather channel
[15:57:53] <cradek> one problem I see is that task issues the motion but can't tell when it's done (I think)
[15:58:33] <cradek> so it's not trivial to make a loopback (set position, hal->task signal to move, task->hal signal that it's done)
[16:00:12] <jepler> cradek:
http://article.gmane.org/gmane.linux.distributions.emc.devel/201
[16:00:27] <jepler> (I also forwarded you a copy because I thought it was older than our gmane archive -- but I guess it wasn't)
[16:00:42] <jepler> wow, total fail by gmane on markup in that article
[16:02:20] <SWPLinux> yep, that's the idea
[16:02:51] <jmkasunich> swp in buffalo?
[16:03:01] <SWPLinux> yep
[16:03:11] <jmkasunich> what is the weather there?
[16:03:18] <SWPLinux> I can actually see the nearby buildings through the blowing snow
[16:03:39] <SWPLinux> the nice thing is that the nearby airport is a lot quieter
[16:03:52] <jmkasunich> ick
[16:03:52] <SWPLinux> how is it there?
[16:04:12] <jmkasunich> freezing rain, trees are getting somewhat glazed (that is the bad news)
[16:04:26] <jmkasunich> the good news is that its not freezing on the ground, and temps are rising
[16:04:37] <jmkasunich> 30.7 to 31.5 while I took my shower
[16:04:45] <jmkasunich> by mid-day it should just be rain
[16:05:05] <SWPLinux> ok. I'm 180 miles away. it won't be 3 hours like it should be, but maybe 4 or 5
[16:05:34] <jmkasunich> cool - for some reason I thought Buffalo was farther than that
[16:05:44] <SWPLinux> no. lucky me :)
[16:10:09] <SWPLinux> ok. time to hit the road. see you later
[16:11:09] <cradek> jepler: I think the motion should be coordinated/world mode, not using the free mode planner (so there is target + "go!"/"done" loopback); also I don't think it should move back to its old place for the same reason tool change doesn't
[16:12:09] <cradek> (also I don't really understand streamer's application here but I suspect that's an aside since there are many ways to generate these commanded moves)
[16:12:23] <jmkasunich> I think streamer was just an example
[16:12:36] <jmkasunich> regarding move-back, you pretty much have to
[16:12:42] <jmkasunich> the interp things you are at one place
[16:12:51] <cradek> not if you are using it for tool change
[16:12:57] <jmkasunich> in hal, you;ve moved all over the place, the interp doesn't know that
[16:12:59] <cradek> is there any other use?
[16:13:14] <skunkworks> pallet changes?
[16:13:16] <jmkasunich> (nor does task, or anything else outside of motion)
[16:13:16] <cradek> I'm assuming this is about tool changes, but maybe I'm missing something else
[16:13:58] <jmkasunich> well, it should be as general as possible (but not more so), but I think this even applies to a toolchange
[16:14:20] <cradek> no assumptions are made about the location after a tool change; it is reread
[16:14:40] <jmkasunich> re-read? from the feedback?
[16:14:51] <cradek> if we put this in task instead of motion, I think we could cause a similar resync after this kind of motion
[16:15:15] <jmkasunich> ok, there is the key - IF it is in task, then task knows what is going on
[16:15:21] <cradek> CANON_POSITION GET_EXTERNAL_POSITION()
[16:15:26] <cradek> ...
[16:15:26] <cradek> pos = emcStatus->motion.traj.position;
[16:15:36] <jmkasunich> as proposed, I think it was in motion only, and traj was in the dark
[16:15:39] <cradek> this propogates through all the layers
[16:16:10] <cradek> I think, but am not sure, that the proposal is about moving in joint space, which I think is a mistake
[16:16:13] <jmkasunich> I see
[16:16:22] <jmkasunich> I think I agree there
[16:16:49] <cradek> imagine a puma with some tools in reach...?
[16:17:09] <jmkasunich> a very early decision needs to be made - what coord system are the moves in
[16:17:16] <jmkasunich> not just joint vs world
[16:17:20] <jmkasunich> what about offsets, etc?
[16:17:22] <cradek> also the moves should be coodinated/straight lines
[16:17:27] <jmkasunich> my guess is the coords should be G53 space
[16:17:33] <cradek> jmkasunich: like tool change position, they would be in the unoffset coordinates
[16:17:46] <jmkasunich> G53 world IOW?
[16:17:59] <cradek> yes I think that's the same as G53
[16:18:04] <cradek> brb
[16:18:08] <jmkasunich> I agree about coordinated mode
[16:26:30] <jmkasunich> hmm, I should have mentioned to swp that if he wants to work on the trailer suspension, I have a floor jack, and he could back it into the garage to work out of the rain
[16:31:39] <jepler> cradek: I think that at the time I wrote this, tool change said it returned to a prior position
[16:32:15] <cradek> yeah I think it's since then that I made the interp resync after tool change
[16:32:47] <cradek> if we want to allow this "whenever" I agree there isn't much choice - you have to leave the position as you found it
[16:32:52] <jmkasunich> if this is done at the task level, what kind of timing skew issues are we going to see?
[16:32:55] <cradek> but I see this as a tool change thing
[16:33:18] <jmkasunich> oh, I just thought of a non-toolchange application
[16:33:22] <cradek> jmkasunich: I don't know what the handshake will look like
[16:33:27] <jmkasunich> (not sure if this is good or not, but....)
[16:33:42] <jmkasunich> all the people who want to be able to stop, inspect or change a tool, and continue
[16:33:51] <jmkasunich> they could invoke this mode to do that
[16:34:13] <cradek> bleh
[16:34:17] <jmkasunich> yeah
[16:34:25] <cradek> I don't want to make an entirely new way to jog. I think that would be a mistake.
[16:34:32] <jepler> changing tool means possibly changing tool length and radius halfway through a cut
[16:34:37] <jmkasunich> yeah, I was just going there
[16:34:40] <jepler> that's crazy talk
[16:35:22] <jmkasunich> unfortunately, since we don't have another good way to solve that problem, some people will see this functionality as a way, crazy or not
[16:35:49] <cradek> but we do - abort, do stuff, rfl
[16:36:02] <cradek> it actually works pretty well right now
[16:36:14] <jmkasunich> every time I see a discussion about that, it seems it doesn't work quite well enough
[16:36:26] <jmkasunich> must admit its not something I've ever tried to do
[16:36:37] <cradek> you have to rfl somewhere smart
[16:37:06] <cradek> I think I don't want to talk about this right now
[16:37:19] <jepler> users want to start from the middle of an arbitrary move -- e.g., halfway through an arc move, after 5 of 9 peck cycles of the 3rd hole in a G8x canned cycle, and so on
[16:37:26] <cradek> is there another non-toolchange use?
[16:37:45] <jmkasunich> nothing springs to mind
[16:37:55] <cradek> jepler: yeah. they expect all those things to work.
[16:38:07] <jmkasunich> but I'm sure somebody will think of something we didn't - that is the nature of users (and life in general)
[16:38:40] <cradek> (fwiw, I currently have no use for this feature)
[16:38:46] <jmkasunich> cradek: I think I agree with you
[16:38:53] <cradek> jmkasunich: which thing?
[16:39:06] <jmkasunich> "don't want to talk about now"
[16:39:08] <cradek> ah
[16:39:15] <cradek> it's a sidetrack
[16:39:17] <jmkasunich> I have a few errands to run
[16:39:41] <cradek> be careful
[16:39:56] <jmkasunich> I still haven't shipped your toolholder, and I have to pick up my order from metal express
[16:40:07] <cradek> don't sweat the shipping - do it anytime.
[16:40:17] <cradek> it's not worth extra driving on ice
[16:40:25] <jmkasunich> anytime = on the same trip as the metal express run
[16:40:31] <cradek> ha
[16:40:35] <cradek> suit yourself :-)
[16:40:44] <jmkasunich> I ship from staples, it is less than a mile away
[16:40:53] <jmkasunich> if it wasn't raining I could walk
[16:42:05] <steve_stallings> did SWP get things figured out and hit the road? I hope the weather is not a major hassle.
[16:42:29] <jmkasunich> he spend the night in buffalo (as planned), and is on the road to cleveland as of about 10-15 mins ago
[16:42:34] <jmkasunich> spent
[16:43:38] <cradek> sounds like the weather could be better.
[16:43:44] <cradek> much better, actually
[16:44:02] <cradek> walking directions from buffalo to cleveland: 2 days, 13 hours
[16:44:12] <jepler> oh is that all?
[16:44:17] <steve_stallings> I think I would have asked them how much $ to store it until spring.
[16:44:20] <cradek> so it says
[16:44:40] <jepler> does that mean 61 hours of non-stop walking?
[16:44:46] <jmkasunich> 2.1 mph, assuming you walk 24 hours a day
[16:44:48] <cradek> yes, 188 miles
[16:47:18] <jepler> unrelated to anything, I want to make a device that turns power on and off to several 120VAC outlets. One of the devices it's switching will be a laser printer, possibly 800W while printing. Should I choose SSRs or relays for this?
[16:47:33] <jmkasunich> how often will you be switching?
[16:48:20] <jepler> the laser I imagine would end up being switched on much less than 1 hour a day. the other devices (<<100W -- dsl modem and wireless router) will, by contrast, be on almost all the time
[16:48:29] <cradek> switch with whatever is rated 120VAC 15A or 20A, whichever your outlet is
[16:48:34] <steve_stallings> either would work if properly sized
[16:48:36] <jmkasunich> I mean, number of on-off cycles
[16:48:42] <jmkasunich> what steve_stallings said
[16:49:04] <jmkasunich> the differences are mostly that an SSR will need some heatsinking, but is probably easier to drive
[16:49:24] <jmkasunich> ssr is quieter, if that matters
[16:49:40] <jepler> I think that's not particularly important
[16:49:53] <jmkasunich> the router and modem are basically wall-warts?
[16:49:57] <jepler> yeah
[16:50:12] <jmkasunich> so you have two very small loads, on most of the time
[16:50:19] <jmkasunich> and one much larger load, rarely on
[16:50:19] <steve_stallings> our network server used to have a laser printer with the raster engine on a card inside the computer and we used a SSR for power control of the big power hungry print engine, ran for over 10 years
[16:50:22] <cradek> I think it's a mistake to assume you know what will ever be plugged into an outlet
[16:50:27] <jepler> (in fact right now I switch the DSL modem's DC power with a small relay; it needs to be restarted occasionally to improve reliability)
[16:50:28] <jmkasunich> you are using one relay for this, or two?
[16:50:41] <jepler> jmkasunich: I'll have one relay per device
[16:50:50] <jmkasunich> oh, that changes things a bit
[16:51:23] <jmkasunich> cradek is right, if you are switching power to an outlet, you need to either assume someone will plug a space heater into it some day, or fuse it for the much smaller load
[16:51:35] <jmkasunich> it seems dumb to use a 20A relay (SSR or regular) for the wall-wards
[16:52:22] <jepler> well, yeah
[16:52:26] <jmkasunich> I haven't looked at prices yet, but SSRs that can switch the full capacity of an outlet won't be so cheap that you'll feel happy about one per device
[16:52:30] <steve_stallings> wall warts in general are dumb, I hate the old transformer style one, modern switchers in slim case are passable
[16:53:06] <jmkasunich> I've thought about cutting the wall-wart cord on my router/modem, and introducing a battery with a float charger
[16:53:12] <cradek> http://surpluscenter.com/item.asp?UID=2008121910520978&item=11-3167&catname=
[16:53:13] <jmkasunich> since the modem is far away from my UPS
[16:53:23] <cradek> this is what's in my lathe control for the spindle outlet
[16:53:29] <cradek> (sherline lathe control)
[16:53:37] <jepler> cradek: yeah, I have a few of those as well
[16:53:46] <jepler> in fact it's my spindle on-off control too
[16:53:55] <jmkasunich> hard to beat that
[16:53:58] <cradek> 18A 120V is fine if you use a normal 15A outlet
[16:54:09] <cradek> they're so easy to drive!
[16:54:12] <jepler> is 15A the "3 prong" outlet?
[16:54:29] <steve_stallings> bet it needs a heatsink surface
[16:54:30] <cradek> yes 15A is the normal outlet without the horizontal hot
[16:54:33] <jmkasunich> the "normal" outlet is 15A (two or three prong)
[16:54:54] <jepler> steve_stallings: yeah if I recall correctly the bottom is metal
[16:54:55] <jmkasunich> 20A has a tee shaped slot, so it will accept 15 or 20A plugs
[16:55:13] <jmkasunich> yes, if you are going to run it anywhere near its rating, it needs a sink
[16:55:30] <cradek> you need to screw it to something anyway...
[16:55:37] <jmkasunich> also, keep in mind that IF an SSR fails, it fails in the on position
[16:55:44] <steve_stallings> SSR can also get into trouble with a tungsten load or switching power supply due to the inrush current
[16:55:51] <cradek> oh, I didn't know that...
[16:56:02] <jmkasunich> amusing story - we had a test oven at work, with SSR control of the heaters
[16:56:28] <jmkasunich> SSR failed, the next morning the plastic cases of the drives that were on heat-run looked like something from picasso's "melting stuff" period
[16:56:51] <cradek> ha
[16:57:39] <jepler> surely the printer has a switching power supplyt
[16:57:49] <jmkasunich> and a tungsten fuser heater
[16:58:02] <jepler> so now you're saying to not use an SSR for that?
[16:58:03] <jmkasunich> although that won't be turned on when the SSR switches on
[16:58:17] <jmkasunich> not neccessarily
[16:58:18] <steve_stallings> choose a SSR with 2X the expected load rating
[16:58:24] <jmkasunich> just don't use a marginally sized SSR
[16:58:33] <jmkasunich> what is the nameplate amps for the printer?
[16:58:48] <jmkasunich> if <9, you should be good with the SSRs you have
[17:00:52] <jepler> hmph, the pdf manual for the printer doesn't say
[17:00:54] <steve_stallings> larger modern switching supplies are typically power factor corrected and the by default includes a sort of soft start that avoids the inrush to charge the caps
[17:01:01] <jepler> it's all about "what to click to install our terrible drivers"
[17:01:12] <jmkasunich> ?
[17:01:18] <jmkasunich> look at the actual printer
[17:01:34] <jmkasunich> all UL listed items must be marked with input voltage and current
[17:01:46] <jmkasunich> (unless maybe you don't have the printer yet?)
[17:02:04] <jepler> it's at home and I'm at the office
[17:02:15] <jepler> all I can find in the manual is "320W average during operation"
[17:02:16] <jmkasunich> note that a significant chunk of the printer current wil be for the fuser heater, that part isn't going thru the switchmode
[17:02:29] <jmkasunich> so about 3A
[17:02:38] <jmkasunich> you'll be fine with that 18A SSR
[17:02:38] <cradek> how old is your printer that it doesn't have its own power saving?
[17:03:07] <jepler> cradek: it has power saving modes, but it still "feels warm" no matter what
[17:03:15] <cradek> ah, that sucks
[17:03:19] <steve_stallings> true, and I don't know if the fuser is as bad as a tungsten lamp or if it has a less agressive temp coefficient
[17:03:35] <jmkasunich> I bet less so - simply because it doesn't run white hot
[17:03:42] <jmkasunich> so the ratio between cold and hot will be less
[17:03:58] <jmkasunich> I know mine flickers the lights a tiny bit when it switches the heater on
[17:04:41] <jmkasunich> that reminds me - I think I might get myself an xmas gift:
http://store.altenergystore.com/Meters-Communications-Site-Analysis/Meters-Battery-Monitors/Power-Meters/P3-International-Kill-A-Watt-P4400-Kill-A-Watt-Power-Meter/p932/?source=froogle
[17:04:53] <jepler> is there a kind of heatsink that is meant to go with this style of ssr, or is screwing it onto some aluminum box going to do?
[17:05:16] <steve_stallings> good contact with steel or alum box will work fairly well
[17:05:25] <jmkasunich> alum better obviously
[17:05:35] <jmkasunich> and 1/8" aluminum better than 1/32"
[17:06:01] <jepler> I wish I hadn't trashed my dead UPS's case. it would be the right thing to put this project in. :(
[17:06:02] <cradek> jmkasunich: HF has those
[17:06:20] <steve_stallings> and New Egg, and almost everywhere....
[17:06:34] <jmkasunich> yeah, I didn't neccessarily mean I would buy it from them
[17:06:38] <jmkasunich> that was just the first google hit
[17:06:38] <steve_stallings> neat gadget, used to cost $$$$ to get this function
[17:06:49] <jepler> I picked one of those up at HF recently, in fact -- I think it was $30 there, but the shelf sign said it was a sale
[17:07:03] <jmkasunich> heh, those surplus center SSRs are $26 from digikey
[17:07:39] <steve_stallings> got my KillAWatt from New Egg, it only cost $350 including the camera that also causht my eye...
[17:07:46] <steve_stallings> causht
[17:07:50] <steve_stallings> caught.....
[17:07:59] <jepler> steve_stallings: oops, I hate it when that happens
[17:08:15] <jepler> * jepler blew about $200 on there yesterday, after intending to buy just a DLT cleaning tape
[17:08:21] <jmkasunich> http://www.crydom.com/en/Products/Catalog/e_z.pdf
[17:08:30] <jmkasunich> ^^^ datasheet for the SSR
[17:08:41] <jmkasunich> there is heatsink and derate info there, haven't read it all yet
[17:09:11] <jepler> 150A peak surge current? sounds like plenty.
[17:09:13] <steve_stallings> yea DLT, I have retired 3 Exabyte drives in favor of DLT-8000s over the last couple of months
[17:09:27] <jmkasunich> no heatsink, 25C ambient, it is only good for a little under 5A
[17:09:50] <jmkasunich> oops, read the wrong graph
[17:09:57] <jmkasunich> that datasheet covers three ratings
[17:10:11] <jmkasunich> no heatsink, 25C, about 7A
[17:10:33] <jmkasunich> 5 degC/watt sink, 25C, 15A
[17:13:15] <jmkasunich> 5deg C/watt is hard to translate into square inches of aluminum, but the smallest sink crydom sells is 2degC/watt (lower is better)
[17:13:58] <jmkasunich> that one is about 2" square, 1/4" thick baseplate, with 7 fins about 1-1/4" long
[17:14:28] <jmkasunich> I bet a scrap old CPU sink would work nicely
[17:14:41] <jmkasunich> old = before they got all fancy with fans and heat pipes and such
[17:14:48] <jmkasunich> just a chunk of extrusion
[17:15:22] <jmkasunich> that would get you the full 18A rating, at least over a household ambient temp range
[17:16:25] <jmkasunich> hmm, another way of looking at it - that sink has about 35 sq in of surface area
[17:16:50] <jmkasunich> a 6" square of aluminum has about the same (assuming only one side is exposed to outside air
[17:17:05] <jmkasunich> make it 1/8" thick to ensure that heat spreads well
[17:27:56] <seb_kuzminsky> jepler: for switching outlets on and off, how about x10? it's cheap and works out of the box in linux
[17:29:05] <jepler> seb_kuzminsky: I forget that x10 is anything but the "creepy spy camera banner ad people"
[17:29:27] <cradek> YM creepy spy camera banner-add spammers HTH
[17:29:30] <cradek> ad
[17:29:57] <seb_kuzminsky> in addition to creepy spycams, they make at least two kinds of computer-controller outlets
[17:30:15] <seb_kuzminsky> a solid state one that switches low loads, and a mechanical relay one that handles much more
[17:30:35] <seb_kuzminsky> i have a box of them lying around here, i'll mail you some if you want
[17:31:23] <seb_kuzminsky> i used x10 to turn a pump on and off for a hydroponics project, and to powercycle a buggy dsl modem way back when
[17:32:55] <seb_kuzminsky> hm, i wonder now if i still have that box
[17:32:55] <seb_kuzminsky> brb
[17:33:54] <seb_kuzminsky> here it is
[17:33:57] <seb_kuzminsky> look at all this junk
[17:34:18] <seb_kuzminsky> "lamp module": max 300W
[17:34:37] <cradek> hm
[17:34:42] <cradek> what does it mean if I get
[17:34:43] <cradek> HAL: ERROR: Only one component per process
[17:34:43] <cradek> ERROR: hal_init() failed
[17:34:51] <cradek> when nothing else in the process calls hal_init()?
[17:34:57] <seb_kuzminsky> "appliance module": max 15A resistive, 1/3 hp motor, 500W incandescent
[17:35:20] <cradek> (yes I'm sure I'm doing something stupid)
[17:36:00] <jepler> the x10 website is so visually offensive that I can't bring myself to think it's a good product
[17:36:25] <cradek> jepler: the modules seb's talking about were made before the www, if that's any consolation
[17:36:39] <jepler> heh
[17:36:51] <seb_kuzminsky> x10-the-company sucks, no doubt about it
[17:36:58] <seb_kuzminsky> x10-the-technology is usable
[17:37:06] <cradek> true
[17:37:06] <jmkasunich> funny, I never associated the two
[17:37:19] <jmkasunich> I knew of the x10 tech - powerline comms, etc
[17:37:25] <seb_kuzminsky> that's the one
[17:37:51] <jmkasunich> one solution, try ebay for the tech, avoid sending your money to the spammy company
[17:38:39] <seb_kuzminsky> or get it for free from my junk pile ;-)
[17:38:58] <jmkasunich> cradek: I think you have found a bug
[17:39:10] <jmkasunich> #ifdef ULAPI
[17:39:10] <jmkasunich> if (ref_cnt) {
[17:39:10] <jmkasunich> rtapi_print_msg(RTAPI_MSG_ERR, "HAL: ERROR: Only one component per process\n");
[17:39:12] <jepler> cradek: I'd say there's a problem in the source code you're refusing to show us
[17:39:16] <jmkasunich> static int ref_cnt;
[17:39:27] <jmkasunich> ref_cnt never gets initialized
[17:40:03] <cradek> nope, that does not fix it
[17:40:06] <jmkasunich> or does C assume init to zero?
[17:40:16] <jepler> "bss" is initialized to all bytes zero
[17:40:22] <jepler> on unix; not specified by "C"
[17:40:32] <jepler> http://en.wikipedia.org/wiki/Block_Started_by_Symbol
[17:40:48] <cradek> I added =0 and it does not help
[17:40:50] <cradek> ohhh
[17:41:03] <cradek> I'm an idiot, I bet INIT_CANON is just called more than once
[17:41:05] <cradek> dangit
[17:41:27] <jmkasunich> printf is your friend for that
[17:41:45] <jmkasunich> bbl, off to run errands
[17:42:23] <cradek> yeah, that was it, duh
[17:42:39] <cradek> if I don't know what I'm doing, I forget to look for the obvious problem
[17:45:23] <CIA-42> EMC: 03cradek 07TRUNK * 10emc2/src/hal/hal_lib.c: this happens implicitly anyway, but let's be explicit
[17:46:21] <jepler> seb_kuzminsky: how much do you want for that x10 stuff?
[17:47:15] <cradek> how do you do the computer interface nowadays? It used to be a serial port on a special controller
[17:47:53] <jepler> cradek: from what I found on the x10 website before I burned my eyes out, there's a serial port dongle that transmits wirelessly to something you plug into the wall
[17:47:57] <jepler> it was called firecracker or something(?)
[17:48:10] <jepler> isn't one of the problems with x10 that you don't know if your command has been received?
[17:48:14] <cradek> man, sorry about your eyes
[17:48:18] <cradek> yes, that's its main drawback
[17:48:27] <cradek> you can send it a few times to make yourself feel better though
[17:48:57] <seb_kuzminsky> jepler: wash them out with bleach
[17:49:32] <cradek> the other problem is often it doesn't make it to the 'other half' of your house (other side of the 220)
[17:49:52] <cradek> at home we have (or had?) a double breaker with nothing but a cap on it for that reason
[17:53:33] <jmkasunich> I hope it is a reliable cap, or a low-rated fast-tripping breaker
[17:54:02] <cradek> um
[17:54:15] <cradek> no idea but probably neither of those things are true
[17:54:42] <jmkasunich> the idea of a cheap cap across 240V makes me shudder
[17:54:54] <jmkasunich> at least tell me it is rated 2x or more of the applied voltage
[17:54:59] <cradek> if anything goes wrong I'd think it would just disappear?
[17:55:04] <cradek> oh probably
[17:55:16] <cradek> I don't remember what it is
[17:55:18] <jmkasunich> it would disappear in a flash
[17:55:34] <jmkasunich> said flash _might_ cause additional arcing in the breaker box
[17:55:35] <cradek> sure, that's ok :-)
[17:55:38] <cradek> oh
[17:55:46] <jmkasunich> at 480V, it would be a serious hazard
[17:55:57] <jmkasunich> at 120V, not much at all
[17:56:01] <jmkasunich> dunno about 240V
[17:56:28] <jmkasunich> anyway, I came back to check harborfreight for kill-a-watt meters
[17:56:38] <jmkasunich> they only seem to have the $99 fancy power strip ones - bummer
[17:56:50] <jmkasunich> (the local harbor frieght is only a mile or so from metal express)
[17:57:52] <jmkasunich> bbl again
[18:24:39] <steve_stallings> steve_stallings is now known as steves_logging
[19:37:02] <cradek> ick, it's not so simple, because the tool change hal loopback stuff is in iotask, not task
[19:38:24] <cradek> and iotask can't put my moves on the interp_list
[19:40:40] <jepler> kill iotask!
[19:40:46] <cradek> noooooo
[19:40:59] <cradek> (but yeah, that's the answer)
[19:41:33] <cradek> well, maybe kill all of task and start over is the answer
[19:47:04] <seb_kuzminsky> jepler: i'm trying to msg you and dcc chat you, are you getting any of this?
[19:47:29] <jepler> hi web
[19:47:33] <jepler> argh
[19:47:33] <jepler> seb
[19:47:36] <jepler> the way I
[19:47:41] <jepler> 'm typing you'd think I had a few beers at lunch
[19:47:48] <jepler> (I didn't)
[19:47:49] <seb_kuzminsky> at least ;-)
[19:48:03] <jepler> well, you know I'm a light drinker
[19:55:42] <jmkasunich> last friday before the holidays, office party?
[19:56:01] <jmkasunich> btw, swp just called me - he made it into ohio, probably about an hour out
[19:56:10] <jmkasunich> and weather here is improving
[19:57:01] <jepler> actually, that's next tuesday
[19:57:13] <jepler> but I don't expect it'll be that good a party
[19:57:36] <cradek> http://comics.com/reality_check/
[19:58:51] <jepler> heh
[19:59:23] <jmkasunich> ;-)
[20:32:50] <cradek> jmkasunich: thanks for shipping that
[21:10:42] <cradek> jepler: it has estop in it too
[21:11:12] <jepler> cradek: oh, iotask?
[21:11:35] <jepler> does that provide any advantage, besides "it's already written"?
[21:11:53] <cradek> also it currently works
[21:12:04] <cradek> those are the only two I can think of
[21:13:58] <cradek> I wish I could remember what's wrong with tool prep. if we could fix that too, it would be even better
[21:17:06] <jepler> that was a productive session
[21:33:05] <micges> cradek, jepler: what about my qestion about more than one TOOL_CHANGE_POSITION ?
[21:33:24] <micges> is it possible even ?
[21:40:29] <micges> good night all