---

Hallo zusammen,

hat bitte jemand einen Tipp für mich?

Ich möchte alle Konfigurationen in einer Baugruppe weghaben

Wenn ich aufzeichne bekomme ich

Code:

---

cfn_delete_configuration
:FULL_NAME :START_NAME "/Testbaugruppe_AS" :CONFIGURATION "Konfig1" :END_NAME

---

Leider finde ich nichts geneueres zu cfn_delete_configuration
In der Online-Referenz steht nichts von den Schlüsselwörtern 

Auch bereits das wählen der Konfigurationen will nicht hinhauen

Code:

---

(setf ObjekteZumLoeschen  (sd-call-cmds (get_selection :focus_type  *sd-configuration-seltype*  :select :recursive :in_assembly Baugruppe)))

---

ObjekteZumLoeschen bringt mir nil  obwohl in der Baugruppe definitiv Konfigurationen drin sind...

Hintergrund:

Ich möchte mit "Baum schreiben" die Strukturliste ausgeben. Vorher aber unrelevante Objekte (Ansichtssätze, Behälter, Konfigurationen, Kindelemente von untrennbaren, ...) raushaben. Diese stehen sonst mit in der Baumstruktur.

------------------
...viele Grüße
Stephan

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von StephanWörz:
Ich möchte alle Konfigurationen in einer Baugruppe weghaben

Leider finde ich nichts geneueres zu cfn_delete_configuration
In der Online-Referenz steht nichts von den Schlüsselwörtern

---

http://osd.cad.de/tricks_05.htm  ..  kennste vermutlich .. 

In der Online-Referenz steht es schon richtig drin. Es braucht keine 'Schlüsselworte'. Stell dir einen sequential Dialog vor, der nur diese eine Selektions-Variable mit dem sel-type *sd-configuration-seltype* hat.  Also: selektion + ab in die OK-action, oder after-input bei sequential-LOOP (wo der kram dann eben gelöscht wird)

Wenn du mal nur cfn_delete_configuration via command line aufrufst, siehst du auch am Prompt-text das nur nach Konfigurations gefragt wird (am einfachsten kann man dann auch dem Prompt-text entnehmen ob das Kommando single- oder multiple-selektion verträgt).

Für eine evtl. Antwort meinerseits auf dein get_selection musst du noch auf 🌨️ oder 🌦 oder  🌥️ oder 🌥 warten ..   🙃

------------------
● Firefox ESR ● Java Forum Stuttgart JUGS ● OSD Hilfeseite (de) / help page (en) ● NotePad++ ● BuFDi ●

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

noch scheint die Sonne, aber mein Essen ist noch nicht essbar... 

Ich habe eine leicht verschachtelte Baugruppe unterhalb von root: 

* a001
** a001/a003
*** a001/a003  config1   = :FULL_NAME :START_NAME "/a001/a003" :CONFIGURATION "config1" :END_NAME

Wenn ich den delete cfn aufrufe und dann auch das 'select' Icon in der Toolbar ist die Befehls sequence wie folgt:

Code:

---

cfn_delete_configuration
:in_assembly_additives "/a001"

---

error: Nothing grouped below the selected item

Code:

---

cfn_delete_configuration
:in_assembly_additives "/a001/a003"

---

;; schwubs ist die Config weg.

Vermutung. Eine Konfig ist kein 3D Object, sondern ein Named Feature. Letztere können aber wohl (scheinbar) nicht mit dem standard selector und 'recursive' 'erreicht' werden. Und daher auch nicht via get_selection?

Das folgende funktioniert NICHT:

Code:

---

(setf ObjekteZumLoeschen  (getres (oli::get_selection :focus_type  oli::*sd-configuration-seltype*
  :select :RECURSIVE :in_assembly (oli::sd-pathname-to-obj "/a001"))))

---

Das folgende funktioniert

Code:

---

(setf ObjekteZumLoeschen  (getres (oli::get_selection :focus_type  oli::*sd-configuration-seltype*
  :select :in_assembly (oli::sd-pathname-to-obj "/a001/a003"))))
returns: (#S(ELAN::SEL_ITEM ELAN::PATH ....  #S(CFN::CONFIGURATION DSM::SIM ...)

---

nimm doch einfach: (defun sd-get-all-configs-in-object (obj) .... )

Oder lange Rede kurzer Unsinn:  (sd-inq-configurations :OWNER owner) ala IKIT!

Code:

---

(oli::sd-inq-configurations :OWNER (oli::sd-pathname-to-obj "/"))  => nil   😖

---

Also so:

Code:

---

(setf ObjekteZumLoeschen
  (apply 'nconc
    (mapcar '(lambda (a) (oli::sd-inq-configurations :OWNER a))
      (remove-duplicates
        (getres (oli::get_selection :focus_type  oli::*sd-assembly-seltype*
          :select :recursive :in_assembly (oli::sd-pathname-to-obj "/")))
        :test #'equal :key #'oli::sd-inq-obj-contents-sysid))))

---

Wir selektieren alle assemblies (unterhalb vom StartObject), entfernen shared instances, wenden auf die verbleibenden Baugruppen die IKIT Funktion sd-inq-configurations an und machen daraus eine 'platte' Liste. (den obigen code von unten nach oben lesen)

wie immer: .. hier mit "oli::"  zum Ausprobieren auf der Modeling Command line.

------------------
● Firefox ESR ● Java Forum Stuttgart JUGS ● OSD Hilfeseite (de) / help page (en) ● NotePad++ ● BuFDi ●

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hey Wolfgang,

vielen Dank für Deine Anteilnahme. Werde mich nun mal darüber hermachen und schauen was ich daraus gebastelt bekomme...

------------------
...viele Grüße
Stephan

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Ganz steig ich da nicht durch,

wenn ich das Ganze mal ausgeben lasse

Code:

---

(mapcar '(lambda (a) (display (format nil "Konfig-Objekte zum löschen: ~A" (sd-inq-obj-pathname a))))   
  (apply 'nconc
    (mapcar '(lambda (a) (oli::sd-inq-configurations :OWNER a))       
      (remove-duplicates         
        (getres (oli::get_selection :focus_type  oli::*sd-assembly-seltype*           
                :select :recursive :in_assembly (oli::sd-pathname-to-obj "/")))         
      :test #'equal :key #'oli::sd-inq-obj-contents-sysid))))

---

Bekomme ich die Pathnames der Baugruppen - keine Konfigurationen

und noch eine Frage: Warum

Code:

---

(remove-duplicates...

---

------------------
...viele Grüße
Stephan

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von StephanWörz:
wenn ich das Ganze mal ausgeben lasse

Code:

---

(mapcar '(lambda (a) (display (format nil "Konfig-Objekte zum löschen: ~A" (sd-inq-obj-pathname a))))...

---

und noch eine Frage: Warum

Code:

---

(remove-duplicates...

---

---

eine Konfig ist eine Konfig und kein Object mit einem 3D-obj-Pathname.

in meinem obigen Beipspiel

Code:

---

(setq a3 (oli::sd-pathname-to-obj "/a001/a003"))
(setq a3cfg (oli::sd-inq-configurations :OWNER a3))
(pprint a3cfg)  ;; eine liste mit einer config drin
(pprint (oli::sd-inq-obj-pathname (car a3cfg))) ;; upsss

(pprint (oli::sd-inq-elem-name (car a3cfg))) ;; ahaaa

---

Warum trace'd Du bei deinem Beispiel Aufruf nicht mal alle relevanten interessanten Funktionen? vor allem die wichtigste: sd-inq-configurations

Das mal soweit als Denk 🤔 Anstoss.

Meinen obigen 6 Zeiler kann man auch mit 4 setq's durchführen (und jeweils printen oder so). Der Reihe nach. Aber das bekommst du alleine hin! -> Tu das!

====================

warum remove-duplicates ?

Stell dir vor du hast die Baugruppe "a003" mit der Config in deiner Machine 135 mal verbaut, also geshared.  Löscht Du die Config dann 135 mal? Nein, Du löschst sie einmal. -- Deswegen werden die Baupruppen direkt reduziert, dann wird sd-inq-configurations nur auch 'einmal' und nicht 135 mal gerufen. Das ist dann schon wieder Performance denke.

Ausserdem müßte sonst Dein nachfolgender Code jedes mal gucken ob die config in "a003" noch da ist oder nicht, das wäre auch blöd diese Prüfung 135 mal zu machen, wovon 134 dann ins Leere laufen.

------------------
● Firefox ESR ● Java Forum Stuttgart JUGS ● OSD Hilfeseite (de) / help page (en) ● NotePad++ ● BuFDi ●

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von der_Wolfgang:

warum remove-duplicates ?

Stell dir vor du hast die Baugruppe "a003" mit der Config in deiner Machine 135 mal verbaut, also geshared.  Löscht Du die Config dann 135 mal? Nein, Du löschst sie einmal. -- Deswegen werden die Baupruppen direkt reduziert, dann wird sd-inq-configurations nur auch 'einmal' und nicht 135 mal gerufen. Das ist dann schon wieder Performance denke.

Ausserdem müßte sonst Dein nachfolgender Code jedes mal gucken ob die config in "a003" noch da ist oder nicht, das wäre auch blöd diese Prüfung 135 mal zu machen, wovon 134 dann ins Leere laufen.

---

AHA    ...das macht Sinn, klaro, eine Änderung (löschen der Konfig) wirkt sich ja auf alle Instanzen der betroffenen Bgr. aus.
Da hab ich wohl zuviel  und zuwenig überlegt...

Vielen Dank mal, den Rest verdaue ich morgen 

------------------
...viele Grüße
Stephan

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von StephanWörz:den Rest verdaue ich morgen  

---

Guten Appetit!  ..  🧆 🍝 🥧🍏 🍒 🧀 🍕

------------------
● Firefox ESR ● Java Forum Stuttgart JUGS ● OSD Hilfeseite (de) / help page (en) ● NotePad++ ● BuFDi ●

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

AS-Browser.png

Hallo,

das hat jetzt alles gut geklappt. Vielen Dank für die Hilfe  

Ich konnte nun die Strukturliste auf die Teile/Bgr. mit Aktor/Sensor-Attribut reduzieren. Die Baugruppenstruktur bleibt erhalten.
Im Browser kennzeichne ich die jeweiligen Objekte mit Farbe & Icon  

Aber: irgendwie kollidiert das Ganze mit einem bereits vorhandenen browser-interrogator - der ursprüngliche lebt jetzt nicht mehr  
auch die anderen Symbole, wie Exemplarkennung, Checkbox zum Ein-/ausblenden (die wir ja brauchen) sind weg??
Ok - wieder zurückgebaut. Da muss ich jetzt mal graben und schauen ob ich eine Lösung finde   die Richtung stimmt  
Vielleicht ist ja ein zusätzlicher Strukturbrowser für die Aktor-Sensor-Ansicht eine Lösung - muss mich mal reinfuchsen.

Das Ziel ist dann auch ein Export dieser bereinigten Struktur in Richtung Excel.
Und mal schauen ob das Ganze in der Datenbank (Phoenix/PDM) nicht noch eleganter geht...

Was mich noch interessiert!

Code:

---

(mapcar '(lambda (a) (cfn_delete_configuration :FULL_NAME :START_NAME (format nil"~A" (sd-inq-obj-pathname a)) :CONFIGURATION (sd-inq-elem-name a) :END_NAME)) KonfigZumLoeschen)

---

Warum muss ich bei sd-inq-obj-pathname den "(format nil..." (ohne gings nicht) verwenden, bei sd-inq-elem-name geht es ohne    Beide liefern lt. Doku einen {STRING} 

...was denn Herren Chefs in Zeiten temporärer Unterauslastung nicht alles einfällt  

------------------
...viele Grüße
Stephan

[Diese Nachricht wurde von StephanWörz am 07. Mai. 2025 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von StephanWörz:
Hallo zusammen,

Hintergrund:

Ich möchte mit "Baum schreiben" die Strukturliste ausgeben. Vorher aber unrelevante Objekte (Ansichtssätze, Behälter, Konfigurationen, Kindelemente von untrennbaren, ...) raushaben. Diese stehen sonst mit in der Baumstruktur.

---

Es gibt doch die Möglichkeit in der Strukturlistenansicht mit den Reitern "Zeigen" und "Objekte" die Behälter und AnsSätze auszublenden. Dann wird der Baum doch übersichtlicher.

------------------
freundliche Grüße
Achim

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von achim96:

Es gibt doch die Möglichkeit in der Strukturlistenansicht mit den Reitern "Zeigen" und "Objekte" die Behälter und AnsSätze auszublenden. Dann wird der Baum doch übersichtlicher.

---

...das hatte ich ja noch gar nicht auf dem Schirm    - das werde ich mal durchleuchten. Ob man das wohl auch programmatisch ein- / ausblenden kann.

Muss mal gucken - vielen Dank für den Hinweis     

------------------
...viele Grüße
Stephan

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von StephanWörz:
das hat jetzt alles gut geklappt. Vielen Dank für die Hilfe    

---

fein! 🙂

Zitat:

---

Aber: irgendwie kollidiert das Ganze mit einem bereits vorhandenen browser-interrogator - der ursprüngliche lebt jetzt nicht mehr

---

Naja wenn Du dir alles mögliche überschreibst!!!  Ist es halt weg.  Ein inq-browser-interrogator gibt es übrigens nicht. Und im Strukturbrowser läuft auch das eine/andere im C-Code ab.

Code:

---

(mapcar '(lambda (a) (cfn_delete_configuration :FULL_NAME :START_NAME (format nil"~A" (sd-inq-obj-pathname a)) :CONFIGURATION (sd-inq-elem-name a) :END_NAME)) KonfigZumLoeschen)

---

Warum machst Du denn den mapcar?
Warum löschst Du einzelen?
Habe ich dich auf den Prompt gestupft oder habe ich dich auf den Prompt gestupft?

"Specify the configuration to delete. Hold SHIFT-key to select MULTIPLE ITEMS."

Aber.  DU hast doch eine Liste von selitems! Warum bastelst Du da erste wieder was string mäßiges daraus?

Code:

---

(cfn_delete_configuration a-sel-item)

---

Fertig ist die Brause --  oder eben, da du ja mehrererere hast:

Code:

---

(cfn_delete_configuration KonfigSSSSSZumLoeschen)

---

Fertig ist die Sause

Aber ich habe da noch andere Fragen...

------------------
● Firefox ESR ● Java Forum Stuttgart JUGS ● OSD Hilfeseite (de) / help page (en) ● NotePad++ ● BuFDi ●

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Aber ich habe da noch andere Fragen...

---

z.B. Wieviele Seiten hat das Pflichtenheft❓

#

#

#

#  setzen

#    lassen

Zitat:

---

Original erstellt von StephanWörz:
Ich möchte alle Konfigurationen in einer Baugruppe weghaben .. Ich möchte mit "Baum schreiben" die Strukturliste ausgeben. Vorher aber unrelevante Objekte (Ansichtssätze, Behälter, Konfigurationen, Kindelemente von untrennbaren, ...) raushaben. Diese stehen sonst mit in der Baumstruktur.

---

Von hinten durchs linke Knie über die Brust in's mittlere Auge .....

Warum vergewaltigst Du den Strukturbrowser um temporär bissle was anzuzeigen, was du anschließend in ein schnödes Ascii File schreiben willst (vermutlich CSV)❓

Der Strukturbrowser enthält immer alles ..  und davon viel. Und ob ein Anwender den 7. Knoten noch entfaltet oder den 4. zusammenklappt, da hast du keinen Einfluss drauf. Aber je nachdem haut 'Baumschreiben' mal mehr mal weniger Ausgaben via  :tree-print-name interrogator in Deine Datei. Wirst Du damit zurecht kommen? - Und die anderen (indirekt) vom Achim genannten Anwender-spezifischen Browser-Einstellungen hauen in die selbe Kerbe. Das gibt ne fette Narbe bei dir!

• Scanne Dein Start Object via sd-inq-obj-children (recursive) ab.
  
• Sammle alles auf was von Interesse ist, der Rest wird ignoriert. z.B. UT-Baugruppen werden nicht via sd-inq-obj-children weiter untersucht.
  
• Alles (positive) aufgesammelte kannst Du in eine Display Table schubsen, die sind einfacher zu handhaben.
  
• Den Inhalt der Tabelle kannst du im ersten Schritt mit dem Goody (load "table_export_dia") direkt in eine CSV schreiben lassen.
  
• Die (Struktur) Verschachtelungstiefe kann man in der Tabelle durch Einrücken des Names mit BLANKS etwas simulieren, Die Tabelle bekommt dann natürlich kein SORT-UI  (:columnSortUI NIL) !
  

Es ist viel schwieriger alles unerwartete aus zu sortieren, als nur das auf zu sammeln, was man haben möchte.  "Dreh dich rum"

ggf. kannst Du statt der Display Table eine Browser-Based Tabelle verwenden. Da kann man dann (AFAIR) auch eigene Grafiken und eigene Farben verwenden.

Beide Ansätze haben den Vorteil, das Anwenderli die Original Struktur sogar parallel sehen kann, ggf. darin navigieren und du musst nicht totundteufel implementieren um den vergewaltigten Strukturbrowser nach 'Deiner' Aktion wieder grund zu sanieren.

------------------
● Firefox ESR ● Java Forum Stuttgart JUGS ● OSD Hilfeseite (de) / help page (en) ● NotePad++ ● BuFDi ●

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Von hinten durchs linke Knie über die Brust in's mittlere Auge .....

---

Aua

Zitat:

---

Warum vergewaltigst Du den Strukturbrowser um temporär bissle was anzuzeigen, was du anschließend in ein schnödes Ascii File schreiben willst (vermutlich CSV)❓.

---

...dachte das wäre eine super Idee 

Zitat:

---

• Scanne Dein Start Object via sd-inq-obj-children (recursive) ab.
  
• Sammle alles auf was von Interesse ist, der Rest wird ignoriert. z.B. UT-Baugruppen werden nicht via sd-inq-obj-children weiter untersucht.
  
• Alles (positive) aufgesammelte kannst Du in eine Display Table schubsen, die sind einfacher zu handhaben.
  
• Den Inhalt der Tabelle kannst du im ersten Schritt mit dem Goody (load "table_export_dia") direkt in eine CSV schreiben lassen.
  
• Die (Struktur) Verschachtelungstiefe kann man in der Tabelle durch Einrücken des Names mit BLANKS etwas simulieren, Die Tabelle bekommt dann natürlich kein SORT-UI  (:columnSortUI NIL) !
  

---

Ohhkeee 

Vielen Dank für die erklärenden Worte. Macht natürlich alles Sinn.
Jetzt schau ich mal wie weit ich nach Deinem Rezept komme...

Zitat:

---

Es ist viel schwieriger alles unerwartete aus zu sortieren, als nur das auf zu sammeln, was man haben möchte.   "Dreh dich rum"

---

Eben passiert - vermutlich aber falsche Drehachse, jetzt steh ich auf'm Kopf 

Zitat:

---

ggf. kannst Du statt der Display Table eine Browser-Based Tabelle verwenden. Da kann man dann (AFAIR) auch eigene Grafiken und eigene Farben verwenden.

---

Noch nie davon gehört, hört sich aber schick an...

Zitat:

---

Beide Ansätze haben den Vorteil, das Anwenderli die Original Struktur sogar parallel sehen kann

---

...das wär's         

Dankeschön für die Unterstützung, mal sehen wo die Reise hingeht...

------------------
...viele Grüße
Stephan

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

noch ein paar Schnipsel:

• Du hast den  :secondary-pixmap interrogator überschrieben, damit sind dann die CheckBoxen für die Viewport Drawlist hinüber. Du hättest also eine KOMBINATION vom Original interrogator und deinen Anpassungen implementieren müssen.

• in der Aktor-Sensor-Ansicht sind ja eh nur reale Teile oder Bauruppen, leztere aber nur untrennbare(?) - Also wäre die Information des Modeling-Objekt-Typ-icons eh 'overflow'

• dür die (simulierte) Struktur Einrückung könnte man in Spalte 1 der Aktor-Sensor-Tabelle mit: (display "└" "└─" "└──" "└────")  arbeiten. Abgeleitet von (setq struc-depth (count #\/ obj-pathname))

• (display "Ⓔ Ⓢ Ⓜ")  als Indicator in Spalte 2 der Aktor-Sensor-Tabelle ( von: https://symbl.cc/en/unicode/blocks/enclosed-alphanumerics/ )
  

------------------
● Firefox ESR ● Java Forum Stuttgart JUGS ● OSD Hilfeseite (de) / help page (en) ● NotePad++ ● BuFDi ●

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

in der Aktor-Sensor-Ansicht sind ja eh nur reale Teile oder Bauruppen, leztere aber nur untrennbare(?)

---

Jein, In der Aktor-Sensor-Ansicht sollte die komplette Struktur erhalten bleiben und zusätzliche alle Teile und Baugruppen (können reale und untrennbare sein) welche das entsprechende Attribut mitbringen. Sonstige Objekte (oder named Features) wie Ansichtensätze, Konfigs, Behälter, Schnittebenen, und was sonst noch rumfährt...,  fallen mir (im Moment) keine ein welche hier eine Rolle spielen könnten...

------------------
...viele Grüße
Stephan

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von StephanWörz:
In der Aktor-Sensor-Ansicht sollte die komplette Struktur erhalten bleiben

---

Okay.  dann verstehe ich deinen Ansatz besser (ohne Vorlage des Pflichtenheftes 😋 )

Lass mal die Darstellung von "Ⓔ Ⓢ Ⓜ" als icon für den Moment weg..

Dann hast Du die Farben und die zusätzlichen Spalten (sensor/aktor .. ) - Hast du schon realisiert!

Jetzt löse dich vom OOTB "Baum Schreiben" ..    sondern schreibe einfach Deinen eigenen Dialog "Export_ASView_to_file" - So erhälst Du viel einfacher die komplette Kontrolle über das was in die Datei geschrieben wird.

Der Dialog bekommt eine Startbaugruppe und einen Dateiname. Ganz schnöder Standard dialog.

Die Startbaugruppe arbeitest du ab wie vorher beschrieben. Für jedes 'positive gefundene' Objekt schreibst ne zeile in die Datei.  - Keine Display Table. Gar nix. 

==>> einfacher Lisp Dialog,

==>> keine Huddelei mit User's Browser Settings.

==>> Export_ASView_to_file hängst du als eigene rechts-Maus-Klick-Aktion in's Kontextmenu

==>> Saubere Trennung von (hübschem) UI und Aktion (= csv schreiben).

Das war Vorschlag Nummer Sieben Beh.  😄

------------------
● Firefox ESR ● Java Forum Stuttgart JUGS ● OSD Hilfeseite (de) / help page (en) ● NotePad++ ● BuFDi ●

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

2025-05-0909_22_41-AktorundSensorListe.docx-Word.png

OK, ein Ansatz der mir gefällt.

Das mit dem Pflichtenheft ist so eine Sache...

Das geht bei uns in etwas so los:

Chef kommt und sagt: "kheedsch's mol gugga obb'de do ebbas naabrengschd..." (nö, Übersetzung kommt nicht mit   )

Es geht im wesentlichen darum ein Dokument für eine Maschine (z.T. 100.000 Teile) zu erzeugen, welche die Baugruppenstruktur abbildet und alle Aktoren, Sensoren und sonstige (über Attribute identifizierbare) Objekte darstellt. Dieses Dokument soll dann von allen beteiligten Gewerken (mech. Konstruktion, El. Konstruktion, Softwareentwicklung) verwendet werden, und mit Fachbereichsspezifischen Informationen ergänzt werden können.
Unsere Teile/Baugruppen/untrennbare Baugruppen sind ggf. mit Attributen

- Aktor (0|E|M|P)
- Sensor (0|1)
- Bus (0|1)
-  …

ausgestattet (diese Objekte nachfolgend (AS) genannt) und können dahingehend identifiziert werden.

Folgendes wird gewünscht:

- Baugruppenstruktur wird abgebildet
- Jedes Exemplar eines AS muss extra aufgeführt werden (...keine Zusammenfassung wie in Pseudoordnern)
- saubere Liste (...sonst nix drin, Modellnamen von (AS) sauber >> Enden mit der 8-stelligen Artikelnummer d.h. keine Zählzeichen aus dem CAD)
- einfaches identifzieren der AS im CAD (Strukturliste farbig, Symbol, Präfix am Modelnamen, ...)
- am Ende eine Exceldatei (Formatierung noch nicht definiert)

Über folgende Hürden bin ich bis jetzt gestolpert:

- selektieren der Konfigurationen (gelöst!! Danke Wolfgang!! 💪 )
- Baugruppen, welche keine AS beinhalten nicht in die Liste (also Struktur nur solange auch AS zu finden sind)
- Baugruppen welche ein bestimmtes anderes Attribut haben nicht in die Liste, auch Kinder nicht weiter untersuchen (bei uns gibt es sog. Pseudobaugruppen, welche auch beim Scannen der BOM nicht berücksichtigt werden)
- Baugruppen mit (AS)-Attribut (Kindelemente sollen in der Liste nicht auftauchen)
- untrennbaren Baugruppen mit (AS)-Attribut (Kindelemente sollen in der Liste nicht auftauchen)
- Bereinigen der Struktur durch entfernen ungewünschter Objekte bedeutet "Schreibzugriff für alles" (Unlock ist kritisch...)
- Browser einfärben (Grundsätzlich klar) aber: Wie kann man verschiedene Interrogatoren verwenden (für DB-Status, für AS-Kennzeichnung)???

Hier noch zur Erklärung:

------------------
...viele Grüße
Stephan

[edit-wolfgang]habe das grosse image ersetzt[/edit] wegen Zeilenumbruch.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von StephanWörz:
Das mit dem Pflichtenheft ist so eine Sache...

Chef kommt und sagt: "kheedsch's mol gugga obb'de do ebbas naabrengschd..."

---

Und zum Timing ist die passende Erwartungshaltung dann: "in zwoi .. drei Schdunda brengschd des scho faschd ferdich, gll?"

------------------
● Firefox ESR ● Java Forum Stuttgart JUGS ● OSD Hilfeseite (de) / help page (en) ● NotePad++ ● BuFDi ●

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

@Stephan du hast per PM einen Prototyp erhalten. (siehe auch die anderen PMs)

Ich denke wir haben uns HIER eh schon arg vom 'Betreff' entfernt und der Rest ist dann eher ein Zwiegespräch.

------------------
● Firefox ESR ● Java Forum Stuttgart JUGS ● OSD Hilfeseite (de) / help page (en) ● NotePad++ ● BuFDi ●

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP