Slow down before endstop?
-
@thekm said in Slow down before endstop?:
@fcwilt there's two switches, so it's not just two lines of G1 at different rates, as it needs to change from the switch indicating it's close, to the endstop switch.
Depending on the breaking distance there may not be a need for two switches.
My IR beam break endstop sensors are positioned some 25mm away from the end of the axis. The part that breaks the beam will keep the beam broken all the way to the end of the axis.
So it would provide 25mm to slow to a stop. If 25mm was not enough I could move them and print a new part that breaks the beam to handle the longer distance.
Frederick
-
@fcwilt there's a move that's interrupted by the IR beam breaking, how does it change to using a different interrupt on the second move when it hits the endstop?... G1 is "move until trigger", doesn't something have to change to let the second G1 stop on something different than the first G1?... the little backup on my machine would be much less than the distance needed to decelerate, and would still be true.
-
@thekm said in Slow down before endstop?:
@fcwilt there's a move that's interrupted by the IR beam breaking, how does it change to using a different interrupt on the second move when it hits the endstop?... G1 is "move until trigger", doesn't something have to change to let the second G1 stop on something different than the first G1?... the little backup on my machine would be much less than the distance needed to decelerate, and would still be true.
The proposed H5 parameter would work that same as H1, H3 and H4 - terminating the move.
The only difference is that H5 would respect the M204 setting (acceleration) as opposed to the immediate stop of H1, H3 and H4.
Clearly the "backup" move needs to move enough so the sensor is no longer triggered. Perhaps I should have pointed that out.
Frederick
-
@fcwilt ...always fascinates me how geeks typing to each other can be such a struggle
My machine wouldn't be backing up at all... it would pass the proximity switches, slow down, stop, then disable the proximity switches change to use the actual endstop switches for the second move. This way the endstop switches will still work as endstop switches, and the proximity switches in use for this procedure as needed.
-
@thekm said in Slow down before endstop?:
@fcwilt ...always fascinates me how geeks typing to each other can be such a struggle
My machine wouldn't be backing up at all... it would pass the proximity switches, slow down, stop, then disable the proximity switches change to use the actual endstop switches for the second move. This way the endstop switches will still work as endstop switches, and the proximity switches in use for this procedure as needed.
That is certainly one way to do it if you don't mind having two sensors instead of one. It would save a small amount of time by adding the additional hardware and wiring.
Is there a particular reason why you want to avoid the backup?
Frederick
-
@fcwilt ...it's not the backup, just that using only one trigger would reduce the effective working area, and no longer are the estops representing the absolute max of travel.
Once there was such a feature I could measure the deceleration distance... if it's small enough single switch would be fine.
-
@thekm said in Slow down before endstop?:
@fcwilt ...it's not the backup, just that using only one trigger would reduce the effective working area
Then I did a rotten job of explaining.
Having a endstop sensor some distance away from the end of the axis doesn't have to result in a change to the working area.
Homing is simply a means of the firmware determining where things are. The fact the a G1 H1 move sets the position to the min/max value in M208 is a not an issue.
Let's say my X axis min/max are 0 and 300. And that the sensor is at 275.
So I do a normal G1 H1 move and it stops at 275 but the logical position is set to 300 because of the M208 settings. All I have to do is include a G92 275 after the last G1 H1 and now the logical position matches the physical position.
And movement to 300 is retained.
It is required that the endstop activation is done in such a way that it remains activated from, in this case, 275 to 300. This is usually easily done.
In my case of using IR beam break sensors I simply make the moving part that breaks the beam long enough that it keeps the beam broken until the end of travel.
Frederick
-
@fcwilt I get that once you know where the machine is, you can tell it basically anything about the machine and workspace from there... but if it's triggering at 275... how does it happily cut a job at 285 and have the sensors work as endstops by leaving the machine alone unless it goes to cross 300?... this is what I mean about losing that area of workspace. If something goes wrong, bad feeds and speeds loses steps, endstops should shut it all down at 300.
-
@thekm said in Slow down before endstop?:
@fcwilt I get that once you know where the machine is, you can tell it basically anything about the machine and workspace from there... but if it's triggering at 275... how does it happily cut a job at 285 and have the sensors work as endstops by leaving the machine alone unless it goes to cross 300?... this is what I mean about losing that area of workspace. If something goes wrong, bad feeds and speeds loses steps, endstops should shut it all down at 300.
Endstops don't work for normal G1 moves as used during printing.
I know of nothing in the current firmware that can do what you mentioned - short of using a trigger to activate an external relay to kill power.
But I now understand what you were talking about in earlier posts.
Thanks.
Frederick
-
@fcwilt ...at the moment I just use duet's ability to reset with an endstop hit, which stops the spindle and everything else. But is also why endstop hits are so annoying at the moment and would be nice to have the machine measure itself out when turned on (as it will prevent moves outside its bounds, etc etc)
-
@thekm said in Slow down before endstop?:
@fcwilt ...at the moment I just use duet's ability to reset with an endstop hit,
How is that done?
Thanks.
Frederick
-
@fcwilt CNC mode?... my endstop line is just "M574 X1 Y1 A1 B1 S1"... but there's no doubt that it reboots
-
@thekm said in Slow down before endstop?:
@fcwilt CNC mode?... my endstop line is just "M574 X1 Y1 A1 B1 S1"... but there's no doubt that it reboots
Thanks.
CNC mode must work differently but I see nothing in the M574 docs that allows for your syntax or suggests that the behavior changes in CNC mode.
Do you have a link to some CNC specific docs?
Perhaps I am just missing something.
Frederick
-
@thekm said in Slow down before endstop?:
@fcwilt CNC mode?... my endstop line is just "M574 X1 Y1 A1 B1 S1"... but there's no doubt that it reboots
You must still be using RRF2?
-
@phaedrux I was... and just updated to RRF3.3 to try the probe thing mentioned above... and now I am quite sad, as now the spindle control isn't working... so now I have to wade through all the nonsense of figuring it all out again for the new firmware....
...backwards compatibility, it used to be a thing
Β―\_ (γ)_/Β―
-
@thekm said in Slow down before endstop?:
@phaedrux I was... and just updated to RRF3.3 to try the probe thing mentioned above... and now I am quite sad, as now the spindle control isn't working... so now I have to wade through all the nonsense of figuring it all out again for the new firmware....
...backwards compatibility, it used to be a thing
Β―\_ (γ)_/Β―
Well your v2 vs my v3 clarifies things.
If you figure out how to get endstops to act the way you want please let us know as I would like know as well.
Frederick
-
@fcwilt I have a spare duet that I'm about to play with the probe and a breadboard to see if a voltage divider will do what I want
-
@thekm said in Slow down before endstop?:
@fcwilt I have a spare duet that I'm about to play with the probe and a breadboard to see if a voltage divider will do what I want
Interesting. Hope it works.
Frederick
Printers: a small Utilmaker style, a small CoreXY and a E3D MS/TC setup. Various hotends. Using Duet 3 hardware running 3.4.6
-
@thekm said in Slow down before endstop?:
the nonsense of figuring it all out again for the new firmware....
This is the usual spiel I give for users doing the upgrade.
If you still have access to DWC. Upload these 3 zip files, one at a time in the system tab. Don't extract them first. Reboot after each. Use M115 in the gcode console to verify the firmware has been applied.
https://github.com/Duet3D/RepRapFirmware/releases/download/2.05.1/Duet2Firmware-2.05.1.zip
https://github.com/Duet3D/RepRapFirmware/releases/download/3.0/Duet2and3Firmware-3.0.zip
https://github.com/Duet3D/RepRapFirmware/releases/download/3.3/Duet2and3Firmware-3.3.zip
That will get your firmware and DWC up to date.You can see the change logs here:
https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.xFor your config, might be a good idea to run through the configurator tool and generate a fresh set for RRF3.
https://configtool.reprapfirmware.org/StartBackup your existing config files in the sys folder in case you want to switch back to RRF2. Itβs easy to switch back and forth, just upload the zip file for the version you want and then upload your config files.
These documents will come in handy during the conversion.
https://duet3d.dozuki.com/Wiki/RepRapFirmware_3_overview
https://duet3d.dozuki.com/Wiki/Gcode -
@phaedrux the firmware is updated, got through that. The machine moves, spindle and such isn't working, which went through a huge change in RRF it seems... spindles and external stepper drivers aren't covered in the config tool, I just have to go through it all line by line again. There's scattered config examples around, I should be able to get through it.
