Es geht doch gar nicht um das fetchen der Daten aus der (Siemens-) SPS
Da wir in einer Anlage ggf. ZIG Visualisierungsrechner haben, und es vermieden werden soll, dass alle diese Rechner direkt von der SPS beschickt werden oder selber aus der SPS lesen müssen - das hat zum Teil damit zu tun, dass es zwischen Anlage und Verwaltung meistens eine Firewall gibt, die diese zwei Netze bis auf die Datenbank trennt - gibt es eben einen Service, der die kompletten Datenbausteine in einem konfigurierbaren Intervall aus der SPS liest und in die Datenbank schreibt. Und dort stehen sie ja auch richtig drin. Das läuft, das war vorgegeben, da hab ich schon fertigen Code zum Fetchen bekommen, und ich werde einen Teufel tun mich hier deswegen mit meinem Auftraggeber zu streiten
Die alte Visualisierung die ich gerade
erneuere neu schreibe ist nach dem Fetchen hergegangen, und hat jedes einzelne Bit aus dem
DB als eigenen Datensatz(!) in die Datenbank gepumpt. Das Problem war dann der Traffic, der ein einzelner Client auf dem Netz erzeugt hat, wenn dort einer die Visumaske aufgemacht hat. Das war dann noch so unglücklich gemacht, dass der echt für jedes Bit ein einzelnes Statement zum holen von der Datenbank gefeuert hat.
Deswegen war meine Idee, das aufdröseln der Daten in die einzelnen Bits eben auf den Client auszulagern, und die Datenbausteine komplett als Blob in die
DB zu legen. Dort kann dann jeder der will darauf auswerten und gucken, welcher Antrieb läuft, welcher auf Handsteuerung läuft und wo ggf. welche Störung anliegt.
Ob nun Bits oder Zahlen in dem
DB liegen ist mir recht wurscht. Ob die 10 in dem Byte da drin nun bedeutet, dass es die Zahl 10 ist oder dass da das zweite und vierte Bit (von rechts gesehen) gesetzt sind, das kann ich mit meiner Bitmasken-Prüfung einheitlich abfackeln. Auch Texte sind kein Problem.
Meine Frage bezog sich tatsächlich nur auf die Verdrehung der Bytes, sobald ich sie in einen Cardinal stecke. Und nun werde ich das mal mit einem DWORD probieren und gucken ob ich da dann noch drehen muss oder nicht