bi: TNO-Bouw 4%0--o%

Transcriptie

1 bi: TNO-Bouw 4%0--o%

2 *1 T NO-Bouw Lange Kleiweg 5, Rijsvuijk Postbus AA Delft Telex Fax Telefoon TNO -rapport 93-BI-R 1227 CAD NEUTRALE LEAFO EDITOR - CAD ONAFHANKELIJKHEID GEDEMONSTREERD f BIBUOTJ-IEEK december 1993 BRM, LNB RIJKS WATERSTAAT UTRECHT [. RWS bibliotheek locatie Utrecht Postbus LA Utrecht Aan: Rijkswaterstaat Bouwspeurwerk Postbus LA Utrecht Alle rechten voorbehouden. Niets uit deze uitgave mag worden vermenigvuldigd en/of openbaar gemaakt door middel van druk, fotokopie, microfilm of op welke andere wijze dan ook, zonder voorafgaande toestemming van TNO. Indien dit rapport in opdracht werd uitgebracht, wordt voor de rechten en verplichtingen van opdrachtgever en Projectnaarn Projectnumrner Auteur (s) opdrachtnemer verwezen naar de Pagina s 'Algemene Voorwaarden voor Onderzoeks- Bijlagen opdrachten aan TNO', dan wel de betreffende terzake tussen partijen Figuren gesloten overeenkomst. Tabellen Het ter inzage geven van het TNO-rapport aan direct belanghebbenden is toegestaan. RWS Constructie ing. M.R. Boender drs. B.F.M Luijten TNO Thema WP-subject Trefwoorden : LEAFO editor : LEAFO, LEAFO editor Nederlandse organisatie voor toegepast-natuurwetenschappeliik onderzoek TNO-Bouw verricht onderzoek en geeft advies over bouwvrsagstukken, voornamelijk in opdracht van onder meer de overheid, grote en kleine ondernemingen in de bouw, toeleveringsbedrijven en branche-instellingen. Tip-to

3 93-BI-R1227 december 1993 Dit rapport geeft verslag van een project uitgevoerd in het kader van het onderzoek verricht naar PDlJWegen & Viaducten ten behoeve van integratie bij het computerondersteund ontwerpen van civiel-technische werken, door strukturering van (deel)produktmodellen annex aspect-modellen, door ontwikkeling van prototype software en door ondersteuning van operationalisatie van onderzoeksresultaten. Voor zowel PDIJWegen als PDllViaduct zijn de werkzaamheden in vier clusters ondergebracht. De clusters uit PDL/Viaduct zijn in het meerjaren-programma als volgt omschreven: Cluster A: Ontwikkelen en beproeven van integratiemethoden door middel van produktmodellering gericht op produkttypen in het bijzonder het BasisViaduct- Model, alsook gegevensoverdracht tussen systemen; Cluster B: Ontwikkelen en implementeren van een omgeving ten behoeve van de ontwikkeling, prototyping, implementatie en introductie van produktmodellering en gegevensuitwisseling bij Rijkswaterstaat; Cluster C: Bijdrage leveren tot het operationaliseren van de huidige beschikbare ideeën en kennis uit het verrichte onderzoek in de ontwerp-praktijk; specialistische ondersteuning bij realisatie van operationele software; Cluster D: Gericht kennisnemen, beoordelen (monitoren) en terugkoppelen bruikbaarheid voor de ontwerp-praktijk van (standaardisatie)-ontwikkelingen, kennisoverdracht, voorlichting, en coördinatie. In dit rapport 'CAD-neutrale LEAFO editor - Voorstudie grafische terugkoppeling' wordt verslag gedaan van een onderdeel uit cluster C. Het rapport moet gezien worden als een bijlage bij het rapport 'CAD-neutrale LEAFO editor - CAD onafhankelijkheid gedemonstreerd' [BOENDER&LUIJTEN-93].

4 93-BI-R 1227 december 1993 INHOUDSOPGAVE 1. INLEIDING 1 2. LEAFO'S ONDER AuTOCAD AutoLISP Resultaat Variabelen Geometrie onder AutoCAD AutoCAD basis geometrie Standaard elementen Standaard profielen AutoCAD system environment AutoCAD systeem variabelen LDP systeem variabelen Platform afhankelijkheden Resterende werkzaamheden AANPASSINGEN LEAFO EDITOR Porten naar C versie van PMshell Neutrale Expressies Grafische interface Grafische terugkoppeling Hergebruik damwand voorbeeld Mogelijke verbeteringenluitbreidingen CONCLUSWS EN AANBEVELINGEN 12 LITERATUUR 14 BIJLAGE A: SUBMODEL ELEMENT BESCHRIJVINGEN 15 BIJLAGE B: PROFIEL ELEMENT BESCHRUVINGEN 21

5 93-BI-R1227 december INLEIDING In het rapport CAD neutrale LEAFO editor' [BOENDER&LUIJTEN-92] van november 1992 wordt beschreven hoe parametrische objecten op een CAD neutrale manier kunnen worden opgeslagen en vertaald naar een CAD specifieke programmeertaal. In het prototype van de CAD neutrale LEAFO editor worden de parametrische objecten echter niet volledig op een CAD neutrale manier opgeslagen. De expressies die nodig zijn voor het berekenen van parameter waarden binnen een LEAFO [KUIPER-89a, KUIPER-89b] worden opgeslagen in DAL code waardoor een afhankelijkheid met het CAD systeem Dimension III ontstaat. Dit rapport geeft een beschrijving van de manier waarop parametrische objecten volledig op een CAD neutrale manier kunnen worden opgeslagen. Hiervoor is het prototype van de LEAFO editor uitgebreid met neutrale expressies die worden opgeslagen in een LISP formaat dat eenvoudig te vertalen is. Als demonstratie van de CAD neutraliteit is naast de vertaling naar DAL een vertaling naar AutoLISP ontwikkeld, waarmee wordt aangetoond dat één LEAFO definitie zowel op Dimension III als op Aut0CAD gebruikt kan worden. Daarnaast is de LEAFO editor overgezet naar een nieuwe versie van PMshell waardoor de performance en robuustheid aanzienlijk verbeterd is. In hoofdstuk 2 wordt beschreven hoe de ondersteunende software, waar de LEAFO editor gebruik van maakt, is overgezet naar AutoLISP. In hoofdstuk 3 worden de noodzakelijke uitbreidingen en verbeteringen aan de LEAFO editor beschreven. In dit hoofdstuk wordt ingegaan op de keuze voor LISP als opslag formaat voor de neutrale expressies. In hoofdstuk 4 worden een aantal conclusies gegeven en worden een aantal aanbevelingen gedaan ten aanzien van een eventuele verdere ontwikkeling van de LEAFO editor.

6 93-BI-R1227 december LEAFO'S ONDER AUTOCAD Een van de uitbreidingen aan de bestaande versie van de LEAFO editor was het ondersteunen van LEAFO generatie onder Aut0CAD. Hiertoe diende in eerste instantie de in DAL (Dimension III) geschreven LEAFO Development Package (LDP) met LEAFO ondersteunende routines geport te worden naar Aut0LISP [BOENDER&LIJIJTEN-92]. Deze vertaling is tot nu toe voor zon 80% gereed en biedt de belangrijkste functionaliteiten. In de volgende paragrafen wordt nader ingegaan op een aantal bijzonderheden die tijdens het porten naar AutoCAD naar voren zijn gekomen. Er is in dit hoofdstuk een onderverdeling gemaakt naar taal specifieke zaken (par. 2.1), geometrie specifieke zaken (par. 2.2) en de system environment (par. 2.3). In de laatste paragraaf (2.4) wordt een opsomming gegeven van de nog onder AutoCAD uit te werken LDP functionaliteiten. 2.1 Aut0LISP In deze paragraaf worden enkele bijzonderheden vermeld die tijdens het porten van het LDP zijn opgevallen en die te maken hebben met taal specifieke eigenschappen van AutoCAD. Deze opmerkingen zijn onderverdeeld in de categorieën 'Geometrie' (par ), 'Variabelen (par ) Resultaat Wanneer binnen Aut0LISP geometrie wordt gegenereerd is het niet zoals binnen DAL (Dimension III) dat de identificatie (entiteitsnaam) van de gecreëerde entiteit direct terug gegeven wordt. Via een speciale entiteiten aanroep 'entiast' kan de identificatie van het laatst gecreëerde entiteit verkregen worden Variabelen In Aut0LISP zijn variabelen altijd globaal tenzij in de header van de functie anders gedefinieerd wordt. Het is gebleken dat alle lokale variabelen als zodanig gedefinieerd moeten worden. Binnen het principe van LEAFO's is het niet ongewoon om binnen verschillende LEAFO knopen dezelfde variabele namen te gebruiken. Met name voor de indices van een loop constructie (i, j, k,...). Als vanuit een loop een andere knoop (routine) geactiveerd wordt die een variabele heeft met eenzelfde naam als de index variabele van de loopconstructie kunnen uiteraard rare effecten ontstaan. De loop kan bijvoorbeeld oneindig actief blijven of juist te vroeg beëindigd worden. Aut0LISP ondersteund tevens geen modificeer list operaties. Zo is het dus bijvoorbeeld

7 93-BI-R1227 december 1993 niet mogelijk de waarde van een bepaald veld in een matrix met een enkele wijzig-operatie te veranderen. De gehele matrix moet opnieuw gedefinieerd worden. 2.2 Geometrie onder AutoCAD Via het LDP kan vanuit een LEAFO definitie op verschillende manieren geometrische elementen worden gerefereerd AutoCAD basis geometrie Binnen AutoCAD word een groot aantal standaard geometrische entiteitstypen ondersteund. Binnen de huidige versie van het LDP maken wij gebruik van slechts een aantal daarvan. De LDP routines voor het genereren van geometrie vallen uiteen in twee groepen. De eerste groep vindt binnen AutoCAD een standaard functionaliteit voor het genereren van zijn geometrie (lfpnt, ifine, lfcrc). De overige primitieven (met name solids) vinden in de basis AutoCAD configuratie geen standaard functionaliteit. Voor deze routines is, gebaseerd op bestaande functionaliteiten, getracht de gewenste functionaliteit zo goed mogelijk te benaderen (lffce, lfbox, lfsph, lfrul, lfsweep, lfcyl). Wij geven hier een enkel voorbeeld. Binnen de standaard Aut0CAD configuratie van versie 11 is geen standaard functionaliteit aanwezig voor het genereren van sweeps. Om deze functionaliteit toch te kunnen gebruiken is op basis van '3dface deze functionaliteit benaderd Standaard elementen Een standaard element is in feite een submodel welke op het systeem als aanwezig wordt geacht. Van elk standaard element wordt voorlopig verondersteld dat het aangrijpingspunt exact op de oorsprong ligt en dat de primaire- en secundaire oriëntatie vectoren bekend zijn. Elk element zal dus in een catalogus opgenomen moeten zijn waarbij deze informatie duidelijk vermeld is. In bijlage A zijn voorbeelden opgenomen van de standaard element beschrijvingen van het type 'submodel' zoals gebruikt in de voorbeelden 'damwand' en 'geleiderail'. Het LDP verwacht alle standaard elementen te vinden in de directory aangegeven via de systeem variabele STDPARTSLIB (zie 'LDP systeem variabelen'). Vanuit een LEAFO beschrijving hoeft uitsluitend aangegeven te worden welk standaard element gewenst is en niet waar deze zich bevindt.

8 93-BI-R1227 december Standaard profielen Een standaard profiel is in feite een ASCII file waarin het profiel via zijn x- en y- coördinaten beschreven is. Van elk standaard profiel wordt voorlopig verondersteld dat het aangrijpingspunt exact op de oorsprong ligt en dat de primaire oriëntatie vector langs de positieve Z-as loopt. Elk profiel moet eveneens in een catalogus opgenomen zijn waarbij deze informatie duidelijk vermeld is In bijlage B zijn voorbeelden opgenomen van de standaard element beschrijvingen van het type 'profiel' zoals gebruikt in de voorbeelden 'damwand en 'geleiderail'. Het LDP verwacht alle standaard profielen te vinden in de directory aangegeven via de systeem variabele STDPARTSLIB (zie 'LDP systeem variabelen'). Vanuit een LEAFO beschrijving hoeft uitsluitend aangegeven te worden welk standaard profiel gewenst is en niet waar deze zich bevindt. 2.3 Aut0CAD system environment Ten einde het LDP naar behoren te laten werken moeten een aantal systeem variabelen gezet zijn voordat Aut0CAD opgestart wordt. In de hier volgende paragrafen worden de vereiste systeem variabelen van belang voor Aut0CAD en voor het LDP apart vermeld AutoCAD systeem variabelen ACAD Directory waar alle Aut0CAD specifieke initialisatie files staan. ACADCFG Directory waar alle Aut0CAD configuratie files staan inclusief de Aut0CAD 3D Aut0LISP code files LDP systeem variabelen LDP_DIR Directory waar de LEAFO Development Package geïnstalleerd is. In deze directory bevinden zich alle LDP specifieke zaken zoals bijvoorbeeld de Aut0LISP code en de LDP configuratie files. LDP_TEST_DIR Directory waar de LEAFO editor tijdelijk test LEAFO's kan plaatsen. Het LDP is hiermee in staat deze test LEAFO's automatisch in te lezen.

9 93-BI-R1227 december 1993 STDPARTSLIB Directory waar alle submodellen en profielbeschrij vingen staan van de in de voorbeelden gebruikte standaard onderdelen. In de praktijk zal dit bestaan uit een reeks systeem variabelen waarbij een onderverdeling kan worden gemaakt naar bijvoorbeeld onderdeel-type of fabrikant Platform afhankeljkheden De AutoLISP versie van het LDP is uitgewerkt onder AutoCAD Release 11 c 1 voor de Sun4/SPARCstation. 2.4 Resterende werkzaamheden. De implementatie van het LDP onder AutoCAD versie 11 heeft een aantal nog niet (geheel) uitgewerkte onderdelen. De ondersteuning voor het opbouwen van een hiërarchische 'datastructuur' waarin alle LEAFO onderdelen via hun Id ingedeeld zijn werkt nog niet naar behoren. Dit houdt in dat het momenteel nog niet mogelijk is stukljsten te genereren. Het is in ieder geval wel mogelijk deze functionaliteit in AutoCAD onder te brengen en zal ook worden uitgewerkt. Momenteel wordt nog geen gerichte ondersteuning gegeven voor het gebruik van meerdere detail niveaus voor de geometrische representatie van een LEAFO instantie. Het is overigens de vraag in hoeverre door het LDP ondersteuning gegeven moet worden of dat dit een verantwoordelijkheid is voor de LEAFO programmeur (LEAFO editor). Het LDP kan echter wel een minimale ondersteuning bieden in de routines voor het genereren van standaard geometrie (ifbox, lfsph, lflne,...). Door deze routines uit te rusten met een extra detail niveau' parameter kan vanuit het LEAFO aangegeven worden hoe de geometrische entiteit zich moet representeren. Implementatie hiervan kan op korte termijn uitgevoerd worden en het betreft geen ingrijpende aanpassing van de applicatie. Twee LDP routines zijn zodanig aangepast dat de eindgebruiker tijdens LEAFO instantiatie de LEAFO zo nu en dan een handje moet helpen. Is in de DAL versie de routine LFCALCINT zelf in staat het intersectie punt tussen bijvoorbeeld een lijn en een cirkel te bepalen zo zal in de AutoLISP versie de gebruiker

10 93-BI-R1227 december 1993 moeten inspringen door met de cursor aan te geven waar het intersectie punt zich 'ongeveer' bevindt. Voor de routine LFSTARTPOINT geld in principe hetzelfde. In de Aut0CAD versie moet de eindgebruiker aangeven waar het beginpunt van bijvoorbeeld een lijn zich ongeveer bevindt terwijl de versie in DAL dit zonder problemen zelf kan bepalen. Dit probleem is alleen dan op te lossen wanneer code wordt geschreven die zelf in staat is, om aan de hand van de element gegevens, het intersectiepunt resp. het startpunt te berekenen. Dit laatste voorbeeld geeft een aardig idee van de problemen die kunnen voorkomen wanneer een 'koppeling' gemaakt moet worden tussen de LEAFO editor en een 'nieuw' CAD systeem. De LEAFO editor gaat ervan uit dat het te koppelen CAD systeem over een standaard set functionaliteiten beschikt (neutrale interface). Voorziet het CAD systeem niet volledig in die set dan zal deze (meestal via het zelf implementeren van de gewenste functionaliteiten) aangevuld moeten worden.

11 93-BI-R1227 december AANPASSINGEN LEAFO EDITOR Het prototype van de LEAFO editor zo als deze eind 1992 beschikbaar was liet nog veel te wensen over. Dit hoofdstuk geeft een overzicht van de werkzaamheden die als doel hadden de LEAFO editor stabieler (en daardoor betrouwbaarder) te maken, geschikt te maken voor ondersteuning van meerdere CAD systemen en gebruikersvriendelijker te maken. In de hier volgende paragrafen worden deze aspecten afzonderlijk belicht en aansluitend wordt een overzicht gegeven van bestaande ideeën met betrekking tot verdere aanpassing/uitbreiding van de LEAFO editor. 3.1 Porten naar C versie van PMshell De nieuwe versie van de LEAFO editor is geïmplementeerd met behulp van de nieuwe versie van PMshell. Het LEAFO domein, dat de basis vormt van de LEAFO editor, moest daarvoor opnieuw worden ingevoerd. De volgende stappen waren daarvoor nodig: - Het Express schema dat met de oude versie van PMshell was geschreven kon worden ingelezen met de nieuwe versie van PMshell. Hierdoor was de datastructuur van het LEAFO domein weer hersteld. - De functies en procedures (die niet in een Express schema kunnen worden beschreven) moesten worden toegevoegd. - De bodies van functies en procedures moesten worden vertaald van Eiffel naar C. Zowel Eiffel als C zijn object-gerichte programmeertalen met veel overeenkomsten. Een aantal mogelijkheden die Eiffel biedt worden in C niet ondersteund, maar zijn in de PMshell omgeving aan toegevoegd. De vertaling van het LEAFO domein van Eiffel naar C++ was daarom recht toe recht aan. 3.2 Neutrale Expressies Een van de doelstellingen van de nieuwe LEAFO editor was het ondersteunen van neutrale expressies. Met de oude versie van de LEAFO editor worden expressies als DAL strings opgeslagen, waarmee een afhankelijkheid met DAL ontstaat. Een eerste methode voor het ondersteunen van neutrale expressie is om expressies in te voeren en op te slaan in de vorm van objecten. Voor elke expressie ontstaat op die manier een object boom van waaruit code kan worden gegenereerd voor verschillende target

12 93-BI-R 1227 december talen. Het nadeel van deze aanpak is dat het invoeren van expressies in de vorm van objecten een omslachtige manier van werken is en dat een datastructuur voor de expressies moet worden ontwikkeld. Een tweede methode voor het ondersteunen van neutrale expressie is om expressie te kunnen invoeren als strings en deze strings vervolgens te parsen en te vertalen naar een object boom. Deze manier van werken biedt de mogelijkheid om expressies in te voeren als strings met daarbij de mogelijkheid om expressies te genereren voor verschillende target talen. Het nadeel is dat nog steeds een datastructuur voor de expressies moet worden ontwikkeld en dat een parser moet worden geschreven. In de gekozen methode worden expressies ingevoerd en opgeslagen als strings. Als taal is Aut0LISP gekozen omdat dit een gestructureerde taal is en omdat het ontwikkelen van een nieuwe taal een hoop tijd vergt en niet van belang is voor de LEAFO editor. Daarnaast vergt een nieuwe taal een leerproces terwijl Aut0LISP bekend mag worden verondersteld. De expressies worden ook opgeslagen als strings om te voorkomen dat een datastructuur voor de expressies moet worden ontwikkeld. Om toch de generatie naar meerdere target talen mogelijk te maken worden de expressie geparsed en vertaal naar een van de target talen. Hiervoor is een parser geschreven voor de expressies in Aut0LISP. Deze parser biedt tevens de mogelijkheid om syntax fouten bij het invoeren van expressies te melden aan de gebruiker. 3.3 Grafische interface De user interface van de LEAFO editor bestaat uit twee delen. Het grafische deel en het point & dick deel. Voor het point & dick deel wordt de user interface van PMshell gebruikt terwijl voor het grafische deel de CGE wordt gebruikt. In de oude versie van de LEAFO editor was met name het grafische deel qua performance en robuustheid een zwakke schakel. Dit is echter met de nieuwe versie van PMshell aanzienlijk verbeterd. Daarnaast is de hoeveelheid informatie (lees het aantal symbolen) op het scherm gereduceerd tot een overzichtelijke structuur, zodat een complexe LEAFO als de damwand in zijn geheel op het scherm kan worden bekeken (voorheen was de damwand opgesplitst in drie delen). De verdere informatie kan met behulp van de point & dick interface worden benaderd. Hiervoor zijn naast de standaard formulieren van de user interface van PMshell een aantal specifieke LEAFO formulieren toegevoegd. Hiermee zijn de bezwaren tegen de user interface van de oude LEAFO editor, waarbij de

13 93-BI-R1227 december datastructuur van het LEAFO domein teveel zichtbaar was, grotendeels verholpen. 3.4 Grafische terugkoppeling Een van de grote nadelen van de oude LEAFO editor was dat eventuele fouten in een LEAFO pas aan het licht kwamen bij het gebruik van de LEAFO in een CAD systeem. De slag van uitproberen en verbeteren duurde veel te lang en het uitproberen van sub- LEAFOs binnen een complexe LEAFO was al helemaal niet mogelijk. Om hier een oplossing voor te vinden is een voorstudie gemaakt naar de mogelijkheden van een grafische terugkoppeling van een LEAFO tijdens het ontwerpen. Voor een beschrijving van deze voorstudie wordt verwezen naar het rapport [BOENDER&LUIJTEN- 93]. Omdat een van de oplossingen die in dit rapport worden beschreven binnen korte tijd kon worden gerealiseerd is deze mogelijkheid toegevoegd aan de LEAFO editor. Hierdoor is het mogelijk om tijdens het ontwerpen van een complexe LEAFO een willekeurige sub- LEAFO in de decompositie structuur te selecteren en een preview te bekijken. 3.5 Hergebruik damwand voorbeeld Met de oude LEAFO editor is een LEAFO voor een damwand ontwikkeld (zie figuur 1). Deze LEAFO is dermate complex dat het opnieuw invoeren van deze LEAFO in de nieuwe LEAFO editor een hoop werk en fouten zou hebben opgeleverd. Doordat PMshell (en dus de LEAFO editor) de mogelijkheid biedt om STEP physical files van modellen met een iets afwijkende structuur in te lezen was het mogelijk om het oude model van de LEAFO voor een damwand in te lezen in de nieuwe LEAFO editor. Figuur 1: Hidden-line representatie van damwand LEAFO

14 93-BI-R1227 december 1993 IH Het enige dat nog gedaan moest worden was het met de hand naar Aut0LISP vertalen van de expressies die als DAL strings waren opgeslagen. Daarna konden ze als neutrale expressies worden opgeslagen. Met het nieuwe model van de LEAFO voor een damwand kan nu zowel voor Dimension III als Aut0CAD een procedurele beschrijving worden gegenereerd. 3.6 Mogelijke verbeteringen/uitbreidingen Een aantal zaken zijn in de nieuwe LEAFO editor nog niet gerealiseerd: - Stuklijst generatie: De LEAFO's die handmatig, onder Dimension III, zijn gedefinieerd (zonder toepassing van de LEAFO editor) bieden de mogelijkheid om informatie op te slaan bij de onderdelen van een LEAFO. Hiermee kunnen stuklijsten worden gegenereerd. Deze functionaliteit is ingebouwd in het LDP onder Dimension III. In principe kan de LEAFO editor hiervan gebruik maken. Aangezien deze functionaliteit nog niet in de LDP versie voor Aut0CAD beschikbaar is wordt deze mogelijkheid in de huidige versie van de LEAFO editor nog niet ondersteund. - Meerdere detailniveaus: Het is momenteel nog niet mogelijk gebruik te maken van meerdere detail niveaus in LEAFO's die met behulp van de LEAFO editor zijn opgebouwd. De LDP routines voor het genereren van standaard geometrie (lfbox, lfsph, lflne,...) dienen daartoe eerst zodanig uitgebreid te worden dat deze functionaliteit robuust ondersteund wordt. Ondersteunen de LDP routines deze functionaliteit dan is het mogelijk de LEAFO editor zo aan te passen dat, tijdens generatie van CAD systeem specifieke LEAFO definities (momenteel DAL of AutoLISP), een extra standaard detail niveau variabele per LEAFO wordt meegegeven. Na aanpassing van de LEAFO editor kunnen al gedefinieerde LEAFO's direct gebruik maken van deze extra functionaliteit. Zij dienen echter wel, per gewenst CAD systeem, opnieuw uitgegenereerd te worden (DAL- of Aut0LISP code).

15 93-BI-R 1227 december [Zilr.]. -* * \' \ Orientation Pnmary 0V. Secundary 0V. -Y y -Y y (list Canc Figuur 2 Oriëntatie vectoren definitie - Definitie oriëntatie vectoren: In vrijwel 99 van 100 gevallen worden de primaire- en secundaire oriëntatie vectoren gedefinieerd langs een van de x-, y- of z-assen De user interface zou sterk verbeteren wanneer de gebruiker op eenvoudiger wijze deze as-evenwijdige oriëntatie vectoren kan definiëren. Wij denken hierbij aan het per oriëntatie vector (primair/secundair) beschikbaar stellen van een speciaal invoer veld (zie figuur 2) waarin de positieve- en negatieve x-, y-, en z-assen weergegeven zijn. De gebruiker kan een van deze richtingen via een muisklik selecteren zodat de bijbehorende string-expressie (bijv. (list 1 0 0)) automatisch aangepast wordt. In het speciale invoer veld kan de geselecteerde as dan highlighted weergegeven worden.

16 93-BI-R1227 december CONCLUSIES EN AANBEVELINGEN Koppeling van de LEAFO editor met Aut0CAD is goed mogelijk gebleken. Er zijn echter wel enige aanpassingenluitbreidingen nodig om de Neutrale Interface volledig te kunnen ondersteunen. Voor het bepalen van bijvoorbeeld het startpunt van een lijn en het intersectie punt tussen twee elementen moest speciale code geschreven worden. De gebruiker moet overigens bij deze oplossingen een helpende hand bieden door aan te geven in welk gebied het startpunt resp. het intersectiepunt zich bevindt. Ter vergelijking, binnen Dimension III zijn voor deze functionaliteiten uitgebreide routines aanwezig die het zonder interactie van de gebruiker af kunnen. Dankzij de nieuwe C++ versie van PMshell is de LEAFO editor nu te porten naar andere UNIX platforms zoals o.a. IRIX (UNIX van Silicon Graphics) en Linux (een public domain UNIX). Neutrale expressies worden binnen de LEAFO editor als Aut0LISP expressies gedefinieerd. Van hieruit vindt vertaling plaats naar de overige CAD systeem afhankelijke modelleertalen. Expressies worden door een parser gecontroleerd op syntax fouten en het gebruik van bestaande variabelen. Grafische terugkoppeling is op goedkope en aanvaardbare wijze mogelijk door gebruik te maken van de nu bestaande 'koppeling met Aut0CAD [BOENDER&LUTJTEN-93]. Deze vorm van grafische terugkoppeling is overigens al in deze versie van de LEAFO editor opgenomen! Wij zien echter wel een toekomstbeeld waar de LEAFO editor gegroeid is richting een systeem als het experimentele pakket GeoNode [EMMERIK-90]. De LEAFO editor zou toegepast kunnen worden bij het samenstellen van een bibliotheek van veel gebruikte standaard onderdelen. Dit heeft als voordeel dat de editor intensief gebruikt zal worden en dat eventuele mankementen/onvolkomenhederi in een vroeg stadium opgevangen kunnen worden. Uit de praktijkervaringen kan blijken dat de set van ondersteunde geometrische primitieven met wat meer complexe types moet worden uitgebreid. Om dit goed te kunnen ondersteunen bevelen wij tevens aan hiertoe een goed plan op te stellen en de nodige voorzieningen om het in de praktijk te brengen en voor het plegen van zowel service als onderhoud.

17 93-BI-R1227 december Voordat potentiële gebruikers de nieuwe LEAFO editor intensief gaan toepassen is het aan te raden handleidingen samen te stellen en inleidende cursussen te organiseren. Daarna willen wij met name de praktische toepassing van de LEAFO editor aanbevelen, te denken valt aan één of meer 'gewenste LEAFO's. Er zal in deze fase wel een duidelijke keuze moeten worden gemaakt welke personen deze taak op zich nemen daar een goed begrip van wat men onder LEAFO's moet bestaan belangrijk is. Zij moeten tevens in staat zijn gerichte op- en/of aanmerkingen te leveren op de huidige versie zodat de applicatie met hun ervaringen en wensen kan meegroeien. De LEAFO editor is zeker nog op het gebied van gebruikers interactie verder uit te breiden/verbeteren. Op de langere termijn zou gekeken kunnen worden naar systemen zoals bijvoorbeeld GeoNode [EMMERIK-90] om van de LEAFO editor een systeem te maken dat naadloos aansluit op de denkwereld van de gebruikers.

18 93-BI-R 1227 december LITERATUUR [KUIPER-89a] Kuiper, P, M.J.G.M. van Emmerik, P.H. Willems, Onderzoek LEAFO's, TNO-Bouw, afd. Bouwinformatica, Rijswijk, februari 1990, B [KUWER-89b] Kuiper, P., Samenvatting Onderzoek LEAFO's, TNO- Bouw, afd. Bouwinformatica, Rijswijk, oktober 1989, B [EMMERIK-90} M.J.G.M. van Emmerik, Interactive design of paramet- erized 3D models by direct man ipulation, Delft University Press, Delft, oktober 1990, ISBN /CIP [BOENDER&LUIJTEN-92] M.R. Boender, B.F.M. Luijten, CAD neutrale LEAFO editor, TNO-Bouw, afd. Bouwinformatica, Rij swijk, november 1992, B [BOENDER&LUTJTEN-93] M.R. Boender, B.F.M. Luijten, CAD neutrale LEAFO editor - Voorstudie grafische terugkoppeling, TNO-Bouw, afd. Bouwinformatica, Rij swijk, november 1993, 93-BI-R 1228

19 93-BI-R 1227 december BIJLAGE A: SUBMODEL ELEMENT BESCHRIJVINGEN

20 TNO-rapporl 93-BI-R 1227 december 1993 Er1 Geleiderail Standaard Element - Stijl bouwdienst, rijkswaterstaat Naam: STIJL Omschrijving: Stijl voor een geleiderail Materiaal: Roestvrij staal Maatvoering in: millimeters Routinenaarn: Parameters: LFSTDSTIJL geen. Type: Submodel J 150 S S 60

21 93-BI-R 1227 december Geleiderail Standaard Element Voetpiaat bouwdienst, rijkswaterstaat Naam: VOETPLAAT Omschrijving: Voetpiaat voor een stijl Materiaal: Roestvrij staal Maatvoering in: millimeters Routinenaam: Parameters: LFSTDVOETPLAAT geen. Submodel S

22 93-BI-R 1227 december Damwand Standaard Element Ankerstoel bouwdienst, rijkswaterstaat Naam: ANKERSTOEL Omschrijving: Ankerstoel voor een ankerstang met een bepaalde diameter. De volgende diarneters zijn in de bibliotheek ondergebracht: 5, 10, 15, 20, 25, 30, 35, 40, 45, 50 Materiaal: Roestvrij staal Maatvoering in: millimeters Routinenaam: Parameters: LFSTDASTOEL Diameter (value) Type: Submodel S IN r(s 50

23 il s TNO-rapport 93-BI-R 1227 december 1993 IIJ Damwand Standaard Element Moer bouwdienst, rijkswaterstaat Naam: MOER Omschrijving: Moer voor een ankerstang met een bepaalde diameter. De volgende diaineters zijn in de bibliotheek ondergebracht: 5, 10, 15, 20, 25, 30, 35, 40, 45, 50 Materiaal: Roestvrij staal Maatvoering in: millimeters Routinenaam: Parameters: LFSTDMOER Diameter (value) Type: Submodel 250.' ) 751 L t ii

24 93-BI-R 1227 december 1993 Damwand Standaard Element Stoelpiaat bouwdienst, rijkswaterstaat Naam: STOELPLAAT Omschrijving: Stoelpiaat voor een ankerstang met een bepaalde diameter. De volgende diaineters zijn in de bibliotheek ondergebracht: 5, 10, 15, 20, 25, 30, 35, 40, 45, 50 Materiaal: Roestvrij staal Maatvoering in: millimeters Routinenaam: Parameters: LFSTDSTOELP Diameter (value) Type: Submodel ) r IP 50 25

25 93-BI-R1227 december BIJLAGE B : PROFIEL ELEMENT BESCHRIJVINGEN

26 93-BI-RI 227 december Geleiderail Standaard Element bouwdienst, rijkswaterstaat Naam: RAIL Omschrijving: Rail voor een geleiderail Materiaal: Roestvrij staal Maatvoering in: millimeters Routinenaarn: Pararneters: LFSTDRAIL Lengte (value) Type: Prof iel Reff 80