[Bug] Export file in PCB Exposure GUI out of the window borders

[thirstyone]

System

Linux Mint

Printer and Slicer

• Printer:
• Slicer:

Description of the bug

Using the recently installed UVtools in Linux Mint, I can't see export options in PCB Exposure - they are 'shown' to the left, outside the visible window.

How to reproduce

Feature request: a CLI one-liner to save gerber to stl (or, even more preferably, to svgx)

Files

No response

[github-actions]

This is your first time submitting an issue with UVtools 🥳Please review your issue and ensure that the submit template was followed, the information is complete, and not related to any other open issue. It will be reviewed shortly. Debugging is very important and make the program better. Thanks for contributing and making the software better! 🙌

[sn4k3]

I didn't understand this issue.
Please provide screenshots or more clear description of the problem.

Feature request: a CLI one-liner to save gerber to stl (or, even more preferably, to svgx)

The UVtoolsCmd can run operations from CLI, check the run command. If you are using AppImage you need to run: UVtools.AppImage --cmd run that will give you the syntax.
But you still need an exported uvtop file from GUI to use as template to run the operation from CLI. After having the template you can build a simple BASH script to produce what you want

[thirstyone]

today, when I launched it, the UI looks this way (no options for PCB exposure - the entire 'tools' and 'calibration' menu item are absent.

[sn4k3]

Because you haven't open a file. Uvtools only works if you load your file in.

[thirstyone]

okay, indeed I need to have at least one file open to see the menu (though it seems strange with regard to PCB exposure - I can't open gerber file without opening anything else).
so, here's the first defect (the menu is partly out of the window -

today, when trying to reach that tools menu, I reinstalled UVtools together with dependencies (as per instructions on github), and now, though I can see PCB exposure option, it loads up something strange (yesterday that functionality worked just fine)

This is how it looked yesterday.

Besides that, today this file-convert to menu doesn't work at all.

Another defect is I can't change print resolution - when i hit "change" button I get this message, and nothing changes..

[sn4k3]

(though it seems strange with regard to PCB exposure - I can't open gerber file without opening anything else).

I think the problem is the fact you don't understand the concept of UVtools...

The reason why you need a prior file is because UVtools need to fetch all data, what is the printer, what is able to do (limitations), what pixel pitch it use (Resolution), what the sizes/dimensions, etc... Without any of that data is not possible for UVtools to do anything because it can't guess what is your printer or file format.

Same apply to slicers, you can't slice a file without selecting a printer which contains all it data to be able to slice the STL to the printer.

So you have a gerber and want UVtools to translate that "correctly" to your printer LCD/pixels, how do you expect that to happen if you don't supply the proper info for it able to do the conversion math (Millimeters to pixels) and build the file structure?

That said you can't just open an random file or a PNG as you did in the screenshots you sent. You need to open a file that you previous sliced and print for the target printer you aiming for! This is not optional! Either use or duplicate an file you printed before, or just slice a new file for your printer and use it as a dummy file.

You may see the load file an inconvenience, but think again, if you had to configure printers, formats, parameters and different profiles for each printer you had you will hate it even more. UVtools was made to modify and work under files, not create them from scratch, so it always source all the information from a sliced file that you already have. If you supply the wrong file it's normal that things wont work.

[thirstyone]

okay. instead of choosing my printer in the settings you suggest that i open a file once printed on my printer. at least, that explains why I couldn't find any printer profile config page ;-) it looks like more of a struggle. here's the error i got when opening an .svgx file that i actually printed out on my printer.
it doesn't show any .stl files in the open-file dialog, and it doesn't allow to open .f3d (probably supported by the earlier firmwares of my printer)
you have that 'change resolution' tool - what's its use case?

[thirstyone]

And here's the bug I initially reported. (same picture when trying to open the recent files menu)

[sn4k3]

The error tells about the problem. The SVGX format was made without including the resolution and display size, that information is critical for UVtools. Also SVGX use metric vectors instead of pixels/bitmaps, it's a unique format, this way UVtools have no way to adquire resolution nor trace a image from supplied vector. The only way is by having the missing information. To have such you need to use other slicer, configure a printer with same properties as yours, slice file, open in UVtools and convert to SVGX. To facilitate this you better use PrusaSlicer with my printer configurations, it will save the mess of dealing with parameters and when open on UVtools it will auto convert to SVGX and work under it --> Follow this guide: https://github.com/sn4k3/UVtools/wiki/Setup-PrusaSlicer

Note: When UVtools converts to SVGX it will inject the Resolution and Display information on file and then it can always be open back on UVtools.

it doesn't show any .stl files in the open-file dialog, and it doesn't allow to open .f3d (probably supported by the earlier firmwares of my printer)

UVtools is not a slicer, it only reads output files from slicers, this program is a post-process program to work with MSLA/DLP files.

• STL is model file (Triangles)
• f3d is a CAD project file

None of those are sliced files and UVtools don't do slicing on it own, so they are not supported as input.

you have that 'change resolution' tool - what's its use case?

It allow you to change file and image resolution, also display size.
Should never be used, only who have strong knowledge how printers relate to resolution and display size and also what this is doing in depth can use the tool, even still I don't recommend it.

In a easy sample and also why it was created: You can use it if you have A and B printer (Using same file format), and you want to print A file on B printer but resolution mismatch and it don't allow to print. This tool allow change resolution to match printer B requirement, cropping or expanding image, however if pixel pitch of A is different from B you have to adjust Display too which will trigger a resize to translate to the correct pixel pitch and ensure correct model portions on B, still if the case this not recommended as resize can distorce model.
My recommendation is to never use it, always work under the proper file for your printer.

BUT: If you want to adjust resolution and display size to create something from scratch/layer0, eg: calibration tools, PCB tool, lithophane tool, etc. Using the change resolution tool will never hurt, as long you input the correct information to match the output printer.
eg:

1. From demo file use the tool to change resolution and display using your machine preset from list, untick the resize layers and run the tool.
2. Run PCB tool
3. File -> Convert to SVGX
4. From there you will have a valid file to work with and keep it to run future PCB tools.

And here's the bug I initially reported. (same picture when trying to open the recent files menu)

That is indeed strange, because menu should open to the right and not left.
This is out of my scope as it come from UI framework who decide where to open the submenu.
Try to maximize the window and see if the problem remains.

---

PS: Never use the demo file, its only there to explore the program if you don't have a file and to remember the user to open his file, but should never be used to real reasons.

[thirstyone]

hey, that was not easy! but at least I can once again open gerbers ;-) thank you!
as for the export dialog submenu bug - when the main window is maximized, I can't even see the submenu. However, when I move the main window across the screen, at some the submenu becomes visible. But if you move the window another 100pxs to the right - once again it disappears. I'd really love to fork that gerber part to make the workflow quicker and less complicated..
btw, there's no such a bug in macos ;-) but it doesn't seem to work in command line mode..

[sn4k3]

The UI framework have some bugs and it's more reliable on Windows and macOS, if you wish to contribute for it you can post the issue under their repo: https://github.com/AvaloniaUI/Avalonia/issues you will need to provide much data as you can in order for them track the problem. Including the tricks you need to do for it to be visible.

but it doesn't seem to work in command line mode..

To use PCB tool under CLI you need to export the configurations of the tool and use it as template. Then you need to modify file to select the gerbers, this can be done easy with a bash script where you can even drag and drop your gerber into it.

Here a template:

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<OperationPCBExposure xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <LayerRangeSelection>None</LayerRangeSelection>
  <LayerIndexStart>0</LayerIndexStart>
  <LayerIndexEnd>971</LayerIndexEnd>
  <ProfileIsDefault>false</ProfileIsDefault>
  <Files>
    <PCBExposureFile>
      <FilePath>gerber_v4-F_Cu.gbr</FilePath>
      <InvertPolarity>false</InvertPolarity>
      <SizeScale>1</SizeScale>
    </PCBExposureFile>
  </Files>
  <MergeFiles>false</MergeFiles>
  <LayerHeight>0.1</LayerHeight>
  <ExposureTime>10</ExposureTime>
  <SizeMidpointRounding>AwayFromZero</SizeMidpointRounding>
  <OffsetX>0</OffsetX>
  <OffsetY>0</OffsetY>
  <Mirror>false</Mirror>
  <InvertColor>false</InvertColor>
  <EnableAntiAliasing>false</EnableAntiAliasing>
</OperationPCBExposure>

Save that as a filename.uvtop and feed it using UVtoolsCmd run slicedfile.svgx filename.uvtop

With a simple regex replace you can replace the input file <FilePath>gerber_v4-F_Cu.gbr</FilePath> with new file under the bash script, same goes for other parameters you want to change.

Still I think this is not worth, as you always should confirm the output, if you have to open the UVtools to confirm the result why not run the PCB tool from UI in first place?
The CLI is only good if you want to batch or automate multiple actions.

[thirstyone]

that seems exactly what I was looking for! thank you!

[dc740]

Somehow this bug report changed the subject, but I'm also seeing the menu issues in Ubuntu 23.10.

I'm not being able to export to some files. The menu "moves" when I move the window so I can see some extra options, but right now I can't export to chitubox at all because I can't get to that menu in any way.

"Open recent", "Donate" or any menu that opens a sub-menu is out of reach. I tried compiling it locally but got the same results.

(Should I open a different ticket so the discussion is cleaner?)
Thanks.

[sn4k3]

@dc740 that bug is not related to UVtools but UI framework, It can't be solved on UVtools side. I suggest to open the issue on framework side as I already mention here ⬇️

The UI framework have some bugs and it's more reliable on Windows and macOS, if you wish to contribute for it you can post the issue under their repo: https://github.com/AvaloniaUI/Avalonia/issues you will need to provide much data as you can in order for them track the problem. Including the tricks you need to do for it to be visible.

thirstyone mention that it work fine under macOS, as so Windows. So its a linux problem on the framework.

EDIT: I just noticed that the bug was introduced on latest avalonia version. If you use UVtools v4.2.0 it will show correctly (It uses older avalonia version)

I will open the ticket with them.

[dc740]

Thank you for the fast reply. For reference, it was introduced in Avalonia version 11.0.8 and worked fine in 11.0.7:
AvaloniaUI/Avalonia#14554
AvaloniaUI/Avalonia#14568

I'm going to investigate how to revert in my local compiled binary and see if that fixes it, but it looks like it.

[sn4k3]

You can downgrade Avalonia on your local build, OR downgrade UVtools version to 4.2.0

[dc740]

I can confirm that downgrading Avalonia to 11.0.7 works OK locally. Thanks!

For anyone else looking to workaround it until the Avalonia bug gets fixed can change 11.0.9 to 11.0.7 references in these two files:

         ./UVtools.AvaloniaControls/UVtools.AvaloniaControls.csproj
         ./UVtools.UI/UVtools.UI.csproj

Then compile and the local build will work just fine.

(by the way, thank you again!!! this tool is amazing)