VOR Icon Warning Option,.. (based on your VOR setting, On or Off),... upon opening, a Warning stating the files used were not created with VOR On.. or vice versa, Off?
"Part was generated with VOR Off,.. do you want to Rebuild with VOR On?" if yes, "..are you sure?... downstream features/parts maybe effected",.. or No, ..."do you want to continue using VOR Off"?
NOTE: I am NOT on subscription,.. so, Please, (anyone),.. submit/request the above, thanks.
My other reply is being moderated because it has a link in it.
So I am creating it right now. I have a question:
Based on the nature of VOR, in reality, all you need is 1 full rebuild operation to take place with VOR on after the last updates have been made. Not every step in the design process (I would like to see it that way, but the VOR isn't a feature check.....it is a face and body check). So maybe this warning could be a warning that says that the model has never been fully rebuilt with VOR on?
What do you think?
Hello Dan,.. thank you!
Right, I think what you are saying is if VOR is turned On it does NOT automatically do a Ctrl-Q?,.. so, the user NEEDS to force a Ctrl-Q if they turn on VOR?
BTW, for those reading... if perhaps you are designing with VOR Off (because you hate rebuilds and the model has 3K features and you are fully aware of the VOR Off status) and you want to release the design to ensure the model is valid (released with no errors), you can turn VOR On and Ctrl-Q and save (Vault). This "should" ensure error checking and validation ("unless" other reference geometry has not also been updated with VOR On?). Nothing wrong with doing it that way.. but, it is a conscious effort and why I'm asking for a VOR Warning Option.
I think what is probably normal for most users,. .they do NOT do a Ctrl-Q ever.. so, regardless if VOR is On or Off,.. the past geometry may not be fully validated when adding new features/bodies to the list (with error checking),.. for instance, say you have a collaboration of multiple users and different computers are used,.. if VOR is Off (say ~100 features) and later turned On (say with another ~50 features),.. and again later with VOR On (say, another ~200 features)... then VOR Off again,.... and all the users never run a Ctrl-Q?.. It's possible this could happen,.. and error checks could be missed (say feature number 10) and allowed because no Ctrl-Q was ever forced? ..and, at some point, the "software" may need to request a Rebuild (not the user),.. the software would need to valid... this is where I've seen errors show up... and it's not fun!
Paul Salvador wrote:
Hello Dan,.. thank you!
Right, I think what you are saying is if VOR is turned On it does NOT automatically do a Ctrl-Q?,.. so, the user NEEDS to force a Ctrl-Q if they turn on VOR?
BTW, for those reading... if perhaps you are designing with VOR Off (because you hate rebuilds and the model has 3K features and you are fully aware of the VOR Off status) and you want to release the design to ensure the model is valid (released with no errors), you can turn VOR On and Ctrl-Q and save (Vault). This "should" ensure error checking and validation ("unless" other reference geometry has not also been updated with VOR On?). Nothing wrong with doing it that way.. but, it is a conscious effort and why I'm asking for a VOR Warning Option.
I think what is probably normal for most users,. .they do NOT do a Ctrl-Q ever.. so, regardless if VOR is On or Off,.. the past geometry may not be fully validated when adding new features/bodies to the list (with error checking),.. for instance, say you have a collaboration of multiple users and different computers are used,.. if VOR is Off (say ~100 features) and later turned On (say with another ~50 features),.. and again later with VOR On (say, another ~200 features)... then VOR Off again,.... and all the users never run a Ctrl-Q?.. It's possible this could happen,.. and error checks could be missed (say feature number 10) and allowed because no Ctrl-Q was ever forced? ..and, at some point, the "software" may need to request a Rebuild (not the user),.. the software would need to valid... this is where I've seen errors show up... and it's not fun!
Yes, that is essentially what I am saying. You could have a user that has VOR off. Designs a large part, then just before release, turns VOR on and runs a full rebuild. Check = done. Then turns VOR off. So, in reality, we wouldn't want a warning message saying that is was designed with VOR off.....we just want a warning that states whether or not a VOR check was ever completed (after the last geometry change to the file). Right?
Dan Pihlaja wrote:
Paul Salvador wrote:
Hello Dan,.. thank you!
Right, I think what you are saying is if VOR is turned On it does NOT automatically do a Ctrl-Q?,.. so, the user NEEDS to force a Ctrl-Q if they turn on VOR?
BTW, for those reading... if perhaps you are designing with VOR Off (because you hate rebuilds and the model has 3K features and you are fully aware of the VOR Off status) and you want to release the design to ensure the model is valid (released with no errors), you can turn VOR On and Ctrl-Q and save (Vault). This "should" ensure error checking and validation ("unless" other reference geometry has not also been updated with VOR On?). Nothing wrong with doing it that way.. but, it is a conscious effort and why I'm asking for a VOR Warning Option.
I think what is probably normal for most users,. .they do NOT do a Ctrl-Q ever.. so, regardless if VOR is On or Off,.. the past geometry may not be fully validated when adding new features/bodies to the list (with error checking),.. for instance, say you have a collaboration of multiple users and different computers are used,.. if VOR is Off (say ~100 features) and later turned On (say with another ~50 features),.. and again later with VOR On (say, another ~200 features)... then VOR Off again,.... and all the users never run a Ctrl-Q?.. It's possible this could happen,.. and error checks could be missed (say feature number 10) and allowed because no Ctrl-Q was ever forced? ..and, at some point, the "software" may need to request a Rebuild (not the user),.. the software would need to valid... this is where I've seen errors show up... and it's not fun!
Yes, that is essentially what I am saying. You could have a user that has VOR off. Designs a large part, then just before release, turns VOR on and runs a full rebuild. Check = done. Then turns VOR off. So, in reality, we wouldn't want a warning message saying that is was designed with VOR off.....we just want a warning that states whether or not a VOR check was ever completed (after the last geometry change to the file). Right?
Just as I was retiring from SOLIDWORKS, I was thinking a lot about VOR and the extra body checking and was thinking of better ways to implement it. Personally, I think this discussion is worth branching off on its own; Dan, do you want to do that since you started this sub-thread?
Also, SOLIDWORKS is not trying to hide anything about VOR; it is documented here:
2019 SOLIDWORKS Help - Checking Model Geometry
as well as in other places as found by searching the help for it:
2019 solidworks Search - english
Not as elaborate as the Fisher Unitech video linked in the discussion above (which is very good), but SOLIDWORKS is not deliberately hiding the information.
I would suggest that people that want to know more about VOR watch that video, but I'll also document a simple case here so you can see some representative numbers on the ramifications of using it.
I know that some people think that VOR should just always be on, but users would HATE the performance of SOLIDWORKS if it was always on. And in many cases, especially prismatic/machined types parts, it is almost never needed. I believe VOR does more than just the checks shown in the following example, but this is an easily shown example of one of the things it does. In the model below, I've made a 4x4x4 cube, then I shelled it with a value of 0.25. Then I added a 1.5 fillet to the face opposite to the shell face. With VOR on it fails, but with VOR off, it works, but creates intersecting faces as found by Tools, Check:
And here is approximately* the difference between what is happening when VOR is off vs. when it is on when creating the fillet feature:
* I say approximately, because I don't know the exact algorithms that Parasolid uses. It may only compare new faces against the other geometry but it may compare new AND modified faces against the other geometry. It may also only check new faces against existing faces, not against newly created adjacent faces. Either way, you can get the idea that there are MANY more faces to check with VOR on vs. off.
This is a very simple example and you can see that there are 3.5x the number of face comparisons made with VAR on vs. off. Take this same simple geometry where 4 new faces are created in the same kind of fillet configuration, but the rest of the solid model is more complex (for example, it has a pattern on it in another, unrelated area like the Fisher Unitech example) and has 200 other faces. With VOR off, it would still only be 16 face comparisons, but with VOR on, it would 3200 face comparisons. This will certainly be slower. And this performance degradation would be seen on every single feature, every single time it is rebuilt. So any time a parent feature is changed and rebuilt, all child features would take that performance hit. For people that like to use Ctrl-Q/Force Rebuild all the time instead of regular rebuild, the performance degradation is on every single feature, every single time you Force Rebuild.
And as said above, VOR is not needed on a lot of prismatic parts. A user familiar with solid modeling would not try to add a fillet like shown above since they know it is too large for the part thickness (unless they do it by mistake). Of course a novice user may think that putting the fillet on the outside of the part would automatically fillet the inside, not understanding feature history. So VOR may be more important for novice users. VOR is definitely more important for more complex parts and especially surface type models/"swoopy shapes".
So, these are my current thoughts on a possible solution after thinking about it for a while:
So there is my current brain dump on thoughts of how it could be improved; certainly not the bible on how it should be implemented, but a my 2 cents for discussion. The general idea is to get the benefits of the body checking without taking the performance hit of having VOR turned on all the time and only taking that performance hit at logical intervals and make it smarter so it only rebuilds those features that have not had a full VOR check in the current SP.
Thanks,
Jim
4/26/19 - Edited with more clarity/ideas on how it could be implemented.
Jim Wilkinson wrote:
So there is my current brain dump on thoughts of how it could be improved; certainly not the bible on how it should be implemented, but a my 2 cents for discussion.
Thanks,
Jim
Very cool Jim. Thank you for sharing. Your third bullet point is essentially what I made the enhancement request to be.
As far as branching is concerned, I think that only the original creator of the thread can branch. So Rob Edwards would have to do the branching.
As Jim mentioned, lots of users will never create a file that has a VOR issue unless they're trying. I have designed machines for years and never had an issue that I can remember, but these are industrial manufacturing/assembly machines so the parts are mostly prismatic with no swoopy surfaces, and even not so many external fillets. Those rounds are expensive to machine...
Josh Brady wrote:
As Jim mentioned, lots of users will never create a file that has a VOR issue unless they're trying. I have designed machines for years and never had an issue that I can remember, but these are industrial manufacturing/assembly machines so the parts are mostly prismatic with no swoopy surfaces, and even not so many external fillets.
Issues that don't get detected with VOR off can happen on simpler parts as well:
Jim Sculley wrote:
Josh Brady wrote:
As Jim mentioned, lots of users will never create a file that has a VOR issue unless they're trying. I have designed machines for years and never had an issue that I can remember, but these are industrial manufacturing/assembly machines so the parts are mostly prismatic with no swoopy surfaces, and even not so many external fillets.
Issues that don't get detected with VOR off can happen on simpler parts as well:
Agreed. Just like the simple case that I showed in my example. But if the features are being used properly with good solid modeling practices, you pretty much never need VOR. In that case you reference, you yourself discovered that user was improperly using the Normal Cut option. It is not dissimilar to trying to put a fillet that is too large for the thin walled part. If you look at how Normal Cut works, I'm not surprised that the feature had trouble processing that sketch and inputs properly to make a valid bod and that it was only the extra body checks that caught it.
If you make simple parts with a small number of faces, then there isn't much harm in have VOR on all the time. But if you make simple parts with lots of faces, your performance will be worse.
The whole point of my reply is to make the body checking tools integrated in such a way that all users can get the benefit of the body checks without big performance hits across the board. Which leads me to another idea which I'll update in my original post; that is having an option to always use the extra body checks if the number of model faces is small.
Thanks,
Jim
Jim,
Since most of the parts I design are indeed machined/prismatic parts and not the organic swoopy stuff I had VOR turned off. However, I imported a dumb solid from a customer and it had some little holes in it interior to the part and some open/missing surfaces. I tried adding some solid extrudes to fill them, but was never able to get it to work. Finally I contacted my VAR and he did some stuff with surfaces to resolve it. He also turned on VOR.
Can you comment on the value advice of using/not using VOR with dumb solids, please?
My customer is using Creo 3.0 and I had been using 3D Interconnect to open his collection of parts directly, but some of the parts failed horribly. Now I am asking him to give me both the native Creo parts as well as a STEP file of the assembly. I am having much better luck with the STEP version. Can VOR affect the results I am seeing?
Dennis Dohogne wrote:
Jim,
Since most of the parts I design are indeed machined/prismatic parts and not the organic swoopy stuff I had VOR turned off. However, I imported a dumb solid from a customer and it had some little holes in it interior to the part and some open/missing surfaces. I tried adding some solid extrudes to fill them, but was never able to get it to work. Finally I contacted my VAR and he did some stuff with surfaces to resolve it. He also turned on VOR.
Can you comment on the value advice of using/not using VOR with dumb solids, please?
My customer is using Creo 3.0 and I had been using 3D Interconnect to open his collection of parts directly, but some of the parts failed horribly. Now I am asking him to give me both the native Creo parts as well as a STEP file of the assembly. I am having much better luck with the STEP version. Can VOR affect the results I am seeing?
I don't know a lot about VOR and importing files with 3DInterconnect turned off. But my guess is that VOR isn't used for import using that method; I would think all the body checking comes with the import diagnostics tools (assuming those are run). With 3DInterconnect on , I have even less knowledge of how it works relative to body checking, etc. (because it was so new towards the end of my tenure). I don't even know if the import diagnostics tools can be used with models that come in through 3DInterconnect; I have a feeling they can't but I'm not sure. If Import Diagnostics can't be used, maybe VOR does make a difference on those models. Maybe Utpal Kumar can comment on that.
Once the model is imported via any method and made "clean" if necessary (i.e. no body check errors, etc.), when adding new features, I would apply the same general rules to using VOR. That is, if it is a simple, prismatic part, VOR is likely not needed. But if it is a more complex part and you are working with surfaces (especially organic/"swoopy" shapes) then I would have VOR on.
Thanks,
Jim
...maybe a simple bedtime story...about VOR...
There once was a 30 year old tool shop called "VOR ON".. and they only made PRISMATIC PARTS and have always had "VOR ON". They know the difference between VOR ON and OFF because they are well aware of the differences and concerns.
One day, a new customer, who has been in business for >25yrs, named "VOR OFF" comes in and wants all their PRISMATIC SLDPRT's and SLDASM's on their project made and they have NEVER, EVER, NOT A ONCE, NEVER- -REALLY, EVER had a problem with "VOR OFF".. and they swear by the short hairs of their chinny chin chin because they KNOW what they are doing.
"VOR ON" signs a contract and agrees to a time and amount for making the "VOR OFF" PRISMATIC PARTS.
The following week "VOR ON" opens the "VOR OFF" files and notices small topology errors, they run "Check Entity" and then force a
CTRL-Q (all standard practices at "VOR ON"),.. and lo and behold model trees go RED with errors.
Next, the "VOR ON" company exports the files as Parasolid... but, the topology errors still exist?
"VOR ON" calls to discuss the findings wth the "VOR OFF" company and says, "Unfortunately we have found errors within the models and they need to repair them before moving forward and they also (carefully) suggest "VOR OFF" turn their VOR On.
The "VOR OFF" customer huffs and puffs and says, "there is NOTHING WRONG with our "VOR OFF" files.. your VOR ON setting did something wrong or broke our models and you do NOT know how to use SolidWorks"!
The moral of the story,.. VOR should have a WARNING OPTION so ALL USERS are AWARE if they are working with a "VOR ON" or "VOR OFF" files.
The End.
Here you go:
I once encountered a serious problem with a surfacing-heavy high-feature master part that caused me a LOT of headache. Essentially, my part involved several solid bodies that were subsequently saved out as their own parts (Save Bodies) for further detailing. In the master part, I needed to roll up in the feature tree and create/add/move a button or something---using Split Face---from the main surface contour and doing so (as best I can tell) reassigned face IDs to my various surfaces.
No big deal, but (as best I can tell) the same face ID was assigned to TWO faces after the Split Face command. What this meant was every other forced full rebuild (CTRL-Q) would alternate which downstream features were assigned to which of the split faces after the Split Face command. One would fill my downstream feature tree with a sea of blood and the other would rebuild as normal. Took quite a while for me to figure out what was happening and how to correct it without crashing the entire project (including bodies saved as parts, since those were similarly reassigned as a result of the face ID debacle).
All this appears to me to have been caused by a glitch in VOR, which I believe was switched on at the time and thus quite confounding. How can I split a face and then have multiple assignments of the same face ID to different surfaces/bodies? This was on the edge of catastrophe.
Finally solved the problem---after following hunch after hunch---by rolling up the tree and splitting the face once again for no other reason but to force a face/body reassignment above the double face ID problem. This meant I had to comb through the remaining 300 or so features and reassign which bodies each feature applied to (to stem the blood sea) and therefore which bodies were saved out as which part name. Was a real train wreck, but it DID allow eradication of the duplicated face ID. The whole ordeal was akin to facing Kasparov in chess with my life on the line. Not fun.
I am not sure why or where the comments of VOR on = CTRL+Q for every rebuild and people are reluctant for this reason. In my experience I don't see this behavior, what I see is the part rebuild the feature/sketch that I'm currently within and the items below it in the feature manager. If I CTRL+Q I definitely see a difference upon manually selecting CTRL+Q in rebuild time vs. say going back to 1/4 or 1/3 or 1/2 way down the feature manager tree and doing a normal rebuild from editing an item.
I also notice varying and unexplained behavior from the software. Files can go corrupt, I've seen features go corrupt where a fillet is added ans is fine, then a face or faces within this filet is missing and you can see inside of the part through these missing faces, you can't touch or click on these faces, the part remains a solid still and isn't a surface body after the face goes missing. Quite the odd behavior and it effects items downstream. Doing things like copy the file may work, but typically not, CTRL+Q doesn't work, most often deleting the feature and making a new identical feature again in the same place in history works. So to box in comments that CNC simple shapes are 100% OK with VOR off, I'm not buying it, even if there is some sort of track record, the software will bug out or your file can have some issue.
Paul's story of the 2 businesses sounds good to me, I'm on par with that message and also for my own additional reasons. I find it's easier, more efficient in the long run to fix things before or as they happen than to allow the problems to come later and have a larger workload under less than ideal conditions or time frame to fix later on.
For performance issues, without sidetracking too much, having a functional freeze bar that works would be useful. I have long rebuild time and rebuild complexity issues, greatly, when patterning on things that are like a tire or football type shape. Very often, it's almost a case by case matter, the patterns don't work the same and time consuming creative varying solutions are required to get the item to resolve, and then to try to do it more quickly for a 2nd band-aid type approach to patterns not working well in this type. In this condition I grasp for the freeze bar as patterns can't always be at the bottom, but they don't seem to contribute much if any towards the work and rebuild time below the freeze bar for simple functions.
Hello Paul, I am challenging with the same problem. I want to make a knit-surface but also want to rebuild with "VOR". But i am getting error.
Do you have any solution to make Knit-surface with VOR ?
Latest Videos - What is CTRL Q and VOR in SOLIDWORKS?