Machsupport Forum

Mach Discussion => Mach4 General Discussion => Topic started by: Dusty91 on February 23, 2018, 11:32:32 PM

Title: Possible Feed Rate Bug?
Post by: Dusty91 on February 23, 2018, 11:32:32 PM
I have been using MACH4 for quite some time now and noticed that the "Current Feed Rate" DRO displays 90% of the commanded feed rate. This potential error has been present in all versions following 3233, industrial also.
I am not sure if this is just a DRO issue or if the machine is actually only running at 90%. In case you ask, yes the feed rate slider is set to 100% and also using the simulator as motion controller to eliminate any plugin issue.

In September of last year I submitted a support ticket regarding this issue with no response. There also doesn't appear to be any other posts pointing out this potential bug.
I don't know for certain but it seems like this could be an issue for anyone out there rigid tapping, assuming this isn't just a DRO issue, causing desync between spindle speed an feed.

Has anybody else noticed this and is it an actual issue? Curious because I have been reluctant to move from version 3233.
Title: Re: Possible Feed Rate Bug?
Post by: joeaverage on February 24, 2018, 03:10:11 AM
Hi,
I have noticed the same issue, I'm running 3481 although if memory serves it was the same in previous builds.

I assumed that Mach could work out a limited number of trajectories that fitted the required move and it picked that trajectory that had the closest
feed rate to that requested. I didn't regard it as a bug but rather as a 'quirk'. Maybe you think differently.

Craig
Title: Re: Possible Feed Rate Bug?
Post by: Roaster on February 24, 2018, 06:27:12 PM
I wonder if the program is compensating for tool diameter, trying to figure a cutting speed (tip speed) rather than feed rate (tool speed).
Title: Re: Possible Feed Rate Bug?
Post by: smurph on February 25, 2018, 03:02:53 AM
The current feed rate is supplied as feedback from the motion controller.  So maybe there is a timing issue? 

Steve
Title: Re: Possible Feed Rate Bug?
Post by: TOTALLYRC on February 25, 2018, 08:52:38 AM
I haven't noticed this on my DSPMC powered mill but I will take a look today and see what I see. It may be controller dependent.

Mike
Title: Re: Possible Feed Rate Bug?
Post by: Dusty91 on February 25, 2018, 12:32:33 PM
Thank you for the feedback. I am still leaning toward this being a bug rather than a feature.

joeaverage: That would make sense with CV feed rate turned on and the machine slowed down for a corner. Though with CV on or off, if you MDI G1 X10 F100 the dro will show the machine running at 90 units/min.
                  It also doesnt matter what the feed rate is, it always returns 90%.

roaster: Not likely as that would change the spindle speed and not the feed rate. G96 vs G97. Also my tool table in MACH is blank and all tool comp is handled in CAM software.

smurph: Bug is present on completely stock install of MACH using simulator motion controller with zero third party plugins installed. I would see that as best case scenario so MACH should feedback exactly what was it was told.

totallyrc: Bug is only present on versions of MACH4 after 3233. All previous versions display the correct feed rate. Curious to learn what version you are running.
Title: Re: Possible Feed Rate Bug?
Post by: smurph on February 25, 2018, 03:30:24 PM

smurph: Bug is present on completely stock install of MACH using simulator motion controller with zero third party plugins installed. I would see that as best case scenario so MACH should feedback exactly what was it was told.


The Sim plugin is not a motion controller.  It is not real-time and it uses Windows timers to make it tick.  A 10% variance in timing is quite the norm for Windows.  It doesn't feed back exactly what it is told.  It feeds back the feed rate that it is able to produce.  The Sim plugin is used as an example for people who wish to write motion controller plugins.  Therefore, it is written to use the API in a manner that real motion control plugins would use.  I could make it feed back exactly what it was fed from Mach, but that would not be a very good example.  

So the moral to this story is that Sim is not perfect.  Windows is the "bug".  It relies entirely on Windows and every Windows machine will have different timings depending on what components make it up.  A real motion controller will provide better feed rate feedback.  Also, it is common to have some feed rate variance when CV is in use.  You will see the feed rate drop on corners.  How much depends on the acceleration capabilities of the motors.  But a straight line should report a feed rate VERY close to the desired feed rate.  But do keep in mind that not all motion controllers will report the current feed rate at a frequency that appears instant.  Some could only report at 250 millisecond intervals, for example.  Also, the screen DROs will only update at the screen refresh frequency (stock is 50ms) no matter how often the feed rate is updated.  

Steve
Title: Re: Possible Feed Rate Bug?
Post by: joeaverage on February 25, 2018, 05:10:56 PM
Hi smurph,
thanks for that explanation. I have on a number of ocassions believed that I had found a fault with Mach4
only for its behaviour explained and realise its no fault at all but rather a 'quirk'.

Craig
Title: Re: Possible Feed Rate Bug?
Post by: TOTALLYRC on February 25, 2018, 07:24:09 PM
My MAchine shows the propper feedrate in jog, MDI and G-code. Didn't look at which version I was running.

Mike
Title: Re: Possible Feed Rate Bug?
Post by: Dusty91 on February 27, 2018, 06:13:50 PM
Steve,

Thank you. Turns out that was the problem after all. I first noticed the discrepancy last year when I was designing a new screen set and just assumed, something about an a** out of you an me, the issue would translate to my actual motion controller so I reverted back to an older version of MACH.
I would check new versions as they were released but only with the simulator to see if the issue was resolved. So anyway I tried the latest development version on my machine last night and the current feed rate was correctly displayed.

Thanks for the assistance guys. I hope a I didn't waste too much of your time.

Dustin
Title: Re: Possible Feed Rate Bug?
Post by: joeaverage on February 27, 2018, 06:48:04 PM
Hi,
I for one learn't something about how Mach4 operates so my time was certainly not wasted.

Its been my experience that when smurph explains something is like the curtains being drawn back...

Craig
Title: Re: Possible Feed Rate Bug?
Post by: ysymidi on March 01, 2018, 04:51:46 AM
If you adjust plugin frequency higher than 160, you will see the feedrate fluctuate enormously.
( I don't know how it relates in other motion controllers, but my ESS has an option for plugin frequency.)

I think Mach4 has some issue presenting correct feedrate...

Title: Re: Possible Feed Rate Bug?
Post by: smurph on March 01, 2018, 05:17:11 PM
I think Mach4 has some issue presenting correct feedrate...

Be careful with blanket statements like that.  Mach only "presents" what it is fed back to it from the motion controller.  What are you changing?  You are changing ESS parameters in the ESS plugin, not changing anything in Mach.  Maybe ESS has some issue with feed rate reporting at frequencies higher than 160.  But it isn't Mach.  It could depend on the type of G code file you are running as well.  If you are running a 3D file with CV and the ESS is reporting back to Mach faster that it was at the lower frequencies, then you will see more feed rate deviation.  So is it a > 160 ESS problem or just a symptom of faster reporting?  I don't know.  But again, it isn't Mach.

Another issue is motor capability.  Mach will cap the velocity of a move to the slowest motor in the move's capability.  So if X is able to move at 300 inches a minute and Y is only able to move at 200 inches per minute, then Y will limit X to 200 inches a minute in an XY move, even if you set F300. 

Remember, just because you specify F60 in the G code, that doesn't mean the machine is going to actually do that.  CV and motor velocity capping can and will change it if the conditions warrant. 

if the feed rate fluctuations are a symptom of the type of G code being run and you wish to see a more consistent feed rate, you may want to implement some sort of averaging scheme.  One could do that in the PLC script.  But if CV is causing the feed rate fluctuations, you would consistently see a lower feed rate average than what you specified with F in the G code.  Think of F as a maximum feed rate allowed when using CV. 

Steve
Title: Re: Possible Feed Rate Bug?
Post by: ysymidi on March 02, 2018, 05:36:51 AM
I think Mach4 has some issue presenting correct feedrate...

Be careful with blanket statements like that.  Mach only "presents" what it is fed back to it from the motion controller.  What are you changing?  You are changing ESS parameters in the ESS plugin, not changing anything in Mach.  Maybe ESS has some issue with feed rate reporting at frequencies higher than 160.  But it isn't Mach.  It could depend on the type of G code file you are running as well.  If you are running a 3D file with CV and the ESS is reporting back to Mach faster that it was at the lower frequencies, then you will see more feed rate deviation.  So is it a > 160 ESS problem or just a symptom of faster reporting?  I don't know.  But again, it isn't Mach.

Another issue is motor capability.  Mach will cap the velocity of a move to the slowest motor in the move's capability.  So if X is able to move at 300 inches a minute and Y is only able to move at 200 inches per minute, then Y will limit X to 200 inches a minute in an XY move, even if you set F300. 

Remember, just because you specify F60 in the G code, that doesn't mean the machine is going to actually do that.  CV and motor velocity capping can and will change it if the conditions warrant. 

if the feed rate fluctuations are a symptom of the type of G code being run and you wish to see a more consistent feed rate, you may want to implement some sort of averaging scheme.  One could do that in the PLC script.  But if CV is causing the feed rate fluctuations, you would consistently see a lower feed rate average than what you specified with F in the G code.  Think of F as a maximum feed rate allowed when using CV. 

Steve


I'm sorry. I didn't intend to offend anyone...

I didn't know what relates to feedrate fluctuation. What I saw was fluctuating feedrate but with smooth motion.
Title: Re: Possible Feed Rate Bug?
Post by: smurph on March 02, 2018, 02:33:41 PM
I'm sorry. I didn't intend to offend anyone...

I didn't know what relates to feedrate fluctuation. What I saw was fluctuating feedrate but with smooth motion.

No offense taken.  I just want everyone to understand how this works.  We don't write the motion plugins and there needs to be a distinction between Mach's responsibilities and the responsibilities of the motion plugins in these matters.  The end user needs to realize it may be a problem with the plugin and seek help from the plugin vendor.  And I will work with the plugin vendor to correct the issue if they need help.

Not writing the motion plugins is both a blessing and a curse, if you will.  It is a blessing because it allows for competition between motion devices.  Each device fitting a niche that the others don't.  If we wrote the motion plugin, there would likely be only one motion device and it would probably be overkill for a lot of our users.  It is a curse because people assume that we control everything and then don't understand the roles that that Mach and the motions plugins play.  It is definitely a "team effort".  Mach will not do much without a motion plugin and the motion plugin won't do squat without Mach.

So I spend a lot of time pointing out these distinctions.  It is necessary.  It is not a finger pointing game, mind you.  But rather information to help guide a person to a resolution if they are having a problem. 

Steve