Community
Navisworks Forum
Welcome to Autodesk’s Navisworks Forums. Share your knowledge, ask questions, and explore popular Navisworks topics.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Item missing in clash detective when weekly files are updated

12 REPLIES 12
Reply
Message 1 of 13
ricemal
1631 Views, 12 Replies

Item missing in clash detective when weekly files are updated

I am having an issue when updating weekly subcontractor files. I have previously grouped and assigned all the clashes in the clash detective window. Whenever I get new files from the subcontractors and refresh the files, all my grouped files show up as resolved and I get a string of new ungrouped clashes that are actually the old clashes. I have tried refreshing within Navisworks. I have also tried copy/pasting the new files into my working folder with Navisworks closed, and I get the same result everytime. Has anyone else had this issue?

Tags (1)
12 REPLIES 12
Message 2 of 13
IanBadcoe
in reply to: ricemal

Hi,

 

This happens when something has changed between the models which prevents NW from correctly identifying items in the new files as the same items that they were in the old files.  The Clash module just has to respect the application core's opinion on what is the same or a different item, so clash ends up thinking that all the old clashing items have disappeared and a load of newly clashing items have taken their place.

 

We have done some work to improve this for the next version, but there are still cases that we cannot handle.

 

In particular, files brought in via certain import routes have their item identities so scrambled that we cannot always interpret them.  One particular problem that we have seen is that files passed through one or more intermediate formats can lose itentity information.  Sometimes this is an NW problem, and sometimes it is more that the information has been scrambled along the way.

 

You did not say how you got your files, or what format they are?  If you can let me know that I may be able to tell you more.  If this is turns out not to be something we have already examined, would it be possible for you to provide us with a couple of versions of an example file?

 

Thanks,

 

Ian

Message 3 of 13
ricemal
in reply to: IanBadcoe

My files are .dwg format from the subcontractor. I usually replace the .dwg files in my working folder, and leave the previous versions of the corresponding .nwc files in the working folder and just let Navisworks refresh them. Should I be deleting the .nwc files each week as well?

Message 4 of 13
IanBadcoe
in reply to: ricemal

Hi,

 

No, you should not need to delete the NWC files -- we tend to advise people who are having other problems to try that, but it is more that it eliminates a possible problem, rather than likely to be the cause.  Generally speaking, NWC files always get replaced automatically when the source files change.

 

Data coming straight from DWG should not be a difficult case, although object enablers can complicate things.

 

I see that this was automatically escalated into a Salesforce case.  That isn't really my area but I will ask around about that.

 

If you did not already, could you supply us with examples of two different versions of the same file?  So that we can investigate the exact same process that you are having difficulty with?  You may be able to submit those into the Salesforce incident (as I said, that is really not my area) or you could supply the files directly to me...

 

Thanks,

 

Ian

Message 5 of 13
AchimKersten4634
in reply to: ricemal

We have the same problem with different files of Microstation 7 and Microstation 8. Because of using this frequently running clashtest, we spend too much time for reviewing the same clashes again and again. On the other side clash numbers are used for adressing the clash to the contractor and he uses this number for invoicing his work for that. So in worst case we pay a number of times for the same!

Is there any suggestion of solving this Problem now?

Message 6 of 13

Hi Achim,

 

A problem with microstation files is not actually likely be the same problem that was previously seen with DWG files.

 

If you can supply two versions of the same file which demonstrates the problem then we can investigate what the cause is and look into fixing it.

 

You can send the files via your support contact, or if they are small you may be able to attach them to a PM to me on this forum.

 

Regards,

 

Ian

Message 7 of 13
stahci
in reply to: ricemal

I am having this same problem with a subcontractor that is using AutoSprin I continue to get new clashes that are just continued over from the previous clash report. I have been unable to get assistance on a solution.

Message 8 of 13
IanBadcoe
in reply to: stahci

I think AutoSprink is DWG-based, isn't it?  So that is unlikely to be the same problem that is happening in the DGN files.  It may be the same problem that the original poster had.

 

Again, if you can get two versions of a (preferably small) file to us, then we can look into why this is happening.

 

Regards,

 

Ian

Message 9 of 13
stahci
in reply to: IanBadcoe

Shoot me a message with what you are looking for and where to send them. I can provide my "Central" Navisworks file with all the submodels, exported NWD, individual weekly models from AutoSprink. What ever you need I can send.

Message 10 of 13
IanBadcoe
in reply to: stahci

> Shoot me a message with what you are looking for and where to send them. I can provide my "Central" Navisworks

> file with all the submodels, exported NWD, individual weekly models from AutoSprink. What ever you need I can send.

 

Hi Scott,

 

I have your files now and I can easily reproduce your issue.

 

Unfortunately this is caused by how the DWG files got exported from Autosprink.  The problem is that the file is produced as an export rather than a save (so it is creation of a new file, not a save of an old one).  This means that the newly exported file gets a new "fingerprint" and when you export twice (intending the two files to be different versions of the same thing) the two exported files get different identities (the DWG "fingerprint").  Thus to Navisworks they appear to be a totally different files, and none of the objects in one file are considered to be the same as in the other.

 

This doesn't help you solve your problem, but I thought you might want to know the background...

 

There is, again unfortunately, no work around for this problem at this time.  The problem is that the two files contain genuine information that says they are unrelated and Navisworks can't know that wasn't the intent when you did the export from Autosprink.

 

We have seen the same issue with other products exporting DWGs.  It is ultimately because there is an ambiguity in what is intended when a user "exports" -- they can mean to create another copy of the data in the source application (a new version of the same things), or they can mean to create something genuinely new (say for a different project; now they definitely need to break to the connection with the old data.)

 

We are researching this.  The absolute best fix would be if other products, like Autosprink, were to provide options on the export that enabled the user to preserve the file identity (fingerprint) or not, according to their need.  I do not know whether Autosprink have any such feature?  If not then you could ask their support about providing such a thing in the future.

 

However we are also researching a fix for this at the Navisworks end.  This isn't an ideal fix, because we will have to override what files say about their own identity (which could cause a lot of damage if the identities really were different).  I cannot promise delivery of this on any particular timescale, but it is logged in our system and in competition with other things we need to look at.  If you want it prioritised then please raise it with your support contact and have them log a business case against the issue.

 

(If you have them quote "NW-43285", they may not know what that means, but it will help us rapidly find the correct issue in the database.)

 

Sorry I cannot offer a faster fix for this, but it is a difficult problem.

 

We do not recommend DWG export as the preferred workflow into Navisworks (for this and other reasons) but for Autosprink I am not sure what alternatives exist...  I think you mentioned IFC?

 

Regards and I hope this is of some use, even if not immediately helpful,

 

Ian

Message 11 of 13
dgorsman
in reply to: IanBadcoe

Excellent description of the problems involved with repeatability, Ian.

 

Automatically creating isometric drawings has a similar problem - e.g. the drawings will have some assigned part numbers for that drawing, which should make their way back into the original piping design software so additiona runs will assign the same part numbers.  You may want to have a look into how ISOGEN creates and manages what they call "repeatability files" when generating isometric drawings from an input.  When it creates the drawings, it can create an associated data file which describes what was done with the original information.  That data file can optionally be consumed by the originating program to help with this type of consistency.  Of course, that requires a fair amount of cooperation between all developer parties involved, so actual use of repeatability files is fairly limited.

----------------------------------
If you are going to fly by the seat of your pants, expect friction burns.
"I don't know" is the beginning of knowledge, not the end.


Message 12 of 13
IanBadcoe
in reply to: dgorsman

That does sound very much like an exactly similar thing.  Thanks for bringing it up.

 

This whole area is one of active development, in particular because it is a problem (and opportuinity) for any CAD system in the cloud.

 

e.g. a fundamental requirement when data is copied from one place to another is knowing whether the intention was:

 

1) a copy of the original data with its own identity, or

 

2) a reference, version, or alternative representation of the same entity, which must share the same identity

 

This is tricky in both the core software and the user interface.  e.g. the software can easily have some sort of flag "keep identity" to tell it what to do, but there are lots and lots of existing places where data is copied around, reworking all of them to know how to set the flag is much more challenging.

 

For the user interface the proglem is even more fundamental.  Take even something as simple as copying and pasting.  This can intend either creating a new one, or another reference to the old one.  In some contexts it is very easy.  If you are editing some sort of catalog whch doesn't contain instancing, then it has to be a new entity that is required.  Similarly if you are creating some sort of "view" of another model then it has to be a reference to the "real" item in the "original" data (although your ISOGEN example seems to indicate a case that doesn't work that way...)  Other cases get far more ambiguous.  The simplest example being if somebody merely copies a file and works in it for a short while.  Did they mean:

 

1) new project based on the old one

2) temporary copy for experimenting in

3) new version of the same model

4) etc etc

 

These can all mean different things.

 

Computer science has systems that handle this sort of thing, version control systems for example.  However they need the user to say what they want -- in effect to say: "new version of this", "new thing based on this" or "brand new unrelated thing, please."  CAD users make these kinds of decisions all the time, but they are used to carrying the data in their heads (or implicit in their work-process).  They are not accustomed to being so formal that they have to tell the software what they wanted at every stage.  Document control systems do it somewhat, but at the file-by-file not the entity-by-entity level.

 

It is definitely an area where we all need to evolve: software, service providers and users.  Scott's problem with export from Autosprink is only the tip of the iceberg -- problems and opportunities aplenty going forward in this area...

 

Ian

Message 13 of 13
vkorn
in reply to: ricemal

I am working on a trade model and the GC has updated the Navisworks coordination model but, for some of the clashes there is only one item showing up and the other item is greyed out in the items tab and can't be located in the visual field. Does anyone know why this is?

 

missing clash item.jpg

 

 

Thanks

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Rail Community


Autodesk Design & Make Report