Slow down before endstop?

theKM

@jens55 ...the arm sliding/roller was what I was thinking, but just curious about the hookups and g-code, is it just having the new feedrate on the next line with some distance to travel after that?

(I guess line after is the new feedrate, then after that the usual "travel until endstop")

jens55

@thekm, this is one of my homex.g codes:

G91               ; relative positioning
G1 Z5 F6000 H2    ; lift Z relative to current position
G1 H1 X-550 F6000 ; move quickly to X axis endstop and stop there (first pass)
G1 X5 F6000       ; go back a few mm
G1 H1 X-550 F360  ; move slowly to X axis endstop once more (second pass)
G1 Z-5 F6000 H2   ; lower Z again
G90               ; absolute positioning

This is on a 500 mm x axis hence the '550'

chimaeragh

@thekm May need to use conditional gcode in this one

fcwilt

@thekm said in Slow down before endstop?:

@...the arm sliding/roller was what I was thinking, but just curious about the hookups and g-code, is it just having the new feedrate on the next line with some distance to travel after that?

(I guess line after is the new feedrate, then after that the usual "travel until endstop")

If you can arrange things so that the sensor is triggered a suitable distance before the end of travel and remain triggered until the end of travel I believe you would be fine with one sensor, be it a micro-switch equipped with a roller, an IR sensor, an inductive sensor, etc.

The important thing being is that the sensor cannot be struck by the moving part.

For example on one of my printers that uses the IR sensors the axis is 300mm long and the sensor triggers at 280 and remains so until 300.

So even at a high speed there is plenty of time for it to stop. Then I back off a bit and do it again at a slow speed to improve accuracy.

Frederick

theKM

@fcwilt the backup-and-go-again is an accuracy thing. In my case, it's the stopping at speed that is the problem. it really needs to decelerate to go slow before being told to stop.

fcwilt

@thekm said in Slow down before endstop?:

@fcwilt the backup-and-go-again is an accuracy thing. In my case, it's the stopping at speed that is the problem. it really needs to decelerate to go slow before being told to stop.

Well if you can say with certainty how long it takes to stop then you can position the one sensor at an appropriate location.

The important thing is that the sensor remain triggered from that position until the end of travel.

Normal moves have controlled acceleration/deceleration. I don't know what controls deceleration when an endstop is triggered - I would need to do some research.

Frederick

theKM

@fcwilt ...I get what you're saying, it stops wherever it stops, then re-measure it. But again, it is the stopping that is the problem. When it stops, it a hard stop. It's asking a very heavy machine to stop instantly, and the inertia is putting a lot of unnecessary strain on the ballscrews, the crunch is terrible. Nobody mechanically minded would think that the crunch is the sound of a properly operating machine during regular operation

...so I'm after a way for the controller to apply the max deceleration value and slow it down nicely ahead of the stop.

fcwilt

@thekm said in Slow down before endstop?:

...so I'm after a way for the controller to apply the max deceleration value and slow it down nicely ahead of the stop.

The greater the deceleration the more abrupt the stop - I think you need less deceleration.

Let me do a test to see what settings control deceleration at an endstop. Won't take but an hour or two.

Frederick

theKM

@fcwilt ...correct, this is the setting used to describe the fastest rate the machine can accelerate or decelerate, so when it's processing tool paths it slows down and speeds up appropriately for corners.

But the controller doesn't use these settings for the homing/move-until-switch operations, which is a hard, abrupt stop. If i could just tell it to apply the max deceleration and stop gracefully, that's what I'm after... as I could then tell it to slow down and measure the hard stop point in the usual way.

I super appreciate the help!!!

...until I found the max accel/decel settings, watching it take hard corners like a 3d printer was really horrible

jens55

I don't get why you wouldn't use one of the two options given. What is wrong with using an end stop switch mounted off to the side with a lever and roller and activated by the carriage?
Also, we are talking a single move in the x an y axis that is executed when the machine is initially turned on. 'Crawling' to the end stop would be painful but there is also no reason for the machine to go at maximum speed. You may loose 5 seconds per axis first thing in the morning but does that really matter?
Pick a speed that works for you, change the end stop switch to one that you don't 'run into' and you are set. I don't see the issue .....

theKM

@jens55 ...what I have seen are suggestions for switches. And that's cool. It was my plan to use exactly the switch ideas mentioned (micro switches with long arms and rollers).

Except for my car and tractor, this CNC machine is the heaviest thing that I own, it is a brick. It is also just shy of being the size of a queen sized bed. Telling the gantry to stop instantly without decelerating is prohibitive unless it is crawling. If this was about "5 seconds per axis" I would not have posted, I promise.

I want to look after the machine and I would like to be more productive when using it, and so I need a way to tell it to slow down when it passes a switch so it can be moving slow enough to stop dead when it actually gets to the e-stop.

At the moment I'm just using the e-stops for emergencies only to stop the machine dead, and just hope I don't put in any action in that hits them while trying to manage the job space... because whenever I trigger the e-stops I have to go over all the job setup again because the controller has reset, like it should when it hits emergency stops as it thinks it's an emergency. So, it would be much more productive if I could let the machine discover its work area before running jobs.

As indicated by other responses though, I'm not the only one who would like to take advantage of this efficiency.

jens55

@thekm said in Slow down before endstop?:

It is also just shy of being the size of a queen sized bed.

Ahhh .... a 'serious' sized machine ....

At the moment I'm just using the e-stops for emergencies

I am now confused as to how we got to e-stops (as in emergency stop) as compared to an end stop. Probably just a slip of the tongue/keyboard but those are not the same thing.

So if I understand you correctly now, you are concerned not about the carriage hitting the end stop (or at least that's not the only issue) but rather you want the carriage to slow down also because you think that the sudden stop might be too hard on the machine.
If that is the case then yes, mounting another sensor close to the actual end stop would be the way to go. Yes, it will involve some tricky gcode programming because you will need to sense the carriage passing that switch and then reducing the speed. Unfortunately I can't help with the programing of that. Most Duet setups have enough sensor lines that it shouldn't be an issue to connect a suitable sensor.

Good luck and please share your final setup.

fcwilt

@thekm said in Slow down before endstop?:

But the controller doesn't use these settings for the homing/move-until-switch operations, which is a hard, abrupt stop. If i could just tell it to apply the max deceleration and stop gracefully, that's what I'm after... as I could then tell it to slow down and measure the hard stop

So you have verified that M204 does not effect homing moves - those like G1 H1?

And I take it simply using a nice, slow speed would simply take too much time?

Frederick

theKM

@jens55 ...it's fun time to hang out in CNC forums, machines hitting endstops are equivalent to the world ending and should be nuked from orbit (actual quote from someone else on the topic). If it's not expected to hit endstops, then it's the only indicator there is of the machine knowing that things are not good, and it should die as quickly as possible. Powerful machines with powerful tools, plasma cutters, etc etc... it's a reasonable attitude to take, and the endstops are often wired into the same loop as the emergency stop button, and wired to be closed, so if anything breaks the circuit it all stops.

CNC forums are fun, but none will have specifics on the Duet gcode things.

jens55

@thekm, I agree that a machine should not collide with the end stop. That is why I suggested the sideways switch which does not allow a collision to happen.

theKM

@fcwilt said in Slow down before endstop?:

M204

I set it with 201, which the docco says 204 will reference as to not exceed.

am curious if 205 will do anything though...

fcwilt

@thekm said in Slow down before endstop?:

@fcwilt said in Slow down before endstop?:

M204

I set it with 201, which the docco says 204 will reference as to not exceed.

am curious if 205 will do anything though...

Notice that M201 set acceleration for any kind of move. M204 allows you to put an upper limit on each kind of move - printing and travel.

I need to go test M204.

Frederick

OwenD

On some of the CNC plasma systems we sell, they have two inductive sensors as the end stops.
On reaching the first, the machine slows and on reaching the second it stops and gives a limit error.
I think that on reaching the first, the max speed is reduced. On leaving the zone it's restored.
I think you could use a similar approach provided that you can create triggers that activate on both rising and falling
M581 sort of says that you can if you call it twice for the same input with different values, but you'd have to try.
When M581 is executed, if the T parameter is present but the other parameters are omitted, the trigger inputs and edge polarities for that trigger number are reported. Otherwise, the specified inputs and their polarities are added to the conditions that cause that trigger.

EDIT
Thinking on this, I don't think changing the max speed would interrupt a move in progress.
You'd have to segment it

jens55

@owend, that is a good point .... you would have to do the first move to the earlier stop as if it was the real end stop. Then go to the second end stop at a much slower speed.

fcwilt

@thekm

OK.

I verified the M204 T does affect the acceleration of a G1 H1 move but when the endstop is triggered it stops immediately.

Different value for M205 do not seem to change the stopping.

The firmware supports "triggers" which are external events which can run code - but unless something has changed since I last tested that code cannot interrupt a move in progress.

You could possibly "home" using a series of short moves (10mm ?) - the trigger code may get a chance to run at the end of each move and it could do one last move with low deceleration.

I would have to test that.