SMTP Emailversand

Hallo an alle,
Ich bin recht frisch bei der Sache, habe vergangenes Jahr die LV Kuse Core 1 und 2 besucht und bin nun in der aktiven Lernphase indem ich mich an einem grösseren Projekt abarbeite. Bisher liefs auch ganz gut, mit Forumslesen undder LV-Hilfe und Beispielen gings immer irgendwie weiter. Doch nun stehe ich auf dem Schlauch. Die Baustelle ist der Versand von Fehlemeldungen per Mail. Ich sammle Fehlermeldungen wie z.B Endschalter nicht erreicht, in einer täglichne Datei, zeige sie auf dem Frontpanel und möchte das ganze einmal am Tag versenden, so denn was vorhanden ist. Ich habe gestern das Mail-Vi probiert, was mir immer Fehler ausgab, dann das Beispiel aus LV, auch immer Fehler. Firewall ausgeschaltet, Mailaccount neu eingerichtet, auf anderem Rechner (MAC statt WIN) probiert, aber keinen Erfolg. Mit den SMTP-vi's bin ich dann endlich erfolgreich gewesen. Nun hab ich das heute in mein Programmteil eingebaut und was soll ich sagen - geht nicht. Fehler 56. Einstellungen wie beim test-vi, mehrmals überprüft. Der Test geht immer noch, mein Programmbaustein nicht. Die Verzweiflung rückt näher. Hat da jemand irgendeine Idee? Ich könnte auch die Datei mittels eines Batch jobs versenden, find ich aber nicht so elegant und ich wollte dem Problem erstmal nicht ausweichen.

Gruß
Ed    
  SendMail.vi (Größe: 17,46 KB / Downloads: 239)

  WritingDailyErrorFiles.vi (Größe: 56,17 KB / Downloads: 237)

Anzeige

Hallo Mistered,

bei deinem zweiten VI fehlen leider einige SubVis und Controls, so dass es bei uns nicht lauffähig ist.

Dein Ansatz ist genau der richtige: Erstmal ein Minimalbeispiel zum laufen kriegen und dann weiter ausbauen. Da der Inhalt deines Cases "SendMail" ja identisch mit dem funktionierenden VI is, würde ich vermuten, dass der Fehler in der Logik deiner StateMachine liegt. Ich würde zunächst:

- Use Default if unwired deaktivieren und immer alle Drähte manuell verkabeln.
- einen Stop Knopf zur Beendigung der While Schleife verwenden. Aktuell muss man das VI ja hart beenden - das ist für Referenzen die da in der Luft hängen nicht optimal.

Du öffnest im Case "WriteFile" die Datei mit write-only, gehst dann aber auf ReadFile...?
Versuche mal die Datei vor der While Schleife (oder im Init-Case) einmal zu öffnen, drinnen nur noch zu schreiben und zu lesen und nach der While Schleife (oder in einem Stop-Case) wieder zu schließen. Oder, falls das VI tagelang laufen soll, und nur selten die read und write cases ausgeführt werden, öffne und schließe die Referenz in beiden cases sauber.

Tut mir leid, dass ich zum eigentlichen Problem nicht viel sagen kann. Versuche mal das funktionierende Minimalbeispiel Schritt für Schritt auszuweiten bis du an dem Punkt kommst, an dem es nicht mehr funktioniert. Oder lad alle VIs hoch, die wir zum testen benötigen...

Schönen Gruß,
seuk

Edit:     Alternative SMTP Option hinzugefügt

Dann dreh doch mal den Time-Out am Send-VI höher als 10 Sekunden!!! Offensichtlich ist dein Error-Text länger als "Test".

Fehler 56: The network operation exceeded the user-specified or system time limit.

Gruß, Jens

Hallo,
vielen Dank für die Rückmeldungen.
Dieses vi ist für eine Steuerung, die für Dauerbetrieb gedacht ist. Ich fürchte aber, irgendwas wird das alle paar Wochen mal unterbrechen, Hard- oder Software, da gibts viele Möglichkeiten.
Zum WriteFile, du meinst, ich sollte das ReadFile Case weglassen und alles in einem machen? Ok, werd ich so mal versuchen. Ich habe im SendFile auch noch einmal ein Read, sollte das besser auch geschlossen werden?
Und nun zur Hauptsache, ich habe das Problem gelöst oder besser beseitigt. Es brauchte nur einen Neustart vom Rechner Kopf>Tisch! Warum das andere VI parallel funktionierte-Keine Ahnung. Jetzt laufen beide.
Vielen Dank!

Hey,

ich würde dir empfehlen mal ein Blatt Papier in die Hand zu nehmen und etwas die Zustände zu designen. Hier mal ein Beispiel deiner Cases:

   

Hier sieht man schön, dass du nach deinem Write File auch direkt zu Wait For Write gehen könntest und das Read File einfach mit im Write File Case machen könntest. Warum überhaupt die Datei schreiben und sofort wieder einlesen? Den Textindikator könntest du auch so updaten...

Auffällig ist auch, dass es keinen Endpunkt gibt.

Für die Dateioperationen: Wie oft wird da reingeschrieben und ausgelesen? Du solltest die Referenzen wenn du sie öffnest auch immer sauber schließen.

Lies dir auch nochmal etwas zum Thema State Machine durch. Evtl. kannst du das gedanklich auch noch vereinfachen. Erfahrungsgemäß kommen später immer mehr Funktionen hinzu und dann ist man froh, wenn man bereits möglichst klein und strukturiert angefangen hat, z.B. Trennung in mehreren Modulen:
a) Fehlerüberprüfung --> Loggen in Datei
b) einmal am Tag, check ob Datei vorhanden. Ggf. versenden und löschen oder umbenennen

Gruß,
seuk

Moin,
ich sehe Du hast Dich damit richtig beschäftigt. Vielen Dank, auch für die Denkanstösse, braucht man manchmal...
---Falls das jetzt zu sehr aus dem Thema läuft, bitte an den richtigen Platz verschieben----
Dein Ablaufdiegramm ist soweit richtig, ich muss aber leider sagen, dass ich diese nur im Kopf habe. A) weil sich das im Laufe des Programmierens oft ändert und b) weil ich zu faul bin . Der NewFile Case war mal gedacht, um täglich eine neue Datei zu schreiben. Der ist mittlerweile entsorgt, der Rest ist so geblieben. Bei Programmstart wird in Init jetzt die Tagesdatei erzeugt. Danach pendelt es im Normalfall zwischen WfW und WfS hin und her. im ersten wird auf einen Fehler gewartet, tritt er ein wird er in WF in die durch Init erzeugte Datei geschrieben. Danach in RF ausgelesen.
Ich weiss, dass das auch direkt gehen kann, aber ich möchte zum einen sicherstellen, dass auch korrekt geschrieben wurde (ich habe das Vorgängerprogramm mit einer anderen Software geschrieben, dort traten zum Teil Schreibfehler auf. Da alle Dateien später weitgehend automatisiert ausgewertet werden, sind Dateifehler sehr störend, das bricht alles ab und zieht erfahrungsgemäss lange Suchen nach sich. Ich hoffe das erledigt sich durch LabView). Da ich das dann per Mail bekomme, kann ich eventuelle Fehler gleich korrigieren. Zum anderen läuft dieses Programm unbeaufsichtigt, im Falle eines wie auch immer bedingten Neustarts wären diese Fehler aus der Anzeige verschwunden. Das kann so nicht passieren.
Im WfS Case wird zu einer bestimmten Uhrzeit zum SF Case weitergeleitet um das tägliche File zu senden. Hierbei wird bei leeren Dateien (also kein Fehler im letzten Tag) ein anderer Header geschrieben als bei Dateien mit Inhalt. So kann man gleich sehen ob alles soweit läuft. Lebenszeichen sozusagen. Ist auch wichtig, da alle Dateien weiterverarbeitet werden und man so sicher weiss, das alles in Ordnung war. Keine Datei kann ja auch ne verlorene Datei sein.
Nach dem Senden gehts zurück auf Los und es werden leider keine 4000Euro eingezogen, ne, auf Init und die neue Tagesdatei erzeugt und das Spiel geht von vorn los.
Ich für meine Teil halte das für brauchbar und übersichtlich strukturiert, man muss ja auch später schnell wieder eine Übersicht bekommen. Sicher kann man das noch komprimieren, wahrscheinlich werde ich auch mit fortgeschrittener Routine mal mit anderen Augen drauf blicken und mich schütteln, aber erstmal erscheint mir das für mich ganz ok zu sein.
Ich hoffe, diese Erklärung überzeugt erstmal.

Insgesamt ist diese Geschichte schon recht komplex, die VI-Properties sagen da was von 8. Die 9 werde ich wahrscheinlich nicht ganz erreichen. Jetzt kümmer ich mich mal um die Initialisierungsdatei mit Read/write Anything, was mir empfohlen wurde.

Vielen Dank für den Input, kann gut sein dass ich mich nochmal melde. Aber erst nach nem Neustart

Gruß
Ed