Feed rate issues -questions?

I am running ramps1.4 with marlin firmware and repetier host . I have been messing around adding alot of features to my machine and am having an issue with the way the feedrate is done..?To me is doesn't make any sense..I added the g20-g21 codes to swtich between mm and inch.. This works for the x,y,z positions but doesn't seem to work for the feedrate..Feedrate seems to be unaffected by the change..this is the first issue.Second the feedrates don't seem to be in inch or mm.. and they do not appy to the axis like you would think it would .. For instance if i mave the x,y,and z axis an equal distance they will all travel the same speed and finsh the move together.If i move the axis different distances it will slow down the axis that had the least distance to travel to make them all finish the move at the same time?This doesn't make sense why would it make the moves speed up or slow down so they finish at the same time if the feedrate was commanded the same for all axis?.I am not seeing anything in the code that would cause it to do this?if i run just one axis it still doesn't equal out to inches or mm..I have my max speed for my e x and y set to 211 mm per second Which would make me think if i did a feedrate above that amount it would top out at the 211. but it doesnt i have to run a feedrate of 900 to get it to max the speeds of any of the axis when just moving one axis?..

G20 inches measures in inches and standard is inches per minute
G21 mm measures in mm/s and the standard is mm a second


does this help, if same feed rate numbers are used for inches, machine would slow down by 2/3 as the timing is in minutes

my guess is the limits hard-coded in mm for max feedrate, are limiting machine speed either way.

are you typing in G1 or G0 at beginning of code, G0 is machine each axis at max speed, G1 is all axes moving in parallel or in 3 axis motion helical mode together and moves average out.

there are now, or will be in the near future programming limits for x,y,z axis based on extruder capability as well to increase print quality and reduce issues.

ok you asked for it so here are the answers:

[reprap.org] Reprap gcode
[www.nist.gov] gcode standard NIST RS274NGC
[reprap.org] reprap acceleration and Trajectory Planning

Edited 7 time(s). Last edit at 11/08/2014 11:58PM by jamesdanielv.

Looking at the code the g0 is a g1 in marlin so it doesn't matter if it is a g1 or g0 it will do a g1..Which is crazy how is doesn't do a g0 which is a rapid movement and the g1 should be a feedrate movement. but it is averaging the speed across the three axis rather than setting the feedrate for the axis as commanded..If feedrate 50 in g20 mode the axis should all move at 50 inch per minute not some divided speed that makes them finish at the same time at who knows what speed?how would you know what speed a given axis is moving if it is not moving at the feedrate set ..??

ok it looks like marlin does process g0, g1 codes the same from Marlin_main.cpp, but with using g0 i do not need to include feedrate. the difference could be how my host program handles it. that should not effect process of commands of the general use of the machine however, as within reason x/y axis should be the same speed.

are you sending z commands all the time?

for some machine setups in the past to get your faster feed rate you would type two lines because it use to be that the planner calculated on last feed rate stored. so if it was zero it would ramp from zero up to feed rate specified. if the buffer had a move previous it would start from that speed. I do not know how relevant it is currently, but it is worth a try to send the commands.
F1500
G1 X10 Y10 F1500


switch((int)code_value())
{
case 0: // G0 -> G1
case 1: // G1
if(Stopped == false) {
get_coordinates(); // For X Y Z E F
#ifdef FWRETRACT
if(autoretract_enabled)
if( !(code_seen('X') || code_seen('Y') || code_seen('Z')) && code_seen('E')) {
float echange=destination[E_AXIS]-current_position[E_AXIS];
if((echange<-MIN_RETRACT && !retracted) || (echange>MIN_RETRACT && retracted)) { //move appears to be an attempt to retract or recover
current_position[E_AXIS] = destination[E_AXIS]; //hide the slicer-generated retract/recover from calculations
plan_set_e_position(current_position[E_AXIS]); //AND from the planner
retract(!retracted);
return;
}
}
#endif //FWRETRACT
prepare_move();
//ClearToSend();
return;
}

perhaps you are running into firmware limits for speed?
[reprap.org]

so calculations for motion are based on the breshimham method that interpolates moves [en.wikipedia.org]
so each axis moves at a rate of the master axis. if the rate is to fast for the firmware then all the speeds will be reduced.
please read about [reprap.org] reprap acceleration and Trajectory Planning

this may help for tool motion with individual moves versus moves in a planner.

post your configuration.h file, and i'll take a look at it to see if some setting needs to be changed.

also what version of printer are you using and are you using belts, or lead screws or slides. a picture would also help. also are you using a custom version of firmware? or one downloaded. what version is it.

it seems you have been having issues for a while, reading some of your other posts. what is your goal of using the machine in inches?

Edited 7 time(s). Last edit at 11/09/2014 12:06PM by jamesdanielv.

My machines are custom built cnc plasma,mill and 3d printers I.my machines vary in size from 2x2 to 5x10.. use gt2 belt for the x and y axis and acme screw for the z axis.I use the latest marlin firmware that has alot of mods I did..one of the biggest reasons I need it to run in inches and use the standard g codes is I have over 1500 files I have done over the last 5 yrs for my cnc plasma and mill that I don't wanna have to redo to run on these machines.. not to mention I grew up and live in america so my standard way of thinking in in inches....
Another reason is for cnc plasma it is super important to maintain proper cut speed for good cut quality.so having the axis average out in speed is not gonna work

so the issue is that your custom machines are using a printer firmware for non printing tasks, but needs to use a cnc code code?

in that case the answer is simple. don't use a printer firmware designed for printing. use grbl.

firmware link [github.com]

perhaps i've overlooked something, either way let me know.

the reprap marlin firmware has been made specific for 3d printing. if the issue is speed, then you need to address that of course. check out grbl. again there are limits in performance of firmware, based on step size and feedrates.

for plasma and laser cutting i always recommend specialized dsp processor boards, because arc angle and lead in time needs precise control.

I still would like to see your configuration.h file to see if there is something that can be done to help improve speed, and images would be a plus to see what machine you have.

would you like a parser script that would auto convert your inches to mm?

Edited 7 time(s). Last edit at 11/09/2014 06:09PM by jamesdanielv.

This has been a big help i figured out what was happening making it act so inconsistant. Now the thing i need to figure out is how to make the feedrate be in inches when in g20 mode ..But the main issue i was having was the way it makes the axis balance the feedrate when more then one axis is in a line ..And the fact it will limit the axis to the lowest max feedrate of the slowest axis when more than one axis is in a line..But now that i see what it is doing i can change the post processor or the firmware to fix the issue.This has been alot of trial and error as noone has done this before making one machine to do it all.. And since i want a machine that can do it all without changing things to go from one to the other adds a bunch of issues to overcome. I guess having yrs of working with mach3 ,torchmatecad and other softwares have made it harder to get in touch with grbl based softwares.. As most of the other g code running software work very similar to eachother but grbl does alot of things differently ..

Some of the issues i have been running into are because most grbl based firmwares are for 3d printing,cnc milling but just that and nothing else.The problem is i am trying to keep the 3d printer,cnc mill,and add cnc plasma,vinyl cutter,and other things like plate markers and others to start .. All of this while keeping it able to run without being tied to a computer..So i have set my goal pretty high i am getting really close just putting a few missing links together ..I want it to be able to run files made for plasma,milling or 3d printing without having to go into the firmware everytime.. Also wanting it to run metric or standard without any changes ..That new grbl looked pretty promising .i tried to post a few pics but all my pics are to large to upload

i still think there will be issues in using plasma and laser cutting equipment, but likely only at higher speeds. signal strength or pwm, and angle velocity for arcs need rapid calculations that so far only have been mastered by dedicated parallel dsp processors that are >400$ but well worth the cost. they often use HPGL language, and have a lot of internal memory.

for example with laser and rastering, you need a very rapid feed rate that can not slow down to burn surface of object with a set time over image and pwm power, and airflow. any change in speed would be noticeable and produce scrap. for any level of production of laser or plasma i would recommend the higher power processing of dsp, to save costs.

but then again, this is one area i would be happy if you did prove me wrong and lowered the cost of processing for the entire community. if you have success you should post your notes in follow up links

i do have plans for laser in the future with the machines..There is no doupt laser would require a more powerful processor.For plasma it requires high accell rates and being able to maintain speeds in corners and such to be able to get good cut quality without dross..which so far has shown to be totally possible with marlin -ramps.. pretty much the highest cut speeds you will ever need for plasma is less than 400 inch per minute .. Most of the times it is less than 250 inch per minute unless cutting super thin metal like 20 gauge or less...With my machines i am able to maintain super high accell rates with feedrate over 500 inch per minute without loosing steps....My plan with the electronics is to make them where they can run the open source softwares or be upgraded to high end softwares as people get into it more..Well unless i can work the high end features into the open source community.

i have been making alot of progress on this set up but i am still having one feedrate issue?When i do a g20 the feedrate is still in mm per minute when it should be in inches per minute?Where would i find the code i need to change to fix this i have been digging thru it for a few days now with no luck?

I just double checked the patch I did and the feedrate is multiplied correctly in both relevant lines. (In independent F code handling on line 3785, and in get_coordinates() on line 3919.)

What speeds are you expecting and what are you measuring? Could it be as simple as the feedrate limits preventing you from reaching the expected speed? The default max speed is 500 mm/s or 20 inches/second, the gcode sample you posted earlier requests a feedrate of 50 inches/second.

I have my limits set to 211 mm per sec which should put me just under 500 inch per minute for max v. If i do a g20 in repetier the do a g1 f50 next i do a g1 x50 y50 it will move as if it is set to 50mm per minute-slowww..if i do a g1 f12700 then g1 x50 y50 it will move at the max v i have set .. even if in g20 mode