Re: [Emc-users] Question about using a rotary table
G90 G1A-10 would rotate ccw all the way back from where it is to -10 All the way meaning more than one rotation? Regards, Alex -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Question about using a rotary table
2009/10/2 Alex Joni alex.j...@robcon.ro: G90 G1A-10 would rotate ccw all the way back from where it is to -10 All the way meaning more than one rotation? I think it rather has to. I am thinking in terms of acting the same way as a linear axis. Imagine milling a 2-start, 2-turn worm, you would expect: G0 X0 Z2 A0 G1 Z-5 G1 A720 X100 (Cut one way) G1 Z-10 G1 A0 X0 (Cut back twice as deep) G0 Z2 G0 A180 (position for second start) G1 Z-5 G1 A900 X100 (first cut, second lead) G1 Z-10 G1 A180 X0 (second cut, second lead) To work. However, you could decide that rotary moves of greater than a full turn always have to be G91 moves, and I suppose that would be valid, if not agreeable to all. You might want a hybrid approach where G0 always takes the short way round, but G1 unwinds. That might cause problems with non-round work. Perhaps you could invent G1.1 and G0.1 which are take the shortest route, but keep the machine coordinates that the full unwind would have had. The only optimal solution is for the interpreter to be psychic and to know what the user wanted. Discussion on IRC last night mentioned that the position is stored in a double-precision float which as approx 16 digits of resolution. That means that you can set the rotary axis limits to 10E10 and still have better than 1/1000th of a degree precision even at the end points. At 10 revs per second it would take you a couple of years full-time spinning to hit the limit, so there is no practical difficulty with using G10 L2 as a reset-to-zero. -- atp -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Wrapped rotary axes, Fanuc style: for testing
On Thu, 1 Oct 2009 15:53:02 -0500, you wrote: exactly 1 full turn requires using g91 more than one full turn requires using g91 Argghhh... N G One flavour of Fanuc only (15b)! Why follow a bad design? Fanuc, as is their habit, changed it. Sensibly later Fanuc controllers treat rotary axis just like any other. The telling statement is the last paragraph - NB - One occurrence that is interesting - when the rotation in the same direction reaches 360.0 (a full circle), it continues to increase. It does not become zero degrees again. Also there is none of that G91 nonsense with more than one full turn. Here's what Peter Smid says in CNC programming handbook, and the following applies to ALL rotary axis, just that B is used in this example. (apologies if this doesn't format correctly it was OCR'd from a PDF) Just like any other axis, the B axis can be programmed in the absolute mode or incremental mode, with the same behaviour as the linear axes B Axis direction and general descriptions The B axis is programmed logically the same way as the linear axes, including the mode of dimensioning. Either the absolute or the incremental mode can be used for indexing, using standard G90 and G91 commands respectively. The following example is in the absolute mode, showing two table columns. The first column is the programmed indexing motion in G90 mode, the second column shows the actual resulting indexing motion (Distance-To-Go) and its direction. All rotational directions are based on the perpendicular view to the XZ plane. ~ Absolute Mode - consecutive indexes: Programmed motion in G90Actual indexing motion G90 G28 B0 Machine Bzero position G00 B90.0 CW 90 degrees B180.0 CW 90 degrees B90.0 CCW -90 degrees B270.0 CW 180 degrees B247.356CCW -22.644 degrees B0 CCW -247.356 degrees B-37.0 CCW -37 degrees B42.0 CW 79 degrees B42.0No motion (0 degrees) B-63.871CCW -105.871 degrees The next table is similar. The first column is the programmed indexing motion in G91 mode, the second column shows the motion directions and the actual resulting absolute position. All rotational directions are based on the perpendicular view to the XZ plane. Programmed motion in G91Actual absolute position G90 G28 B0 Machine Bzero position G91 G28 B0 Machine zero - no motion G00 B90.0 CW 90.000 B180.0 CW 270.000 B90.0 CW 360.000 B270.0 CW 630.000 B0 No motion B125.31 CW 755.310 B-180.0 CCW 575310 B-7531 CCW 500.000 B-75.31 CCW 424.690 B-424.69CCW 0.000 Study both tables block by block, in the listing order. The results are always Important for understanding. Note the B-37.0 in the first table - exactly the same result could be achieved if the block read B323.0 as a positive value. In the second table, the first block is in the absolute mode to guarantee a start at B0. One occurrence that is interesting - when the rotation in the same direction reaches 360.0 (a full circle), it continues to increase. It does not become zero degrees again. That is something to watch. If indexing (in the incremental mode) takes place twice around, the absolute table position will be 720.000°, Indexing twice will also be necessary in the opposite way in order to reach absolute zero. Steve Blackmore -- -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Question about using a rotary table
On Thu, 1 Oct 2009 13:56:32 -0500, you wrote: Gentlemen, on the Fanuc 15mb control: exactly 1 full turn requires using g91 more than one full turn requires using g91 Not one of Fanuc's better ideas and since changed :) Steve Blackmore -- -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Encoders
On Thu, 01 Oct 2009 12:32:48 -0400, you wrote: And what I think I'm seeing is quantization noise in the time domain, the occasionally very narrow spike probably isn't there on your o-scope. But it (to me anyway) points to a problem in that the sampling is probably not being done in the base thread, but in the 1 millisecond thread. Can that not be moved to the base thread? From that halscope shot, I think I'd slow the spindle revs to 100 just to reduce the noise effects of the sampling jitter. I've redone that at 100 rpm, and out of interest looked at the pulses out for the Z axis, the position interpolation is linear, as shown in halscope, the pulses out are anything but! Surely they should be linear too? There are several screenshots so I bundled them into a pdf. On page 6 I changed the sampling rate to base thread. http://filebin.ca/wacbfm/screenshots.pdf Steve Blackmore -- -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Encoders
2009/10/2 Steve Blackmore st...@pilotltd.net: On page 6 I changed the sampling rate to base thread. http://filebin.ca/wacbfm/screenshots.pdf Aha! I see noisy encoder signals. That seems to be confusing the velocity calculation (but possibly not the position calculation) I am also a little surprised that the mark-space ratio on channels A and B differs. I don't know enough about the subject to know if that matters. -- atp -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Encoders
2009/10/2 Andy Pugh a...@andypugh.fsnet.co.uk: Aha! I see noisy encoder signals. To see if that is the problem, you could debounce the signals in HAL. None of the glitches looks to be longer than one sample, so a single sample debounce should do. The drawback is that you potentially lose encoder at full speed. This is my custom.hal setup, you would need to add a channel for your encoder and I am sure I have too many links in the chain and it could be shorter. If you put it all in your normal hal file then you could skip the unlinkp bits, but I keep mine in custom to keep it safe from stepconf meddling. loadrt debounce cfg=2 addf debounce.0 base-thread setp debounce.0.delay 2 unlinkp encoder.0.phase-A unlinkp encoder.0.phase-Z unlinkp parport.0.pin-13-in unlinkp parport.0.pin-15-in net indexunfilt = parport.0.pin-13-in net indexunfilt = debounce.0.0.in net indexfilt = debounce.0.0.out net indexfilt = encoder.0.phase-Z net spindleunfilt = parport.0.pin-15-in net spindleunfilt = debounce.0.1.in net spindlefilt = debounce.0.1.out net spindleunfilt = encoder.0.phase-A -- atp -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] WG: Re: WG: Re: axis and batch processing
Chris, Is your PROGRAM_PREFIX setting in the [DISPLAY] section set? Regards, Jan On Thu, Oct 1, 2009 at 12:54, Chris Epicier seuch...@yahoo.de wrote: Hi all I am in the process of cutting parts, due out soon. Should be doing million things, other than keepin my cnc busy. I checked and rechecked the syntax in bot, master, labels and other files. I cannot find a mistake there. Is there a way I can debug this? A way to set axis/emc to talk to me about what is going wrong? Greets chris Besides: had yesterday a couple of guys couriuos abut the cnc cutting. one of them works for steel cutter. He said he was impressed about the features and easiness emc and axis can be handled. Also my finding: great! So a big faaa thankyou to all that made emc what it is now! Jan Thank you very much for the quick reply. Stephen had pointed me to this also, I have amended the files accordingly and still get Bad Number Format. I attach the original files not stripped. Maybe there is something there that shoudl not be. Besides, all files rune smoothly as truely standa alone files. So I do not believe it is actually within the sub files. greets chris Betreff: Re: [Emc-users] WG: Re: axis and batch processing An: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Datum: Mittwoch, 30. September 2009, 19:48 Chris, in file labels.ngc, line 1: Olabels sub Should be: Olabels sub and: Olabels endsub Should be Olabels endsub This syntax error should also be corrected in the other files. regards, Jan On Wed, Sep 30, 2009 at 18:00, Chris Epicier seuch...@yahoo.de wrote: Dear Stephen Check this chapter in the manual: http://linuxcnc.org/docs/2.3/html/gcode_main.html#r3_7 Regards, Jan I did, but I just cannot get it to work. I have 5 files: [master.ngc] Olabels call Ointernal_contours call Oexternal_contours_rough call Oexternal_contours_finish call G53 G0 X0Y0Z0 [end of master.ngc] [labels.ngc] Olabels sub N0G20M6T2 N868M09 N869M30 Olabels endsub M2 [end of labels.ngc] [internal_contours.ngc] Ointernal_contours sub N0G20M6T2 N868M09 N869M30 Ointernal_contours endsub M2 [end of internal_contours.ngc] [external_contours_rough.ngc] Oexternal_contours_rough sub N0G20M6T2 N868M09 N869M30 Oexternal_contours_rough endsub M2 [end of external_contours_rough.ngc] [external_contours_finish.ngc] Oexternal_contours_finish sub N0G20M6T2 N868M09 N869M30 Oexternal_contours_finish endsub M2 [end of external_contours_finish.ngc] All files are in the same directory. I believe I got the master file about right. What I doubt there is if the homing sequence is correct but that's not a showstopper. In [labels.ngc] and all the other sub files, I doubt the missing line numbering. My programming experience tells me, either it has to be ther or totally omitted. If I load master ngc in axis, I get no errormessage. when I run the file I get Bad Number Format. I am lost now. What's wrong and where, any help is greatly appreciated. greets chris === 3.7 Calling Files To call a file name the file the same as your call and include a sub and endsub. The file must be in the directory pointed to by PROGRAM_PREFIX omyfile call (a named file) or o123 call (a number file) In the called file include the oxxx sub and endsub and the file must be a valid file myfile.ngc omyfile sub ... omyfile endsub M2 If I interprete that correctly, I shoud be able to do this: Let's assume I have these files: engrave.ngc, bevel.ngc, inner.ngc, outer. ngc, home.ngc I so, I woul generate another file, let's call it master.ngc with about te following content: omaster.ngc call engrave.ngc omaster.ngc call home.ngc omaster.ngc call bevel.ngc omaster.ngc call home.ngc omaster.ngc call inner.ngc omaster.ngc call home.ngc omaster.ngc call outer. ngc omaster.ngc call home.ngc However that fails, why? I haven't tried it, but one thing to note is that the are necessary around a named O-word or parameter. Also, the manual might be a little unclear since it looks like the text
Re: [Emc-users] Question about using a rotary table
On Fri, 2009-10-02 at 12:10 +0100, Andy Pugh wrote: 2009/10/2 Alex Joni alex.j...@robcon.ro: G90 G1A-10 would rotate ccw all the way back from where it is to -10 All the way meaning more than one rotation? I think it rather has to. I am thinking in terms of acting the same way as a linear axis. In the old days, we called the actions of our Angular definition, Wrapped Linear. Quite a few of the 4th axis machines I've worked on used this definition. It is very different from a 0-360 notion. IMO the planning for a 360-0 machine level reset needs to take account of encoders and gearing combinations that don't turn out to be exact. Rayh -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Wrapped rotary axes, Fanuc style: for testing
On Fri, Oct 02, 2009 at 12:18:50PM +0100, Steve Blackmore wrote: One occurrence that is interesting - when the rotation in the same direction reaches 360.0 (a full circle), it continues to increase. It does not become zero degrees again. I think your book is describing the same behavior EMC has always had. My opinion is that's the only sane way for rotaries that can't turn forever, like a tilting head. Lots of users have pointed out (rightly in my opinion) that this behavior is awkward for rotaries that turn forever, because the position winds up forever. Once an axis says 12345.67 you have no idea from looking at the number which way it points. You have no idea what number to program in either G90 or G91 mode to get it to 90 degrees from there without an unwanted 30-ish turn unwind. Stuart's machine is like this, where C turns forever (but not B) and I think the solution he proposes is an at-least-somewhat-sane way of dealing with it. Are you objecting to this second scheme being added at all? If so, why? Is there another way, that's better in your opinion, that a different control handles an unlimited-turning rotary that solves the windup problem? Chris -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Material Edge Contour not visible
Hi guys, I'm using a cutter cadius compensation with gcode G41 and I follow the Material Edge Contour simply letting EMC to work and adjusting the trajectory based on my absolute coordinates. The trajectory I can see is only that of the backplot calculated (the tool path starting in the center of the tool) but I can't see the exact edge contour. Am I mistaking anything? Thank you Luigi -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Encoders
On Fri, Oct 02, 2009 at 12:37:05PM +0100, Steve Blackmore wrote: On page 6 I changed the sampling rate to base thread. http://filebin.ca/wacbfm/screenshots.pdf Excellent, page 7 shows the problem very clearly. You have really awful spindle feedback. I'm surprised this works at all. You have a bad noise or wiring problem, but also you have a bogus A channel with a duty cycle nowhere near 50%. What kind of encoder is this? Very old ones have adjustments inside that you can fiddle with. Maybe you could improve the duty cycle on A. The noise problem has to be fixed in your wiring though. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Encoders
On Fri, 02 Oct 2009 12:37 +0100, Steve Blackmore st...@pilotltd.net wrote: I've redone that at 100 rpm, and out of interest looked at the pulses out for the Z axis, the position interpolation is linear, as shown in halscope, the pulses out are anything but! Surely they should be linear too? There are several screenshots so I bundled them into a pdf. On page 6 I changed the sampling rate to base thread. http://filebin.ca/wacbfm/screenshots.pdf Steve Blackmore -- The last screenshot is the good one (it is the only one that is zoomed in enough to see the details of the encoder signals). Problem #1: both the dark blue and the green encoder traces have numerous glitches. Most of the time those glitches will simply result in one count up followed by one count down, with no net change in position. But there WILL be a disturbance in the calculated velocity and possibly in the interpolated position (since it uses velocity to interpolate position between encoder pulses). And sometimes you might get unlucky and have a glitch that actually gets counted, which will cause a real net position error. The dramatic drop in velocity that happens about 3.2 divisions from the left of the screen coincides with the glitch on the green encoder trace - that glitch was probably interpreted as a count by the software. It is less clear what causes the two large velocity spikes about 6 divisions from the left. There are no corresponding glitches on the encoder signals. But keep in mind that the velocity is only updated every 1mS, and it reflects everything that happened in the preceding 1mS period. So those velocity spikes might be due to encoder noise that happened slightly earlier. There was a large burst of noise on the green encoder line before the first spike. You'd need to zoom in by about another factor of 10 to get a real look at the encoder signal glitches. If they are lasting only one base period, then software debounce as Andy Pugh has already suggested could work. However, that will limit the max count rate, and is at best a workaround. I'd recommend trying to deal with the glitches at the source, which is almost certainly in the hardware. Check the wiring, parport connections, shield grounds, etc, for places where noise could get in. Use an analog scope to probe directly on the inputs to the computer and see if there is any noise or crosstalk between the encoder channels, etc. Note that crosstalk spikes might be less than a microsecond long - use a two channel scope, trigger on one encoder channel and look at the other, with sweep speeds varying from slow enough to see a full encoder cycle all the way up to 100nS/div or so. I notice that the glitches only happen when the encoder signals are high. Maybe the encoder has open collector drivers and you need stronger pullups to overcome noise in the high state? Problem #2: the dark blue encoder trace has a duty cycle that clearly not 50% - probably more like 35%. In the normal x4 counting mode, the encoder counter looks at every edge, and calculates velocity based on the time between edges. The low duty cycle on the dark blue trace means that instead of seeing edges at 0%, 25%, 50%, 75%, and 100% of a full encoder cycle, the edges are happening at something like 0%, 20%, 50%, 80%, and 100%. If you ignore the large spikes and notches in the light blue velocity signal, there is a clear periodic pattern about one vertical division high which corresponds to that pattern. The rising blue edge, rising green edge, and falling blue edge are closer together than they should be, resulting in the velocity being too high. Then the falling blue edge, rising green edge, and rising blue edge are farther apart than they should be, so the velocity is too low. This is a perfect example of GIGO (garbage in, garbage out). The signals going into the encoder counter are bad, so the results coming out are also bad. Nothing downstream from there can possibly be right, so it doesn't even make sense to look at the step pulses coming out of EMC2. Fix the noise problems and the big spikes should go away. Fix the duty cycle (if you can) and the periodic variations should go away. If you can't fix the duty cycle issue, then use x1 counting. X1 counting only looks at a single edge of one channel and is immune to duty cycle errors (at the expense of having 1/4 the resolution). Hope this helps, John Kasunich -- John Kasunich jmkasun...@fastmail.fm -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net
Re: [Emc-users] Material Edge Contour not visible
On Fri, Oct 02, 2009 at 03:31:51PM +0200, 5150 wrote: Hi guys, I'm using a cutter cadius compensation with gcode G41 and I follow the Material Edge Contour simply letting EMC to work and adjusting the trajectory based on my absolute coordinates. The trajectory I can see is only that of the backplot calculated (the tool path starting in the center of the tool) but I can't see the exact edge contour. Am I mistaking anything? No, AXIS only shows the path of the tool. You can toggle between compensated and noncompensated previews in AXIS if you put a block delete character (/) in front of your G41,G42 commands. Then poke the block delete button to toggle. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Question about using a rotary table
Gentlemen, I can think of one scenario that the rotary (0-359.999) configuration will handle better than the linear (0 thru unlimited) configuration. On a 180 degree move you would give a command of B180 or B-180 (the same position). If the sign does not tell the machine which way to turn then how does the machine know which way to move the axis? Just as important, how does the operator know which way the machine is going to move? Also, how does the post handle the move? You would need an intermediate move to allow the machine and operator to determine the direction of motion. The post can be instructed by another commanded position or a direction vector for the tool motion. There are trade offs in all configurations. In my world, small it may be, the rotary configuration is clearer and more intuitive for the post, the operator and the machine. I am glad Henry Ford does not run the industry now. You could have any color Model T you wanted along is it was black. :) -- you can lead a person to knowledge but you cannot make him think -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Wrapped rotary axes, Fanuc style: for testing
On Thu, Oct 01, 2009 at 03:53:02PM -0500, Chris Radek wrote: G53 still does the full unwind. Not anymore - now it uses the sign to determine which way to turn, and goes to the specified coordinate in that direction while disregarding g5x and g92 offsets. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Encoders
Andy Pugh wrote: 2009/10/2 Steve Blackmore st...@pilotltd.net: On page 6 I changed the sampling rate to base thread. http://filebin.ca/wacbfm/screenshots.pdf Aha! I see noisy encoder signals. That seems to be confusing the velocity calculation (but possibly not the position calculation) I am also a little surprised that the mark-space ratio on channels A and B differs. I don't know enough about the subject to know if that matters. OOO! I think you have something! YES, this actually makes sense! The velocity calculation uses the time of the last edge coming in to compute velocity. If you have noise on the encoder signals (A B), then the time of the last edge may not be relevant to the last valid count, or if the encoder is just dithering it will show much higher velocity than would be measured by position delta. Does the velocity calc require a valid quadrature transtiion, or does it count ANY transition on the A and B inputs? Also, if the encoder is dithering rapidly while not moving at all beyond the +/- 1 count, does that count as a high velocity? I think it has to, the way the code is written. There was a chip that did the quadrature to analog tach conversion, it had two frequency to voltage converters, that were differentially summed. One for each direction. So, encoder dithering would cancel out by summing. Jon -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Encoders
Jon Elson wrote: OK, things look worse, and obvious noise is showing in the A and B traces when you do this. I think it shows that the sampling was being done at the faster rate before. OOps, I misread what you had changed. Chris said it right. This is allowing you to see what is actually being seen by the base thread sampling, and why the velocity estimation is noisy. I think if you blow up the position trace with the AC coupled selection of the offset button, you will see incorrect counts due to the noise in the encoder signals. You may have electrical interference, these encoders may need a pull-up resistor to +5 V on the A and B lines. Or, the LED may be fading, throwing off the duty cycle of the A, especially. Something is dreadfully wrong. It is typical to see some dither right at the transition point of the signal, but you have pulses right in the middle of the high parts. MOST notably, they are ONLY present when the A or B are high, NEVER when they are low! This is a BIG hint that the drive strength of the encoder's output driver might be insufficient, and is barely pulling up above the threshold of the parallel port's input. I would think a 1 K Ohm resistor from +5 V to the A and B would make a big difference. You can get +5 V from the game port or a hard drive plug. Yup, also looking closer, I see COORDINATED spikes in both A and B on a number of cycles. That reinforces my suspicion of the above. Jon -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Encoders
Steve Blackmore wrote: I've redone that at 100 rpm, and out of interest looked at the pulses out for the Z axis, the position interpolation is linear, as shown in halscope, the pulses out are anything but! Surely they should be linear too? There are several screenshots so I bundled them into a pdf. On page 6 I changed the sampling rate to base thread. http://filebin.ca/wacbfm/screenshots.pdf OK, things look worse, and obvious noise is showing in the A and B traces when you do this. I think it shows that the sampling was being done at the faster rate before. On the position trace, you can set the offset to AC Coupled, and then blow it up to a more sensitive scale, just so the beginning to end spans the whole screen in vertical. That should make any anomalies visible. Jon -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] WG: Re: WG: Re: axis and batch processing
Chris Epicier wrote: Hi all I am in the process of cutting parts, due out soon. Should be doing million things, other than keepin my cnc busy. I checked and rechecked the syntax in bot, master, labels and other files. I cannot find a mistake there. Is there a way I can debug this? A way to set axis/emc to talk to me about what is going wrong? Try removing the O sub/endsub lines and loading the files individually. That should get you a line number where the error occurs (I hope). I glanced at the files and didn't see anything strange. One thing to note though, the interpreter behaves as though there were no spaces in the line. When calling subroutines that take parameters, each parameter needs to be enclosed in [] to insure that it's treated as a separate entity. If there are any places where you have two numbers separated only by whitespace, that will be an error. As an example, 1.25 3.99 will be interpreted as 1.253.99, which is a bad number format. I'm not sure where else to point you. - Steve -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Encoders
On Friday 02 October 2009, Steve Blackmore wrote: On Thu, 01 Oct 2009 12:32:48 -0400, you wrote: And what I think I'm seeing is quantization noise in the time domain, the occasionally very narrow spike probably isn't there on your o-scope. But it (to me anyway) points to a problem in that the sampling is probably not being done in the base thread, but in the 1 millisecond thread. Can that not be moved to the base thread? From that halscope shot, I think I'd slow the spindle revs to 100 just to reduce the noise effects of the sampling jitter. I've redone that at 100 rpm, and out of interest looked at the pulses out for the Z axis, the position interpolation is linear, as shown in halscope, the pulses out are anything but! Surely they should be linear too? There are several screenshots so I bundled them into a pdf. On page 6 I changed the sampling rate to base thread. http://filebin.ca/wacbfm/screenshots.pdf Steve Blackmore -- Page 5 and 6 show it but not at a good time scale, page 7 from the base thread sample shows it very clearly Steve. Noise. Until that is gone (and encoder A output could have a closer to 50% duty cycle too, I'd almost return that one in fact if its sealed and non adjustable), it isn't going to work, not even if we make sacrifices. :) I have to assume the encoders cabling is shielded, and the shield ends at the encoder so there is no connection via the shield to the machine by way of how the encoder is mounted and driven. That would be what we call a ground loop, and that is usually a no-no. And that with everything unplugged from power, that there is good continuity from the encoder cable shielding all the way back to the computers case. I think what we need to see is both a good picture of the encoder, a good pix of where the encoder cable is connected into the system, and maybe some ohm- meter readings between the computer's ground and the machine's ground with all power cables connected to power. Something is letting noise into that circuit, or forcing it as the case may be. Basically, there should be a good connection from the machine frame to the round pin of the wall socket it is plugged into, and a good connection from the shielding of the encoder cable back to the round pin of the socket the computer is plugged into, and if the machine is unplugged, there should not be any continuity from the machine frame to the computer case. And there should be a very low, under 1 or 2 ohms, connection between the round holes of the duplex the computer is plugged into, and the round hole of the duplex the machine is plugged into. Preferably on the same circuit breaker. A different circuit means it would have to go all the way back to the service entrance box to hit the common 'static' ground. That is a lot of wire acting like an antenna, and it could get pretty noisy. This next test is sorta last ditch, but will detect poor work by past electricians who really should turn in their card, they didn't pass the test. Open the service box (it goes without saying, be careful) and trace the circuit the computer is running on, then turn off that breaker, lift the white wire of that cable away from the neutral buss and turn the breaker back on, now nothing on that circuit should have power, but that white wire will now have line voltage on it if anything on the circuit is turned on. It might read up to 50 volts with everything off just from capacitance on that circuit, so use a 4 to 15 watt lamp to detect that, if it lights, something is still turned on. If everything still works mostly normal, there is a non-code connection out there, so then put the white wire back on the neutral buss (turn the breaker off so you don't get zapped put the service box back together, leaving that breaker off follow that circuit through every junction box it hits until you find where it is connected, white (neutral wire) to the static (bare wire) ground, and disconnect it. Whites to whites ok, bares to bares ok, but not together. You may even have to replace some old, no static ground romex cable with modern cable that has the w/g in its type number. The static ground, and the neutral cannot be connected together _anyplace_ but at the neutral buss of the service entrance breaker box. And that point should have 2, 8 gauge ground wires to ground rods, going as close to straight down as possible bearing in mind the ground rods they have to connect to have to be a certain distance apart according to the NEC. Good luck. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) The NRA is offering FREE Associate memberships to anyone who wants them. https://www.nrahq.org/nrabonus/accept-membership.asp I am having FUN... I wonder if it's NET FUN or GROSS FUN? -- Come build
Re: [Emc-users] Question about using a rotary table
Stuart Think about it. The linear will always be predictable. It moves from the current position to new position. In linear absolute mode -180 is not the same as 180. If I were at between -180 and 180 for a move to 180 it would move CW, a move to -180 it would move CCW . If the current position was above 180 it would move CCW for both. less than -180, CW for both. In incremental mode it would move the same as if the current position was between -180 and 180. It is true an axis that rotates 360 degrees will appear to the operator as being in the same position but mathematically they are not. Can't you get your (0-359.999) performance by using the N MOD 360 operation which returns the remainder of the number divided by 360. Only if I am thinking about a position on a dial do these appear the same to me. I am certainly not sure as how I would implement the behavior you describe. To me it is up to the G-Code programmer or Post Processor to know that this is a wrapped axis and to make the program efficient you can set the current location to N MOD 360 with out a change in position. As a programmer or the post processor I would like to know is how to change the current linear position N to N MOD 360 without causing a physical move of the machine, as my attempts with G10 L2 A 0 did not appear to have the desired result. Hubert Stuart Stevenson wrote: Gentlemen, I can think of one scenario that the rotary (0-359.999) configuration will handle better than the linear (0 thru unlimited) configuration. On a 180 degree move you would give a command of B180 or B-180 (the same position). If the sign does not tell the machine which way to turn then how does the machine know which way to move the axis? Just as important, how does the operator know which way the machine is going to move? Also, how does the post handle the move? You would need an intermediate move to allow the machine and operator to determine the direction of motion. The post can be instructed by another commanded position or a direction vector for the tool motion. There are trade offs in all configurations. In my world, small it may be, the rotary configuration is clearer and more intuitive for the post, the operator and the machine. I am glad Henry Ford does not run the industry now. You could have any color Model T you wanted along is it was black. :) -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Wrapped rotary axes, Fanuc style: for testing
On Fri, 2 Oct 2009 08:25:32 -0500, you wrote: On Fri, Oct 02, 2009 at 12:18:50PM +0100, Steve Blackmore wrote: One occurrence that is interesting - when the rotation in the same direction reaches 360.0 (a full circle), it continues to increase. It does not become zero degrees again. I think your book is describing the same behavior EMC has always had. My opinion is that's the only sane way for rotaries that can't turn forever, like a tilting head. Ehh? It's sane for any rotary, particularly those that CAN rotate forever. Lots of users have pointed out (rightly in my opinion) that this behavior is awkward for rotaries that turn forever, because the position winds up forever. What if it does wind up forever - you can always re zero it if you wish as Ian Wright has shown. Also as Andy pointed out, you can do an optional short move to zero in some controllers, invent a code for it if considered essential. Once an axis says 12345.67 you have no idea from looking at the number which way it points. You have no idea what number to program in either G90 or G91 mode to get it to 90 degrees from there without an unwanted 30-ish turn unwind. Yes you do? 12435.67 gets it +90 degrees (cw) from 12345.67 or 12255.67 gets it -90 degrees (ccw) from there. Stuart's machine is like this, where C turns forever (but not B) and I think the solution he proposes is an at-least-somewhat-sane way of dealing with it. Are you objecting to this second scheme being added at all? If so, why? Is there another way, that's better in your opinion, that a different control handles an unlimited-turning rotary that solves the windup problem? I'm objecting strongly to there being no such thing as 360 or bigger, as Stuart suggested Quote Gentlemen, I have previously requested the rotary axis usage as follows: 1: the rotary position stays within 0 and 359.999 you never see 360 (or more) in the program nor on the position screen Steve Blackmore -- -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Encoders
On Fri, 02 Oct 2009 11:34:45 -0500, you wrote: . I would think a 1 K Ohm resistor from +5 V to the A and B would make a big difference. You can get +5 V from the game port or a hard drive plug. Yup, also looking closer, I see COORDINATED spikes in both A and B on a number of cycles. That reinforces my suspicion of the above. Thanks Jon - that's an easy thing to try tomorrow. If that still fails I'll try yet another encoder G. Steve Blackmore -- -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Encoders
On page 6 I changed the sampling rate to base thread. good, the first 5 pages are in respect to phase-a b irrelevant. Looking at page 6 however, AB look really bad, try running them through a debounce first. That might increase chances of success. http://filebin.ca/wacbfm/screenshots.pdf Regards, Alex -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Question about using a rotary table
On Fri, 2 Oct 2009 09:29:05 -0500, you wrote: Gentlemen, I can think of one scenario that the rotary (0-359.999) configuration will handle better than the linear (0 thru unlimited) configuration. On a 180 degree move you would give a command of B180 or B-180 (the same position). If the sign does not tell the machine which way to turn then how does the machine know which way to move the axis? The sign DOES tell the machine which way to move. +ve goes CW, -ve goes CCW. It's NO different to a linear axis - do you have problems knowing which way that is moving? Of course not - so why should a rotary axis be any different ;) Steve Blackmore -- -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Encoders
On Friday 02 October 2009, Andy Pugh wrote: 2009/10/2 Steve Blackmore st...@pilotltd.net: On page 6 I changed the sampling rate to base thread. http://filebin.ca/wacbfm/screenshots.pdf Aha! I see noisy encoder signals. That seems to be confusing the velocity calculation (but possibly not the position calculation) I am also a little surprised that the mark-space ratio on channels A and B differs. I don't know enough about the subject to know if that matters. Yes it does Andy. If the lack of a 50% duty cycle places one edge closer than the other, then it can miss-track because of miss counts at a much lower rpm going one way than the other. The ideal is a 50-50 duty cycle, with the edges of one signal at exactly the center of the flat part of the signal from the other channel. Regardless of direction its being turned. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) The NRA is offering FREE Associate memberships to anyone who wants them. https://www.nrahq.org/nrabonus/accept-membership.asp Robot, n.: University administrator. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Wrapped rotary axes, Fanuc style: for testing
On Fri, Oct 02, 2009 at 04:05:54PM +0100, Steve Blackmore wrote: Ehh? Ehh? It's sane for any rotary, particularly those that CAN rotate forever. OK, matter of opinion. Let me explain and justify my opinion further down. Simply restating it is silly. Also as Andy pointed out, you can do an optional short move to zero in some controllers, invent a code for it if considered essential. OK, I agree a counterproposal might have this scheme. Once an axis says 12345.67 you have no idea from looking at the number which way it points. You have no idea what number to program in either G90 or G91 mode to get it to 90 degrees from there without an unwanted 30-ish turn unwind. Yes you do? 12435.67 gets it +90 degrees (cw) from 12345.67 or 12255.67 gets it -90 degrees (ccw) from there. You misunderstand what I meant to 90 degrees - let me explain more carefully. My rotary table has marks around it. I want the 90 mark to line up with the pointer. The pointer is currently between some marks. The DRO currently says 12345.67. I want to type a command in MDI to do it. Using the current EMC way, I either type G90 G0 A90 and wait for it to unwind many turns, or I get out my calculator and figure: 12345.67 / 360 = 34.2935 360 * 34 = 12240 12240 + 90 = 12330 OK, so I use G90 G0 A12330 or now I can calculate 12345.67 - 12330 = 15.67 and then use G91 G0 A-15.67 I can now, if I like, reset the DRO to 90 with a G92 A90. If I have not made any mistakes in my calculations this will work. Then, tomorrow when I power up and home the machine, my DRO will still have that offset: it will then read A -12240.00 and at that time I will want to program G92 A0 or G92.1 to fix it. Now instead, with Stuart's proposed system my DRO wouldn't say 12345.67. It would say 105.67 which is also what the pointer is pointing to. I would type G90 G0 A90 if I wanted it to rotate in the positive direction (most of a turn) to get there, or G90 G0 A-90 if I wanted it to rotate the other way to get there. To me this is a VERY clear improvement for a rotary table that's used in indexing mode where the user/programmer doesn't care how many times it has rotated, or possibly even for a forever-rotating head on a 5 axis machine. I'm objecting strongly to there being no such thing as 360 or bigger, as Stuart suggested If I have an A axis mounted on my mill and I use it to mill flats to make hex heads on a part, it's exactly true that there is no such thing as 360 or bigger that I care about. If you asked a manual machinist who cranks a rotary table to do this same task, he'd say he uses 0, 60, 120, and so on to do it. He would say funny things about you if you noticed he always cranked his table the same way as he makes these hexes, and you insisted that it was currently set to 12230 degrees! For that kind of use it doesn't matter how many times the rotary has turned. No position information is relevant to the user or programmer except the pointer on the side of the table that points to numbers that could, with this scheme, also be shown on the DRO. I see a use for both systems. I see that you strongly prefer one over the other. I do not understand yet why you object so strongly to the second one being added. Chris -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Wrapped rotary axes, Fanuc style: for testing
As a spur gear tooth cutter one needs 0-360, but a helical gear cutter goes above 360, a worm maker may need up to 10 turns, a thread miller may want a lot more. For a hobbing machine many hundreds or thousands of turns but returning to the real homed 0 or arbitary angle in less than one turn is the important move without any offset as another cut will be made Dave Caroline -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
