Trimble Business Center

I just wanted to verify that TBC v5.0 seems to be handling blocks a lot better. I used to battle blocks because I would get a lot of blocks that had nested entities on the 0 layer, so when you exploded blocks you would get a bunch of data on the zero layer that you would have to manual sort through. I am surprised that this didn't make the release notes, if so, but I do understand there was probably a lot to cover. I went through 6 old projects yesterday (importing the original CAD files and running through the standardize function) and could not replicate the issues I used to have with versions earlier than TBC 5.0.

Thank you TBC team!!!! This has made the standardize process a lot faster and smoother. 

Awesome

Glad that we are doing some good stuff for you all in Development. Thanks Pat for sharing this, the developers love an Attaboy from time to time, and it is better coming from users that appreciate what they are doing

Really appreciate your efforts on the Forum Pat

Alan

I did some in depth testing on this today and it appears that you end up with a lot more block entities on the 0 layer or "prefix" 0 layer when you had a prefix when importing a dwg. I tested this four times; raw file from from engineer, raw file from engineer with adding prefix to layers, converted file from civil 3D, converted file from civil 3D with adding prefix to layers and in both cases where I added prefixes to layers I ended up with substantially more entities going to the "prefix"-0 layer.

I am going to request a macro to relayer block entities that have either a 0 layer for the entities or "prefix"-0 layer to make this process quicker. 

Could this be look into in the future for the import process?

Thanks!

The dwg with the prefix "ACAD-" is the "clean export I did  from civil 3D. The other is the original CAD drawing I received from the engineer.

Please add your test file to the posting so that our QA team can validate and comment

Alan

Question

I have been looking at the issue here and have discussed with development. 

1) We use a library product to do the "AutoCAD Stuff" in TBC. so the "Exploding" is done in the library - we send things to it and it returns the data to the database so it isnt quite so easy to do what you are asking about relayering block entities that would end up on Layer 0 to the Layer of the Block. However it would be possible to write a separate command that serves up the blocks one at a time to the engine and then relayer the data on return to the Block Layer so we could potentially write a second Explode command that behaves differently - we may be able to combine the two into the existing command but we need to evaluate that.

2) When you prefix the Layers, we could treat Layer 0 differently and not prefix that layer. This we think would solve the issue with more objects showing up on Layer 0 after the Explode command - we are going to test that to see if that would at least result in the same behavior and we are looking at what specifically is causing this effect that you are seeing. We think it is because data drawn on Layer 0 and Blocks that are created on Layer 0 have different operational characteristics so we have to be careful we dont break something here. Main challenge with this approach is that all Layer 0 data from all imported DWG files would end up on Layer 0 - that is OK if you Relayer all that stuff after import to other Layers thereby leaving Layer 0 Empty after each round of Import, however if you did not do that you would now have layer 0 data from various batches of import all on the same layer because that is not getting prefixed.

Let me know what you think on this question. As with all these types of request the devil is in the details and I want to make sure that if we do something here that we do it the best way possible.

Again no promises - the team is busy right now and if this is a bigger deal than a "quick fix" it will end up on the request list with many other things sitting out there.

Alan

Alan,

1. This sounds good to me. If the import takes a little extra time (I believe we would be talking seconds correct? might even be unnoticeable) that is fine with me if it saves manual manipulation. Or would this command be a separate command in BC such as a command in Project Cleanup.
2. This sounds good as well.Currently everything is going to my "Prefix"0 layer, so if we can send it to the 0 layer but reduce the entities that end up there, I have no problem with that. I try to keep nothing on the zero layer anyway. I treat this as a "broken" catch all. After I import a file I try to get all of the data on logical layers and clean up the linework. If I can't think of where to associate data, I will usually through a z in front of the layer and assign this to a misc view filter for later use. So the work flow you are presenting would fit into this without any serious alterations to my workflow. 

Thanks,

Pat

We have a test file now that ;eaves Layer 0 alone

1) There are only 66 Objects on Layer 0

2) All the other Blocks that are on other Layers are still invisible when you isolate Layer 0

3) When you explode the Blocks you end up with    objects on Layer 0

4) All the Block Data that was defined on other Layers is now on the other prefixed Layers after explode

This is as per the import without Prefixing. This would minimize the number of objects that you have to relayer until we can address the Explode option. DOes this help / Make sense.

Alan

I believe I follow you. 3 and 4 are throwing me off a bit though. 

3) When you explode the Blocks you end up with    objects on Layer 0. - Does this mean you ended up with no objects on the 0 layer?

4) All the Block Data that was defined on other Layers is now on the other prefixed Layers after explode - here you mention prefixes, below you mentioned this process was executed without using the prefixing import on. If you wouldn't mind clarifying this. 

If the standard import was able to address blocks and bring this to reasonable minimum (like you mention above) if not zero, this would save me a lot of time and I wouldn't mind scarifying prefixes on import. Maybe a macro (short term fix) or a command (long term depending on the complexity of this issue) could be written to take layers in BC and add a prefix (Gary wrote a great macro that copies linework and adds a prefix to the layers for things such as phased projects :TML - Copy Layer Group Members (V2) ) this would do the same thing as what I am doing currently but in a different series of events and saving me quite a few steps and manual manipulation. 

My biggest use for prefixes is so that the engineer's data does not flood in with my layers and I use prefixes to keep track of revisions. 

Thank you. 

We made a minor change to the TBC DWG / DXF Importer. That when you say

Prefix Layers all layers except Layer 0 get prefixed. Because Layer 0 has

special meaning in the AutoCAD world, prefixing it changes the meaning of

data assigned to Layer 0 and the way that it behaves. Of course sometimes a

user deliberately uses Layer 0 and sometimes they use Layer 0 by mistake -

we will never know which they intended of course.

When we prefix all layers except Layer 0 then we get the exact same

scenario that you have in your video when you dont prefix the layers. There

is little data specifically drawn on Layer 0, and when you explode blocks

you get some data that falls out of Blocks inserted on other layers that

have lines embedded on Layer 0, but it is the same amount as you had in

your example of non prefixed layer import.

That means that today I have to clean up those 500 or so items not the 2500

or so items. I would have to clean out Layer 0 after each import so that

the next import with different Prefix would then start the process over

again.

We are going to look at how fast a process would be where we send the

selected Blocks to the Exploder one by one so that we can control the

layering of the data coming back.

The question we had though is that if the Block was placed on a Layer

called Block, and has embedded linework on Layers 0, Fred, George and

Harry, when we relayer the data coming back should we leave all but Layer 0

as is and relayer the Layer 0 data to the Block Insert Layer, or should we

relayer all of the data coming back to the same layer as the Block Insert

Layer?

We are thinking that because the current Explode Command behaves the same

way that AutoCAD behaves we should leave it as is and if we need an Explode

Block Command for Data Prep that behaves quite differently that we likely

should do that as a separate process.

Alan

On Thu, Dec 6, 2018 at 4:29 PM plheureux@severinotrucking.com <

Alan that sounds great. Thank you for addressing this. I would much rather work with 500 entities vs 2500 entities. 

In regards to the blocks that have a mix of entities on different layers, I would recommend only relayering entities that are on layer 0. The entities on layers are essential "smart data" where as entities on the zero layer are "dumb" data. I would rather the layered entities go to their intended layer and then I can decide later if I want to change these using the Standardize tool or relayer tool. Sometimes the separation of layers is useful. Every now and then I will receive xrefs as blocks and if everything was relayered this block would become useless.

Another example would be for instance on a cistern, there is some linework that I will need and my field crews will need for design and build purposes. There is some linework that is unnecessary such as mechanical joints. If the blocks are prepared correctly(cross your fingers), those different style entities should go to different layers making it easier to cleanup versus everything getting dumped to a cistern layer and manually deleting components over deleting layers.

I understand there may be a use for relayering all the block entities to the block's layer but I would recommend this as a separate command because I think it has the potential to create more work in certain situations if this was integrated into the import process. 

Blocks and prefixes have been working great since the update. I am getting very few entities, sometimes none, that get dumbed on the zero layer. Thanks again for looking into this!

@Gary Lantaff @Alan Sharp

I think this got broken with 5.10. I am no longer seeing a 0 layer being created when you import a dwg/dwf with a prefix. Such as Z-Test-0

May I also recommend that this prefix layer 0 be set to protected when created. This would eliminate this layer getting deleted when running project cleanup. 

I have also noticed that if you set the Civil3D proxygraphics are set to 1, you get very minimal entities on layer and blocks tend to be easier to work with. The combination of this and the tweaks in the V5.0 patch and this have greatly reduced the entities I see on the zero layer. Thank you for the help.