[Emc-users] G38.x Probing questions for tool offsets
Today I made a simple 1 wire probe so I can probe a surface for engraving, pcb milling and for tool offset contact plate. I was playing around in the MDI with G38.2 and I have some questions. The tool drives into the plate and of course goes through it (I mean, bends it, flexible 10mil sheet) as it de-accelerates. I would then like to back up a little and re-probe at a lesser feed to get a more accurate result. (Or is this necessary since the variables would be set at latch time?) When I issue a 38.5 to retract (target state is no-contact) it makes a jitter then stops and says "Probe ?? while in non-probe MDI command." I can try again but it doesn't do anything. I try a regular feed or rapid and it aborts with the same message without movement. I can only move the machine by going to direct control and using the keyboard (or my joystick pendant.) Maybe I am just getting noise near the surface. I could add a Schmitt buffer for hysteresis, as well as a resistor/cap filter on the probe input. Thanks, Colin -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Second probe question - Probe surface then mill it
I am writing some code to mill solder paste stencils. I would like to use a probe to map the surface for possible unevenness in the surface before milling. Since the gcode is generated by a program I have two methods I see. 1. (obvious one) probe first to a log file, feed into the program which it then interpolates and generates the milling output. 2. Have the program generate the milling output, but first step have it do a probe pass, it then records the offsets to an array in memory (emc variables) and before milling each feature call a subroutine to interpolate the z offset and set. The feature would then be milled using incremental/relative coord mode. Return to absolute, move to next feature position, re-interpolate offset, etc. I think method 2 would be pretty convenient! And not that complex to program. What do you think? C -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] threading Z oscillation depends on encoder PPR
John Kasunich wrote: > It does not introduce a delay. > > It uses the velocity between the last two edges to predict the position > as time moves on, until the next edge arrives, at which point it uses > that edge to correct any error in the prediction. > > Below is a halscope plot from when I was testing the interpolated output. > > http://jmkasunich.com/pics/interpolated-encoder.png > That is indeed very pretty! Jon -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] threading Z oscillation depends on encoder PPR
Jon Elson wrote: > Andy Pugh wrote: >> Is there any reason not to use position-interpolated by default? > There might be. I don't know how position-interpolated works, but I > assume it might > introduce a delay in the position reports. It does not introduce a delay. It uses the velocity between the last two edges to predict the position as time moves on, until the next edge arrives, at which point it uses that edge to correct any error in the prediction. Below is a halscope plot from when I was testing the interpolated output. http://jmkasunich.com/pics/interpolated-encoder.png This was over a year ago and I don't remember exactly what all the traces are. I believe I was using the simulated encoder component to generate a low-PPR test signal. The sine-wavey signal is the speed command to the simulated encoder - I wanted to simulate a spindle whose speed was varying under cutting load. The red is the normal position, taking rather coarse steps because it is a low PPR encoder. The light blue is the interpolated position. As you can see, there is no delay. In fact, the non-interpolated position can be said to have a "delay", since it sits at a constant level while the actual position is advancing, then jumps to catch up. The interpolated position is much closer to the actual. Regards, John Kasunich -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] threading Z oscillation depends on encoder PPR
Michael Haberler wrote: > > stepgen just does what axis tells it to do: > http://mah.priv.at/cgi-bin/viewvc.cgi/emc-syncmove/pos-cmd-steprate.png?revision=1.1&root=CVS&view=markup > > the wobble is already in axis.2.motor-pos-cmd so that takes stepgen > out of the picture IMHO > Well, the dbg_step_rate is not what I was expecting, it is the integration of a square wave, which gives a triangle wave. So, clearly the axis following logic is jamming accleration from max + to max - and cycling back and forth at just about a 2 Hz rate. It would probably work better if it just held one or the other until the axis got close into sync with the spindle. I still don't understand why the acceleration is reversing sign like that. Is there some integrator that has wound up so it overshoots the desired alignment of axis to spindle? Or, is it trying to get in sync, and finally the spindle has passed a full revolution, and then the logic is trying to sync up to the next revolution instead? I still don't quite get what is going on. Jon -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] threading Z oscillation depends on encoder PPR
Andy Pugh wrote: > 2009/10/22 Michael Haberler : > >> yes - I ran into the problem when switching to hm2 which doesnt >> currently provide position-interpolated >> >> > > Which is an interesting point. It seems that a hardware quadrature > counter is likely to be counterproductive if you have a low-count > encoder. > I'm not sure it is COUNTER-productive, but if the spindle encoder resolution times the maximum spindle speed doesn't exceed the ability of the software encoder counter, than it doesn't GAIN anything. > With a software encoder you need to hit the balance between having > enough pulses per servo thread to always get a position update, but > not have more than one encoder edge per base-thread. Quite a balancing > act with a typical 20:1 base to servo thread ratio, and not one that > can work at any but a small range of speeds. > > Is there any reason not to use position-interpolated by default? There might be. I don't know how position-interpolated works, but I assume it might introduce a delay in the position reports. This is of no consequence if your spindle speed stays relatively unchanged throughout your threading operations, and you don't reverse the spindle. I could think of some sort of threading operation where you made a finish pass at a different spindle speed, and of course there is rigid tapping, where you need to keep the thread synchronized when the spindle is reversed. So, any significant delay could be a real problem there. Those are the only places I know of where interpolation could cause a problem. Jon -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] threading Z oscillation depends on encoder PPR
Am 22.10.2009 um 20:04 schrieb Jon Elson: > ... > limit, and then the system becomes violently unstable. This is all > just > guessing from too little info, > hopefully we can get some plots of other signals from the stepgen to > see > in more detail what is > happening inside. >> Also note that G33 et-al are position-mode not velocity-mode. axis.2.f-error was just a stab in the dark, it was just the first signal which correlated to the sound stepgen just does what axis tells it to do: http://mah.priv.at/cgi-bin/viewvc.cgi/emc-syncmove/pos-cmd-steprate.png?revision=1.1&root=CVS&view=markup the wobble is already in axis.2.motor-pos-cmd so that takes stepgen out of the picture IMHO the encoder ist out of the picture as well because its simulated and that gives the same effect as the real one I guess I'll look into adding some probing hal pins in tp.c and see wether position update underrun can be observed it's more curiosity at this point - really I dont care too much because I'll fix it with a decent encoder and I think the overall approach - tracking position - is right as opposed to 'ah, index seen - let's jog down that pass' which strikes me a bit of fly-by-night exercise -Michael ps: her's a bonus video - yes, it almost sounded like this: http://www.youtube.com/watch?v=Ht96HJ01SE4 ;-) -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] threading Z oscillation depends on encoder PPR
2009/10/22 Michael Haberler : > > yes - I ran into the problem when switching to hm2 which doesnt > currently provide position-interpolated > Which is an interesting point. It seems that a hardware quadrature counter is likely to be counterproductive if you have a low-count encoder. With a software encoder you need to hit the balance between having enough pulses per servo thread to always get a position update, but not have more than one encoder edge per base-thread. Quite a balancing act with a typical 20:1 base to servo thread ratio, and not one that can work at any but a small range of speeds. Is there any reason not to use position-interpolated by default? -- atp -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] threading Z oscillation depends on encoder PPR
Am 22.10.2009 um 12:21 schrieb Andy Pugh: > 2009/10/22 Jon Elson : > >> Good hypothesis and data taking! So, it seems the problem is the >> encoder counter sees >> a zero velocity between actual encoder counts, and tells the slaved >> axis >> to stop NOW! Then a >> count comes in, and it says MOVE NOW! Yes, I can see this is a >> definite >> problem. > > I am not sure that this is the full story anyway. Me neither. I've collected my current conjectures at http://mah.priv.at/txt/sm.txt and asked the emc-devel folks for a review. If that's considered to contain sufficient facts as opposed to factoids I'll put it on the wiki - comments welcome. > The oscillations > are typically nothing like encoder frequency (say 200Hz) but nearer 5 > Hz. I dont think the oscillations relate to encoder frequency per se but to the rate at which the TP sees an unchanged position between subsequent TP cycles - it's a spindle-speed and PPR dependent problem after all. The speed at which the corrective action is taken after a hiccup (stopping or accelerating the dependent axis) depends on axis acceleration and speed. That was clearly visible after I tried your suggestion in fiddling with acceleration - higher acceleration resulted in lower f-error and higher oscillation frequency (which happened to taper off faster of course). maybe one should view it differently - the encoder creates a stream of *changed* position updates and the TP consumes it (only changed/ reasonably accurate position reports make sense). If the encoder falls behind due to quantization the TP starts stuttering. The relative speed could be subject to all sorts of fluctutations and delays, which could explain why some passes sort of look ok and some stutter > Also note that G33 et-al are position-mode not velocity-mode. > > The simple solution might be for stepconf to always connect to > position-interpolated rather than just position. yes - I ran into the problem when switching to hm2 which doesnt currently provide position-interpolated > With a good encoder > this seems to work fine in most cases as long as the axis > accelleration is adequate. yes, I'm out in shopping mode.. -Michael -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Feedrate
I'm confused by your question, so my answer may be off the mark. In my configuration for a linear axis, I have INPUT_SCALE set to 2048, that is, 2048 steps per millimeter. You need to set that up first for rotary axis, the number of steps per degree. You mention 120,000. Is that 120,000 steps per revolution? If so, that is 120,000/360 steps per degree. Once that is configured, you can set F to be in degrees per min. (or radians, or whatever your preferred unit is) > -Original Message- > From: Ian W. Wright [mailto:watchma...@talktalk.net] > Sent: Thursday, 22 October 2009 7:32 PM > To: emc-users@lists.sourceforge.net > Subject: [Emc-users] Feedrate > > Hi, > > Is there any way of multiplying or dividing feedrate? On the > little gantry system I have just set up the rotary axis is > driven by a microstepping stepper driving a worm and wheel > and so, at the moment, G0 corresponds to a feedrate of around > 120,000! I want to maintain the input accuracy of the present > system but it would be nice to be able to enter the feedrate > as a more sensible number rather than having to use F10 > or so. I assume I could probably do something with > OUTPUT_SCALE but would that affect my accuracy? > Also, one of the axes moves correctly under MDI but the > reading is reversed in AXIS - is there a way to change this > - I can't see one in the AXIS documentation. > > Thanks, > Ian > __ > Ian W. Wright > Sheffield UK > > -- > > Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] threading Z oscillation depends on encoder PPR
Andy Pugh wrote: An alternative might be to keep things much as they are, but to have a parameter in the G-code for how much "run up" it has. It then becomes a somewhat simpler trajectory planner issue to get to the thread start at the right speed next time the index comes round on the unloaded spindle and only then to enter the current position-feedback mode to stay on-pitch and allow for spindle velocity changes. I think that might actually be the essence of how Chris' patch works, though that just waits to get a better spindle speed estimate I think. Greeting to all This may be another "data point". "Another PC based controller" produces pretty decent threads even on a low powered spindle like the Tormach Duality with only one pulse per rev. by not attempting to solve the general problem. The threading code (G32) watches index pulses until it sees several with a consistent timing. That gives the spindle speed and with the requested pitch (F word) gives the Z feed in units/min. Now the Z (and X for tapered threads) trajectory can be planned from the current Z position. On seing the next index the trajectory runs. To get a clean start one cuts a few threads in air over the acceleration period. So there is no exact thread position on the stock - it all depends of the acceleration - but multiple start threads work out fine by keeping the same spindle speed and starting with Z 1/2. 1/3 etc. of a pitch greater. The actual code does a running correction, if the spindle speed droops, effectively by using the feed rate override logic . I think it might be better to recognise a rise too as an overcompensated spindle drive can speed up on taking the cutting load - but that is a detail and was not done as FRO upwards could at one time violate the motor tuning parameters. This is by no means an electronic gearbox but needs no tuning and is surprisingly effective for turning even long threads. John Prentice -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] threading Z oscillation depends on encoder PPR
Andy Pugh wrote: > 2009/10/22 Jon Elson : > > >> Good hypothesis and data taking! So, it seems the problem is the >> encoder counter sees >> a zero velocity between actual encoder counts, and tells the slaved axis >> to stop NOW! Then a >> count comes in, and it says MOVE NOW! Yes, I can see this is a definite >> problem. >> > > I am not sure that this is the full story anyway. The oscillations > are typically nothing like encoder frequency (say 200Hz) but nearer 5 > Hz. > Right, I guessed around 2 Hz, but they are not plain oscillations, ie. not at all sinusoidal. The axis.2.f-error was a sharp-edged, straight-sided triangle wave, indicating some function feeding the velocity was giving a square-wave signal, ie. hard limiting. What I BELIEVE is happening, is that the coarse granularity of the encoder signal is exciting the velocity logic to ram into its output limit, and then the system becomes violently unstable. This is all just guessing from too little info, hopefully we can get some plots of other signals from the stepgen to see in more detail what is happening inside. > Also note that G33 et-al are position-mode not velocity-mode. > But, stepgen needs to convert to velocity to know what step rate to generate until the next servo cycle. I think this is where the oscillation is coming from, but the root CAUSE may be from violent fluctuations in the commanded position going in, requiring the velocity to change faster than the algorithm can handle. Once it has been upset, it seems to not recover gracefully. > There might be an argument for using a more sophisticated PID type > controller, but the correct P. I and D would almost certainly be > strong functions of spindle speed. Add to that the complication that > you are trying to control to position but are limited by velocity and > acceleration and it becomes difficult to think about, let alone work > out how it should be coded. > Agreed that for rigid tapping, which needs to follow the exact path from BOTH directions with minimum position lag, this is not easy. Jon -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] How many quadrature encoder counts per inch in a commercial servo system.
>> This caused me to wonder... How many encoder pulses per inch does a professional CNC machine use. My lathe - a commercial "hard turn" machine that I bought from Timken only has 2450 pulses per inch of travel on both axes. It was originally setup to turn semi hard bearing races prior to heat treating and grinding. The encoders are mounted right on the axes ball screws. So I guess they figured that they will cut the races to within a couple of thou, then heat treat them and grind the bearing cups to much tighter tolerances. The machine was really setup for high volume production with a 20' bar feeder, parts catcher, pressure lube on all of the ways etc, etc. So as John said I think it all depends on the machine and what it is designed to do. Dave cogoman wrote: > Thanks to Sven Wesley I was impressed by the AMT102-V Versapak > quadrature encoder available at Digi-Key. With 2048 PPR, which could > get 8192 quadrature increments it could give me a possible solution to a > router axis drive. Using skateboard bearings to support a 5/16" rod, a > DC motor could drive the rod with O-rings and pulleys. A fine steel > stranded cable wrapped around the rod many times would release about 1" > of cable per revolution. With 8192 steps per revolution, there would be > about 250u inches per encoder step. > > This caused me to wonder... How many encoder pulses per inch does a > professional CNC machine use. > > When we were swapping drive cards on our FADAL 4020, I seem to > remember the following error getting to around 60 encoder pulses (or at > least I think the controller was listing error in pulses) at a fairly > fast feed rate, and the machinist said that was in the normal range. We > recently discussed this and it seems that cutting around the outside of > a square part, which is usual for us, the end mill would come to a stop, > allowing the servo motor to catch up, before the 90 degree turn to mill > the next side. Also, the final cut is usually at a lower feed rate > which should have less error. > > So, are there enough encoder pulses per inch to make 60 pulses off a > very small error around 200u inches, or could it be that having a servo > that's behind by a couple of thousandths during heavy material removal > doesn't adversely affect the size achieved during the final finish cut. > > Or, in the immediate application, could an encoder count that gives > 250u inches per encoder pulse allow the system to cut with accuracy > better than .001" in the final part. > > -- > Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > > -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Axis database connectivity
Good idea, I have been thinking about the tool table being in the data base for a while. Fully automated manufacture here we come. Dave Caroline -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] threading Z oscillation depends on encoder PPR
2009/10/22 Jon Elson : > Good hypothesis and data taking! So, it seems the problem is the > encoder counter sees > a zero velocity between actual encoder counts, and tells the slaved axis > to stop NOW! Then a > count comes in, and it says MOVE NOW! Yes, I can see this is a definite > problem. I am not sure that this is the full story anyway. The oscillations are typically nothing like encoder frequency (say 200Hz) but nearer 5 Hz. Also note that G33 et-al are position-mode not velocity-mode. The simple solution might be for stepconf to always connect to position-interpolated rather than just position. With a good encoder this seems to work fine in most cases as long as the axis accelleration is adequate. There might be an argument for using a more sophisticated PID type controller, but the correct P. I and D would almost certainly be strong functions of spindle speed. Add to that the complication that you are trying to control to position but are limited by velocity and acceleration and it becomes difficult to think about, let alone work out how it should be coded. An alternative might be to keep things much as they are, but to have a parameter in the G-code for how much "run up" it has. It then becomes a somewhat simpler trajectory planner issue to get to the thread start at the right speed next time the index comes round on the unloaded spindle and only then to enter the current position-feedback mode to stay on-pitch and allow for spindle velocity changes. I think that might actually be the essence of how Chris' patch works, though that just waits to get a better spindle speed estimate I think. -- atp -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Axis database connectivity
Hi, I've written a simple python script for Axis, which allows you to retrieve your gcode from a mysql database. If anybody is interested in this, the details are on my site at: www.andyshelley.co.uk/emc/index.php. I've also posted this link on the linuxcnc forum. Thanks, Andy. -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Feedrate
Hi, Is there any way of multiplying or dividing feedrate? On the little gantry system I have just set up the rotary axis is driven by a microstepping stepper driving a worm and wheel and so, at the moment, G0 corresponds to a feedrate of around 120,000! I want to maintain the input accuracy of the present system but it would be nice to be able to enter the feedrate as a more sensible number rather than having to use F10 or so. I assume I could probably do something with OUTPUT_SCALE but would that affect my accuracy? Also, one of the axes moves correctly under MDI but the reading is reversed in AXIS - is there a way to change this - I can't see one in the AXIS documentation. Thanks, Ian __ Ian W. Wright Sheffield UK -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
