Back
[00:30:07] <fjungclaus__> cradek: jepler: I just comitted my mdi-history changes to axis.py and axis.tcl on TRUNK. PLS give them a try and report problems and/or suggestions to me. Good night. Frank
[00:30:24] <jepler> fjungclaus__: thank you and good night
[00:31:22] <fjungclaus__> Hmmm. CIA didn't recognized the changes to axis.py ... maybe CIA is tired, too :)
[00:31:41] <SWPLinux> I got one CIA message and two commit mesasges
[00:31:45] <SWPLinux> so it's half asleep
[00:32:44] <fjungclaus__> Any easy way to become informed about changes to the repository by emails!?
[00:33:08] <jepler> fjungclaus__: yes, there's an e-mail list
[00:33:11] <fjungclaus__> ooopppsss: Is there any easy way to become informed about changes to the repository by emails?
[00:33:28] <jepler> https://lists.sourceforge.net/lists/listinfo/emc-commit
[00:33:35] <fjungclaus__> And how to subscribe to this list
[00:33:48] <fjungclaus__> I'm too slow on typing :-)
[00:34:14] <fjungclaus__> TNX for info
[00:35:44] <fjungclaus__> CU
[00:35:48] <fjungclaus__> fjungclaus__ is now known as fjungclaus-away
[00:45:56] <jepler> jmkasunich: you've mentioned a better way of estimating speed of an encoder, based on the time that the pulses was seen (as opposed to the current method, pulses per slow thread)
[00:46:27] <jepler> jmkasunich: if there are a lot of fast threads per pulse, this will be good, but if there are few then it won't be very high resolution
[00:46:44] <jmkasunich> not true
[00:46:50] <SWPLinux> it's more suited for hardware, which has a fixed and accurate period
[00:46:51] <jepler> jmkasunich: do you switch between the two strategies, or something else I haven't considered yet?
[00:47:12] <SWPLinux> (or at least something with very high resolution timestamps)
[00:47:16] <jmkasunich> for each edge, you capture the time and increment a count
[00:47:38] <jmkasunich> the next edge overwrites the time and increments the count
[00:47:57] <jmkasunich> iin the slow thread you capture and store a count/time pair
[00:48:07] <jmkasunich> in the next slow thread, you capture and store another pair
[00:48:23] <jmkasunich> velocoty = (count1-count2)/(time1-time2)
[00:48:34] <jepler> ah ok
[00:49:38] <jepler> this will still suck for less than 1 count per slow thread
[00:49:42] <jepler> reading 0 sometimes and nonzero sometimes
[00:49:42] <jmkasunich> yes
[00:49:52] <jepler> no good for 1 PPR spindle speed, for instance
[00:49:53] <SWPLinux> also reversals need extra logic
[00:50:00] <jmkasunich> but the original method sucks just as much
[00:50:15] <jmkasunich> SWPLinux: reversals don't need extra logic
[00:50:24] <SWPLinux> 1 PPR spindle is fine, since the count is the exact time for one revolution
[00:50:29] <jmkasunich> counts is assumed to be bidirectional the difference can have any sign
[00:50:35] <SWPLinux> it just averages over a full revolution ...
[00:51:00] <jmkasunich> yeah, it always averages over the period between the two events that you captured in the slow thread
[00:51:11] <jepler> ok, then how do I ever know the spindle has stopped?
[00:51:19] <jmkasunich> ;-)
[00:51:37] <SWPLinux> ah right, the timestamp isn't a delta, it's absolute
[00:51:52] <jmkasunich> dealing with less than 1 count per slow thread is interesting (but no worse than the old approach)
[00:52:15] <jmkasunich> if you haven't seen a count in 10 slow threads, does that mean you stopped? or just that you are running at 1 count per 12 slow threads?
[00:52:18] <jmkasunich> no way to tell
[00:52:34] <SWPLinux> any resolution encoder can't tell you the spindle has stopped, just that it hasn't moved far enough to see an encoder edge
[00:52:40] <jmkasunich> exactly
[00:53:01] <SWPLinux> so the 0.00001 IPM example of Jon's is a problem :)
[00:54:01] <jepler> now what to do about the fact that I need to get 2 variables atomically, count and time?
[00:54:19] <SWPLinux> from an FPGA, or the HAL issue?
[00:54:19] <jmkasunich> depends on what you are getting them with
[00:54:32] <jepler> I'm thinking software encoder here
[00:54:47] <jepler> storing 16 bits of each probably suffices in that case
[00:54:48] <jmkasunich> the driver (or component if you are doing it all in software) needs to "deal" with that
[00:55:14] <jmkasunich> for SW, you need to communicate atomically between the capture function and the count function
[00:55:20] <SWPLinux> true - the canonical encoder interface has a velocity output
[00:55:26] <jmkasunich> both part of the same driver, so they are free to use tricks
[00:55:32] <SWPLinux> (or at least a delta)
[00:55:51] <jepler> SWPLinux: yes -- jmkasunich saw that and complained that it was naive
[00:55:56] <jepler> now I wanna fix it
[00:56:01] <SWPLinux> ah
[00:56:06] <jmkasunich> double buffer, for example, the capture routine switches a pointer to a struct that contains both time and count
[00:56:24] <jmkasunich> you have two structs, the high speed funct writes into the one that the poiinter is pointing at
[00:56:40] <jmkasunich> the capture funct changes the pointer, then reads the old struct
[00:57:01] <SWPLinux> are there guarantees that aslow funct can't interrupt a fast one? (it seems to me there are ...)
[00:57:27] <jmkasunich> yes, HAL threads use speed based priority
[00:57:28] <SWPLinux> that would lead to lockup, I guess (since BASE_PERIOD must be too small)
[00:57:36] <jmkasunich> (there's a name for that, can't remember it)
[00:57:40] <jmkasunich> rate monotonic scheduling I think
[00:58:04] <SWPLinux> hmmm - rate monotonic means "fixed period"
[00:59:15] <jmkasunich> http://en.wikipedia.org/wiki/Rate-monotonic_scheduling
[00:59:26] <jmkasunich> "Static priorities assigned according to the rate monotonic principle (tasks with shorter periods/deadlines are given higher priorities)"
[01:00:11] <jmkasunich> HAL may not be doing everything that article describes as rate monotonic scheduling
[01:00:24] <jmkasunich> but it uses the "faster thread = higher priority" principle
[01:01:40] <SWPLinux> interesting, thanks. I was looking at the generic meaning of the words, not the specific application to RT systems
[01:01:56] <jmkasunich> actually, HAL/RTAPI does satisfy all four of the conditions listed at the top of the article
[01:02:22] <jmkasunich> "no resource sharing" is met because all HAL data transfers are atomic, no locking is ever used by the RT code
[01:04:20] <jepler> uh oh
[01:04:20] <jepler> jmk is going to lart me
[01:04:26] <jmkasunich> lart?
[01:04:32] <jepler> luser attitude readjustment tool
[01:04:41] <jmkasunich> what did you do?
[01:05:17] <jepler> I think that when I added the velocity output from encoder.c I got it wrong with respect to atomic transfer
[01:05:36] <jmkasunich> the existing velocity?
[01:05:49] <jmkasunich> I don't see how, because that one only looks at one variable
[01:06:18] <jepler> to get the right value over index pulses, I had to make 'raw_count' not reset at index
[01:06:30] <jepler> velocity is difference between counts over time
[01:06:36] <jmkasunich> http://en.wikipedia.org/wiki/Image:LART.png
[01:06:40] <jmkasunich> thwack!
[01:06:56] <jepler> but to do that I introduced another variable, last_index_count
[01:07:06] <jepler> which is set by the fast thread and read by the slow thread, like raw_count
[01:07:25] <jmkasunich> oh, and subtracted from raw_count?
[01:07:50] <jepler> *(cntr->count) = raw_count - cntr->last_index_count;
[01:07:50] <jepler> yes
[01:08:30] <jepler> raw_count = cntr->raw_count;
[01:08:30] <jepler> *(cntr->count) = raw_count - cntr->last_index_count;
[01:08:38] <jepler> meant to paste both lines
[01:08:51] <jmkasunich> I was wondering why no cntr-> on raw_count
[01:09:31] <jmkasunich> anyway, no lart swinging from me
[01:09:44] <jepler> no?
[01:10:27] <jmkasunich> because when I was doing the encoder man page I looked at encoder.c, specifically checking what you did (because I didn't remember the velocity variable being there)
[01:10:32] <jmkasunich> and I didn't see any problems
[01:10:44] <jmkasunich> if we both missed it, then I'd have to lart myself too
[01:11:37] <jepler> and so I escape by the skin of my teeth
[01:11:41] <jmkasunich> now that you're raised the issue, there probably are some very low probability but real atomicity issues
[01:11:56] <jmkasunich> with index
[01:12:22] <jmkasunich> probably all info passing from the high speed function to the low speed one should be double buffered
[01:12:59] <jmkasunich> lets see....
[01:13:14] <jmkasunich> phase-A, -B, -Z are used only by the highspeed code
[01:13:53] <jmkasunich> count, pos, vel, pos-scale, etc are only lowspeed
[01:13:58] <jepler> I think that formerly the only data used by both was 'raw_count'
[01:14:51] <jmkasunich> index-ena and Zmask too
[01:15:01] <jmkasunich> (have to refresh my memory on what Z-mask is all about)
[01:15:07] <jmkasunich> I bet its some silly optimization
[01:15:25] <jepler> oh so they are
[01:15:28] <SWPLinux> is that an input to the high speed thread?
[01:16:21] <SWPLinux> if so, then I suspect you're supposed to connect A or B to it, and it will only "see" the index during that phase
[01:16:33] <jmkasunich> Zmask?
[01:16:42] <jmkasunich> no, that is me doing optimization
[01:16:46] <SWPLinux> ok
[01:17:09] <jmkasunich> the problem is that update() in particular is a software implementation of a hardware algorithm
[01:17:21] <jmkasunich> and so I used hardware approaches like masking and such
[01:18:34] <jmkasunich> and I reused the variable "state" too, which confused me even more
[01:20:37] <jmkasunich> the sole purpose of Zmask was to eliminate a conditional branch in the fast routine
[01:20:51] <jmkasunich> dumb
[01:21:11] <cradek> good evening
[01:21:33] <jmkasunich> hi
[01:23:11] <cradek> argh the mouse-pointer-eating rhinoceros cat is here as soon as I sit down to work on something
[01:23:34] <jmkasunich> jepler: update() should NOT clear *(cntr->index_ena), it should only clear Zmask (so Zmask is a slow->fast->slow handshake, slow sets it when index_ena is true, and fast clears it, the slow sees it clear and clears index_ena
[01:23:48] <cradek> too bad there isn't something at the room's entrance that could block her ..... hey wait
[01:23:52] <jmkasunich> either that, or Zmask goes away completely and _only_ fast looks at or clears index_ena
[01:23:53] <fjungclaus__> fjungclaus__ is now known as fjungclaus
[01:24:18] <cradek> hi frank, just building your changes to try now
[01:24:41] <jmkasunich> it looks like raw_count, last_index_count, and timestamp (thats a new one) are the data that needs to be atomicly transferred from fast to slow
[01:25:03] <jmkasunich> struct atomic_data { stuff };
[01:25:14] <jmkasunich> and in the main structL
[02:27:30] <cradek> jepler: is your offer to write g76 documentation still valid?
[02:28:13] <jepler> cradek: yes
[02:28:16] <cradek> yay
[02:28:23] <jepler> I forget, did I try to extort something from you in return?
[02:28:33] <cradek> it's in the final format for at least the start of the 2.1 cycle
[02:28:43] <cradek> luckily I forgot too, if so
[02:28:46] <jepler> darn
[02:28:48] <jepler> I lose
[02:29:06] <cradek> my pitiful idea of documentation is in that gcode file
[02:29:09] <jepler> OK
[02:29:27] <cradek> I bet drawing a picture would help
[02:29:31] <jepler> probably
[02:29:38] <cradek> but I guess you can see pretty well in AXIS what's going on
[02:30:28] <cradek> I don't know if the angled in/out belongs in 2.1 - it's very new, and I have to make this bugfix in HEAD before it works right for inside threads too
[02:31:35] <cradek> either way I'm pretty sure this is the final version for 2.1.0
[02:32:41] <jepler> is this canned cycle always in XZ or does the usual business about active axis apply to g76 as well as g8x?
[02:32:59] <cradek> for right now it's only in XZ
[02:33:39] <cradek> it's only for untapered threads along Z
[02:34:13] <jepler> I'll probably have to ask you a lot of questions about this before I can write good documentation
[02:34:24] <cradek> that's fine
[02:34:49] <cradek> it's only for the simplest, commonest thread, which helps (maybe one picture will be adequate)
[02:34:58] <jepler> is g76 x- or y- an error?
[02:35:36] <cradek> unfortunately I think there are probably a lot of GIGO cases right now - that's one of them
[02:35:51] <cradek> I really need to identify them all
[02:36:28] <jepler> If I write in the documentation "it is an error if", I don't care whether the interpreter will actually signal the error at this time
[02:36:31] <jepler> just that it's nonsense
[02:36:43] <jepler> can you tell me what a "drive line" is?
[02:37:12] <jepler> is it typically outside the material ?
[02:37:15] <cradek> it's the move outside the material along the thread
[02:37:17] <cradek> yes
[02:37:27] <Nicolas35LA> Hi all, is there a text mode (command line or other) utility to send mdi commands in EMC2
[02:37:42] <cradek> Nicolas35LA: yes, it's named mdi
[02:37:52] <jepler> it's part of the emc2-axis package
[02:38:25] <cradek> jepler: if you load g76 in axis you can see the bottom horizontal cyan line is the drive line
[02:38:26] <Nicolas35LA> thanks, so ther is actually a unix mdi executable or script
[02:38:31] <cradek> yes
[02:38:36] <Nicolas35LA> thank You
[02:38:57] <jepler> it is actually a python script
[02:39:05] <Nicolas35LA> cool
[02:39:18] <Nicolas35LA> must axis be downloaded separately?
[02:39:45] <jepler> if you followed the regular installation instructions for emc2 on ubuntu, it should be included
[02:39:50] <cradek> it's a separate package (for the 2.0 release family) but typically they are installed together
[02:40:10] <Nicolas35LA> ok, I am compiling my own on a debian install
[02:40:38] <cradek> you'll probably want to build and use emc 2.1 then, which has AXIS included
[02:40:51] <cradek> the official 2.1.0 release is due any day now
[02:41:26] <Nicolas35LA> sounds good
[02:41:58] <jepler> "
[02:41:59] <jepler> A thread is defined by its "drive line", which is a line outside the material that defines the thread. The "drive line" goes from the initial location to the Z- value specified with G76."
[02:42:38] <cradek> the thread is defined by a line that defines the thread?
[02:42:51] <jepler> oops
[02:42:54] <jepler> I can't even write one sentence
[02:42:59] <cradek> :-)
[02:43:08] <cradek> other than that, yes
[02:43:18] <jepler> "A thread is defined by its "drive line", a safe line outside the thread material. The "drive line" goes from the initial location to the Z- value specified with G76"
[02:43:36] <cradek> I suppose the drive line only describes/defines the start and end of the thread
[02:44:07] <cradek> the full description of the thread geometry includes the depths ijk
[02:44:22] <cradek> and p (pitch) I guess
[02:44:49] <cradek> everything else is just details about how the machine should cut it
[02:45:21] <jepler> The Z extent of the thread is the same as the Z extent of the drive line
[02:45:32] <cradek> right
[02:50:57] <jepler> If I select "constant depth" digression, what is the change in depth (X) for each pass?
[02:51:13] <cradek> j
[02:51:33] <cradek> the last one may be smaller to meet the target of course
[02:51:48] <jepler> oh -- so it would be i, i+j, i+2j, ..., last
[02:52:03] <cradek> actually the first cut is i+j but yes
[02:52:34] <jepler> and if digression is 2.0, then it's i+j, i+j+??, i+j+??+???, ..., last
[02:52:44] <cradek> yes
[02:52:51] <jepler> digression > 2.0 would be "decreasing area"
[02:53:01] <cradek> yes
[02:53:27] <cradek> and 1 > r > 2 is increasing area, but less increase than constant depth
[02:53:48] <jepler> presumably the material has been turned to a radius matching 'i' before the threading pass
[02:53:56] <cradek> yes
[02:54:55] <cradek> and "last" is i+k
[02:58:35] <jepler> "compound slide angle"
[02:59:10] <jepler> "
[02:59:11] <jepler> The "compound slide angle" is the angle (in degrees) between successive thread starts. Typical values are 29, 29.5 or 30."
[02:59:23] <jepler> that doesn't make sense
[03:00:04] <cradek> do you know what it does?
[03:00:05] <jmkasunich> why not?
[03:00:34] <jmkasunich> it does lack info about which way the "compound" is pointing (toward headstock or tailstock)
[03:00:59] <jepler> cradek: I see the angle of about 30 degrees but I understand only vaguely what the purpose of it is, and I don't think what I wrote and pasted above explains it
[03:01:00] <cradek> and how to measure the angle
[03:01:25] <jmkasunich> jepler: you are correct, that text assumes a machinist already familiar with manual threading
[03:01:26] <cradek> jepler: if you cut straight in, (compound 0) you cut on both side of the tool and it digs in
[03:01:29] <jmkasunich> it could be better
[03:01:52] <cradek> jepler: if you cut at compound 30, only the leading side of the tool cuts
[03:02:03] <jepler> so a value of -29.5 might be used if you're cutting the "other direction"?
[03:02:03] <cradek> so you pick 29 so the trailing side doesn't "rub"
[03:02:14] <jmkasunich> basically, if you cut on both sides of the V tool, the two chips flow off the tool toward each other, and pile up
[03:02:22] <cradek> g76 converts the angle properly so you can always say 29
[03:02:24] <jmkasunich> if you cut on only one side, the chip is free to flow better
[03:02:45] <jmkasunich> cradek: that explanation of 29 sounds backwards
[03:02:56] <jmkasunich> with 30, in theory the trailing edge just touchers
[03:02:58] <jmkasunich> touches
[03:03:07] <cradek> yes just touches, which is bad
[03:03:09] <cradek> you want it to cut a bit
[03:03:10] <jmkasunich> with 29, the trailing edge takes a tiny shaving cut
[03:03:21] <cradek> if that's not what I said, it's what I meant
[03:03:24] <jmkasunich> ok,
[03:03:43] <jmkasunich> you said "doesn't rub" which I meant as "has some airspace"
[03:03:46] <cradek> ah
[03:03:52] <jmkasunich> which I _read_ as...
[03:03:59] <cradek> no if you use greater than 30 (airspace) you will get a distorted thread
[03:04:03] <jmkasunich> right
[03:04:17] <cradek> assuming 60 degree tool
[03:04:22] <jmkasunich> yeah
[03:04:27] <cradek> it's tempting to make >30 an error, but that's assuming a lot about the tool
[03:04:31] <jmkasunich> whitworth!
[03:04:37] <jmkasunich> acme!
[03:04:46] <cradek> so I left it as a GIGO case
[03:04:51] <jmkasunich> (although both of those are less then 30)
[03:05:06] <cradek> yeah, not sure what would be greater
[03:05:19] <jmkasunich> some weird thread
[03:05:29] <jmkasunich> who are we to prohibit weird tho
[03:05:44] <cradek> right
[03:05:46] <jepler> Are spring passes at the I- depth?
[03:05:57] <cradek> no spring are at the final depth
[03:06:01] <jepler> oh OK
[03:06:22] <jepler> during the fest demos you did some passes at the thread peak depth -- that's not a spring pass
[03:06:25] <jepler> ?
[03:06:36] <cradek> no, that's an initial turning cut
[03:06:51] <jepler> is H1 one *extra* pass, or two total passes at the last depth?
[03:06:55] <cradek> the theory is the work pushes away from the tool during the cut, so you do several passes at the final depth to give it a chance to "spring" back
[03:07:11] <cradek> H1 is two passes at the last depth. if you want only one (no spring pass) you can program H0
[03:07:35] <cradek> a spring cut is an EXTRA cut at the final depth
[03:08:30] <cradek> (on a manual lathe you can just keep cutting at the final depth until it doesn't seem to be cutting anymore)
[03:09:23] <jepler> using your swarf detector or your spindle load detector?
[03:09:38] <cradek> swarf detector (eyeballs)
[03:10:00] <cradek> well maybe you use the other one too
[03:10:07] <cradek> lots of multifunction detectors
[03:18:26] <jepler> "The "compound slide angle" is the angle (in degrees) of the line that passes through successive thread starts. The number is always positive even if the drive line is towards +Z. Typical values are 29, 29.5 or 30."
[03:19:00] <jmkasunich> is that true?
[03:19:03] <jmkasunich> (always positive)
[03:19:18] <jepler> that's what cradek said
[03:19:33] <jepler> 21:02:22 <cradek> g76 converts the angle properly so you can always say 29
[03:19:42] <jmkasunich> usually if you are threading right hand threads (travel towards headstock) the compound also advances towards the headstock
[03:19:48] <jepler> cradek: j- and k- are always positive?
[03:19:58] <cradek> +q cuts on the leading side of the tool
[03:20:00] <jmkasunich> if threading left hand, the compount advances towards the tailstock
[03:20:22] <jepler> did I understand wrong?
[03:20:33] <cradek> -q, which you don't want, cuts on the trailing side
[03:21:40] <jmkasunich> the it should say "a positive value cuts on the leading edge of the tool" instead of " The number is always positive even if the drive line is towards +Z."
[03:22:07] <jepler> OK
[03:22:15] <cradek> yeah I like that better
[03:23:12] <jepler> j- and k-: always positive?
[03:23:26] <cradek> yes since they are depths
[03:23:36] <jmkasunich> even for internal threads?
[03:23:38] <cradek> (but neg are accepted silently)
[03:23:48] <cradek> -i makes everything internal
[03:23:52] <jmkasunich> ok
[03:24:09] <cradek> IMO i has a "direction" but jk don't
[03:24:12] <cradek> brb
[03:30:09] <cradek> oops I said it wrong
[03:30:24] <cradek> +i is internal since the drive line is - from the work
[03:30:40] <cradek> -i means the work is to the - of the drive line (external threads)
[03:30:54] <jepler> what if the tool is on the far side of the material?
[03:31:31] <cradek> if x ~ r, outside threads are always going to be -i
[03:32:05] <cradek> (no matter where the tool is)
[03:32:12] <jmkasunich> what if somebody decides to mount a threading tool at the back of the lathe and the turning tool in front
[03:32:20] <cradek> if x ~ -r, I suppose outside would be +i, but that's an odd setup
[03:32:58] <cradek> jmkasunich: since there's no provision for reversing X when you change tools, they'll have to keep in mind the signs
[03:33:28] <cradek> (I think jepler shouldn't worry about that)
[03:33:34] <jmkasunich> ok
[03:35:06] <SWPadnos> heh - trying to figure out what you guys are saying is a very interesting exercise
[03:35:17] <jepler> yes I'm also trying to figure out what I'm saying
[03:35:28] <SWPadnos> I understand all the words, but that's as far as it goes
[03:35:35] <jepler> PORK!
[03:35:39] <jepler> g76 p.05 z-.5 i.075 j-.015 k.045 h3 r2.0 q29.5
[03:35:49] <jepler> axis dies at 100%CPU trying to load this
[03:36:03] <cradek> did you update in the last hour or so?
[03:36:22] <jepler> notice that j is negative
[03:36:33] <jepler> er -- oops, I updated but ran something else :-P
[03:36:34] <cradek> right - I think that's one of the things I fixed
[03:36:42] <cradek> haha I've done that a thousand times
[03:36:53] <cradek> actually I usually forget to compile
[03:37:09] <jepler> I did worse than that -- I was running an installed ~alpha1
[03:37:40] <cradek> yayyy, you're writing documentation AND testing
[03:38:30] <jepler> * jepler waits for another dpkg-buildpackage
[03:41:52] <cradek> I should test g2[01] + g76
[03:42:07] <cradek> pretty sure it works right, since I was cutting 1/4-20 on my metric lathe
[03:42:30] <jepler> * jepler waits for another dpkg-buildpackage
[03:42:40] <jepler> at least they're only a couple minutes apiece, even with the docs
[03:43:10] <SWPadnos> it would be so much easier for a lathe bonehead like me to say "1/4-20x1.75"
[03:43:35] <SWPadnos> or use a tap/die
[03:44:44] <skunkworks> Mmmmm rigid tapping...
[03:45:04] <SWPadnos> I tend to get quite rigid after lots of tapping
[03:45:13] <jmkasunich> TMI
[03:45:32] <SWPadnos> sicko
[03:45:33] <cradek> SWPadnos: G76 1/4-20x1.75
[03:45:39] <jepler> hum wth?
[03:45:40] <jepler> open("/dev/rtai_shm", O_RDWR) = -1 ENOENT (No such file or directory)
[03:45:46] <jepler> I'm on 'sim' -- why's it trying to do this?
[03:46:04] <SWPadnos> cradek, yep, that's my kind of G-code
[03:46:17] <SWPadnos> assuming that I get 1.75" of 1/4-20 thread from it
[03:46:47] <jepler> * jepler waits for another dpkg-buildpackage
[03:46:50] <cradek> jepler: my sim package works
[03:46:58] <jepler> my previous one did too
[03:51:48] <cradek> jmkasunich: do you think jepler needs to say that if the start of the thread is not out of the material, you need to cut a notch because the tool pauses there? I'm thinking for instance of cutting a lefthand thread where you can't start off the material
[03:52:18] <jmkasunich> do you have entry and exit? or is that a 2.2 thing?
[03:52:29] <cradek> no entry/exit in 2.1.0 at least
[03:52:43] <cradek> it's 90% or more done in trunk
[03:52:58] <jmkasunich> then you need a notch regardless of which way you are going
[03:53:03] <jmkasunich> either an exit notch or an entry notch
[03:53:22] <cradek> yes if you can't start off the end (like g76.ngc does)
[03:53:32] <jmkasunich> you were doing exit ramps at fest
[03:53:39] <cradek> (both notches would be ideal)
[03:53:41] <jmkasunich> what happened?
[03:53:50] <cradek> yes you can always code G33 at any angles by hand
[03:53:53] <jmkasunich> or is this the diff between the canned cycle and handcrafted code
[03:53:54] <jmkasunich> ok
[03:54:30] <cradek> that's why I think g76 doesn't have to do everything under the sun
[03:55:07] <jmkasunich> for 2.1, it should say "the tool will pause briefly both before and after each threading pass, so relief groove(s) may be required at entry and/or exit"
[03:55:10] <jmkasunich> or words to that effect
[03:55:29] <cradek> yes, very good
[03:56:10] <cradek> I think you can often manage without an exit notch - it does not stop there - but it sure can't hurt
[03:56:43] <jmkasunich> it doesn't stop? as in it remains in sync but moves away from the work?
[03:57:02] <cradek> it just rapids out
[03:57:14] <jmkasunich> repeatably?
[03:57:27] <cradek> yeah
[03:57:37] <cradek> FO is disabled for that rapid out
[03:57:45] <jmkasunich> IOW, each rapid starts a little deeper because of your feed, and as it comes out, will it remove no more than the same depth?
[03:57:52] <jmkasunich> in that case, I would revise it
[03:58:16] <jmkasunich> for 2.1, it should say "the tool will pause briefly before each threading pass, so relief a groove may be required at the entry"
[03:58:41] <jmkasunich> if if can do grooveless exit, we shouldn't say otherwise
[03:59:46] <jepler> I don't know if all I've written is accurate, but I'm done for the night
[03:59:53] <cradek> thank you jepler
[03:59:54] <jmkasunich> goodnight
[04:00:05] <cradek> goodnight (for me too)
[04:00:25] <jmkasunich> this encoder thing is tricker than it seems - its definitely gonna be a 2.2 thing
[04:00:42] <jmkasunich> I'm getting there though
[04:00:51] <cradek> jmkasunich: a suitably perverse person could set the spindle override down for the first pass, then back up for the second, which would cause a heavy second outward cut
[04:01:23] <jmkasunich> hmm
[04:01:30] <jmkasunich> doncha just hate perverse people
[04:01:38] <cradek> I could disable spindle override for the whole sequence
[04:02:06] <jmkasunich> thats kinda nasty, because people might want to slow it down to observe, especially the first few passes
[04:02:37] <jmkasunich> exit ramps will solve that, right?
[04:02:43] <cradek> I guess I don't think anything needs to be said/done
[04:02:53] <cradek> yes the ramps solve it nicely
[04:02:54] <jmkasunich> because they ramp out is synced
[04:02:57] <cradek> they are quite cool
[04:03:02] <jmkasunich> s/they/the
[04:03:10] <jmkasunich> I can't type worth crap tonight
[04:03:17] <cradek> yes both ramps are synced
[04:03:40] <jmkasunich> maybe in addition to the former sentence about entry grooves, we need something like
[04:05:06] <jmkasunich> "the exit move is an unsynchronized rapid. If the spindle speed is increased after several passes are complete, subsequent passes may dig in. this can be avoided by providing a relief groove at the exit, or by not changing the spindle speed while threading"
[04:05:23] <jmkasunich> delete that line for 2.2
[04:05:51] <cradek> jepler checked in his writing - would you add that if you're going to be up for a while? I've got to get going
[04:06:06] <jmkasunich> I guess
[04:06:26] <cradek> I'll do it tomorrow otherwise, no problem
[04:06:35] <jmkasunich> actually a few minutes of Lyx might be a good clearing of the head
[04:06:37] <jmkasunich> I'll do it
[04:07:46] <cradek> thank you
[04:09:34] <skunkworks> would you not want to add the option of a ramp in- out?
[04:09:54] <jmkasunich> skunkworks: its not finished yet (at least not well enough to put in the release)
[04:10:00] <skunkworks> ok
[04:12:01] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[05:34:55] <jmkasunich> the new velocity code is written and checked, but untested
[05:35:02] <jmkasunich> I'll test and commit tomorrow
[15:19:23] <rayh> I see that halstreamer and halsampler man pages exist but have not been converted to html and available at linuxcnc.org. Are these not a part of 2.1? Do we need to set up a new link to trunk pages? How often are those pages updated?
[15:21:48] <jepler> let me look into that
[15:21:59] <jepler> the online documentation is updated several times a day
[15:22:03] <cradek> jepler: in lyx how do you do the smart quotes? is it ``...'' like in latex?
[15:22:12] <cradek> or is it ``..."
[15:22:18] <jepler> cradek: just use the " key
[15:22:33] <jepler> cradek: you have to do something unnatural like contrl-" to get a dumb quote
[15:22:33] <cradek> duh
[15:25:11] <rayh> Thanks jepler
[15:29:46] <jepler> rayh: those manpages should now show up in the 2.1 HTML documentation
[15:29:57] <rayh> thanks
[15:31:24] <jepler> this was not a matter of trunk vs branch, but the trunk documentation is also online and updated several times a day.
http://linuxcnc.org/docs/devel/
[15:33:58] <rayh> jepler: got a few minutes to talk about halstreamer?
[15:35:56] <cradek> jepler: thanks for writing that sorely-needed documentation for the threading cycle
[15:36:34] <jepler> rayh: I'm not an expert but I'll try to answer your questions
[15:37:50] <rayh> Im thinking about a hard wired interface panel.
[15:38:03] <jepler> you can see an example of halstreamer use in tests/flipflop.0 -- halstreamer is used to provide the input data for the test
[15:38:35] <rayh> a pic or such outboard prepares status as a serial stream.
[15:39:47] <rayh> sends it to a "file" where streamer reads it to various hal components.
[15:40:25] <jepler> I'm not sure "halstreamer" is the right tool for this
[15:40:36] <rayh> I should have said halstreamer.
[15:40:36] <rayh> Is my thinking way off?
[15:41:12] <cradek> rayh: what will be on the panel?
[15:41:16] <rayh> What is streamer and halstreamer intended for?
[15:42:24] <jepler> rayh: streamer is intended for generating some waveform in userspace and taking the next sample from that waveform each time a HAL thread executes
[15:42:31] <rayh> a bunch of dedicated pushbuttons, jog wheels and such.
[15:42:58] <jepler> it has a FIFO which allows userspace to generate 100 to 1000 samples in advance, so that there is always data available in the realtime thread
[15:43:07] <rayh> A second use, in the opposite direction for serial data would be Modbus to a spindle drive.
[15:43:44] <rayh> Ah.
[15:45:08] <cradek> wonder if EPP over parport would be a good protocol for getting a bunch of IO quickly
[15:45:25] <cradek> serial ports are pretty slow compared to a jogwheel
[15:45:25] <rayh> IMO no
[15:45:57] <rayh> The reason I say that is my early work with PICO stuff.
[15:48:42] <cradek> for jogwheels you need to read them in realtime for it to perform well, so it rules out rs232/usb/etc, this is a hard problem
[15:48:53] <cradek> oop
[15:50:02] <jepler> according to my notes, pluto-servo does 160 bits "in" + 128 bits "out" in around 100uS. that's nearly 3 megabits/second.
[15:50:42] <cradek> wow
[15:50:43] <jepler> cradek: I think ray was talking about a system with an external fpga or microcontroller counting the quadrature and sending counts over the wire to emc
[15:51:11] <cradek> oh I see
[15:51:21] <cradek> so all you need is a count change every servo cycle
[15:51:39] <jepler> 09:38:35 <rayh> a pic or such outboard prepares status as a serial stream.
[15:51:40] <jepler> yeah
[15:51:43] <cradek> but still isn't rs232 too slow for the servo cycle?
[15:51:59] <jepler> iirc, at 115200 baud you can get about 80 bits per direction per 1ms servo cycle
[15:52:02] <SWPadnos> it looked to me like he also wanted buttons or other controls in that packet
[15:52:39] <jepler> you have much more flexibility if you are doing something non-realtime
[15:53:45] <cradek> 80 bits is a lot of buttons I guess
[15:54:14] <cradek> not sure how many bits of count you would need per jogwheel - maybe 6?
[15:54:15] <jepler> for realtime, jmk had a suggestion that involved using one of the outgoing status lines to signify "beginning of packet", so you don't lose any of those precious bits to some crazy synchronization scheme
[15:54:36] <jepler> it depends on the max counts per ms you want to be able to send
[15:54:39] <cradek> sure
[15:54:53] <SWPadnos> if you ise full duplex, then you get 115 bits on the wire, which can be as much as 88 bits each way. but it's a pain to do that and will only work with 16550-class chips (with buffers > 11 bytes)
[15:54:55] <SWPadnos> s/ise/use/
[15:55:22] <SWPadnos> otherwise you have to babysit the serial chip and send out new bytes manually
[15:55:24] <cradek> and anything over 115200 is just asking for trouble
[15:55:30] <SWPadnos> (ie, 10 or 11 times per ms)
[15:55:40] <jepler> it looked like 115200 was the max possible on general hardware
[15:55:56] <cradek> (heck anything over 38400 is asking for trouble)
[15:55:55] <SWPadnos> even 115200 is asking for trouble with anything longer than ~6 feet
[15:56:11] <SWPadnos> especially in a noisy environment
[15:56:28] <cradek> I bet it's better than > 6 feet of EPP though
[15:56:40] <SWPadnos> better but slower ;)
[15:56:45] <cradek> right
[15:56:50] <jepler> that 3 megabit/second EPP rate is 375000 bits per wire-second
[15:57:18] <cradek> I'd still be tempted to use that, even though EPP is a pain on some parports
[15:57:19] <SWPadnos> and that would be faster if it weren't for the silly ISA architacture
[15:58:45] <cradek> there's a reason they used EPP for scanners and quickcams I guess
[15:59:16] <SWPadnos> heh - try using the ASKIR or whatever that high speed IR serial protocol is :)
[15:59:25] <SWPadnos> I think that's in the megabit range
[15:59:50] <cradek> don't walk between me and the computer when I'm trying to jog!
[15:59:55] <SWPadnos> heh
[16:00:06] <SWPadnos> don't let chips fly between you and the conputer ...
[16:11:09] <cradek> logger_dev: bookmark
[16:11:09] <cradek> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2007-01-26.txt
[16:11:24] <cradek> rayh: ^^ we brainstormed a little more in your absence
[16:11:38] <SWPadnos> hmmm. the logger isn't giving the right address
[16:12:14] <SWPadnos> it's here:
http://www.linuxcnc.org/irc/chat.freenode.net:6667/emcdevel/2007-01-26.txt
[16:12:18] <rayh> What did you come up with.
[16:12:59] <SWPadnos> serial is teh sukc ;)
[16:13:46] <cradek> nothing of much value I'm afraid
[16:14:12] <rayh> * rayh reads back
[16:20:07] <rayh> I see pluto servo. Is there an IO version being planned?
[16:20:45] <SWPadnos> there may not be enough IOs to make it worthwhile. also, for industrial uses (ie, things people pay you for), I gather that the pluto isn't the best design
[16:21:22] <rayh> Okay.
[16:21:51] <SWPadnos> Jeff can probably tell you more about that, and I can tell you about using development boards in industrial settings ;)
[16:22:12] <alex_joni> SWPadnos: can you stop the loggers, and restore irc.freenode.net ?
[16:22:13] <rayh> It would be more effective to build a pluto like system with real IO.
[16:22:27] <SWPadnos> alex_joni, I can certainly stop them, dunno about the second part ...
[16:24:39] <jepler> I could do an I/O-only version of the plutos. I think I could give you 35 I/O selectable on a per-bit basis plus 3 dedicated inputs.
[02:27:30] <cradek> jepler: is your offer to write g76 documentation still valid?
[02:28:13] <jepler> cradek: yes
[02:28:16] <cradek> yay
[02:28:23] <jepler> I forget, did I try to extort something from you in return?
[02:28:33] <cradek> it's in the final format for at least the start of the 2.1 cycle
[02:28:43] <cradek> luckily I forgot too, if so
[02:28:46] <jepler> darn
[02:28:48] <jepler> I lose
[02:29:06] <cradek> my pitiful idea of documentation is in that gcode file
[02:29:09] <jepler> OK
[02:29:27] <cradek> I bet drawing a picture would help
[02:29:31] <jepler> probably
[02:29:38] <cradek> but I guess you can see pretty well in AXIS what's going on
[02:30:28] <cradek> I don't know if the angled in/out belongs in 2.1 - it's very new, and I have to make this bugfix in HEAD before it works right for inside threads too
[02:31:35] <cradek> either way I'm pretty sure this is the final version for 2.1.0
[02:32:41] <jepler> is this canned cycle always in XZ or does the usual business about active axis apply to g76 as well as g8x?
[02:32:59] <cradek> for right now it's only in XZ
[02:33:39] <cradek> it's only for untapered threads along Z
[02:34:13] <jepler> I'll probably have to ask you a lot of questions about this before I can write good documentation
[02:34:24] <cradek> that's fine
[02:34:49] <cradek> it's only for the simplest, commonest thread, which helps (maybe one picture will be adequate)
[02:34:58] <jepler> is g76 x- or y- an error?
[02:35:36] <cradek> unfortunately I think there are probably a lot of GIGO cases right now - that's one of them
[02:35:51] <cradek> I really need to identify them all
[02:36:28] <jepler> If I write in the documentation "it is an error if", I don't care whether the interpreter will actually signal the error at this time
[02:36:31] <jepler> just that it's nonsense
[02:36:43] <jepler> can you tell me what a "drive line" is?
[02:37:12] <jepler> is it typically outside the material ?
[02:37:15] <cradek> it's the move outside the material along the thread
[02:37:17] <cradek> yes
[02:37:27] <Nicolas35LA> Hi all, is there a text mode (command line or other) utility to send mdi commands in EMC2
[02:37:42] <cradek> Nicolas35LA: yes, it's named mdi
[02:37:52] <jepler> it's part of the emc2-axis package
[02:38:25] <cradek> jepler: if you load g76 in axis you can see the bottom horizontal cyan line is the drive line
[02:38:26] <Nicolas35LA> thanks, so ther is actually a unix mdi executable or script
[02:38:31] <cradek> yes
[02:38:36] <Nicolas35LA> thank You
[02:38:57] <jepler> it is actually a python script
[02:39:05] <Nicolas35LA> cool
[02:39:18] <Nicolas35LA> must axis be downloaded separately?
[02:39:45] <jepler> if you followed the regular installation instructions for emc2 on ubuntu, it should be included
[02:39:50] <cradek> it's a separate package (for the 2.0 release family) but typically they are installed together
[02:40:10] <Nicolas35LA> ok, I am compiling my own on a debian install
[02:40:38] <cradek> you'll probably want to build and use emc 2.1 then, which has AXIS included
[02:40:51] <cradek> the official 2.1.0 release is due any day now
[02:41:26] <Nicolas35LA> sounds good
[02:41:58] <jepler> "
[02:41:59] <jepler> A thread is defined by its "drive line", which is a line outside the material that defines the thread. The "drive line" goes from the initial location to the Z- value specified with G76."
[02:42:38] <cradek> the thread is defined by a line that defines the thread?
[02:42:51] <jepler> oops
[02:42:54] <jepler> I can't even write one sentence
[02:42:59] <cradek> :-)
[02:43:08] <cradek> other than that, yes
[02:43:18] <jepler> "A thread is defined by its "drive line", a safe line outside the thread material. The "drive line" goes from the initial location to the Z- value specified with G76"
[02:43:36] <cradek> I suppose the drive line only describes/defines the start and end of the thread
[02:44:07] <cradek> the full description of the thread geometry includes the depths ijk
[02:44:22] <cradek> and p (pitch) I guess
[02:44:49] <cradek> everything else is just details about how the machine should cut it
[02:45:21] <jepler> The Z extent of the thread is the same as the Z extent of the drive line
[02:45:32] <cradek> right
[02:50:57] <jepler> If I select "constant depth" digression, what is the change in depth (X) for each pass?
[02:51:13] <cradek> j
[02:51:33] <cradek> the last one may be smaller to meet the target of course
[02:51:48] <jepler> oh -- so it would be i, i+j, i+2j, ..., last
[02:52:03] <cradek> actually the first cut is i+j but yes
[02:52:34] <jepler> and if digression is 2.0, then it's i+j, i+j+??, i+j+??+???, ..., last
[02:52:44] <cradek> yes
[02:52:51] <jepler> digression > 2.0 would be "decreasing area"
[02:53:01] <cradek> yes
[02:53:27] <cradek> and 1 > r > 2 is increasing area, but less increase than constant depth
[02:53:48] <jepler> presumably the material has been turned to a radius matching 'i' before the threading pass
[02:53:56] <cradek> yes
[02:54:55] <cradek> and "last" is i+k
[02:58:35] <jepler> "compound slide angle"
[02:59:10] <jepler> "
[02:59:11] <jepler> The "compound slide angle" is the angle (in degrees) between successive thread starts. Typical values are 29, 29.5 or 30."
[02:59:23] <jepler> that doesn't make sense
[03:00:04] <cradek> do you know what it does?
[03:00:05] <jmkasunich> why not?
[03:00:34] <jmkasunich> it does lack info about which way the "compound" is pointing (toward headstock or tailstock)
[03:00:59] <jepler> cradek: I see the angle of about 30 degrees but I understand only vaguely what the purpose of it is, and I don't think what I wrote and pasted above explains it
[03:01:00] <cradek> and how to measure the angle
[03:01:25] <jmkasunich> jepler: you are correct, that text assumes a machinist already familiar with manual threading
[03:01:26] <cradek> jepler: if you cut straight in, (compound 0) you cut on both side of the tool and it digs in
[03:01:29] <jmkasunich> it could be better
[03:01:52] <cradek> jepler: if you cut at compound 30, only the leading side of the tool cuts
[03:02:03] <jepler> so a value of -29.5 might be used if you're cutting the "other direction"?
[03:02:03] <cradek> so you pick 29 so the trailing side doesn't "rub"
[03:02:14] <jmkasunich> basically, if you cut on both sides of the V tool, the two chips flow off the tool toward each other, and pile up
[03:02:22] <cradek> g76 converts the angle properly so you can always say 29
[03:02:24] <jmkasunich> if you cut on only one side, the chip is free to flow better
[03:02:45] <jmkasunich> cradek: that explanation of 29 sounds backwards
[03:02:56] <jmkasunich> with 30, in theory the trailing edge just touchers
[03:02:58] <jmkasunich> touches
[03:03:07] <cradek> yes just touches, which is bad
[03:03:09] <cradek> you want it to cut a bit
[03:03:10] <jmkasunich> with 29, the trailing edge takes a tiny shaving cut
[03:03:21] <cradek> if that's not what I said, it's what I meant
[03:03:24] <jmkasunich> ok,
[03:03:43] <jmkasunich> you said "doesn't rub" which I meant as "has some airspace"
[03:03:46] <cradek> ah
[03:03:52] <jmkasunich> which I _read_ as...
[03:03:59] <cradek> no if you use greater than 30 (airspace) you will get a distorted thread
[03:04:03] <jmkasunich> right
[03:04:17] <cradek> assuming 60 degree tool
[03:04:22] <jmkasunich> yeah
[03:04:27] <cradek> it's tempting to make >30 an error, but that's assuming a lot about the tool
[03:04:31] <jmkasunich> whitworth!
[03:04:37] <jmkasunich> acme!
[03:04:46] <cradek> so I left it as a GIGO case
[03:04:51] <jmkasunich> (although both of those are less then 30)
[03:05:06] <cradek> yeah, not sure what would be greater
[03:05:19] <jmkasunich> some weird thread
[03:05:29] <jmkasunich> who are we to prohibit weird tho
[03:05:44] <cradek> right
[03:05:46] <jepler> Are spring passes at the I- depth?
[03:05:57] <cradek> no spring are at the final depth
[03:06:01] <jepler> oh OK
[03:06:22] <jepler> during the fest demos you did some passes at the thread peak depth -- that's not a spring pass
[03:06:25] <jepler> ?
[03:06:36] <cradek> no, that's an initial turning cut
[03:06:51] <jepler> is H1 one *extra* pass, or two total passes at the last depth?
[03:06:55] <cradek> the theory is the work pushes away from the tool during the cut, so you do several passes at the final depth to give it a chance to "spring" back
[03:07:11] <cradek> H1 is two passes at the last depth. if you want only one (no spring pass) you can program H0
[03:07:35] <cradek> a spring cut is an EXTRA cut at the final depth
[03:08:30] <cradek> (on a manual lathe you can just keep cutting at the final depth until it doesn't seem to be cutting anymore)
[03:09:23] <jepler> using your swarf detector or your spindle load detector?
[03:09:38] <cradek> swarf detector (eyeballs)
[03:10:00] <cradek> well maybe you use the other one too
[03:10:07] <cradek> lots of multifunction detectors
[03:18:26] <jepler> "The "compound slide angle" is the angle (in degrees) of the line that passes through successive thread starts. The number is always positive even if the drive line is towards +Z. Typical values are 29, 29.5 or 30."
[03:19:00] <jmkasunich> is that true?
[03:19:03] <jmkasunich> (always positive)
[03:19:18] <jepler> that's what cradek said
[03:19:33] <jepler> 21:02:22 <cradek> g76 converts the angle properly so you can always say 29
[03:19:42] <jmkasunich> usually if you are threading right hand threads (travel towards headstock) the compound also advances towards the headstock
[03:19:48] <jepler> cradek: j- and k- are always positive?
[03:19:58] <cradek> +q cuts on the leading side of the tool
[03:20:00] <jmkasunich> if threading left hand, the compount advances towards the tailstock
[03:20:22] <jepler> did I understand wrong?
[03:20:33] <cradek> -q, which you don't want, cuts on the trailing side
[03:21:40] <jmkasunich> the it should say "a positive value cuts on the leading edge of the tool" instead of " The number is always positive even if the drive line is towards +Z."
[03:22:07] <jepler> OK
[03:22:15] <cradek> yeah I like that better
[03:23:12] <jepler> j- and k-: always positive?
[03:23:26] <cradek> yes since they are depths
[03:23:36] <jmkasunich> even for internal threads?
[03:23:38] <cradek> (but neg are accepted silently)
[03:23:48] <cradek> -i makes everything internal
[03:23:52] <jmkasunich> ok
[03:24:09] <cradek> IMO i has a "direction" but jk don't
[03:24:12] <cradek> brb
[03:30:09] <cradek> oops I said it wrong
[03:30:24] <cradek> +i is internal since the drive line is - from the work
[03:30:40] <cradek> -i means the work is to the - of the drive line (external threads)
[03:30:54] <jepler> what if the tool is on the far side of the material?
[03:31:31] <cradek> if x ~ r, outside threads are always going to be -i
[03:32:05] <cradek> (no matter where the tool is)
[03:32:12] <jmkasunich> what if somebody decides to mount a threading tool at the back of the lathe and the turning tool in front
[03:32:20] <cradek> if x ~ -r, I suppose outside would be +i, but that's an odd setup
[03:32:58] <cradek> jmkasunich: since there's no provision for reversing X when you change tools, they'll have to keep in mind the signs
[03:33:28] <cradek> (I think jepler shouldn't worry about that)
[03:33:34] <jmkasunich> ok
[03:35:06] <SWPadnos> heh - trying to figure out what you guys are saying is a very interesting exercise
[03:35:17] <jepler> yes I'm also trying to figure out what I'm saying
[03:35:28] <SWPadnos> I understand all the words, but that's as far as it goes
[03:35:35] <jepler> PORK!
[03:35:39] <jepler> g76 p.05 z-.5 i.075 j-.015 k.045 h3 r2.0 q29.5
[03:35:49] <jepler> axis dies at 100%CPU trying to load this
[03:36:03] <cradek> did you update in the last hour or so?
[03:36:22] <jepler> notice that j is negative
[03:36:33] <jepler> er -- oops, I updated but ran something else :-P
[03:36:34] <cradek> right - I think that's one of the things I fixed
[03:36:42] <cradek> haha I've done that a thousand times
[03:36:53] <cradek> actually I usually forget to compile
[03:37:09] <jepler> I did worse than that -- I was running an installed ~alpha1
[03:37:40] <cradek> yayyy, you're writing documentation AND testing
[03:38:30] <jepler> * jepler waits for another dpkg-buildpackage
[03:41:52] <cradek> I should test g2[01] + g76
[03:42:07] <cradek> pretty sure it works right, since I was cutting 1/4-20 on my metric lathe
[03:42:30] <jepler> * jepler waits for another dpkg-buildpackage
[03:42:40] <jepler> at least they're only a couple minutes apiece, even with the docs
[03:43:10] <SWPadnos> it would be so much easier for a lathe bonehead like me to say "1/4-20x1.75"
[03:43:35] <SWPadnos> or use a tap/die
[03:44:44] <skunkworks> Mmmmm rigid tapping...
[03:45:04] <SWPadnos> I tend to get quite rigid after lots of tapping
[03:45:13] <jmkasunich> TMI
[03:45:32] <SWPadnos> sicko
[03:45:33] <cradek> SWPadnos: G76 1/4-20x1.75
[03:45:39] <jepler> hum wth?
[03:45:40] <jepler> open("/dev/rtai_shm", O_RDWR) = -1 ENOENT (No such file or directory)
[03:45:46] <jepler> I'm on 'sim' -- why's it trying to do this?
[03:46:04] <SWPadnos> cradek, yep, that's my kind of G-code
[03:46:17] <SWPadnos> assuming that I get 1.75" of 1/4-20 thread from it
[03:46:47] <jepler> * jepler waits for another dpkg-buildpackage
[03:46:50] <cradek> jepler: my sim package works
[03:46:58] <jepler> my previous one did too
[03:51:48] <cradek> jmkasunich: do you think jepler needs to say that if the start of the thread is not out of the material, you need to cut a notch because the tool pauses there? I'm thinking for instance of cutting a lefthand thread where you can't start off the material
[03:52:18] <jmkasunich> do you have entry and exit? or is that a 2.2 thing?
[03:52:29] <cradek> no entry/exit in 2.1.0 at least
[03:52:43] <cradek> it's 90% or more done in trunk
[03:52:58] <jmkasunich> then you need a notch regardless of which way you are going
[03:53:03] <jmkasunich> either an exit notch or an entry notch
[03:53:22] <cradek> yes if you can't start off the end (like g76.ngc does)
[03:53:32] <jmkasunich> you were doing exit ramps at fest
[03:53:39] <cradek> (both notches would be ideal)
[03:53:41] <jmkasunich> what happened?
[03:53:50] <cradek> yes you can always code G33 at any angles by hand
[03:53:53] <jmkasunich> or is this the diff between the canned cycle and handcrafted code
[03:53:54] <jmkasunich> ok
[03:54:30] <cradek> that's why I think g76 doesn't have to do everything under the sun
[03:55:07] <jmkasunich> for 2.1, it should say "the tool will pause briefly both before and after each threading pass, so relief groove(s) may be required at entry and/or exit"
[03:55:10] <jmkasunich> or words to that effect
[03:55:29] <cradek> yes, very good
[03:56:10] <cradek> I think you can often manage without an exit notch - it does not stop there - but it sure can't hurt
[03:56:43] <jmkasunich> it doesn't stop? as in it remains in sync but moves away from the work?
[03:57:02] <cradek> it just rapids out
[03:57:14] <jmkasunich> repeatably?
[03:57:27] <cradek> yeah
[03:57:37] <cradek> FO is disabled for that rapid out
[03:57:45] <jmkasunich> IOW, each rapid starts a little deeper because of your feed, and as it comes out, will it remove no more than the same depth?
[03:57:52] <jmkasunich> in that case, I would revise it
[03:58:16] <jmkasunich> for 2.1, it should say "the tool will pause briefly before each threading pass, so relief a groove may be required at the entry"
[03:58:41] <jmkasunich> if if can do grooveless exit, we shouldn't say otherwise
[03:59:46] <jepler> I don't know if all I've written is accurate, but I'm done for the night
[03:59:53] <cradek> thank you jepler
[03:59:54] <jmkasunich> goodnight
[04:00:05] <cradek> goodnight (for me too)
[04:00:25] <jmkasunich> this encoder thing is tricker than it seems - its definitely gonna be a 2.2 thing
[04:00:42] <jmkasunich> I'm getting there though
[04:00:51] <cradek> jmkasunich: a suitably perverse person could set the spindle override down for the first pass, then back up for the second, which would cause a heavy second outward cut
[04:01:23] <jmkasunich> hmm
[04:01:30] <jmkasunich> doncha just hate perverse people
[04:01:38] <cradek> I could disable spindle override for the whole sequence
[04:02:06] <jmkasunich> thats kinda nasty, because people might want to slow it down to observe, especially the first few passes
[04:02:37] <jmkasunich> exit ramps will solve that, right?
[04:02:43] <cradek> I guess I don't think anything needs to be said/done
[04:02:53] <cradek> yes the ramps solve it nicely
[04:02:54] <jmkasunich> because they ramp out is synced
[04:02:57] <cradek> they are quite cool
[04:03:02] <jmkasunich> s/they/the
[04:03:10] <jmkasunich> I can't type worth crap tonight
[04:03:17] <cradek> yes both ramps are synced
[04:03:40] <jmkasunich> maybe in addition to the former sentence about entry grooves, we need something like
[04:05:06] <jmkasunich> "the exit move is an unsynchronized rapid. If the spindle speed is increased after several passes are complete, subsequent passes may dig in. this can be avoided by providing a relief groove at the exit, or by not changing the spindle speed while threading"
[04:05:23] <jmkasunich> delete that line for 2.2
[04:05:51] <cradek> jepler checked in his writing - would you add that if you're going to be up for a while? I've got to get going
[04:06:06] <jmkasunich> I guess
[04:06:26] <cradek> I'll do it tomorrow otherwise, no problem
[04:06:35] <jmkasunich> actually a few minutes of Lyx might be a good clearing of the head
[04:06:37] <jmkasunich> I'll do it
[04:07:46] <cradek> thank you
[04:09:34] <skunkworks> would you not want to add the option of a ramp in- out?
[04:09:54] <jmkasunich> skunkworks: its not finished yet (at least not well enough to put in the release)
[04:10:00] <skunkworks> ok
[04:12:01] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[05:34:55] <jmkasunich> the new velocity code is written and checked, but untested
[05:35:02] <jmkasunich> I'll test and commit tomorrow
[15:19:23] <rayh> I see that halstreamer and halsampler man pages exist but have not been converted to html and available at linuxcnc.org. Are these not a part of 2.1? Do we need to set up a new link to trunk pages? How often are those pages updated?
[15:21:48] <jepler> let me look into that
[15:21:59] <jepler> the online documentation is updated several times a day
[15:22:03] <cradek> jepler: in lyx how do you do the smart quotes? is it ``...'' like in latex?
[15:22:12] <cradek> or is it ``..."
[15:22:18] <jepler> cradek: just use the " key
[15:22:33] <jepler> cradek: you have to do something unnatural like contrl-" to get a dumb quote
[15:22:33] <cradek> duh
[15:25:11] <rayh> Thanks jepler
[15:29:46] <jepler> rayh: those manpages should now show up in the 2.1 HTML documentation
[15:29:57] <rayh> thanks
[15:31:24] <jepler> this was not a matter of trunk vs branch, but the trunk documentation is also online and updated several times a day.
http://linuxcnc.org/docs/devel/
[15:33:58] <rayh> jepler: got a few minutes to talk about halstreamer?
[15:35:56] <cradek> jepler: thanks for writing that sorely-needed documentation for the threading cycle
[15:36:34] <jepler> rayh: I'm not an expert but I'll try to answer your questions
[15:37:50] <rayh> Im thinking about a hard wired interface panel.
[15:38:03] <jepler> you can see an example of halstreamer use in tests/flipflop.0 -- halstreamer is used to provide the input data for the test
[15:38:35] <rayh> a pic or such outboard prepares status as a serial stream.
[15:39:47] <rayh> sends it to a "file" where streamer reads it to various hal components.
[15:40:25] <jepler> I'm not sure "halstreamer" is the right tool for this
[15:40:36] <rayh> I should have said halstreamer.
[15:40:36] <rayh> Is my thinking way off?
[15:41:12] <cradek> rayh: what will be on the panel?
[15:41:16] <rayh> What is streamer and halstreamer intended for?
[15:42:24] <jepler> rayh: streamer is intended for generating some waveform in userspace and taking the next sample from that waveform each time a HAL thread executes
[15:42:31] <rayh> a bunch of dedicated pushbuttons, jog wheels and such.
[15:42:58] <jepler> it has a FIFO which allows userspace to generate 100 to 1000 samples in advance, so that there is always data available in the realtime thread
[15:43:07] <rayh> A second use, in the opposite direction for serial data would be Modbus to a spindle drive.
[15:43:44] <rayh> Ah.
[15:45:08] <cradek> wonder if EPP over parport would be a good protocol for getting a bunch of IO quickly
[15:45:25] <cradek> serial ports are pretty slow compared to a jogwheel
[15:45:25] <rayh> IMO no
[15:45:57] <rayh> The reason I say that is my early work with PICO stuff.
[15:48:42] <cradek> for jogwheels you need to read them in realtime for it to perform well, so it rules out rs232/usb/etc, this is a hard problem
[15:48:53] <cradek> oop
[15:50:02] <jepler> according to my notes, pluto-servo does 160 bits "in" + 128 bits "out" in around 100uS. that's nearly 3 megabits/second.
[15:50:42] <cradek> wow
[15:50:43] <jepler> cradek: I think ray was talking about a system with an external fpga or microcontroller counting the quadrature and sending counts over the wire to emc
[15:51:11] <cradek> oh I see
[15:51:21] <cradek> so all you need is a count change every servo cycle
[15:51:39] <jepler> 09:38:35 <rayh> a pic or such outboard prepares status as a serial stream.
[15:51:40] <jepler> yeah
[15:51:43] <cradek> but still isn't rs232 too slow for the servo cycle?
[15:51:59] <jepler> iirc, at 115200 baud you can get about 80 bits per direction per 1ms servo cycle
[15:52:02] <SWPadnos> it looked to me like he also wanted buttons or other controls in that packet
[15:52:39] <jepler> you have much more flexibility if you are doing something non-realtime
[15:53:45] <cradek> 80 bits is a lot of buttons I guess
[15:54:14] <cradek> not sure how many bits of count you would need per jogwheel - maybe 6?
[15:54:15] <jepler> for realtime, jmk had a suggestion that involved using one of the outgoing status lines to signify "beginning of packet", so you don't lose any of those precious bits to some crazy synchronization scheme
[15:54:36] <jepler> it depends on the max counts per ms you want to be able to send
[15:54:39] <cradek> sure
[15:54:53] <SWPadnos> if you ise full duplex, then you get 115 bits on the wire, which can be as much as 88 bits each way. but it's a pain to do that and will only work with 16550-class chips (with buffers > 11 bytes)
[15:54:55] <SWPadnos> s/ise/use/
[15:55:22] <SWPadnos> otherwise you have to babysit the serial chip and send out new bytes manually
[15:55:24] <cradek> and anything over 115200 is just asking for trouble
[15:55:30] <SWPadnos> (ie, 10 or 11 times per ms)
[15:55:40] <jepler> it looked like 115200 was the max possible on general hardware
[15:55:56] <cradek> (heck anything over 38400 is asking for trouble)
[15:55:55] <SWPadnos> even 115200 is asking for trouble with anything longer than ~6 feet
[15:56:11] <SWPadnos> especially in a noisy environment
[15:56:28] <cradek> I bet it's better than > 6 feet of EPP though
[15:56:40] <SWPadnos> better but slower ;)
[15:56:45] <cradek> right
[15:56:50] <jepler> that 3 megabit/second EPP rate is 375000 bits per wire-second
[15:57:18] <cradek> I'd still be tempted to use that, even though EPP is a pain on some parports
[15:57:19] <SWPadnos> and that would be faster if it weren't for the silly ISA architacture
[15:58:45] <cradek> there's a reason they used EPP for scanners and quickcams I guess
[15:59:16] <SWPadnos> heh - try using the ASKIR or whatever that high speed IR serial protocol is :)
[15:59:25] <SWPadnos> I think that's in the megabit range
[15:59:50] <cradek> don't walk between me and the computer when I'm trying to jog!
[15:59:55] <SWPadnos> heh
[16:00:06] <SWPadnos> don't let chips fly between you and the conputer ...
[16:11:09] <cradek> logger_dev: bookmark
[16:11:09] <cradek> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2007-01-26.txt
[16:11:24] <cradek> rayh: ^^ we brainstormed a little more in your absence
[16:11:38] <SWPadnos> hmmm. the logger isn't giving the right address
[16:12:14] <SWPadnos> it's here:
http://www.linuxcnc.org/irc/chat.freenode.net:6667/emcdevel/2007-01-26.txt
[16:12:18] <rayh> What did you come up with.
[16:12:59] <SWPadnos> serial is teh sukc ;)
[16:13:46] <cradek> nothing of much value I'm afraid
[16:14:12] <rayh> * rayh reads back
[16:20:07] <rayh> I see pluto servo. Is there an IO version being planned?
[16:20:45] <SWPadnos> there may not be enough IOs to make it worthwhile. also, for industrial uses (ie, things people pay you for), I gather that the pluto isn't the best design
[16:21:22] <rayh> Okay.
[16:21:51] <SWPadnos> Jeff can probably tell you more about that, and I can tell you about using development boards in industrial settings ;)
[16:22:12] <alex_joni> SWPadnos: can you stop the loggers, and restore irc.freenode.net ?
[16:22:13] <rayh> It would be more effective to build a pluto like system with real IO.
[16:22:27] <SWPadnos> alex_joni, I can certainly stop them, dunno about the second part ...
[16:24:39] <jepler> I could do an I/O-only version of the plutos. I think I could give you 35 I/O selectable on a per-bit basis plus 3 dedicated inputs.
[16:35:13] <alex_joni> logger_dev: bookmark
[16:35:13] <alex_joni> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2007-01-26.txt
[16:35:47] <alex_joni> ok, this might have worked :)
[16:37:27] <rayh> Each pluto would have 35 IO?
[16:38:02] <jepler> by my count, yes
[16:38:54] <jepler> right now I don't have any support for multiple boards, either on different parports or chained on the same port, so "each" is maybe not a word to use.
[16:39:04] <alex_joni> does anyone mind if I bump to alpha2 ?
[16:39:11] <alex_joni> * alex_joni wants to build new packages
[16:39:22] <jepler> go right ahead
[16:40:39] <rayh> I confess to being ignorant of the pluto stuff.
[16:40:50] <rayh> Is there any doc on it?
[16:40:53] <alex_joni> it takes up a parport
[16:41:09] <SWPadnos> http://www.fpga4fun.com/
[16:41:27] <SWPadnos> near the bottom on the left - pluto-p
[16:41:32] <rayh> I've read a bit of the fpga4 stuff a while back.
[16:41:43] <rayh> I was wondering how we implement it.
[16:41:44] <alex_joni> http://cvs.linuxcnc.org/cvs/emc2/docs/src/hal/pluto_servo.html?rev=HEAD;content-type=text%2Fhtml
[16:41:54] <SWPadnos> ah
[16:42:31] <SWPadnos> jepler, have you done much with the pluto connected via cable?
[16:42:34] <alex_joni> http://linuxcnc.org/docs/devel/html/man/man9/pluto_servo.9.html
[16:43:05] <jepler> SWPadnos: for cradek's lathe there's a 6' or 8' cable to the pluto
[16:43:32] <jepler> SWPadnos: we didn't notice any problems that seemed to be due to noise on the pluto-PC link
[16:46:16] <SWPadnos> ok. just wondering if it had been tried
[16:46:45] <SWPadnos> it's only ~18 ns of delay for a 6' cable, so I wouldn't expect any timing issues
[16:46:53] <SWPadnos> and IEEE1284 cables are shielded
[16:51:03] <alex_joni> dpkg -l | grep emc2
[16:51:03] <alex_joni> ii emc2 2.1.0~alpha2 PC based motion controller for real-time Lin
[16:51:32] <SWPadnos> ux
[16:51:48] <alex_joni> too much for dplg :D
[16:51:53] <SWPadnos> heh
[16:51:59] <alex_joni> dpkg even
[16:52:23] <SWPadnos> You may be able to get rid of the "PC based" art - it's probably obvious for those using Ubuntu ;)
[16:52:27] <SWPadnos> s/art/part/
[16:53:21] <alex_joni> or just have RT instead of real-time :D
[16:54:12] <alex_joni> works quite well..
[16:54:23] <SWPadnos> could imply RTLinux though ...
[16:54:25] <alex_joni> it even created the proper ~/emc2/nc_files folder
[16:55:26] <SWPadnos> yay
[16:55:30] <SWPadnos> !
[16:55:44] <alex_joni> even the desktop shortcut it created works great
[16:56:05] <alex_joni> SWPadnos: where is your stepper quick info?
[16:56:33] <SWPadnos> it's pretty sad right now, but it's in docs/src/lyx/quickstart/
[16:57:16] <alex_joni> * alex_joni looks
[16:57:22] <SWPadnos> * SWPadnos hides
[16:58:34] <rayh> so if everyone's hiding who's it.
[16:58:43] <alex_joni> dpkg -l | grep emc2
[16:58:43] <alex_joni> ii emc2 2.1.0~alpha2 PC based motion controller for real-time Lin
[16:58:43] <SWPadnos> ray's it!
[16:58:53] <alex_joni> aargh
[16:58:55] <SWPadnos> heh
[16:59:03] <alex_joni> pesky lyx and copy
[16:59:14] <alex_joni> "The second number, "0", is needed for other types of motor systems, but can't be left out for steppers."
[16:59:22] <alex_joni> are you sure about that?
[17:00:18] <alex_joni> it runs just fine without the second 0
[17:02:26] <SWPadnos> ok. I guess emc doesn't read it - only some of the UIs (and few of those as well)
[17:02:35] <alex_joni> actually it gets read by HAL only, and afaik parameter subsitution doesn't work for FOO= 1 2
[17:03:19] <SWPadnos> it must, since the sample configs use it, and the second number is there in all of them (I think)
[17:03:39] <alex_joni> it works, but it only takes the first variable
[17:03:58] <SWPadnos> right
[17:04:05] <alex_joni> I'm tempted to remove the second 0 from all the configs
[17:04:29] <cradek> now's the time
[17:04:41] <alex_joni> I only see AXIS reading that value
[17:04:53] <alex_joni> and xemc
[17:04:59] <SWPadnos> 'd love to see it go
[17:05:02] <SWPadnos> +I
[17:05:03] <jepler> if AXIS barfs without that second zero I'll fix it right away
[17:05:08] <alex_joni> * alex_joni goes to work
[17:05:48] <jepler> but I think that the split()[0] means "discard everything after the first whitespace" and works without any space
[17:08:47] <alex_joni> I'll test it on a config with AXIS in a sec.
[17:12:06] <SWPadnos> just to be sure - the offset functionality that the second number provides is still available, even though it's almost always unused ???
[17:12:23] <alex_joni> no
[17:12:36] <alex_joni> there are configs that need an offset for the DAC's
[17:12:50] <alex_joni> but they use a second variable OUTPUT_SCALE / OUTPUT_OFFSET
[17:12:52] <SWPadnos> well, given enough complexity added to .hal files, you can do it ...
[17:12:59] <SWPadnos> ok
[17:13:06] <alex_joni> at least mazak does that
[17:13:11] <SWPadnos> that's good enough. it's there in some other form
[17:13:15] <alex_joni> I think stg/vti/motenc do too..
[17:13:21] <alex_joni> I'll check to be sure
[17:13:36] <SWPadnos> or as a hal sum + some other ini var if you relly needed it
[17:35:13] <alex_joni> jepler: no need to touch AXIS
[17:48:53] <jepler> alex_joni: good! thanks for testing that
[17:49:13] <alex_joni> rest feels safe too
[17:49:18] <alex_joni> commiting now
[17:49:28] <alex_joni> * alex_joni would feel more confident if others test it too
[17:51:21] <SWPadnos> gotta love it when you spam-limit CIA :)
[17:51:35] <alex_joni> spam-limit ?
[17:52:07] <SWPadnos> err - flood ?
[17:52:23] <jepler> argh the g76 graphic doesn't show up in the HTML docs :(
[17:52:45] <SWPadnos> it gets slowed down because it tries to send too many messages at once
[17:52:48] <cradek> aw crap
[17:53:02] <cradek> I was going to start hitting refresh soon
[17:54:38] <jepler> cradek: easy enough to look at the epsi or dxf file, or view the pdf
[17:55:08] <jepler> I wish all the latex2html converters weren't such crap
[18:46:10] <Guest920> Guest920 is now known as skunkworks
[19:01:19] <rayh> I'm testing 2.1 alpha2 on a emc-live install without all the packages upgraded.
[19:01:29] <alex_joni> ooh.. nice
[19:02:03] <rayh> and it wants to upgrade a bunch of them. Is that necessary or just an artifact of the way alpha2 was compiled?
[19:02:51] <alex_joni> if you apt-get update then it will want to upgrade all possible packages
[19:03:07] <alex_joni> this is not because of the alpha2 package, but rather because APT works that way
[19:03:28] <rayh> No I just asked it to install emc
[19:03:33] <rayh> upgrade emc
[19:03:59] <alex_joni> how?
[19:04:52] <rayh> it is also upgrading gcc3.4, refblas3, libg2c0, lappack3, python 2.4 imaging and numarray
[19:05:02] <rayh> synaptic
[19:05:15] <alex_joni> gcc3.4 ?
[19:05:24] <alex_joni> that's odd..
[19:05:39] <rayh> I thought so.
[19:05:43] <alex_joni> seems I have it too
[19:05:53] <alex_joni> gcc, gcc-3.3, gcc-3.4
[19:05:59] <alex_joni> rayh: synaptic updates what's available
[19:06:05] <alex_joni> not necessarely related to emc2
[19:06:19] <rayh> No I just asked for emc upgrade
[19:06:45] <rayh> If I upgraded emc-live it would be more than 100 meg.
[19:06:53] <rayh> which is impossible with my connection.
[19:07:59] <alex_joni> then it probably upgrades emc2 and dependencies
[19:08:24] <rayh> I don't even know what refblas3 is?
[19:08:49] <alex_joni> refblas3 - Basic Linear Algebra Subroutines 3, shared library
[19:09:13] <rayh> oh okay.
[19:09:44] <alex_joni> no idea where that's from
[19:10:20] <rayh> It got all the downloads and is installing stuff now. I'll soon know.
[19:10:45] <alex_joni> coo
[19:11:29] <rayh> wah. four categories under cnc. Nice.
[19:11:49] <alex_joni> well.. figured it's easier than another submenu for docs
[19:13:00] <rayh> I like it. the quick didn't work. But you talked about that earlier.
[19:13:25] <rayh> I also like it that the sample configs tree is collapsed.
[19:13:34] <alex_joni> quick didn't work?
[19:13:56] <rayh> not here.
[19:14:01] <alex_joni> hmm.. it should have :)
[19:14:04] <alex_joni> * alex_joni checks
[19:14:21] <jepler> python2.4-numarray pulls in gcc3.4 for a reason I don't understand
[19:14:39] <jepler> emc2.1 depends on python2.4-numarray for the "image-to-gcode" program
[19:15:09] <jepler> I think it is also the thing pulling in those other packages you named
[19:15:30] <rayh> Oh yes it did. I had a browser open in another desktop.
[19:15:54] <jepler> $ apt-cache show python2.4-numarray | grep Depends
[19:15:54] <jepler> Depends: python2.4, lapack3 | atlas3-base | liblapack.so.3, refblas3 | atlas3-base | libblas.so.3, libc6 (>= 2.3.4-1), libg2c0 (>= 1:3.4.4-5)
[19:18:03] <jepler> cradek: did you get a chance to look at the g76.dxf / g76.epsi image?
[19:18:37] <cradek> no, updating now
[19:20:03] <rayh> I also like the popup asking if you'd like to make a copy.
[19:20:33] <alex_joni> rayh: there's also a checkbox for make Desktop link
[19:20:47] <alex_joni> I guess that section of the User Manual can get shorter/simpler
[19:20:58] <rayh> The create desktop shortcut made a non-working icon.
[19:21:09] <alex_joni> it worked for me..
[19:21:21] <alex_joni> can you look at what it points?
[19:22:16] <rayh> It is of type folder rather than launcher.
[19:22:31] <alex_joni> that's odd
[19:22:42] <jepler> Type=Application
[19:22:50] <cradek> jepler: "K" is incorrect on the picture
[19:22:53] <jepler> can you open the .desktop file in a text editor and put the contents into pastebin?
[19:23:11] <cradek> I wonder if we could show the thread itself too
[19:23:48] <rayh> sure except that I've not run pastebin at all. got a hint.
[19:23:55] <alex_joni> pastebin.ca
[19:23:58] <alex_joni> www.pastebin.ca
[19:24:22] <jepler> it's a website
[19:25:23] <rayh> That's odd.
[19:26:50] <rayh> I don't see "stepper_inch.desktop in my desktop directory.
[19:27:14] <alex_joni> any .desktop there?
[19:27:25] <rayh> Where else in a ubuntu system might it be?
[19:28:34] <SWPLinux> it must be in ~/Desktop if it shows up on your desktop ...
[19:29:12] <rayh> It shows on the desktop. It says it's an empty file.
[19:30:19] <SWPLinux> "it" being the file browser? you can try catting it in a terminal
[19:30:23] <rayh> Yep an empty file.
[19:30:46] <alex_joni> odd
[19:31:02] <rayh> cat is happy returning nothing.
[19:31:22] <rayh> Now this was a copy of stepper inch from standard configs to my home.
[19:31:35] <alex_joni> can you try again?
[19:31:44] <alex_joni> start emc, check the create desktop shortcut ?
[19:31:58] <alex_joni> * alex_joni has a feeling doing both things (copy the config and creating the link might not work)
[19:33:01] <SWPLinux> hmmm. the trouble is that you don't get the "copy ...?
[19:33:12] <SWPLinux> dialog if you can write to the var file ...
[19:33:33] <SWPLinux> so you never get the opportunity to create a shortcut again once it's copied (right?)
[19:33:34] <rayh> same thing if I change the name of my configurations away from the picker
[19:33:46] <alex_joni> SWPLinux: no
[19:33:55] <rayh> I'll try the copy now.
[19:34:07] <SWPLinux> duh - I only had to look ;)
[19:34:09] <alex_joni> SWPLinux: the create shortcut is a checkbox on the config picker
[19:34:56] <rayh> the copy works as it should.
[19:35:33] <SWPLinux> ok. I don't get the icon, but that's probably because I'm running RIP/SIM
[19:35:36] <rayh> I don't get a working desktop link for either the sample config or the copied config.
[19:36:31] <SWPLinux> ok. this is a stupid question, but you did close emc before double-clicking the desktop shortcut, right? :)
[19:36:39] <alex_joni> do you get a message about Shortcut created ?
[19:38:25] <rayh> Um. EMC wasn't running when I asked for the shortcut.
[19:38:43] <rayh> I get a desktop icon but it is pointing to an empty file.
[19:38:56] <rayh> or named for an ...
[19:39:51] <alex_joni> hmm.. I notice something strange
[19:40:05] <alex_joni> the desktop Icon I created (using the installed package):
[19:40:22] <rayh> That's what I'm doing here also.
[19:40:29] <rayh> Installed package.
[19:40:39] <alex_joni> /home/juve/emc2.1.x/scripts/emc /home/juve/emc2/configs/stepper/stepper_inch.ini
[19:40:46] <alex_joni> that's what the Launcher field says
[19:41:04] <alex_joni> it should have been /usr/bin/emc not /home...
[19:43:50] <rayh> All I get is a completely empty file with the name of the config as the name with .desktop appended.
[19:47:45] <rayh> I'll try installing on another box.
[19:48:55] <alex_joni> jepler: I see there's a variable called HOME in emc.tcl
[19:49:12] <alex_joni> it points to /home/juve/emc2.1.x for the created package..
[19:51:38] <alex_joni> what's emcmkdesktop ?
[19:53:14] <alex_joni> ah-ha
[19:53:22] <alex_joni> that's a script that's not beeing packaged
[19:55:12] <rayh> One more death defying bug squash.
[19:56:15] <alex_joni> yeah, nice catch
[19:56:45] <rayh> wasn't my fault that we caught it. I only found the problem.
[19:58:34] <alex_joni> rayh: testing a fix :)
[19:59:02] <alex_joni> although I'm puzzled how it finds the proper emcmkdesktop script here
[20:01:25] <rayh> The second upgrade wants the same set of additional packages upgraded as well.
[20:01:47] <alex_joni> second upgrade?
[20:07:12] <alex_joni> rayh: works now :)
[20:08:32] <rayh> good.
[20:09:14] <alex_joni> I'll build new packages (still alpha2)
[20:09:25] <alex_joni> you can install the package with dpkg -i
[20:10:02] <rayh> Okay. It takes a long hour to download.
[20:10:17] <alex_joni> it's 6MB
[20:13:04] <rayh> Let me know when you are ready for me.
[20:13:27] <alex_joni> ETA 50 seconds
[20:14:27] <alex_joni> rayh: done
[20:16:10] <jepler> I hate qcad
[20:16:21] <jepler> this is the best that "free software" can do on cad?
[20:16:24] <cradek> from what I've seen that's understandable
[20:16:39] <alex_joni> * alex_joni joins the club
[20:18:50] <fjungclaus-away> fjungclaus-away is now known as fjungclaus
[20:19:34] <fjungclaus> Hi, everybody!
[20:19:54] <alex_joni> hi Frank
[20:20:29] <fjungclaus> Hallo, Alex
[20:21:58] <fjungclaus> What is the planned release date for the upcoming emc version ... all people seems to be busy as a bee here :-)
[20:22:44] <fjungclaus> Found more then 50 emc-commit-messages in my mailbox since last night!
[20:23:19] <cradek> I hope to have it nearly finalized this weekend
[20:23:33] <alex_joni> fjungclaus: end of the month
[20:24:52] <fjungclaus> End of the month sounds far away, but thats next week :-)
[20:25:07] <alex_joni> fjungclaus: yes
[20:29:42] <fjungclaus> cradek: jepler: I didn't get any mail with wiggings about my mdi-history patch. Does that mean it's somehow working or does that mean not yet tested :)
[20:29:55] <cradek> I tried it and I think it looks great
[20:30:22] <cradek> I was surprised at first by how the entries move around (when you invoke an entry, it moves to the bottom)
[20:30:52] <cradek> after a while I understood why you did that
[20:31:09] <rayh> I spoke with Roland earlier today. He was wondering if emc folk want to make formal presentations during the workshop?
[20:31:13] <cradek> (I guess I still have mixed feelings)
[20:31:21] <cradek> but other than that I like it a lot
[20:32:12] <alex_joni> anything else I need except latest TRUNK?
[20:32:13] <fjungclaus> If there's something to improve, don't hesitate to let me know it. I can tolerate criticism ...
[20:33:00] <SWPLinux> rayh: I think it would be good to do some configuration-related sessions
[20:33:24] <cradek> sorry, brb
[20:33:27] <SWPLinux> I think a lot of people are intimidated by the reputation of Linux / EMC as a difficult to configure system
[20:33:56] <alex_joni> how does the history work?
[20:34:22] <alex_joni> I get the following when hitting cursor up in MDI:
[20:34:38] <alex_joni> TCL error in asynchronous code:
[20:34:38] <alex_joni> invalid command name "mdi_up_cmd"
[20:34:38] <alex_joni> while executing
[20:34:38] <alex_joni> "mdi_up_cmd"
[20:34:38] <alex_joni> (command bound to event)
[20:36:47] <fjungclaus> alex_joni: Don't you have def mdi_up_cmd in axis.py??? The binding itself is in axis.tcl and calls mdi_up_cmd in axis.py. So maybe you have the newest axis.tcl, but not yet the newest axis.py???
[20:37:06] <alex_joni> * alex_joni looks
[20:37:21] <fjungclaus> You should have axis.py 1.48
[20:37:47] <alex_joni> I have 1.48
[20:38:05] <alex_joni> and I see the def mdi_up_cmd(*event)
[20:38:41] <fjungclaus> alex_joni: Hmmmm ... does hitting cursor down work or does is emit an error, too?
[20:38:48] <alex_joni> same error
[20:38:53] <alex_joni> well.. mdi_down_cmd
[20:39:04] <awallin> might it be because the history buffer is empty?
[20:39:30] <fjungclaus> awallin: Nice idea. Could have been mine :-) I'll test it ...
[20:40:34] <alex_joni> awallin: I specifically entered 3-4 commands before trying
[20:40:47] <awallin> oh, ok
[20:41:15] <alex_joni> TCL error in asynchronous code:
[20:41:15] <alex_joni> bad listbox index "end - 1 lines": must be active, anchor, end, @x,y, or a number
[20:41:20] <alex_joni> while executing
[20:41:23] <alex_joni> ".top.tabs.fmdi.history see {end - 1 lines}"
[20:41:23] <alex_joni> (command bound to event)
[20:42:00] <fjungclaus> alex_joni: awallin: Just cleared the history with CTRL-M and tested it. But for me it's working ...
[20:42:23] <alex_joni> fjungclaus: what's the file where history gets created ?
[20:44:29] <jepler> as far as I can tell, {end - 1 lines} should be a perfectly valid index in a text widget
[20:44:41] <fjungclaus> alex_joni: fmdi.history !?!?!?!?!? Don't have this here anywhere?
[20:45:03] <jepler> wait: "bad listbox index"?
[20:45:36] <fjungclaus> jepler: Yes, but i changed the text widget to an listbox widget and there should not be an {end -1 lines} anymore. So what code is alex running there?
[20:45:50] <alex_joni> fjungclaus: latest TRUNK
[20:45:56] <alex_joni> I updated 3-4 times now
[20:45:58] <jepler> alex_joni: did you 'make' after you updated?
[20:46:10] <alex_joni> oh
[20:46:17] <alex_joni> * alex_joni tries that :)
[20:46:31] <fjungclaus> :-)
[20:46:40] <alex_joni> thougth you don't make python stuff..
[20:46:56] <fjungclaus> Don't worry ... had the same problem yesterday :-)
[20:47:08] <alex_joni> ok, now it works as it should
[20:47:37] <alex_joni> fjungclaus: it works as I'd expect it to.. nice work
[20:48:48] <fjungclaus> If you find it to confusing, when history members move around, it will be no problem to remove this. I (for myself) am not sure if a history should behave like this ...
[20:49:23] <fjungclaus> But the intention was to always have the lastest used element at the end of the history list
[20:49:22] <jepler> I haven't looked at this yet, but when something is repeated in history I prefer to see it shown multiple times in the history
[20:49:56] <alex_joni> * alex_joni agrees.. bash does it that way too
[20:50:15] <jepler> otherwise the history is not a history -- it doesn't show the actions I did in order
[20:50:22] <alex_joni> there would be another nice thing :)
[20:50:44] <alex_joni> when you start typing it can make a small dropdown with history items that match
[20:50:47] <fjungclaus> jepler: Ok, but e.g. when your history size is only 16 and you 16 time repeat one history element, there history only contains that one element ....
[20:50:49] <alex_joni> like firefox does
[20:52:36] <fjungclaus> jepler: If we still have an endless sized history (like before) your behaviour would probably be the best one. If the history size is limited to small number (like 16 by now), my first implementation would be best
[20:53:14] <fjungclaus> Maybe we've to see what for the history is used.
[20:54:28] <fjungclaus> My way of using it most times is having a number of xy-positions in there, which I have to reach in a quick manner to setup and center my workpieces
[20:54:40] <SWPadnos> is there a specific reason why the history is limited to 16?
[20:54:48] <jepler> why 16 history items, rather than 100 or 1000
[20:55:05] <SWPadnos> it would be great to be able to do something by hand, then save the history as an nc file ...
[20:56:29] <jepler> I don't often use MDI so I also don't know what's best for a user
[20:56:39] <fjungclaus> Ok, the history is of size 1000 and then you have scroll around a lot, when you e.g. need entries number 1 and 2 serveral time and they are not automatically moved to the end ....
[20:56:53] <jepler> I don't want it to turn out to be the thin edge of the "we want a g-code editor" wedge
[20:57:18] <SWPadnos> no - that's not needed
[20:57:38] <SWPadnos> though the idea of running an external editor has come up
[20:58:12] <SWPadnos> on the MDI page, an export button of some sort might be nice (but that's just me brainstorming - I'm not asking for that)
[20:58:24] <alex_joni> yeah, one day it should do CAD and CAM aswell </rant>
[20:58:32] <SWPadnos> heh
[20:58:37] <jepler> alex_joni: that's for input filters to do
[20:58:47] <jepler> image-to-gcode, "gwiz", etc
[20:58:51] <SWPadnos> well, it shouldn't do them, but it should be able to easily talk to other programs that do ...
[20:59:12] <jepler> or if the "other program" is long-lived, it should be using axis-remote.py
[21:00:28] <jepler> e.g., gcam writes /tmp/extremely-nifty.ngc and then executes: axis-remote /tmp/extremely-nifty.ngc
[21:00:48] <jepler> (probably after using axis-remote --ping to make sure axis is running)
[21:03:48] <fjungclaus> I just took a look to how the bash history is working. And interestingly it's exactly working like my implementation. After choosing and executing an old entry, it moved(!) to the end of the history!!!
[21:04:27] <jepler> oh really?
[21:05:26] <fjungclaus> jepler: Take a bash and type history, then change an old entry and again type history ...
[21:05:28] <jepler> I stand corrected
[21:06:00] <SWPadnos> hmmm. if you do !21 twice, it should be the same command ...
[21:06:06] <jepler> http://pastebin.ca/329552
[21:06:38] <SWPadnos> that last history was from up up up enter?
[21:06:41] <SWPadnos> +up
[21:06:43] <jepler> no, I typed the command each time
[21:06:46] <SWPadnos> ah
[21:07:03] <jepler> but history RET UP RET shows 'history' twice the second time
[21:07:12] <jepler> and !! RET shows it three times
[21:07:31] <SWPadnos> right, and !1 should show it again, I think
[21:07:47] <jepler> C-r h RET also adds a 'history' to my history
[21:08:13] <SWPadnos> what if you up-arrow a few times, and change a to ab ?
[21:08:26] <SWPadnos> do you still have a as #3 or 5, and ab as 10 or so?
[21:08:32] <SWPadnos> err - 2 or 4
[21:09:20] <jepler> yes but now I have a "*" next to one line of my history as well
[21:09:23] <jepler> not sure what "*" means
[21:09:36] <fjungclaus> Ok, you're right! The !-command (in contrast to selecting by up/down) doesn't move the entries. It seems to copy
[21:09:46] <jepler> I'm using an old bash on this machine (2.05b.0(1) on redhat 9)
[21:09:52] <jepler> it may be that they've modified some of these behaviors
[21:11:19] <fjungclaus> Here it's GNU bash, version 3.1.17(1)-release (i486-pc-linux-gnu)
[21:12:27] <SWPLinux> with the same bash version (3.blah), if I up-arrow and enter, I get a duplicate
[21:12:31] <SWPLinux> if I up-arrow and edit, I get a duplicate
[21:12:38] <fjungclaus> So what about If i introduce a consecutive number to the history elements. Then we could have an !-command for the mdi-input, too !?
[21:12:40] <SWPLinux> (with the edits, of course)
[21:13:11] <fjungclaus> Or does ! collide with some different meaning in context of g-codes!?
[21:13:19] <SWPLinux> I think that would be confusing to look at (since people didn't type in the number)
[21:14:17] <fjungclaus> SWPLinux: confusing: Indeed. Therefore we would need a listbox with two columns ...
[21:14:31] <jepler> it's probably best to wait and see what users reactions are
[21:14:41] <SWPLinux> but maybe if you type block numbers (N1 N2), then allow the user to recall by those
[21:14:43] <SWPLinux> !N20
[21:14:48] <SWPLinux> or !20 looks for N20 ...
[21:14:57] <alex_joni> ewww
[21:14:57] <SWPLinux> heh
[21:14:58] <jepler> yuck from here too
[21:15:05] <SWPLinux> ok - nevermind ;)
[21:15:12] <alex_joni> assuming things again .. feels bad :D
[21:15:21] <alex_joni> !20 -> G20 ?
[21:15:22] <alex_joni> :D
[21:15:27] <SWPLinux> !way
[21:15:38] <alex_joni> :-!
[21:15:55] <SWPLinux> is that equivalent to -: or :+ ??
[21:16:04] <SWPLinux> (in rpn, of course)
[21:16:08] <fjungclaus> I would not though, that this simple history-changes needs so much discussion :-)
[21:16:27] <SWPLinux> it should be less work to duplicate the entry, I'd think
[21:16:44] <alex_joni> fjungclaus: we have too much time in here
[21:16:45] <SWPLinux> ie, up/down only populate the edit control, and enter adds to the history ...
[21:16:56] <alex_joni> and we usually do this disection to almost everything :D
[21:17:24] <alex_joni> fjungclaus: sometimes it's bad.. but other times it means things are really well thought out
[21:17:52] <fjungclaus> alex_joni: Ok, and next week you can tell all the guys waiting for emc-2.1 who is gulty on the delay: Frank Jungclaus :-) :-)
[21:18:03] <alex_joni> not really
[21:18:05] <alex_joni> this is TRUNK not 2.1
[21:20:11] <jepler> fjungclaus: sometimes sometimes changes get way more discussion than they actually require -- I still haven't actually tested it, but I don't have any serious concerns about this change
[21:20:35] <alex_joni> s/sometimes/most of the times/
[21:20:54] <alex_joni> but it would be boring in here otherwise :)
[21:20:55] <jepler> alex_joni: no, a lot of things go by without any comment
[21:21:10] <alex_joni> I mean of those discussed
[21:21:17] <jepler> alex_joni: yes that's probably true then
[21:21:25] <alex_joni> I agree about the ones that pass bye
[21:21:25] <alex_joni> by
[21:21:45] <jepler> fjungclaus: in fact I am very pleased that you are spending your time to improve AXIS
[21:21:48] <fjungclaus> Ok, as a general consensus, I'll increase the number of elements in the history to a maximum of 1000 and changes moving element to copying the element ...
[21:22:59] <SWPLinux> now hard is it to add a "select all" and/or "copy" operation to the history list?
[21:23:11] <SWPLinux> like right-click / copy
[21:23:28] <alex_joni> SWPLinux: dangerous grounds you're walking on :D
[21:23:36] <SWPLinux> shouldn't be :)
[21:24:08] <fjungclaus> jepler: I using emc since autum 2000 and (as an engineer) I always felt that I have to do something for this nice project.
[21:24:39] <rayh> Hey Frank you have done lot for this project already.
[21:25:12] <fjungclaus> Hi, Ray. Nice to hear you xxxx see you ....
[21:25:39] <rayh> Next time I get over, we must visit and raise a glass.
[21:27:04] <jepler> fjungclaus: you are in Hannover?
[21:27:05] <fjungclaus> SWPLinux: selecting mutiple entries by mouse is no problem ... I'll give it a try ...
[21:27:33] <SWPLinux> fjungclaus: cool. is copy one of the standard operations with that widget?
[21:28:06] <alex_joni> nope..
[21:28:08] <fjungclaus> jepler: Yeah, Hannover. If you've already heard of Xenomai. It's coming from our university here ...
[21:28:24] <alex_joni> fjungclaus: cool..
[21:29:09] <jepler> fjungclaus: I have some friends who studied Architecture in Hannover, and spent a week there a few years ago.
[21:29:22] <fjungclaus> SWPLinux: Not yet. There is no context menu by default. But you (read as I) could create one and bind it it to the the right mouse button
[21:29:32] <SWPadnos> heh - ok
[21:30:45] <fjungclaus> jepler: I already have know some of the architecture students. But this is more then 10 years in the past. Studied there from 1991 to 1997.
[21:31:46] <rayh> * rayh goes to find der grosse shell atlas
[21:32:03] <alex_joni> looking for hannover?
[21:33:25] <jepler> google maps is your friend
[21:33:31] <fjungclaus> jepler: But I'm "only" an electrical engineer. My main focus was on semiconductor technolgy and micro electronics. But I'm working on hard- and software in the area of field-buses, real-time os, embedded systems
[21:33:55] <rayh> fjungclaus: Isn't there There is a train from Hanover to Dortmund?
[21:34:56] <fjungclaus> rayh: Yes. You can travel from Hannover<-> Dortmund using the train (very fast and comfortble by an ICE) or use the "Autobahn" A2
[21:35:40] <alex_joni> jepler: not on dialup
[21:36:00] <fjungclaus> rayh:
http://www.google.de/maps?f=q&hl=en&q=wedemark,+brelingen,+abbauernring&sll=50.092393,10.195313&sspn=37.605507,59.326172&ie=UTF8&z=17&ll=52.554907,9.686648&spn=0.004325,0.010761&t=h&om=1
[21:36:04] <alex_joni> I'll be in Siegen next month :)
[21:36:23] <jepler> alex_joni: good point
[21:36:24] <fjungclaus> alex_joni: What can anyone do there :-)
[21:36:36] <alex_joni> fjungclaus: project meeting
[21:37:38] <jepler> * jepler hopes to travel to Germany in April to visit some friends
[21:37:38] <fjungclaus> alex_joni: AFAIR you're still in the academic business? Am I right!?
[21:37:48] <alex_joni> fjungclaus: not quite :)
[21:38:03] <alex_joni> but this is an EU project..
[21:38:36] <alex_joni> my academic times are over, although I plan to take PhD sometimes in the future
[21:39:00] <alex_joni> s/take/take a/
[21:40:14] <fjungclaus> alex_joni: I now a lot of people having planings about PhD. But if they've started earning money for the first time, they often forget about that target
[21:40:43] <fjungclaus> alex_joni: s/now/know
[21:40:44] <alex_joni> I worked throughout most of my college time..
[21:43:10] <fjungclaus> jepler: travel to Germany!? aren't you located overseas!?
[21:43:57] <jepler> fjungclaus: yes, I live in the states
[21:43:57] <rayh> fjungclaus: That train goes within a half km of my son's home.
[21:44:30] <jepler> fjungclaus: but I have some ties to Germany -- friends and family
[21:45:25] <fjungclaus> rayh: My cousin is also located in the Dortmund area. But I've never been there ...
[21:46:34] <fjungclaus> rayh: Now, as you told it my remembering is coming back. We already talked by email about your son living here in Germany some years before
[21:47:26] <rayh> Right. He sells and services medical xray equipment.
[21:49:29] <fjungclaus> rayh: My company is building field-bus (CAN) components for GE-Medical and Siemens-Medical. But none of them is located in Dortmund (as I think)
[21:49:56] <rayh> He sells Italian equipment.
[21:50:04] <alex_joni> fjungclaus: oooh
[21:50:07] <rayh> and some made in Canada.
[21:50:15] <alex_joni> sounds like something interesting for emc2 ;)
[21:50:25] <fjungclaus> alex: Oooohh what
[21:50:34] <fjungclaus> alex: CAN?
[21:50:38] <alex_joni> * alex_joni loves CAN-based servos
[21:51:38] <rayh> * rayh has some questions about coordinated motion using CAN motors.
[21:51:43] <fjungclaus> One of my last projects I participated was an Ethernet<->CAN-Bus-Gateway for Lenze frequency converters and Lenze Servo-Drives :-)
[21:52:01] <alex_joni> lenze?
[21:52:05] <alex_joni> I know stoeber..
[21:53:07] <fjungclaus> alex_joni: You don't know them. They aren't small :-)
http://www.lenze.de/internet_en_active/020_Products/020_Servo_drives/020_Servomotoren/Produktfamilie_Servomotoren.jsp?cid=0b0164e0800078b1
[21:53:30] <fjungclaus> alex_joni:
http://www.lenze.de/internet_en_active/020_Products/020_Servo_drives/010_Servo_Umrichter/Produktfamilie_Servo_Umrichter.jsp?cid=0b0164e0800078a8
[21:54:33] <fjungclaus> alex_joni: To not be misunderstood: I'm not working there.
[21:55:29] <alex_joni> fjungclaus: nice motors
[21:55:48] <fjungclaus> Ok. Now 11:00PM is coming nearer and I should start continuing to work an the MDI-history ...
[21:56:48] <fjungclaus> alex_joni: Yes they sell very nice stuff and have a good reputation! But it's of the range I can pay for my cnc-hobby.
[21:57:24] <alex_joni> fjungclaus: I understand.. I play with very nice stuff at work.. but also way out of my hobby league :D
[21:57:24] <fjungclaus> alex_joni: But it's out off the range I can pay for my cnc-hobby. I'm typing more and more non-sense stuff here ...
[21:57:51] <alex_joni> fjungclaus: that's ok.. irc is full of nonsense.. we started to understand it :D
[21:59:40] <fjungclaus> alex_joni: :-) BTW, is all the stuff typed in the past on the irc accessible somewhere in the net?
[21:59:57] <jepler> logger_dev: bookmark
[21:59:57] <jepler> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2007-01-26.txt
[22:00:08] <jepler> the logger writes everything down
[22:00:37] <SWPadnos> logger_dev, help
[22:03:07] <fjungclaus> Speechless now ;-)
[22:04:00] <SWPadnos> of course, all this only works when it doesn't get disconnected ... :)
[22:04:51] <alex_joni> and some doesn't even then
[22:05:11] <alex_joni> I never figured out what chump does :D
[22:07:03] <fjungclaus> One last :-) But I think the the emc is one of the more serious ones on irc ...
[22:29:37] <cradek> does everyone think we're still on track to finalize packaging this weekend?
[22:29:44] <alex_joni> * alex_joni sure does
[22:29:57] <cradek> yay that's great
[22:30:06] <cradek> maybe we'll have a release
[22:30:45] <SWPadnos> are there any objections to changing INPUT_SCALE to OUTPUT_SCALE in all the inis (and in the other places where it's needed)?
[22:31:04] <alex_joni> yes
[22:31:11] <SWPadnos> heh - ok :)
[22:31:18] <alex_joni> er.. no objections for TRUNK
[22:31:22] <SWPadnos> ok
[22:31:32] <alex_joni> but for the branch, I think it's too much of a diff
[22:31:37] <SWPadnos> there are only ~6 references in the source tree
[22:31:48] <alex_joni> and there's no way we can test the servo configs now
[22:32:23] <cradek> that would break documentation too
[22:32:25] <SWPadnos> don't the servo HAL files use OUTPUT_SCALE for both input and output ...
[22:32:48] <SWPadnos> err - nevermind. ppmc does, but a true analog servo wouldn't
[22:33:54] <alex_joni> juve@taurus:~/emc2.1.x$ grep -r -e "INPUT_SCALE" * | wc -l
[22:33:53] <alex_joni> 385
[22:34:10] <SWPadnos> that includes documentation and configs
[22:34:10] <alex_joni> juve@taurus:~/emc2.1.x/src$ grep -r -e "INPUT_SCALE" * | wc -l
[22:34:13] <alex_joni> 14
[22:34:25] <SWPadnos> right, and several of those are DEFAULT_INPUT_SCALE
[22:34:40] <SWPadnos> and others (particularly in iniaxis.cc) are in comments, but not used in the code
[22:34:44] <alex_joni> SWPadnos: right, and scripts, and axis, and a couple of other places that need changing
[22:35:03] <alex_joni> it might be a HAL only change
[22:35:04] <SWPadnos> ok - I see it's pretty invasive. it can be done for 2.2/TRUNK
[22:35:05] <alex_joni> + docs
[22:35:28] <alex_joni> but I'm somehow reluctant to do it a couple of days before 2.1.0
[22:35:31] <SWPadnos> I guess one way to test is to change it in one config and see what barfs ... :)
[22:36:18] <alex_joni> * alex_joni is sick of changing configs
[22:36:25] <SWPadnos> heh
[22:36:35] <SWPadnos> at least you're tops on navi.cx now :)
[22:37:02] <cradek> alex_joni: thanks for doing the dirty work
[22:37:02] <alex_joni> I acheived my goal in life
[22:37:09] <rayh> Catch you guys later.
[22:37:28] <cradek> did you guys figure out the problem with the desktop icon?
[22:37:32] <alex_joni> yeah..
[22:37:41] <alex_joni> emcmkdesktop wasn't included in the deb
[22:37:47] <cradek> ah
[22:37:54] <alex_joni> I have no idea how it worked here..
[22:37:58] <cradek> I swear that worked for me...
[22:38:14] <alex_joni> same here.. but it used the one from the 2.1 branch somehow
[22:38:20] <alex_joni> no idea how it found it
[22:38:24] <cradek> hmm
[22:38:30] <cradek> no clue either
[22:38:38] <alex_joni> actually I have a hunch..
[22:38:46] <alex_joni> there is a variable called EMC_HOME
[22:38:57] <alex_joni> which is /home/user/emc2.1/ even in the deb
[22:39:20] <cradek> hmm, that doesn't seem good
[22:39:41] <alex_joni> look at /usr/share/emc/tcl/emc.tcl
[22:40:15] <cradek> variable HOME /usr/local/src/emc2.v2_1_branch
[22:40:31] <alex_joni> well.. if you put it there :D
[22:40:48] <alex_joni> I have: variable HOME /home/juve/emc2.1.x
[22:41:22] <alex_joni> cradek: you did make the package from /usr/local/src/.. right?
[22:42:04] <cradek> yes
[22:42:19] <alex_joni> anyways, still doesn't say why it found emcmkdesktop
[22:48:01] <alex_joni> heh.. "emc -l" is way cool
