I have two SV04s, one of them is having some odd firmware flashing issues, firmware never writes the .cur file after flashing but appears to flash the printer, I have tried multiple Sd cards that all work to flash my other SV04. Trying to flash @Bjoern firmware version 1.4.6.
The main reason I was trying to flash it was due to some odd bugs with homing and auto leveling (also wanted some of the cool features that come along with it)
Before the incomplete flash, the printer would move the bed all the way forwards and crash the extruder into the hotbed (probe was past the bed so it kept moving). If I disabled the motor and pushed the bed to the rear before any homing this issue does not happen. I assumed this was caused by the bed sensor but this particular issue disappeared after the partial flash.
When auto leveling, the probe starts about an inch farther back than it should causing the auto leveling to fail when it reaches the rear of the bed. (This disappeared with the partial flash).
Now that the printer has issues with the bed and extruder positions, occasionally moving them the incorrect directions.
The other printer is having issues with dual mode, I am using ultimaker cura 5.8, I copied the start and end gcodes from the sovol version of cura because I thought that was causing the issues.
The first issues I assume were from pid tuning, the printer would park one extruder and freeze for an indefinite period of time. I ran pid tuning on both extruders and I think that fixed it but now it is freezing before parking the hotend. The first time it happened it eventually picked the print back up but dragged it across the board once it did and made spaghetti. The second time It started up again but failed to attempt rehoming the hotend and crashes the other hotend into it.
Hello Stg58,
first of all, a warm welcome to the forum!
You have described some problems, I try to give explanations & some hints in the same order:
Firmware flashing:
The firmware.cur is not written if the SD card is write-protected. Maybe a piece of Scoth tape will help to keep the write lock disabled. Assuming that you were able to flash the display software successfully, you should be able to open the “Printer Info” screen from the “Settings” screen. The “Printer info” screen should show firmware version v1.4.6 and display version v1.14.3. Otherwise flashing has not been successful.
I would also recommend to initialize the EEPROM after changing the firmware - remember to keep your offset data before. The complete procedure is documented here.
Nozzle crashing & strange behavior in Sovol’s stock firmware:
As far as I know, Sovol has published the source codes for the SV04 firmware for version v1.1.0 for the last time. Version v1.1.0 contains a nasty bug v1.1.0 contains a nasty bug that strikes, as soon as the end of the file (EOF) is reached: This sets the left extruder T0 as active tool and the Dual mode as current print mode. All remaining commands in the print queue will be executed with tool T0 & possibly in the wrong print mode. This bug affects almost all modes except the single mode. I don’t know if this bug has been fixed in later versions of the stock firmware. A possible workaround is a couple of dwell statements in the beginning of the end g-code section in order to ensure that all move have been done before reaching EOF:
G4 P10; wait 10 ms - 01
G4 P10; wait 10 ms - 02
G4 P10; wait 10 ms - 03
G4 P10; wait 10 ms - 04
G4 P10; wait 10 ms - 05
G4 P10; wait 10 ms - 06
G4 P10; wait 10 ms - 07
G4 P10; wait 10 ms - 08
G4 P10; wait 10 ms - 09
G4 P10; wait 10 ms - 10
G4 P10; wait 10 ms - 11
G4 P10; wait 10 ms - 12
G4 P10; wait 10 ms - 13
G4 P10; wait 10 ms - 14
G4 P10; wait 10 ms - 15
G4 P10; wait 10 ms - 16 should be sufficient for the queue
More ways to crash your nozzles: the “Move” menu screen:
SV04 has no current extruder positions after a power-on. Therefore homing is a good idea before moving the nozzles using the “Move” screen. It will avoid crashes.
Cura:
Being a satisfied user of PrusaSlicer, I can’t help with problems with Cura.
Nozzle freeze issues:
Your assessment coincides with mine - incorrect PID parameters will put the SV04 in a never-ending waiting loop. This can be fixed using PID-tuning. However, Sovol’s stock firmware v1.1.0 is using the same PID parameters for both nozzles, therefore PID-tuning the right nozzle will overwrite the settings for the left nozzle and vice versa… This can be a showstopper if both nozzles are too different. My firmware version has independent PID parameters for each nozzle in order to avoid this problem.
Quick summary:
Ensure that firmware and display software are matching on your updated SV04. Remember to keep your offsets & initalize EEPROM.
Use homing before moving the nozzle by using the move menu screen.
If you keep the stock firmware:
– Add a bunch of harmless end g-code statements in order to avoid strange behaviour.
– Try to find a set PID-parameter settings that work for both nozzles
Both machines are running your version of the firmware. Sorry I didn’t clarify in the original post. The flashing issue is odd, same as card works in one printer and not the other, not write protected, screen flashed fine, idk if it could be an Sd card slot issue or the bootloader. Other issue could be a corrupt ad card I need to try printing with a different one. It now only freezes before parking the inactive extruder.
A different SD-card could help fixing the flashing issue.
The problem of inactive extruder freezing is unknown to me. Can you describe it & is there a way to reproduce it?
I’m running a few tests right now to see if it repeats on a different printer using the same g code as well as testing repeatability on the printer I originally had it happen on with a freshly sliced model.
In dual mode: Printer will freeze at the end of a layer with the extruder positioned over the print. If I let it sit it will eventually resume printing.
It’s hard to diagnose as the error does not occur consistently at the same layer height.
I have had it resume a print successfully after this pause and I have had it resume printing but crash the second tool head into the one that was sitting over the print.
I will report back with results from my other printer (somehow it works without proper flashing)
Actually just checked the other printer and it did the same thing. I need to take a look at my gcode and slicer output to verify that is not the issue. I would expect more consistency with where the error occurs. If it was a firmware issue I would assume others would have noticed it by now so I highly doubt that is an issue.
Hard to tell if it is a hardware issue as both sv04s came to me used.
one of the sv04s I’m using is a friends he lent me before traveling for a few months(the one that refuses to flash, I even flashed the other one between attempts to confirm the Sd card will flash a printer)
One way to narrow down the problem is to identify suspicious sections in the printed G-code program.
In this case inspecting layer end instructions, toolchanges & initialization settings should be most interesting. First things to look for are anti-oozing functions like frequent temperature changes, moving instructions for the inactive extruder (check if ordered positions are still in the printable area 0 - 300mm) & waiting instructions.
Will definitely check those portions of the code out. Helps a lot to narrow down where there may be an issue. Once I figure this out I will probably modify my gcode to have the inactive extruder park on the rubber wiper to avoid oozing instead of lowering the dwell temp.
I haven’t, I am stubborn and don’t mind learning why things do what they do, right now I am guessing that my issues are caused by my printer failing to home the inactive extruder consistently. Sometimes it doesn’t when switching, sometimes it does just after the new extruder is heated properly, and sometimes it does it when the new extruder receives the heat command.
I am adding a line in my extruder switch end code to home the extruder so it happens regardless if my printer decides to do it or not.
Also, the freezes are appear to be for much shorter periods of time since I completed pid tuning. The left extruder is the only one experiencing significant amounts of freezing now so I may have not gotten a good tune on that one.
It depends: The firmware has a nozzle auto-park feature that will move the inactive nozzle to its home position on tool change. Selecting dual model via touch screen activates the auto-park feature. G-code M605 S1 does this, too.
There is a full control mode that can be activated by g-code M605 S0. In this mode the firmware does not care where to move the inactive extruder.
Freezing issue:
It is always a good idea to carry out the PID tuning at the same temperature with which you want to print out afterwards. More than three tuning cycles is also a good idea. Did you save the new PID settings using M500 after tuning?
I need to look at the gcode again, I believe I remember seeing m605 s0 so that could be the issue. I ran it at my print temp for 8 cycles and saved with m500 so it should be fine.
Well, I removed the redundant extruder switch code and it appears to have solved the issue. I’ll know for sure once it finishes my print. There were no m605 commands so I guess I had just remembered wrong.