Prevent Travel moves from going over a bed area

[CNCModeller]

Hi All,
I have a polar printer and it has a region in the centre of the bed that is excluded due to the kinematics of the printer.

I've recently started printing larger "hollow" prints that fit around the centre of the bed, however sometimes a travel move attempts to go through the excluded region. My question is do any of the slicers have a feature that prevents travel moves from entering a region of the bed?

The duet appears to pause the print because the excluded bed area is going to be crossed rather than diverting around the area, e.g. via its perimeter.

CURA has nozzle_disallowed_areas but these just appear to prevent you from slicing a model that intersects them. In my case the model its self does not intersect the centre of the bed, but because the centre of the bed is within the outer bounds of the model cura wont allow me to slice it.

I'm only using CURA as its the recommended slicer for this model, its a model aircraft I got from "PlanePrint". These files are not your average solid model, rather a load of surfaces that when printed individually intersect to form a structure.

Any thoughts? I'm stumped.

Cheers
Barry M

[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!