Sometimes the valves go on wrong layer. Even if I change the layer of the valve after I isolate that layer the valve disappears. If it would be on different layer. I have to use BEDIT command to edit the valve block, delete the 3D model an replace a new one with 0 layer.
The 3D solid of a valve has to be on 0 layer within the block. But the P3D assign different layer within the block to that 3D solid.
Is it a bug?
Can it be fixed?
Solved! Go to Solution.
You can access layer settings for Plant 3D by going to PROJECTSETUP, Plant 3D DWG Settings > Layer and Color Settings.
Have you set up your layers like you want them to be through this dialog?
Actually I turned off this feature a long time ago.
I made those custom made valves with custom geometry. Maybe the problem was with the 3D solids. I changed all line properties of the solid (color, linetype, lineweight, material) to ByBlock. Hopefully I won't have this kind of problem anymore.
We have the same problem. From my experiences in AutoCAD I think that is something with block creation, In catalog with valves.
In our project, problem is with check valves.
I have idea that We must change block with this type of valve directly in folder with block for Plant ...
I must test...
P.S. idea with layer codification is good, but it seam that doesn't work with some type of valves.
Yes, the problem with the valves only. The fittings and tubes are OK.
I realised that the P3d assigns the pipeline layer within the 3D block to the 3D solid when I insert a new valve. But if I insert the same type and size valve on a different line the layer of the valve solid within the block remains the same. That is the problem.
Maybe if I insert a valve on the 0 layer the P3d won't assign different layer.
I will try.
In the meantime I found a solution.
Be on the "0" layer always when routing a pipe or inserting a valve block. The software will change the layer automatically according to the line number.
And when create a new inline element in the cataloge based on custom dwg geometry set everything to "By block".
Found the solution:
All custom block components MUST be color "Byblock", layer 0. Once you create the block, the block MUST be color "ByLayer", layer 0. Then you plantpartconvert them and then it the parts will change color with the layers.
The cause of this problem is that Plant3d, in reality, is just Autocad with a bunch of Blocks kept in a database. When you insert a custom valve, it re-"blocks" your custom block and will associate a color with the current layer. The plantpart thus becomes a deeplly nested block with the current layer/color and now you can't change the color of the block without a bunch of complicated bedits.
Now, if your catalog is like mine and full of literally hundreds of custom blocks, its prohibitively time consuming to go back and bedit all your old blocks and re-input them into your plant database.
Instead, I was able to find a lisp routine, "fixblock.lsp" that will fix all your custom parts without breaking the plant intelligence. All you need to do is run the lisp, select all the blocks in the drawing (or at least all the parts you want fixed), and then do a "regenall" and BAM everything will show up with the correct color/layer association.
I'm not sure if you had already come up with the solution yet, but I wanted to post this in case anyone had this problem still.
P.S. I'm such a luddite with computer stuff sometimes. I don't know how to attach a file but here is the lisp routine I was referring to. its an oldie but a goodie:
;FixBlock.lsp [June 30, 1998]
; Copyright 1996 - 1998 ManuSoft
; Freeware from:
; Load function, then enter FIXBLOCK to redefine selected blocks
; so that all entities are on layer '0', color 'BYBLOCK'.
(defun C:FixBlock (/ ss cnt idx blkname donelist Grp Update)
(defun Grp (gc el) (cdr (assoc gc el)))
(defun Update (bname / ename elist)
(setq ename (tblobjname "BLOCK" bname))
(and ename (zerop (logand 52 (Grp 70 (entget ename '("*"))))))
(setq elist (entget ename '("*"))
elist (subst '(8 . "0") (assoc 8 elist) elist)
elist (if (assoc 62 elist)
(subst '(62 . 0) (assoc 62 elist) elist)
(append elist '((62 . 0)))))
(setq ename (entnext ename)))
(if (/= "ENDBLK" (Grp 0 elist))
(entmake '((0 . "ENDBLK") (8 . "0") (62 . 0))))
(if (> (logand (Grp 70 (tblsearch "layer" "0")) 1) 0)
(princ "\nLayer 0 must be thawed before running FIXBLOCK!\n")
(princ "\nPress <Enter> to fix all defined blocks\n")
(setq cnt 0
ss (ssget '((0 . "INSERT")))))
(setq idx (sslength ss))
(while (>= (setq idx (1- idx)) 0)
(if (not (member (setq blkname (Grp 2 (entget (ssname ss idx)))) donelist))
(if (Update blkname) (setq cnt (1+ cnt)))
(setq donelist (cons blkname donelist))))))
(while (setq blkname (Grp 2 (tblnext "BLOCK" (not blkname))))
(if (Update blkname) (setq cnt (1+ cnt)))))
(princ (strcat "\n" (itoa cnt) " block" (if (= cnt 1) "" "s") " redefined\n"))))
Only one problem. When I want to save on a model after using Fixblock I have a severe system freezup. I have to reset my computer after this.
Hrm, i haven't really run across that problem yet. How big are your files? can you fixblock and save incrementally? Perhaps a purge then an audit might help before you try to save.