Beiträge von MiFa1969

Ich würde auch mit dem Act reden. Vielleicht sind die Gründe ja einleuchtend.

Oder du kannst sie überzeugen, dass der andere Dienstleister genauso gut ist.

Das ist so ähnlich wie wenn Künstler zu uns aufs Land kommen.

Da bekommt man oft einen Rider, da traut man sich im ersten Moment nicht, den Job zu machen. Wenn man dann darüber spricht, sind die fast immer sehr genügsam und freuen sich, dass man fragt.

Das ist zumindest meine Erfahrung. Und da waren auch schon Leute dabei, die man ab und zu im Fernsehen sehen kann.

Was ich vergessen habe zu erwähnen, die ganzen Schnittstellen und Protokolle lassen sich beliebig und mehrfach verwenden. Bei vielen Fabrikanten geht oft nur eine begrenzte Anzahl davon an einer CPU.

Dadurch lassen sich die wildesten Adaptionen erstellen.

Zum Beispiel von KNX auf Crestron, DMX zu DALI, beliebige TCP Pakete zu weiß der Geier.

Und die Schnittstellen müssen physisch nicht direkt an der CPU hängen.

Ich weiß, dass es da diverse Gateways gibt. Aber mit dieser Lösung können die Daten auch noch modifiziert und behandelt werden, bevor sie in ein anderes System geschickt werden.

Ich weiß, da greift der alte Spruch: wenn man weiß wie es geht, ist es immer einfach

Cool, einer der es kennt! So schwer ist das programmieren gar nicht.

Zitat von Carsten Lang

....also für mich sieht das auf dem Bild so aus, als ob die Entriegelungslasche schon ungedrückt am Gehäuse anliegt.

So kann man die nicht weitgenug eindrücken, um den Stecker zu entriegeln.

Ne, dass täuscht. Die geht bestimmt 5mm beim drücken rein.

Liebe Moderatoren, ich weiß nicht so recht, wo ich das Unterbringen soll.

Es gibt keinen so richtigen Platz dafür. Deshalb jetzt mal hier. Wenn Ihr einen besseren Platz findet, könnt ihr das gerne verschieben.

In einem anderen Thread wurde ich gebeten, mal ein wenig über ein Automatisierungssystem zu berichten, mit dem ich in meinem Hauptjob seit ca. 20 Jahren zu tun habe.

Und ganz wichtig: Ich arbeite nicht bei dem Hersteller.

Die Idee dazu kam mir eigentlich schon vor längerer Zeit, da man mit dem System die Veranstaltungstechnik streift bzw. in Festinstallationen sogar mehr als nur streift.

Das System um das es hier geht, kommt aus der klassischen Steuerungstechnik. Und irgendwie auch nicht. Warum?

Das System ist eines der vielfältigsten in diesem Bereich, wenn es um Protokolle, Bussysteme und Schnittstellen geht. Und dann ist es eben sehr gut programmierbar. Nicht so wie ihr vielleicht denkt, wie man das früher mit SPS-Systemen gemacht hat. So nach dem Motto Eingang A und Eingang B geht auf ein UND Glied und wenn dass wahr ist wird Ausgang A gesetzt.

Ja, dass geht natürlich immer noch. Aber das war es dann auch schon.

Man verwendet den Dialekt IEC6-1131-3 zu dem auch die Unterart „Structured Text“ gehört. Das ist eine Programmiersprache, die sehr mit Pascal verwandt ist. Damit lassen sich dann Funktion und Funktionsbausteine definieren usw.

Und wem das nicht reicht, kann auch reinen C Code mit einbinden.

Das System besteht immer aus einer CPU und diversen I/Os, Schnittstellen oder Buskarten.

Die CPU beginnt im kleinsten mit einer ARM basierten Kern und endet bei einem I7 mit mehreren Kernen.

Das sieht dann im Kleinen so aus:

Und so in etwas größer.

Es gibt auch kleine Embedded PCs die man verwenden kann:

Sehr viel weiter würde ich nicht ins Detail gehen. Gerne mache ich weiter, wenn Interesse besteht.

Hier aber noch mal eine kleine (unvollständige) Übersicht über die Protokolle, Bussysteme und Schnittstellen:

Protokolle / Bussysteme:

Asi, BACnet, CANopen, DALI, DMX, Artnetm DeviceNet, Ethercat, Ethernet/IP, IEEE1588, KNX, M-Bus, Modbus. Profibus, Profinet, RS232, RS485, SMI

Und noch eine Übersicht, was es an Software-Schnittstellen gibt:

JSON Data Interface, OPC UA, OPC UA Pub/Sub, Modbus TCP, Modbus RTU, EtherNet/IP Adapter, FTP Client, TCP/IP, TCP/UDP Realtime, Serial Communication, SMS/SMTP, Database Server, XML Server, FDT ComDTM, IoT Communication (MQTT), IoT HTTPS/REST, IoT WebSockets, IoT OCPP

Zum Schluss noch ein paar Beispiel was man so machen kann:

DE | PIXERA control: innovative Automatisierungskonzepte für die Medien- und Gebäudetechnik

Beckhoff stellt in Kooperation mit den österreichischen Projektionsspezialisten von AV Stumpfl die Integration von Beckhoff Hardware in das softwarebasierte…

vimeo.com

DE | Lundin Norway: Breaking the Surface

EtherCAT synchronisiert 529 Achsen einer kinetischen Installation der Scandinavian Design Group, Beckhoff Servoklemmen bewegen den virtuellen Ozean: Die…

vimeo.com

Audico installiert State-of-the-Art-Lichttechnik im historischen Wasa-Theater

www.beckhoff.com

Und zum Schluss, ein Produkt, das überhaupt nichts mit VT zu tun hat, was man aber echt mal sehen muss – schwebende Kacheln:

DE | XPlanar: 360°-Moverrotation für die Maschine der Zukunft

Die hochdynamische und softwarebasierte 360°-Moverrotation des XPlanar-Systems eröffnet neue Freiheitsgrade für Inspektion, Produktbearbeitung und…

vimeo.com

Alles gut, lieber einen Tipp zu viel, als einen zu wenig.

Kann ja jeder damit umgehen wie er will.

Vielen Dank!
Ich habe gerade eine ganz andere Vermutung. Das kann ich aber erst am Montag testen.

Genau die SPSen die das Problem haben, verwenden den zweiten Ethernet Port für ein proprietäres Bussystem, dass keinen IP Stack verwendet. Da sind in der Regel abgesetzte I/Os dran.

Aber genau bei den SPSen hängt als Slave auch eine SPS dran, die ebenfalls mit dem IP Netz verbunden ist. Soweit ist das auch kein Problem.

Aber genau die SPS ist diejenige wo sich die Mac Adresse doppelt.

Aber der Hersteller hat bei diesem Bussystem einen IP Tunnel eingebaut, den man bei Bedarf aktivieren kann. Damit kann man an das Bussystem ein IP Gerät anhängen das eventuell keinen physikalischen Zugriff auf das IP Netz hat.

Und dieser Modus ist eine Voreinstellung.

Dadurch wird eventuell die Mac Adresse durch den Tunnel dem falschen Gerät zugeordnet.

Habe deswegen auch schon dem Support des Herstellers geschrieben. Und ich werde den Tunnel einfach mal abschalten. Dann zeigt sich das schnell.

Wenn es das wäre... Meine Vermutung geht stark in die Richtung, da es genau die Geräte sind, die diese Konstellation haben.

Ich habe mal eine kleine Skizze gemacht, damit man es besser versteht:

So wie das hier gemacht ist, macht man das eigentlich nicht. Sinn war wohl, dass der Datenaustausch zwischen SPS1 und SPS2 auch funktioniert, wenn mal das IP Netzwerk weg ist.

Und wenn meine Vermutung stimmt, müsste das Problem durch abschalten des Tunnels behoben sein. Der Tunnel wird eh nicht verwendet.

Das würde auch wieder erklären, warum es mit dem alten Server (also ohne VM) auch die selben Probleme gab.

Nächsten Montag weiß ich mehr.

Zitat von marce

Am Switch einen Port auf Monitoring schalten und da mal beim Booten des Servers alles Mitschneiden, was da so rein kommt. Dann an einem gemütlichen Wochenend mit Wireshark analysieren.

Wenn ich nicht weiter komme, wird mir nichts anderes übrig bleiben.

Danke!

Zitat von robert müller

Configfile. Die wurden doch sicher vom alten Server übernommen.

Meine Theorie ist: Es gibt die Option, in der Config eine Tabelle oder ähnlich mit Geräten, IP- und MAC-Adressen zu hinterlegen. Ein übereifriger Integrator hat damals bei der Ersteinrichtung des Systems eine solche eingepflegt. Zwischenzeitlich wurden IPs an den Geräten geändert und jetzt beißt dich der Ist-Stand mit der alten Config.

Für die ARP Tabelle gibt es kein Configfile. Die baut sich ja über Broadcasts auf.

Ich schau morgen mal weiter.

Vielen Dank auf jeden Fall mal bis hier her!

Zitat von Licht_01

Der Extra Thread dafür klingt super.

Das Haus in dem ich Arbeite soll nächstes Jahr Saniert werden, dafür wäre es also interessant.

Aktuell wäre die Überlegung komplett auf Geräte von Chamsys zu setzen, vllt. wäre es aber ja so sinnvoller.

Mache ich gerne. Gib mir ein bisschen Zeit, dann stelle ich was zusammen.

Ich arbeite übrigens nicht bei dem Hersteller.

Ich setze die Produkte aber seit über 20 Jahren ein.

Du kannst damit so ziemlich jedes Bussystem anbinden und hin und her schieben.

So was gibt es sicher auch als kleine Konverter.

Aber hier kannst du eben viel Intelligenz reinbringen, da die Steuerungen extrem programmierbar sind.

Mal OT, dass System um das es hier geht (die Automatisierungsgeräte) ist von Beckhoff.

Schätze mal, dass das viele in der VT Branche nicht kennen.

Die haben sehr interessante Lösungen für den Bereich Licht und Bewegung.

Hier mal ein Beispiel:

Ohne hier Werbung machen zu wollen, könnte ich mir vorstellen, dass das viele Möglichkeiten bieten würden.

Es gibt fast kein Protokoll aus dem Industrie-Umfeld bzw. Signalform wo das System nicht kann.

Und bei Bedarf kann auch direkt C Code eingebunden werden.

Wenn da jemand Interesse hat, mache ich gerne mal einen Thread und erkläre das ein wenig.

Theoretisch könnte das sein. Aber warum war es auf dem alten Server auch so?

Jede Idee wird durch einen anderen Umstand wieder zerlegt.

Ich werde in den nächsten Tagen mal noch ein paar Tests machen.

Was ich auch nicht verstehe ist, dass es nur ein paar der Geräte sind, bei denen das passiert.

Eines davon habe ich auch schon mit der aktuellen Firmware versorgt.

Hat auch nichts geändert.

Da sitzt irgendwo ein großer Wurm den ich nicht sehe

Die meisten der Geräte haben zwei Netzwerkadapter. Die haben aber in der Regel keine IP Adresse, weil sie entweder nicht verwendet werden oder weil da ein Ethernet-Basierendes Bussystem dranhängt, dass keinen IP Stack verwendet.

Und durch das es ein separater Netzwerkadapter ist, hat er auch eine andere Macadresse.

Zitat von robert müller

DNS und DHCP reagieren allergisch auf falsch gehende Uhren? Hab ich so noch nie erlebt, wüsste auch nicht, wieso

Es ist genau genommen DNS in Verbindung mit AD.

AD ist da extrem empfindlich.

Wir hatten mal in unserem Büro extreme Probleme mit Zugriffen auf Dateifreigaben der Server.

Nach langer Fehlersuche lag es an einer falschen Uhrzeit im L2 Switch.

Auf dem Switch sind mehrere VLANs und ein DNS Relay leitet die DNS Anfragen der Clients weiter.

Und durch die falsch Uhrzeit im Switch wurden die DNS Anfragen vom AD abgelehnt.

Das hat aber mit dem ARP Problem sicher nichts zu tun.

Zitat von robert müller

Hängt zwischen dem betroffenen System und den Clients irgendeine Middlebox? Transparente Firewall auf L2 oder sowas? Oder ist vielleicht auf dem Router / der Firewall / whatever irgendwas konfiguriert a la wenn IP vom Server fragt, gib schon mal Antwort aus einer vordefinierten Liste?

Nein, das ist ein ganz flaches Netz. Ich habe auf den Servern auch schon alles abgeschaltet, was da eventuell reinspuken könnte.

Aber das mit der IP Adresse kommt mir verdächtig vor.

Ich würde auch gerne zum Test mal den zentralen Switch tauschen. Aber da fehlt es zur Zeit an einem passenden Gerät.

Du hast vollkommen recht, Uhrzeit ist in Netzwerken tatsächlich sehr wichtig.

Da habe ich auch schon die tollsten Dinge erlebt.

DNS und auch DHCP sind da sehr empfindlich, wenn die Uhren nicht synchron sind.

Aber das passt. Daran liegt es leider nicht.

Ich finde es gut, wenn ihr eure Ideen mitteilt. Irgendwann geht bestimmt die Lampe an und bringt Licht ins dunkle

Die VM wurde neu aufgesetzt. Das alte System war Windows Server 2008.

Jetzt 2019.

Ich denke schon, dass sich da was verschluckt. Nur warum kommt mir nicht in den Sinn.

Ich hatte gestern noch mit meinem Kunden gesprochen. Der meinte, dass war früher auch schon so. Mit früher meinte er, bevor der Rechner virtualisiert wurde.

Was hat das alte und das neue System gemeinsam?

Die VM hat nach dem Wechsel auf das neue System die selbe IP bekommen, wie vorher der alte Server. Könnte es irgendwie an der IP hängen?

Das muss ich auch testen. Ich gebe der VM mal eine andere IP.

Mal sehen, ob der Fehler dann noch auftritt.

Das vermute ich auch. Aber es kann einen verrückt machen.

Ein Kollege mit sehr guten Kenntnissen in virtualisierung meinte, es könnte ein Bug in HyperV sein. Würde das Verhalten zumindest erklären.

Wenn ich was rausfinde, gebe ich Bescheid.

Danke nochmals!

Die Geräte haben nahezu alle noch einen kleinen Hutschienen-Switch davor geschaltet.

Die sind aber nicht managebar.

Und von da geht es auf einen zentralen Switch.

Da hängt auch der Server dran.

Ich finde es halt merkwürdig, dass das Problem nur in der VM besteht.

Der Host der VM hat damit keine Probleme.

Es gibt da noch einen Service PC im Netz.

Da muss ich mal schauen, wie es sich da verhält.