detect endstop while printing
-
Hello. This is the situation (duet3 SBC mode, version 3.4.2)
Print area 220X220
Endstop while homing define X0 and Y0 defined with this line on config.g:
G10 P0 X0 Y0 Z0
SOmetime I have troubles with overhangs, the nozzle crashes and the printer loose steps. So from there the printer doesnt know the real position of the printhead and I have suffered strong crashes of printhead with the sides because after loosing steps, of couse if the printehead wants to move to 1 side, probably that side is closer than the firmware thinks
So my question is:
.- if I move the endstop like 5 mm on the negative side of X for example, I can define that using
G10 P0 X-5 Y0 Z0But I dont know how to do this (if it is posible): I want to detect while printing if the endstop is trigered. If that happens it means the printer has loose steps, and so pause the print, or re home.
I guess I could do this using the stall detction? but so far I have had no success , too much false positives.
So, can this be done? detection an endstop while printing.
Thanks in advance
-
@tinchus thats not how you define an endstop position.
Wouldn't you be better with stall detection? https://docs.duet3d.com/en/User_manual/RepRapFirmware/Events -
@jay_s_uk As I posted, stall detection has not gone good for me at the momet, I had a lot of stops for falso detections.
-
@tinchus then remap the endstop as a trigger using M581
But stall detection you have to tune to your system and a lot of things can affect how good it works -
@jay_s_uk I know, but so far those tunnings have not been successul for me. My printer has a heated chamber and the diferent temperatures seems to have some effect on the motors capability to have the same config everytime. It just doesnt work
-
@tinchus End stops are only checked when homing so you can't use an end stop in that way when printing. If I understand you correctly, you are saying that if the head collides with the print, then it will lose steps and/or the belt jumps and so the head becomes out of position and the homing position is lost. At this point, the print is probably ruined so the obvious solution would be to fix the printing issues which causes the problem. But if you are unable or unwilling to do that, and you can't/don't want to use stall detection, then you could use additional switches and wire them as external triggers. https://docs.duet3d.com/User_manual/Reference/Gcodes#m581-configure-external-trigger
If you use the R1 parameter, then the trigger will only be acted on while printing from the SD card so they won't interfere with normal homing. You would of course need to use 4 switches - X min, X max, Y min and Y max to catch all eventualities.
All in all, it'll be far easier to fix the nozzle crashing issues.
-
@deckingman was thinming about that. and I was looking for a post from DC42 where he spoke about channels. I guess these triggers would go through a separate channel than the one being used for printing so delay on detection wont exist?
Fixing the printing problem is the must, BUT, what I want to avoid is a printhead crashing against one side of the printer, I dont want to save the print, I want to avoid hardware damages. -
@tinchus It's best to fix whatever causes the step loss. If there's some reason you can't fix it, you could try rehoming the printer at every layer. If your endstops are precise (optical are best), print quality will not suffer. Rehoming at every layer has a significant time penalty, so you could rehome at every 3rd or 5th or 10th layer, etc. You would put some custom code in the slicer to be executed upon layer change to make it work.
I ran tests of the optical endstops in my printer with rehoming on every layer (this is done is some commercial printers for detecting layer shifts) and the prints came out more or less identical to prints made in the normal manner. See: https://drmrehorst.blogspot.com/2020/03/testing-ummds-xy-optical-endstops.html
-
@mrehorstdmd your proposal is not realistic. Or at least at this time, it is something we all want but nobody has achoeve: it is imposible right now to not have a blob for example, and it is imposible to detect it and avoid the nozzle crashing against it. That sometimes makes the motor loos steps. This is just an example.
Anyway, my question was answered: I cant use the endstop and I should use stall detection if posible.
Thanks all -
@tinchus I have done it, and so has MarkForged.
There shouldn't be any blobs- adjust extrusion. However, small blobs should not cause the motors to skip steps. You really need more torque to drive the mechanism (more current, bigger or closed loop motors, higher supply voltage, etc.) or modify the mechanism to require less torque (correct alignment problems, reduce the number of pulleys, etc.), or both.
-
@tinchus If you do want to use a switch detect movement outside of the print area as others have already said you can hook the switches up so that they generate a trigger event (see M581). You will probably need 4 switches though to cover the high/low end of both the X and Y axis. You can probably use just a single input pin per axis if you wire the switches correctly and you should be able to use that same input as your endstop if you configure things carefully and remap the pin usage after homing.
-
@mrehorstdmd This post is not meant for a debate. I completely understand and agree with you, but what you are saying is very theoretical.
If you say that you can launch any print, with STL coming from people not really skilled on designing for FDM printing, and you can guaranty that you will not have a single problem printing those STL on ABS or Nylon where you should not use layer fan... then we need to talk in private and start a business because at this time, that situation does not exist on Market.We have a markforged at the school is it is just a good machine that definitely is not worthy what they paid for. If I take the STL from my students, of 50, I can guaranty you that at least 10 will fail because of an overhang crashing against the nozzle. It is a bad design on the STL? Most sure it is. But the problem is there, you can always control the STL design, and leaving the printer non attended printing on the air with the risk of colliding against the sides is not good for the hardware. We have already broke a print head in that way, so what Im describing is definitely something that in real life happens. Other teachers have described the same, so we are not the only ones having this problem with markforge, wich is not the only "super expensive brand" having this problem.
-
@gloomyandy yes, thank you very much, I think this is MY (I remark this because Im not saying is the good one, but in my situation looks like the best way for now)
