Hallo QM,
Question_mark schrieb:
Also ein bisschen mehr als nur ein Compliance Test-Tool steckt schon hinter der Mitgliedschaft. Aber ich will hier keinen Glaubenskrieg über Vor- und Nachteile einer Mitgliedschaft anzetteln.
Das ist mir schon klar, aber ich will ja auch nicht umbedingt in den Gremien der OPC-Foundation über die Zukunft von OPC mitsprechen können, nur weil ich gerade einen OPC-Server entwickle oder entwickelt habe. Nur für das Test-Tool wäre die Mitgliedschaft auch völlig überzogen teuer (ist sie meiner Meinung nach auch so schon).
Question_mark schrieb:
Mein obiger Post sollte fubu einige Hürden und Fallstricke bei der Entwicklung aufzeigen, nichts anderes !
Da stimme ich Dir durchaus zu, aber die liegen meiner Meinung nach nicht vorrangig darin, Kenntnis über die Spezifikationen zu erhalten, denn das geht (nach Registrierung) über die Website der OPC-Foundation ja recht einfach. Die meisten Probleme dürften wohl eher bei der letztendlichen Umsetzung der Spezifikationen in Programmcode auftreten, denn das setzt meines Erachtens auch mit Unterstützung durch eine Toolbox schon einiges an Erfahrung in der Software-Entwicklung voraus, damit es gut wird.
Question_mark schrieb:
Auch in der neuesten Version 8.0.2 von LibNodave wird z.B. die Racknummer beim TCP/IP falsch berechnet und funktioniert trotzdem (weil 99,9% der Anwender Rack 0 einstellen, und damit funktioniert es eben zufällig).
Mag sein, wobei libnodave aktuell in der Versionsnummer 0.8.2 vorliegt. Bei Open-Source bedeutet eine Version < 1.0 üblicherweise, das der Author die Software für noch nicht vollständig bzw. völlig ausgereift hält, was ich bei libnodave zwar für Tiefstapelei halte, worüber man sich als Anwender jedoch im Klaren sein muß.
Wenn man Zottel allerdings über den genannten Fehler in Kenntnis setzt (oder wenn er das hier liest), dann ist das Problem sicher innerhalb kürzester Zeit gefixt, und zu Not kann man sich auch selber weiterhelfen (hab' ich beides bei libnodave schon mehrmals gemacht). Bei kommerziellen Produkten (meist Closed Source) ist man vom Hersteller auf Gedeih und Verderb abhängig, was wir schon schmerzlich erfahren mußten, zwei Beispiele:
Ein Kollege von mir hat von einem Support-Mitarbeiter zwei Wochen nach der Anfrage wegen eines Software-Problems einen Rückruf mit der Frage bekommen, ob man sich um das Problem noch kümmern muß oder ob es sich mittlerweile von alleine gelöst hat. Letzteres war der Fall, weil mein Kollege gar nicht erst die 2 Wochen auf den Rückruf warten konnte und darum schon einen recht aufwendigen Workaround um das Problem herum programmiert hatte.
Einem anderen Kollegen wurde bei einem eindeutigen Software-Fehler vom Support es Herstellers mitgeteilt, das wir uns entweder die demnächst herauskommende Folgeversion
kaufen müssen, oder wir beauftragen
und bezahlen die Software-Korrektur in der aktuellen Version.
Question_mark schrieb:
Bei der Realisierung eines Kommunikationsprotokolls ist es aber schon ein Unterschied, ob es anhand von reverse engineering (hier jetzt mal durch Loggen und auswerten einer Kommunikation) oder anhand einer dokumentierten Protokollbeschreibung entstanden ist.
Das betrifft aber speziell libnodave, und nicht die freien OPC-Bibliotheken, da die OPC-Spezifikationen ja öffentlich frei verfügbar sind. Zudem habe ich den Eindruck, das manche Entwickler der freien Bibliotheken offensichtlich selbst Mitglieder der OPC-Foundation sind.
Ich will auch keinen Glaubenskrieg anfangen, aber Aufgrund unserer Erfahrungen mit dem Verhalten von manchen Herstellern kommerzieller Software baue ich darauf, das diese durch die Konkurrenz aus dem Open-Source Bereich endlich zum Umdenken gezwungen werden. Es ja gibt schließlich auch kommerzielle Hersteller, die das besser können, das schließt sich also nicht aus. Und mindestens solange werde ich nicht müde, meine durchweg positiven Erfahrungen mit Open-Source öffentlich zum Ausdruck zu bringen.
Gruß Axel