Hallo,

USB und serielle schnittstelle duerften da nicht viel bringen, da sie je nach protokoll eigtl ne abfolge von signalen aussenden und kein klares on oder off.

bei serieller schnittstelle könntest du aller aller hoechstens eines der steuersignale abgreifen...
aber werde jetzt hier nicht aufdroeseln welcher pin dafuer geeignet ist.

was den strom und die spannung angeht ... meineserachtens gibt es zwar netzteilmaessig ne 12V versorgung fuer die Motoren der Fetsplatte und DVD-Laufwerke aber gesteuert bekommt sie glaube nicht raus. Ganz zu schweigen vom Strom. Denn es kommt auf die Bauart des Releais an, wieviel strom so ein relais zieht. manche ziehen bis zu einem Ampere (motorschuetze was zwar hier bestimmt nicht gemeint ist, aber nen extremfall darstellt) was dann die belastbarkeit einiger steuerchips auf dem mainboard arg ueberschreitet.

Eine moeglichkeit etwas vom rechner aus gut azusteuern is meist noch der parallelport, den du dann aber wirklich ueber ne zwischenplatine schalten solltest. entweder nen zwischenrelais oder nen vorsteuer transistor (stichwort Treiber / OPV).

Gruß, Hermann

Also

danke nochmal für die Hilfe und die Artikelinfos.

Du könntest sogar alles hier von abkupfern:

Ich hab es mir angeschaut, und meine verarbeitung war/ist im Grunde nicht viel anders. Anstatt dem scan nach Environment.Newline, verwende ich aufgrund der eigenheit des Embeddetboards
serialportobj.WriteLine(string ...)
Und ich habe nicht so viele try catches drin. Das grundprinzip ist dennoch das selbe.

Für den Anfang hat der hack mit Application.DoEvent in der While(true) Schleife witzigerweise zuverlässig geholfen.

Ich baue nun aber (da es ja nun einen funktionierenden schnellen wurf gibt) das ganze nochmal mit einem Backround workerthread und eventbasierend um. Nur diesmal endlich mit etwas mehr ruhe.

Gruß, Hermann

danke erstmal für die Antworten, auch wenn sie, so wie ich es lese, mehr auf meine erste Frage eingehen (die mit der While{ } schleife) statt auf meine 2. frage mit dem Debugger.
(ich hoffe ja es wurde bis zuende gelesen ... ich weiss es ist recht viel)
Wie gesagt, die while Schleife hatte ich ja auch erstmal wieder abgebaut.

Anschliessend dann die sache (wie herbivore ja auch schon sagt, und in seinem beispiel mit "warum blockiert meine GUI -> Nehme System.Windows.Forms.Timer auch bestaetigt) nur noch durch das Data_receive event und den Timer elapsed event geregelt. Keine Schleife mehr.

Deswegen ja die wichtigere frage, warum werden alle Received Events ordentlich behandelt wenn der Breakpoint da sitzt, und warum nicht wenn er nicht dasitzt.

Ich werde mir das Codebeispiel von Joetempes nochmal genau anschauen, vielleicht hilft es ja weiter.

MfG Hermann

Hallo,

Vornweg: bitte erst zuende lesen, bevor hier auf meine erste Frage komisch reagiert wird.
Wichtiger ist meine zweite frage...

ich habe ein problem mit dem Seriell_Receive Event.
Ich habe eine kleine C#-GUI applikation geschrieben in der ich daten über die Serielle Schnittstelle an einen MicroController sende. Dieser Sendet mir darauf hin nen haufen Daten zurück. Meine applikation kann nun ueber ein Scriptfile gesagt bekommen, dass er auf einen bestimmten Substring(vom Microcontroller) warten soll, biss er den nächsten string an den Microcontroller senden soll.

Kurze daten zur Verbindung: Verwendet wird ein Prolific USB->COM Conwerter und die Einstellungen sind durch den Microcontroller nicht änderbar vorgegeben.

//Serielle konfiguration vorgegeben:
private void SerialPreconfig()
{
	COM.PortName = "COM3";
	COM.BaudRate = 115200;
	COM.DataBits = 8;
	COM.StopBits = StopBits.One;
	COM.Parity = Parity.None;
	COM.ReadTimeout = -1;
	COM.WriteTimeout = -1;
	COM.Handshake = Handshake.None;
}

Da die entwiklung sehr schnell gehen musste habe ich es zuerst ganz schlecht mit einer while(true) schleife des GUI Threads probiert (das die GUI blokiert ist hier völlig egal). Das Data_Received Event der Seriellen schnittstelle sollte das flag new_data_received setzen.

do
{ 
	Thread.Sleep(1000)
}While(new_data_received==false);


private void Seriell_DataReceived(object sender, EventArgs e)
{
	new_data_received = true;
} 

Frage1: Beim durchsteppen im Debugger habe ich gemerkt, dass mich das event erst erreicht wenn ich per debugger die while schleife abbreche und wieder aus der Funktion rausgehe. Warum ist das so? Sollte das Programm durch das Thread.Sleep() nicht in der lage sein irgendwann mittendrin mal die Data_Recieved Routine das flag setzen zu lassen? Bzw gibt es eine Art "Sleep" was dieses Zulässt?

... ok soweit so gut, habe ich das ganze also (auch schnell und weniger durchdacht) umgebaut, und sobald das Scriptfile nun vom C# Programm verlangt auf einen String vom Microcontroler zu warten, das dieser GuiThread einen Timer startet (etwa 1sek Zyklus) und ein warteflag setzt und sich damit beendet.

Sollte nun ein Data_Received Event eintreffen, vergleicht die Routine nun den string und bei übereinstimmung soll dieser das warteflag löschen. Die Timerroutine beendet sich bei gelöschtem Warteflag selbst. Klingt etwas kompliziert... vielleicht ist es mit Code verstaendlicher.

//Auszug aus ScriptFile Auswertungsroutine (MainForm)...
//...
//Soll hier auf ein spezielles Wort gewartet werden ?
else if (ScriptLanguage.CompareSign(TempSendLine, eScriptLangSigns.WAIT_FOR_SPECIAL) == true)
{
	//Übergebe vergleichsstring auf den gewartet werden soll
	SerialHandler.WaitForWordSequence = ExtractSpecialWord(TempSendLine);
	//gehe eine zeile im Script weiter
	SendScriptFileIndex++;
	//Vermerke das auf einen speziellen Substring gewartet werden soll
	SerialPort.WaitForWord = true;
	//Starte timer zum ab und an mal schauen ob vergleichsstring gefunden wurde
	_TimerRefresh.Enabled = true;
	//Beende diesen Sendedurchlauf
	return;
}

//class SerialPort
private void Seriell_DataReceived(object sender, EventArgs e)
{ //+++hier breakpoint+++

    //...speichere Daten aus Lesepuffer...
    //...
    //wird gerade auf einen Bestimmten Substring gewartet
    if (WaitForWord == true)
    {
    	//Handelt es sich um den gesuchten substring?
        if (DataToRecieve.IndexOf(WaitForWordSequence) > -1)
        {
            WaitForWord = false; //Merke es zum beenden des Timerwartens
        }
    }
}

//MainForm Timer Routine
private void TimerRefresh_Tick(object sender, EventArgs e)
{
    if (SerialPort.WaitForWord == false)
    {
        //Disable zuerst sich selbst
        TimerRefresh.Enabled = false;
        //Löse einen neuen Sendedurchlauf aus 
        SendData();
    }
}
 

Bevor ihr den Code auseinandernehmt nun meine eigentliche frage dazu...
Frage 2:
sobald ich dort wo "+hier breakpoint+" steht, einen breakpoint einfuege, funktioniert der ablauf einwandfrei, und jedes mal wenn ich daten vom Microcontroller sende, kommen sie auch als Event an.
Nehme ich den breakpoint weg, oder kompiliere ich es als release, bzw starte es auch extern (nicht ueber VS) dann haengt sich das programm öfters mal auf. So als wenn das Data_Received Event irgendwie verschluckt wird. Oder teilweise garnicht geworfen wird oder so.

Weiss einer warum genau das so ist und ob man was dagegen machen kann.
Ich habe bereits gegooglet und auch hier gesucht, aber ohne dieses Event, also zBsp. mit nem WorkerThread der permanent den Buffer ausliest scheint mir zwar eine lösung, aber eine die doch recht lange dauert es umzubauen.Aufgrund dann auch mehrerer anfallender

Stringoerationen weiss ich nun auch nicht wie performancekritisch diese Workerthreadlösung sein wird.

Warscheinlich gibt es ja etwas wesentlich eleganteres oder etwas was ich übersehen habe.
Für konstruktive Kritik und Vorschläge wäre ich sehr offen.

MfG Hermann

Hallo,

ich verstehe im Mom auch noch nicht so ganz warum das unbedingt über excel laufen muss, ich will dich hier aber nicht zum C# überreden, vielleicht eher im gegenteil...
Ich habe mal ein zwei kleinere GUI-Automationen in C# mittels des white-frameworks geschrieben, und man kann viel damit machen (sofern sich die Steuerelemente in UISpy oder, ähnlichem iidentifizieren lassen).
Jedoch hat es mich pro applikation so ca. 2-3Wochen gekostet. Das war im endeffekt viel aufwand fuer eine wiederkehrende, aber auch bedingte Sequenz von "Knöpfedruecken". Das lag an der grossen Fehlerbahndlung, die Nötig war, wenn sich die GUI anders verhielt als sie im normalfall sollte.

Ich weiss nun nicht, wieviel zeit du hast, bzw wie -anfaellig- die GUI fuer ungeahntes verhalten ist... aber sollte deine GUI irgendwie Messages aus dem CAN auswerten, kann ich mir das gut vorstellen
Aber wenn es dich interessiert, such mal nach dem White-framework (evtl. in verbindung mit nUnit). ansonsten bleibe lieber bei einer Schnittstelle "unterhalb" der GUI, um deine Funktionen automatisiert aufzurufen...

Eine andere etwas -skurile- lösung fuer GUI-automation ist "Sikuli" welches irgendwie über die Farbwerte des Monitorbildes geht oder so, und dort einfach die Maus draufklicken laesst.
Dies ist wesentlich einfacher zu "programmieren" wenn man es ueberhaupt so nennen darf, aber auch nicht sehr -intelligent- was das verhalten angeht.

musst du mal schauen...
ich hoffe ich konnte dir helfen

Hallo, darf ich mich hier auch noch mit reinhaengen, denn ich habe ein aehnliches problem, aber einwenig mehr eine konkrete frage dazu,
Ich habe ein C# Programm welches fuer kurze zeit einen 2en thread erstellt und wieder schliesst. Die beiden Threads haben sonst sogut wie nichts miteinander gemeinsam, keine gemeinsamen variablen oder pramater, oder sonst was.
Das einzige was die beiden verbindet sind konsolenausgaben.

Jetzt aber das problem, ich habe das Prog auf einem rechner geschrieben (Visual Studio 2008 .Net3.0 - Nur im Debugmodus) hier funzt alles reibungslos
Dann hab ichs auf einem anderen rechner (mit hardware und OS maessig nahezu gleicher konfiguration) ueberspielt und dort (nur .net 3.0 installiert aber kein VS) ausgefuehrt. Da stuertzt er jedesmal ab wenn der Thread grade gestartet ist. Ohne VS ja leider nich wiurklich zu debuggen.

KANN das irgendwie mit dem Debugcompile zusammenhaengen ? (dasses evtl. noch an was anderem liegen koennte is mir auch klar) oder ist das auszuschliessen ? ich will ungern staendig zwischen debug und relaese wechseln...

entweder verstehe ich die antwort nicht ganz, oder die frage, oder den zusammenhang.

Wenn PC->Pumpe sendet Dreh 10% dann Dreh 50% dann Dreh100% und dann Dreh 90%

und zurueck kommt ok, ok , error, ok, nicht ok, ok;

kann ich die respones zwar unterscheiden, aber doch nicht ausfriemeln worauf nun der error basiert, der dazwischen geschmissen wurde Oo. Ich weiss nicht genau ob es das ist was der TE damit sagen wollte.

ansatz ist vielleicht, den PC->Pumpe messages, ne art counter zu geben, und diese counternummer in der response wiederzufinden ? ich weiss ja jetzt nicht ob du am pumpencontroler was manipulieren kannst.
Oder eben das normale timingverhalten messen (sofern es sich nicht unterscheidet in verschiedenen faellen) koenntest du es uebers timing ermitteln.

oder ka ob das bei COM auch so war, dass man die uebertragung auf unidirektional stellen konnte. ka ob das dann funzt.

greez HB

ok thx 😃

Warum Zeigt mir die
System.Envireoment.Version immer 2.xxx an obwohl ich mit VS2008 und angeblich
.net Framework 3.x arbeiten sollte ?

Steh ich da aufn schlauch oder hat das eine mitm anderen nix zu tun ?

Hallo,

ich komme irgendwie nicht weiter.
Ich habe eine C-Sharp Applikation welche andere GUI-Programme automatisiert testet, mittels dem White-Framework.

Ein teil des Tests sieht nun vor, das es eine Spezifizierte Datei im Explorer sucht, und per DragAndDrop in das zu Testende Programm zieht.

Mein problem ist nun dass, wenn ich ein neues explorerFenster starte, ich keinen zugriff ueber White auf das MainWindow bekomme....

Application AppExp = Application.Launch("C:\\WINDOWS\\explorer.exe");
Assert.IsNotNull(AppExp, "ERROR: NULL:  AppExp\n");

List<Window> ExpWinList =AppExp.GetWindows();
Assert.IsNotNull(ExpWinList, "ERROR: NULL:  ExpWinList\n");
Assert.GreaterOrEqual(ExpWinList.Count,1); //// <- hier scheitert er da anzahl 0

Window ExpWinMain = ExpWinList[0];

bei den paar anderen Programmen bekam ich entweder null als Liste zurueck (wurde behoben) oder eben eine Liste mit einem Fenster (MainWindow).
Nur hier geht das nich so.
Mir ist Klar das der explorer ein gewisser sonderfall ist, aber hat jemand sowas schonmal gemacht ?
Ich habe schon einwenig gegooglet und im White-Forum gelesen. Aber nichts grossartig hilfreiches gefunden. Die ScreenRepository Klasse aus dem WhiteRecorder benötigt ja auch ein Window im Konstruktor ... aber das ist ein anderes Thema.

Surpression schrieb ja weiter oben das wenn er in seine Konsole die neben der
GUI laeuft "sleep" eintippt:
"Das GUI friert ein, das ist auch der erwünschte Effekt.
Doch ich möchte, dass die Kommandozeile ebenfalls "schläft"."

Wenn ich jetzt aber sage im Kompiler ich kompiliere das ganze Programm als Konsolenanwendung. Habe ich dann ueberhaupt noch eine GUI die den gewusnchten effekt erzielen kann ??? Bzw muss ich diese dann nicht erst durch die Konsole starten ?
Das ist das was ich nicht ganz verstehe.

Ich habe mal wieder eine Frage, ....

Warum soll Supression seinen Quelltext als Konsolenanwendung Programmieren
Wenn er doch irgendwie eine GUI mit einer Konsole im hintergrund haben will
oder habe ich da was völlig falsch verstanden ?

Gruss Hermann

Ich glaube ich verstehe da einiges Grundlegendes nicht ?

Wer sagt das der Fragende User mit dem warteProblem ein Neuling ist ?

In Welchen Foren oder Buechern steht das das man bei einer einfachen Konsolenanwendung die nichts weiter machen soll als nichts tuhn
kein Polling verwenden darf ?

Was heisst eigentlich die CPU - Last auf 100% treiben ?
Was heisst Rechenintensiv ?
Wer sagt einem das die CPU-Last auf 100% getrieben wird ?
Was passiert dann wenn sie auf 100% ist ?