Dumb question about travel limits

deckingman

@stephen6309 said in Dumb question about travel limits:

@mrehorstdmd The axis won't go past the setting you made in M208. Once homed, the controller won't send it past the maximum or less than the minimum setting.

I can confirm that this is so. I once attempted to print something which was about 400mm diameter on a build plate where the limits were set to 410mm in Y but only 390mm in X. The resultant part was a "D" shaped circle with a flat

oliof

@deckingman I tried to print a large box on a delta once. Got nice fillets (-: For this the kinematics need to implement the feature to check if a move would go out of bound and limit it to stay within the bounds of the reachable area. Cartesian, Core, and Delta kinematics have this implemented. It's the one thing I can't figure out for the Tripteron ...

mrehorstdmd

@deckingman Does it do it gracefully- i.e. does it apply acceleration - or does it just slam into the end of the axis when it gets there?

It's the slam that causes the problem in my situation. The kinetic energy ends up as electrical energy on the power supply line. If the controller applies the acceleration/jerk set in the config.sys file it shouldn't be a problem.

mrehorstdmd

@oliof The slicer should prevent you from trying to slice an object that doesn't fit entirely within the printable area of the bed. Of course, you can make an error in defining the bed size, or the position of the origin that could still allow a print that won't fit to get sliced...

deckingman

@mrehorstdmd said in Dumb question about travel limits:

@deckingman Does it do it gracefully- i.e. does it apply acceleration - or does it just slam into the end of the axis when it gets there?

TBH, it was so long ago that I can't really remember. I don't recall seeing anything alarming but then the print head would only have been travelling at a modest speed of 60 to 80mm/sec or so. Also being circular, the print head continued to travel in Y but not in X. So it was more a case of an earlier than expected change of direction of segmented moves, than a sudden end of a single long move. Sorry, that's probably not much help for your situation.

oliof

@mrehorstdmd yes, it was sliced with the wrong profile.

mrehorstdmd

I guess I just need to run a test on my printer at low speed and see what happens.

JoergS5

@mrehorstdmd in my understanding of the code,

if the printer is in laser or cnc mode, it doesn't process the G1 move and aborts the complete move with "G0/G1: target position outside machine limits".

If in other mode, it checks whether an intermediate position is reachable and processes this partly move. The reachability is additionally checked with the option to move part of the axes (uncoordinated move of coordinated axes).

Those checks are done before the move is segmented. Segments are additionally checked in case of a segment is unreachable. This is especially for arc moves and kinematics with nonlinear behaviour like scara.

G2/G3 moves are handled differently: if the end position is not reachable, it completely aborts with "G2/G3: outside machine limits".

The checks whether a move is reachable or partly reachable is implemented kinematic specific (in method LimitPosition). Sometimes M208 limits are considered, sometimes not (CoreXY considers M208 limits).

JoergS5

@oliof said in Dumb question about travel limits:

Tripteron

may I ask an OT shortly? Do you use Tripteron with RRF and how? I thought about developing kinematics for it because patent will expire in september this year, but are you able to use it today?

oliof

@joergs5 I have an implementation of the colinear tripteron kinematics, but am missing the algebra to detect whether a move is inside the reachable volume or not. I didn't build it for quite a while but since the implementation is largely self contained it should probably still work.

As you may remember we discussed working on alu dibond living hinges a while back but then you fell into a 6dof robot shaped hole (-;

https://github.com/oliof/RepRapFirmware/tree/colinear-tripteron

parallel tripteron in a box frame is fully Cartesian and doesn't need any code changes.

dc42

@mrehorstdmd said in Dumb question about travel limits:

In config.sys we can set maximum travel speeds and accelerations, as well as minimum and maximum ordinates for each axis. How does Duet handle a gcode file that commands movement beyond axis limits? Does it "replace" the gcode commanded travel distance with a value that will stop at the set limit? Will it apply the set acceleration to the new ordinate?

In FFF mode it will limit the coordinates so as to be within the printable area. This handles the case of a skirt being outside the printable area even though the print is within it.

In CNC or Laser mode the job will be terminated with an error message.

JoergS5

@oliof said in Dumb question about travel limits:

you fell into a 6dof robot shaped hole (-;

yes, it's a very deep and dark hole and I haven't found my way out of it yet

When the patent of Tripteron is expired, I may try to build a printer. It should have high precision. When the patent is expired, we could finish the code and push it to the official RRF together.