johncarlson21 / sv04-marlin-2.1.x Goto Github PK

The z offset indicates .001mm + or -, but the movement when pressed is 0.1mm, i measured it with feeler gauges.

Describe the bug
Printing via Octoprint, at the end of the print, the SV04 doesn't seem to recognise that the print is finished and the screen remains on the printing screen with the buttons for "Stop", Pause" and "Tune", rather than reverting to the "Home" screen. Requiring the user to press the "Stop" button and then confirm to return to the "Home" screen

To Reproduce
Steps to reproduce the behavior:
Run a print via Octoprint and wait until the print is completed.

Expected behavior
At the end of the print, the SV04 should revert to the home screen without user intervention

Go to move screen and the z-axis reading decimal point is out by 10
It reads 1.20 mm instead of 12.0 mm

It just a display error

From András Petrovszki

I just tried to set flow rate to 102% under a duplicate print, then it stops printing suddenly on actual position. I switched off and on to try a resume. I was on the middle of first layer, but it continues after resume to print from the very first purge line again, therefore I restarted completely. Made a new try on flow set to avoid one-case event, but failed again.

Describe the bug
Switching to tramming (from auto-leveling) seems to raise the Z height. Continuing to tram (by pressing the same number) seems to raise the Z height as well.

To Reproduce
Steps to reproduce the behavior:

1. Go to Leveling
2. Put a piece of paper under the nozzle after it finishes
3. Use -/+ to get the nozzle to "scratch" the paper
4. Click Tramming
5. Press the "1" (my nozzle actually shifts to the left a bit when I first do this...should it?)
6. Press the "1" again, several times.
7. Notice how the paper moves easier each time.

Expected behavior
I would expect the Z height to remain the same

Additional context
Using 2.1.3.1b3

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

If you print something in single mode and then immediately print that same thing again without turning it off it decides to use the second extruder.

Bug Timeline

New

Expected behavior

Expected to use the selected extruder in single mode whenever which extruder is used isn't specified in starting gcode

Actual behavior

Printer will use the selected extruder once, but if that print completes and you immediately start the same print with the same extruder selected again it will alternate to the opposite extruder. In this case it alternated to extruder 2. This is fixed by power cycling. Then you can select whichever extruder and it will use the expected extruder.

Steps to Reproduce

1. Slice any STL and do not specify which extruder its to use in starting gcode.
2. Print file, and then immediately print it again with the same extruder selected in single mode.
3. Printer then will alternate to the secondary extruder.

Version of Marlin Firmware

2.1.2

Printer model

Sovol SV04

Electronics

Stock

Add-ons

Stock

Bed Leveling

UBL Bilinear mesh

Your Slicer

Prusa Slicer

Host Software

None

Don't forget to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

No response

Describe the bug
The mesh is reversed on loadup via RTS_INIT

To Reproduce
Steps to reproduce the behavior:

1. generate mesh
2. look at the lines.. for example 1 2 3 4 5
3. reboot printer
4. go to meshviewer, each line is reversed so the example line gets 5 4 3 2 1

Expected behavior
showing as saved

Additional context
the fix for this is to change the order here:

  // away from origin
  if (zig)
  {
    inStart = GRID_MAX_POINTS_X - 1;
    inStop = -1;
    inInc = -1;
  }
  else
  {
    // towards origin
    inStart = 0;
    inStop = GRID_MAX_POINTS_X;
    inInc = 1;
  }

Thank you for the code. I included it in my fork and came to this bug after user reports.

I have some custom Tool Change Code in prusa slicer where for every tool change it does the following
{ if previous_extruder>-1 }
T{previous_extruder}
M106 S0
T{next_extruder}
M106 S255
{ endif }

What happens is the previous tool parks as expected, turns the fans off very briefly and then the other tool head moves into position and both fans turn on. I've verified the gcode actually expands to the correct T0/T1 as expected but the unused one still has full fan speed. Through the touch screen however you can control it ON/OFF
Offset_X_Y_dual_extruder_1_PLA_SOVOL_DualColor_0.4mm_Models_PLA(Nearest).ini (SUNLU Black PLA)_SOVOL_DualColor_0.4mm_Models_PLA(Nearest).ini (Sovol Dual Color).zip

First of all, congratulation on the EXCELLENT job. My SV04 prints like a charm and the DWIN display is beautiful.
I´ve made just some cosmetics adjustments:

• Enabling the PID individual adjustments
• define NUM_RUNOUT_SENSORS 1 // Number of sensors, up to one per extruder.
• define TOOLCHANGE_ZRAISE 2 // (mm)
  However, I wonder why you didn´t use the DRIVER_TYPE TMC2209_STANDALONE instead of the 4988. Any known problem?

Describe the bug
Prompt is cut off

To Reproduce
Steps to reproduce the behavior:

1. Extruder is cold
2. Go to 'Settings | Refuel'
3. Click on 'Unload'
4. You'll be prompted to heat up the extruder (also note typo, "filament" is spelled "fament" - tried to search the code so I could open a PR but search didn't help)
5. Click 'Yes'
6. Click the 'Back' arrow
7. Notice the prompt is cut off

Expected behavior
Behavior is fine, but the graphic is cut off

Describe the bug
When I run a print on the custom firmware for the SV04 from octoprint, after it completes, in the Octoprint UI the printer status is "operational" but the LCD is still on the "print status" display. I can manually click the "Stop Print" button but it would be nice if this happened automatically so I would know the status just by looking at the display

To Reproduce
Steps to reproduce the behavior:

1. Setup Octoprint
2. Print a file
3. Wait for it to complete

Expected behavior
The LCD display returns to the main screen.

Screenshots

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

When using a G-Code like M125 to pause printing, it will try to park the head all the way to the right...which leads to head 1 crashing into head 2, resulting in a layer shift. I believe this is due to NOZZLE_PARK_POINT using Y_MAX_POS, but I'm not sure--I haven't tested it. In the meantime I'm gonna be setting the park point manually, I suppose.

Version of Marlin Firmware

V2.1.3

During a print, the Tune screen freezes, and the upper portion doesn´t recognize the touches.

To Reproduce
Steps to reproduce the behavior:

1. Go to the Main screen during printing.
2. Click on the Tune button
3. Click to return or Z offset
4. See, the screen doesn´t recognize the commands.

Expected behavior
Normal button commands have been recognized.

Screenshots
See the movie at https://drive.google.com/file/d/1wthAncXLiA_4KpMk4Q1GJKuJWQ5VYgX6/view?usp=sharing

Desktop (please complete the following information):

• OS: W11
• Browser Chrome
• Version V2.1.3.1b2
• Screen Version 1.2.6

Additional context
Add any other context about the problem here.

M300 is currently ignored (same as with stock). It would be nice if M300 performed as expected.

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

I have loaded machine firmware V2.1.3.1b3 along with screen firmware 1.2.7 on 4 different SVO4 printers. On 2 of them they are printing flawlessly. On the other 2 machines anytime a arc/curve is printed the head seems to stutter. So on straight lines it prints as it should but when it gets to an arc head stops puts down a dot of filament, it moves a tiny bit spits a dot of filament, moves a little more then another dot until the end of the arc then goes to full speed normal printing again when it gets to straight line. This only happens on the first layer. All subsequent layers print as normal even in the curves. On one of the two printers i was able to get rid of the majority of the stuttering/dotting by dropping the initial layer speed to 10mm or less. I have reflashed firmware on both machines multiple times which has not helped. On the 2nd stuttering machine after a reflash but before recalibrating I ran a print and it ran perfectly fine in the air above the plate, but again after creating the bed mesh and calibrating everything else it went back to stuttering. Do you have any suggestions on what to try next? Could this be just a case of bad silicone lottery and the printers processing speed cannot handle the extra calibration needed for the 7x7 bed mesh? Or can the bed mesh code be optimized so it is not as taxing on the processor?

Bug Timeline

About 2 months

Expected behavior

I expected printer to print a smooth arc.

Actual behavior

printer stuttered while printing arc with dots of filament

Steps to Reproduce

first flash firmware
second calibrate machine and bed mesh
run a print with arcs with initial layer speed faster than 10mm

Version of Marlin Firmware

V2.1.3.1b3

Printer model

Sovol SVO4

Electronics

Stock

Add-ons

No response

Bed Leveling

None

Your Slicer

Cura

Host Software

Cura

Don't forget to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

No response

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

In motion.cpp, specifically update_software_endstops(), when 'new_tool_index' is 0 (left extruder) the resulting min/max will become 0/362 instead of -62/302 - the execution flows into line 864 - soft_endstop.min.x = 0, instead of line 869 - soft_endstop.min.x = X1_MIN_POS;

I have checked via M211 using pronterface that the max X for T0 is actually too high and could result in collision with right extruder:

>>>T0
SENDING:T0
Active Extruder: 0
>>>M211
SENDING:M211
  M211 S1 ; ON
  Min:  X0.00 Y0.00 Z0.00   Max:  X364.60 Y302.00 Z400.00

Bug Timeline

No response

Expected behavior

G1 X-50 should work when T0 is active, without disabling software endstops.

Actual behavior

G1 X-50 is ignored.

Steps to Reproduce

No response

Version of Marlin Firmware

The latest release

Printer model

SV04

Electronics

Stock

Add-ons

No response

Bed Leveling

None

Your Slicer

Prusa Slicer

Host Software

None

Don't forget to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

No response

Would it be possible to add 2 decimal places to the steps adjustments, at worst being 0.5 out is not really accurate enough

Is your feature request related to a problem? Please describe.

No response

Are you looking for hardware support?

No response

Describe the feature you want

Considering the current issue in Marlin, it is too easy to hit this save button when adjusting temperature or fan speeds. There is no need to save on this page as changes here are related to print in process.

I have hit this button many times, due to large fingers and a sensitive touch screen. As a result it makes it more difficult on the next print to set the starting offset.

Additional context

No response

**On the esteps adjustment, there should be x and y and z for each extruder.
Lovely add-on

Having tried the "stock" firmware and now 2 versions into your amazing upgrade of the touch screen and marlin code base, would you be able to type in a value for the z-offset page(s)? I'm only asking because since it was changed from 0.05 step to 0.01 step it does take awhile to get to the correct offset. Mine just happened to be -1.36. It seems sometimes when the firmware is updated, it zeros the value and I've taken pictures of z-offset along with x/y offsets for nozzle. I think this would just add a little to an already great release. Thanks again for your time

Is your feature request related to a problem? Please describe.
Nope

Describe the solution you'd like
When I press "Disable Motors" I'd like positive feedback that it was actually pressed.

Describe alternatives you've considered
Hit it 10 times just to make sure. And then another 5, for just in case.

Initially I had my flow turned down intentionally in prusa slicer(V. 2.5.0 released) to around 96%(0.96), with a minimum of 4 loops. I seen how the first loop progressed and while it was starting the second loop, I adjusted the flow on the screen to 102% on Nozzle 1. It then proceeded to move the nozzle to start the actual print without completing the rest of the loops. Print completed but it skipped part of the queue in marlin with changing the flow.

I have the CXC from Ember Prototypes. In order to use it, both tool heads need to be able to move over the same part of the bed. Currently the two heads are prevented from doing that, at least on the touch screen. This occurs despite the fact the inactive tool head is parked off the bed. In a future update if you could set up the manual movement to be able to move both tool heads to any X position on the bed, it would fix the issue. Even just allowing a small overlap in the middle would allow the printer to work with this device.

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

I get these warnings with VSCode when I build, but NOT with other Marlin 2.1.x repos I build:
In file included from C:\Users\brigh\.platformio\packages\framework-arduinoststm32\cores\arduino/WString.h:29, from C:\Users\brigh\.platformio\packages\framework-arduinoststm32\cores\arduino/Print.h:27, from C:\Users\brigh\.platformio\packages\framework-arduinoststm32\cores\arduino/Stream.h:26, from C:\Users\brigh\.platformio\packages\framework-arduinoststm32\cores\arduino/HardwareSerial.h:29, from C:\Users\brigh\.platformio\packages\framework-arduinoststm32\cores\arduino/WSerial.h:5, from C:\Users\brigh\.platformio\packages\framework-arduinoststm32\cores\arduino/wiring.h:47, from C:\Users\brigh\.platformio\packages\framework-arduinoststm32\cores\arduino/Arduino.h:36, from Marlin\src\feature\../sd/../inc/../HAL/./STM32/../shared/Marduino.h:36, from Marlin\src\feature\../sd/../inc/../HAL/./STM32/HAL.h:28, from Marlin\src\feature\../sd/../inc/../HAL/HAL.h:30, from Marlin\src\feature\../sd/../inc/MarlinConfig.h:31, from Marlin\src\feature\../sd/cardreader.h:24, from Marlin\src\feature\powerloss.h:28, from Marlin\src\feature\powerloss.cpp:31: Marlin\src\feature\powerloss.cpp: In static member function 'static void PrintJobRecovery::resume()': Marlin\src\feature\powerloss.cpp:583:40: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings] 583 | gcode.process_subcommands_now(PSTR("G1 E3 F3000")); C:\Users\brigh\.platformio\packages\framework-arduinoststm32\cores\arduino/avr/pgmspace.h:30:20: note: in definition of macro 'PSTR' 30 | #define PSTR(str) (str) | ^~~ Marlin\src\feature\powerloss.cpp:588:42: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings] 588 | gcode.process_subcommands_now(PSTR("M605 S1")); C:\Users\brigh\.platformio\packages\framework-arduinoststm32\cores\arduino/avr/pgmspace.h:30:20: note: in definition of macro 'PSTR' 30 | #define PSTR(str) (str) | ^~~

Bug Timeline

new to me, but I just started using this repo

Expected behavior

do not expect to see warnings like this. Don't with other Marlin builds I run.

I'm far form an expert, so maybe/likely operator error.

Actual behavior

get these warnings

Steps to Reproduce

1. Clone repo
2. build

Version of Marlin Firmware

2.1.3.1b3

Printer model

Sovol SV04

Electronics

stock

Add-ons

none

Bed Leveling

ABL Bilinear mesh

Your Slicer

Cura

Host Software

None

Don't forget to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

No response

The flow adjustment settings under the advanced tab keep resetting back to 100% after turning the machine off and on.

Hello I updated the new screen and the new firm ware on my Sovol sv04 but I didn’t record the printer info I got it all working so far but when I do a home or print the extruder hits the end when it goes to home position it comes to far it sounds like it’s jumping gears and I get a error message could you help me with these setting or may be explain to me how to fix this problem 🤷

Describe the bug
In Dual Mode, my start gcode includes G29. When running, Extruder 0 (left) begins in what seems to be position 4/49, near the front right corner. It then continues probing, going right, until crashing into Extruder 1(right), as if it believes it began at 1/49, or the front left corner. When running G29 in any other mode this does not happen.

To Reproduce
Steps to reproduce the behavior:
Slice model in Cura with G29 in start gcode
Change print mode to dual on touch screen
Start print, confirm mode is correct
Leveling begins in the wrong position.

Expected behavior
Slice model in Cura with G29 in start gcode
Change print mode to dual on touch screen
Start print, confirm mode is correct
Leveling begins at front left corner, building the mesh.
Print begins.

Printer Information
Sovol SV04
johncarlson21 v2.1.3.1
Touchscreen v1.2.7

Additional context
Add any other context about the problem here.
Original post below:
First let me begin by saying thank you for all the development you have done thus far, you saved this printer for me.

Here is my issue:
In my start gcode with Cura, I run G29 on all SV04 profiles (Single, Copy Mirror, etc). On everything but Dual mode it works fine. In Dual mode, Extruder 0 begins auto leveling at what seems to be position 4 in the regular mesh, so not quite the front right corner, but close. It begins the routine, heading to the right, but it seems that the printer believes it is beginning at the front left corner. This causes it to crash into Extruder 1 (right), then continuing on.

To print, I've removed G29 altogether and it worked beautifully (just finished a 25 hour print). However, I'm worried about not having a mesh active when I do this. Call me paranoid.

Again, G29 works perfectly fine in other modes. Thank you for reading!

SV04DualGCode.zip

Hey there! Loving this custom firmware, it's way ahead of stock.
I was curious if anyone has been able to implement universal bed leveling on their SV04. Of course, the touchpad doesn't have any UBL menus or anything, so I imagine this would be quite a bit of work. I think it's a real shame that the SV04 doesn't support it natively, as the bed is quite large and getting a high quality mesh takes some time.