Back
[00:03:15] <jepler> hm, 50-microsecond step pulse length + doublestep is a terrible combination
[00:03:22] <jepler> do some bad stepper boards really require that?
[00:05:41] <cradek> where did you see that?
[00:06:51] <SWPadnos> the guy with the AIO-500
[00:07:33] <SWPadnos> stepgen should probably choose some pseudo-arbitrary steplen at which to stop using doublestep
[00:07:57] <SWPadnos> like 2x max_lat or something
[00:08:13] <cradek> that kind of looks like a crap board to me
[00:08:19] <SWPadnos> it probably is
[00:08:25] <cradek> John T said it best
[00:08:47] <SWPadnos> heh - experience instead of hardware :
[00:08:48] <SWPadnos> :)
[00:19:44] <jepler> SWPadnos: yeah .. something
[00:19:47] <jepler> more bugs for me to add to stepconf
[00:20:15] <SWPadnos> cool! there haven't been any for a while, I think it needs more
[00:20:57] <SWPadnos> the best thing to do (assuming you want it added) is to make a checkbox, and populate it based on some heuristics
[00:21:26] <SWPadnos> the calculations always get done based on whatever the checkbox state is, so there's no question about how the number was derived
[00:22:19] <jepler> a starting user won't be able to decide how to set the checkbox. ergo, no checkbox.
[00:22:55] <SWPadnos> well, it will be automatically filled in for them, and the tooltip/instructions can say "leave this alone unless you know what you're doing"
[00:23:25] <SWPadnos> then again, there are users that don't know that STEPLEN is the STEP LENgth
[00:28:16] <jepler> you need a 3-state checkbox for that (on/off/auto) and no such thing exists in my happy place
[00:30:35] <SWPadnos> no, on/off, and the furst time through, let an equation turn it on or off
[00:30:40] <SWPadnos> first
[00:30:56] <cradek> once-you-touch-it-you're-committed?
[00:31:04] <cradek> no way to get back to auto?
[00:31:16] <SWPadnos> no, you can always check/uncheck it
[00:31:40] <SWPadnos> I think that may be less surprising than having your setting change when you back up and return to the page
[00:31:57] <SWPadnos> I understand that on/off/auto is better, but there may be acceptable workarounds
[00:53:24] <jepler> so what else did I miss this weekend?
[00:53:36] <jepler> I didn't pay the internets much attention .. or IRC at any rate
[00:54:20] <SWPadnos> well, I deconstructed a retaining wall, in preparation for getting our driveway repaved
[00:56:44] <jepler> sounds like a great time
[00:56:52] <SWPadnos> uh - yeah
[00:57:20] <SWPadnos> and I checked on hurricane Ike a lot, since I have a sister in Galveston
[00:57:49] <SWPadnos> well, she was in Galveston - she evacuated to Austin before the storm hit
[00:59:00] <cradek> I do not understand the appeal of living on underwater islands
[00:59:09] <SWPadnos> me either
[00:59:28] <SWPadnos> plus it's so hot all summer, that she "needs" to travel anywhere else to get away from the heat
[00:59:44] <SWPadnos> even going to Europe is probably less expensive than running the AC all summer
[01:00:12] <jepler> hm at the nice places where you like to stay?
[01:00:25] <SWPadnos> err - no, usually with friends/family or camping
[01:00:31] <SWPadnos> but she does fly first class :)
[01:00:49] <jepler> cradek: can I impose on you this week to work on zenbot's new screws?
[01:00:59] <cradek> yes
[01:01:00] <SWPadnos> Continental seems to have really cheap first class
[01:01:11] <cradek> sounds fun. I fired up the mill for some stuff today so it is working again.
[01:01:35] <cradek> (and I am pretty much well again)
[01:01:36] <jepler> cradek: and is the lathe running at this point? there's the couplings to be made too
[01:01:44] <cradek> yes, it works great
[01:02:13] <jepler> I saw stuff scroll by but didn't read it closely .. something about the two ball sizes and trig and metal shavings..
[01:02:42] <cradek> I am going to try putting bigger balls in it. but the originals are back in and it's working.
[01:03:49] <jepler> but you finally found the oscillation problem in the amp?
[01:03:57] <cradek> yes I fixed it ... with a resistor
[01:04:10] <jepler> a good guess, or based on theory?
[01:04:18] <cradek> I decline to answer that
[01:04:26] <jepler> I don't blame you
[01:04:49] <cradek> I did not guess where to put it - but figuring out what to put there is an emperical process
[01:06:16] <cradek> I wired in a pot for adjustment and them measured the result and replaced it with a fixed resistor
[01:06:40] <cradek> it is very snappy now. I have the accel set at 20. I have not checked for current limiting - maybe it could be faster.
[01:11:56] <cradek> I guess if it was limiting I would see ferror.
[01:12:00] <cradek> so, it isn't
[01:13:20] <jepler> so it takes what, .1 second to accelerate?
[01:13:28] <jepler> or does it move faster than I think
[01:14:00] <cradek> um, .16 sec
[01:14:05] <cradek> 3.33 in/sec
[01:16:47] <cradek> bbl
[11:51:15] <BigJohnT> alex_joni: I like the right click menu, what does the AXIS selection do?
[11:51:51] <alex_joni> it selects run from line
[11:52:01] <alex_joni> so if you push run it will run from the selected line..
[11:53:09] <BigJohnT> the AXIS is dimmed out only the start from here is allowed
[11:54:32] <BigJohnT> I left clicked on a line then right clicked and selected start from here then pressed the run button and I got what I expected
[11:56:36] <alex_joni> the AXIS is only a text
[11:57:08] <BigJohnT> ok
[12:06:40] <jepler> I think it's so you can remember what application you right-clicked on :-P
[12:10:46] <CIA-40> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/TODO: add TODO for documents
[12:10:55] <BigJohnT> that would help me when I have 27 apps open :)
[12:11:57] <BigJohnT> off to work with me
[12:13:24] <alex_joni> jepler: indeed :)
[12:13:35] <alex_joni> it looks silly with just one entry though
[12:14:03] <alex_joni> jepler: may I pick your brain later on the running_line selection?
[12:14:38] <jepler> alex_joni: sure, but for now I have to drive to the office
[12:14:52] <alex_joni> yeah, I'm a bit busy at work too.. so no hurry
[12:59:55] <jepler> alex_joni: something specific you want to ask?
[13:02:38] <pmbdk> Has anyone tried to use a 16c950 usrt in emc?
[13:02:48] <pmbdk> usrt => uart
[13:03:27] <SWPadnos> for what?
[13:03:29] <jepler> the only "serial port" driver in emc is the one called serport; it just treats the control pins like dumb I/O pins. It should work on anything that is 8250-compatible.
[13:04:19] <pmbdk> I will need to communicate using the serial port as wll... The 8250-compatible part is however not my problem
[13:04:30] <pmbdk> My problem is setting the baud rate higher than 115200
[13:04:31] <SWPadnos> something like modbus?
[13:04:40] <SWPadnos> ah, that's not an EMC problem
[13:04:49] <pmbdk> Nope, not at all... :)
[13:05:02] <SWPadnos> in the old days, you'd use "setserial" to set the max port speed
[13:05:12] <jepler> if it is a realtime driver, then you will have to write low-level register IO for your device. if it's a userspace driver, then what matters is whether the regular linux serial driver works with it.
[13:05:28] <SWPadnos> when the user requested 38400 or 57600 (or something), it would acutally use the settings set by setserial
[13:05:40] <pmbdk> I need it in the realtime part
[13:05:52] <jepler> somewhere around here I have info on setting "nonstandard" baud rates through the linux ioctl interface, but I guess that's not what you need
[13:05:52] <SWPadnos> hmm
[13:05:58] <pmbdk> can I use setserial to set the parameters?
[13:06:09] <SWPadnos> dunno - like I said, that was the old days ;)
[13:06:09] <jepler> no, you won't use the linux serial driver at all
[13:06:20] <jepler> you'll write your own driver that does low-level register IO to the 16c950 chip
[13:06:22] <pmbdk> that's what I thought
[13:06:49] <pmbdk> I remember that 8250 could not do it officially
[13:06:58] <pmbdk> including 16550
[13:07:18] <pmbdk> so you had to write to some register to make it happen
[13:07:31] <pmbdk> although this was not the official way to do it
[13:08:07] <jepler> the 8250 and 16550 max speed depends on some attached clock with a minimum divisor. Whether some extended 8250s or 16550s changed the minimum divisor through an extended or undocumented register, I don't know
[13:08:08] <pmbdk> since the divisor registers could only divide with 1, and the prescaler was set to 16 and everything was running at 1.8... MHz
[13:08:20] <jepler> right that sounds approximately like what I recall
[13:08:56] <pmbdk> i'm trying to read through a 16c950 datasheet
[13:09:21] <pmbdk> however if anyone knew the two or three i/o registers I need to setup it would be much easier... :-)
[13:09:37] <alex_joni> there is a serial driver part of RTAI
[13:09:54] <alex_joni> jepler: how the drawing of the blue rectangle is done in the 'text' widget
[13:10:10] <alex_joni> and how (where) I would go on about to add a new one..
[13:13:40] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: when start-from-line is set, reflect it in the program text by greying out lines before the start point
[13:13:48] <jepler> you're in luck! take a look at that diff; I bet it'll point you in a promising direction
[13:14:03] <jepler> step 1. configure the "tag". step 2. apply or remove it at the right times
[13:14:27] <alex_joni> jepler: that was one of the things I wanted to do :D
[13:14:59] <jepler> still, I think that "set first line" should go away, and it should become "run from this line" as a single action.
[13:15:04] <jepler> that makes greying it out a bit redundant
[13:16:06] <alex_joni> the other thing I want to do is mark the aborted line
[13:16:49] <alex_joni> not sure it's so intuitive to first set your modal codes, then look for the line you want and right click for "run from this line"
[13:17:00] <pmbdk> alex_joni: I guess the serial driver is not an integral part of emc?
[13:17:36] <SWPadnos> the driver that uses the modem status lines as I/O is. the RTAI driver is not
[13:18:06] <alex_joni> pmbdk: no, but it should be part of rtai
[13:19:57] <alex_joni> http://www.captain.at/rtai-serial-port-example.php
[13:20:27] <cradek> emc/task/emccanon.cc:1516: error: expected primary-expression before ‘<<’ token
[13:20:30] <cradek> heh
[13:20:34] <cradek> YOU GUYS BROKE THE ... oh
[13:20:39] <jepler> alex_joni: that's a userspace example
[13:20:56] <jepler> so the wrong road to head down for an emc hal driver
[13:21:32] <jepler> also, loadmods.sh really shows an appalling understanding of unix
[13:22:11] <cradek> no kidding
[13:22:14] <alex_joni> it's an lxrt example
[13:22:37] <pmbdk> is lxrt a part of emc2?
[13:22:46] <alex_joni> pmbdk: no, it's got nothing to do with emc2
[13:22:52] <alex_joni> * alex_joni suggest further reading first
[13:23:14] <jepler> rtai has (at least) two ways to do realtime code: first as kernel modules. second as "userspace" processes. lxrt is the name of the second way. emc uses the first way exclusively
[13:23:16] <alex_joni> lxrt = userspace "realtime" RTAI
[13:26:50] <cradek> jepler: I like that greying
[13:29:26] <alex_joni> cradek: what do you think of the idea of a popup when you select the run from line?
[13:29:29] <SWPadnos> how about syntax hilighting next? :)
[13:29:56] <alex_joni> a text entry which holds the modal codes up to that point (the ones that aren't currently active)
[13:30:12] <alex_joni> ray mentioned this used to exist at some point on emc1
[13:30:24] <alex_joni> that way the user can copy that and past to MDI
[13:32:15] <alex_joni> jepler: huh, wasn't the current line selected using blue? (while running a program)
[13:44:31] <pmbdk> hmmm, i still don't get it... I simply need to read/write to/from the serial port. This can be done in a hal component relatively easy as in emc2/src/hal/drivers/serport.comp so I simply need to set the baudrate...
[13:45:14] <pmbdk> fifo stuff, etc is also relatively simple... The only thing I don't get i the clock setup...
[13:46:16] <SWPadnos> that varies somewhat depending on the chip and the card
[13:46:36] <pmbdk> SWPadnos: yep, that's my problem... :-/
[13:46:40] <SWPadnos> I don't think they all use the same source clock, and there are several flavors of "high speed" UART
[13:46:53] <pmbdk> I use the 16c950
[13:46:55] <SWPadnos> so look at the source for the Linux driver(s), and see how they do it
[13:47:05] <pmbdk> Heh, tried to... :)
[13:47:07] <SWPadnos> alternately, you can look at the datasheet for the chip you're trying to use
[13:47:34] <pmbdk> the problem is that the chip datasheet doesn't really (as far as I can tell) specify the clock
[13:48:06] <SWPadnos> uh - look at the crystal on your board ...
[13:48:46] <pmbdk> thus the clock divisor registers can be set a number of ways (and in 16c950 compatible mode it's somewhat more than in 16550 mode) but it really doesn't specify the clock input
[13:48:55] <pmbdk> yeah, that's of course one way... :-)
[13:49:30] <SWPadnos> you could also try using a userspace comm program that supports the chip, and then use a different program to read back the settings it uses
[13:49:36] <pmbdk> but the idea of having a serial driver is obviously better... I just don't know how to use it with emc2, where to get it, etc
[13:49:56] <SWPadnos> if ti works with userspace, especially at high speeds, the registers will get set somehow :)
[13:50:25] <SWPadnos> note that there will be some issues with using it in-kernel, RT, with EMC
[13:50:44] <pmbdk> actually, i'm not sure that will work... in some places i've seen that it uses the scratch register to set up some intermediate stuff...
[13:50:45] <SWPadnos> 1) you won't be able to use the serial port interrupt - you'll have to poll
[13:51:06] <pmbdk> i'm only going to poll
[13:51:14] <SWPadnos> (unless you want to get into weird stuff)
[13:51:16] <pmbdk> so that's fine
[13:51:45] <SWPadnos> 2) you'll have to do your own buffering (not a huge programming challenge)
[13:52:14] <pmbdk> I _think_ i'm able to use the fifo even though i'm not using interupts
[13:52:32] <SWPadnos> if you expect to get responses back from the external hardware, you'll need error handling and timeout-related stuff in the kernel
[13:52:43] <SWPadnos> dealing with errors is always a pain with serial
[13:54:47] <pmbdk> SWPadnos: I agree... But on the other hand I already have this (and it works fine) so it shouldn't be a big problem...
[13:55:03] <SWPadnos> heh
[13:55:30] <SWPadnos> it's a little different when you're in a situation where you *MUST NOT* block for any reason
[13:57:28] <pmbdk> well, i'm not going to block...
[13:57:42] <cradek> serport.comp is NOT a serial driver
[13:57:56] <cradek> it controls the handshaking bits to be used for IO
[13:58:05] <pmbdk> cradek: no, but it communicates with the serial port... :-)
[13:58:24] <pmbdk> yes, and I need to read/write from other registers...
[13:58:34] <cradek> ok I understand
[13:58:39] <pmbdk> but in essence it still does what I need (I guess)
[13:59:00] <SWPadnos> not really
[13:59:11] <SWPadnos> it inputs and outputs stateless bits
[13:59:11] <pmbdk> but I still need a way to set my baudrate to >115200...
[13:59:21] <cradek> I just got here so didn't see the place where you said what you need...
[13:59:39] <SWPadnos> a serial communications driver needs to know whether it's supposed to output a new byte, read a received byte, process a packet, etc.
[14:00:00] <pmbdk> SWPadnos: sure...
[14:00:03] <SWPadnos> if you already have all that code, then splitting it out into a periodically called function shouldn't be hard
[14:00:20] <pmbdk> SWPadnos: true... :)
[14:00:33] <SWPadnos> if you have a scope, you can experiment with various timing registers and see what baud rate you end up with
[14:00:43] <pmbdk> but all I was asking for was actually setting up the uart for >115200 bps... :)
[14:01:12] <SWPadnos> it should be easy to try several of the recipes you find in other places and figure out the lock frequency
[14:01:16] <SWPadnos> clock
[14:01:20] <pmbdk> well, I will probably end up testing then... I just hoped... :-)
[14:02:28] <pmbdk> anyway, thanks for the help... will have to leave...
[14:20:57] <jepler> until -rt can give software step generation comparable to -rtai, I think it's a non-starter. It will make things worse for users, not better, if 5% of them can run on an ubuntu-built kernel and 95% of them have to use a different one. It creates confusion, and I am not sure what the benefit is for the minority of -rt users.
[14:22:01] <SWPadnos> anyone who uses hardware for microsecond-scale realtime can probably use the -rt kernel
[14:22:33] <jepler> right, but I don't think that's a substantial fraction of our users
[14:22:36] <SWPadnos> EMC could be all (or almost all) userspace at that point, which would also allow use of USB and other devices that we currently have issues with
[14:22:40] <jepler> more probably have smp and/or x86_64 machines, for instance
[14:22:49] <SWPadnos> it would be a lot easier to write a G-Rex driver in userspace
[14:23:05] <SWPadnos> -rt works on those, AFAIK
[14:23:53] <jepler> "oh you downloaded the wrong 700 megabyte iso file, of course emc just makes your steppers stall" -- I don't want to be saying this on IRC when our parport users download the wrong thing
[14:24:02] <SWPadnos> heh
[14:24:27] <SWPadnos> all we have to do is #ifdef POSIX error ... in hal_parport :)
[14:25:06] <SWPadnos> or in stepgen
[14:25:47] <cradek> maybe in a year or two, when one of you more clever guys make the $20 external step generator
[14:26:51] <jepler> I doubt you can do $20
[14:27:05] <SWPadnos> $20 cost, in 1 million quantity
[14:27:19] <jepler> yeah, but not $20 end-user cost in 100 quantity
[14:27:25] <SWPadnos> err - no
[14:32:57] <jepler> some of the ftdi serial chips have interesting byte-wide mode where bytes from the host are clocked out at a set rate, and bytes from an external device are clocked in at the same rate, according to a data direction register.
[14:33:53] <SWPadnos> didn't we look at those modes and determine that they wouldn't work for us
[14:34:00] <SWPadnos> or maybe that was on the gecko list
[14:34:21] <SWPadnos> something having to do with not accepting a new packet until the old one is completely flushed or something
[14:34:21] <jepler> the buffers are small, but if -rt gives USB and 1ms latency you can keep the fifos full but not overflowing
[14:34:37] <jepler> oh -- I haven't looked into it that closely
[14:34:56] <SWPadnos> there was a discussion of it somewhere - may not have been her
[14:34:57] <SWPadnos> e
[14:35:01] <jepler> I know that in some of the serial modes there are funky rules for when the device will report bytes available for transfer
[14:35:52] <jepler> anyway, envisioning 4 bits for step pins, two bits for parallel shift registers (in and out), and two bits left over for e.g., estop in and dedicated charge pump out. externally you need the ftdi chip and a couple of shift registers.
[14:36:36] <jepler> of course you have to duplicate all of stepgen's logic inside the ft hardware driver
[14:36:37] <SWPadnos> or just use a microcontroller to do the same thing - may be less expensive
[14:37:03] <jepler> yeah it might be worth looking into what you could do with a usb+microcontroller chip such as at90usb
[14:37:21] <SWPadnos> yep
[14:39:10] <jepler> but that's a project for someone younger and more foolish than me
[14:39:17] <SWPadnos> man, $2.17 each in 100 quantity for the 8k AT90USB
[14:39:24] <SWPadnos> how about older and more foolish?
[14:40:06] <jepler> darn, I know I ran into a nice page recently with some-open-source-license at90usb firmware for all sorts of different personalities
[14:42:01] <jepler> ah here's the one I was thinking of:
http://www.fourwalledcubicle.com/MyUSB.php and here's something else I ran into on the way:
http://www.ssalewski.de/AT90USB_board.html.en
[14:42:14] <cradek> the problem with getting something a project like this done is that none of us needs it
[14:42:23] <SWPadnos> heh
[14:42:40] <jepler> that's very true
[14:43:36] <cradek> the people who really need it are the ones who want to put steppers on high-speed machines (or step-servos on the same machines), and they're pretty much just going about it wrong
[14:45:12] <skunkworks_> 500gb seagate drives for 49.99 from geeks.com
[14:45:15] <skunkworks_> sata
[14:45:42] <SWPadnos> that seems about right :)
[14:45:46] <skunkworks_> http://www.geeks.com/details.asp?invtid=ST3500630AS-R
[14:45:52] <skunkworks_> with code 500DEAL
[14:46:37] <SWPadnos> ah, it's $10 off
[14:46:42] <skunkworks_> yes
[14:47:01] <skunkworks_> * skunkworks_ just bought 10
[14:47:03] <skunkworks_> ;)
[14:50:21] <SWPadnos> heh
[14:51:03] <SWPadnos> one thing that surprosed me - I just put together a high end machine for my nephew, and used the WD Raptor 300G/SATA2 drive. it's actually a 2.5" drive mounted on a big 3.5" form factor heatsink
[14:51:07] <SWPadnos> surprised
[14:51:17] <skunkworks_> wierd.
[14:51:22] <SWPadnos> unfortunately, it's 14mm thick, so it won't fit in a lot of notebooks, like mine
[14:51:25] <skunkworks_> I don't like WD
[14:51:36] <SWPadnos> the Raptors are the fastest drives on the planet, other than SSD
[14:51:46] <SWPadnos> including SCSI320
[14:52:24] <SWPadnos> for a long time, they were the only IDE/SATA drives that beat any of the U320 drives in anything
[14:53:10] <skunkworks_> I just have had a higher amout of wd go bad here.. my only reason.
[14:53:43] <SWPadnos> yeah. once you've been around long enough, you'll have had spells where drives from every vendor have gone bad
[14:54:02] <SWPadnos> it's happened to me with Conner, Wuantum, Seagate, Maxtor, WD, IBM ...
[14:54:07] <SWPadnos> Quantum, that is
[14:54:43] <SWPadnos> I wonder when those 1.5TB drives will actually be available for sale
[14:55:03] <skunkworks_> the only seagates I have that have gone bad are ones in servers running 24.7 - wd and maxtor have failed in workstations.
[14:55:42] <SWPadnos> seagate is probably the most consistently non-failur-eprone vendor
[14:55:44] <SWPadnos> gah
[14:56:21] <skunkworks_> heh
[14:57:43] <SWPadnos> hey - that's not bad. 1.5TB (Seagate) drives, $199 each
[14:57:56] <SWPadnos> slightly higher per GB, but 3x the density :)
[14:58:12] <skunkworks_> yah- the 1tb drives have come down quite a bit also
[14:58:15] <skunkworks_> TB
[14:58:16] <SWPadnos> imagine waiting for that fsck
[14:58:26] <SWPadnos> TERABYTE!!! muahahahahahaha
[14:58:28] <SWPadnos> oh, sorry
[14:58:43] <jepler> how big is a 1.5TB drive? About 1TiB?
[14:58:48] <SWPadnos> I still remember buying a 1GB drive "once it got below $500"
[14:58:50] <skunkworks_> I remember when drives came down to a $1 a MB...
[14:58:50] <SWPadnos> heh
[14:58:50] <cradek> SWPadnos: for a year or two we installed scsi seagate baraccudas in all our customer machines. it seems like they all failed, every last one
[14:59:03] <skunkworks_> cradek: yikes
[14:59:10] <cradek> I remember my disgust whenever I'd see the ugly fish on it
[14:59:27] <SWPadnos> oh, I've had problems with them, but they do seem to have had fewer time periods when they made crappy drives
[14:59:31] <skunkworks_> well there you go.. It doesn't seem to matter...
[14:59:48] <SWPadnos> or maybe they were just longer ago, so I don't remember them as well now :)
[15:00:10] <cradek> yeah this was a long time ago. 2G drives I think.
[15:00:54] <SWPadnos> oh, I forgot Micropolis! I've still got several 4.xx GB SCSI drives from them, which are mostly failed
[15:00:57] <cradek> ST32550N. I have one here.
[15:01:00] <SWPadnos> I wonder if it's time to toss them
[15:01:38] <cradek> I have a full height 1G seagate SCSI in my AT. it still works fine. Those big ones never died, they just got louder and louder
[15:01:54] <SWPadnos> heh, lke the ST4096
[15:01:57] <skunkworks_> my experience started with the 9gb drves
[15:02:05] <SWPadnos> 80MB, 5.25" full height drive
[15:03:47] <cradek> http://www.computermuseum.li/Testpage/HardCard20MB1980s.jpg
[15:03:55] <cradek> my first hard disk (I think)
[15:03:57] <SWPadnos> I remember those
[15:04:27] <cradek> for the last few years of its life, I had to pull it from the machine and beat it on the bottom of my shoe to get it to spin up
[15:04:31] <cradek> once it was running it was fine, of course
[15:05:05] <SWPadnos> the old stiction problem
[15:06:04] <SWPadnos> reminds me of one time I visited the computer club at my old high school, a year or two after graduating
[15:07:05] <skunkworks_> http://cgi.ebay.com/SEAGATE-ST410800WD-9GB-SCSI-68PN-WIDE-DIFF-DRIVE-TESTED_W0QQitemZ330024263037QQcmdZViewItem?_trksid=p3286.m20.l1116
[15:07:08] <SWPadnos> the staff advisor was teaching the club folks how to fix the hard drives in the macs they had, which consisted of disassembling the computer, removing the hard drive, giving it a quick "flick" to loosen the platters, and then reassembling the computer
[15:07:35] <SWPadnos> I then showed them my technique, which was to grab the entire computer, give it a quick flick, and turn on the power
[15:07:38] <cradek> duh, you just have to spin the computer
[15:07:46] <cradek> amateurs
[15:07:47] <SWPadnos> yep
[15:08:12] <SWPadnos> there was another time when he was telling them how to connect a modem to a mac "you plug the cable into the picture of a telephone"
[15:08:40] <SWPadnos> quite a departure from the club I had co-founded, where we did things like assemble robot kits, have programming contests, and desing/build memory expansions
[15:08:58] <SWPadnos> (for the Vic-20, of course ;) )
[15:44:15] <skunkworks_> I have rapped a hardrive on the table to get the platters to start spinning..
[15:48:52] <cradek> http://cvs.linuxcnc.org/cvs/emc2/src/emc/task/emccanon.cc.diff?r1=1.84;r2=1.85
[15:49:03] <cradek> this really makes me wonder if he knew what he was doing
[15:50:06] <jepler> you considered e-mailing him?
[15:50:13] <jepler> he may have had something subtle in mind that you just can't grasp
[15:50:15] <cradek> I considered badmouthing him on irc
[15:50:34] <cradek> yes possibly. subtle like leaving in that comment
[16:27:19] <skunkworks_> is this the dtg stuff?
[16:29:08] <cradek> no, I'm pondering some stuff about the tool table. but like usual, I don't quite know how it all fits together
[16:29:26] <Lerman__> Lerman__ is now known as Lerman
[16:34:28] <alex_joni> hmm.. you can ask the guy who changed those lines
[16:45:46] <cradek> yeah isn't that funny?
[16:55:37] <alex_joni> I bet the function is called from a place where it's not yet converted
[17:06:52] <SWPadnos> heh: quote from customer review on NewEgg: "Part of my network also includes the garage and I've been pleasently surprised how durable this switch is. The switch out there has survived freezing temps, triple digit temps, getting pee'd on and crapped on by the mice... Any hardware that can take that abuse for a year and keep running full bore gets my vote."
[17:08:50] <alex_joni> well.. I have a switch that outdid that :D
[17:08:55] <SWPadnos> :)
[17:09:19] <SWPadnos> this is a new-ish D-Link 8-port gigabit switch, which is $30 after a $10 rebate
[17:09:20] <alex_joni> had an access point outside, together with a switch inside the box
[17:09:33] <alex_joni> and water dribbled in, until the switch was half under water
[17:09:38] <SWPadnos> heh
[17:09:39] <alex_joni> then the whole thing froze solid
[17:09:46] <alex_joni> -10C outside
[17:09:51] <alex_joni> and it was still running
[17:09:56] <SWPadnos> extreme watercooling
[19:00:34] <cradek> I was pondering making the tool table be reread at every g41/g42/g43 but the layers bite me. the interp could reread it from canon, but canon doesn't have an updated copy until io gets an nml message from somewhere
[19:00:56] <alex_joni> what's the nml message ?
[19:01:13] <alex_joni> firing up dapper here..
[19:01:14] <cradek> Issuing EMC_TOOL_LOAD_TOOL_TABLE -- (+1107,+268, +13,,)
[19:01:40] <cradek> I also want to revive the nml message that writes an entry (I think it's SOMETHING_SET_OFFSET_SOMETHING)
[19:01:56] <cradek> but it has to know something about the two formats of tool table
[19:02:32] <cradek> but that doesn't solve the other problem where I want a gcode to also be able to write to the table
[19:02:53] <cradek> it feels a bit to me like the interp should handle the tool table directly
[19:02:59] <alex_joni> and writing is out of sync again
[19:03:21] <alex_joni> IO is synched to execution, interp is ahead
[19:03:35] <cradek> oh, hm
[19:05:00] <alex_joni> hmm.. this VM is quite fast
[19:05:13] <alex_joni> took me 2 minutes to start it up, cvs up and recompile
[19:09:48] <cradek> I guess the gui could do a save-and-move. send the message to write the new entry, then issue the new g43
[19:10:57] <cradek> except you can have tool 1 loaded and have offset H2, which should you reload?
[19:14:07] <alex_joni> can you back up a bit, and explain what you're trying to do
[19:14:12] <alex_joni> * alex_joni feels a bit lost :)
[19:14:34] <cradek> you mean I should decide what I want before I start trying to implement it?
[19:15:12] <alex_joni> yeah, I know it sounds insane
[19:15:30] <cradek> yeah that's just crazy-talk
[19:16:47] <cradek> I guess I want a bunch of things
[19:17:09] <cradek> I'd like an easy way to tweak a tool table entry and immediately see the coordinates change
[19:17:28] <alex_joni> in manual/mdi?
[19:17:33] <cradek> this probably involves a full gui tool table editor
[19:18:07] <cradek> I don't care really. something less obscure than G10L1P2X ... because you really have to know the old value
[19:19:18] <micges> tool table editor could be great
[19:19:42] <cradek> the common operation is like "subtract .001 from the loaded tool's X setting"
[19:20:02] <cradek> or maybe the loaded offset, not the loaded tool (but often they are the same)
[19:21:25] <alex_joni> subtract temporarly?
[19:21:28] <alex_joni> or for a run?
[19:21:31] <alex_joni> or forever?
[19:21:39] <cradek> forever, write the new value to the tool table
[19:21:45] <alex_joni> (tools is something I stayed away until now :)
[19:22:14] <cradek> on a lathe it seems like you have to mess with them constantly
[19:23:24] <micges> cradek: yes you have
[19:24:13] <micges> we have fanuc cnc lathe and tool table is deeply hidden in interface, its sucks
[19:24:44] <cradek> the secondary goal is something that would be nice - even during a program run, whenever you encounter g41/g42/g43, read the latest value from the tool table (or gui), get rid of the explicit 'reload tool table'
[19:28:46] <cradek> hm, looks like F6 is free in AXIS (and F4). It would be cool to have a tool table tab
[19:29:32] <micges> I think F6 would be good
[19:30:36] <jepler> tkemc.tcl:bind . <KeyPress-F4> {emc_mode auto}
[19:30:36] <jepler> tkemc.tcl:bind . <KeyPress-F6> {emc_task_plan_init}
[19:31:00] <cradek> they don't send any message...
[19:31:01] <micges> oh
[19:31:12] <jepler> (just looking what tkemc does with the same keys)
[19:31:12] <cradek> oh ykrmv
[19:31:14] <cradek> oh tkemc
[19:31:29] <alex_joni> heh, off by one
[19:31:48] <cradek> we need a gui named ykrmv
[19:33:12] <alex_joni> lets rename the one from issy
[19:33:23] <alex_joni> ykrmv sounds better anyways
[19:46:57] <pmbdk> Is there a "default" way to debug realtime HAL components? Poor-mans-debugger such as a realtime equivalent of printf would do it for me right now
[19:47:07] <alex_joni> printk
[19:47:26] <alex_joni> otoh, you can configure emc2 for simulation, and debug components with a regular debugger
[19:47:34] <alex_joni> but that doesn't work for drivers
[19:47:41] <alex_joni> try rtapi_print
[19:49:39] <pmbdk> thank! :)
[19:49:43] <pmbdk> s
[21:59:11] <steve_stallings> steve_stallings is now known as steves_logging
[22:14:30] <jepler> hm, spotted an odd behavior -- after a probe in mdi, dtg isn't reset
[23:26:23] <jmkasunich> regarding tool table stuff
[23:26:50] <jmkasunich> 30 seconds of thought into this, but... why not have the tool table as a bunch of #vars
[23:27:08] <jmkasunich> with a M (or G) code that says "write to disk"
