I think I would like a variation on M208

fcwilt

Hi,

Now perhaps I am simply overlooking the obvious and this suggestion makes no sense.

Just the same, I am thinking I would benefit from a variation of M208 which would be used to set limits based on User Position, as opposed to Machine Position as M208 does.

Right now I am working on a printer that allows tool changing.

And as suggested the Z probe offsets are all 0 and the tools offsets are with respect to that.

When a tool is mounted the M208 limits don't have the desired effect as the tool offsets result in allowing the tool to positioned outside the bed, typically running into other parts of the printer.

Yes, I can adjust M208 for each tool as needed but it would be simpler to be able to use a single command to prevent the User Position from exceeding desired limits.

That type of limit, with the same settings, would apply to any tool regards of offset settings.

Just my two cents.

Thanks.

Frederick

oliof

@fcwilt if you set the tool offsets with G10, they should apply towards the reference head point, which is Tool 0, to which M208 applies. Is that not sufficient in your case?

fcwilt

@oliof said in I think I would like a variation on M208:

@fcwilt if you set the tool offsets with G10, they should apply towards the reference head point, which is Tool 0, to which M208 applies. Is that not sufficient in your case?

I was going by the E3D motion system configuration as posted by dc32 a long time ago.

For the Z probe there is this:

G31 P200 X0 Y0 Z0

Notice all the offsets are 0.

For the tools there is this:

G10 P0 X-9 Y39 Z-5
G10 P1 X-9 Y39 Z-5
G10 P2 X23 Y41 Z-5.65
G10 P3 X23 Y41 Z-5.65

Based on my testing this makes the Z probe the "printhead reference point" and the axis limits as specified by M208 are referenced to it, the Z probe.

This is the XY part of my M208:

M208 X-150:150 Y-100:100

And sure enough the tip of the Z probe can never be moved outside of those limits (assuming the limits are being respected because M564 H1 S1 has been executed at sometime).

The limits set by M208 apply to machine position, whereas the tool offsets set by G10 change the user position when a tool is active (T0, T1, T2 T3 have been executed).

It's true that a normal G90 G1 move puts the tool where expected. For example G90 G1 Y100 moves any of my tools to Y=100.

The problem is the machine position at the point is Y=63 because the tool Y offsets are all Y=37.

Thus you can, using G90 G1 moves, also move the tool anywhere in the Y range from Y=100 to Y=137, which is off the print bed and can strike other parts of the printer.

Maybe there is a better way.

Frederick

T3P3Tony

@fcwilt I see what you are saying. I have a range of different tool sizes in my tool changer and the pickup head without a tool fitted is what I set my axis limits with (because I home without a tool picked up). With a tool picked up I cannot reach the limits without crashing.

On your machine would the tool specifically limits always be inside the machine limits?

oliof

@T3P3Tony I would adjust the M208 limits in the tool change macros but I can see how that's fraught to errors if a tool change fails or tool change with P0 is required.

T3P3Tony

@oliof yes it not ideal. For some situations the idea of a per tool keepout zone can work.

fcwilt

@T3P3Tony said in I think I would like a variation on M208:

On your machine would the tool specifically limits always be inside the machine limits?

The printer has enough extra travel that the tools, even with a +37 Y offset (the X is 0) can reach the entire printable area without any issues with hitting other bits.

What I have resorted to is a routine, called set_axis_limits, which accepts one or two parameters, that I call at appropriate times, to modify the M208 limits.

The routine does the math based on values from the object model and the only constants were the values needed to allow reaching the tool mounts when changing tools.

They were not hard to determine, The only "risk" is being sure to call the routine at the right times with the right parameters.

It may be the only practical way given the issues accompanying a tool changing feature.

But I have a gut feeling there is a better way that would require some firmware features added, basically doing in firmware what I now do in code, but the firmware would always make the right adjustment at the right time.

Frederick

fcwilt

@oliof said in I think I would like a variation on M208:

@T3P3Tony I would adjust the M208 limits in the tool change macros but I can see how that's fraught to errors if a tool change fails or tool change with P0 is required.

That is what I am now doing but it is not perfect as it assumes, as of now, that everything works as it should.

Dealing with tool change failures is something I need to think more about.

Thanks.

Frederick

dc42

@fcwilt if all your tools are the same size then you should be able to adjust the M208 limits to define the available area that any one of the tools can reach, which will be smaller than the area that the probe can reach. If your tools have different sizes, then either you need to define the available print area in M208 to correspond to the print area that all tools can reach, or change the M208 limits in the tool change files as I do.

In theory we could add a command to specify for each tool the X and Y dimensions in excess of the standard values assumed by M208; but unless tool changers become a lot more popular then I think the existing method of adjusting M208 limits in the tool change files is satisfactory.

fcwilt

@dc42

I agree that adjusting M208 is the most practical solution given the number of customers that would benefit from you spending time doing something in the firmware.

I have one routine that I can pass a tool number, a probe number or put/get flag and it adjusts M208 for each situation.

The code is not complicated, relies on axis and offset values from the object model to do most of the work.

The only hardcode values are those that "expand" M208 to allow safe access to the tool docks.

The only thing I haven't solved is a way to create a "barrier" around the Z axis hardware, which can be struck when doing put/get moves if the put/get code has a flaw.

I quite pleased with the result.

Frederick

dc42

@fcwilt can you use the keepout zone function to avoid the Z hardware?

fcwilt

@dc42 said in I think I would like a variation on M208:

@fcwilt can you use the keepout zone function to avoid the Z hardware?

I don't know if I can use it because I have never heard of it.

Where can I read about it?

Thank you.

Frederick

dc42

@fcwilt https://docs.duet3d.com/User_manual/Reference/Gcodes#m599-define-keepout-zone.

fcwilt

@dc42 said in I think I would like a variation on M208:

@fcwilt https://docs.duet3d.com/User_manual/Reference/Gcodes#m599-define-keepout-zone.

Thank you.

Frederick