Beiträge: 189
Registriert: 27.10.2004

erstellt am: 09. Nov. 2004 13:17      <-- editieren / zitieren -->      Unities abgeben: 

ich kann Deine Meinung gut verstehen und toleriere das auch. In Deiner Situation würde ich genauso denken und handeln. Ich werde dann eben alleine probieren müssen, das Konzept hinzubekommen, aber so richtig weiß ich noch nicht, wie ich das schaffen soll. Naja...

Habe trotzdem mal noch eine Frage:
Bei der Programmierung der automatisierten Mastzusammensetzung benötige ich wohl definitiv eine Datenbank? Ohne die würde das nicht gehen, oder? Ich muß das wissen, um mein Konzept fortführen zu können. Holger gab mir den Ratschlag, alle Bauteile zu katalogisieren und von denen die technischen Eigenschaften zu ermitteln, die zur eindeutigen Zuordnung einer Bauteildatei notwendig sind. Diese Eigenschaften soll ich in eine Datenbank einarbeiten, um über diese Datenbankeinträge auf die Dateien zugreifen zu können. So seine Meinung. Wie siehst Du das? Gäbe es Alternativen zu einer Datenbank?

Und dann habe ich mal noch eine Frage zu Blöcken - wie so oft schon:-)

gehe mal davon aus, daß ich eine Zeichnung habe, die nur einen Block enthält. Wie komme ich an Informationen über diesen Block heran? Und vor allem interessiert mich, was mit diesen Informationen geschieht, wenn ich Änderungen am Block vornehme.

Beiträge: 1250
Registriert: 20.05.2002

erstellt am: 09. Nov. 2004 12:03      <-- editieren / zitieren -->      Unities abgeben: 

Gruß, Axel Strube-Zettler

Beiträge: 189
Registriert: 27.10.2004

erstellt am: 09. Nov. 2004 11:49      <-- editieren / zitieren -->      Unities abgeben: 

ich kann Dich schon verstehen, dass Du das nicht unentgeltlich machen willst. Wenn ich an Deiner Stelle wäre, würde ich genauso denken.

Aber ein paar kleine Tipps sind ja sicher immer drin, oder?

MfG

Kiltswitch

Zitat:

---

Original erstellt von Brischke:
Hallo kiltswitch,

sicher kann dir Axel und/oder ich (landet eh im selben Topf) weiter helfen. Nur hier, muss ich ganz ehrlich sagen, hat das Forum seine Grenzen.
Denn hier geht es dann wieder um die Erstellung des Konzeptes selbst. Der Aufwand, der dort reingesteckt werden muss, kostet. Nach meiner Einschätzung ca. 20-30% der Gesamtkosten (geschätzt ca 1 Entwickler 1 Jahr). Diesen Aufwand hier für Low zu erbringen, funktioniert nicht
a) weil dazu wirklich Fachgespräche vor Ort notwendig sind, die tatsächliche Kosten verursachen
b) ich nicht gewillt bin, hier eine Dienstleistung im Werte von mehreren 1000,-€ unentgeldlich zu erbringen.

Besonders b) möchte ich auch begründen. Steht das Konzept, dann kann im Grunde jeder das Programm erstellen, was dann fast nur noch Fleißarbeit ist.

Grüße Holger

---

Beiträge: 2999
Registriert: 17.05.2001

erstellt am: 09. Nov. 2004 11:40      <-- editieren / zitieren -->      Unities abgeben: 

sicher kann dir Axel und/oder ich (landet eh im selben Topf) weiter helfen. Nur hier, muss ich ganz ehrlich sagen, hat das Forum seine Grenzen.
Denn hier geht es dann wieder um die Erstellung des Konzeptes selbst. Der Aufwand, der dort reingesteckt werden muss, kostet. Nach meiner Einschätzung ca. 20-30% der Gesamtkosten (geschätzt ca 1 Entwickler 1 Jahr). Diesen Aufwand hier für Low zu erbringen, funktioniert nicht
a) weil dazu wirklich Fachgespräche vor Ort notwendig sind, die tatsächliche Kosten verursachen
b) ich nicht gewillt bin, hier eine Dienstleistung im Werte von mehreren 1000,-€ unentgeldlich zu erbringen.

Besonders b) möchte ich auch begründen. Steht das Konzept, dann kann im Grunde jeder das Programm erstellen, was dann fast nur noch Fleißarbeit ist.

Grüße Holger

Beiträge: 189
Registriert: 27.10.2004

erstellt am: 09. Nov. 2004 08:29      <-- editieren / zitieren -->      Unities abgeben: 

Ich weiß nicht, wie genau Du das mit meiner Aufgabe hier im Forum verfolgt hast, also nochmal:

mein Unternehmen plant und errichtet Mobilfunkmasten. Die werden in AutoCAD konstruiert. Die Konstrukteure setzen diese Masten in AutoCAD aus einzelnen Blöcken zusammen, welche in einem Bauteilkatalog abgelegt sind.

Meine Aufgabe ist es, ein Konzept für einen Mastkonfigurator zu entwickeln. Und zwar mit folgenden Zielen:

1. Automatisierte Zusammensetzung des Mastes aus seinen Einzelteilen
2. späteres Einfügen / Löschen / Austauschen von Bauteilen ermöglichen
3. Kontrolle bei Änderungen des Mastes (z.B. Verdrehen oder
  Verschieben des Mastes) u. - falls notwendig - automatische
  Abänderung - bspw. der Antennenposition an den Halterungen

Diese drei Ziele liegen vor und ich soll nun ein Konzept entwickeln, wie das funktionieren könnte. Beginnen will ich natürlich bei der Mastzusammensetzung. Wie kann ich eine Automatisierung hinbekommen, die meinen Mast zusammensetzt? Das wäre schon mal der erste Schritt, aber die anderen beiden Ziele sind auchwichtig - besonders 3.!
Die Antennen haben eine ganz bestimmte Ausrichtung (Strahlbereich) und sind an Halterungen am Mast angebracht. Wird nun bspw. der Mast gedreht (aber nur der Mast - die Antennenstrahlrichtung bleibt konstant!!), dann muß kontrolliert werden, ob die Antennen an ihren alten Halterungen bleiben können. Wegen ihrem Schwenkbereich. Verstehst Du, was ich meine?

Das war ganz grob erklärt, was mein Unternehmen will. Vielleicht kannst Du mir ja weiterhelfen.

Beiträge: 189
Registriert: 27.10.2004

erstellt am: 09. Nov. 2004 08:11      <-- editieren / zitieren -->      Unities abgeben: 

erstmal Danke für Dein langes Statement. Da ich nicht so wissend bin wie Du, muß ich die Argumente und Meinungen so hinnehmen und ich denke auch, dass Du sicher damit Recht hast.

LISP, VB(A) und andere Plattformen hin oder her:

Mein Unternehmen möchte möglichst eine Lösung direkt in AutoCAD haben. Meine Aufgabe besteht darin, herauszufinden, wie das mit dem Mastkonfigurator funktioniert. D.h. ich soll ein Konzept aufstellen, dazu einen Programablaufplan entwickeln (das Programm ist nicht komplett zu entwickeln) und man hätte noch gern ein kleines Beispielprogramm, wo man sieht, dass es auch wirklich funktioniert.
Das ist also meine Aufgabe. Aber ich komme an dem Punkt Konzepterstellung irgendwie einfach gerade nicht weiter. Da mir das Programmierwissen fehlt (also was es für Möglichkeiten gibt) und ich auch in AutoCAD nur "Grundwissen" habe (noch nie mit LISP oder VBA was am Hut hatte, sondern AutoCAD immer nur normal zum konstruieren nutzte), befinde ich mich gerade wie in einer Sackgasse.

Ich bin wirklich auf professionelle Hilfe angewiesen. Ich bräuchte jemand, dem ich sage, was ich will und der mich sozusagen "an der Hand nimmt" und mich durch das Programmierland lotst.

Beiträge: 1250
Registriert: 20.05.2002

erstellt am: 08. Nov. 2004 21:37      <-- editieren / zitieren -->      Unities abgeben: 

Eines vorweg, damit nichts in den falschen Hals gerät: Nimm bitte nichts persönlich, wenn ich von Qualifikation usw. rede. Du bist nach deinen Aussagen selbst überfordert, und das muss man auch ganz klar in die Überlegungen einbeziehen. Mit anderen Worten: Das Halbwissen eines Praktikanten in einer Programmiersprache kann doch nicht ausschlaggebend für die Auswahl der Sprache für ein komplexeres Softwareprojekt sein, oder?

Ich denke, Lisp von Grund auf zu lernen, ist für dich nicht mehr Aufwand, als dein VBA-Wissen bis zur 'Profistufe' auszubauen. Lisp hat nun mal eine klare, sehr einfache Syntax, während VB(A) ein riesiges Sammelsurium von Ausnahmen, Sonderfällen und langen Listen von Schlüsselwörtern ist. Selbst MS selbst in nicht in der Lage, mal eine Liste aller Keywords herauszubringen.

Lisp hat, was die Effizienz betrifft, deutliche Vorteile - Code wird in VBA i.d.R. etwa 5 mal so lang wie in Lisp. Und auch das, was ich unter dem Stichwort Resourcen angedeutet habe, spielt eine große Rolle: Für viele Detailprobleme, die du haben wirst, findest du hier bei cad.de und überall im Netz mehr oder weniger fertige Lisp-Lösungen im Netz - allerdings wirst du da das Unterscheiden zwischen guten und schechten bis extrem schlechten Lösungen lernen müssen. Komplettlösungen in VBA wirst du allerdings suchen müssen, das meiste spielt sich auf einem _deutlich_ niedrigeren Niveau ab. Komplettlösungen zu einem Thema in VBA habe ich bisher eigentlich gar keine im Netz gesehen.

Der Nachteil von Lisp liegt ganz klar bei den Dialogen: Während man VBA-Dialoge als "Stand von 1999" bezeichnen kann, ist das, was du in Lisp zusammenzimmern kannst, eindeutig nochmal rund 10 Jahre älter - nicht mal eine Combobox kriegst du da hin. Das ist von der Funktionalität her der Stand von Windows 2.0 (falls das überhaupt jemand schon mal gesehen hat;-)))!

Deutlich die Nase vorn hat Lisp da, wo es um geometrische Berechnungen sowie Erzeugen und Modifikation von Geometrie hat - alles, was (AutoCAD betreffend) in VBA geht, funktioniert in Lisp auch, da beide Sprachen auf die gleichen ActiveX-Methoden zugreifen können, aber in Lisp hast du zusätzlich alle anderen Möglichkeiten (Stichwort Gruppencodes) einschl. der simplen, aber immer noch sehr effektiven Command-Programmierung.

Und jetzt das große ABER: Beide Sprachen sind eigentlich nur noch lebende Leichname. VBA und das zu Grunde liegende VB6 wurden schon vor 2 Jahren vom Nachfolger VB.NET abgelöst, ein VBA.NET ist aber nicht in Sicht. VB6/VBA setzt vollständig auf COM auf, und COM wird in zukünftigen Windows-Versionen keine Rolle mehr spielen. VisualLisp wurde von AutoDesk vor einigen Jahren zugekauft und ersetzt das bis dahin vorhandene AutoLisp. Durch diesen Zukauf wurde Lisp durch Zugriff auf COM erweitert (und ein paar Neuerungen wurden auch eingeführt). Fällt COM demnächst weg, könnte AutoDesk eigentlich wieder das alte AutoLisp einbauen - das kann man ja auch nicht gerade als Fortschritt bezeichnen.

Jedenfalls entwickeln sich weder VBA noch VisualLisp noch irgendwie weiter, und niemand weiss, was damit passiert, wenn COM dann wirklich verschwindet. Kann sein, dass COM in vier Jahren verschwunden ist, kann auch sein, dass es als Legacy auch noch in 10 Jahren da ist. Wer weiss? Alte DOS-Programme laufen ja auch noch... Um dein Wissen hier zu vertiefen, solltest du einfach mal ein bisschen im Autodesk.NET-Forum lesen - aber Vorsicht: Das ist hartes Brot.

Man könnte nun meinen, dass ich hier irgendwas verwechselt habe: Deine Frage war ja eigentlich nur, wie man in VBA auf Blöcke zugreift, und ich schreibe hier eher über ein Software-Projekt, an dem ein Team über Jahre hinweg entwickelt. Ich denke einfach, das ist es auch (und auch Holger Brischke sieht das so). Ich habe schon genug solche Konfiguratoren gesehen: Da wird immer jahrelang daran entwickelt, und wenn sie zu zwei Dritteln fertig sind, wird von vorne angefangen, weil man auf die falschen Pferde gesetzt hat.

Ein falsches Pferd ist da für mich AutoCAD: Das ist ein Werkzeug, mit dem man Fertigungszeichnungen usw. machen kann oder auch Häuser planen, Landkarten erstellen usw. Bisher ist jder Produkt-Konfigurator, den ich erlebt habe, irgendwann bei Fragen angekommen "Warum muss man AutoCAD haben, um das zu benutzen? Wir können doch nicht alle Außendienstler mit AutoCAD ausrüsten..."

Keine Ahnung, ob es bei euch einen Außendienst gibt, der Masten verkauft - aber die Deutsche Bundespost seid ihr doch auch nicht, und die Zeiten, wo alles zentral geplant wurde, sind doch vorbei. Also wird es auch bei euch ein "Will nur mal sehen, ob das geht und was es kostet" geben. Deshalb mein Ansatz in den Phasenvorschlägen: prüfen, ob nicht eine Browser-Applikation sinnvoller ist, als gleich in AutoCAD Fertigungszeichnungen zu erzeugen. Vielleicht nicht doch erst eine Machbarkeitsprüfung mit Bild und Preis als Verkaufsargumente im IE oder Mozilla? Und wenn das Ding beschlossen/verkauft ist, die Daten an AutoCAD senden? 

Ich denke, das reicht erstmal jetzt... ich will dir ja helfen und dich nicht in die nächste Gummizelle treiben;-)

Gruß, Axel Strube-Zettler

Beiträge: 189
Registriert: 27.10.2004

erstellt am: 08. Nov. 2004 14:53      <-- editieren / zitieren -->      Unities abgeben: 

Und Du meinst also, mit LISP kann man das meiste besser umsetzen als mit VBA? Dann muß ich mir darüber ja auch mal noch Gedanken machen, ob vielleicht die Nutzung von LISP sinnvoll wäre.

Aber zunächst mal Danke für Deine Phasen.

Beiträge: 1250
Registriert: 20.05.2002

erstellt am: 08. Nov. 2004 14:45      <-- editieren / zitieren -->      Unities abgeben: 

Phase I

1. Verfassen eines Exposés, in dem die Software in Grundzügen beschrieben wird. Was soll sie können und leisten, wer soll sie einsetzen, auf welchen Plätzen, LAN oder WAN...

2. Zusammenstellen der Möglichkeiten, wie die Ziele erreicht werden können: Als Browser-Applikation im WWW, als AutoCAD-Applikation auf lokalen Plätzen usw. usf.

3. Sollen Daten erfasst werden, und wenn ja wie? Wie sieht es mit der Auswahl der Teile aus? Zentrale Datenbank oder alles dezentral?

Phase II

Wenn in I Entscheidungen getroffen sind, kann man:

1. die technischen Möglichkeiten zusammentragen (Software, auf der man aufsetzen könnte, OS, mögliche Programmiersprachen usw.)

2. das Für und Wider einzelner Techniken diskutieren

3. Ein paar wichtige Pseudo-Dialoge zusammenschieben (mit Visio oder ähnlichen Mitteln) und den Mitarbeitern vorlegen, die später damit arbeiten sollen

4. die vorhandenen Resourcen abschätzen

5. eine grobe Kosten/Nutzen-Analyse durchführen

Phase III

1. Festlegen der verwendeten Techniken (Software, Sprachen usw.)

2. Exaktere Kosten-/Nutzenanalyse

3. Erstellen eines Pflichtenheftes

Phase IV

1. Codieren nach Pflichtenheft

Phase V

1. Qualitätssicherung

Phase VI

1. Dokumentationserstellung

2. Installation + Einweisung

Was dein Chef dir jetzt empfiehlt, fällt also hauptsächlich unter II/4.

Mit Gruppencodes hast du übrigens in VBA nichts zu tun, die ActiveX-Methoden haben deskriptive Namen. Vielleicht war den Hinweis auf die GCs aber so gemeint, dass du auf Lisp umsteigen solltest. Da würde ich auch ernsthaft drüber nachdenken, weil die Programmierung wesentlich effizienter ist und dir auch wesentlich mehr Knowledge-Resourcen zur Verfügung stehen.

Gruß, Axel Strube-Zettler

Beiträge: 189
Registriert: 27.10.2004