Hallo zusammen, ich habe seit einiger Zeit ein Problem, bei dem mir so langsam die Ideen ausgehen. Aus diesem Grund hoffe ich auf den ein oder anderen Hinweis oder Ideen zur Fehlersuche. Situation: Die im Anhang befindliche Schaltung zeigt einen Master (in meinem Fall einen Zynq 7000), der über I2C auf 2 Slaves (ADC53401 von TI) zugreifen soll. Da die Versorgungsnetze des Masters und der beiden Slaves getrennt sein müssen, wurde eine ADUM1250 zur galvanischen Trennung eingesetzt. Sekundärseitig vom galvanischen Trenner befinden sich dann die SCL und SDA Leitung jeweils mit einem 4k7 Pull-Up gegen die geeignete Versorgungsspannung. Die beiden Slaves hängen wie ihr sehen könnt dann wie üblich am I2C Bus. Problem: Ich kann mit dem Master immer nur einen der beiden Slaves finden, obwohl die Adresse unterschiedlich ist. Da ich mehrere Boards habe, konnte ich das auch auf unterschiedlichen Boards verifizieren. Es ist allerdings so, dass auf einem Board auch immer nur einer der beiden Slaves - und dieser ändert sich nicht - erreichbar ist. Ich habe den Eindruck, einer der beiden Slaves unterdrückt den Anderen, und zwar reproduzierbar. Die I2C Signale auf beiden Seiten des ADUM1250 habe ich mir angesehen, sieht alles einwandfrei aus. Wenn ein Slave nicht erkannt wird, geht die SDA Leitung über den Pull-Up steil nach oben, der Slave macht keinen Anstalten die Leitung nach unten zu ziehen um sein Acknowledge zu geben. Um die gesamte Schaltung unabhängig von meinem Board zu überprüfen, habe ich den Verbund aus Zynq 7000 + ADUM1250 + 2x ADC53401 mit Eval Boards aufgebaut. Damit funktioniert alles wunderbar und beide Slaves lassen sich ansprechen. Ich gehe daher von einem spezifischen Fehler auf meiner Schaltung bzw. meinem Board aus. Habt ihr irgendwelche Denkanstöße für meine grauen Zellen? Ich bedanke mich im Voraus für jeglichen Hinweis. Viele Grüße Felix
Angehängte Dateien:
-
2022-08-05_17h38_05.png
100 KB
Genau, ich nutze die Pull-Ups der FPGA Pins welche ich im constraints file definiert habe. Ich habe es aber auch schon mit/ohne im Vergleich versucht, macht keinen Unterschied.
Hat zufällig jemand von Euch weitere Ideen? Ich bin für jeden Hinweis, jede Frage und jeden Denkanstoß dankbar...
Felix F. schrieb: > Um die gesamte Schaltung unabhängig von meinem Board zu überprüfen, habe > ich den Verbund aus Zynq 7000 + ADUM1250 + 2x ADC53401 mit Eval Boards > aufgebaut. Damit funktioniert alles wunderbar und beide Slaves lassen > sich ansprechen. Ich gehe daher von einem spezifischen Fehler auf meiner > Schaltung bzw. meinem Board aus. Das bedeutet: mit dem selben Code, den selben Bausteinen und der selben Verdrahtung funktioniert es im fliegenden Aufbau? Aber die gleiche Schaltung zickt auf deiner Hardware? Felix F. schrieb: > Da ich mehrere Boards habe, konnte ich das auch auf unterschiedlichen > Boards verifizieren. > Es ist allerdings so, dass auf einem Board auch immer nur einer der > beiden Slaves - und dieser ändert sich nicht - erreichbar ist. Der so ansprechnbare DAC funktioniert dann auch wie erwartet? > Ich habe den Eindruck, einer der beiden Slaves unterdrückt den Anderen, > und zwar reproduzierbar. Abhängig vom Board kann der ansprechbare DAC aber auch der andere sein? Was passiert, wenn du den "ansprechbaren DAC" außer Betrieb setzt oder ihm eine andere Adresse gibst? (das ist dann übrigens auch der Grund, warum ich solche Adressleitungen immer über einen Widerstand nach Vcc bzw. GND führe: Widerstand raus und ich habe den Pin zur freien Verdrahtung. Du brauchst jetzt halt ein Messer. Viel Glück ;-)
Lothar M. schrieb: > Felix F. schrieb: >> Um die gesamte Schaltung unabhängig von meinem Board zu überprüfen, habe >> ich den Verbund aus Zynq 7000 + ADUM1250 + 2x ADC53401 mit Eval Boards >> aufgebaut. Damit funktioniert alles wunderbar und beide Slaves lassen >> sich ansprechen. Ich gehe daher von einem spezifischen Fehler auf meiner >> Schaltung bzw. meinem Board aus. > Das bedeutet: mit dem selben Code, den selben Bausteinen und der selben > Verdrahtung funktioniert es im fliegenden Aufbau? Aber die gleiche > Schaltung zickt auf deiner Hardware? Genau so ist es... Alles was auf meinem Board zu dieser Funktion war, konnte ich mit einem Eval Board als Träger für den Zynq + 2x ADUM1250 Eval Boards + 2x DAC53401 Eval Board nachbasten. > Felix F. schrieb: >> Da ich mehrere Boards habe, konnte ich das auch auf unterschiedlichen >> Boards verifizieren. >> Es ist allerdings so, dass auf einem Board auch immer nur einer der >> beiden Slaves - und dieser ändert sich nicht - erreichbar ist. > Der so ansprechnbare DAC funktioniert dann auch wie erwartet? Ja, der funktioniert wir erwartet. >> Ich habe den Eindruck, einer der beiden Slaves unterdrückt den Anderen, >> und zwar reproduzierbar. > Abhängig vom Board kann der ansprechbare DAC aber auch der andere sein? Genau, das hängt vom Board ab, ändert sich dann aber nicht. Irgendein Effekt bügelt den jeweils anderen DAC zusammen, sodass dieser seinen Dienst gar nicht erst aufnimmt. > Was passiert, wenn du den "ansprechbaren DAC" außer Betrieb setzt oder > ihm eine andere Adresse gibst? > > (das ist dann übrigens auch der Grund, warum ich solche Adressleitungen > immer über einen Widerstand nach Vcc bzw. GND führe: Widerstand raus und > ich habe den Pin zur freien Verdrahtung. Du brauchst jetzt halt ein > Messer. Viel Glück ;-) Ja, das ist mir leider durch gerutscht und sollte wie du sagt der Standard sein. Die Abstände sind dermaßen eng und durch den fehlenden 0R Widerstand an den Adress-Pins wird es echt tricky. Kannst du dir Vorstellen, dass hier ein Problem liegt? Also das über die Festlegung der Adresse ich den anderen DAC lahmlegen kann? Lothar, vielen Dank für deine Ideen! Ein frischer Blick auf die Sache hilft immer weiter.
Felix F. schrieb: > Hat zufällig jemand von Euch weitere Ideen? > Ich bin für jeden Hinweis, jede Frage und jeden Denkanstoß dankbar... Oszi ranhängen und messen: - was machen die isolierten SDA2 und SCL2, wenn der "funktionierende" Slave angesprochen wird? - was machen SDA2 und SCL2, wenn der "nicht funktionierende" Slave angesprochen wird? - diesselben Messungen nochmal für SDA1 und SCL1 durchführen. Damit sollte sich zumindest unterscheiden lassen, ob wirklich der Slave nicht wie gewünscht reagiert, oder ob das Problem in deiner weiteren Signalkette liegt.
Angehängte Dateien:
-
2022-08-10_10h33_24.png
92 KB
Achim S. schrieb: > Felix F. schrieb: >> Hat zufällig jemand von Euch weitere Ideen? >> Ich bin für jeden Hinweis, jede Frage und jeden Denkanstoß dankbar... > > Oszi ranhängen und messen: > - was machen die isolierten SDA2 und SCL2, wenn der "funktionierende" > Slave angesprochen wird? > - was machen SDA2 und SCL2, wenn der "nicht funktionierende" Slave > angesprochen wird? > - diesselben Messungen nochmal für SDA1 und SCL1 durchführen. > > Damit sollte sich zumindest unterscheiden lassen, ob wirklich der Slave > nicht wie gewünscht reagiert, oder ob das Problem in deiner weiteren > Signalkette liegt. Hallo Achim, Oszi Messungen habe ich, hier mal der Fall in dem die Adresse 0x48 ein Acknowledge bekommt, die 0x49 nicht. Fällt euch bei der Messung irgendwas Verdächtiges auf?
Hallo, kannst du auch mal ein Bild von deiner Platine machen ? Evtl. sieht man ja was, was dir gar nicht mehr auffällt. Schon komisch das es auf n Eval Board funktioniert und auf deiner PCB nicht. jetzt mal wild geraten.. schonmal geguckt ob ein nachfolgender OP defekt ist und den Out des ADC kurzschließt und sich dadurch nicht mehr ansprechen lässt ? Gruß
STK500-Besitzer schrieb: > Wo misst du das? Die Frage ist egal. Ich hatte mich wegen "ADuM" verguckt.
Felix F. schrieb: > Kannst du dir Vorstellen, dass hier ein Problem liegt? Also das über die > Festlegung der Adresse ich den anderen DAC lahmlegen kann? Du musst "das Problem" vereinfachen und aufteilen. Und es dann Schritt für Schritt angehen. Aus diesem Grund wäre es wichtig, herauszufinden, was denn sicher geht und ob das reproduzierbar ist. So was simples wie "Ist Benzin im Tank?", also schlicht die Durchgängigkeit und Stabilität der Versorgung hast du sicher schon kontrolliert.
Felix F. schrieb: > Oszi Messungen habe ich, das ist auf der isolierten Seite gemessen? und dem Signal voraus ging eine korrekte StopCon? dann würde ich auch vorschlagen: am nicht funktionierenden DAC messen, ob irgendwas"komisch" ist. (Spannungseinbruch, fehlender Kontakt, ...) dazu alle Pins des Baustein durchmessen und wirklich auf den Pins messen (nicht auf der Leiterbahn neben dem Pin)
Was ist das mit dem A0 am DAC 53401. Woran ist der angeschlossen? Wenn der floatet gibt es unterschiedliche Slave Adressen? Oder wie habe ich das zu interpretieren?
PittyJ schrieb: > Was ist das mit dem A0 am DAC 53401. Woran ist der angeschlossen? Schau mal in den Schaltplan. Jeweils mit +5V und GND.
Lothar M. schrieb: > So was simples wie "Ist Benzin im Tank?", also schlicht die > Durchgängigkeit und Stabilität der Versorgung hast du sicher schon > kontrolliert. Das Wort SICHER würde ich bei so einer Kommunikation ersatzlos streichen! Man sollte JEDE noch so triviale Sache SOLIDE prüfen, DANACH kann man vielleicht sicher sein. Siehe Fehlersuche.
Falk B. schrieb: > PittyJ schrieb: >> Was ist das mit dem A0 am DAC 53401. Woran ist der angeschlossen? > > Schau mal in den Schaltplan. Jeweils mit +5V und GND. Im Schaltplan schon. Aber was liegt da wirklich an?
Hast du mal versucht über die Broadcastadresse aus dem Datenblatt beide gleichzeitig anzusprechen? Wie verhält sich der nicht funktionierende Chip dann? Wenn er funktioniert, scheinst du ein Adressproblem zu haben.
Ein aktuelles Beispiel zum Thema "ich bin sicher" ;-) Beitrag "Bus-powered FT232RL geht nur manchmal" " Viel an Aufbau-Hinweisen hat ja das Datenblatt nicht ;), die, die es hat, habe ich eingehalten."
Angehängte Dateien:
-
2022-08-10_14h19_39.png
44 KB
Lothar M. schrieb: > Felix F. schrieb: >> Kannst du dir Vorstellen, dass hier ein Problem liegt? Also das über die >> Festlegung der Adresse ich den anderen DAC lahmlegen kann? > Du musst "das Problem" vereinfachen und aufteilen. Und es dann Schritt > für Schritt angehen. Aus diesem Grund wäre es wichtig, herauszufinden, > was denn sicher geht und ob das reproduzierbar ist. > > So was simples wie "Ist Benzin im Tank?", also schlicht die > Durchgängigkeit und Stabilität der Versorgung hast du sicher schon > kontrolliert. Ich bin ehrlich, da ich bisher mit der Versorgung keinerlei Probleme hatte, habe ich mir diese noch nicht in diesem Zusammenhang angeschaut. Ich werde dazu morgen mal Messungen machen, ob die Versorgung stabil ist. Was ich aber schon mal beisteuern kann, ist ein Screenshot in dem man sieht, wie ich mir die Versorgung zusammenbaue, siehe Anhang. Die +L12V0 speise ich mit einem ordentlichen Netzteil ein mit ausreichender Strombegrenzung. Die Dimensionierung der Widerstände rund um "DC2" habe ich eben nochmal kontrolliert, entspricht dem Datenblatt...
Achim S. schrieb: > Felix F. schrieb: >> Oszi Messungen habe ich, > > das ist auf der isolierten Seite gemessen? und dem Signal voraus ging > eine korrekte StopCon? dann würde ich auch vorschlagen: am nicht > funktionierenden DAC messen, ob irgendwas"komisch" ist. > (Spannungseinbruch, fehlender Kontakt, ...) dazu alle Pins des Baustein > durchmessen und wirklich auf den Pins messen (nicht auf der Leiterbahn > neben dem Pin) Die Messungen habe ich auf der Sekundärseite des ADUM1250 gemacht, da dieser noch eine Bauform hat, an die ich Messleitungen anlöten konnte. Bei den DAC53401 Teilen kriege ich das nicht mehr hin, die Pins sind so klein und kaum zu erreichen. Aber da du auf fehlenden Kontakt o.Ä. anspielst: Eventuell gibt es ja bei der Bestückung dieser DACs ein Problem. Möglicherweise wird die Fläche nicht ordentlich erhitzt oder es ist zu wenig Lötzinn vorhanden. Viel machen kann ich da selbst nicht, aber ich könnte den Bereich und das Bauteile bzw. die beiden Bauteile mal moderat mit dem Heißluftföhn bearbeiten.
PittyJ schrieb: > Falk B. schrieb: >> PittyJ schrieb: >>> Was ist das mit dem A0 am DAC 53401. Woran ist der angeschlossen? >> >> Schau mal in den Schaltplan. Jeweils mit +5V und GND. > > Im Schaltplan schon. Aber was liegt da wirklich an? Ja, die A0 Pins der DACs sind ordentlich angeschlossen. Die Verbindung zu +E5V0 bzw. EGND habe ich durchgemessen direkt am DAC...
MaWin schrieb: > Hast du mal versucht über die Broadcastadresse aus dem Datenblatt beide > gleichzeitig anzusprechen? Wie verhält sich der nicht funktionierende > Chip dann? Wenn er funktioniert, scheinst du ein Adressproblem zu haben. Auch über den Broadcast kann ich jeweils nur einen DAC finden. Leider habe ich mit dem Broadcast Versuch keine Messungen aufgezeichnet, das kann ich aber morgen nachholen und werde dies auch tun. Ist sicher kein Fehler sich auch das mal anzuschauen was da auf dem Bus wirklich passiert.
Hi Felix, ein Versuch mit der Broadcast-Adresse waere auch meine erste Vermutung gewesen, aber das scheint es nicht zu sein... Mehrmals "draufballern" duerfte auch nix bringen... Wenn bei dem Aufbau mit den Evalboards alles funktioniert, dann gibt es doch bestimmt groessere Unterschiede bei: * Spannungsversorgung (der Baustein scheint aber keine besonderen Anforderungen zu haben, auch wird die A0-Adresse mit jedem Kommando neu gesamplet) * Layout-Guidelines, das DB gibt da recht konkrete Hinweise/Anforderungen Habt ihr das ueberprueft?
Felix F. schrieb: > Auch über den Broadcast kann ich jeweils nur einen DAC finden. Wie stellst du da fest, dass irgendwas "gefunden" wurde? Denn beim Broadcast empfängt der Master ja nichts, es wird laut Datenblatt nur gesendet: "Broadcast is supported only in write mode." Felix F. schrieb: > Ja, die A0 Pins der DACs sind ordentlich angeschlossen. Die Verbindung > zu +E5V0 bzw. EGND habe ich durchgemessen direkt am DAC... Wurden die ICs manuell gelötet?
Lothar M. schrieb: > Felix F. schrieb: >> Auch über den Broadcast kann ich jeweils nur einen DAC finden. > Wie stellst du da fest, dass irgendwas "gefunden" wurde? Denn beim > Broadcast empfängt der Master ja nichts, es wird laut Datenblatt nur > gesendet: "Broadcast is supported only in write mode." Ähm, da hast du mich jetzt. Das muss ich mir nochmal anschauen. Ich nehme das mit und gebe dann ein Update. Danke für den Hinweis... > Felix F. schrieb: >> Ja, die A0 Pins der DACs sind ordentlich angeschlossen. Die Verbindung >> zu +E5V0 bzw. EGND habe ich durchgemessen direkt am DAC... > Wurden die ICs manuell gelötet? Da ich die Bestückung nicht selbst mache, muss ich mich hier schlau machen. Ich gehe aber zu 99% von einer maschinellen Bestückung und Verlötung aus. Das Bauteil sitzt einfach zu gerade für eine manuelle Arbeit.
Felix F. schrieb: > Das Bauteil sitzt einfach zu gerade für eine manuelle > Arbeit. Lass das nicht eine Feinlöterin (typischer Frauenberuf. Bei uns ist die LP-Fertigung komplett weiblich) hören. Dann gibt das was auf die Ohren.
Angehängte Dateien:
-
Untitled_picture.png
11 KB
Gestern konnte ich einige Euren Anregungen überprüfen mit folgenden Ergebnissen: 1) Defekte OPs nach dem DAC? Eventuell Kurzschluss an deren Ausgängen? R14 + R48 entfernt, somit beide ADCs lastfrei Keine Auswirkungen auf Problematik 2) +E5V0 Versorgung prüfen und messen, während I2C Zugriff Es konnten keine Einbrüche auf dem +E5V0 Netz festgestellt werden Gemessen mit dem Oszi mit segmentiertem Speicher 3) Broadcast senden und mit Oszi aufzeichnen Broadcast an die Adresse 0x47 wird mit einem ACK bestätigt, vermutlich zieht somit mindestens ein Slave SDA auf low, hilft uns also hier nicht weiter Die gesendet Daten können ignoriert werden... Oszi Aufnahme im Anhang 4) Lötstellen der betroffenen Bauteile kontrollieren Sieht alles soweit i.O. Ich werde die Platinen dennoch nächste Woche vom Zulieferer prüfen lassen. 5) Layout Regeln für DAC53401 eingehalten? Layout Vorgaben aus Datenblatt dienen als Beispiel Mit Ausnahme der beiden PU and SLK und SDA wurde Alles weitestgehend beachtet Die beiden fehlenden PU wurden manuell nachgerüstet Aufgefallen ist mir noch ein weiterer Punkt zu dem ich noch nicht herausgefunden habe: Auf meinen Board ist der VFB Pin nicht angeschlossen, also n.c. Dies ist ein Unterschied im Vergleich zu den verwendeten Eval Boards mit denen der Zugriff funktioniert hat. Ich kann mir aber nicht vorstellen warum dies Auswirkungen auf die Adressierung bzw. den ACK haben soll. Soweit mal der aktuelle Stand. Ich freue mich auf Eure Kommentare in der Hoffnung, dass ich noch nicht am Ende bin :-)
:
Bearbeitet durch User
Felix F. schrieb: > 3) Broadcast senden und mit Oszi aufzeichnen > Broadcast an die Adresse 0x47 wird mit einem ACK bestätigt, vermutlich > zieht somit mindestens ein Slave SDA auf low, hilft uns also hier nicht > weiter > Die gesendet Daten können ignoriert werden... > Oszi Aufnahme im Anhang Naja, dann wäre hier vielleicht der Ausgang des DAC interessant, ob beide einen gleichen Signalverlauf haben, wenn du per Broadcast z.B. ein Dreieck/Rechteck simulierst. Weil wie du bereits festgestellt hast, sagt das ACK nicht viel aus... Schon mal die anderen 2 Adressen versucht (0x94, 0x96)? Rein für Fehler oder gleiches nACK Verhalten zu simulieren? Der A0-Pin lässt sich ja auf 4 Varianten anschliessen um 4 Adressen zu generieren
:
Bearbeitet durch User
In einem Thread im TI-Forum wird empfohlen, die Spannung an Pin 4 (Cap für internen LDO) nachzumessen. Sie muss zwischen 1,55V und 1,6V liegen, wenn der Baustein korrekt hochgepowert ist. Ansonsten würde ich weiter versuchen, die Spannungsverläufe an allen Anschlusspins nachzumessen. Mir ist klar, dass man nicht gut rankommt und der Pitch ziemlich eng ist. Aber mit der (Nadel-)Spitze des Tastkopfs geht an der Seite des Gehäuses ja vielleicht doch was.
Felix F. schrieb: > Ich freue mich auf Eure Kommentare in der Hoffnung, dass ich noch nicht > am Ende bin :-) Was soll das mit dem Broadcast? Sprich ganz normal die korrekte Adresse an! Das muss gehen. Im Zweifelsfall jeweils einen der ICs vom I2C trennen, entweder die Leitungen unterbrechen oder den IC auslöten.
Falk B. schrieb: > Felix F. schrieb: >> Ich freue mich auf Eure Kommentare in der Hoffnung, dass ich noch nicht >> am Ende bin :-) > > Was soll das mit dem Broadcast? Sprich ganz normal die korrekte Adresse > an! Das muss gehen. Im Zweifelsfall jeweils einen der ICs vom I2C > trennen, entweder die Leitungen unterbrechen oder den IC auslöten. Lieber Falk, ich versuche es mal mit deinen Worten zu sagen: "Die Wörter DAS MUSS GEHEN würde ich bei so einer Kommunikation ersatzlos streichen! Man sollte JEDE noch so triviale Sache SOLIDE prüfen, DANACH kann man vielleicht sicher sein. Siehe Fehlersuche." Ich versuche mir Mühe zu geben in meinem Beiträgen und bin für jede KONSTRUKTIVE Hilfe dankbar. Wer das anders sieht, darf gerne still mitlesen ;-)
Felix F. schrieb: > Ich versuche mir Mühe zu geben in meinem Beiträgen und bin für jede > KONSTRUKTIVE Hilfe dankbar. Wer das anders sieht, darf gerne still > mitlesen ;-) Das ist aber nur Rumgestochere. Fehlersuche sieht so aus, dass eben NUR der "fehlerhafte" Baustein am Bus hängt.
Also ich würde eher beim DAC anfangen zu suchen. TI hat einem damit viel Schlangenöl eingeträufelt. 1. Man kann die Geschwindigkeit des I2C-Buses in einem Register setzen. Dadurch ändern sich aber die erlaubten rise and fall Zeiten für die Signalen. Das könnte ein Problem sein. Besonders, falls der Baustein doch schon vorkonfiguriert wurde. 2.Der Adresspin für die I2C-Adresse hat leider 4 mögliche Einstellungen. Mit Anschluß an SCL hat man eine weitere mögliche Adresse oder auch an SDA. Fragt nicht was TI dort gemacht hat.Wenn der Adresspin in der Luft hängt, sind auch zwei weitere Adressen möglich. 3. Die Kapazitäten für die Spannungsversorgung mit LDO sind nur mit einem Nebensatz erwähnt. Aber gerade dieser Bereich kann zu Schwingen anfangen und damit den Baustein außer Funktion. Besonders die 10µF am CAP-Pin würde ich näher an die Empfohlenen von 1,5µF bringen. 4.Wenn der FB-Pin nicht angeschlossen ist, gibt es auch nur Ärger. Natürlich ist der ADUM1250 auch nicht ohne, weil durch die Rückkopplung bei Störungen das Signal kippen könnte.
Es gibt Neuigkeiten: Nach der Inbetriebnahme weiterer Boards der gleichen Version hat sich auch hier dasselbe Fehlerbild gezeigt. Aus der Verzweiflung heraus habe ich daraufhin eine ältere Version der Boards nochmals heran genommen, habe mir aber nicht viel davon erhofft, da sich der relevante Schaltungsteil nicht verändert hat, weder im Schaltplan noch im Layout. Also das Zynq Modul wie es ist rüber auf das ältere Board gesteckt und... ... siehe da: Mit der älteren Board Version funktioniert der I2C Bus mit beiden Slaves problemlos. Vorläufiges Fazit derzeit: Es muss doch irgendeinen Unterschied geben, eventuell auch Bestückungs- oder Lötfehler. Optisch konnte und mit "Durchmessen" konnte ich selbst aber nichts feststellen. Die Boards befinden sich nun beim Zulieferer zur Analyse - bin gespannt was raus kommt und werde berichten. Bis hierhin schon einmal vielen Dank für Eure Hilfe! Tolles Forum!
OMG! Was für eine schwache Leistung! DU bist derjenige, der den Fehler finden muss, nicht der Bestücker! Denn DU bist der Entwicklungsingenieur. Aber offensichtlich hast du weder Ahnung von Hardware noch Bock zur Fehlersuche. Naja. Fachkräftemangel und so . . .
Falk B. schrieb: > OMG! Was für eine schwache Leistung! DU bist derjenige, der den Fehler > finden muss, nicht der Bestücker! Denn DU bist der > Entwicklungsingenieur. Aber offensichtlich hast du weder Ahnung von > Hardware noch Bock zur Fehlersuche. Naja. Fachkräftemangel und so . . . Da DU offenbar zu ALLEM was zu sagen hast, bin ich gespannt was die Moderatoren zu deinem Beitrag sagen. Diesen habe ich soeben gemeldet. Ich bitte dich persönliche Beleidigungen ohne Hintergründe (Arbeitsorganisation, Zusammenarbeitsmodelle, ...) zu kennen zu unterlassen. Dies ist mein letzter Beitrag in deine Richtung!
Felix F. schrieb: > Da DU offenbar zu ALLEM was zu sagen hast, bin ich gespannt was die > Moderatoren zu deinem Beitrag sagen. Diesen habe ich soeben gemeldet. > Ich bitte dich persönliche Beleidigungen ohne Hintergründe > (Arbeitsorganisation, Zusammenarbeitsmodelle, ...) zu kennen zu > unterlassen. > Dies ist mein letzter Beitrag in deine Richtung! Wo ist denn in Falks Beitrag eine Beleidigung? Bloß, weil er die Wahrheit sagt?
Felix F. schrieb: > Da DU offenbar zu ALLEM was zu sagen hast, bin ich gespannt was die > Moderatoren zu deinem Beitrag sagen. Diesen habe ich soeben gemeldet. Ach wie süß, er geht zur Mutti petzen ;-) > Ich bitte dich persönliche Beleidigungen ohne Hintergründe > (Arbeitsorganisation, Zusammenarbeitsmodelle, ...) zu kennen zu > unterlassen. Wahre Worte sind nicht schön. Schöne Worte sind nicht wahr. Laotse > Dies ist mein letzter Beitrag in deine Richtung! Adios, Companero!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.