jepler: is this logic backward? int modes = use_control_in[n] ? 0 : PARPORT_MODE_TRISTATE;
ries_ is now known as ries
cradek: yes, you're probably right.
[12:51:00] <jepler> http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/2009-10-29.txt
micges_work1: was playing with ja3
is jogging in world mode supposed to work with the speed specified on the AXIS slider?
because it always goes full speed here
it supposed to use slider value, but after few attempts I've give up for now
EMC: 03jepler 07v2.4_branch * r46588e0ae365 10/src/hal/drivers/hal_parport.c: Fix inverted test for parport TRISTATE mode
ah ok ;)
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
360 degrees and move by the shortest route to that position." as anti-windup solution...
will you accept patch to do the same in EMC?
there is something like tihs in emc
no, current anti-windup will choose direction from the sign before the number.
A90 and A-90 will go to the same position, but different directions.
micges_work1: crap, I had to invert some joint directions, and now my kins don't work anymore :(
aystarik: wait for cradek for opinion
micges_work1: yeah, need to invert DH parameters too, but it's a pain
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.
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
actually, now G43/tlo too
actually I wonder if anyone has tested wrapped rotary + ABC tool offset
cradek, yes, as I understand it should not deviate too much from current wrapped rotary...
aystarik: (I'd be much more likely to accept a patch that also adds tests of the new functionality)
if you don't know how to do that, ask and we'll help
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?
what is it?
setting/re-setting scale of each axis.
1.0 is 100%. .5 is 50%, so on.
we've had some requests for scaling
IMO it should be per G5x system, like rotation is. if you scale by 50%, what happens to all your coordinate system origins?
also in EMC without major work we cannot support anisotropic scaling
arcs must be round
(I'm surprised mach has anisotropic because it seems like it would need to be supported by all the various external motion planners)
maybe it chops arcs up into lines for those devices or something - no idea
frankly I have never once used scaling, even though I had a (non EMC) machine that supported it
well, they may error out if G2/G3 is found and scale is on.
I think it's not useful
true, it might just work very badly - who knows
Main EMC G-program is parametric :)
I would consider a patch that does isotropic scaling and does sane things with origins, tool lengths, etc
it should be set by an extension of G10 and be per coordinate system
we could allow anisotropic for rotary axes
that is true since you can't have an AB "plane" arc
it's not clear to me what isotropic means on a machine with rotaries
heck it's not clear to me what *scaling* means on a machine with rotaries
I hadn't even thought of that.
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 :-)
(after having done rotation, I don't envy step 2...)
it might help you to look at all the places I had to touch when adding rotation
some are kind of tricky, like handling G10 L20 P[other system]
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.
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.
if you can test the tip of v2_3_branch and report whether it's fixed for you, that would be helpful
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.
mshaver: not of 2.3.
there are not regular debs for 2.3, but there are for 2.4 and master
mshaver: for 2.4 and master, see http://emc2-buildbot.colorado.edu/~buildmaster/
Althought, I just moved to a new machine (Karmic) and I should try to get my build environment going...
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
Does master have the fix?
seb_kuzminsky: I hope 2.3.5 is the last one
ok i wont bother then
cradek: I didn't immediately find the equivalent to 866bbe on master or v2.4_branch. Is it there?
yes I'm sure it is
OK, I'll reboot to my Hardy setup, install the master deb and test it. Back after that with a report :)
jepler: defer-format works on rt
just some small syntax errors in vsnprintf.h
want to send me a patch?
jepler: will send you tomorrow
I have no access to rt atm
huh I swear I actually built this on an rt system, but clearly it's broken
jepler: I have that type of issues once a week, often even make clean doesn't help
oh in this case I'm sure it's a false memory that I actually compiled it
no I mean you can compile and don't have error, but on fresh clone at same pc you will get error
jepler: I installed master from the debs on the buildbot. The tool change bug we were talking about appears to be fixed! THANKS!
mshaver: thanks chris, I think he's the one who did the work
mshaver: yay, someone's using the buildbot debs!
Having ready to install debs saves a lot of time!
seb_kuzminsky: feel like looking at some boring diffs?
ooh yes, boring diffs!
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.
first and third being the most relevant to your interests
in 1/3, in hal_parport_epp_write_data, in the second conditional, shouldnt it be (buf+len) instead of (buf|len)?
+ if (!(((long)buf | len) & 0x03))
this line ^^^ ?
or maybe just !(len & 0x3)
.. and again in read_data
that seems to be a way to test "buf is 4-byte-aligned and len is a multiple of 4" in one go
what's the test supposed to mean?
it's in the code I copied from the kernel
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?
if that's what linux does, then it's probably right ;-)
seb_kuzminsky: the argument doesn't have to be aligned, but you only get the maybe-faster outsl if it is
thansk for cleaning that up jeff
you think it is cleaning, not just code churn?
I tested it, or think I tested it ;-) on pluto and 7i43 .. didn't touch ppmc yet
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
10.7.15 Scale factors G50 and G51
To define a scale factor which will be applied to an X, Y, Z, A, B, C, I & J word before it is
used program G51 X~ Y~ Z~ A~ B~ C~ where the X, Y, Z etc. words are the scale
factors for the given axes. These values are, of course, never themselves scaled.
It is not permitted to use unequal scale factors to produce elliptical arcs with G2 or G3.
To reset the scale factors of all axes to 1.0 program G50
that's the most naive implementation possible...
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
G92 wouldn't work
polar coordinates wouldn't work
(needless to say I would reject a patch that uses this scheme)
it would take a lot more thought and care than that to get it right
jepler: maybe thursday I can try to add that after we get all the bugs fixed
Well, somehow G92 should work... Main screen of mach has DRO with scale (G51) and typing of new value (G92) for each axis...
I'm considering what would happen if you put that scheme into EMC
I of course know nothing about the mach implementation
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
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...
"scale ... applied to an X ... word before it is used"
that's what I mean by "scheme"
if that is really the algorithm they use, it has a lot of problems
even if we add a rotation feature, compatibility with m--h is not a high goal
it's not a goal at all
keeping competitive :)
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
cradek: er, right
I'm not in competition with m--h.
aystarik: I'm also not interested in making a feature list to compete with mach, especially if the "features" are badly implemented
this is why I asked if we are interested in them... :)
I'm much more open to a description of our users needing a certain thing.
occasionally someone says they would have used scaling if it was available
that would be the reason to add it.
IMHO, users of EMC and users of Mach should be not much different... 90% will use it for 3d/2.5d router work
IMO it's hard to say whether you are right about that
10% of EMC would work with robots/5coords, etc...
there is a poll on the EMC site...
the question here is what percentage need scaling
er, would like to have
nobody NEEDS scaling :-)
I would like to :)
I think I might use it sometimes (but very rarely)
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..
jepler: scaling is no use with parts making
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...
but parts making is only small percentage of emc use
(err machine use)
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.
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)
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.
truetype-tracer output is a possible example of this second use case
in fact it laboriously has scaling capability added to the output
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
but it is much easier to scale at source level, not at the bottom...
the advantage of X[#3*5]... is that you are specifying the result you want
well those are the only two use cases I can come up with - if they are invalid they are invalid...
I have no investment in this really, except that I see it has nonzero value
10.7.20 Rotate coordinate system – G68 and G69
Program G68 A~ B~ I~ R~ to rotate the program coordinate system.
A~ is the X coordinate and B~ the Y coordinate of the center of rotation in the current
coordinate system (i.e. including all work and tool offsets and G52/G92 offsets.)
R~ is the rotation angle in degrees (positive is CCW viewed from the positive Z direction).
I~ is optional and the value is not used. If I~ is present it causes the given R value to be
added to any existing rotation set by G68.
e.g. G68 A12 B25 R45 causes the coordinate system to be rotated by 45 degrees about
the point Z=12, Y=25
Subsequently: G68 A12 B35 I1 R40 leaves the coordinate system rotated by 85
degrees about X = 12, Y=25
Program G69 to cancel rotation.
here goes rotation ...
sounds like it rotates the work offsets... I like ours better where you can rotate each coordinate system its own amount
I don't care about how mach does stuff; I don't use it
I hope there's a typo in their example, otherwise I don't follow it (it has B35 and then Y=25)
Z=12 does not make sense too... Should be X? :)
G68 A1 B1 R25 / G68 A2 B2 I666 R25 would be interesting to try
maybe emc should have a scaled down 'mach' mode. ;)
how uninteresting that would be to program
I don't like this pissing contest stuff, can we stop worrying about mach?
if you copy features for no reason but copying features, I'm not interested
if you want new features and care to do them well, I'm very interested
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...
I have some interest in scaling, but not copying mach's scheme because it has (at least) the problems I described
I would happily review a patch for 'shortest path' rotary indexing
cradek: I have question
I have machine with rotary joint
and from implementation it seems that F1000 on only rotary means 1000 degrees/sec right?
are you talking about commanding a rotary axis move (e.g., G1 A- F1000)?
(even if it's rotary joints that move to perform G1 X- F1000, the F is interpreted as linear units per minute)
G93 should be used, if both A and X appear in G1
I have changeable rotary joint with many diameters, on each F1000 will be different linear velocity on A
The rule emc follows in G94 mode is described here: http://linuxcnc.org/docs/html/common_machining_center.html#sub:Feed-Rate
aystarik is right: G93 can be a good way to deal with that
yes I'm looking
jepler is right: the behavior is carefully documented and you can use G94 if you want
basically you calculate linear path from A and X motion, and then divide your linear feedrate by this path to get inverse time rate...
yes I think pretty much all 5 axis cam output is done this way
interesting, thanks guys
imagine a move with B=90 and C rotating. The apparent feed depends how far up the tool you are cutting.
same problem in a different way I guess
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
* aystarik just wrote a postprocessor to wrap Y axis around excentric cylinder in A...
I can't use G93, it's confilct with our velocity control via adaprive-feed :|
adaptive feed is not allowed with G93? are you sure?
surely it is
I mean that I've F1000 on begin of each program and rest is done via AF
you can still write the gcode
you just have to know the cutting length of each move and calculate an F for it
micges: is it EDM ?
plasma or oxygen cutter
what is the feedback signal?
I'm just curious, does not belong to discussion above...
of what signal ?
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
micges: and what changes them?
jepler: looks good
seb_kuzminsky: oh yeah, I see that now
its quite complicated
you enter velcoity cmd to module and it's scaling af until required vel will be achieved
"required" by what? I don't understand basics... sorry... :)
aystarik: too late today for this :)
ok. thanks anyway :)
long day and after that car fixing.. I'm simply tired :)
no problem... I was just curious.
who's going to the cnc workshop in ann arbor? what days will the emc contingent be there?
I hope to go, but can't tell you anything beyond that
* alex_joni sighs
I'll be present in spirit ;)
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