Prevent Travel moves from going over a bed area

zapta

I presume that the offending moves are travel rather than print. Write a script that will post process the gcode file and replace the bad moves with detours?

It will require some work, programming wise, unless if somebody else already done that. If the bad moves are straight lines that cross the center circle, programming should be easier as it sufficient to process each gcode line independently.

Edit: Here is a sample script that modify one gcode command to another. In your case, the move command will be replaces with a few detour moves. https://pastebin.com/VSH7820B

o_lampe

@cncmodeller Most slicers can print two or more objects after another (consecutive print). What if you create an dummy object in the center of the bed as first object and let the real object be around part 1. The slicer would slice both, but the paths of the second part will not cross the center.
Now you only have to delete the first object in gcode.

T3P3Tony

@cncmodeller I will move this to the firmware wishlist as I think we may want to add a feature request to polar printers to convert an invalid G0 path to a valid one, by diverting around the centre instead of pausing the print. I don't know how much work that would be though so a slicer based solution would be good for now.

JoergS5

I would propose a different solution. The reason for the singularity in the center is, that the rotational movement approaches zero. The movement as such is printable for g0/g1 moves with the linear axis, so it's not a real singularity (only mathematically, but not a real world printer with nozzle width). The 0,0 is reachable, but one cannot rotate at this point. A solution is to allow zero rotational movement while crossing the center. When the rotational movement is below a threshold, it should be set to 0 in this case, so the linear axis can move with normal speed. The movement is segmented, so this 0 rotational speed can be set for a few of those segments. The advantage is, that printing at 0,0 will be possible.

T3P3Tony

@joergs5 Ahh i see. Lets see what @dc42 suggests.

CNCModeller

Thanks for the input gents, a firmware based approach would be an ideal solution.

Lets see what @dc42 thinks and take it from there.

I have been thinking on this and now that the M669 A and F values are working as long as the path doesn't go directly over 0,0 in theory the printer should be able to cope as the rotational speed will be capped. My Radius axis can reach 0,0 as I use the nozzle there to tram in the printer axes, so in the short term I could set my min printable radius to 1mm to minimise the likelihood of pauses.

Thanks both for the insights!

Cheers
Barry M

o_lampe

@joergs5
Would the printer still know where it is after crossing the center?

When the rotational movement is below a threshold, it should be set to 0 in this case,
so the linear axis can move with normal speed. The movement is segmented, so this 0 rotational speed can be set for a few of those segments

To me it sounds the same as if the rotational axis would skip steps (with the well-known consequences).

The reason for the singularity in the center is, that the rotational movement approaches zero.

The required angle-speed close to the center is also a problem. You might be able to approach the area around 0,0, but with a given angular speed limit, the Y-move has to slow down a lot.
AFAIK, RRF doesn't make a difference between G0 and G1 moves regarding speed limits? It treats both as combined move

JoergS5

@o_lampe said in Prevent Travel moves from going over a bed area:

with a given angular speed limit, the Y-move has to slow down a lot.

this is what is addressed by setting the stepper of the angular speed to 0, when approaching (0,0). Then the linear stepper and the extruder can move full speed.

Would the printer still know where it is after crossing the center

Strictly speaking, the printer nevers knows where its steppers are (ignoring closed loop and absolute encoders), firmware has been told where they are by homing. Firmware assumes they are at a specific position and there were no lost steps, and stores this information in a counter (steps*microsteps).

The firmware has all available information about stepper changes since homing (because he sends all stepper commands) and internal stored positions (can be seen in M114 Count values) and can correct it if needed. E. g. if the rotational stepper is stopped, the internal counter for stepper's position should be stopped also.

doesn't make a difference between G0 and G1...regarding speed

I am not sure about this, but I also expect they are handled the same way, but can have different maximum speeds.

JoergS5

A separate solution is to turn off segmentation for this special (0,0) move, because the rotational stepper will have a fixed starting speed which will not change during the move. But the resulting straight line will be curved, and I don't know how much. Maybe it's acceptable for a short line.

o_lampe

I was wondering, if a FW-solution for this problem would also help implementing infinite rotation for rotary axes?
Two flies with one clap

JoergS5

This post is deleted!