Plattformunabhängiges Diagnosesystem

[RHBaum]

Das Ding wird wachsen... Hört sich hirnrissig an, ist aber so.

Ich kenn einige Projekte wo es auch so ist ...
Aber, für alle diese Projekte halte ich C++ als die ungeeignetste Sprache. C++ lebt von bibliotheken und konstannten schnittstellen.
Der Aufwand, in C++ was zu implementieren, ist um Welten hoeher als wie mit anderen Sprachen. Dafuer hat man aber auch mehr Möglichkeiten.

Aufn ersten Blick, was Du entwickeln willst, sind "funktionsfaehige Prototypen". Um ueberhaupt mal in der Lage zu sein, Anforderungen zu erkennen, und um in den Besitz eines ueberhaupt aussagefaehigen Lastenhefts zu kommen.

Nimm eine andere Sprache.

Bei uns laeuft es in vielen Dingen aehnlich. Es gibt Projekte, die sind gewachsen. Da hat ein / zwei Programmierer mit ner Scriptsprache ne menge auf die Beine gestellt. Meist waren es NichtInformatiker.
Irgendwann kommt der Punkt, wo das gewachsene so tief verwurzelt ist, das es nicht mehr zu entfernen geht. Auf der anderen Seite kommen immer mehr Nutzer hinzu und stossen immer mehr an Grenzen die ned zu umgehen sind.
Dann wird das Projekt meist komplett neu aufgesetzt, und die bisherige Loesung ist der Prototyp. Auf einmal hasst du aber Romanweisse Anforderungen im Lastenheft, wo vorher nur eine einzige Idee war.
Und ploetzlich schluckt das Project auch das zigfache an Ressourcen. Nicht nur entwickler, auch Manager und Tester .... In dieser Phase ist Einarbeitung in C++ / externe Projectvergabe ueberhaupt kein Thema mehr, sondern scho Vorraussetzung.
Aber um dahinzukommen ist c++ eher kontraproduktiv.

Ciao ...

[harry_m]

...Nimm eine andere Sprache...

Das sagst Du so einfach... Und welche?

Mein Kollege hat etwas Ähnliches schon mal in C# im Visual Studio 2008 aufgebaut. Die Parametrierung erfolgte mittels .XML-Dateien. Dafür das er es nicht fertigstellen konnte, hat es ganz gut funktioniert.

Was kann jetzt C#, was Qt nicht kann?

Soll ich mich doch noch darauf einlassen es in C# zu machen und dann hoffen, dass ich es irgendwann mit Mono auf Linux portieren kann?

[ScyllaIllciz]

Nimm eine andere Sprache.

Bei uns laeuft es in vielen Dingen aehnlich. Es gibt Projekte, die sind gewachsen. Da hat ein / zwei Programmierer mit ner Scriptsprache ne menge auf die Beine gestellt. Meist waren es NichtInformatiker.
Irgendwann kommt der Punkt, wo das gewachsene so tief verwurzelt ist, das es nicht mehr zu entfernen geht. Auf der anderen Seite kommen immer mehr Nutzer hinzu und stossen immer mehr an Grenzen die ned zu umgehen sind.
Dann wird das Projekt meist komplett neu aufgesetzt, und die bisherige Loesung ist der Prototyp. Auf einmal hasst du aber Romanweisse Anforderungen im Lastenheft, wo vorher nur eine einzige Idee war.
Und ploetzlich schluckt das Project auch das zigfache an Ressourcen. Nicht nur entwickler, auch Manager und Tester .... In dieser Phase ist Einarbeitung in C++ / externe Projectvergabe ueberhaupt kein Thema mehr, sondern scho Vorraussetzung.
Aber um dahinzukommen ist c++ eher kontraproduktiv.

Das sehe ich komplett anders. Es ist abhängig von den Voraussetzungen innerhalb der Firma ab. Wir hier haben das Problem, dass ein Projekt in C# entwickelt werden muss. Das Problem dabei ist, dass bei uns ausschließlich in C/C++ entwickelt wird. Jetzt soll Einer diese Sprache lernen und das Projekt durchziehen und hat keinen Ansprechpartner innerhalb der Firma. Das ist ganz schon viel und hart.

Dann lieber definiere ich vernünftige Schnittstellen (Plugins) und versuche das Projekt so modular, wie möglich zu definieren.

Ein anderes Beispiel. Wir haben auf unserer Steuerung für die Konfiguration mit Bash Skripten angefangen. Das ganze hat jetzt solche Ausmaße angenommen, dass bei jeder kleinen Änderung/Erweiterung, kaum einer mehr durchblickt. Klar hat man darüber nachgedacht, dass ganze jetzt neu aufzusetzten und in C++ zu schreiben aber jetzt kommt das Hauptproblem. 1. Es "tut" ja und 2. es kostet viel Zeit das ganze zu spezifizieren, zu entwickeln und zu testen.

[harry_m]

Leut, bitte seid mir nicht böse...

Aber ich habe gehofft, in diesem Thread Antworten auf meine Fragen zu bekommen und nicht eine Grundsatzdiskussion eröffnen.

Es sind zwar auch Sachen, die mich dringend interessieren und ich bin in einem anderen Thread gerne auch dabei.

Hier sind wir jedoch schon auf der zweiten Seite und ich schätze, keiner weiß mehr, wonach ich gefragt habe.

Oder ist die Frage wirklich so abwegig, dass niemand etwas Sachliches zu sagen vermag?!

[RHBaum]

. Es ist abhängig von den Voraussetzungen innerhalb der Firma ab.

Das natürlich auch ... wenn du 20 c++ programmierer hasst und dann irgendwas in Java machen willst ... dann nimm lieber c++

Dann lieber definiere ich vernünftige Schnittstellen (Plugins) und versuche das Projekt so modular, wie möglich zu definieren.

Meine Aussage bezog sich, auf Projecten mit "Prototyp" Charakter.
Also wo sich "Anforderungen stündlich ändern" ... Da ist c++ einfach zu viel aufwand.

Und selbst mit nicht c++ Anwendungen kann man saubere module programmieren ... Hatt den Vorteil, das man wenn man aus dem Prototyp Status rauskommt, die module, wo man genau weiss das sie von der schnittstelle her so bleiben, effizienter in c++ neubauen kann.

Was kann jetzt C#, was Qt nicht kann?

Du willst Sprache mit Framework vergleichen ? ^^
Aber wenn du fragst, was c# kann, was c++ nicht kann ... iss die Antwort: rumfrickeln und mit wenig aufwand viel optisches erreichen.

C++ is maechtiger und effektiver, aber schneller zum ziel kommt man mit c#
Also meistens, Ausnahmen bestaetigen die regel

Aber gibt ned nur C#, der Aufwand in C# iss noch relativ hoch. mit anderen Scriptsprachen laesst sich vielleicht noch schneller der 1. Wurf machen.

Ciao ....

[harry_m]

Was kann jetzt C#, was Qt nicht kann?

Du willst Sprache mit Framework vergleichen ? ^^....

Mensch... Klar, habe es falsch formuliert...

Es hätte korrekterweise heißen sollen

"Was kann C# im Visual Studio (und .NET-Umgebung), was C++ im Qt-"Gewand" nicht kann?!"

Das man mit C# schneller zum Ziel kommt weiß ich selbst: denn ich habe mit C# schon mal angefangen: ging viel leichter von der Hand, als C++ mit Qt. Auch andere bestätigen das.

Das war aber nicht die Antwort auf die Frage. Meine Frage lautete:

"Warum hat mein Kollege in C# im VS2008 es geschafft eine parametrierbare Applikation zu schreiben und warum wird hier behauptet, dass C++/Qt dafür nicht geeignet ist?!"

Ich weiß sehr wohl die Vorteile einer Script-Sprache bzw. eines Interpreters zu schätzen. Aber die Applikation meines Kollegen war eine Ansammlung von .exe und .dll- Dateien plus eine .xml-Konfigurationsdatei.

Warum soll das in C++ nicht auch möglich sein?

Und übrigens: ich habe nicht davon gesprochen, dass die Aufgabe sich von Heute auf Morgen komplett ändert. Änderungen gibt es immer. Es ist nur eine Frage des Konzepts. Und wenn die Objektorientierte Programmierung nicht dafür erfunden wurde, solche Aufgaben zu erledigen, so weiß ich auch nicht weiter.

[RHBaum]

Warum hat mein Kollege in C# im VS2008 es geschafft eine parametrierbare Applikation zu schreiben und warum wird hier behauptet, dass C++/Qt dafür nicht geeignet ist?!

Lies mal richtig
Keiner behauptet das es nicht möglich ist, Ich behaupte nur das Dich mit einfach c++ schwerer tust !
Aber wenn Du so fixiert auf c++ bist, dann gibt es sicher eben Aspekte die für C++ sprechen. Nur musst das dann auch so kommunizieren.
Bsp. wenn Performance und Freiheit von einer runtime, also ne exe die fast ueberall startet, als Beispiel, eine Anforderung sind, dann kann sich das Verhaltniss schon in Richtung C++ wieder verschieben.

Was wir gar ned einschaetzen koennen, ist der Umfang und die Energie, die in das Project fliessen soll ....
Aber sobald das einen "professionellen" Status erreicht, sollten da auch Programmierer mit den entsprechenden Skills mitarbeiten.
Und zu den Skills eines guten Programmieres gehoert es, das er nicht nur eine Sprache beherrscht, und sich in andere Sprachen recht schnell einarbeiten kann ... Und noch besser ist, wenn man mehrere Technicken in einem Project sinvoll und effektiv verwenden kann, also mixxen. Oft ist es gar ned erforderlich, das alles in c++ geschrieben wird ...


Ciao ...

[harry_m]

Wenn das nicht erhellend ist.

Ich mache mal ein kleines Resümee...

- Der Thread vor einer Woche veröffentlicht worden.
- 22 Beiträge habe ich bis jetzt gezählt.

Was ich bis jetzt erfahren habe:

1. Ich soll erst das Programmieren lernen, dann Fragen stellen
2. Es ist schwierig, C++ zu lernen.
3. Ich soll lieber irgendeine andere Sprache wählen
4. Beim Programmieren läuft sehr viel schief.
5. Profis zu beschäftigen ist besser.

Ist mir sonst noch was entgangen?

In dem Sinne: danke für die Unterstützung, liebe Kollegen.

Ich habe viel gelernt.

[franzf]

Zynismus hilft da aber auch nicht weiter.
Und aus den Infos die du uns gegeben hast, können wir dir keine Software-architektonischen Tips geben. Mehr kann man dir nicht sagen.
Deshalb hab ich ja gemeint, du solltest dich in die Richtung mal warmlesen (OO-Analyse und Design).
Und der Tip von RHBaum war auch nur gut gemeint: Eine komplexe Sprache wie C++ kann einem mehr Steine in den Weg legen als eine einfache Scriptsprache wie Python/Ruby...

Ich weiß leider nicht wie ich sonst noch helfen kann.

[harry_m]

Zynismus hilft da aber auch nicht weiter.
Und aus den Infos die du uns gegeben hast, können wir dir keine Software-architektonischen Tips geben...

Kein Zynismus.

Ich bin einfach Enttäuscht. Denn ich weiß aus Erfahrung, wie viel hilfreicher meine Fragen in anderen Foren behandelt wurden.

Ich habe die Frage so gut, wie nur möglich beschrieben. Mag sein, es war nicht ausreichend. Dann fragt doch mal!

Zu Python/Ruby: und wie mache ich damit eine Plattform unabhängige Oberfläche? Ich dachte das ist falsch, eine Sprache mit eine Framework zu vergleichen?!

Ich habe mir schon was dabei gedacht, als ich mich für C++ und Qt entschieden habe: und das stand von Anfang an nicht zu Diskussion.

Das ist das einzige Deutschsprachige Qt-Forum und man kommt hier aus dem allgemeinen Smalltalk nicht heraus.

[franzf]

Zu Python/Ruby: und wie mache ich damit eine Plattform unabhängige Oberfläche? Ich dachte das ist falsch, eine Sprache mit eine Framework zu vergleichen?!

python und ruby sind erstmal nur Sprachen, sowie halt C++, Java, C#, ... Dort wird der Syntaktische, Semantische, ... Grundstock für Programme gelegt.
Um dieses Grundgerüst baut sich eine STandardbibliothek auf. Und da fängt bereits der Unterschied an: die C++-StdLib ist sehr klein. Wenn du die STL dazu nimmst wird es nicht viel besser. Um wirklich was mit C++ anfangen zu können, musst du drittanbieter Libs dazu nehmen. boost, oder eben Qt.
C#, java, python haben da von der Installation weg DEUTLICH mehr zu bieten - z.B. überall schon ne GUI. Für viele Aufgaben gibt es bereits Lösungen: XML mit DOM und SAX, inis lesen, Socket-Programmierung, ...
Packaging ist mit Python usw auch einfacher: File speichern, irgendwo mit import einbinden, klappt. In C++ musst du in Header und Source aufteilen, bei includes zirkuläre Abhängigkeiten beachten, die ODR nicht verletzen, mit Compiler und Linker umgehen lernen, Fehler lesen lernen.
Ich könnt jetzt noch weiter machen. Aber ich weiß dass es dir nichts bringt Ich will nur sagen, dass für eine schnelle Lösung andere Sprachen geeigneter sind - vor allem wenn man die Sprache erst noch lernen muss.

Zu deinen Fragen:

1. Von vier Maschinen müssen die Daten eingesammelt werden. Datenmenge: ein Array aus 20 Byte. Daten werden über Ethernet via OPC übermittelt. (Für diejenigen, die sich in diesem Bereich nicht auskennen "OPC" steht für "OLE for Process Control", das ist ein offener industrieller Standard für den Datenaustausch in der Automatisierungstechnik.)

2. Die eingesammelte Daten müssen visualisiert werden. Dafür wird pro Maschine ein "Icon" angezeigt werden.

3. Seine Bestandteile: Rand, der verschiedene Farben haben kann, Zentrales Bild, das 20 verschiedene Symbole anzeigen kann. Die Farbe des Hintergrunds soll auch veränderbar sein. Oben in diesem "Icon" soll ein fixer Text stehen, der jedoch parametrierbar sein muss. Unten im "Icon" soll ein String sein, dessen Inhalt je nach Daten unterschiedlich zusammengesetzt wird.

1) Ich hab von OPC keinen Plan! Wenn du für den Anfang eh schon fertige Sachen von Windows nehmen wirst, wird das nicht das große Problem sein - kann aber ein Spezialist sicher mehr sagen.
Aus Qt-Sicht startest du für Netzwerksachen bei QAbstractSocket aufwärts. Für Byte-Arrays gibt es QByteArray.

2) Icon -> QPixmap.

3) Die Bestandteile des Icons?
*) Oder willst du eher ein eigenes QWidget malen? -> QWidget ableiten und paintEvent+sizeHint implementieren.
*) Oder vorhandene Komponenten in einem Layout anordnen? QWidget::setLayout() mit passendem Layout.

Frage 1) war technischer Natur, die spezielle Anforderungen benötigt.
2) und 3) waren schon auf eine grafische Umsetzung angelegt.

Und jetzt die Fragen.

1. Da die OPC-Schnittstelle auf Windows-DCOM basiert, wird es unter Linux eine andere geben (OPC United Architecture: befindet sich bereits in Entwicklung). Daher muss das Einsammeln der Daten von der Anzeige sehr strickt getrennt werden.

- wie macht man das denn in der Qt-Welt am besten?

Ja, Daten von Anzeige trennen. Das kommt ganz drauf an, WIE du das erreichen willst. Das kommt auch auf den Umfang an. Am schönsten geht das über das "Qt Item View Framework" (Fester Bestandteil von Qt): Ein eigenes Model von QAbstractItemModel ableiten. Wenn du eine der View verwenden kannst (List, Table, Tree) -> fertig. Nein? Nochmal von QAbstractItemView ableiten.
Ich bin mir aber sicher, dass das zu komplex wird für den Anfang. Dann musst du selber kapseln: class Item für die Daten, class ItemView:public QWidget für die ANzeige. View zeigt ein Item an.

Ich beschreibe mal meine Vorstellung. Hoffen wir mal, dass es als Grundlage dienen kann.

Klasse "OPC-Connection": liest die Daten vom OPC-Server und schreibt sie ... irgendwo hin.

Klasse "Maschinenstatus": liest die Daten, und bildet sie entsprechend ab.

Sehr schön, zwei Klassen. Die Beschreibung ist allgemein und lässt viel Raum für Spekulationen. Hier kann man nicht wirklich ansetzen.

Wir haben als Info:
Maschinenstatus wird per OPC übertragen. Die Anzeige soll via Icons stattfinden. Daten von Anzeige trennen.

Was fehlt? Eine konkrete Aufgabenstellung Bei OPC kann dir nur ein Spezialist helfen. Die Anzeige ist auch kein Problem. WIr haben keine Info WAS die Maschinen machen. Was steckt in den Bytes? Brauchst du nen kleinen Parser? Oder sind das nur "Status-Bytes". Sollen die Daten-Klassen dynamisch auf Änderungen der Maschinen reagieren? Willst du Status-Kontrolle durchführen - also Warnungen bei bestimmten Konstellationen ausgeben?

Zwischen Datenbeschaffung von der Maschine und Anzeige klafft eine riesige Definitionslücke.

Im Prinzip fehlt nur noch, dass du mit C++ anfängst. Konkrete Fragen werden sich dann von selber ergeben, wenn es nur um die Qt-Seite geht.
Wenn es dir um das Konzept deiner Softwarearchitektur geht, musst du anfangen, dir selbst und deinen Kollegen/Vorgesetzten Fragen zu stellen, um genau abzustecken, was die Software können soll und was nicht, um ein "Lastenheft" o.Ä. zu erstellen. Um zu wissen, wie man das macht, braucht man Erfahrung, und/oder ausreichend Wissen -> OOA/D.

Vielleicht kannst du nun etwas genauer artikulieren, wo deine Probleme liegen, dann kann man auch konkret helfen. Eine komplette Analyse + Designvorschlag wird dir hier noch keiner geben können...

[Giesbert]

Hi Harry,
das was du willst ist schon lösbar in C++/Qt. Vom Prinzip her brauchst du ein Schichten Modell:
1. UI --> Qt/C++
2. BusinessLogic --> Qt/C++
3. Datenanbindung --> C++/COM mit OPC

Die Datentypen zu konvertieren ist keine Hexerei, aber bei COM kann man viel falsch machen (egal ob in C++, C# oder VB, ja auch da)

Um egnauer zu sagen, wie deine Datenmodelle aussehen müssen, müsste man wissen, wie die Oberfläsche genau aussehene soll und wie die Daten aussehen, die reinkommen sollen.

Die Datenanbindung könntest du über eine Dll realisieren, so daß du diese später austauschen kannst, wenn du von OPC auf OPC UIA umstellen willst.

So weit mal zu den Prinzipiellen Dingen.

Ciao
Gerolf

PS: ob man diese Aufgabe mit C# schnelle lösen kann weiß ich nicht, das kenne ich zu wenig. Aber viel weniger komplex wird es auch nicht. Man hat nur weniger Memory Leaks als in C++ (zumindest am Anfang)

[Giesbert]

3) Die Bestandteile des Icons?
*) Oder willst du eher ein eigenes QWidget malen? -> QWidget ableiten und paintEvent+sizeHint implementieren.
*) Oder vorhandene Komponenten in einem Layout anordnen? QWidget::setLayout() mit passendem Layout.

Ich denke, einzelne Widgets wären hiuer einfacher als Model/View.
Wenn es nur darum geht, anhand der Stati Bitmaps cons) zu malen wären custom widgets mit peintEvent vorzuziehen.
Wenn die Darstellung Tabellarisch sein soll/muss, wäre es eher ein Model/View mit einem "Icon Generator", um die Bitmaps zu bauen.

[franzf]

Ich denke, einzelne Widgets wären hiuer einfacher als Model/View.
Wenn es nur darum geht, anhand der Stati Bitmaps cons) zu malen wären custom widgets mit peintEvent vorzuziehen.
Wenn die Darstellung Tabellarisch sein soll/muss, wäre es eher ein Model/View mit einem "Icon Generator", um die Bitmaps zu bauen.

und selbst die am genauesten ausformulierte Beschreibung führt zu Diskussionen zum genauen "wie".

Ist nicht böse gemeint, soll nur zeigen, dass erst noch einiges geklärt werden muss, bevor exakte Unterstützung möglich ist.

[harry_m]

Na geht doch! Jetzt habe ich schon mal was zum kauen.

Heute ist es schon zu spät, ich werde es morgen aufarbeiten und mich melden. Ich will auch ein Paar Bilder veröffentlichen: angeblich sagt ein Bild mehr, als Tausend Worte.

Danke Jungs.

P.S.: hier schon mal das erste Bild...