[BUG] Wanhao D7+ Weird Issue (rotated, squeezed, duplicated)

[Jacotheron]

Whenever I process the file from PrusaSlicer, using the default Wanhao D7 profile (supplied with UVtools), and exporting (from UVtools) as the xml.cws, the printer rotates the images by 90 degrees, and squeeze 4 of them side by side. In essence it tries to print the file 4 times, but no dimensional accuracy.

I have opened (as it is a plain zip) the generated file and compared it with a file made by Wanhao Workshop, and found no specific potential issues:

• While Wanhao Workshop prefixes all the files (except the manifest.xml) with "mango3d", UVtools prefix it with "UVtools". Prior to using Wanhao Workshop I used other software, which used a different prefix for all files - thus it is not the prefix.
• Both zip packages contains the manifest.xml file. In essence this files have a list of the images/slices in order (with their name), as well as the gcode file (with its name). UVtools also mentions the "SliceProfile" (UVtools.slicing), but typically the printer should only read what it needs, and should ignore this extra info.
• UVtools also added a file "slice.conf", but once again, I expect it to be ignored, as not even the manifest points to it.
• Wanhao Workshop also added 2 extra files (preview.png and preview_mini.png), but on the D7, this is never shown to the user (maybe on a newer model), and thus it not being there should not cause issues (the other software also did not have these).
• The images themselves are PNG with dimensions 2560x1440 for both zip packages. I even opened them in a hex viewer to compare the binary data (at the header and other meta), but found no differences (other than the content); thus it is not even due to being "progressive" or other encoding issues.

The generated gcode differs quite a lot, but tweaking gcode for many years now, the effects of the gcode are the same (just achieved using different means). At most I would only expect printing issues (for example not completing a move before turning the UV on etc -> things managed by the gcode).

Are there any possible solutions I can try? I am willing to work with suggestions to get this solved.

As an extra note, something I found very early on with my D7+ was that filenames may not contain spaces. A space would prevent the file from getting loaded and thus being unprintable (until the space is removed). How can I ensure that the filenames does not contain spaces?

[sn4k3]

Can you send me an original file from thier slicer and a file from uvtools?

[Jacotheron]

Ok, I have attched here the 2 file wanhao-workshop.zip - Wanhao Workshop file (this is simply a white block, used to confirm the screen is fine - no dark/dead spots).

Shape-Box.xml.zip - PS and UVtools file (this is a very similar file, to see the dead spots).

Both files have been renamed to .zip files, as Github does not allow the .cws extension.

[sn4k3]

Here the problem:

Original uses 32 bit png, UVtools uses 8 bit To test, replace first layer image from uvtools file with the original, but give it the same name UVtools00.png Do a dry print test, i expect the first layer to print well but the second and above to do the problem.

Additionally i would need you to slice other files for other Wanhao printers, does all uses 32bits?

[Jacotheron]

That dry run test matched exactly what you expected: the first layer (from original Wanhao Workshop file) filled the entire build plate, and when it continued to the 2nd, it was once again duplicated and stretched.

I also looked at a couple of other files (tried to do a random selection) sliced in the past few years, and all of them uses the 32bits.

I believe now this is the cause and the solution is to use 32bit images.

[sn4k3]

Ok, if all Wanhao machines that use that format (cws) use 32 bit png i can patch to do so

[Jacotheron]

I believe so. The Duplicator 7 and 8 both make use of the Wanhao Workshop (though separate versions), whereas the 11 specifically states that it use Chitubox.

I only have the 7+ (plus meaning it runs autonomously vs connected to the computer on usb and hdmi), so unable to test/verify.

Since you already split the Wanhao D7 from the Wanhao D8, updating only the D7's files should be the safest option, until someone can confirm for the D8.

[sn4k3]

Since you already split the Wanhao D7 from the Wanhao D8

They are the same format (.cws) they are not split. So updating to 32 bit will affect all other printers that use .xml.cws

[Jacotheron]

I am unable to find specific information on what image types are required by the cws file format. I also don't know anyone with a D8 to test and confirm whether it will work or not (I am hesitant to ask for a potentially breaking change). That said, I would find it very strange if Wanhao implemented their firmware differently between the 2 printers. At the very least, I would expect the D8 to be backwards compatible, if implemented differently.

As to other printers implementing the xml.cws file, I don't know which they are or their implementations.

Would it perhaps be possible for you to split the Wanhao methods to a new format (I see that Novamaker have 2x versions of the CWS format, in the Export list)? Even if that would take a bit longer before it can be released, that will ensure an existing user's workflow does not break.

[sn4k3]

The xml.cws is a virtual extension to make the difference between Nova cws and others. xml.cws is .cws at same, the difference is that they have a manifest.xml which is how uvtools detect the difference between nova and Wanhao. File formats are a mess and .cws is just a zip which can use a ton of different methods, using same extension per format is a bit difficult to control everything. But as told i will change .xml.cws to use 32 bit and nova .cws will stay on 8 bit

[sn4k3]

Test with the new release and report back

[Jacotheron]

I have done a dry-run and it worked (no more rotated, squeezed and duplicated); now doing a full print to confirm that it all works as expected.

[Jacotheron]

The test print is running a bit longer than I expected (Prusa estimated at 6h22; UVtools estimated at 10h19; while currently it is more than 12 hours and only at ~88%, estimating 14 hours total).

In any case, I can see the object and the size if what I expect, as is the shape, however I am finding a weird annoyance: the UV comes on before the lift move completed (in fact the uv goes off, then turn back on, and then the lifting sequence starts). This is causing the print surface to suffer (and seems to cause layers to be higher than the expected layer height).

I have carefully analyzed the gcode files and found one missing command G4 P0 -> it ensure all previous moves are complete, prior to sending the next command.

Basically the lift command is given, then G4; lower command is given, then G4.

Are there any way I could maybe make the adjustment in the gcode myself? You have so far been a great help, thank you very much (the UVtools are great).

[sn4k3]

UVtools compensastes for movements, it's all the delays that starts with a 0, eg: ;<Delay> 06500 However it depends on real speed and firmware so the compensation can be a bit off. It's hard to keep all variations of gcode on same file format but i will seek a solution.

Are there any way I could maybe make the adjustment in the gcode myself?

You need to extract the gcode file, do a find and replace regex and replace the file on the ZIP. It's not hard but sucks

[Jacotheron]

I have now tried a couple a things, and it is not working well. I tried reducing the lifting speeds (as I noticed UVtools was by default faster), still the same issue. I have tried to insert the wait commands throughout a whole print, but still it was not working.

I am now at the point where I just want to replace any part that is giving me issues. On this printer it seems that first thing giving me issues is the NanoPi they have inside (which runs their firmware, reading the gcode and displays the images). I have a couple of RaspberryPis laying around (3B+), and was wondering what image I can run on it to have it replace the NanoPi?

Do you have options for me? Ideally I would like to use PrusaSlicer to handle the slicing, and if needs be, convert it to whatever with UVtools.

I have noticed NanoDLP, which seems to be fine on the RPi, but it is its own slicer (so as I understand it, you upload the stl file, and it slices and streams the commands to the printer). However some files I might need to print, have high poly counts, and even my desktop takes a while to slice them. It also works through the network, but my RPi have a 7" touch display already, so would like to use that as well.

The printer then also contains a Ramps 1.3 style mainboard, optimized for the printer (z-min, z-motor, fans, UV Led etc), for which I have found original firmware source (thus I can customize it, and reflash easily). The firmware is Sprinter based, but I have also found a community created Repetier based firmware (which is actually made for NanoDLP compatibility). Then it contains a separate HDMI to display converter board (along with a further adapter board to which the display connects; thus I can use all of these and simply provide HDMI signal).

[sn4k3]

I'm not aware of other solution other than NanoDLP. We really need solutions on the market and open-source!

I think in your case is best to fix what isn't working. Upgrading to other board / firmware can be more problems than a solution. If you print the original file from Creation workshop, does it print without the problem?

[shahinv]

You can slice on desktop and upload it to NanoDLP. Also you can slice on prusa and upload.

[sn4k3]

New version append G4 P0 at every required sync. Please check

[Jacotheron]

I have now setup the printer so that I can either use the original NanoPi or my RaspberryPi (NanoDlp).

I have just tested the new version of UVTools and still found an issue, it seems to me that the line to show the slice ";<Slice> 0" also enables the UV light, this resulted in it starting early, while the printer was moving.

;LAYER_START:0 -> UVtools
;PositionZ:0.05mm
;<Slice> 0
G1 Z5.05 F25;Z Lift (1)
;<Delay> 013500
G4 P0;Sync movements
;<Delay> 1000
G1 Z-5 F100;Retract (1)
;<Delay> 04500
G4 P0;Sync movements
;<Delay> 3000
M106 S255;Turn LED ON
;<Delay> 35000
M106 S0;Turn LED OFF
;<Slice> Blank
;<Delay> 1000
;LAYER_END

vs

;********** Layer 0 ****** -> WanhaoWorkshop
;<Delay> 3000
;<Slice> 0
M106 S255 ; UV on
;<Delay> 25000
M106 S0 ; UV off
;<Slice> Blank
;<Delay> 1000;********** Lift Sequence 0 ******
G1 Z6 F25
;<Takes> 14400
G4 P0 ; Wait for lift rise to complete
;<Delay> 1000
G1 Z-5.965 F40
;<Takes> 8947.5

I notice that everytime the slice is output, it is followed by the "M106 S255".

I have changed this in the test print (moving the slice comment to just before the Turn LED ON), for 12 layers, and it kept in sync. All movements completed before uv on, and only started after the uv was off. This seems to be the last required change.

Regarding the NanoDLP, I am having issues with it communicating to the screen (must be an HDMI timing issue, where currently only half the screen works, but it syncs); while working on getting the NanoDLP to work, I have flashed new firmware on the Arduino compatible (used to control the steppers and UV), however this firmware is said to remain compatible with WanhaoWorkshop gcode (it simply forces the board to reply when a movement is complete).

Thank you for your patience and time.

[sn4k3]

Ok so we need to test if it's <Slice> fault... Please do a dry run of a file but replace gcode content with:

;START_GCODE_BEGIN
G21;Set units to be mm
G91;Partial positioning
M17;Enable motors
M106 S0;Turn LED OFF
;<Slice> Blank
G28 Z0;Home Z
;END_GCODE_BEGIN


;LAYER_START:0
;<Slice> 0
;<Delay> 3000
;<Slice> Blank
G1 Z20 F150;Z Lift (1)
G4 P0;Sync movements
;LAYER_END


;START_GCODE_END
M18;Disable motors
;END_GCODE_END
;<Completed>

Does LED goes ON after homing? If so does it waited 3s before lift? Also after 3s wait does ;<Slice> Blank turn off LED? Please report back

[Jacotheron]

I have tried your gcode test above, the printer immediately completed (no UV, and no delay).

I then used the following gcode:

;START_GCODE_BEGIN
G21;Set units to be mm
G91;Partial positioning
M17;Enable motors
M106 S0;Turn LED OFF
;<Slice> Blank
G28 Z0;Home Z
;END_GCODE_BEGIN


;LAYER_START:0
;PositionZ:0.05mm
G1 Z5.05 F25;Z Lift (1)
;<Delay> 013500
G4 P0;Sync movements
;<Delay> 1000
G1 Z-5 F100;Retract (1)
;<Delay> 04500
G4 P0;Sync movements
;<Delay> 3000
;<Slice> 0
;<Delay> 35000
M106 S0;Turn LED OFF
;<Slice> Blank
;<Delay> 1000
;LAYER_END


;START_GCODE_END
M18;Disable motors
;END_GCODE_END
;<Completed>

This is very similar to what UVtools generate now, however the ;<Slice> 0 is where the M106 S255 would be, which is now removed. With this, the delays, and movements are correct, and the UV still turns on (when the slice 0 is being executed).

I don't know if other printers may use the M106 explicitly, so would recommend having both there, but the important part for Wanaho is that the slice should be called only when the printer is ready to expose the next layer.

[sn4k3]

I have tried your gcode test above, the printer immediately completed (no UV, and no delay).

That's very strange.

but the important part for Wanaho is that the slice should be called only when the printer is ready to expose the next layer.

I will try to put it working, but there is are strong motives why i set ;<Slice> as first line. Each printer use thier only way to execute commands instead of a standard schema, this make very hard to have a generic parser

[sn4k3]

Check the latest version and report if is fixed

[Jacotheron]

On the dry-run, it works as expected; will now start an actual print to confirm.

[sn4k3]

Should be fixed now