Re: Overhead and the Future

Hawco, Paul R. wrote:

> [I've snipped parts to what I wanted to comment on. -PB]
> PRH - me too
>
>
> 2.1) I already know this, this is a relatively simple part of the entire
> process. Once the database is built everything else follows. As I
> mentioned (I don't want to be seen as plugging COADE, since they are a
> site sponsor, but) doing this sort of thing with non-PDS/PDMS is getting
> easier and easier. I don't need/want the process department to have to
> exactly buy a component while I am running pipe and placing inline
> components. That can be specified and entered later.
>
>
> PRH: Today, CADworx, autoplant ... and PDS could all be used on the same
> project (different units) - Navisworks is a 3D viewing tool that
> supports many of the different Plant design vendors - you can pull them
> together - you just need to know a lot about the setup of each program
> as the process will involve setting a scale and offset in some of the
> files - even though each program measures in feet or m they have their
> own internal scale which must be factored in. We use CADpipe and PDS
> here and I have used models from both on the same projects - it takes a
> lot of work to stay on top of it. In my mind it really only makes sense
> if you can isolate the project into units. Many clients don't want to
> do it because you then are most likely looking at different
> drawing\report formats for each unit as well.

2.1.2) I hear what you're saying and I think your last sentence is very important. Maybe we could design using whatever software we want and then use a translator to convert the raw data into something visually consistent for managers to review. It's not that managers are evil and/or incompetent (some obviously can be and are, however), it's that they want to simplify things so that they can make decisions without getting bogged-down with overly-complex computer or software-related obstacles.

> 4.1) "we just need someone to write the code and then provide training
> to take people to the next level". Do you know what BRL-CAD is?
>
> PRH: I didn't until you mentioned it - the US government and military
> have the resources to do anything they want - if the OIL companies were
> interested in taking plant design engineering to the next level it would
> be done overnight - they are not. [...]

4.1.2) BRL-CAD is now open source, it was released early in 2005. See <a href="http://developers.slashdot.org/article.pl?sid=05/01/08/1823248&tid=185&tid=103&tid=117&tid=8">http://developers.slashdot.org/article.pl?sid=05/01/08/1823248&tid=185&tid=103&t\ id=117&tid=8</a>
(see http://makeashorterlink.com/?H2E6166CB if the above is truncated). "Open Source" software essentially means that anyone can download the source code and do whatever they like with it without having to pay the original developer.

> 13.1) Too much reliance on newfangled programs is a bad thing. I've seen
> transmitted PDF engineering drawings that are illegible (but the
> supplier has fulfilled his obligation) and other PDF documents that were
> sent by a whiz kid using a version of Adobe that had features that were
> invisible to the end user (unless, of course, the end user had clicked
> and enabled an obscure command within Acrobat Reader). This is good
> somehow?
>
>
> PRH: You are highlighting my point exactly - PDF - NEW tools - NO
> training. These tools are invaluable if you use them right - problem is
> for every person that uses them effectively there are probably 100 who
> don't.

13.1.2) In the cases I was referring to it was vendors that provided both examples of illegibility and/or confusion-causing documentation. I guess that just goes to show that document format, creation methods etc. must be agreed-upon before work starts. Another great example was a legitimate recipient's email server rejecting zipped files because it thought they might be contain viruses.

Paul Received on Sun Sep 11 02:02:00 2005