ugbatch.bat gives different result from published PDF through worker.bat
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
ugbatch.bat gives different result from published PDF through worker.bat
Version: Windchill 13.0
Use Case: Recently ran across an issue where a pdf generated through Windchill by way of my NX workers comes back with some of the view geometries not showing on a drawing. When I run that same file through ugbatch.bat, I get the correct output. Is this a CreoView Adapter recipe issue? Or NX settings issue? Leaning toward the former but I don't know what different settings ugbatch.bat (out of the box, in my case) may run to get a different result.
Description:
Recently ran across an issue where a pdf generated through Windchill by way of my NX workers comes back with some of the view geometries not showing on a drawing. When I run that same file through ugbatch.bat, I get the correct output.
The incorrect result comes from the standard "check in triggers publishing and everything runs through the CAD worker with PDF as additional file format" flow.
If I open the file on my system and export a PDF from NX directly, this exports fine.
If I manually run ugbatch.bat on the CAD worker with the same drawing, the result looks fine (i.e. all the geometry is showing).
Is this a CreoView Adapter recipe issue? Or NX settings issue? Leaning toward the former but I don't know what different settings ugbatch.bat (out of the box, in my case) may run to get a different result.
Solved! Go to Solution.
- Labels:
-
Windchill Visualization
- Tags:
- nx
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
I did solve this yes... unfortunately, it was much less glorious than anything up with the workers.
The issue was in NX and as I was working through PTC tech support it became apparent.
Basically, the user had at some point hid or isolated some part of the model so only one view ended up showing up because that was one that wasn't hidden. I played around with view layers and everything looked fine but when trying to export data to PTC, the export step in NX caught the error below.
Error: No solids found to section
In the end, in the NX drawing is did CTRL-W/Show All... and that ended up working because it had un-hid or un-isolated all the geometry.
The CAD worker was taking the data as it came... but for whatever reason, the UI version didn't show the same thing as what it was seeing so it was trickier to track down. In way, it caught a user inaccuracy so that's good?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
Did you end up solving your issue? Where I've seen differences between server side and client side publishing in Creo, it comes from two areas. One is that there is locally modified content in the workspace that the server side does not have. This can end up with different results. Look for blue plus signs in the workspace for modified components. I am not a NX expert but with Creo, we needed to make sure that the environments on client and server CAD worker were the same. that would be the second place to look. It might be property settings or environment files similar to Creo's config.pro files.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
I did solve this yes... unfortunately, it was much less glorious than anything up with the workers.
The issue was in NX and as I was working through PTC tech support it became apparent.
Basically, the user had at some point hid or isolated some part of the model so only one view ended up showing up because that was one that wasn't hidden. I played around with view layers and everything looked fine but when trying to export data to PTC, the export step in NX caught the error below.
Error: No solids found to section
In the end, in the NX drawing is did CTRL-W/Show All... and that ended up working because it had un-hid or un-isolated all the geometry.
The CAD worker was taking the data as it came... but for whatever reason, the UI version didn't show the same thing as what it was seeing so it was trickier to track down. In way, it caught a user inaccuracy so that's good?
