Michal
/
Prusa-Firmware-MMU
mirror of https://github.com/prusa3d/Prusa-Firmware-MMU
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Attempt to solve spuriously ejected filaments

pull/204/head
D.R.racer 2022-09-14 11:57:55 +02:00
parent 860b91e42b
commit 5dd4c279c9
2 changed files with 8 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
src/logic/feed_to_finda.cpp
View File

@ -20,7 +20,7 @@ void FeedToFinda::Reset(bool feedPhaseLimited, bool haltAtEnd) {
ml::leds.SetPairButOffOthers(mg::globals.ActiveSlot(), ml::blink0, ml::off);
mi::idler.Engage(mg::globals.ActiveSlot());
// We can't get any FINDA readings if the selector is at the wrong spot - move it accordingly if necessary
ms::selector.MoveToSlot(mg::globals.ActiveSlot());
ms::selector.MoveToSlot(mg::globals.ActiveSlot()); // @@TODO move to slot can return "refused", what shall we do in such a state? Report an error?
}
bool FeedToFinda::Step() {

9
src/modules/selector.cpp
View File

@ -67,8 +67,13 @@ Selector::OperationResult Selector::MoveToSlot(uint8_t slot) {
return OperationResult::Accepted;
}
if (mf::finda.Pressed()) {
// @@TODO not sure why (if) this happens, but anyway - we must not move the selector if FINDA is pressed
// This seems to cause all kinds of strange issues like errorneously ejected filaments from the wrong slot (because selector refused to move).
// Moreover, FINDA looks very unreliable over time and occasionally causes spurious triggers.
// But relying on a higher-level status (filament load state) could solve the issue,
// because it is only updated at specific spots sometimes also according to FINDA status.
//if (mf::finda.Pressed()) {
if( mg::globals.FilamentLoaded() > mg::FilamentLoadState::AtPulley ){
// @@TODO not sure why (if) this happens, but anyway - we must not move the selector if we think that we have filament in the selector.
// That includes the CutFilament operation as well
return OperationResult::Refused;
}