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.
-
@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
-
@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.
-
There is this https://duet3d.dozuki.com/Wiki/Configuring_RepRapFirmware_for_a_CNC_machine but I'm not sure how up to date it is. If you have any suggestions on improving that page while you go through it, please let me know and I can update it. I'm not a CNC user myself, so my understanding is limited.
-
@fcwilt ...voltage divider works in so much as I get the 500 and 1000 levels through the zprobe input. Next is making the machine move and see what it does with G38.2
-
So I've tried to chase down what straight probing can do for me...
I made a setup with a breadboard to emulate the analog signal, and confirmed that with buttons I could trigger a value of around 515, and 1000 (confirmed in DWC probe interface)... to correspond with the docco of what the IR probe does. Set the probe value with G31, also verified in the UI.
Regardless of what I send through 32.8, it only ever moves at the second feedrate from 558, nothing I tried got it to move at the initial faster rate.
The move itself accelerates and decelerates if not interrupted, and the stop is still a hard stop (it's only moving at the second slower feedrate, so I guess that's expected).
There is an ominous line in the gcode docco:
"When doing a plain G30 command, an additional probe will be done using the first speed to establish the approximate bed position, before one or more additional probes are done using the second speed. The first speed will not be used when probing at a defined point or when mesh bed probing.".
I've tried to find any config examples of something I may have missed to get it to honor the initial feedrate, but, not finding any.
M558 P1 C"zprobe.in" H0 F10000:300 T500 G31 P500 X0 Y0 Z0 ; following line is actually pretty handy G38.2 X{move.axes[0].userPosition-25}