Hello Guest it is March 18, 2024, 10:56:38 PM

Author Topic: Possible Feed Rate Bug?  (Read 3080 times)

0 Members and 1 Guest are viewing this topic.

Re: Possible Feed Rate Bug?
« Reply #10 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
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Re: Possible Feed Rate Bug?
« Reply #11 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...

Offline smurph

*
  • *
  •  1,544 1,544
  • "That there... that's an RV."
    • View Profile
Re: Possible Feed Rate Bug?
« Reply #12 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
Re: Possible Feed Rate Bug?
« Reply #13 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.

Offline smurph

*
  • *
  •  1,544 1,544
  • "That there... that's an RV."
    • View Profile
Re: Possible Feed Rate Bug?
« Reply #14 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