solidworks_urdf_exporter icon indicating copy to clipboard operation
solidworks_urdf_exporter copied to clipboard

Exported STLs empty due to use by another process

Open BenArtes opened this issue 5 years ago • 18 comments

Solidworks 2019 SP3

While trying to export out model we ran into this issue while working, specifically when trying to select entire sub-assemblies as link components.

I break pointed at this line of code (between SaveAs and call to CorrectSTLMesh and verified that there were no warnings / errors and used Windows Resource Manager to see that Solidworks did still have the .STL file open. In fact Solidworks / SaveAs kept seemingly random STL files open until some point during export completion.

All broken exported STLs were listed as 1kB in Windows Explorer but was actually just 80 bytes and basically only contained the binary string solid part_name followed by enough 0x20 bytes to fill out the 80 bytes.

We found that selecting individual pieces of sub-assemblies resolved the issues so that's what we've done for now, but I wanted to report the issue. I tried to replicate with simpler models (including the models that were posted to the previous BitBucket issue), but couldn't reproduce it.

I'm happy to help try to debug the issue and have VisualStudio installed and the source cloned and building, but without thoughts on what to try I'll probably move on to our other issues / development.

Thanks.

BenArtes avatar Aug 27 '19 17:08 BenArtes

I've run into this issue one other time and could not pinpoint an issue with the code. It was some very strange glitch in the SW model itself. I could even try to manually save the STL and it would give me 1kb files. I think this has to be addressed on a model by model basis, but I'll leave this open if anybody else has inputs to add.

brawner avatar Aug 27 '19 17:08 brawner

Trying to export manually was a good test. We have some very experienced Solidworks users so I'll run this past them to see if they've ever encountered it or if they can discuss with Dassault.

I'll update if we figure anything out.

BenArtes avatar Aug 27 '19 17:08 BenArtes

I am also having this issue exactly as described. Solidworks 2019. The files are 80 bytes and contain solid base_link. Happens on our complex robot models

blaine141 avatar Dec 11 '19 06:12 blaine141

Are these models checked out by PDM? I believe this problem can be caused by incomplete checkouts or errors in the PDM model. Not entirely sure though.

For the meshes that are 0 bytes, can you manually hide all the components except the ones that make up the mesh and then save as STL with respect to the link’s coordinate system ? Does that mesh look good?

On Dec 10, 2019, at 10:12 PM, blaine141 [email protected] wrote:

 I am also having this issue exactly as described. Solidworks 2019. The files are 80 bytes and contain solid base_link. Happens on our complex robot models

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

brawner avatar Dec 11 '19 11:12 brawner

Solidworks 2018 SP4 I met the same problem when trying to export entire model, but some of the STLs are 80 bytes. Selecting individual pieces of sub-assemblies can resolved the issues but it would be quite annoying while dealing with complex robot models. So I try to copy the whole entire sub-assemblies and paste it, then export the copied whole entire sub-assemblies, It seems resolved the issues too. Maybe copy makes the assembly individual.

jjaaseon avatar Dec 23 '19 07:12 jjaaseon

Closing this issue due to age and the fact that the issue seemed related to SW itself.

brawner avatar Jun 12 '20 03:06 brawner

That seems reasonable, to anyone in the future, the issue was likely as @brawner described with solidworks PDM checkout issues. If I discover a particular cause I'll reopen this issue with details.

BenArtes avatar Jun 12 '20 04:06 BenArtes

Hi I know the issue is marked closed but any suggestions or further insights on how this issue can be solved?

trns1997 avatar Oct 01 '20 12:10 trns1997

Is your situation similar? Do you use PDM to checkout an assembly?

brawner avatar Oct 01 '20 18:10 brawner

@brawner I will get back to you on that. But I would assume so. For some reason, some exported STLs are 1kb in size. Our current work around is to manually export those broken STLs but would be great if we could avoid the manual work. I will get back to you tomorrow with more details.

trns1997 avatar Oct 01 '20 20:10 trns1997

@brawner so, to get back to your question. So we are not using PDM to checkout the assembly. And it seems to always be the same subassemblies that fail to export the STL files. Any clue why the stls exported are only 1 kb in size?

trns1997 avatar Oct 02 '20 11:10 trns1997

@trns1997 the cause of this issue isn't currently known. @brawner assumed, based on the evidence presented, that this was caused by incorrectly checking out a model from PDM, if you have a model that consistently has this problem, can you share it? Or can you have recreate the issue with a simpler assembly / sub-assembly that you can share?

Looking into this again, I found this discussion about it on the SW forums. In particular this answer claims to resolve the issue in VBA.

Without digging into it too deeply, looks like SW may be getting confused about what is selected and exporting the wrong thing / nothing? Maybe someone can try running the exporter with various parts of a model selected and not selected?

Considering the issues with the included exporter, this post suggests just re-implementing ExportSTL with a C# example here.

BenArtes avatar Oct 02 '20 15:10 BenArtes

I had originally thought this issue might have been due to PDM since that was the only situation it occurred in, but I honestly had no idea. I was able to reproduce the same issue by manually exporting the STL, and in that situation it might have been due to an incomplete checkout.

However, it looks like the links that @BenArtes found actually suggest a different fix, which is a great find. I'll try to incorporate this fix in soon.

brawner avatar Oct 02 '20 18:10 brawner

@brawner thank you will wait till the fix is merged then. Just a general follow up @BenArtes, I unfortunately cannot share the solidworks files due to confidentiality reasons, but for some reason when i deleted the subassembly part that failed to export stl in the main assembly when running the exporter and reinserted it and redid the mates and ran the export again it all worked fine. The stls generated in the mesh folder looked great. Either way lets hope the fixes @brawner pushes soon solves this issue.

trns1997 avatar Oct 02 '20 19:10 trns1997

Hi, I am having the the same issue with SolidWorks 2020 SP5. Below is a minimalistic example of a cube that produces the error for me. Maybe it helps. https://cmu.box.com/s/ky2nn2pawi5k2v9aam9f4zwwwhqq3gxe

Instructions:

  1. Open Assembly EXAMPLE-SIMPLE-CUBE.SLDASM
  2. Run the URDF exporter using the existing export configuration (i.e. simply export component SimpleCubeAsm as the base-link)
  3. Examine the generated mesh file base-link.STL. If the issue occurred, then the file should be empty/invalid (~80 bytes).

The attached assembly contains two layers of sub-assemblies. The last layer contains the cube solidworks part. I noticed that when I export any assembly/part other than SimpleCubeAsm, then the export of base-link.STL is successful.

AdrianSchoisengeier avatar Dec 08 '20 02:12 AdrianSchoisengeier

Exactly same issue here with SW2021 SP2 and exporter v1.6.0, also I can share my model here. I also show you here which of those STLs are not being generated correctly: image which are the most complex ones...

OrionHeart avatar Apr 03 '21 22:04 OrionHeart

so I also figured out that for every subassembly that didnt get the propper STL file, it gets autogenerated if I select a lower hierarchy for each part, like this: image Now all get generated, I just need to figure out how to use the URDF in CoppeliaSim (aka V-REP), as I get a "no robot" error

OrionHeart avatar Apr 04 '21 00:04 OrionHeart

This is not a fix, but I got this issue when I had incorrectly chosen the links. I will try to explain how it happened and how I fixed it.

e.g., Consider the following hierarchy of assembly with two sub-assemblies and further, one among them has two sub-assemblies -Base_robot -Moving_parent_part -sub_assembly_1 -sub_assembly_2

While exporting, I chose the links in the following order -base_link <Base_robot> - 1 child -Base_Child <Moving_parent_part> - 2 child links - link1<sub_assembly_1> - 0 child link - link2<sub_assembly_2> - 0 child link

The export gave 80 bytes STL for Moving parent and sub_assembly 1 and 2.

I think the issue was while choosing the part for Base_Child; I chose Moving_parent_part, which already includes sub_assembly_1 and sub_assembly_2. Further, I selected sub_assembly_1 for link1 and sub_assembly_2 for link2, which might have triggered the error due to nested selection.

When I moved sub_assembly_1 and sub_assembly_2 out of the Base_Child, and followed the previous selection, the STLs were properly generated.

gkarun avatar Nov 14 '23 11:11 gkarun