-
|
A couple of months ago I upgraded to UVTOOLS 4.4.3, then later to 5.0, now at 5.0.2. Since 4.4.3 I've noticed that UVTOOLS seems to be trying to decode and implement 2 stage lift for a pwmx printer file which does not support this (Anycubic Mono X). The result is corrupted timing being used whenver I save an updated pwmx file in UVTOOLS. I'm using the latest firmware (3.5.4) and slicer software (Photon Workshop) from Anycubic support website. Slicer setup for Mono X does not accept 2 stage timing for lift/retract. When I print a pwmx file saved in my slicer, it shows a 5h 52m print time on the printer screen. When I print the same file after being saved in UVTOOLS, it shows 8h 4m print time. UVTOOLS shows 2 + 2.1 for lift distance on normal layers (set to 7 in slicer), but shows correct lift distance for base layers, and shows incorrect values for lift and retract time for all layers. I'm pretty sure I could fix this by going back to a UVTOOLS version prior to 4.4.3 because I used it for over a year a while back with no 2-stage timing stuff. Is it possible UVTOOLS is mis-reading the pwmx file format version or something? I see it has the capability to save in 3 formats for pwmx, and when I tried all 3 then diff'd them with the slicer copy... all were very different. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 8 replies
-
|
UVtools does not set any TSMC values by itself. If you find a file that does send here without saving with UVtools (A copy directly from slicer)
Nothing related to TSMC was touched in v5. However you can try revert back to v4.4.3 and report back with the result. |
Beta Was this translation helpful? Give feedback.
-
|
I confirmed that UVTools thinks my pwmx file is v 516, as saved by slicer. Nevertheless, there is no 2 stage timing settings in slicer for the Mono X (also printer manual shows simple single-stage timing settings for this model, I never even heard of TSMC before I upgraded UVTools to 4.4.3 and started investigating why it now shows 2 timings and lift distances). Also re-confirmed that UVTools displays 2 stage timing values which are mostly changed from what I saved in slicer. And again, the file from slicer shows a print time of 6 hours when I load it in printer, and the UVTools version, saved without changing anything, has an extra 2.5 hours added to the print time, as the printer sees it. If you want to look at it, I've attached the print file as saved directly by Photon Workshop 3.5.0. My printer thinks it will take approx. 6 hours, which agrees with slicer estimate. After saving a separate copy in UVTools without changing anything, the UVTools copy shows approx. 8.5 hours print time on my printer, since it has mistakenly put lower speeds in for 2 stage lift on normal layers (and mistaken my printer for being TSMC compatible?). UVTools is adding 2.5 hours of print time without my telling UVTools to change anything. Since neither the factory slicer nor the factory printer support TSMC, I'm thinking UVTools should not either. |
Beta Was this translation helpful? Give feedback.
-
|
Again, UVtools does not think nor change anything by default. When you first load the file, UVtools loads the file EXACTLY as slicer did.
They can mess up the file as they want because that data if not used by printer will not impact anything. However, UVtools have no way to know, and all data set is used for calculations, because of that is impacting the time calculation as you observe. You have the option to ignore or sanitize the file by setting no TSMC. Additionally, UVtools will turn on advanced flag to print per layer data instead of global data, which can introduce problems, this is again because anycubic mess up file with misinformation. This printer IMO should never support the v516. My advice: Convert file to version 1 |
Beta Was this translation helpful? Give feedback.
-
|
UVTools is changing something, because it mysteriously adds 2.5 hours to my print time. From what you say, it is likely that slicer has invalid values for fields not used by this printer, but UVTools is using those values as if they are valid. Perhaps there's a flag set in the 516 file which tells the printer not to use 2 stage timing fields, and UVTools is changing that flag on save. That's just a theory. I will try to save my file as version 1, and see if that preserves the correct lift timing and print time. |
Beta Was this translation helpful? Give feedback.
-
|
I just sliced and saved a trivial print file -1cm cube- then loaded it into UVTools, did save as, exited, then did a diff on the 2 files: My printer shows the UVTools copy takes 35m to print, the original only 30m. I'm still trying to check this, but I suspect it's because the invalid values in those fields you show in the slicer file for normal layers are causing the added print time. UVTools exports to v1, v515, and v516 also report the extra 5m print time. |
Beta Was this translation helpful? Give feedback.
-
|
Ok here's what I think is happening. Photon slicer does not expose settings for TSMC or for having separate lift/retract settings on base layers and on normal layers. Also, Mono X manual does not discuss these settings. However, you say 516 format supports these settings, and UVTools exposes them to the user. When I load my slicer output file in UVTools, it shows correct timing and lift for base layers, but slow speeds and insufficient lift for normal layers. Those normal layer values are not set in the slicer UI, and they are invalid and are the reason UVTools adds extra time to print jobs, and only lifts 4.16 mm on each exposure instead of the 6 mm I specified. And one of those 6 bytes in the print file which were changed by UVTools is causing my printer to use the invalid separate settings for normal layers encoded in the file, whereas when I print the slicer version, those values are ignored by my printer, and the values stored in the fields for base layer are used for all layers. So my printer hardware actually does support having these separate settings, but Anycubic has chosen to keep these settings hidden from users, and the Anycubic slicer fails to populate them. My printer ignores these extra/invalid settings when printing from slicer file. But when printing from UVTools copy my printer uses these extra/invalid settings. This has to be because of those 6 bytes changed by UVTools when it saved my otherwise unmodified slicer file. Who is the owner of the 516 file format? Anycubic? Or is it a wider industry standard? Is there something in the file definition which tells the printer to only use base layer settings and not both? Or sets some kind of mode? Do you know what those 6 bytes do? Thanks for taking the time to look at this. I've been grateful to have UVTools over the last few years to clean up my prints, and I've learned much through it's reading references. |
Beta Was this translation helpful? Give feedback.
-
|
I finally did exhaustive testing on this issue, and found that UVTools did not change the actual lift settings used by my printer during print. I measured actual lift distance and travel time. UVTools did, however, change the print file such that my printer reports 2 extra hours of print time at the start of (and throughout) the job. UVTools also displays invalid lift settings for a loaded print file. While these glitches sent me on this goose chase, they did not affect the actual print, and I feel safe continuing to print files saved by UVTools (and also ruled out UVTools as cause of print failure I had the other night). One of the bytes modified by UVTools in my print files, at byte offset 0x84, was changed from 0 to 1. On a hunch I loaded the file into a hex editor, and changed this 1 back to a 0 again, and printed it. Poof! The incorrect print time estimate was gone, and the original correct estimate was restored on my printer screen. Thanks again for looking at this, and sharing your tech insight. |
Beta Was this translation helpful? Give feedback.
-
|
In short, Anycubic set TSMC values but they aren't support by the printer. Globals will be used but integrity between globals and other data fails. If you compare globals VS TSMC (Slow + Fast height) does not match with global set value. (They like to mess up values and invalidate thier own spec). So, all calculations are based on those TSMC values because they are set. There is a flag to enable / disable TSMC (AdvancedMode), with that flag and on decode I could sanitize all values and remove TSMC... Also UVtools only change that flag to true if you change any of TSMC the values, otherwise it will stay as 0. The byte offset you found: The format and its versions are held by Anycubic and only Anycubic machines use this format. About UVtools time estimate, it's just an estimate, and with error. There are some variables missing to make an accurate calculation. And so you should never expect UVtools estimate to be correct at the minute. To make your file clean, you must:
Alternative:
|
Beta Was this translation helpful? Give feedback.
-
|
I see. So the global values are in separate fields and I'm not seeing them in UVTools, and my printer won't display TSMC values on screen. However with flag set, both UVTools and printer add 2 hours to a 3 hour print job. It sounds like Anycubic is generating print file with the flag 0, to indicate global settings are used. So wouldn't UVTools just go by that? Alternatively, if UVTools wants to offer per-layer and TSMC settings to override global settings, maybe it could populate the TSMC fields based on the global values, for print files where flag is 0? During my testing I discovered that Mono X is in fact using TSMC, but it is probably hard-coded in firmware, because I'm not setting it anywhere. Apparently, it takes about 25% of the lift distance, and uses 50% lift speed for final lift/retract stage. I tested this using a 15mm lift and 360 mm/min global setting, and with 8mm and 240. In Photon Workshop slicer, there is a drop-list to let me change the print profile ("Control Type") from Basic to something else I can't see because the list is greyed-out for the Mono X. When I change printer type to a newer model (Photon M7), I get the other setting, Advanced, and that lets me set TSMC values. Presumably, when slicer saves this print file, flag would be 1. Also, you mentioned UVTools won't change this flag on my print file unless I change TSMC values. But this is not what I see. Three or four times I've loaded a slicer file into UVTools, then did File -> Save As directly without modifying a thing. Each time it changes those 6 bytes I showed you, including the flag. When I make repairs but don't touch printer values, and save a modified copy, it sets the flag. |
Beta Was this translation helpful? Give feedback.
-
I think when PerLayerOverride flag is ON it will show the print time from file instead of calculating on firmware. So the time you see its the time from UVtools.
Possible, but with current implementation and abstraction is hard to do such. Anycubic is the only file format who use this kind of flag.
Your machine was released when only version 1 exists (no tsmc or other fancy features). They released some firmwares but is unknown what it supports. Note that versions are retro compatible even if printer does not know v516, as file is made with jump addresses, v1 can print v516 file, just all "new" features are ignored / not read.
Thats the AdvancedMode which turn on or off TSMC. In your case it write as 0 (Disable).
I think you are mixing the flags,
How they set:
These flags and values are visible in left information panel on UVtools (Properties)
|
Beta Was this translation helpful? Give feedback.
I finally did exhaustive testing on this issue, and found that UVTools did not change the actual lift settings used by my printer during print. I measured actual lift distance and travel time. UVTools did, however, change the print file such that my printer reports 2 extra hours of print time at the start of (and throughout) the job. UVTools also displays invalid lift settings for a loaded print file. While these glitches sent me on this goose chase, they did not affect the actual print, and I feel safe continuing to print files saved by UVTools (and also ruled out UVTools as cause of print failure I had the other night).
One of the bytes modified by UVTools in my print files, at byte off…