Re: [Emc-users] OT: MPG format
Thanks for all the replies. I'll go with convention then; a rotating knob on the wheel. Throwing the hat over the fence; I'll post back on this within two months on where I've got to. (too many projects..) Regards Roland On 26 March 2011 04:18, Jon Elson wrote: > Igor Chudov wrote: > > I am wondering about something. > > > > For manual movement, I use a Saitek P880 joypad. I am literally overjoyed > by > > this joypad and how easily it moves the axes. > > > > Having said this bad pun, I wonder if those manual pulse generators are > > better, ergonomically, than this joypad. > > > > I have a feeling that a joypad is far better than MPGs in the ease of > moving > > the mill. > > > It probably is easier for general jogging around. I use the keypad to > make cutting moves, as when > cleaning up the top of a workpiece, because I get constant feedrate that > way. But, I use the jog dial > for stepping down, or advancing the > cut, because I can count out thousandths of an inch by the detents, > without looking at anything. > > Jon > > > -- > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] OT: MPG format
> Thanks for all the replies. I'll go with convention then; a rotating knob on > the wheel. > Throwing the hat over the fence; I'll post back on this within two months on > where I've got to. (too many projects..) If you can make an alternative one with a 'hi-fi' look (smooth wheel, no detents(?)), with maybe a push-down functionality (the whole wheel is a momentary-on push-button) then it might be interesting for a lot more DIYers than just us CNCers. AW -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Square corners With G41/G42
> in my shop we have used small offsets in EMC2 for a long time > we have had no issues of resulting incorrect geometry from entry or exit > motion If you look at the docs on radius comp you will see that if you don't have a lead in, the first move will become the lead in. The start of the move will be un compensated and the end of the move will be fully compensated. I don't know what happens if the first move is an arc. > if you have artistic designs and generate tool centerline code with a lot of > small linear (and possibly circular) moves then EMC2 and its radiusing of > the outside and inside corners will be problematic at best and unworkable at > worst Which is why I am adding G41/G42 support. If SheetCam knows about the offset it can generate the correct tool paths to allow for it. In some cases it does mean that parts of the original drawing may be optimized out but the generated tool paths will be completely legal for EMC or any control as long as you don't specify a larger radius in the control than you specified in SheetCam. > if you change to part geometry code (offset by the tool radius) you will > have a different program but you will still encounter the same problems with > the cutter comp > the same amount of change ie .002 inch > with centerline code total adjustment is -.002 > with geometry code total adjustment is still -.002 even though > the number for a 1/4 cutter is .123 instead of .125 > both will not work for the same reason The difference is that if SheetCam knows about the offset then it can make sure that for instance inside corners always have a big enough radius to allow for the tool without any warnings that you will gouge the part. > I ,too, would like to have the choice of using this feature or not > I have requested this option and argued this point more than one time (to no > avail YET) :) > > I want 5 axis cutter comp - with this 'feature' enabled 5 axis cutter comp > is not workable - with this feature disabled then 5 axis cutter comp would > be possible My brain hurts trying to think about 5-axis comp. I assume you could only use it with a ball nosed cutter. Thinking about it, surely kinematics would have to add the comp, not the interpreter. The interpreter doesn't know about the kinematics of the machine so it doesn't know the cutter orientation. Actually adding squared corners isn't that difficult. Instead of calculating the angles of the two lines to add an arc you simply find the intersection of the two lines. The difficult bit is finding someone motivated enough to do it. I am afraid I don't have a plasma or waterjet so I don't have a lot of incentive to do it myself. Unfortunately my spare time is rather limited. I am only just finishing off my EMC controlled lathe now and I started that about 2 years ago... Les -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] RPM with PWM/VFD/G540 to KBIC type controller. Not working? Help?
On 26 March 2011 01:02, Michael Jones wrote: > loadrt pwmgen output_type=0 > addf pwmgen.make-pulses base-thread > addf pwmgen.update servo-thread > net spindle-on <= motion.spindle-on > net spindle-speed-cmd motion.spindle-speed-out => pwmgen.0.value > net spindle-on motion.spindle-on => pwmgen.0.enable > net spindle-pwm pwmgen.0.pwm => parport.0.pin-14-out > setp pwmgen.0.pwm-freq 50.0 > setp pwmgen.0.scale 3500 > setp pwmgen.0.offset 0.114285714286 > setp pwmgen.0.dither-pwm true > net spindle-on => parport.0.pin-17-out All looks OK. Can you look at pin-14-out in Halscope? (or with a real scope) I suspect you may find that you do have a PWM, but that something is not happening at the G540 end. If you can't get it to work I have a little circuit that definitely does work with a KBIC that I can show you (and another which might work better, but I haven't tried) You mention using an Arduino to give tacho feedback, I assume that is to measure DC voltage and convert to pulses? I am not sure that that will achieve all that much as the KBIC runs closed-loop on input voltage so any difference between PWM command and feedback speed will be constant terms related to the conversions rather than useful load compensation feedback. Setting up a spindle encoder is possibly more useful. -- atp "Torque wrenches are for the obedience of fools and the guidance of wise men" -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] OT: MPG format
On 3/25/2011 1:13 PM, Roland Jollivet wrote: > Hi Colin > > The dials are normally graduated, and a spin of however much should move the > machine exactly that amount. Unless it's being used in a velocity mode, > where turning the wheel means move continuously, and stop means stop. (also > a debated topic (overrun)) > > However, I want to supply the encoder only, similarly, as illustrated below. > The terms 'jog wheel', MPG and pendant are often used in a mixed way. > > http://www.directencoders.com/products/mpg30/mpg30.asp > > But there are just too many configurations to start making the keypads too. > In fact, my preference is for the MPG to mounted on the swivel panel, > leaving a hand free, of which we often need a few more. > > Regards > Roland Geez, at either $150 or $170, somebody's mighty proud of their MPG. Mark -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] OT: MPG format
On 26 March 2011 10:27, Anders Wallin wrote: > If you can make an alternative one with a 'hi-fi' look (smooth wheel, > no detents(?)), with maybe a push-down functionality (the whole wheel > is a momentary-on push-button) then it might be interesting for a lot > more DIYers than just us CNCers. I have that on the controller I am building. I got the switch from eBay for a couple of pounds. Unfortuntately (as mentioned earlier) it seems to stop tracking at really quite moderate speeds. I will see how it goes in use. (I might try pulling one apart to see why it stops tracking, too) -- atp "Torque wrenches are for the obedience of fools and the guidance of wise men" -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] OT: MPG format
On 3/25/2011 6:26 PM, Igor Chudov wrote: > I am wondering about something. > > For manual movement, I use a Saitek P880 joypad. I am literally overjoyed by > this joypad and how easily it moves the axes. > > Having said this bad pun, I wonder if those manual pulse generators are > better, ergonomically, than this joypad. > > I have a feeling that a joypad is far better than MPGs in the ease of moving > the mill. > > Am I mistaken about it? > > i Igor, I wondered the same thing. That's why I have both a joypad and an MPG hooked up to my machine. Got the best of both worlds, I think. For long movements, I use the joypad. For shorter, more accurate movements I use the MPG. The joypad is using a USB port, so I didn't have to worry about having another parallel port, which is already being used by the MPG. They have different purposes for my machine. My machine bed is 6' long. It's a lot of cranking to move the gantry 6', but push a button, and hold the joystick over, and it moves nicely. But if I want to move precisely to position X or position Z, the MPG is my go to control. Mark -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] OT: MPG format
On 26 March 2011 11:46, Mark Wendt (Contractor) wrote: > But if I want to move > precisely to position X or position Z, the MPG is my go to control. If I want to go to a specific X and Y I tend to type "G0….." in the MDI and hold a finger on the ESC button. -- atp "Torque wrenches are for the obedience of fools and the guidance of wise men" -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Square corners With G41/G42
2011/3/26 Les Newell : > > SheetCam will generate excellent tool center line paths. It handles nesting > of parts within each other correctly and automatically works out which side > to compensate. As I have a number of customers complaining due to the lack > of G41/G42 support I decided I had better do something about it. > But how does it handle open lines? I had one customer, who wanted to cut out animals from plywood for small kids and open lines inside the outer contour were part of the design. > >> in my shop we have used small offsets in EMC2 for a long time >> we have had no issues of resulting incorrect geometry from entry or exit >> motion > > If you look at the docs on radius comp you will see that if you don't > have a lead in, the first move will become the lead in. The start of the > move will be un compensated and the end of the move will be fully > compensated. I don't know what happens if the first move is an arc. > At least for me it worked correctly in the same way as You said - compensation is applied during the first move, regardless, if that is G01 or G02/G03. For best results, please test it and report here :) > Which is why I am adding G41/G42 support. If SheetCam knows about the > offset it can generate the correct tool paths to allow for it. In some > cases it does mean that parts of the original drawing may be optimized > out but the generated tool paths will be completely legal for EMC or any > control as long as you don't specify a larger radius in the control than > you specified in SheetCam. I think that making amount of optimization to be depending on the max kerf width, specified by user, is very useful idea! I just would recommend testing it more than 6 times with different designs, because I managed to get that "concave corners, gouging needed" error also on outer corners, where it did not make sense to me. > The difference is that if SheetCam knows about the offset then it can > make sure that for instance inside corners always have a big enough > radius to allow for the tool without any warnings that you will gouge > the part. My conclusion was that G41/G42 compensation works correctly for inside corners, which are created by two straight lines, so creating rounded corner is not necessary. The problems start, when these straight lines are shorter than diameter of the tool (or even more, if that is very sharp inner corner - for example, in a star contour). So I think that instead of making rounded corners it would be enough to clean up code and make sure that there are not many small straight lines. Viesturs -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Square corners With G41/G42
On Sat, Mar 26, 2011 at 02:31:47PM +0200, Viesturs L??cis wrote: > > At least for me it worked correctly in the same way as You said - > compensation is applied during the first move, regardless, if that is > G01 or G02/G03. For best results, please test it and report here :) Yes, EMC supports an arc lead-in; I can't speak for any other controls. Arc lead-in can be very useful, especially on an inside contour. -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Square corners With G41/G42
2011/3/26 Chris Radek : > On Sat, Mar 26, 2011 at 02:31:47PM +0200, Viesturs L??cis wrote: >> >> At least for me it worked correctly in the same way as You said - >> compensation is applied during the first move, regardless, if that is >> G01 or G02/G03. For best results, please test it and report here :) > > Yes, EMC supports an arc lead-in; I can't speak for any other > controls. Arc lead-in can be very useful, especially on an inside > contour. I would say that they not only can, but actually they are very useful :) I _always_ use lead-in and lead-out moves. Sometimes they are just a few mm long, but still. And only case, when those lead-ins and outs are not arcs, is rectangular outer contour, all other cases and especially for _all_ inside contours I am using exclusively arc lead-in and lead-out moves. I think that straight lead-in and the corner, where it meets the actual contour creates more visible mark than a gradual approaching of the actual path as it is with arc lead-in. I have seen results of waterjet cutting, where the burn point is right on the contour and I hate the way it looks, so I think that for plasma and waterjet a lead-in is a must, lead-out is optional. Viesturs -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] OT: MPG format
Mark Wendt (Contractor) wrote: > Geez, at either $150 or $170, somebody's mighty proud of their MPG. > > HEDSS sells the basic 2" encoder for $56 on eBay in single quantity. It really seems there ought to be cheaper ones, but maybe they just don't make enough of them. This has 100 tick marks, engraved numbers every 10, and mechanical detent, with spinner knob. Jon -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] OT: MPG format
On 3/26/2011 7:52 AM, andy pugh wrote: > On 26 March 2011 11:46, Mark Wendt (Contractor) > wrote: > >> But if I want to move >> precisely to position X or position Z, the MPG is my go to control. > > If I want to go to a specific X and Y I tend to type "G0….." in the > MDI and hold a finger on the ESC button. That's another way too. The MPG allows me to do it while I'm at the machine though, rather than being at the computer, which in many cases is a lot easier. That's the whole idea behind either the joypad or the MPG control. Mark -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] OT: MPG format
On 3/26/2011 12:37 PM, Jon Elson wrote: > Mark Wendt (Contractor) wrote: >> Geez, at either $150 or $170, somebody's mighty proud of their MPG. >> >> > HEDSS sells the basic 2" encoder for $56 on eBay in single quantity. It > really seems there ought > to be cheaper ones, but maybe they just don't make enough of them. This > has 100 tick marks, engraved > numbers every 10, and mechanical detent, with spinner knob. > > Jon Or, you can get the whole bloomin' pendant for $179... http://www.kelinginc.net/BreakoutBoards.html Scroll about halfway down. Mark -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] RPM with PWM/VFD/G540 to KBIC type controller. Not working? Help?
>-Original Message- >From: andy pugh [mailto:bodge...@gmail.com] >Sent: Saturday, March 26, 2011 4:25 AM >To: Enhanced Machine Controller (EMC) >Subject: Re: [Emc-users] RPM with PWM/VFD/G540 to KBIC type controller. >Not working? Help? > >On 26 March 2011 01:02, Michael Jones >wrote: > >> loadrt pwmgen output_type=0 >> addf pwmgen.make-pulses base-thread >> addf pwmgen.update servo-thread >> net spindle-on <= motion.spindle-on >> net spindle-speed-cmd motion.spindle-speed-out => pwmgen.0.value >> net spindle-on motion.spindle-on => pwmgen.0.enable >> net spindle-pwm pwmgen.0.pwm => parport.0.pin-14-out >> setp pwmgen.0.pwm-freq 50.0 >> setp pwmgen.0.scale 3500 >> setp pwmgen.0.offset 0.114285714286 >> setp pwmgen.0.dither-pwm true >> net spindle-on => parport.0.pin-17-out > >All looks OK. Can you look at pin-14-out in Halscope? (or with a real >scope) I suspect you may find that you do have a PWM, but that >something is not happening at the G540 end. > >If you can't get it to work I have a little circuit that definitely >does work with a KBIC that I can show you (and another which might >work better, but I haven't tried) > >You mention using an Arduino to give tacho feedback, I assume that is >to measure DC voltage and convert to pulses? I am not sure that that >will achieve all that much as the KBIC runs closed-loop on input >voltage so any difference between PWM command and feedback speed will >be constant terms related to the conversions rather than useful load >compensation feedback. Setting up a spindle encoder is possibly more >useful. Andy, Thanks for the input. I haven't yet taken the Hal Scope to the output (I haven't figured out exactly how to use it yet, I suppose I probably should) and I don't own a physical scope.. one of the two should probably should be next on my list. I have watched the pin 14 in the HAL monitor, and it is doing "something", but when I try measure voltages at the G540, I get nothing (where I do get 0-11v when I measure with the POT connected). I was suspicious of the HAL until you looked at it, now I'm wondering if either this setup (http://pminmo.com/g540-vfd) is wrong/backwards/or-something for the KBIC, or if there might be something wrong with the G540's VFD output. On the Arduino front.. I was more looking at it due to seeing this project: http://ckcnc.wordpress.com/2011/01/23/thinking-inside-the-box/ I wasn't thinking of an active/automatic monitor and adjust type of control but just to show actual RPM vs commanded RPM. Exact RPM isn't so much of an issue at the moment, but having the information could prove useful from time to time (me being the information junkie that I am). Thanks, Michael -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] OT: MPG format
Mark Wendt (Contractor) wrote: > On 3/26/2011 12:37 PM, Jon Elson wrote: > >> Mark Wendt (Contractor) wrote: >> >>> Geez, at either $150 or $170, somebody's mighty proud of their MPG. >>> >>> >>> >> HEDSS sells the basic 2" encoder for $56 on eBay in single quantity. It >> really seems there ought >> to be cheaper ones, but maybe they just don't make enough of them. This >> has 100 tick marks, engraved >> numbers every 10, and mechanical detent, with spinner knob. >> >> Jon >> > > Or, you can get the whole bloomin' pendant for $179... > > http://www.kelinginc.net/BreakoutBoards.html > > Yeah, I JUST can't do that! After much eBay and web surfing, I couldn't do any better than the $56 MPG, but no WAY I will pay $179 for a cheap plastic box with a couple switches and the encoder. I did set up a CNC4PC pendant for a guy, and I was not terribly impressed with the thing. My first homemade pendant is too big, and the switches are in the wrong place for one-handed operation (I was given a big MPG). My second one uses the smaller HEDSS encoder and works better. Jon -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] OT: MPG format
On Sat, 2011-03-26 at 13:30 -0400, Mark Wendt (Contractor) wrote: > > On 3/26/2011 12:37 PM, Jon Elson wrote: > > Mark Wendt (Contractor) wrote: > >> Geez, at either $150 or $170, somebody's mighty proud of their MPG. > >> > >> > > HEDSS sells the basic 2" encoder for $56 on eBay in single quantity. It > > really seems there ought > > to be cheaper ones, but maybe they just don't make enough of them. This > > has 100 tick marks, engraved > > numbers every 10, and mechanical detent, with spinner knob. > > > > Jon > > Or, you can get the whole bloomin' pendant for $179... > > http://www.kelinginc.net/BreakoutBoards.html > > Scroll about halfway down. > > Mark Don't forget, I just got the Homann ModIO working with EMC2. One of the applications is a pendant. http://homanndesigns.com/store/index.php?main_page=index&cPath=15&zenid=43248caf2a8e36454074607748052eb1 Short URL: http://alturl.com/kixb3 -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/index.html California, USA -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] OT: MPG format
On Sat, 2011-03-26 at 14:39 -0500, Jon Elson wrote: > Mark Wendt (Contractor) wrote: > > On 3/26/2011 12:37 PM, Jon Elson wrote: > > > >> Mark Wendt (Contractor) wrote: > >> > >>> Geez, at either $150 or $170, somebody's mighty proud of their MPG. > >>> > >>> > >>> > >> HEDSS sells the basic 2" encoder for $56 on eBay in single quantity. It > >> really seems there ought > >> to be cheaper ones, but maybe they just don't make enough of them. This > >> has 100 tick marks, engraved > >> numbers every 10, and mechanical detent, with spinner knob. > >> > >> Jon > >> > > > > Or, you can get the whole bloomin' pendant for $179... > > > > http://www.kelinginc.net/BreakoutBoards.html > > > > > Yeah, I JUST can't do that! After much eBay and web surfing, I couldn't > do any better than the $56 MPG, but no WAY I will pay $179 for a cheap > plastic box with a couple switches and the encoder. I did set up a > CNC4PC pendant for a guy, and I was not terribly impressed with the > thing. My first homemade pendant is too big, and the switches are in > the wrong place for one-handed operation (I was given a big MPG). My > second one uses the smaller HEDSS encoder and works better. > > Jon I haven't used a pendant, but I don't see myself using one single handed. I would probably make a few points around the machine to mount the pendant where I can reach it, but keep my eye on what's going on. That's why I think the feel of the detent feedback is important. I would look to the major CNC machine makers for insight on this. They have decades of experience and have weeded out any of the fancy stuff that doesn't get used in the long run. -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/index.html California, USA -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] unexpected realtime delay
Hi Peter, I think you meant to say 20% not 120% since you gave the example of 200ms jitter will trip the error with a 1ms servo thread. I had a chance to do some further testing. I ran the latency test for longer - a couple hours and the servo thread jitter just barely exceeded 14us which is exactly 2% of my servo thread (700us) so I'm thinking the error is tripping at only 2% jitter - remember I have no base thread. I tried turning off hyper-threading and adding the isolcpus=1 to grub and the latency numbers about halved and no more delay errors - BUT - It has severely affected the computers performance so I won't leave it that way. I would rather just clear the error. I think 2% jitter on the servo thread is perfectly acceptable. My motors are running smooth as silk and performing well. So if it's supposed to trip at 20% and mine seems to trip at 2% have I discovered a bug or is this a problem exclusive to my system? Maybe someone else running a servo only system could try setting their servo period to 40x max jitter and see if the error is generated. That would make the error 2.5% - enough to trip if it is in fact tripping at 2%. Anyway, no biggie. I don't mind clearing the error since it only pops up once per run. It would be different if it was nagging me. Joel Jacobs On Tue, Mar 15, 2011 at 3:29 PM, Peter C. Wallace wrote: > On Tue, 15 Mar 2011, Joel Jacobs wrote: >> Hi, >> Is there any way to adjust the sensitivity or suppress this error? I >> have an Atom D525 running the latest EMC2 > > > You will still get "unexpected realtime delay" errors with just a servo thread > if the latency gets to be more than 120% of the servo period (this would be > 200 uSec at a 1ms servo thread period) This is a fairly serious amount of > latency and probably should be looked into. -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] OT: MPG format
Kirk Wallace wrote: > I haven't used a pendant, but I don't see myself using one single > handed. For use with an edge finder, two hands are available. What I usually do for Z is to slip a piece of paper between the cutter and the work, and when the paper gets stuck, I know that I am .003" (or whatever the thickness of the paper is) above the work. This would work better with a one-handed pendant. A number of CNC makers had handheld pendants with an axis selector, a rate selector and and MPG on it. Many of them had a place on the main control panel where this could be hung, but you could take it up close to the spindle when touching off and similar operations. I certainly love mine, and would not have it any other way. Jon -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] unexpected realtime delay
Joel Jacobs wrote: > Hi Peter, > I think you meant to say 20% not 120% since you gave the example of > 200ms jitter will trip the error with a 1ms servo thread. > I had a chance to do some further testing. I ran the latency test for > longer - a couple hours and the servo thread jitter just barely > exceeded 14us which is exactly 2% of my servo thread (700us) so I'm > thinking the error is tripping at only 2% jitter - remember I have no > base thread. > Yes, for some time I have thought the error message threshold is set a bit too sensitively. A 10% variation of run time for a real time component is certainly cause for worry, but one should leave enough overhead for the occasional burst of DMA or other activity that slows the CPU down. When these error messages occur, more information on the exact amount of run time variance is put in the /var/log/messages file, easiest to examine recent ones with the dmesg command. With only a 700 us servo thread, your CPU should not be real heavily loaded, so even a 10 or 20% increase in run time is not likely to overrun the next scheduled execution of the thread. Fortunately, these messages are only notices, and don't affect the machining. > I tried turning off hyper-threading and adding the isolcpus=1 to > grub and the latency numbers about halved and no more delay errors - > BUT - It has severely affected the computers performance so I won't > leave it that way. I would rather just clear the error. >I think 2% jitter on the servo thread is perfectly acceptable. Check the dmesg report, and if it really is just a 2% overrun, go ahead and ignore it. > My > motors are running smooth as silk and performing well. >So if it's supposed to trip at 20% and mine seems to trip at 2% > have I discovered a bug or is this a problem exclusive to my system? > Maybe someone else running a servo only system could try setting their > servo period to 40x max jitter and see if the error is generated. > That would make the error 2.5% - enough to trip if it is in fact > tripping at 2% What really is important is the normal run time for the entire thread vs. the scheduling interval. If there is more than 20% headroom there, I wouldn't worry about it. Jon -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] OT: MPG format
On Sat, 2011-03-26 at 17:38 -0500, Jon Elson wrote: > Kirk Wallace wrote: > > I haven't used a pendant, but I don't see myself using one single > > handed. > For use with an edge finder, two hands are available. What I usually do > for Z is to > slip a piece of paper between the cutter and the work, and when the > paper gets stuck, I know that I am .003" (or whatever the thickness of > the paper is) above the work. This would work better with a one-handed > pendant. > > A number of CNC makers had handheld pendants with an axis selector, a > rate selector and and MPG on it. Many of them had a place on the main > control panel where this could be hung, but you could take it up close > to the spindle when touching off and similar operations. I certainly > love mine, and would not have it any other way. > > Jon But, the the way I think I would use it would be to rest it or clip it to the machine and use one hand to operate the paper or dowel and the other rested on the pendant and turning the knob with my fingers. I don't think holding the pendant and operating the knob with one hand would be easy or safe. My jury rig manual pulse generator has a heavy base so I can rest it on the mill table and it will stay put while I touch off, then I move it up by the PC, so it doesn't get chips on it. I used another manual pulse generator on a FADAL mill. It was mounted in the console which I could reach while touching off. If you say you can hold and operate your pendant in one hand, I'll have to reconsider my opinion. What I'd like to see, is a way to make these MPG encoders cheap enough that several could be mounted to the machine, such as, to have one for each axis. This would come close to allowing a CNC to operate like a manual machine. Maybe I'll get to it this summer. -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/index.html California, USA -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] OT: MPG format
Kirk Wallace wrote: > If you say you can hold and operate your pendant in one hand, I'll have > to reconsider my opinion. > I have a button that has to be pressed for the MPG to move the machine. I think this is important, as I sometimes bump the dial by accident, and the thought of the machine zooming off when I bump it is scary. So, I would have to hold the pendant and press the button with one finger while turning the dial with my thumb. My second generation of the pendant makes this possible, but it is not completely ergonomic. I have that pendant on my minimill, which is used for shows like the CNC Workshop, and I don't usually machine anything on it. So, I haven't really used that gen 2 pendant very much. Someday, I may redo the pendant on the Bridgeport, and I might make a mock-up first to get the most comfortable positions for everything. > What I'd like to see, is a way to make these MPG encoders cheap enough > that several could be mounted to the machine, such as, to have one for > each axis. This would come close to allowing a CNC to operate like a > manual machine. Maybe I'll get to it this summer. > Well, I've gotten pretty comfortable with the one dial for 3 axes. Our Bridgeport/Romi lathe at work has dials like that, so when it is in manual mode, it is supposed to feel very much like a manual lathe. The guys at work use it that way probably more than they use the CNC feature. Jon -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] unexpected realtime delay
Ok, found something interesting. I left the isolcpus=1 in grub and re-enabled hyper-threading and latency topped out around 11.2us with acceptable performance. I thought it should be fixed so ran EMC2 and after a few hours the error tripped again. Here is the details from dmesg: [16870.928322] 24014168: ERROR: Unexpected realtime delay: check dmesg for details. [16870.928333] [16870.928336] In recent history there were [16870.928338] 1259487, 1262655, 1058805, 1265220, and 1248228 [16870.928341] elapsed clocks between calls to the motion controller. [16870.928350] This time, there were 1273653 which is so anomalously [16870.928354] large that it probably signifies a problem with your [16870.928357] realtime configuration. For the rest of this run of [16870.928360] EMC, this message will be suppressed. At first glance it looks like the 1058805 is the outlier here, not the 1273653 it's complaining about. Anyway I'm trying to make sense of these numbers. Earlier in the dmesg output is this: [ 62.467909] RTAI[sched]: Linux timer freq = 250 (Hz), TimeBase freq = 1800221000 hz. So, f=1800221000, p=1/f, servo thread = p*n (n=numbers from dmesg) clocksservo threadjitter 1259487 = 699.629us -0.371us -0.0535% 1262655 = 701.389us +1.389us +1.984% 1058805 = 588.153us -111.847us -15.978% 1265220 = 702.814us +2.814us +0.402% 1248228 = 693.375us -6.625us -0.946% 1273653 = 707.498us +7.498us +1.071% It looks to me that the 1058805 is the problem child here and it's not an Unexpected realtime delay at all. Looks like an Unexpected premature execution of the thread! Any idea what could cause this? Joel -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
