Hi.
"Uffe Bak" <uffe.bak@autodesk.com> skrev i en meddelelse
news:1018601034.44061@hqnntp01.autodesk.com...
> Hej P.C.
>
> I forlængelse af Michaels indlæg - så vil jeg blot nævne at der er 2 sider
> af denne sammenligning:
>
> #1: Programmet og de tillægs rutiner som kører ovenpå platformen
>
> #2: Arbejdsmetodik og process
---------- Ja, det er netop her min tvivl har været, og jeg kan forstå ,at der
ikke er megen mening i ,ikke at overholde de retningslinier der er.
>
> Ad: #1 - allerede forklaret godt af Michael. Mechanical Desktop (MDT)
> indholder funktioner til Solid og overflade (NURBS Surface) modellering,
> opbygning af samlinger, samt generering af 2D dokumentation. Ligeledes
> finder der mange hjælpe funktioner indenfor mekanisk konstruktion (f.eks.
> ved brug af Pasninger (H7g6) er der direkte adgang til tabeller). Derudover
> findes mange standard komponenter (skruer/bolte) og en række oversætnings
> funktioner til STEP, VDAFS og IGES. Alt dette kører som en række .ARX
> programmer der automatisk indlæses ovenpå en AutoCAD - og styres vha.
> Profiler for opstart.
Jo ,det er jo gammelkendte metoder og tegnings rutiner, ------- altså at basere
tegningen på indsatte blocks og attributes, men det giver så AutoCAD en mere
"projekterings" baseret brugerflade ; altså skemaer der skal udfyldes, for at
ændre tegnings objekter ,istedet for standard måden man ellers kan være vandt
til, hvor man kalder funktionen svarer på hvad funktionen behøver , og så
"glemmer" objektet, indtil en anden funktion ændrer på objektet ; ------ Øh nu
vrøvler jeg nok lidt, men det jeg mener er, at ligesom man kan få lidt af et
problem, når man første gang arbejder med 3Ds fordi her kan nogle mene at der
ligesom "mangler" en kommando linie, så vil man stå på herrens mark, med MDT,
hvis man ikke har konkret brancespecifik viden om, hvordan man projekterer.
>
> Ad: #2 - Men den største forskel er man nu bruger en metodik rettet mod en
> Model baseret process istedet for en Tegnings baseret process. Dvs. Som
> bruger så tænker du i en fysisk 3D verden - hvor du skaber de del elementer
> som konstruktionen behøver for at fungerer. Når du er tilfreds - så skabe du
> 2D dokumentation, med indbyggede kommandoer til at genererer de afbildninger
> som man behøver for at beskrive konstruktionen.
>
Det synes jeg lyder meget fornuftigt, -------- det minder meget om den måde man
håndterer en 3Ds tegning, hvor det også handler om objekternes egenskaber, og
hvor man trækker et skama frem, når man skal ændre disse. Det "objekt
orienterede" i programeringen _vil_ jo påvirke den måde brugeren får mulighed
for at håndtere objekterne, ------- men det vil jeg lige komme tilbage til.
> Man kan tale om at man bruger en objekt orienteret metode - men det begreb
> er efter min mening mere rettet mod den programmerings metode man bruger for
> at skabe programmet. Derfor er Model begrebet måske mere velegnet.
Jep.
>
> Alt dette betyder man i MDT ikke bruger standard AutoCAD kommandoer ret
> meget udover Line, Arc, PLine etc. for at tegne den første skitse.
> Funktioner man bruger derefter er alle fra de ekstra ARX moduler - og følger
> arbejdsgang fra part, over samling til tegning/stykliste.
>
Sålænge der er fornuft i det, og dert kan bruges helt konkret, er det vel vejen
frem. (bortset fra min kæphest).
> Vort søster program Architectual Desktop (ADT) følger samme retnings
> linier - men da det er rette mod Byggeri og Konstruktion, så indeholder den
> de fag specifikke elementer som anvendes inden for dette felt. Dvs. metodik
> er anderledes - da det er rettet mod den måde om denne industri arbejder på.
Ja, -------- men så kommer du nemlig frem til min kæphest, og jeg håber ikke jeg
har hyppet den så ofte ,at i ikke tager den alvorligt ;
Det er nemlig efter _min_ mening ikke altid en fordel at "trække" standard mure,
frem fra standard biblioteker, blot fordi det nu er det nemmeste og
projekterings mæssigt sikrest. Det jeg mener er, at meget moderne byggeri er
utroligt firkantet og "Lego agtigt" , netop fordi mure er noget man trækker frem
og angiver bredde og højde på.
Altså man bygger på den måde ens arkitekt applikasion tillader at man bygger og
i det formsprog det så indebærer.
Og det gør man ikke kun fordi det er praktisk og overskueligt, men først og
fremmest, for at dokumentere. Det der så i den forbindelse er min "kæphest" er
altså ,at det er "filosofien" bag et regnskabsprogram, der kommer til at
bestemme de fysiske rammer for mine børnebørn, alene fordi det er praktisk at
bygge på den måde.
At man så kan se lidt kritisk på den filosofi, og spørge om man ikke lige så
godt kan formgive bygningen først, og så lade en applikasion generere bygge
elementer , bagefter --------- er så det jeg kalder min kæphest og de af jer der
følger gruppen, ved så også, at jeg lader min kæphest løbe frit omkring på sin
egen hjemmeside, hvor jeg prøver at argumentere for en lidt mere flexibel måde,
at projektere på ;
http://d1o111.dk.telia.net/~u139600113/a
Jeg vil så lige tilføje, at jeg da mener det er helt fint, at metoder og
standarder der existerede for 30 år siden og før, bliver omskrevet til et
computer program, ------- men bortset fra det rent profesionelle og brance
specifike , så syntes jeg at der ikke er særligt meget "ny teknologi" i dette,
bortset fra, at man har en praktisk computer, til at håndtere de samme
værktøjer, der blev brugt før bygnings konstruktører begyndte at bruge CAD
baserede projektering ; men det er ligesom man samtidigt fastlåser udviklingen
i en bestemt retning, og at dette er bestemt af praktiske hensyn, synes jeg er
en lidt tam undskyldning for, ikke at udforske de indlysende muligheder, der
trods alt i disse år er ved at åbne sig indenfor CNC styret produktion.
For at gøre en lang forvrøvlet mail endnu længere, vil jeg så sige, at det da er
fint at robotisere store dele af produktionen, men det jeg taler om, er altså
mere grundlæggende teoretisk og har med de muligheder at gøre, som jo desværre
kræver både prototyper og hands-on udvikling af noget, som desværre har det en
smule svært ,når der _findes_ gammelkendte metoder man hellere vil omsætte til
computer programmer , ---------- og arkitekterne hellere vil diskutere fantasi
projekter der mere minder om tegneserie historier og giver en en mistanke om, at
de ikke har fuldt med i matematik og fysik undervisningen i folkeskolen ; fordi
siden hvornår har man kunnet basere energi produktionen på "pitzo elektriske"
elementer, der danner energi ,når bygningen rokker i vinden ?
Altså skal vi bygge med Lego fordi ingen af arkitekterne har overblik over hvad
en applikasion egentligt er, og skal udviklingen fastlåses af "state of the art"
, alene fordi ingen tør være kritiske.
Jeg håber i har taget min small-talk til jer, og accepterer at det er svært at
undlade at drage et par konklusioner, når fakta er som fakta nu engang er.
P.C.
>
> Endeligt - så er det helt fint med denne slags åbne spørgsmål - det en
> nyhedgruppe af denne type giver et godt diskussions forum.
>
> Med venlig hilsen - og god weekend
>
> Uffe Bak
> Autodesk Nordic & Baltic
>
>
>
>
> "CADmageren" <CADmageren.news@kandu.dk> wrote in message
> news
wt8.15523$567.862167@news000.worldonline.dk...
> > Hej P.C.
> >
> > Mechanical Desktop (MDT) er en overbygning til AutoCAD.
> > Dvs at det er en ganske almindelig AutoCAD, hvorpå der er lagt en masse
> > ekstra moduler.
> > Solids og andre MDT-objekter kan kun redigeres hvis MDT er installeret,
> > men de kan som regel godt ses i en standard AutoCAD - om
> > "proxyobjekter".
> >
> > Med venlig hilsen
> >
www.cadmageren.dk
> >
> > Michael Christoffersen
> >
> >
> > --
> > Leveret af:
> >
http://www.kandu.dk/
> > "Vejen til en hurtig løsning"
> >
>
>