"Switch to Local" causes corruption of file OUTSIDE of Windows file management

Jim Canale

I have a half dozen assembly files I've created over the past several years. They use XREF's. In each case, all the XREFS were in a subfolder of the network folder where the assembly file resided. Recently I had to make a minor edit to one of these assemblies. When I opened the file, I discovered that a few of the dozen or more XREF's were flagged as "not found", or their paths were no longer correct. I checked the original components. All were fine. I tried other assembly files stored in other network folders with their own XREF subfolders. Those too had incorrect paths.

I returned to the original assembly, opened the assembly browser, and corrected the paths. So far so good. I decided not to risk corruption of the component paths again. I applied the "Switch to Local" command to eliminate the use of XREF's. The command appeared to complete without a problem. There wer no error messages. I proceded to make the edit, and BricsCAD promptly froze. I had trouble getting to the Task Manager, but when I did, I found that BricsCAD was gobbling up enormous amounts of memory, and that memory usage was steadily rising. It approached 8 GB, and that crashed Windows. I had to do a hard restart to recover.

Now you'd think that since I never had the opportunity to SAVE, following the "Switch to Local", and edit (very minor), that the file would open as an XREF assembly. Boy was I surprised. On opening the assembly, it froze and crashed AGAIN! So apparently the "Switch to Local" alters the file structure outside of Windows normal file management system. I'm no programmer, but I think this is VERY bad.

I attempted to "Switch to Local" on several of my other assemblies. They too, froze and crashed. I had to get the IT manager to restore the assemblies from backups. . I tried the file repair option in BricsCAD. It didn't work. My machine kept freezing and crashing. I have V17.2.08 (platinum), and V18.2.14 (platinum) installed. Same result with both versions - a corrupted assembly file that eats massive amounts of memory.

I filed an SR. They told me the best way to transmit the restored assembly and XREF's subfolder was to perform an ETransmit. I did so. They claimed they performed the "Switch to Local". I did. They claimed the switch worked fine. I insisted on seeing the localized file. It crashes my machine......

Attached is the etransmit file I sent to support. It is an XREF assembly that opens just fine on my machine. If any of you are brave enough to open it and attempt the "Switch to Local" , I'd appreciate your findings... Be sure and make a couple edits after the switch, close the file and then re-open it. If you're really brave I have attached the "localized" file, the support group gave me. I can't open it without a crash.

Jim Canale

No input? I hope I didn't burn bridges by being away from this forum so long... My mother was very ill and eventually died. Couldn't respond to posts.

I submitted an SR for the problem and did not like the answers. I was scolded for not remembering the contents of an older SR. (There is no obvious way to search through old SR's for a particular discussion.) I was also scolded for using the feature found in the Drawing Explorer to change the component paths. But that feature has been there through several versions. If they didn't want people to use it, why hasn't it been removed? I was told I shouldn't back up the project by copying the entire folder (assembly file and subfolder of components) to another drive location. Why not? This is an established backup method that works with every other application I've tried. They didn't tell me why the component paths keep changing, and why the "Switch to Local" command corrupts the file and crashes the program. (It does so without ever issuing a SAVE command.).

Fortunately our IT manager was able to restore my assemblies. But I will never again trust BricsCAD's XREF's and the "Switch to Local" command.

I'm really ticked

RSW

@Jim Canale said:
I was also scolded for using the feature found in the Drawing Explorer to change the component paths. But that feature has been there through several versions. If they didn't want people to use it, why hasn't it been removed?

I'll check this out later to see if it does affect things on my end.

I was told I shouldn't back up the project by copying the entire folder (assembly file and subfolder of components) to another drive location. Why not? This is an established backup method that works with every other application I've tried.

I do this all the time without issues so far, even "worse" it is how I sync (through software using a CRC check) across multiple computers and the syncing server.

They didn't tell me why the component paths keep changing, and why the "Switch to Local" command corrupts the file and crashes the program. (It does so without ever issuing a SAVE command.).

The component paths shouldn't be changing unless there is something in the folder structure or how you set up your assembly that causes this to happen. So far I have not experienced anny issues with switching the components to local, not even after deleting the folder with components etc.

However... a few questions:

• Why were all your layers set to locked?
• Why is your BOM in the model space instead and then put on a sheet layer through a viewport instead of putting it directly on a sheet layer?
• Why are you using 2D blocks in your model space for section views instead of generating them through viewbase etc?

The reason I am asking is that I normally keep the model space for the assembly only and everything else is on the sheet layers unless there is no other way to avoid putting additional stuff in model space other than the assembly. The cleaner model space is the less potential issues (in general).

Fortunately our IT manager was able to restore my assemblies. But I will never again trust BricsCAD's XREF's and the "Switch to Local" command.

Your version of the all local does become unresponsive on my system as well and memory usage keeps slowly increasing.

I can't say I have experienced issues with XREF's and switch to local so far in BricsCAD. The only issues with XREF's I ever experience are the common ones that apply to the use of XREFs/linked files as can happen in any program using this (e.g. somone forgot to include the XREF or renamed it etc.)

That being said... I don't edit files live files stored on a network storage but always locally as editing files stored on a network can cause issues unless you have a rock solid system, I've seen too many complaints on that to even try this with things like CAD without a proper and solid backend designed for this (and BricsCAD is not really designed for this at the moment imho unlike some other CAD programs and even those can have issues). A plain text file would be ok, but anything more critical is always edited locally if possible.

Without futher information I can only assume it is something on your network that is causing issues wiith the file paths. It is almost as if the file pointers or whatever it is called are being changed from time to time. Even a simple change of a network harddrive to replace an older one could cause issues as some software uses drive ID's etc. to create unique ID's across multiple drives for copies of the same file.

Jim Canale

RSW,
Thanks for your lengthy reply. May I get back to you on Tuesday when I'm back to work? You ask some interesting questions, and I need to try some of your suggestions. I no longer have a system at home.

I will tell you that I typicwlly lock layers I'm not editing, and when done with the file. Makes it seem better protected. Also, use of paperspace viewports to view 2D drawings is the way it was done before 3D. The level of detail and control I have is better. Will explain later.

RSW

@Jim Canale Sure no problem, I should still be around next week

I get the reasoning for locking, I do this from time to time as well (or freeze layers temporarily) but normally not for the final version unless it is a layer that should usually never be edited (e.g. template borders).

The paperspace viewport for 2D drawings is normal (I started on AutoCAD 11 (not 2011) with a one or two day exposure to AutoCAD 10), but what I was referring to is why create a 2D drawing for views in your model if you could achieve the same with the viewbase command and have it put directly on a sheet layer and which normally also automatically updates when changes are made. Not sure if you are aware but you can e.g. create a view of the inner part by selecting the entire model except the outer shell.

There appears to be an issue with your component naming, when putting the components into a subfolder and use the XREF section in the drawing explorer to relink the components to the files it refuses to update the links to the ones having a comma in the filename.

Using the mechanical browser and firsts select all instances of the component and then use replace and select the component in the subfolder does work without issues.

Did you try using the replace feature to achieve the same thing instead of using the XREF section of the drawing explorer? This may prevent the issue you are experiencing. You can replace all instances of the same component in one go this way (as described above) and this may be more reliable than using the drawing explorer route.

Another thing I noticed, which may have to do with the naming of your components is that some of them start with instance number of 2 (:2) and having the reference name in the XREF section of the drawing explorer ending with _1 but the filename of the component does not . None of the other references that do not have the _1 ending do have this issue and start with :1 for the first instance as one would expect to happen. (Unless a component instance has been deleted and then a new instance got inserted in the same session, then it will start with :2 for the instance number).

You may want to check if the components having issues are having a comma in the filename and/or have their reference name ending with _1 and the filename of the component does not. If yes then try fixing this file and reference naming to see it if resolves the issue or not.

RSW

Another question, if you update the links through the drawing explorer XREF section, do the components show up as red or black in the mechanical browser? I just did the XREF update route again and notice that the components were still listed as red after reopening the file, though the XREF section does show them as found.

Using the replace method as mentioned in my reply above does not have this issue.
Even though components that are inserted are XREFS from a principal point of view I think they are probably not regular XREFS and should therefore not be treated as traditional XREFS as you seem to be doing. I could be wrong but the only ones knowing for sure are the people at Bricsys.

Jim Canale

RSW,
Sorry for the delay in getting back to you. As soon as I got to work this AM, I was hit with a bunch of stuff.

Anyway, I stopped trying to use the Drawing Explorer to reset the component paths as soon as I realized they were not changing the paths. (Highlighted in red) I switched to using the REPLACE command. found in the Mechanical Browser. So the paths are all correct on my drawings. The problem is, as soon as I "Switch to Local", it corrupts the file and creates the massive memory leak. What is really bad about it, is it damages the file even though I never issue a SAVE command. So apparently, "Switch to Local" does something to the file outside the normal Windows file system. I'd say that is a very bad design, but I am not a software engineer.

As for my usage of model space for my 2D views..... Back when BricsCAD introduced the capability to create 2D views in paper space I was thrilled. I didn't have good luck however. The auto-update feature wasn't reliable. Moving the 3D model would break the linkage. I do a lot of ordinate dimensioning on my bed of nails fixtures and sheet metal housings. Standard dimensioning is too cluttered for high density drill patterns. I had trouble picking off the correct origins for the ordinate dimensioning. I complained to the support group repeatedly about it, but they blew me off. Pretty obvious they didn't understand the problem. I can't have errors on the prints I send out! I also have some issues with detail views and cross sections. I get more flexibility with detail views in model space. Last time I checked, the paper space cross section tool did not allow me to make a cross section on a diagonal. It also didn't allow me to section a jog or spur of a chassis. It insists on showing the cross section across the entire viewport. Yes, I'm giving up auto updating. But as I said, it has never been reliable for me. I've asked if they would make it possible to direct the views directly to model space, and make them auto-updateable, but they weren't interested. I could go into greater detail about my problem with paper space dimensioning,, but I think I'd be getting too far off topic. I started this thread to ask for help removing XREF's from my drawings.

also noticed the dimensioning wasn't reliable, because it was harder to select the

Jason Bourhill

Hi Jim,

A distinction needs to be made between "Components" and "Xrefs". The files you provided are setup as components, and as such need to be treated a little differently to what you might do with a simple xref. Components are hybrid of Xrefs/Blocks with additional properties and features, hence it's best to work with them via the Mechanical Browser.

These are the steps I took to work with your files:

1. Run BMUNMECH. This removes the mechanical structure from the drawing, essentially reverting components back to simple xrefs.

2. Run AUDIT/RECOVER on the drawing. This found and fixed a number of errors. In particular it took issue with some of the names used for the Xrefs. Essentially it didn't like the xrefs that used commas in the name. Generally I would try to avoid using full stops, commas and the like in file names, particularly if you're accessing file from network drives (which may be using a different OS & file format to the client).

This resulted in a working drawing with the assembly formed from simple xrefs, see "62-A0001 AUO 21.5 Hi-Brite-Xrefs" attached.

From here I could then convert the drawing back to mechanical components using BMMECH. Because I've got access to V19, I could also generate an exploded view for use with the BOM and generate an assembled view, see "62-A0001 AUO 21.5 Hi-Brite-Components" attached as well as a PDF prints.

I think the main problem you're having is the paucity of documentation for what are compelling features. Without guidance it is very easy to fall head first into bear traps or get eaten by alligators. There are also significant changes (fixes/improvements) between versions.

Regards,
Jason Bourhill
CAD Concepts

RSW

Thanks Jason for confirming the file naming using commas was causing issues, as I suspected this might be one of the causes of Jim's troubles as well as handling components as plain xrefs.

It's good to read how you fixed this as I wouldn't have thought myself of doing a BMUNMECH first before auditing/recovering an assembly as I would have assumed the audit/recovery would not need this.

So it does beg the question, does an audit/recover of an assembly work well without doing a BMUNMECH or should that preferably always be done for best results?

RSW

Jim, I understand why you are doing it the way you are doing things given the issues you are having, though do think some things are workflow related and other come from lack of fully understanding features/tools because of the documentation not being extensive enough as Jason also mentioned. I have issues with the latter as well and sometimes have to figure things out through trial and error because things are not working as expected (having used Solidworks may actually be a disadvantage in some ways as BricsCAD does some things a bit differently, sometimes a bit better and sometimes a bit worse).

Hopefully Jason's reply is giving you enough info to solve at least your assembly file corruption issues.

Jim Canale

@Jason Bourhill said:
Hi Jim,

............ I think the main problem you're having is the paucity of documentation for what are compelling features. Without guidance it is very easy to fall head first into bear traps or get eaten by alligators. There are also significant changes (fixes/improvements) between versions.............

Jason Bourhill
CAD Concepts

THANK YOU Jason.

What do you mean by the expression "full stop"? I extracted to my desktop the assembly you converted to XREF's. The XREF's still had commas in the file names. Was that intentional? I ran _Audit on the assembly, but it didn't find any errors. I switched to the desktop and renamed the XREF's, omitting the commas. I returned to the assembly, and corrected the paths to the XREF's from the drawing explorer. I initialized the mechanical structure with BMMECH and they all converted back to components. I then ran "Switch to Local", and thankfully there was no freeze, crash, or memory leak. Not sure what solved the problem. Was it the omission of the commas in the component file names? Or the _Audit you ran earlier?

I'm disappointed I couldn't get a better response from the support group. They never offered me any explanation why the paths to my components keep changing. They never told me there was any problem with my component file names.. And frankly the method they suggested to fix my assembly file did wor - at least on my Windows 7 system.

You're absolutely right.. We need better documentation. I haven't gotten our IT manager to install V19 yet, because my machine ran V18 so poorly. (underpowered I think.) The exploded views would be very handy.

At some point, when I have more time, I will upload some files and try to explain my objections to placing my 2D views in paper space. For the time being, I will just say that it is not amenable to many of the parts and assemblies I work with, and I'm too liimited in making detail views and cross sections.

Jim Canale

@RSW said:
Thanks Jason for confirming the file naming using commas was causing issues, as I suspected this might be one of the causes of Jim's troubles as well as handling components as plain xrefs.

It's good to read how you fixed this as I wouldn't have thought myself of doing a BMUNMECH first before auditing/recovering an assembly as I would have assumed the audit/recovery would not need this.

So it does beg the question, does an audit/recover of an assembly work well without doing a BMUNMECH or should that preferably always be done for best results?

RSW,
Thank you for your input. Not sure if the commas were the issue, or whether it was an issue with network storage. If the latter, it's a real problem, as I am required to work off the network drives to protect my data. As much as I like the idea of using components, and having automatically generated B.O.M.'s, and exploded views, I will stop creating these types of assemblies, until I know for certain what causes the path corruption. I will get back to that later. For the time being I have to move on to other projects.

Jim Canale

Jason,
Just for reference, I also downloaded and extracted the other archive you provided. I could not open the assembly file. It immediately crashes my machine.
Jim C.

Jason Bourhill

@Jim Canale said:

What do you mean by the expression "full stop"? I extracted to my desktop the assembly you converted to XREF's. The XREF's still had commas in the file names. Was that intentional?

Sorry, didn't explain that well. It is the block definition table that can't cope with these special characters. When you attach an Xref it uses the filename as the block name by default. With your drawings I left the filenames alone, but renamed the xrefs definitions within BricsCAD to something that it can cope with. To avoid having do this all the time, it is easier to rename your xrefs to something that BricsCAD can cope with.

I did the minimal changes necessary to get the drawing to work for me. I didn't rename the xref files as you may have been using them elsewhere. Better that yopu make the decision to do this yourself.

There is a LISP function called SNVALID that you can use to check whether a symbol name is valid or not. The help lists the characters that are reserved.

e.g. Xref name with a comma isn't valid
: (snvalid "22-B0016 Insulator, Valox")
nil

Remove the comma, and it's ok
: (snvalid "22-B0016 Insulator Valox")
T

I mentioned full stop, as you've used it in the name of the assembly. Potentially you may include this assembly as a component in a larger one. This is where the full stop may present some issues. I say may, because use of a full stop isn't invalid, however I recommend avoiding as I have had issues in the past.

An advantage to components is that you can name them independently (via the Mechanical Browser) to the filename. This allows you to use simple filenames for your components while having a more detailed description, with punctuation appear on your BOM.

Regards,
Jason Bourhill
CAD Concepts

Jason Bourhill

@RSW said:
So it does beg the question, does an audit/recover of an assembly work well without doing a BMUNMECH or should that preferably always be done for best results?

AUDIT/RECOVER should work without the need for BMUNMECH. I simply used BMUNMECH to put the drawing back to a point where I knew where I was. From there I could move forward again.

Regards,
Jason Bourhill
CAD Concepts

Jason Bourhill

@Jim Canale said:
Jason,
Just for reference, I also downloaded and extracted the other archive you provided. I could not open the assembly file. It immediately crashes my machine.
Jim C.

I could open in V18.2.20 without issue. However, I have had similar experiences with other files.

Regards,
Jason Bourhill
CAD Concepts

Jim Canale

@Jason Bourhill said:

@Jim Canale said:

....

Sorry, didn't explain that well. It is the block definition table that can't cope with these special characters. .........
There is a LISP function called SNVALID that you can use to check whether a symbol name is valid or not. ............
An advantage to components is that you can name them independently (via the Mechanical Browser) to the filename. This allows you to use simple filenames for your components while having a more detailed description, with punctuation appear on your BOM.

......

Jason Bourhill
[CAD Concepts](http://www.cadconcepts.co.nz/ "CAD Concep

Jason,

Thanks. You never said what a "full stop" was, but I Googled it. British expression for a period. Are you British?
Still not sure what fixed the assembly. Was it the omission of the commas, or something else you did? I have some trepidation about using components, having seen the paths get altered on a regular basis. You pointed out some additional benefits of using components, but if the paths are going to change, the assemblies won't be reliable. In fact, I'd like to convert my assemblies to local, but since "Switch to Local" caused unrecoverable file damage, and hard system crashes, I am very leery of it. I think I will have to wait for a rainy day to experiment.

Jim Canale

Ok, I re-read your post. Apparently the special characters are the culprit. I am tempted to prove that, but don't feel like crashing my machine again. I will avoid the use of commas and "full stop". Thank you both.