Back
[07:22:00] <CIA-35> EMC: 03seb 07TRUNK * 10emc2/docs/man/man9/hostmot2.9: (log message trimmed)
[07:22:00] <CIA-35> EMC: hostmot2 release 0.9:
[07:22:00] <CIA-35> EMC: Fixed stepgen.stepspace, it was not getting set correctly on the FPGA.
[07:22:00] <CIA-35> EMC: Fixed stepgen.position-fb, it was not getting set reported correctly
[07:22:00] <CIA-35> EMC: to HAL.
[07:22:00] <CIA-35> EMC: Added stepgen.maxvel.
[07:22:02] <CIA-35> EMC: Added raw.dump_state, a way to cause hostmot2 to dump its internal
[07:22:06] <CIA-35> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/ (ChangeLog hostmot2.c hostmot2.h raw.c stepgen.c): (log message trimmed)
[07:22:09] <CIA-35> EMC: hostmot2 release 0.9:
[07:22:11] <CIA-35> EMC: Fixed stepgen.stepspace, it was not getting set correctly on the FPGA.
[07:22:13] <CIA-35> EMC: Fixed stepgen.position-fb, it was not getting set reported correctly
[07:22:15] <CIA-35> EMC: to HAL.
[07:22:17] <CIA-35> EMC: Added stepgen.maxvel.
[07:22:19] <CIA-35> EMC: Added raw.dump_state, a way to cause hostmot2 to dump its internal
[12:14:10] <skunkworks> did I see an issue with putting negative scale into the ini?
[12:14:15] <skunkworks> that was fixed
[12:16:13] <skunkworks> http://cia.vc/stats/author/jepler/.message/246ef1
[12:16:41] <skunkworks> http://www.cnczone.com/forums/showthread.php?p=491649#post491649
[12:16:46] <skunkworks> same issue?
[12:33:52] <jepler> skunkworks: it depends what "can't insert a negative number" means. The bug is not that a negative number can't be typed into the window, the bug is that when you enter a negative number it doesn't work right (the axis won't move)
[12:34:06] <jepler> the fix for that problem will be in 2.2.7, and the workaround is to enter all positive numbers and use "invert" on the direction pin
[12:36:06] <skunkworks> ok - I will pass that on.
[12:36:16] <skunkworks> Thanks jepler.
[12:36:37] <jepler> good morning, and you're welcome
[12:37:39] <jepler> I just wish I hadn't fould up stepconf in that way :(
[12:38:18] <skunkworks> oh - so it isn't an ini issue? it is a stepconfig issue?
[12:39:08] <jepler> yes
[12:39:09] <skunkworks> if you manually changed the ini scale to negative - it would work? (yes I know you cannot then go back and use stepconf to make changes)
[12:39:27] <skunkworks> that doesn't seem so bad :)
[12:39:54] <jepler> basically, when stepconf writes a negative SCALE it also ends up writing a negative MAXVELOCITY
[12:40:01] <jepler> er, MAX_VELOCITY
[12:40:06] <skunkworks> I was thinking - boy - that is going to break a ton of configs.
[12:40:08] <skunkworks> ;)
[12:40:15] <skunkworks> ah - ok
[12:46:09] <skunkworks> jepler: what happens if you edit the ini/hal manually and then try to re-run stepconf? do you loose your changes?
[12:46:16] <jepler> no, you lose your changes.
[12:46:22] <skunkworks> heh
[12:53:51] <SWPadnos> no loose changes in *these* inis
[12:55:56] <cradek> yay, that means there will be a 2.2.7 that I can try to sneak new features into
[12:57:41] <jepler> hah!
[12:57:51] <jepler> I know I've got some I want :-P
[12:58:09] <cradek> I'll help you check them, if it would help.
[12:58:17] <jepler> (and clearly one of them is a bugfix for the "I can't abort when an operator message is shown" bug)
[12:58:29] <SWPadnos> I should add the gs2_vfd module too, but I can't remember why I didn't
[12:58:54] <cradek> what does that do?
[12:58:56] <jepler> SWPadnos: it's a given that you can just throw that in TRUNK
[12:59:08] <SWPadnos> modbus control of a gs2 series VFD
[12:59:16] <SWPadnos> (from Automation Direct)
[12:59:36] <SWPadnos> I wonder if it had to do with the license for the modbus library
[12:59:38] <cradek> oh hey, I think that's what I have
[12:59:45] <jepler> if that uses a library, then it is tougher to put it in 2.2 -- so far we've not required additional packages to be installed for upgrades within the 2.2.x series
[13:00:22] <SWPadnos> it's a source library, I don't think there's a package
[13:00:32] <SWPadnos> like NML, for the most part
[13:00:45] <micges> any ideas how to fix bug sf#2046178 ?
[13:01:12] <jepler> speaking of sf bugs, is there any way to take a bug number and directly get the report?
[13:01:26] <jepler> it seems like you have to know what project, and what tracker, and then scan the "request id"s in that tracker...
[13:01:51] <jepler> micges: the answer is "run from line needs serious work and many developer hours of time to work like people want"
[13:01:59] <SWPadnos> type it into the sesarch box at the top right of the EMC main page
[13:02:11] <skunkworks> http://www.cnczone.com/forums/showthread.php?p=491709#post491709
[13:02:27] <jepler> SWPadnos: aha
[13:02:37] <SWPadnos> * SWPadnos just learned that ;)
[13:08:49] <jepler> (suppose that you have the program: G0 X0 Y0 Z0 / G2 X0 I1 / M2. What should a control do if you actually jog to X10 then run from the G2 line? It doesn't even make sense! there's no an arc from X10 Y0 to X0 Y0 with the center at X11 Y0!)
[13:09:22] <cradek> I agree with jepler, and if you jog, none of the arcs are ever going to be what you want
[13:09:32] <cradek> but, even without jogging, the behavior is a little puzzling
[13:10:37] <SWPadnos> it could be argued that stop/restart from the same line would be least surprising if it acted like pause (feedhold)
[13:10:55] <SWPadnos> though I have no idea how to make that true - I suspect it's not trivial
[13:13:30] <micges> jepler: It should run line with G2 with it as it is said "this is next line to run"
[13:15:07] <SWPadnos> maybe we should ask the user list what most controls do or what they would expect
[13:15:36] <SWPadnos> I don't think we have enough information to (a) decide to do a lot of work to make it do something we like or (b) decide it's too hard to get right
[13:16:25] <micges> if you think that is stupid, I think that it must be consistent
[13:17:12] <SWPadnos> no, not stupid, just unclear (note that I'm not testing this right now, so I haven't seen the actual behavior)
[13:17:56] <SWPadnos> if you stop a program during an arc, and you want to complete the arc when you restart the program, then it's important that the machine is still on the arc
[13:18:10] <SWPadnos> otherwise the math either doesn't work, or the recalculated arc is wrong
[13:18:52] <Lerman> Remember that the interp doesn't know where the machine is. It only knows where it told it to go.
[13:18:54] <SWPadnos> so if you've moved at all, or hitting Estop allowed the motors to get off the path, then there's a problem that probably can't be solved by the computer
[13:19:06] <SWPadnos> Lerman, unless you have servos and feedback
[13:19:19] <Lerman> Since jogging isn't seen by the interp, it can't know that you jogged.
[13:19:36] <Lerman> No. Servos and feedback tell emc where it is, but not the interp.
[13:19:38] <SWPadnos> uh - yes, the interp knows where jogging takes the machine
[13:20:23] <SWPadnos> I think we have a terminology problem here (probably on my end :) )
[13:20:52] <SWPadnos> the interp certainly knows what the machine position is when it starts a move
[13:21:27] <Lerman> Or maybe at mine. :-) When I say interp, I mean the thing that reads the gcode.
[13:21:35] <SWPadnos> heh
[13:21:56] <Lerman> That does not include the RT stuff.
[13:22:14] <SWPadnos> that must also know what the machine position is, or it couldn't calculate the arc in the first place
[13:22:39] <Lerman> The interp (as I use the term) doesn't know or care whether it is a stepper system or a servo system.
[13:22:48] <SWPadnos> (emcstatus exposes that stuff to userspace, as do some HAL pins)
[13:23:08] <SWPadnos> true, either feeds position back to the upper userspace layers
[13:23:14] <SWPadnos> it's just synthesized for stepper
[13:23:15] <Lerman> The interp knows what it told the machine to do. It says go to x, y, z and sets that as its current position.
[13:23:16] <SWPadnos> s
[13:23:22] <SWPadnos> nope
[13:23:33] <SWPadnos> this is why people with stepper machines can get following errors
[13:23:40] <SWPadnos> if stepgen isn't correctly configured
[13:24:03] <micges> I know all this up to now
[13:24:05] <Lerman> From a layer closer to the hardware than what I'm calling the interp.
[13:24:20] <skunkworks> isn't that 'motion' - not interp?
[13:24:28] <SWPadnos> oh - yes, you're right that that's how the interp is able to keep interpreting while long past lines are being executed
[13:24:31] <micges> let's forgot about jog
[13:25:04] <Lerman> My partial solution to some of the problems is to move some of this back up the hierarchy into what I call the interp.
[13:25:09] <SWPadnos> but when you switch to auto mode from jog/MDI it has to re-sync, so it will know where the machine actually is at the start
[13:25:39] <Lerman> Yup. And it wants to start at the beginning of the program.
[13:26:15] <Lerman> To get all of the mode, etc stuff right.
[13:26:56] <SWPadnos> aside from that - there is the problem micges is mentioning (which I haven't reproduced yet, though it seems cradek and jepler have)
[13:27:16] <SWPadnos> in fact, they're so quiet, I'm almost expecting a CVS commit message in a few minutes ;)
[13:27:54] <skunkworks> heh ;)
[13:28:02] <skunkworks> funny how that usually works
[13:28:27] <skunkworks> Lerman: how is the conversion to emc2 going?
[13:28:53] <micges> ok test is:
[13:29:05] <Lerman> I'm still working on it. Axis is now running OK. I'm getting limit switch errors when I try to run. It tells me that I'm on the limit when I'm not.
[13:29:15] <micges> 1. run emc/sim
[13:29:35] <Lerman> I suspect the logic in the ini file that tells the sense of the switches has changed.
[13:30:02] <Lerman> I decided to RTFM and I'm starting to do that now.
[13:30:42] <SWPadnos> the old ini parameters named xxx_INDEX are no longer used, they're HAL-ified now
[13:30:48] <Lerman> I run sim all the time on another machine. That's how I've been able to contribute to the source.
[13:31:13] <micges> 2. load gcode:
[13:31:13] <micges> %
[13:31:13] <micges> F1000
[13:31:13] <micges> G61
[13:31:13] <micges> M50 P0
[13:31:14] <micges> G0 X0.0000 Y0.0000
[13:31:16] <micges> G4 P0.100
[13:31:18] <micges> M50 P1
[13:31:19] <Lerman> Yeah, I figured it was something like that. Do you know if there is an EMC1 to EMC2 upgrade guide around.
[13:31:20] <micges> M4
[13:31:22] <micges> G4 P0.1
[13:31:24] <micges> G1 X100.0000 Y0.0000
[13:31:24] <SWPadnos> micges, I think the steps to reproduce are in the bug report - I just don't have a PC runnung with EMC at the moment
[13:31:26] <micges> G3 X143.3013 Y25.0000 I0.0000 J50.0000
[13:31:28] <micges> G3 X143.3013 Y75.0000 I-43.3013 J25.0000
[13:31:30] <micges> G3 X100.0000 Y100.0000 I-43.3013 J-25.0000
[13:31:32] <micges> G1 X0.0000 Y100.0000
[13:31:34] <micges> M5
[13:31:36] <micges> G4 P0.0
[13:31:38] <micges> M50 P0
[13:31:40] <micges> G0 X0.0000 Y0.0000
[13:31:42] <micges> %
[13:32:14] <micges> oh ok
[13:33:01] <SWPadnos> Lerman, I think the idea is to take the sample config that uses your hardware, and change the things that are machine-specific in the HAL/ini files (scales, PID, I/O pin assignment, etc)
[13:33:59] <Lerman> That's what I did. I'm just not done yet. :-)
[13:34:11] <Lerman> Thanks. BBL.
[13:34:19] <SWPadnos> heh - see you
[13:35:51] <micges> SWPadnos: I take care to make sure that machine is on the arc when run from it
[13:37:17] <micges> point is that Im call "start from 44" and emc is going to run 43 in some way
[13:38:05] <micges> everytime that actual arc is after g1 line , that g1 line is executed
[13:38:11] <micges> that the problem
[13:38:30] <micges> everything else is in all correct
[13:39:15] <SWPadnos> I think that behavior is done on purpose, to insure that the arc is correct
[13:39:38] <SWPadnos> you have to be at the correct start point for the arc calculation to come out the same
[13:41:36] <cradek> I agree with jepler that we do not have a coherent design for run-from-line so adding bugfixes is the wrong approach
[13:42:10] <cradek> like he pointed out, if you jog, there is no arc and starting at the arc lines like in micges's bug report is an error
[13:45:09] <cradek> in this way I don't agree with micges's "expected behavior" in the bug report. To me the expected behavior is an error message about an invalid arc.
[13:48:27] <SWPadnos> I agree - I think the expected behavior is what happens the first time - a move to the start, then continue from there
[13:49:00] <SWPadnos> there is a bug though, the second one doesn't do that
[13:49:19] <SWPadnos> the bug being that they're treated differently, not that I really know which is right
[13:51:16] <micges> when you have 0.5 kW laser and you stop in middle of 1m radius arc (burned with 100mm/min) to check anything, then you can't move to begin and burn it again..
[13:51:37] <SWPadnos> yep, I was thinking about laser/plasma/watercutting
[13:51:58] <cradek> SWPadnos: no, he is saying the opposite, that the first behavior is wrong and the second one is right
[13:52:05] <cradek> to me they are both wrong
[13:52:09] <SWPadnos> I know :)
[13:52:26] <cradek> oh ok, I was wondering about your reading comprehension there for a minute
[13:52:29] <SWPadnos> heh
[13:52:36] <SWPadnos> do you have an idea of what's right?
[13:52:48] <SWPadnos> I'm not sure there are any other options than "don't allow that"
[13:52:54] <cradek> who me?
[13:53:39] <SWPadnos> yes
[13:53:40] <cradek> neglecting implementation complexity, I would point out that if you haven't jogged, you are on the arc, and you could in theory construct a new arc that follows the rest of the old arc
[13:54:02] <SWPadnos> I think behavior 1 is better. micges thinks behavior 2 is better. you don't like either, so you have to come up with 3 :)
[13:54:11] <micges> hehe
[13:54:13] <cradek> I suggested 3: give an error
[13:54:28] <micges> I suggest 4: let user choose
[13:54:29] <cradek> because you can't run that line from the current machine position; it makes no sense to do so
[13:54:33] <SWPadnos> error for what? selecting an arc as the "next line"
[13:54:40] <micges> correct: let intergrator choose
[13:54:42] <SWPadnos> I like the user choosing
[13:54:44] <cradek> no, selecting an invalid arc
[13:54:46] <cradek> choose WHAT?
[13:54:50] <cradek> that's a non-answer
[13:54:57] <SWPadnos> start from here or start from the beginning
[13:55:03] <SWPadnos> when resuming a program
[13:55:05] <cradek> you can't start from here
[13:55:22] <cradek> it is not a valid arc
[13:55:35] <SWPadnos> you may not be able to start from here, but the machine can't tell if you wanted to based on whether the math works out
[13:55:42] <micges> you can't start from middle but its burn correctly ? strange
[13:56:38] <SWPadnos> I don't see how I got the arc I got, unless IJ arcs always have asolution (barring pathological cases like zero radius)
[13:56:39] <micges> in somehow something allow it to run correctly in second arc from bug report
[13:56:50] <cradek> no, it does not follow the original arc, look again
[13:56:55] <cradek> it makes some other (wrong, buggy) arc
[13:56:57] <SWPadnos> incorrectly - that isn't the programmed arc
[13:57:08] <SWPadnos> right, there is an arc, but not the one you wanted
[13:57:18] <skunkworks> if you are using r style arcs... It could theoretically make an arc where ever you are.
[13:57:21] <SWPadnos> or not the one that was programmed
[13:57:49] <cradek> skunkworks: consider +/- r. r arcs are not fully specified either
[13:58:04] <SWPadnos> that's my point - unless you calculate the "original" arc, and the "arc from current position", and see if one is part of the other, you can't tell if you're on the programmed path or not
[13:58:19] <cradek> that's right.
[13:58:41] <cradek> but the user didn't ask for the programmed path, he asked for starting on line NNN, where NNN is an arc that may be valid considering the current position
[13:58:54] <cradek> you could make THAT arc, and you can tell if it's valid by doing the math
[13:59:04] <cradek> this is what I mean by there-is-no-coherent-design
[13:59:09] <SWPadnos> right, hence my argument that the control can't tell which it should do based on the math working or not working out
[13:59:13] <SWPadnos> heh, ok, we agree
[13:59:17] <SWPadnos> violently ;)
[13:59:32] <cradek> you can't hear my typing from there can you?
[13:59:37] <SWPadnos> almost
[13:59:41] <cradek> :-)
[13:59:47] <SWPadnos> there's a train, so it's muted a bit
[14:00:21] <cradek> so our task, should we choose to accept it, is to try to come up with a coherent design
[14:00:32] <cradek> our second task would be to implement it
[14:01:01] <micges> I must go home now, I will write on wiki my current go-to-line behavior
[14:01:07] <micges> maybe its help a bit
[14:01:13] <micges> bbl
[14:01:45] <cradek> bye
[14:01:50] <SWPadnos> one thing that may be coherent (not just for arcs) is to save the last position when the machine is stopped, and if it's restarted within DEADBAND or some user-settable amount, simplify the decision-making somehow
[14:01:55] <SWPadnos> see you
[14:02:25] <cradek> the interpreter does read and resync the current machine position sometimes
[14:02:36] <cradek> that's not a problem
[14:03:00] <jepler> my position is that RFL will simply never work
[14:03:06] <SWPadnos> that would have to be combined with an integrator-set option regarding the start point of run-from-line (move to start and repeat entire move, or continue move from new position)
[14:03:33] <SWPadnos> I didn't mean re-sync current pos with machine pos, I meant compare position at restart to saved position at stop
[14:03:49] <cradek> I have what I think is a coherent design. It is possible to implement it. It is fairly simple.
[14:04:26] <jepler> what we have now is simple too
[14:04:32] <jepler> it's just that the users don't like it
[14:04:35] <SWPadnos> and certainly implementable
[14:04:48] <jepler> (I'm talking about more than just this issue regarding arcs)
[14:04:49] <cradek> 1) when someone asks for run-from-line, ignore all lines in the file above that line, and run starting with that one. 2) allow mdi and manual "mode setup" to be preserved across mode changes so the operator can set modal stuff to make part 1 useful
[14:05:52] <cradek> if the line makes no sense (as it would with an improper arc), give the correct error
[14:06:09] <SWPadnos> if it makes sense, but is wrong, then GIGO
[14:06:14] <SWPadnos> ?
[14:06:19] <jepler> and error if the line is inside any O-construct?
[14:06:33] <SWPadnos> I don't think so
[14:06:52] <cradek> so the operator would load the tool, set the TLO, maybe move to a position, start the spindle, start the coolant, maybe set G90, set G20, then RFL
[14:06:56] <SWPadnos> if I start a loop, and decide I want it to run longer, then I might want to stop, set the loop counter higher, and continue
[14:07:28] <cradek> jepler: you would run from the given line. If you meet an O-endloop without having seen a matching O-loop, you would give the appropriate error
[14:07:51] <SWPadnos> but the O-LOOP would have been in the "previous run"
[14:07:52] <jepler> http://pastebin.ca/1180682
[14:07:57] <jepler> what does this mean?
[14:08:29] <cradek> you'd get a G0, then an abort with error "endsub without sub"
[14:09:24] <cradek> if you ROFL line 4, you'd get 'O100 subroutine not defined' or however it's spelled
[14:09:44] <jepler> you think users will like this implementation enough not to complain about it?
[14:09:52] <cradek> I can't predict that
[14:10:10] <cradek> I think it would work pretty decent for typical gcode
[14:10:30] <cradek> but more importantly, I don't think we can do better, I think it's nearly the only possible coherent design
[14:10:45] <cradek> (someone correct me if I'm wrong)
[14:11:09] <SWPadnos> don't O calls now search the current file (and some subdir), or is that only in trunk?
[14:11:21] <cradek> I'm not sure
[14:11:25] <jepler> SWPadnos: beats me, but NO FUCKING WAY is a completely new ROFL implementation going into 2.2
[14:11:33] <SWPadnos> heh
[14:11:35] <cradek> no kidding
[14:11:42] <SWPadnos> ok, so we're talking TRUNK anyway then ;)
[14:11:55] <jepler> (the "O" is for "Operator"?)
[14:12:26] <SWPadnos> Run Off, Fine Loser
[14:12:37] <SWPadnos> nevermind., time for more coffee
[14:12:45] <cradek> "O" stands for "'O'nly letter that was not used yet"
[14:13:08] <SWPadnos> that would be E
[14:13:14] <SWPadnos> or is that ls ?
[14:13:16] <cradek> E is used in g76 I think
[14:13:32] <SWPadnos> interesting. I think it wasn't a couple of years ago
[14:13:42] <cradek> I used all the remaining letters :-/
[14:13:50] <SWPadnos> (we were discussing ellipses, and as luck would have it, E was available ;) )
[14:13:52] <SWPadnos> ah
[14:13:55] <cradek> beware that my proposed design won't give micges what he wants
[14:14:26] <cradek> machinery's handbook talks about an ellipse gcode, or is it a parabola? some of that silly stuff is in 274d
[14:14:32] <SWPadnos> it should - it does it "right" half the time anyway
[14:14:49] <cradek> huh? no it doesn't
[14:15:00] <SWPadnos> for micges' definition or "right"
[14:15:04] <SWPadnos> s/or/of/
[14:15:13] <cradek> no, he's mistaken, he thought it follows the arc, but it doesn't
[14:15:27] <SWPadnos> it follows an arc though, at least when I tried it
[14:15:49] <cradek> ok, but to call the behavior "make any old arc" correct just means he is mistaken
[14:15:59] <SWPadnos> so if you restart without moving, it will be pretty close to "the" arc
[14:16:11] <SWPadnos> actually, it should be "the" arc
[14:16:30] <cradek> but it's not the arc the line of gcode asks for...
[14:16:53] <SWPadnos> actually, it should be the rest of the arc the G-code asks for, if the machine hasn't moved
[14:16:56] <cradek> it's the arc the line of gcode asks for if it's run immediately after the previous line
[14:17:14] <SWPadnos> hmmm. not when I ran it - at least that's not what I interpreted it as
[14:17:24] <SWPadnos> lemme put up a screenshot
[14:17:27] <cradek> I'm not being clear
[14:18:15] <cradek> consider that a g3 command makes an arc from the current position with the center calculated incrementally from the current position
[14:18:20] <SWPadnos> or if you move back to the position where you stopped before restarting, I think
[14:18:43] <cradek> if you stop in the middle of the arc, then run that same g3 command again, you get a different arc, probably an undefined one
[14:19:39] <SWPadnos> oh, that's true isn't it
[14:19:58] <cradek> yep
[14:20:14] <SWPadnos> this is what I got:
http://www.cncgear.com/images/arc-bug.png
[14:20:16] <cradek> in my proposed implementation you would get an error because the arc is invalid
[14:21:15] <cradek> yes you got "any old arc" which is clearly (to me) not the right behavior
[14:21:32] <SWPadnos> just so I'm clear, how would you determine that the arc is invalid?
[14:22:03] <cradek> the interp does this (for IJ) by calculating the center incrementally from the start point, then comparing the start and end radii
[14:22:20] <SWPadnos> invalid and incorrect are not synonyms here
[14:22:27] <cradek> (it must be doing something wrong currently)
[14:22:33] <SWPadnos> the arc I got was valid but not correct
[14:22:53] <cradek> the arc you asked for should have been invalid
[14:23:27] <cradek> I do not know what you think the correct arc would have been
[14:23:59] <SWPadnos> asked for by restarting, or asked for by entering it in the G-code?
[14:24:16] <cradek> specifically in micges's example where you jog off the path
[14:24:24] <cradek> I don't see a correct possible arc
[14:24:38] <cradek> all I see is an error condition
[14:25:24] <SWPadnos> http://www.cncgear.com/images/arcbug-top.png
[14:25:29] <SWPadnos> it's mathematically correct
[14:25:38] <cradek> what is?
[14:25:47] <SWPadnos> err - maybe it isn't after all. hmmm
[14:25:58] <cradek> would you define 'correct' please
[14:26:05] <cradek> I think I understand 'valid'
[14:26:19] <SWPadnos> well - no, I won't define correct with that arc ;)
[14:27:28] <SWPadnos> I'm trying to see how the center point was "found"
[14:27:35] <cradek> buggily
[14:29:07] <cradek> somewhere in the arc-representation shuffle it assumed some things that aren't so, and managed to come up with a valid arc
[14:31:10] <SWPadnos> is there an environment variable you can set to get debug output?
[14:31:25] <SWPadnos> like EMC_DEBUG=0xFFFFFFFF emc
[14:31:27] <cradek> file/set debug whatever, task issue
[14:31:37] <SWPadnos> oh, ok
[14:31:38] <jepler> remember there are comments in the posemath arc code that imply it can represent spirals or some funky crap like that
[14:32:26] <cradek> it will do multi-turn non-axis-aligned helixes
[14:32:30] <cradek> so will TP
[14:32:33] <cradek> only gcode won't
[14:32:39] <cradek> (gcode/canon)
[14:41:36] <SWPadnos> I think it's using the programmed "previous endpoint" to get the arc center, rather than the actual position
[14:41:42] <SWPadnos> (like lerman suggested)
[14:42:28] <cradek> ok, but it doesn't make an arc around that center (it can't -- there isn't one)
[14:43:10] <cradek> IMO, figuring out the exact implementation of the current bug is unimportant compared to designing what it should do
[14:43:12] <SWPadnos> hmmm - no, I must be wrong, there's no way to get to the NW quadrant that way, and the arc clearly does that
[14:43:31] <SWPadnos> I think they're both significant
[14:43:42] <cradek> ok
[14:44:12] <SWPadnos> depending on what we find, there may be a bugfix and a feature change here
[14:44:17] <SWPadnos> as separate items
[14:44:59] <cradek> ok I see, we have different goals, you are interested in maybe changing this one behavior to make it a little better
[14:46:08] <SWPadnos> yes, a 2.2-compatible bugfix, vs a 2.3-compatible functionality change
[14:46:22] <SWPadnos> if there is one - I'm not convinced either way yet
[15:00:17] <CIA-35> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: add item to quickref
[15:01:11] <jepler> http://emergent.unpy.net/files/sandbox/½ of what cradek wants.patch
[15:02:38] <cradek> amazingly, that URL works
[15:12:25] <skunkworks> not on IE of course
[15:12:43] <cradek> http://emergent.unpy.net/files/sandbox/%C2%BD%20of%20what%20cradek%20wants.patch
[15:14:24] <skunkworks> * skunkworks wonders how someone can digest the code that fast and spew out new code.
[15:15:58] <cradek> I think the key is to stop arguing and do it
[15:16:20] <cradek> but mostly he did it to prove that I didn't want what I said I wanted
[15:16:33] <cradek> (I do not think he succeeded)
[15:27:42] <Lerman> I need the magic incantation to determine what the hal pins on ppmc are.
[15:27:57] <SWPadnos> halcmd show pin ppmc
[15:28:34] <SWPadnos> oops. I meant RTFM, bonehead!
[15:29:29] <Lerman> From the beginning, please. Doing a halcmd loadrt.. tells me that rtapi error could not open shared memory...
[15:30:21] <SWPadnos> oh, I thought you meant "when EMC was already running"
[15:31:09] <SWPadnos> if you have a HAL file that loads the driver, then you should be able to use "halrun -i <yourfile.hal>"
[15:31:14] <SWPadnos> though it may be -I, not -i
[15:31:35] <SWPadnos> that will drop you into an interactive halcmd "shell"
[15:31:54] <SWPadnos> (after starting the RT system and loading the hal file)
[15:32:12] <cradek> I always just start emc. if there's a bad line in the hal file, I comment it out to get emc to start
[15:32:56] <SWPadnos> yep, that's a good way, especially because you can change connections around and see if they do what you want, then change the hal files to match
[15:32:58] <Lerman> The more direct question is: For the ppmc driver what are the inverted input pins called. RTFM didn't work.
[15:33:20] <SWPadnos> ...in-not, like all the other drivers with digital I/O
[15:33:38] <SWPadnos> if that's not what you get, then it should be considered a bug in the driver
[15:33:40] <Lerman> Got it. halrun followed by the loadrt line followed by the show line. Ah. in-not NOT in.not Thanks.
[15:33:49] <SWPadnos> heh
[15:34:11] <SWPadnos> is there a manpage for the hal_ppmc driver?
[15:34:20] <SWPadnos> (can't tell since I'm on a non-RT system at the moment)
[15:34:49] <Lerman> Yes. It is badly wrong.
[15:35:18] <Lerman> It shows: (B I T) ppmc.<port>.in.<channel>.not
[15:35:42] <cradek> complain to your vendor!
[15:35:44] <SWPadnos> oh, then that should be fixed
[15:35:50] <SWPadnos> by your vendor! :)
[15:36:29] <Lerman> Last time I looked, fixing a manual required the installation of additional tools.
[15:37:43] <jepler> if you verify what the right thing is, let me know what it is and I'll get it fixed in the manual.
[15:37:47] <jepler> bigjohnt would also be happy to do it
[15:37:54] <Lerman> Finding the source is non-trivial. A suggestion: each of the manuals should have a section either at the beginning or as an appendix telling how to regenerate the manual and where the source is.
[15:38:09] <jepler> yes, editing the manual requires the version of lyx that comes with ubuntu 6.06 -- at the moment there's no effective way to edit the manual on 8.04 machines.
[15:38:15] <Lerman> That way, any idiot (even me) could do that.
[15:38:38] <jepler> the source for the manuals is in an emc2 checkout, and it's built by 'make' when you --enable-build-documentation and have the appropriate tools.
[15:40:18] <SWPadnos> theoretically, you could fix it with nano
[15:40:26] <SWPadnos> but I think you'd go insane first
[15:40:38] <BigJohnT> * BigJohnT :)
[15:40:47] <BigJohnT> what am I doing jepler
[15:41:12] <SWPadnos> the hal_ppmc section gives incorrent names for the inverted inputs
[15:41:14] <jepler> BigJohnT: making fixes to the manual suggested by others
[15:41:25] <SWPadnos> they say "...in.not" when it should be "...in-not"
[15:41:30] <BigJohnT> yep
[15:42:04] <jepler> yeah if I read the source code right it's in-not (but out.invert, go figure!)
[15:47:35] <BigJohnT> Lerman: is the error on the man page? I'm on a windoze machine...
[15:48:01] <jepler> I think it's in hal/drivers.lyx -- I'll go fix it now
[15:48:11] <BigJohnT> ok thanks jepler
[15:48:21] <jepler> I don't think there's a ppmc manpage
[15:48:41] <SWPadnos> no, I didn't see one in my source tree
[15:49:15] <BigJohnT> yep I see it on hal/drivers.lyx
[15:50:13] <CIA-35> EMC: 03jepler 07TRUNK * 10emc2/docs/src/hal/drivers.lyx: fix ppmc pin naming error
[15:50:32] <CIA-35> EMC: 03jepler 07v2_2_branch * 10emc2/docs/src/hal/drivers.lyx: from branch: fix ppmc pin naming error
[15:59:38] <CIA-35> EMC: 03swpadnos 07TRUNK * 10emc2/src/hal/drivers/hal_ppmc.c: Fix pin naming of -invert input pins
[16:01:44] <SWPadnos> hmmm. I'm insane now, looking at lyx code in nano
[16:02:02] <SWPadnos> jepler, can you take out the comment about changing the name in a later version
[16:02:04] <SWPadnos> ?
[16:03:21] <fenn> SWPadnos: yeah, you should be using vim :)
[16:03:34] <SWPadnos> I'm sure that would have helped
[16:03:41] <SWPadnos> ... me go insane sooner
[16:04:44] <CIA-35> EMC: 03jepler 07TRUNK * 10emc2/docs/src/hal/drivers.lyx: yay, swp fixed this
[16:04:50] <SWPadnos> heh - thanks
[16:05:49] <SWPadnos> ok, that's what I thought I had to do, but I couldn't check it
[16:15:56] <SWPadnos> hmmm. I wonder if I fixed that wrong
[16:16:27] <SWPadnos> the canonical input definition just says there's a "(bit) invert" parameter
[16:16:34] <SWPadnos> err - output
[16:21:54] <jepler> or else those docs are wrong too
[16:22:14] <jepler> IMO everything should be like hal_parport -- in in-not out out-invert
[16:22:15] <SWPadnos> could be
[16:22:45] <BigJohnT> while you guys are insane... what do you think of splitting the quick start part out of the Integrators manual and making a short "Getting Started" that can be downloaded from the web site
[16:22:47] <SWPadnos> oh, then my fix is wrong, it doesn't do out-invert
[16:23:02] <SWPadnos> it does blahblah.dout.##-invert
[16:23:25] <jepler> oh
[16:26:22] <SWPadnos> so parport doesn't match the online docs
[16:26:56] <jepler> offs
[16:27:19] <SWPadnos> well, the cods are ambiguous
[16:27:22] <SWPadnos> docs too
[16:27:29] <SWPadnos> http://www.linuxcnc.org/docview/html//hal_general_ref.html#cha:Canonical-Device-Interfaces
[16:28:18] <SWPadnos> the way I read it, the "base name" would be ppmc.#.dout.##.
[16:28:32] <SWPadnos> to which you add out and invert for the pin and param
[16:28:52] <SWPadnos> but it isn't really specific
[16:29:09] <SWPadnos> (since of course we don't have a separate write function for each bit)
[16:30:35] <SWPadnos> looking (randomly) at ax5214.h, the name is also mangled relative to the spec
[16:31:17] <SWPadnos> ax5214h.#.in-##-not vs ax5214h.##.##.out-not (or something like that)
[16:31:26] <SWPadnos> err s/out/in/
[17:14:09] <micges> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?RunFromLine
[17:16:41] <SWPadnos> interesting, but still has failure modes
[17:17:14] <SWPadnos> for instance, edit/reload the file and now the line numbers are screwed up (maybe far fetched, maybe not)
[17:17:59] <SWPadnos> what may be nice would be to have a "continue" vs a "re-run" option when restarting
[17:18:08] <SWPadnos> instead of having EMC try to figure out which one you wanted
[17:18:38] <SWPadnos> "run from line" vs. "run from within line" :)
[17:19:49] <micges> correction inserted read again :)
[17:21:26] <SWPadnos> ok. I don't think that changes my suggestion though :)
[17:22:34] <SWPadnos> there are a few options, which are kind of orthogonal to each other
[17:23:11] <SWPadnos> 1) restore state from the program or keep the state that was set up in MDI (or reset parts of it, like it does now by default, but I don't think that's too useful)
[17:23:45] <SWPadnos> 2) start the motion from where it was when stopped, or start the motion from the beginning (ie, from the prior endpoint)
[17:23:58] <SWPadnos> there was a third, but I forgot it :
[17:24:01] <SWPadnos> :)
[17:24:53] <SWPadnos> damn
[17:24:56] <SWPadnos> I hate it when that happens
[17:28:39] <micges> ad 1. keep the state that was set up from mdi
[17:29:09] <SWPadnos> oh - 3) use current endpoint or move to other start point (either the original programmed start or the stop point)
[17:29:17] <SWPadnos> so technically item 2 has 3 options
[17:29:41] <micges> ad 2. that could be settable by integrator(from begin for mills. from where was stopped for laser, waterjests)
[17:29:51] <SWPadnos> that's your choice, I'm saying that the integrator or operator should have that choice - EMC shouldn't decide for them
[17:30:59] <SWPadnos> maybe I'll send an email to the user list asking what behavior(s) are desirable
[17:31:18] <micges> that would be cool
[17:31:20] <SWPadnos> hey - off-topic question: you're somewhere between Kielce and Warsaw, right? (more or less)
[17:31:49] <micges> less
[17:31:54] <SWPadnos> heh
[17:32:04] <micges> 200km from kielce and 220 from warsaw
[17:32:12] <SWPadnos> oh, hmm
[17:32:41] <SWPadnos> Torun, right?
[17:32:46] <micges> yes
[17:33:21] <SWPadnos> ok. just wondering. my sister is probably going to a wedding in Olsztyn - wasn't sure how far away that is
[17:33:42] <micges> 200 km :P
[17:33:54] <SWPadnos> also, I recently found velokraft in Krakow:
http://www.velokraft.com/
[17:33:57] <SWPadnos> very cool bikes
[17:34:41] <micges> nice
[17:35:03] <SWPadnos> hmmm. I wonder what it would cost to do a jaunt from Germany to Krakow when I'm there next month
[17:36:29] <micges> where in germany ?
[17:36:51] <SWPadnos> Gottingen, so I could leave from Hamburg or Frankfurt easily, maybe Cologne/Dusseldorf too
[17:38:17] <SWPadnos> I can take a train most of the way there - I'll have a Germany/Czech Republic rail pass
[17:39:06] <micges> then trip to Krakow wouldn't be problem
[17:39:21] <micges> have good connection with Germany
[17:39:37] <micges> and with Czechy
[19:26:37] <alex_joni> heh, stepconf is used by a lot of people
[19:26:52] <SWPadnos> two hundred bazillion
[19:26:59] <SWPadnos> or at least two hundred
[19:37:44] <alex_joni> yeah, but most of them come up with pertinent feature requests
[19:38:02] <alex_joni> the problem is that by implementing them all, it will grow really huge
[19:38:37] <SWPadnos> yeah
[19:39:01] <SWPadnos> I don't think it's gotten too bloated yet, but the feature pminmo wants could make it get that way
[19:39:24] <SWPadnos> I think that would require stepconf to load in the current settings from the ini file, which I believe it doesn't do at the momet
[19:39:27] <SWPadnos> moment
[19:39:36] <SWPadnos> (it just checks md5 sums to see if the file has changed)
[19:53:15] <alex_joni> yeah, but it loads an xml
[21:37:26] <pminmo> I'd like to help in some way, as it feels like I'm hooked on emc2 , but being such a novice at emc and linux I'm not sure how, except documentation. Even there somebody would need to direct me and check what I have done. I'm also really new to irc and that netiquitte as emc has lead me here. So if I can offer something of help, who, what, where....? Phil
[21:41:25] <BigJohnT> hi pminmo, you can share with me the changes
[21:42:07] <BigJohnT> you would have to be running 6.06 to edit any of the docs...
[21:42:53] <pminmo> right now i'm in windoozs, but if I reboot I'm in 8.04
[21:58:56] <cradek> SWPadnos: can I slap 400 MB of stuff somewhere on dreamhost? A community college teacher is interested in a copy of my yggdrasil beta CD for a class project using vintage hardware.
[22:02:55] <cradek> pminmo: even knowing the docs and answering questions here is a big help
[22:03:37] <cradek> BigJohnT has read all of it and I'm amazed how many obscure questions he answers :-)
[22:05:06] <pminmo> I can try to answer questions, but I learn each day what I thought I understood but didn't....
[22:07:43] <BigJohnT> what are you trying to say cradek ?
[22:07:48] <BigJohnT> :)
[22:07:57] <cradek> that I appreciate what you do
[22:09:29] <BigJohnT> thanks :)
[22:11:05] <BigJohnT> so what do you think about ripping out the basic getting started from the integrators and making a short "Getting Started Guide"?
[22:11:51] <pminmo> is that a question for me?
[22:12:05] <BigJohnT> anyone
[22:12:39] <cradek> I have thought about how nice it would be if there would be a one-sheet-of-paper getting started guide. I've never written it because I know the shorter something is, the harder it is to write
[22:13:03] <BigJohnT> I think it might take a sheet or two
[22:13:22] <cradek> one was my goal... maybe counting the back, but preferably not
[22:13:57] <cradek> anyway, I think it's a good idea, it would be less overwhelming.
[22:14:31] <BigJohnT> my thought is if newbee could download a short pdf to guide them through the download, burn, install of the live cd it has to be better than 400 pages :)
[22:14:42] <cradek> yes!
[22:14:47] <pminmo> for me, I didn't find Stepconf untill after I had spent hours tweaking the .ini and hal files
[22:14:52] <BigJohnT> and perhaps the stepconf so they could get up and running asap
[22:15:12] <cradek> yikes, then we should fix that
[22:15:26] <cradek> pminmo: this is how you can help - you don't have to know all the details
[22:15:33] <cradek> but you can help with a new-user perspective
[22:15:52] <BigJohnT> I have done that in the Quick Start section of the newer manuals
[22:15:54] <pminmo> well they don't come much greener that I have
[22:16:20] <BigJohnT> exactly
[22:17:08] <BigJohnT> * BigJohnT is going home and Phil and I will work on the Getting Started Guide
[22:17:25] <cradek> slick
[22:18:01] <pminmo> if there is an emc for dummies i would resemble that....
[22:18:20] <BigJohnT> think quality control
[22:18:38] <cradek> bbl
[22:18:50] <BigJohnT> anyhow I'm off to the house now, I've made enough chips for the day
[22:19:37] <pminmo> chow time bbl
[23:34:33] <CIA-36> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/config/ini_config.lyx: add servo configuration
[23:50:07] <pminmo> help tried to do a
[23:50:11] <pminmo> ./configure --enable-run-in-place --enable-build-documentation=pdf
[23:50:11] <pminmo> checking installation prefix... /usr/local
[23:50:11] <pminmo> checking for RT dir... Using /usr/realtime-2.6.24-16-rtai/bin/rtai-config as the RT signature
[23:50:11] <pminmo> checking for location of kernel headers... using value from RTS: /usr/src/linux-headers-2.6.24-16-rtai
[23:50:11] <pminmo> checking for cc version... found gcc in rtai-config
[23:50:12] <pminmo> checking for gcc... gcc
[23:50:14] <pminmo> checking for C compiler default output file name... configure: error: C compiler cannot create executables
[23:50:17] <pminmo> See `config.log' for more details.
[23:51:18] <SWPadnos> have you built (anything) on this machine before?
[23:52:02] <pminmo> nope
[23:52:11] <BigJohnT> SWPadnos: I had Phil do a anon cvs checkout
[23:52:15] <pminmo> I can put the logfile on pastebin if needed
[23:52:17] <SWPadnos> the you need to run the following command:
[23:52:21] <SWPadnos> apt-get build-dep emc2
[23:52:30] <BigJohnT> :)
[23:52:39] <SWPadnos> presumably, you've already done `apt-get install emc2-dev`
[23:52:55] <BigJohnT> nope :(
[23:53:11] <SWPadnos> then do both of those and run configure again :)
[23:53:24] <SWPadnos> emc2-dev may not be needed, but what the heck
[23:53:47] <SWPadnos> I'm not sure what else is needed to be able to build docs though, I think there are some additional dependencies
[23:53:49] <pminmo> it's off doing the build now, thanks
[23:53:54] <SWPadnos> cool
[23:54:00] <SWPadnos> fast connection there ;)
[23:54:25] <pminmo> 3M or 6M forget
[23:55:05] <SWPadnos> must be cable with NetBoost or whatever they call it when they give you faster for a few minutes/seconds
[23:55:28] <pminmo> is this going to build a different config of emc than what I got of the live cd and did an update on?
[23:55:49] <pminmo> dsl
[23:55:54] <BigJohnT> your doing a run in place
[23:56:05] <BigJohnT> with pdf docs
[23:56:18] <SWPadnos> you're also building TRUNK/pre-2.3, unless you did a CVS checkout of v2_2_branch
[23:56:26] <skunkworks> depends on what cvs incatation you did..
[23:56:39] <BigJohnT> he did trunk
[23:57:39] <SWPadnos> ok, so there will be some differences between the released 2.2.6 and the result of this build, in addition to being run-in-place
[23:57:55] <pminmo> BigJohnT is driving, I'm just trying to hang on
[23:58:05] <SWPadnos> remember to always source /your/build/location/emc2/scripts/emc-envrionment
[23:58:35] <SWPadnos> you need to do that in any shell you want to use with the run-in-place version
[23:58:40] <BigJohnT> SWPadnos: after the make he is just looking at the pdf's
[23:58:46] <SWPadnos> ok, that's easier ;)
[23:59:03] <SWPadnos> but they'll be slightly wrong for the installed version, I think
[23:59:04] <pminmo> I'm still in my linux diapers
[23:59:08] <SWPadnos> I don't know exactly where though
[23:59:22] <BigJohnT> he will be current with me
[23:59:29] <SWPadnos> yes
[23:59:45] <SWPadnos> remember to get the specific version of lyx if you want to do any editing
