Reporting some bugs in Bjoern's firmware V1.14.6

Sovol SV04 IDEX
1

Originally my printer V5.2.1 came with firmware version 1.1.4 and display version 2.0. Since it had some problems, like slamming heads against each other after G28 X command, I installed the Bjoern70’s firmware V1.14.6 and display V1.14.3.

Here I’m reporting some bugs that I’ve encountered with the new version:

In setup → move menu, it prevents the left head to go, for example, further than to X88, after moving the right head to X150, even though it always changes and parks the heads, when I select a different head.

Printer always resets after printing from SD, displaying “processing please wait”, instead of “finish print”.

This is the output on USB serial (after a very short SD g-code file in dual mode):
Done printing file
Done printing file
…
Done printing file
Done printing fileinfo:jump to app
start
Watchdog Reset
Marlin v1.14.6 …

or

After the end of SD printing it keeps sending to USB serial (after my 20x20 test cube SD g-code file in single 2 mode):
echo:busy: processing
File deleted:PLR
//action:notification 25m 22s
echo:Print time: 25m 22s
Done printing file
//action:notification 25m 22s
echo:Print time: 25m 22s
Done printing file
//action:notification 25m 22s
echo:Print time: 25m 22s
… then resets itself …

M0 resets (as RepRap) the printer instead of waits for a key (as Marlin) (from USB or SD).
I’m fine with the reset action, but it doesn’t work when the printer is “busy processing”.
It would be nice, if I could press emergency stop button in Repetier host to immediately reset the printer, if it is doing something crazy. (It seems that USB serial DTR high to low doesn’t work for this printer. But M112 requires to cycle power switch and unplug USB cable to restart the printer.)

If printer is not homed in dual mode, the printer resets itself at the beginning of SD print. Instead of just printing from where it is. And you can’t use G28 X because, it always messes something up.

First move command or after G28 X over USB serial doesn’t use the supplied Fnnn parameter (in, at least, modes single 1 or 2, dual).

Example: send:
G28 X
G1 X100 F2000
(It should go slowly, but it goes fast.)

First move after G28 X Y is always wrong (after G28 alone is fine or first G28 Y and then G28 X):

Example: send:
G28 X Y
G1 F2000 ;moves the bed forward slowly than back fast

Example: send:
G28 X Y
G1 X100 Y100 F2000 ;moves bed in Y first, than in X with wrong speed, (not together)

In dual mode, don’t use G28 X, as the first command, or right after dual mode selection, because it first homes left head to X-62 but then it parks it at X0, so the other one will crash into it.

In SD g-code file, in dual mode (or if M506 S1 dual mode selection is at the beginning): the first command before any head move should be M28, or else the dual mode will not function properly, or the printer will reset it self.

(Not really a bug, but good to know.)
To select single mode 1 or 2 from SD file, use M506 S1, followed by T0 or T1, followed by G28.

If you select mode via USB serial with M605 S3 from any other mode than mode 2, it will say “Printer must be in DXC_DUPLICATION_MODE prior to specifying DXC_MIRRORED_MODE”

Selecting duplicate or mirror mode from the menu, and then sending USB serial print moves, doesn’t do the duplication or mirroring. You must send the M605 S2 or M605 S3 command via USB serial, prior to this type of USB serial printing.

Best regards.

2

Hello and welcome,
Did you send a message on the Facebook group?
Not sure he is present on this forum.
Cheers

3

Hi there,
you won’t reach me on facebook - I’m here & will have a look at the bugs…

/R
Bjoern

4

Great, glad to see you there

5

Hi again,
Testormat, thanks a lot for that detailed report - it sure will help me improving the firmware.
I’ll try to answer your observation going by their enumeration:
1.+ 4. + 5. + 6.: I’ll need to have a deeper look into the sources…
2. The reset was intended to ensure a known state of the printer after done printing. Getting rid of the “finished print” message screen is a feature that has been asked for by octoprint users. The next firmware update v1.15.0 will come with that screen again. I’ll need a deeper look into the sources iot limit the serial message burst when done printing.
3. I already changed the M0/M1 implementation. In the next firmware version M0/M1 will result in a pause & resume screen. I had an emergency stop in my mind when I did the current implementation.
I never tried M112, by I know that M81 power-off works with extra hardware, however, the motherboard will remain powered on if there is sufficient power delivered via USB, but it turns power supply & all motors, fans and heaters off.
7. + 8. Single mode 1 and single mode 2 are no genuine Marlin firmware features. These were implemented by Sovol (and it seems the engineers should have been given more time…). I’m currently trying to add both single modes (& maybe a backup mode) into M605. This should result in a cleaner implementation. Anyhow, I’ll will add this to my test section.
9. Yes, this is exactly done as documented…
I’ll keep you informed…
/R
Bjoern

1 Like
6

Thank you for the replies,
and for the effort repairing this firmware.

1 Like
7

Here is another annoyance:

I think the software endstops are set wrong.

Notably, when I move the left extruder to the position X-62 it only goes to X0, but if I move the right one to X362, it does actually move there. In all printing modes (testing via USB.serial.)

Sending the M211 command reveals that software X limits are set from 0 to 362 for both the left and the right head. (Reading them with T0 then M211 or T1 than M211. I’m not sure if in the source of the FW they can be configured separately.) And they’re set equally for all printing modes: single1,2, dual, duplicate, mirror.

This is mostly wrong in the mode M605 S0 where the left head cannot be moved away from the print bed to X-62 and so it blocks the full movement of the right head.

For now, the workaround is, to fully disable software endstops with M211 S0.

Allowing X movements to -62 and +362 allows us to create our own nozzle purging and wiping scripts.

Existing software endstops X0 to X362 for both heads already don’t protect the left head from hitting the right one parked, so the easiest solution would be to simply extend this limit to be from X-62 to X362 for both heads in all modes, so we don’t need to fully disable the software endstops.

Though, for naive users, a proper solution might be a table of endstop limits for all modes and each head, applied at each mode/head change.

I will just be adding possible bugs to this topic as I go along with setting up my printer.

Regards-

8

Hello Bjoern,
I hope you are well!

I would like to know if you will release a new update soon. Also, I would love to contact you outside this forum to explore possible collaboration.

9

Hello KubaBuba,
my job keeps me quite busy currently therefore the next release will need some more time, but it should happen still in 2024…
/R
Björn

10

Thanks for the update! We can’t wait for the M0 and resume from the LCD feature. Now we need to put kitchen timers all over our printers:D

11

My two cents:

  • In dual mode, it takes about 3-4 minutes to start printing after the T0 and T1 reach temperature. I believe it’s set up the way that it won’t start until both readings are stabilized to very small, negligible delta values.
  • Purging is way too fast for very flexible filaments.
  • Saving the after 64-point bed measuring very often causes a printer reset without saving the values.
12

Hi again,
thanks a lot for the feedback. This is my first impression:

  • The first issue can be solved by PID-tuning both nozzles.
  • In order to find a solution for the second issue I need to know how you started purging. Via the menu it should have been a speed rate of 6 mm/s which seems moderate to me.
  • I’ll have a look at the third issue.

/R
Björn