Cannot do G1 with zero feed rate

Hello, I´ve been trying to make an object on Rhino, but everytime i try to run the post process, the machine goes to measure the tool and before it comes back it appear this message " Cannot g1 with zero feed rate", i dont know how to fix it and im looking for help as i really need to get this done ASAP, its the first time this error occures and the guys that sold me the software and gave me instruction and is supossed to be helping me its not replying to my messages, so this is my last resort.
Thank for your time.

1 Like

There is no CAM that is native in Rhino, so you must be using some plug-in or stand alone program to create your G-Code. Which one?

1 Like

sory, i dont think i understand the question, i use Rhino-Cam, ill atach a screenshot

Hi Avvelino -

You can find the RhinoCAM forum here: RhinoCAM Topics & Support - MecSoft Corporation
You should also be able to get support from support@mecsoft.com
-wim

1 Like

thank you, i will try it.
thank you!

You can also post the RhinoCAM file with the operation in question, there are a few people here who can test.

1 Like

OHH,i would apreciate it very much, will do it right now if someone can test it and maybe find whats wrong i would apreciate!
thanks all for the time and replys

botao.3dm (1.1 MB)

Hmm, I can post the first operation in your file no problem and I don’t see any lines with G1 that don’t have a valid nonzero feedrate associated with them (FXXX.xx). So I guess you are going to need to consult directly with Mecsoft on this one, I don’t know what might be causing your machine to think there is a G1 with a zero feedrate.

1 Like

OK, thank you very much for your time

Put it on the list of reasons not to use mecsoft’s version of moduleworks.

Either your post processor is trying to post 0 rate feeds, or it did and your machine is trying to feed at 0 rate.

Either way, you’ll need to fix your post processor, or switch cam software.

All cam softwares are permutations of moduleworks/machineworks – show me ones that aren’t.

All cams are setup to be more difficult than they should be.

Rhino needs a better cam plugin.

1 Like

I cannot confirm this, I posted the operation and the code has no lines like that. However, I don’t know how the machine interprets the code. The operation looks fine to me, there is no need to blame RhinoCAM’s toolpaths for this IMO. I don’t know the machine - it’s a 5 axis - but if there is an error somewhere, it is most likely in the configuration of the postprocessor.

1 Like

In that case (if the error is from the machine) then maybe the machine requires ‘inverse time feed’, and isn’t receiving it.

Or the post can’t post 5-axis simultaneous without inverse time feed, etc – does mecsoft even have fully functional 5-axis yet, I mean it’s been over 10 yrs since they said they would :sleeping:

Technically mastercams 5-axis isn’t fully functional either. So, it’s not just mecsoft.

And ultimately it’s moduleworks that’s causing the primary obstruction, not just the private-labelers.

Even the machines themselves cause obstruction.

My umc haas does allow regular ipm feedrate, but since 5-axis technology is still so under developed, and inaccurate, I just do 3+2 most of the time. So, I don’t even bother worrying about if its running inverse time. It’s something I used to worry about on a fadal built in the 90’s. But 3+2 hurdles that anyway.

1 Like

Well, it’s not actually 5 axis code, just running on what looks to be a 5 axis machine - either that or they just used the wrong post. It only sets the axis A and B to zero at the tool changes and that under G0, so on inverse time feed needed. Thereafter it’s all XYZ.

2 Likes

Without seeing the code, I’d have to wonder if maybe there’s any F-codes without the ‘decimal’?

Even then still weird it would be interpreted as 0 so idk.

But one of my fadals likes to take ‘F50’ for example and turn it into something like ‘F0.0005’ (which is basically 0 :sleeping: :sweat_smile:) if it’s not written ‘F50.’.

I suppose it might also be possible the particular machine doesn’t use ‘feed rate’ in a modal sense, and might need redundant F-codes … or say jumping from G00 to G01 without reinstating the feed.

And there’s some controls I know of where the circular interpolations of G02 G03 are not modal, and still may require G01 after.

I’ve also seen controls that don’t like blank lines, comments, special characters, etc.

So, never know how machines will hiccup over certain block sequences…

1 Like

Thank you everybody trying to help, i allready reached out to MecSoft and we are trying to fix the problem.
Thanks!

1 Like