Hi, how are you?
I installed the firmware and I really liked it, but about the left extruder, it still doesn’t accept a negative value in x, my code is similar to yours, could this be a limitation that Orca Slice is placing? I’ll do the same test on the Prusa later and let you know here, thank you very much for your help
Hi again,
the G-code above worked as intended directly via USB-cable using Pronterface & also via .gcode-file from SD-card. You could check your slicer output files whether there are any changes to your cleaning gcode sequence. Do you run a printer server that might apply any changes?
/R
Björn
Hi, I found the problem. If I use dual mode on the printer, the left extruder doesn’t accept negative x after it starts printing. I adjusted the gcode to use both extruders in single mode, and then everything works fine.
Now, another problem I’m having is with Pause. The machine stops and retracts the filament, but it doesn’t start printing again after I confirm to resume.
Hi again,
my g-code fragment posted above worked both in single mode & dual mode on my SV04. Which firmware version are you currently using?
Concerning your pause issue: Without details about current g-code sequence, actions you took, used printer mode & installed firmware version I won’t be able to provide any help.
/R
Björn
On the pause issue: I have posted about this before. I see it when the filament detector throws an error. The display gives the prompt: Paused. “Resume” to continue, “Stop” to cancel.
After I replace the filament and select Resume, the screen goes back to the printing progress display and while the bed temperature maintains it’s target temperature, the nozzle temperature keeps dropping even though the target temperature still indicates 210°c (in my case).
I am running firmware v.1.15.6
Then, either through time or the nozzle temperature drops too far, another error pops up. I restart at this point. I don’t know how the gcode could affect this, but this is the code used to test:
PauseIssue_PLA_1m2.gcode (5.1 KB)
Hello urbnsr,
I don’t remember your posting about a similar filament sensor issue. Anyhow, thanks a lot for your g-code & your description on how the issue happened. I’ll try to reproduce the situation & have a closer look iot find a solution.
/R
Björn
Thanks Bjoern. I don’t think my previous post was about the filament sensor, itself, I just used the sensor yesterday to simulate the condition to put the printer into the pause/resume cycle to better describe how it works. Or doesn’t…
Hello @Bjoern, Thank you so much for all the work you put into putting out better firmware for the SV04. I’ve recently started using it and it’s a great upgrade. I also see you’ve been active on the forums here and helping people in the community and I feel guilty asking for help when I have nothing to contribute, but here I am.
I’m having what appears to be the same issue as urbnsr above with the filament runout sensors. I haven’t been running your firmware long (maybe 2-3 weeks) and am on 1.15.6 according to the display panel for both the printer and display.
I’m going to be doing a longer print that doesn’t need to look nice and using up a bunch of old rolls, so I wanted to test the runout sensors before doing so. I started a random small print with just a piece of filament stuck in the sensor, and after it had started pulled it out. Here’s what happened next:
- hot end lifts and moves over the purge bucket
- the printer first feeds a little then completely retracts the filament out of the extruder
- the “paused” screen is displayed with the options to stop or resume
- I select resume
- I feed new filament into the extruder and replace my piece in the sensor (as this is a test I wasn’t actually feeding through the sensor). I should note I’ve tried this out of order and doing it before selecting resume and it doesn’t appear to have an impact.
- the printer returns to the normal printing screen however, as described by urbnsr above the hot end just stops heating and its temp starts droping even though the display indicates it should be set at, in this case, 215
- after no major change and given plenty of time to work through things I will press the stop print button
- things get weird.
I wish I could be more specific here but as I’ve tested this a couple times I have not gotten consistent results. A variety of symptoms happen but not always in the same order. The system seems to enter some sort of loop. It may soft reboot at this point but if it does it comes back online with the temp set to 170 for some reason and also gives a number of beeps like it was pausing the print. I am unable to start a new print. I can select the print button and select the file, but it will not accept the user input to start the print. Exiting out from this screen can result in another soft reboot (this is why I say it’s in a sort of “loop” as the only way to start a new print is to use the power button to to a cold start). The system sometimes after rebooting will bring up the pause screen again. I’m assuming on boot it must be thinking that it had a print in progress and had power loss instead of a proper shutdoown? Regardless, its after this that sometimes it brings up the “manually change fillament, click print to continue or stop to stop print” screen.
I was wondering if you’d been able to replicate this issue yourself. If I can provide any more information I’d be happy to do what I can to diagnose the issue. I have not yet but can connect a USB cable to it and bring up pronterface to get a little more information. I’ve noticed this thread itself is quite old and spans a few topics, if you would like me to open a new thread dedicated to it I would gladly do so (I’m new here, not sure on the expectations of that sort of thing).
I hope you read this and are able to help, thanks for all your work!
Hello Pearldrums,
first of all, welcome to the forum. You described several observation which touch several Marlin firmware features that might have had impact…
- advanced pause feature
- filament runout handling
- cold extrusion prevention
- power-loss recovery
Additionally, aborting (stopping) the print without resetting the printer might have left instructions in the queue which led to “weird” & non-deterministic behaviour.
For a thorough analysis it would need more details about printer state (e.g. selected print mode, printed g-code, actions take (buttons pressed) & hidden temp file on your SD-card.
Anyhow, I appreciate your input. Currently I’m working on a new release & will have a deeper look at the (re-)heat procedure after changing/loading filament.
/R
Björn