#emc-devel | Logs for 2011-11-28

Back
[00:00:23] <tissf> same for me :)
[00:01:29] -!- tissf has quit [Quit: Page closed]
[00:02:48] -!- mhaberler has quit [Quit: mhaberler]
[00:03:03] -!- cevad has quit [Quit: Leaving]
[00:04:21] -!- theorbtwo has quit [Ping timeout: 258 seconds]
[00:04:32] theorb is now known as theorbtwo
[00:20:31] -!- Loetmichel has quit [Ping timeout: 252 seconds]
[00:20:31] -!- ries has quit [Read error: Connection reset by peer]
[00:35:52] -!- FinboySlick has quit [Quit: Leaving.]
[00:36:07] -!- andypugh has quit [Quit: andypugh]
[00:43:56] -!- maximilian_h [[email protected]] has joined #emc-devel
[00:44:19] -!- maximilian_h has quit [Client Quit]
[00:51:44] -!- jsr has quit [Remote host closed the connection]
[01:02:58] -!- jmkasunich has quit [Quit: Leaving]
[01:05:40] -!- mschuhmacher has quit [Ping timeout: 265 seconds]
[01:06:12] -!- zlog has quit [Remote host closed the connection]
[01:06:16] -!- Tom_itx has quit []
[01:13:35] -!- crazy_imp has quit [Ping timeout: 244 seconds]
[01:14:15] -!- H264 has quit [Ping timeout: 260 seconds]
[01:18:32] -!- tlab has quit [Quit: Leaving]
[01:20:18] -!- Valen has quit [Quit: Leaving.]
[01:22:11] -!- Danimal_garage has quit [Read error: Connection reset by peer]
[02:07:14] -!- robh__ has quit [Ping timeout: 252 seconds]
[02:11:16] -!- zlog has quit [Remote host closed the connection]
[02:11:19] -!- Tom_itx has quit []
[02:34:05] -!- ries has quit [Quit: ries]
[02:54:36] -!- kb8wmc has quit [Quit: ChatZilla 0.9.87 [Firefox 3.6.24/20111107173218]]
[02:58:24] -!- mikeggg has quit [Ping timeout: 248 seconds]
[03:05:04] -!- H264 has quit [Ping timeout: 245 seconds]
[03:22:23] -!- A2Sheds has quit [Ping timeout: 248 seconds]
[03:24:09] -!- ve7it has quit [Remote host closed the connection]
[04:43:36] -!- garage_seb [[email protected]] has joined #emc-devel
[04:44:21] -!- psha[work] [psha[work][email protected]] has joined #emc-devel
[04:52:37] -!- sumpfralle has quit [Ping timeout: 240 seconds]
[05:49:46] toastyde1th is now known as toastydeath
[05:52:59] -!- mhaberler [[email protected]] has joined #emc-devel
[06:10:48] -!- garage_seb has quit [Quit: Leaving]
[07:44:54] -!- e-ndy [e-ndy!jkastner@nat/redhat/x-vclwmwhfyccwktoj] has joined #emc-devel
[08:06:44] -!- capricorn_one has quit [Remote host closed the connection]
[08:28:12] -!- danimal_laptop has quit [Read error: Connection reset by peer]
[08:36:47] -!- Thetawaves has quit [Quit: This computer has gone to sleep]
[09:15:04] -!- theorbtwo has quit [Ping timeout: 245 seconds]
[09:15:12] theorb is now known as theorbtwo
[09:48:46] -!- robh__ [[email protected]] has joined #emc-devel
[10:42:29] -!- mhaberler has quit [Quit: mhaberler]
[10:58:12] -!- Turtl3boi has quit [Quit: ChatZilla 0.9.87 [Firefox 8.0.1/20111120135848]]
[11:07:57] -!- mhaberler [[email protected]] has joined #emc-devel
[12:47:01] -!- skunkworks has quit [Remote host closed the connection]
[12:56:31] -!- mschuhmacher [mschuhmacher!5c4b5eb5@gateway/web/freenode/ip.92.75.94.181] has joined #emc-devel
[13:02:09] <CIA-95> EMC: 03jthornton 07v2.5_branch * rf782d77e9d80 10/docs/src/Submakefile: Docs: remove a bit more of Lyx
[13:06:25] -!- psha[work] has quit [Quit: Lost terminal]
[13:13:17] -!- sumpfralle has quit [Ping timeout: 252 seconds]
[13:16:34] <mhaberler> cradek: why did you implement xy_rotation in canon and not in the interpreter?
[13:40:08] -!- psha [[email protected]] has joined #emc-devel
[14:04:59] -!- vladimirek [[email protected]] has joined #emc-devel
[14:11:04] <cradek> mhaberler: it exactly mirrors (ha) the way offsets work
[14:12:00] <mhaberler> was that offsets-in-canon thing in the NIST version already?
[14:12:15] <cradek> yes, it's very old
[14:12:19] <mhaberler> I see
[14:12:30] <mhaberler> let me ask you a very whacky question
[14:12:37] <cradek> I don't know the answer
[14:12:52] <mhaberler> hm… lets see
[14:13:59] <mhaberler> assume ccomp, offsets and rotation were conceptually at the motion stage and corrections/path changes etc happen there (yes I know, kernel and all)
[14:14:20] <mhaberler> in that case it should be a lot easier to pause, change tool/offset & continue
[14:14:32] <cradek> bbl, I will read back after breakfast
[14:14:34] <mhaberler> "just in time"
[14:14:37] <mhaberler> ok, enjoy
[14:30:11] -!- vladimirek has quit [Ping timeout: 255 seconds]
[14:39:46] -!- sumpfralle has quit [Quit: Leaving.]
[14:46:31] -!- ries has quit [Read error: Connection reset by peer]
[15:04:51] <cradek> the most evident flaw in that plan is that cutter comp can't be done JIT because you must know an arbitrary number of future moves to do it
[15:05:43] <mhaberler> ok, let me step back a second. Assume there is 2-stage processing:
[15:06:15] <mhaberler> interp spits out a 'dumb queue' (no offsets, ccomp) but with information to have that applied later
[15:06:53] <mhaberler> between task and interp (conceptually motion and interp) sits a vehicle, lets call her warp
[15:07:23] <mhaberler> warp can apply offests, and do ccomp. she can also correlate a motion command to the corresponding dumb queue entry
[15:08:39] <mhaberler> now, if one were to change offsets or tool geo during feed hold, warp can get the new offsets/tool geo, go back to the corresponding dumb queue entry, and reapply (I'm leaving out the intra-move stop problem for now)
[15:10:05] <mhaberler> what's wrong with the idea?
[15:10:23] <cradek> the hard parts would be 1) deciding what warp could actually do, and what to do in the impossible cases, and 2) actually writing warp
[15:11:39] <cradek> "take a dumb path and just offset it" sounds so easy but it's really quite hard (#2 problem)
[15:11:56] <mhaberler> stab in the dark; do coordinate system offsets, tool geometry, rotation, ccomp path computation
[15:12:20] <cradek> if you let the user change tool size/geometry in the middle of a move (or worse, near a corner) motions that were previously possible become impossible (problem #1)
[15:12:36] <mhaberler> ok, fair enough
[15:12:57] <cradek> #3 - moving more of the complex math into kernel space is a bad idea
[15:13:17] <mhaberler> but that doesnt sound like an emc specific problem
[15:13:28] <mhaberler> re kernel: no math there, I dropped that idea
[15:13:41] <mhaberler> it would be a userland task sitting between dumb and motion queue
[15:14:45] <mhaberler> without in-flight changes to tool/offset/ccomp, the warp output would 1:1 match current canon output
[15:16:00] <mhaberler> if I understand correctly, the 'impossible path (gauging) is now detected in interp_queue.cc
[15:16:36] <cradek> yes gouging
[15:17:06] <cradek> I don't remember the details of how all it's detected without looking
[15:18:02] <cradek> I think you might want to consider doing only entirely possible things instead: for instance hold the queue and read the new cutter dia before each G41/G42
[15:18:27] <cradek> if that's the problem you're trying to solve (changing diameter while program is running)
[15:19:00] <cradek> and for jogging during pause, it's entirely possible to make a coordinated move back to where you were before pausing, then continue
[15:19:18] <mhaberler> well right, that's the 'easy' case
[15:19:45] <cradek> right, what I'm saying is I think what you're proposing instead involves lots of impossible cases
[15:19:54] <mhaberler> I'm not solving the problem.. I try to think through it how it could be done in the most general way
[15:20:04] <mhaberler> impossible due to ccomp?
[15:20:46] <cradek> at least, yes
[15:21:07] <cradek> unless you see the problem of comp differently from how I see it
[15:21:49] <mhaberler> I understand offset curves, but I dont fully understand how its done in emc
[15:21:55] <cradek> fwiw, I also considered moving ccomp into task, so it's separate from the interp.
[15:22:06] <mhaberler> aja
[15:22:17] <mhaberler> what about offsets and rotation?
[15:22:18] <cradek> offsetting curves is easy, finding endpoints is the problem when that's how moves are specified
[15:22:35] <mhaberler> is that the 'chained points' thing?
[15:23:07] <cradek> no, that's for collapsing nearly colinear moves
[15:23:13] <mhaberler> aha
[15:23:30] -!- i_tarzan has quit [Ping timeout: 244 seconds]
[15:23:41] <mhaberler> what does your change (ccomp into task) gain except taking it out of interp?
[15:25:05] <cradek> you could have a different interp more easily, without reimplementing comp, which is probably the most complex part of the current interp
[15:26:32] <cradek> but if you want our gcode interp anyway, moving it to another layer would do no good, but sacrifice all the hard-won stability we currently have
[15:27:49] <mhaberler> I think we can gain a lot by cleaning up the interp so it's instantiable without side effects - which are currently massive
[15:28:19] <cradek> I think we are fundamentally different - you think "what's the biggest restructure I can conceive, which gives us the most future freedom" and I think "what's the most minimal change we can make, which sacrifices the least amount of stability, that solves the problem"
[15:28:36] <cradek> you need both kinds of people on a project
[15:28:49] <mhaberler> again, I am not proposing this, I want to understand how it could be done.
[15:28:56] <cradek> we may currently have the results of a long string of #2 type people :-)
[15:29:45] <mhaberler> yes, but sometimes you reach a point where the next heroic patch drags you into the swamp, not out of it
[15:30:39] <cradek> yes - too many #2 type people can make a program get stuck and never be able to progress further - too many #1 people and you may never have a program that's releasable at all
[15:31:19] <mhaberler> I agree in the absence of planning
[15:31:52] <cradek> we are currently stuck, or we were before psha (#1 type) fixed mdi and you (#1 type) did scriptable tool change, both things we had needed for a long time
[15:32:30] <cradek> so maybe even talking to me about this (#2) is the wrong approach
[15:33:03] <mhaberler> I didnt ask you about which issues you see with the idea.
[15:33:31] <cradek> sure you did: mhaberler> what's wrong with the idea?
[15:34:02] <cradek> (or did I misunderstand something?)
[15:34:11] <mhaberler> delete not, sorry - meant to say 'didnt ask you to do it'
[15:34:28] <cradek> ah I see
[15:34:43] <mhaberler> out of curiosity: lets redo the idea on the level of G-code source-to-source translation (again not a roposal, a thought experiment), and then I'll let you off the hook
[15:34:52] <mhaberler> really whacky.. ok:
[15:34:57] <cradek> heh ok
[15:35:42] <mhaberler> assume a program which has moves but also offset, tool offset, ccomp. can one rewrite the program into another one with conditional execution such that:
[15:36:27] <mhaberler> in the first stage only the moves are processed, but the offset/tool offset/ccomp stuff is retained, as 'canon mdi' which is fed during processing to a second interpreter
[15:36:53] <mhaberler> I'ts the same idea, just at the gcode level - 2 stage processing
[15:37:05] <mhaberler> q: would the output be identical..
[15:37:36] <mhaberler> was that clear enough? (not sure ;-)
[15:38:15] <mhaberler> offsets etc are only applied in stage 2 'canon mdi' processing
[15:38:22] <cradek> yes - but I think the first stage does nothing, the second stage does what our current interp does
[15:38:24] <mhaberler> (postponed)
[15:38:55] <cradek> I guess the text parsing stuff, which is a bit smelly, is in stage 1
[15:39:18] -!- DrNoboto has quit [Ping timeout: 258 seconds]
[15:39:20] <cradek> so ok I'm with you I think
[15:39:52] <mhaberler> plain rs274 parsing. its just offset application, tool offset application, ccomp isnt applied in the interp but passed as a MDI(gcode string) to canon
[15:39:53] <cradek> I can imagine a separation between "read into the block struct" and "make moves based on that"
[15:40:32] <cradek> crap, brb, work
[15:40:46] <mhaberler> g1 x2 y3 would create a STRAIGHT_FEED(…)
[15:40:59] -!- DrNoboto [[email protected]] has joined #emc-devel
[15:41:15] <mhaberler> G43 would create MDI("G43 <params>")
[15:42:04] <mhaberler> as the interplist is run through, the MDI() commands are interpreted
[15:42:19] <mhaberler> this is about making the queue restartable with new offsets
[15:44:14] <mhaberler> since the real canon commands in the queue dont have offsets/ccomp, re running the MDI with new offsets/ccomp "should work" (or not)
[15:45:23] <mhaberler> there would be second interp instance, owned by task, which is just there for doing the MDI() stuff (or redoing it in case we're backing up)
[15:45:58] <mhaberler> back to question 1;-) whats wrong with the idea
[16:08:12] -!- syyl has quit [Client Quit]
[16:13:40] -!- e-ndy has quit [Quit: Ex-Chat]
[16:38:25] -!- automata has quit [Ping timeout: 244 seconds]
[16:42:14] -!- skunkworks [skunkworks!~chatzilla@str-bb-cable-south2-static-6-425.dsl.airstreamcomm.net] has joined #emc-devel
[16:42:40] -!- IchGucksLive [[email protected]] has joined #emc-devel
[17:01:59] -!- e-ndy [[email protected]] has joined #emc-devel
[17:04:55] -!- e-ndy has quit [Client Quit]
[17:05:13] -!- e-ndy [[email protected]] has joined #emc-devel
[17:05:43] <cradek> IchGucksLive: I noticed you sent a zip file of changes to the list. instead, here is some information that will help you share your work with others: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Git#Send_patches_through_e_mail_or_the_web
[17:06:02] <cradek> I think you might get more collaboration and interest if you make it easy for people to see/try your changes
[17:10:12] <mhaberler> looking at the code, that above idea wouldnt currently work because crc is in the interpreter and applied before canon output
[17:11:08] <mhaberler> with your moving 'ccomp to task' idea - did you mean crc or tool offset or coordinate systems or rotation or all of them?
[17:11:15] <IchGucksLive> Ias emc totely rewritten !
[17:19:25] <cradek> well it's tempting to do all
[17:20:18] <cradek> ngc authors originally thought comp would be outside interp (there was a canon call for begin/end radius offset) but they put it in interp.
[17:21:37] <mhaberler> what kind of translation did you consider moving to task?
[17:23:07] <IchGucksLive> cradek: we are working hard to fit your need
[17:25:54] <cradek> mhaberler: I only had the most half-baked of ideas, but it seems like all of offset/rotation/units is too complicated, code needs to be right in many places
[17:26:17] <cradek> I think the basic problem is that interp and canon both have world models that must remain in sync
[17:26:56] <IchGucksLive> cradek: are you talking on my issue ?
[17:27:01] <mhaberler> nein
[17:28:16] <cradek> IchGucksLive: sorry no, mhaberler and I have been discussing interpreter structure today
[17:28:36] <cradek> IchGucksLive: I did have advice for you about using git earlier; I sent you a url
[17:29:12] <mhaberler> well right. the above idea would work iff canon could be independently reexecuted just to apply offsets/coordsys/crc/toolcomp
[17:29:44] <cradek> yes, I guess all you need is (yet) another queue
[17:30:45] -!- cncbasher [cncbasher!~quassel@cpc15-hart9-2-0-cust101.11-3.cable.virginmedia.com] has joined #emc-devel
[17:34:41] <mhaberler> the sharing of wm information could be achieved, but moving all comp to canon is a very big bite
[17:35:24] <mhaberler> maybe we should drop the interp list and just create python method calls instead ;-)
[17:35:24] <cradek> yes
[17:35:45] <cradek> big bite and I'm not sure there's any real reason to do it
[17:36:04] -!- micges [[email protected]] has joined #emc-devel
[17:36:20] <cradek> I removed the interp list and almost had it working again once
[17:36:25] <cradek> it's hardly necessary to have that queue
[17:36:42] <cradek> but queueing mdi moves (which works great today) is very nice and I'd hate to lose it
[17:38:23] -!- DrNoboto has quit [Ping timeout: 252 seconds]
[17:38:57] <mhaberler> that's not what I meant - a queue is needed; I just thought through the 'backing up the queue without different comp/offsets' issue and possibly canon is the wrong abstraction to do this
[17:39:56] <mhaberler> I meant a queue of python commands so operation parameter binding could be delayed
[17:40:02] -!- DrNoboto [[email protected]] has joined #emc-devel
[17:40:11] <cradek> it seems fundamentally possible to discard the queue and recalculate (wherever the queue is - doesn't matter) if you can solve the problem of what to do with the current partially-done move/moves (2 moves in blending case)
[17:41:38] <mhaberler> for linear programs yes; but what with tc/hal input/probe?
[17:41:49] <mhaberler> queuebuster-free I mean
[17:42:00] <mhaberler> those could be redone, yes
[17:42:21] <mhaberler> or at least from after the last qb
[17:42:35] -!- motioncontrol has quit [Quit: Sto andando via]
[17:42:36] -!- Nick001 has quit [Ping timeout: 240 seconds]
[17:42:40] <mhaberler> and replaying canon input after sync :-/
[17:43:05] <cradek> you never have to back up/discard past a queue buster do you? can you explain further?
[17:44:13] <mhaberler> no, assume recalculate (=run program again) and program has a probe/tc/hal input; the output is identical only if probe/hal input/tc delivered the same results after sync()
[17:44:49] <mhaberler> glorified RFL if you will
[17:44:59] <cradek> oh you are assuming you run the program from the beginning again?
[17:45:14] <mhaberler> any other options?
[17:45:49] <cradek> but that's what we have today, with all its problems
[17:46:18] <mhaberler> what did you think of then when backing up?
[17:46:20] <cradek> I thought you were talking about saving state along the way so you could back up and start again from a previous time
[17:47:23] -!- bootnecklad has quit [Ping timeout: 244 seconds]
[17:47:29] <cradek> but you are right, restarting as a way to resume is obviously not sufficient
[17:47:31] <mhaberler> previous time == a certain canon command, or a certain gcode line? I'm thinking canon
[17:47:46] <cradek> I don't know which
[17:49:21] <mhaberler> what I think could work is 'enrich' the canon interface enough so all offset/crc etc application can move from interp to canon; then backing up and replaying the interplist with changed offsets/radius/rotation etc could work
[17:49:22] <mhaberler> +
[17:49:38] <mhaberler> its essentially delaying binding moves and coordinates
[17:51:04] <mhaberler> as I see it rerunning the program is not guaranteed to deliver identical results because of QB's - rerunning such a queue os
[17:51:05] <mhaberler> is
[17:51:08] <cradek> do you realize there are currently two ways to pause/step/resume: the gcode line based one, and the realtime motion queue?
[17:51:14] <mhaberler> yes
[17:51:45] <cradek> are you proposing that you delay binding coordinates (good terminology) until after the realtime motion queue?
[17:52:10] <mhaberler> no, before motion - in phase 2 (warp)
[17:52:20] <mhaberler> motion has no idea
[17:52:39] <mhaberler> except for the intramove/s pause/reentry issue
[17:52:44] <cradek> so motion would discard the realtime queue and refill?
[17:52:51] <mhaberler> yes
[17:52:54] <cradek> ok I see
[17:55:31] <mhaberler> motion needs to receive via the motion queue, and report exact source id (not just sequence_number but also source file) so the canon command can be exactly identified whatever ngc file it came from
[17:55:47] <mhaberler> but that i did - no surprises
[17:57:10] <cradek> I think I know a surprise :-/
[17:57:19] <mhaberler> nay
[17:57:39] <mhaberler> only if delivered with a fix ;-)
[17:57:42] <cradek> o100 repeat [10]; g91 g1 x1; o100 endrepeat
[17:58:01] <cradek> let it queue, pause/step, you'll step over all 10 moves at once
[17:58:42] <cradek> I think your fix cannot fix this, and it is the same symptom of not being able to uniquely identify the canon command
[17:59:23] <cradek> file/line is better than line only but it still might not be enough?
[17:59:34] <mhaberler> let me see.. would these be merged into one move?
[17:59:56] <cradek> well assume that's irrelevant
[18:00:10] <mhaberler> crap, does that really work, multiple commands on a line with semicolon?
[18:00:14] <cradek> (true they might be collapsed in canon, but not always)
[18:00:21] <cradek> no! it's 3 lines of gcode
[18:00:43] <cradek> the point is you get 10 canon calls in a row, all from the same file/line
[18:01:13] <mhaberler> ok, throw in a serial
[18:01:19] <cradek> sorry I gave you multiple distractions from that point
[18:01:26] <mhaberler> no, very valid
[18:01:44] <cradek> add a hash of the whole interp state??
[18:02:38] <mhaberler> I thought about that; I'm currently spinning out exec state, machine state, modal and config into classes; unsure about canon state
[18:03:11] <mhaberler> it's a lot of space if used indiscriminately; but interp roll forward/backwards is an option in theory
[18:03:39] <mhaberler> need to think about that one
[18:04:04] <mhaberler> oh, misread the hash thing
[18:04:30] <mhaberler> a serial should do
[18:04:44] <cradek> "step works surprisingly sometimes" is a current real problem because of move collapsing and line numbers not uniquely identifying the move (step in motion queue just goes until a new saved line number is reached)
[18:05:10] <cradek> please explain serial
[18:05:41] <mhaberler> canon commands need serial numbers; sequence numbers dont uniquely identify them as you said rightly
[18:06:14] <mhaberler> we have a mapping of (file,line) => set of serials
[18:06:52] <cradek> but (file,line) doesn't uniquely identify them either
[18:07:24] <mhaberler> because the execution context (repeat counter) is missing in the equation
[18:07:34] <cradek> yes
[18:07:58] <mhaberler> would you explain a scenario for "step works surprisingly sometimes"?
[18:08:06] <mhaberler> is that motion q stepping?
[18:08:15] <cradek> yes, this exact scenario is the situation
[18:08:18] <mhaberler> or gcode stepping?
[18:08:30] <cradek> motion queue stepping
[18:08:42] <cradek> it steps over all 10 g1 commands coming from my repeat
[18:08:50] <mhaberler> so the step criterium is sequence number
[18:08:58] <mhaberler> duh
[18:09:05] <cradek> or, in the case of colinear collapsing, it steps over an arbitrary number of gcode lines because they became one move
[18:09:10] <mhaberler> aaaaaaargh
[18:09:31] <cradek> sorry :-/
[18:09:53] <mhaberler> so what would be the right thing to do when motion stepping ?
[18:10:18] <mhaberler> step based on canon command?
[18:10:42] <mhaberler> I dont see smaller ghranularity
[18:10:51] <cradek> I really don't know!
[18:10:52] <mhaberler> oh, tp.
[18:11:09] <cradek> I think the user expects it to step one line of gcode
[18:11:37] <cradek> some lines of gcode make many canon calls and many moves
[18:11:42] <mhaberler> an 'executed' line of code, not a 'line on the screen' that is, I guess
[18:12:00] <cradek> also some lines of gcode sometimes make less than one canon call (like collapsed colinear moves)
[18:12:02] <mhaberler> the first would be true for every iteration
[18:13:07] <mhaberler> btw who does motion stepping anyway.. whats the use case except debugging? hop further during pause?
[18:13:10] <cradek> yes I don't think the user wants to step through 10 lines of comments one at a time, but I doubt the user would be too offended
[18:13:44] <cradek> well the user can't pick the kind of stepping, it depends when exactly he pauses which one he gets
[18:14:41] <cradek> pause is used all kinds of ways, program proofing, to clean chips, to move clamps, etc
[18:14:44] <IchGucksLive> how i do find files in emc-dev as im in a terminal at this location example hersey.py
[18:14:56] -!- kb8wmc [[email protected]] has joined #emc-devel
[18:15:18] <cradek> find . -name hershey.py
[18:16:55] <mhaberler> pause and step would be motion pins..? only see program-number; or is it task doing it?
[18:17:09] <archivist> IchGucksLive, or locate hershey.py
[18:17:19] <cradek> UIs send pause/step/resume to task
[18:17:35] <cradek> it's not in hal (except through halui)
[18:17:42] <IchGucksLive> archivist: danke
[18:17:47] <mhaberler> ok, I see
[18:17:56] <cradek> well I'm wrong - motion has feedhold too! but that's not steppable.
[18:18:15] <cradek> bbl, lunch
[18:18:30] <mhaberler> cu
[18:20:08] -!- skunkworks has quit [Read error: Connection reset by peer]
[18:25:29] -!- bootnecklad has quit [Quit: Leaving]
[18:28:34] <cncbasher> kb8wmc: i dont have any problems connecting
[18:30:10] <kb8wmc> hmmm....I get a notice that it is listed as a "phishing site" and am unable to navigate to any of the links on there
[18:31:03] <kb8wmc> now I don't know what to think
[18:31:32] <archivist> kb8wmc, your dns provider is blobking it probably
[18:31:43] <archivist> blocking even
[18:31:47] <cncbasher> kb8wmc: what av software are you using .. is it blocked from your pc etc
[18:32:08] <kb8wmc> yes, that is where the notice is coming from
[18:32:27] <cncbasher> which av are your using
[18:32:46] <kb8wmc> no av software is blocking it
[18:34:04] <kb8wmc> my ISP is now connected somehow with OpenDNS and the notice is from my ISP
[18:35:07] <IchGucksLive> cradek: im now at 4.0 http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Git#Commit_changes
[18:35:23] <IchGucksLive> what is neyt i added all the changed files to emc-dev
[18:35:27] <kb8wmc> hallo IchGucksLive
[18:35:34] <IchGucksLive> kb8wmc: Hi
[18:36:23] <IchGucksLive> kb8wmc: http://www.youtube.com/watch?v=3cbbW7iGjwo
[18:36:36] <kb8wmc> thank you sir
[18:43:16] <IchGucksLive> cradek: ?
[18:46:21] -!- ve7it [[email protected]] has joined #emc-devel
[19:02:44] -!- isssy has quit [Quit: Visitor from www.linuxcnc.org]
[19:13:25] -!- elmo40 has quit [Ping timeout: 260 seconds]
[19:17:59] -!- bootnecklad1 has quit [Ping timeout: 245 seconds]
[19:25:56] -!- IchGucksLive [[email protected]] has parted #emc-devel
[19:32:48] -!- kb8wmc has quit [Quit: ChatZilla 0.9.87 [Firefox 3.6.24/20111107173218]]
[19:39:42] -!- vladimirek [[email protected]] has joined #emc-devel
[19:42:57] -!- vladimirek has quit [Remote host closed the connection]
[19:57:11] -!- vladimirek [[email protected]] has joined #emc-devel
[20:01:41] -!- zlog has quit [Remote host closed the connection]
[20:01:44] -!- Tom_itx has quit []
[20:06:27] -!- vladimirek has quit [Remote host closed the connection]
[20:07:19] -!- vladimirek [[email protected]] has joined #emc-devel
[20:24:44] -!- cncbasher [cncbasher!~quassel@cpc15-hart9-2-0-cust101.11-3.cable.virginmedia.com] has parted #emc-devel
[20:27:36] -!- mschuhmacher has quit [Ping timeout: 265 seconds]
[20:35:47] -!- psha has quit [Quit: Lost terminal]
[20:45:48] -!- vladimirek has quit [Remote host closed the connection]
[20:52:00] -!- elmo40 has quit [Ping timeout: 248 seconds]
[21:17:18] -!- e-ndy has quit [Quit: Ex-Chat]
[21:21:45] -!- elmo40 has quit [Ping timeout: 260 seconds]
[21:41:02] -!- skunkworks [skunkworks!~chatzilla@str-bb-cable-south2-static-6-425.dsl.airstreamcomm.net] has joined #emc-devel
[21:46:42] -!- andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust492.basl.cable.virginmedia.com] has joined #emc-devel
[22:05:42] <JT-Shop> can you give me a little more help?
[22:05:44] <JT-Shop> i ran a search for ini in the manual with no luck.
[22:05:45] <JT-Shop> please tel me what im doing wronge.
[22:05:47] <JT-Shop> i know nothing about linux.
[22:06:00] <JT-Shop> ^^ too many PDF manuals :(
[22:06:46] -!- isssy has quit [Quit: Visitor from www.linuxcnc.org]
[22:07:53] <cradek> http://www.google.com/search?q=emc2+ini
[22:08:05] <cradek> this isn't too entirely helpful either
[22:08:34] <cradek> sure are a lot of emc-related docs on other sites
[22:09:06] -!- FinboySlick has quit [Quit: Leaving.]
[22:12:13] -!- JT-Shop has quit [Read error: Connection reset by peer]
[22:13:28] -!- mhaberler has quit [Ping timeout: 244 seconds]
[22:13:46] -!- micges has quit [Quit: Ex-Chat]
[22:16:17] -!- JT-Shop [[email protected]] has joined #emc-devel
[22:20:13] -!- JT-Shop has quit [Read error: Connection reset by peer]
[22:20:24] -!- JT-Shop [[email protected]] has joined #emc-devel
[22:21:32] <JT-Shop> wow that is a bunch of hits for emc2+ini
[22:25:19] -!- elmo401 has quit [Ping timeout: 248 seconds]
[22:32:13] -!- jthornton has quit [Ping timeout: 240 seconds]
[22:33:57] -!- jthornton [[email protected]] has joined #emc-devel
[22:43:21] -!- jthornton has quit [Ping timeout: 244 seconds]
[22:44:13] -!- JT-Shop has quit [Ping timeout: 244 seconds]
[22:49:31] -!- JT-Shop [[email protected]] has joined #emc-devel
[22:50:19] -!- syyl has quit [Quit: Leaving]
[22:50:37] -!- jthornton [[email protected]] has joined #emc-devel
[22:52:59] -!- Fox_Muldr has quit [Ping timeout: 252 seconds]
[22:56:18] -!- JT-Shop has quit [Ping timeout: 258 seconds]
[22:59:30] -!- JT-Shop [[email protected]] has joined #emc-devel
[22:59:45] -!- jthornton has quit [Ping timeout: 260 seconds]
[23:00:25] -!- kb8wmc [[email protected]] has joined #emc-devel
[23:00:47] -!- jthornton [[email protected]] has joined #emc-devel
[23:05:00] -!- elmo40 has quit [Ping timeout: 260 seconds]
[23:08:14] -!- jthornton has quit [Ping timeout: 244 seconds]
[23:09:03] -!- JT-Shop has quit [Ping timeout: 248 seconds]
[23:19:25] -!- mhaberler [[email protected]] has joined #emc-devel
[23:19:26] <andypugh> I have noticed that you pretty much have to know that the INI file stuff is in "Basic configuration"
[23:22:04] -!- JT-Shop [[email protected]] has joined #emc-devel
[23:23:12] -!- jthornton [[email protected]] has joined #emc-devel
[23:27:32] -!- servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[23:31:17] -!- JT-Shop has quit [Ping timeout: 252 seconds]
[23:31:55] -!- skunkworks has quit [Read error: Connection reset by peer]
[23:33:47] -!- jthornton has quit [Ping timeout: 255 seconds]
[23:43:49] -!- H264 has quit [Ping timeout: 245 seconds]
[23:50:57] -!- acemi has quit [Quit: WeeChat 0.3.2]
[23:53:59] -!- jsr has quit [Remote host closed the connection]
[23:57:14] -!- GoSebGo has quit [Ping timeout: 244 seconds]