Ja, dass Core ist gebraucht.
Ich habe aber eine Info unterschlagen, sorry.
Ich habe noch 50cm Patchkabel vom Core auf die Neutrik Durchgangsbuchse in der Rackblende.
Ich teste mal direkt am Core. Aber der Test mit dem Port B läuft noch (inkl. Rackverkabelung).
Seit einer Stunde noch kein Fehler.
Hallo Kilian,
guter Tipp! Das werde ich auf jeden Fall versuchen.
Danke!
Moin Kollegen,
ich möchte kein Leichenschänder sein, aber ich habe das selbe Problem.
Vor einem halben Jahr habe ich mein X32 Fullsize gegen ein X32Core getauscht.
Mit dem Fullsize / S32 und einem Kabel mit den folgenden Spezifikationen nie Probleme:
Länge: 70 m
Belden Industrial
Vergoldete Kontakte
Schirmung: SFTP (SF/UTP)
4x2xAWG26/7
robuster, gummiartiger PUR-Mantel
Extra schnitt- und abriebsfest
Kälteflexibel
Neutrik NE8MC Ethercon Stecker
Letzte Woche dann eine VA mit dem Core und dem S32, im Minutenabstand Aussetzer und Knackser.
Habe das ganze zum Test nochmals aufgebaut. Es ist komplett nachvollziehbar. Mit dem langen Kabel die selben Probleme. Nehme ich ein 3m Patchkabel ist alles in Ordnung. Über Stunden keinen Fehler.
Kann es am Core liegen? Hat das andere NICs drin?
Oder liegt es eventuell am aufgerollten Kabel?
Bei der VA hatte ich nur ca. 10m abgerollt, Bei meinem Test noch weniger.
Danke und Grüße
Michael
In Logic lässt sich der Master Ausgang unter Einstellungen > Audio > I/O Zuweisung einem ggf. unbenutzten Kanalpaar zuordnen.
Alternativ lässt sich der Master Bus auch muten und man muss auch erst gar nichts dorthin routen
Ich weiß, aber es hat damals nicht funktioniert. Ist schon zwei oder drei Jahre her.
Bin mir nicht mehr so sicher, was ich alles versucht habe.
Was ich noch weiß, dass ich damals einfach erst ab Kanal 3 oder höher die Spuren zugewiesen habe.
Bleibe bei Reaper. Ich habe auch lange mit Logic versucht. Aber man kann Logic nicht abgewöhnen, den Master auf Kanal 1 und 2 auszuspielen.
Ich bin da fast verzweifelt, da ich dachte, ich bin zu blöd dafür.
In Reaper geht das ohne Probleme.
Das ist nicht schön. Aber es menschelt halt immer.
Da habt ihr das einzig richtige gemacht 
Edit: Ich war zu langsam. Mein Kommentar bezog sich auf Zegis Bericht
Fehler gefunden. Es war nicht das, was ich vermutet hatte.
Bei dem System kann man einen Software-Adapter für ein Realtime Protokoll verwenden.
Den hat der Sys.-Integrator reingemacht und da war eine falsche IP drin.
Also nicht die, die zum Gerät gehört hat.
Dadurch hat der Software-Adapter mit einer IP gepusht. die nicht zu ihm gehört.
Und diese IP war ja auch vergeben.
Dadurch ist in dem Rechner die Mac-Tabelle durcheinander gekommen.
Das hat mich mindestens 1000 graue Haare gekostet.
Vielen Dank an Alle, die mitgeholfen haben!
Das meinte ich mit größeren Produktionen.
Für den Live Einsatz ist es vermutlich nicht relevant, abgesehen von sehr großen Produktionen.
Es war nur ein Hinweis, dass es so etwas gibt.
Mit den Infos kann jeder machen was er will.
In meiner Branche sicher nicht…
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.
....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:
Und zum Schluss, ein Produkt, das überhaupt nichts mit VT zu tun hat, was man aber echt mal sehen muss – schwebende Kacheln:
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.
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!
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!
