Back
[05:03:43] <cradek> jepler: is this logic backward? int modes = use_control_in[n] ? 0 : PARPORT_MODE_TRISTATE;
[07:22:05] <ries_> ries_ is now known as ries
[12:42:04] <jepler> cradek: yes, you're probably right.
[12:51:00] <jepler> http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/2009-10-29.txt
[12:52:26] <alex_joni> micges_work1: around?
[12:55:51] <micges_work1> yes
[13:00:26] <alex_joni> micges_work1: was playing with ja3
[13:00:46] <alex_joni> is jogging in world mode supposed to work with the speed specified on the AXIS slider?
[13:00:56] <alex_joni> because it always goes full speed here
[13:01:46] <micges_work1> it supposed to use slider value, but after few attempts I've give up for now
[13:02:02] <CIA-2> EMC: 03jepler 07v2.4_branch * r46588e0ae365 10/src/hal/drivers/hal_parport.c: Fix inverted test for parport TRISTATE mode
[13:02:02] <alex_joni> ah ok ;)
[13:22:47] <aystarik> I'm re-reading manual for Mach3Mill, and they have "Shortest Rot, if checked, makes any rotary axis treat the position given as an angle modulo
[13:22:47] <aystarik> 360 degrees and move by the shortest route to that position." as anti-windup solution...
[13:24:09] <aystarik> will you accept patch to do the same in EMC?
[13:28:04] <micges_work1> there is something like tihs in emc
[13:30:24] <aystarik> no, current anti-windup will choose direction from the sign before the number.
[13:31:04] <aystarik> A90 and A-90 will go to the same position, but different directions.
[13:31:09] <alex_joni> micges_work1: crap, I had to invert some joint directions, and now my kins don't work anymore :(
[13:32:42] <micges_work1> aystarik: wait for cradek for opinion
[13:32:56] <micges_work1> alex_joni: ewww
[13:38:07] <alex_joni> micges_work1: yeah, need to invert DH parameters too, but it's a pain
[14:05:00] <cradek> aystarik: I'd consider that patch. It's possible you could build on the wrapped rotary code that's already there, and it wouldn't be too bad. But you're going to have to carefully think through how offsets should be handled.
[14:05:43] <cradek> making the axis move is the easy part - making everything else (G10, G92, probing, G28/G30, G28.1,G30.1, ...?) coherent again is what will be hard about the project
[14:06:31] <cradek> actually, now G43/tlo too
[14:06:53] <cradek> actually I wonder if anyone has tested wrapped rotary + ABC tool offset
[14:09:27] <aystarik> cradek, yes, as I understand it should not deviate too much from current wrapped rotary...
[14:10:50] <cradek> aystarik: (I'd be much more likely to accept a patch that also adds tests of the new functionality)
[14:11:09] <cradek> if you don't know how to do that, ask and we'll help
[14:11:28] <aystarik> I've also found G50/G51 axis scale set commands in Mach, as I understand, there is nothing like that in EMC? Do we need it?
[14:11:50] <cradek> what is it?
[14:12:12] <aystarik> setting/re-setting scale of each axis.
[14:12:28] <aystarik> 1.0 is 100%. .5 is 50%, so on.
[14:12:40] <cradek> we've had some requests for scaling
[14:13:12] <cradek> IMO it should be per G5x system, like rotation is. if you scale by 50%, what happens to all your coordinate system origins?
[14:13:47] <cradek> also in EMC without major work we cannot support anisotropic scaling
[14:14:04] <aystarik> why?
[14:14:12] <cradek> arcs must be round
[14:15:04] <cradek> (I'm surprised mach has anisotropic because it seems like it would need to be supported by all the various external motion planners)
[14:15:13] <cradek> maybe it chops arcs up into lines for those devices or something - no idea
[14:16:11] <cradek> frankly I have never once used scaling, even though I had a (non EMC) machine that supported it
[14:16:17] <aystarik> well, they may error out if G2/G3 is found and scale is on.
[14:16:20] <cradek> I think it's not useful
[14:16:44] <cradek> true, it might just work very badly - who knows
[14:16:45] <aystarik> Main EMC G-program is parametric :)
[14:17:33] <cradek> I would consider a patch that does isotropic scaling and does sane things with origins, tool lengths, etc
[14:18:30] <cradek> it should be set by an extension of G10 and be per coordinate system
[14:19:56] <aystarik> we could allow anisotropic for rotary axes
[14:20:43] <cradek> that is true since you can't have an AB "plane" arc
[14:21:11] <cradek> it's not clear to me what isotropic means on a machine with rotaries
[14:21:24] <cradek> heck it's not clear to me what *scaling* means on a machine with rotaries
[14:21:41] <cradek> I hadn't even thought of that.
[14:22:41] <cradek> this may be big enough that you should write up a proposal before working on a patch. That way we can all talk about it and figure out a sane behavior -- trying to correctly implement the sane behavior is step 2 :-)
[14:23:38] <aystarik> right
[14:23:59] <cradek> (after having done rotation, I don't envy step 2...)
[14:24:23] <cradek> it might help you to look at all the places I had to touch when adding rotation
[14:24:45] <cradek> some are kind of tricky, like handling G10 L20 P[other system]
[14:25:33] <cradek> brb
[18:41:53] <mshaver> cradek: Any progress on "issues with toolchange with certain configs - ID: 2941688"? I've independently discovered this problem as I use [EMCIO]TOOL_CHANGE_QUILL_UP = 1 in the smithy .ini files for milling machines.
[18:46:56] <jepler> mshaver: commit 866bbe808e92553aca7a2d16d0fa7cd3411f5d3a (v2_3_branch) purports to fix that problem. that commit will be in 2.3.5 which I hope to release this coming weekend.
[18:47:30] <jepler> if you can test the tip of v2_3_branch and report whether it's fixed for you, that would be helpful
[18:48:28] <mshaver> jepler: Cool! I'll test it as soon as I can! Are we building nightly debs now? If so, it would save me a little time.
[18:48:52] <jepler> mshaver: not of 2.3.
[18:48:58] <cradek> there are not regular debs for 2.3, but there are for 2.4 and master
[18:49:04] <jepler> mshaver: for 2.4 and master, see
http://emc2-buildbot.colorado.edu/~buildmaster/
[18:49:08] <cradek> (not nightly)
[18:49:25] <mshaver> Althought, I just moved to a new machine (Karmic) and I should try to get my build environment going...
[18:49:36] <seb_kuzminsky> any ideas how long will 2.3 live? if it's going to be around for a while after 2.4.0, maybe i should add 2.3 debs to the buildbot
[18:49:46] <mshaver> Does master have the fix?
[18:49:48] <jepler> seb_kuzminsky: I hope 2.3.5 is the last one
[18:49:55] <seb_kuzminsky> ok i wont bother then
[18:52:10] <jepler> cradek: I didn't immediately find the equivalent to 866bbe on master or v2.4_branch. Is it there?
[18:52:42] <cradek> yes I'm sure it is
[18:53:12] <jepler> aha: 80bcdbd8df6f84b1bd2f1675f16236e1500ff5a3
[18:53:29] <mshaver> OK, I'll reboot to my Hardy setup, install the master deb and test it. Back after that with a report :)
[18:55:39] <micges> jepler: defer-format works on rt
[18:56:27] <micges> just some small syntax errors in vsnprintf.h
[18:56:35] <jepler> micges: oh?
[18:56:46] <jepler> want to send me a patch?
[18:57:13] <micges> yes
[18:57:21] <micges> one moment
[18:58:33] <micges> jepler: will send you tomorrow
[18:58:58] <micges> I have no access to rt atm
[18:59:59] <jepler> OK
[19:05:07] <jepler> huh I swear I actually built this on an rt system, but clearly it's broken
[19:07:32] <micges> jepler: I have that type of issues once a week, often even make clean doesn't help
[19:07:52] <jepler> oh in this case I'm sure it's a false memory that I actually compiled it
[19:09:00] <micges> no I mean you can compile and don't have error, but on fresh clone at same pc you will get error
[19:10:03] <mshaver> jepler: I installed master from the debs on the buildbot. The tool change bug we were talking about appears to be fixed! THANKS!
[19:10:26] <jepler> mshaver: thanks chris, I think he's the one who did the work
[19:10:57] <seb_kuzminsky> mshaver: yay, someone's using the buildbot debs!
[19:11:02] <mshaver> cradek: THANKS!
[19:11:35] <cradek> welcome!
[19:11:35] <mshaver> Having ready to install debs saves a lot of time!
[19:12:12] <jepler> seb_kuzminsky: feel like looking at some boring diffs?
[19:12:43] <seb_kuzminsky> ooh yes, boring diffs!
[19:12:57] <mshaver> I always get tied up in that "version mismatch" thing when I try run-in-place... The debs solve that unless I'm actually doing development myself.
[19:13:51] <jepler> seb_kuzminsky:
http://emergent.unpy.net/files/sandbox/epp.mbox
[19:16:09] <jepler> first and third being the most relevant to your interests
[19:19:15] <seb_kuzminsky> in 1/3, in hal_parport_epp_write_data, in the second conditional, shouldnt it be (buf+len) instead of (buf|len)?
[19:20:17] <jepler> + if (!(((long)buf | len) & 0x03))
[19:20:19] <jepler> this line ^^^ ?
[19:20:25] <seb_kuzminsky> or maybe just !(len & 0x3)
[19:20:28] <jepler> .. and again in read_data
[19:20:34] <seb_kuzminsky> yes
[19:21:03] <jepler> that seems to be a way to test "buf is 4-byte-aligned and len is a multiple of 4" in one go
[19:21:07] <cradek> what's the test supposed to mean?
[19:21:09] <jepler> it's in the code I copied from the kernel
[19:21:24] <seb_kuzminsky> you're using outsl to write any number of 32-bit words, but the source buffer doesnt have to be 32-bit aligned does it?
[19:21:33] <seb_kuzminsky> if that's what linux does, then it's probably right ;-)
[19:22:08] <jepler> seb_kuzminsky: the argument doesn't have to be aligned, but you only get the maybe-faster outsl if it is
[19:22:23] <seb_kuzminsky> gotcha
[19:23:32] <seb_kuzminsky> thansk for cleaning that up jeff
[19:24:58] <jepler> you think it is cleaning, not just code churn?
[19:25:19] <jepler> I tested it, or think I tested it ;-) on pluto and 7i43 .. didn't touch ppmc yet
[19:55:52] <cradek> jepler: I know I ask you every six months, but do you still have the patch to make lathe X point up on the AXIS preview? It would cut down on confusion if it was an option.
[20:03:24] <jepler> http://mid.gmane.org/20080916131626.GB3375@unpythonic.net
[20:26:14] <aystarik> 10.7.15 Scale factors G50 and G51
[20:26:14] <aystarik> To define a scale factor which will be applied to an X, Y, Z, A, B, C, I & J word before it is
[20:26:14] <aystarik> used program G51 X~ Y~ Z~ A~ B~ C~ where the X, Y, Z etc. words are the scale
[20:26:14] <aystarik> factors for the given axes. These values are, of course, never themselves scaled.
[20:26:14] <aystarik> It is not permitted to use unequal scale factors to produce elliptical arcs with G2 or G3.
[20:26:14] <aystarik> To reset the scale factors of all axes to 1.0 program G50
[20:30:14] <cradek> that's the most naive implementation possible...
[20:34:22] <cradek> R format arcs would never work - canned cycles would have the wrong retract and peck values - setup commands like G10 would give wrong offsets - G41.1 D... would give wrong diameter - G43.1 Z... would give wrong tool length
[20:36:09] <cradek> G92 wouldn't work
[20:36:52] <cradek> polar coordinates wouldn't work
[20:37:27] <cradek> (needless to say I would reject a patch that uses this scheme)
[20:37:45] <cradek> it would take a lot more thought and care than that to get it right
[20:39:34] <cradek> jepler: maybe thursday I can try to add that after we get all the bugs fixed
[20:39:39] <cradek> jepler: thanks
[20:40:15] <aystarik> Well, somehow G92 should work... Main screen of mach has DRO with scale (G51) and typing of new value (G92) for each axis...
[20:40:42] <cradek> I'm considering what would happen if you put that scheme into EMC
[20:40:53] <cradek> I of course know nothing about the mach implementation
[20:42:25] <cradek> also if you just scale the values of x/y/z as you read them in, if you scale X to 90% and G0 X1, the DRO won't show X=1
[20:43:16] <aystarik> I don't really see "scheme" in their description -- implementation could be any... They just forbid G2/G3 if scales for axis are not equal as predicted...
[20:43:42] <cradek> "scale ... applied to an X ... word before it is used"
[20:43:53] <cradek> that's what I mean by "scheme"
[20:44:11] <cradek> if that is really the algorithm they use, it has a lot of problems
[20:44:13] <jepler> even if we add a rotation feature, compatibility with m--h is not a high goal
[20:44:34] <cradek> it's not a goal at all
[20:45:06] <aystarik> keeping competitive :)
[20:45:10] <cradek> aystarik: I don't care what mach does - I'm just saying that an approach that does what that documentation says is inadequate for EMC and would be rejected
[20:45:25] <cradek> jepler: [scaling]
[20:45:44] <jepler> cradek: er, right
[20:45:50] <jepler> I'm not in competition with m--h.
[20:46:09] <aystarik> with Fanuc?
[20:46:10] <cradek> aystarik: I'm also not interested in making a feature list to compete with mach, especially if the "features" are badly implemented
[20:46:38] <aystarik> this is why I asked if we are interested in them... :)
[20:46:40] <cradek> I'm much more open to a description of our users needing a certain thing.
[20:47:50] <cradek> occasionally someone says they would have used scaling if it was available
[20:48:16] <cradek> that would be the reason to add it.
[20:48:17] <aystarik> IMHO, users of EMC and users of Mach should be not much different... 90% will use it for 3d/2.5d router work
[20:48:47] <cradek> IMO it's hard to say whether you are right about that
[20:48:49] <aystarik> 10% of EMC would work with robots/5coords, etc...
[20:49:23] <aystarik> there is a poll on the EMC site...
[20:49:26] <cradek> the question here is what percentage need scaling
[20:49:38] <cradek> er, would like to have
[20:49:42] <cradek> nobody NEEDS scaling :-)
[20:49:50] <micges> ha
[20:49:52] <aystarik> :)
[20:50:01] <micges> I would like to :)
[20:50:17] <cradek> I think I might use it sometimes (but very rarely)
[20:50:25] <micges> simpliest version
[20:50:29] <jepler> I'm an example of someone who can't conceive of the use for scaling: I have part programs that are in inches; if I made them at 99% or 10% of the size, the part would be wrong..
[20:51:18] <micges> jepler: scaling is no use with parts making
[20:51:44] <aystarik> as I understand, they moved some kind of g-code postprocessor into mach, I've seen option to rotate program -- did not find it in docs yet...
[20:51:48] <micges> but parts making is only small percentage of emc use
[20:52:09] <micges> (err machine use)
[20:52:28] <cradek> jepler: when you cast aluminum it shrinks 5% when it cools. for a long time mold makers have had tools like rulers made 5% oversize for measuring mold features. it could be pretty natural to use that for gcode too.
[20:52:37] <jepler> image-to-gcode is another kind of task some users perform .. but if you scale that, you get a wrong result (if you scale down, the program will cut too much away because the relationship between the programmed tool and the actual tool was broken)
[20:53:10] <cradek> another take: the use of inkscape for gcode generation tells me that people use it for art stuff that isn't made to a particular size. It's natural to want to scale that kind of output to fit an artsy type of workpiece.
[20:53:38] <micges> agree
[20:53:58] <cradek> truetype-tracer output is a possible example of this second use case
[20:54:08] <cradek> in fact it laboriously has scaling capability added to the output
[20:54:11] <jepler> in that case you'd have to be using cutter comp or again the shape of the finished item will not match what you had onscreen
[20:54:18] <aystarik> but it is much easier to scale at source level, not at the bottom...
[20:54:45] <jepler> the advantage of X[#3*5]... is that you are specifying the result you want
[20:55:38] <cradek> well those are the only two use cases I can come up with - if they are invalid they are invalid...
[20:56:06] <cradek> I have no investment in this really, except that I see it has nonzero value
[20:56:11] <aystarik> 10.7.20 Rotate coordinate system – G68 and G69
[20:56:12] <aystarik> Program G68 A~ B~ I~ R~ to rotate the program coordinate system.
[20:56:12] <aystarik> A~ is the X coordinate and B~ the Y coordinate of the center of rotation in the current
[20:56:12] <aystarik> coordinate system (i.e. including all work and tool offsets and G52/G92 offsets.)
[20:56:12] <aystarik> R~ is the rotation angle in degrees (positive is CCW viewed from the positive Z direction).
[20:56:12] <aystarik> I~ is optional and the value is not used. If I~ is present it causes the given R value to be
[20:56:12] <aystarik> added to any existing rotation set by G68.
[20:56:13] <aystarik> e.g. G68 A12 B25 R45 causes the coordinate system to be rotated by 45 degrees about
[20:56:13] <aystarik> the point Z=12, Y=25
[20:56:14] <aystarik> Subsequently: G68 A12 B35 I1 R40 leaves the coordinate system rotated by 85
[20:56:14] <aystarik> degrees about X = 12, Y=25
[20:56:15] <aystarik> Program G69 to cancel rotation.
[20:56:24] <aystarik> here goes rotation ...
[20:57:59] <cradek> sounds like it rotates the work offsets... I like ours better where you can rotate each coordinate system its own amount
[20:58:09] <cradek> but whatever
[20:58:20] <cradek> I don't care about how mach does stuff; I don't use it
[20:58:24] <jepler> I hope there's a typo in their example, otherwise I don't follow it (it has B35 and then Y=25)
[20:59:30] <aystarik> Z=12 does not make sense too... Should be X? :)
[20:59:38] <cradek> G68 A1 B1 R25 / G68 A2 B2 I666 R25 would be interesting to try
[21:02:24] <skunkworks> maybe emc should have a scaled down 'mach' mode. ;)
[21:02:42] <cradek> how uninteresting that would be to program
[21:02:50] <skunkworks> heh
[21:02:59] <aystarik> lobotomy?
[21:03:09] <cradek> I don't like this pissing contest stuff, can we stop worrying about mach?
[21:03:27] <cradek> if you copy features for no reason but copying features, I'm not interested
[21:03:37] <cradek> if you want new features and care to do them well, I'm very interested
[21:06:00] <aystarik> ok, as I understand, there is no interest in having G51/G50 pair. I, personally, would like to have option of "shortest path" wrapped rotary axis. If you don't reject the idea right away, I would like to give it a try...
[21:06:58] <cradek> I have some interest in scaling, but not copying mach's scheme because it has (at least) the problems I described
[21:07:15] <cradek> I would happily review a patch for 'shortest path' rotary indexing
[21:07:29] <micges> cradek: I have question
[21:07:41] <micges> I have machine with rotary joint
[21:08:31] <micges> and from implementation it seems that F1000 on only rotary means 1000 degrees/sec right?
[21:08:41] <cradek> deg/min
[21:08:53] <micges> err right
[21:09:00] <jepler> are you talking about commanding a rotary axis move (e.g., G1 A- F1000)?
[21:09:08] <micges> yes
[21:09:13] <cradek> right
[21:09:58] <jepler> (even if it's rotary joints that move to perform G1 X- F1000, the F is interpreted as linear units per minute)
[21:10:15] <aystarik> G93 should be used, if both A and X appear in G1
[21:11:03] <micges> I have changeable rotary joint with many diameters, on each F1000 will be different linear velocity on A
[21:11:22] <cradek> yes
[21:11:26] <jepler> The rule emc follows in G94 mode is described here:
http://linuxcnc.org/docs/html/common_machining_center.html#sub:Feed-Rate
[21:11:33] <cradek> aystarik is right: G93 can be a good way to deal with that
[21:11:52] <micges> yes I'm looking
[21:12:04] <cradek> jepler is right: the behavior is carefully documented and you can use G94 if you want
[21:13:15] <aystarik> basically you calculate linear path from A and X motion, and then divide your linear feedrate by this path to get inverse time rate...
[21:13:43] <cradek> yes I think pretty much all 5 axis cam output is done this way
[21:14:28] <micges> interesting, thanks guys
[21:15:03] <cradek> imagine a move with B=90 and C rotating. The apparent feed depends how far up the tool you are cutting.
[21:15:48] <micges> yes
[21:16:08] <cradek> same problem in a different way I guess
[21:16:49] <jepler> what that shows is a machine model which tells you where the controlled point is is *not* sufficient to give you a nice simple "F word in distance units per minute" mode
[21:17:13] <cradek> agree
[21:18:51] <micges> eww
[21:19:10] <aystarik> * aystarik just wrote a postprocessor to wrap Y axis around excentric cylinder in A...
[21:20:01] <micges> I can't use G93, it's confilct with our velocity control via adaprive-feed :|
[21:20:35] <cradek> adaptive feed is not allowed with G93? are you sure?
[21:20:43] <cradek> surely it is
[21:20:45] <micges> no no
[21:21:07] <micges> I mean that I've F1000 on begin of each program and rest is done via AF
[21:21:41] <cradek> you can still write the gcode
[21:22:07] <cradek> you just have to know the cutting length of each move and calculate an F for it
[21:23:25] <micges> yes
[21:24:40] <aystarik> micges: is it EDM ?
[21:25:09] <micges> plasma or oxygen cutter
[21:25:31] <aystarik> what is the feedback signal?
[21:26:04] <aystarik> I'm just curious, does not belong to discussion above...
[21:26:16] <micges> of what signal ?
[21:26:24] <alex_joni> for AF
[21:26:29] <aystarik> yes
[21:26:45] <seb_kuzminsky> jepler: back to your boring diff, in hm2_7i43.c, in hm2_7i43_epp_write, looks like there's a comment that should have been a removed line
[21:26:50] <micges> joints velocities
[21:27:40] <aystarik> micges: and what changes them?
[21:28:23] <seb_kuzminsky> jepler: looks good
[21:29:20] <jepler> seb_kuzminsky: oh yeah, I see that now
[21:31:10] <micges> aystarik:
http://www.pastebin.ca/1807349
[21:31:27] <micges> its quite complicated
[21:32:13] <micges> you enter velcoity cmd to module and it's scaling af until required vel will be achieved
[21:32:22] <micges> more less
[21:33:08] <aystarik> "required" by what? I don't understand basics... sorry... :)
[21:34:12] <micges> aystarik: too late today for this :)
[21:34:31] <aystarik> ok. thanks anyway :)
[21:35:00] <micges> long day and after that car fixing.. I'm simply tired :)
[21:35:31] <aystarik> no problem... I was just curious.
[22:29:28] <seb_kuzminsky> who's going to the cnc workshop in ann arbor? what days will the emc contingent be there?
[22:37:36] <jepler> I hope to go, but can't tell you anything beyond that
[22:43:22] <alex_joni> * alex_joni sighs
[22:43:35] <alex_joni> I'll be present in spirit ;)
[23:39:36] <CIA-2> EMC: 03mshaver 07master * rcee162db1bfb 10/configs/smithy/ (15 files): Add files to support new 622 versions, change 1240 machine velocities, and lower spindle speed PWM output to 100Hz