Software funktioniert nicht auf allen PCs

Also das Funkmodul macht "auch" Probleme und funktioniert bei 2 
aufeinanderfolgenden Testvorgängen meist nicht.

Max schrieb:
> Es laufen mehrere Threads. Der PC mit
> einem schnelleren Prozessor macht Probleme.

klingt stark nach einen Threadproblem. Überprüfe alle zugriffe auf 
globale Variablen/Daten.

>>...Teststand über ein GUI steuert

Darunter kann man sich nur wenig vorstellen, genauere Beschreibung wäre 
gut.
evtl. überfährst du den FTDI.

Bei diesem Teststand wird über RS232 ein Mc angesteuert und über USB 
eine Platine zur Farbanalyse. Zudem wird mit dem Prüfling über Funk 
kommuniziert, wozu das Funkmodul genommen wird. Dazu steht ihm ein 
Thread bereit, der die Eingangsdaten des FTDI-Chip (über einen Treiber, 
der direkt auf die USB-Schnittstelle zugreift mit Hilfe einer 
Seriennummer (D2XX-Treiber)) in einen Eingangspuffer schreibt. Ansonsten 
stellen alle anderen Threads , der in Vb.net geschriebenen Software, 
eine Instanz der Klasse Backgroundworker dar, also dem Backgroundworker 
steht auch ein Thread zur Verfügung und dieser Klasse steht in vb.net 
einige Funktionalität bereit.
Der zeitkritische Vorgang, bei dem mit dem Prüfling kommuniziert wird 
(Anmeldung), findent in einem Backgroundworker statt.

Was bedeuted, dass ich den FTDI überfahre?

noch ein Nachtrag. Unter win7 funktioniert diese Software wiederum mit 
einem mind. ebenso schnellen, wie der PC auf dem sie nicht unter win xp 
funktioniert.

Peter II schrieb:
> klingt stark nach einen Threadproblem. Überprüfe alle zugriffe auf
> globale Variablen/Daten.

Wieso darauf überprüfen? Weiß nicht was ich jetzt tun soll.

Max schrieb:
> Peter II schrieb:
>> klingt stark nach einen Threadproblem. Überprüfe alle zugriffe auf
>> globale Variablen/Daten.
>
> Wieso darauf überprüfen? Weiß nicht was ich jetzt tun soll.

man muss jeden Zugriff auf Variablen (oder Objekte) Threadsicher machen. 
Das heist das immer nur ein Thread darauf zugreifen kann.

Wenn du z.b. 2. Threads hast die eine Variabel hochzählen

i = i + 1;

dann ist du hier schon einen Fehler, weil der zugriff nicht atomar ist. 
Du verzählst dich damit.

Robert L. schrieb:
> du hast also 1,5 Wochen gesucht,
> die suche ergab bisher : "es funktioniert nicht"..
>
>
> ich glaub du suchst einfach falsch
> lass z.B. mal jeden Thread mitloggen was er/wann macht...
>
>
>
> (wenns zeitkritisch ist, nimmt man keine threads ;-)...

was versteht man denn darunter? System.Diagnostics - aufzeichnen und 
auslesen? Oder Software nutzen wie SmartInspect?

Stehen nur Rechner mit win xp und 7 zur Verfügung.

Max schrieb:
>> ich glaub du suchst einfach falsch
>> lass z.B. mal jeden Thread mitloggen was er/wann macht...
> was versteht man denn darunter? System.Diagnostics - aufzeichnen und
> auslesen? Oder Software nutzen wie SmartInspect?

siche ich nicht als sinnvoll an. Mit dem System.Diagnostics änderst du 
das Zeitverhalten der Threads und der fehler kann schon nicht mehr 
auftreten.

Zeige doch einfach mal etwas quellcode, wichtig ist der Thread und der 
Teil der die Daten dann weiterverarbeitet.

hast Du überhaupt Zugriff auf den Sourcecode?

Quellcode kommt gleich, erkläre dann anhand von ihm

> Also ich frag einfach mal

Unter Windoss 3.1 konnte man noch sehr gut echtzeitfähige 
Anwenderprogramme schreiben, denn die Interrupts standen den 
Anwenderprogrammen zur Verfügung und es gab nichts höherpriorisiertes.

Seit dem Festplattencache vcache.386 hatte man Probleme, weil das per 
NMI jeden Prozess bis zur Ewigkeit ausbremsen konnte, damit war Win95 
nicht mehr für Echtzeitanwendungen geeignet, es sei denn, man schmiss 
das Cache raus.

Wenn man überhaupt auf Interrupts reagieren muss, muss man heute Device 
Treiber schreiben, die im höherpriorisierten Kernel sitzen. Das geht 
unter Windows XP noch.

Mit Windows 7 ist auch das unmöglich geworden, du müsstest deine Treiber 
signieren, das Betriebssystem ist somit vollkommen unbrauchbar für 
Echtzeitexperimente.

Unter Linux sieht es übrigens nicht besser aus.

Manche Leute nennen das Fortschritt.

MaWin schrieb:
> Wenn man überhaupt auf Interrupts reagieren muss, muss man heute Device
> Treiber schreiben, die im höherpriorisierten Kernel sitzen. Das geht
> unter Windows XP noch.

das ganze ist zwar schön zu wissen, spielt hier aber überhaupt keine 
rolle.

> Mit Windows 7 ist auch das unmöglich geworden, du müsstest deine Treiber
> signieren, das Betriebssystem ist somit vollkommen unbrauchbar für
> Echtzeitexperimente.

auch das wollte niemand wissen.


Es will eine FTDI Chip abfragen, dieser liefert so langsam daten, das 
das schon vor 10Jahren auf jeden PC funktioniert hat.

Hier wird nur ein Fehler in der Anwendungssoftware sein, es muss kein 
Treiber geschrieben werden und auch nicht auf Interrupts reagiert 
werden. Denn der Treibe vom FTDI liefert ein event.

Also naja, ist jetzt eine Menge. bgw_funkmodul_DoWork unterscheidet 2 
modi des Funkmoduls. im 2. jeweils was durch eine boolsche Variable 
unterschieden wird, werden alle Daten durchgelassen.
Der Backgroundworker deligiert nach dem Finden eines Zeichen an die Sub 
Work data.
Der Thread reiveData schreibt einfach in einen Buffer, was ein Bytearray 
darstellt.
Der Testvorgang findet in einem Backgroundworker statt und ist hier 
nicht darstellt.
Prinzipiell ist das jetzt schon viel Code. Falls das erschlägt oder ich 
das anders, lieber erklärend darstellen soll, mache ich das gerne.
Auch könnte ich den Ausschnitt des Testvorgangs darstellen.

1

 Private WithEvents Funkmodul As New FTDI() 'FTDI Bibliothek

2

3

'Delegate für das Funkfunkmodul

4

    Private Delegate Sub Delegat_Funkmodul_Data_Received(ByVal dIN As String)

5

    Private Funkmodul_Data_Received As New Delegat_Funkmodul_Data_Received(AddressOf Funkmodul_Work_Data)

6

7

'Thread aufgerufen in frm_main_Load

8

    Private Sub Funkmodul_DataReceived()

9

10

        Dim count As UInteger = 0

11

        Dim din(1) As Byte

12

        Dim bytesread As UInteger = 0

13

14

        While True

15

16

            Funkmodul.GetRxBytesAvailable(count)

17

18

            If count > 0 Then

19

                Funkmodul.Read(din, 1, bytesread)

20

                Funkmodul_fifo(Funkmodul_schreibe_pointer) = din(0)

21

                Funkmodul_schreibe_pointer += 1

22

                If Funkmodul_schreibe_pointer = UBound(Funkmodul_fifo) + 1 Then Funkmodul_schreibe_pointer = 0

23

24

            End If

25

26

            Threading.Thread.Sleep(1)

27

28

        End While

29

30

    End Sub

31

32

 Private Sub bgw_funkmodul_DoWork(sender As System.Object, e As System.ComponentModel.DoWorkEventArgs) Handles bgw_Funkmodul.DoWork

33

34

        Dim command As String = ""

35

        Dim i As Integer = 0

36

        Dim j As Integer = 0

37

        Dim Anz_Zeichen As Integer = 0

38

        Dim start As Integer = 0

39

40

        While True

41

42

            If Me.bgw_Funkmodul.CancellationPending Then Exit Sub

43

44

            While Funkmodul_schreibe_pointer <> Funkmodul_lese_pointer

45

46

                If bol_funk_init Then

47

                    'Kommandmode

48

49

                    If Funkmodul_found_startzeichen Then

50

51

                        If i = 2 Then

52

                            Anz_Zeichen = Funkmodul_fifo(Funkmodul_lese_pointer) + 1

53

                        End If

54

55

                        command += Chr(Funkmodul_fifo(Funkmodul_lese_pointer))

56

57

                        If i = Anz_Zeichen + 2 Then

58

59

                            Funkmodul_Data_Received(command)

60

                            Funkmodul_found_startzeichen = False

61

                            command = ""

62

                        Else

63

                            i += 1

64

                        End If

65

                    Else

66

                        If Chr(Funkmodul_fifo(Funkmodul_lese_pointer)) = STX Then Funkmodul_found_startzeichen = True : i = 1 : command = STX

67

                    End If

68

69

                Else

70

                    'Transparentmode

71

72

                    If Chr(Funkmodul_fifo(Funkmodul_lese_pointer)) = STX Then

73

                        Funkmodul_found_startzeichen = True

74

                        command = STX

75

                    Else

76

                        command += Chr(Funkmodul_fifo(Funkmodul_lese_pointer))

77

                    End If

78

79

                    If Funkmodul_found_startzeichen Then

80

81

                        If Chr(Funkmodul_fifo(Funkmodul_lese_pointer)) = ACK Then 'And command.Substring(18, 1) <> 1 Then 'Ack von RC

82

                            Funkmodul_found_acknowledge = True

83

                        End If

84

85

                        If Chr(Funkmodul_fifo(Funkmodul_lese_pointer)) = ETX Then

86

                            Funkmodul_found_stopzeichen = True

87

                        End If

88

89

                        If Funkmodul_found_stopzeichen Then

90

                            'Jetzt noch den CRC 

91

                            If j = 4 Then

92

                                Funkmodul_Data_Received(command)

93

                                command = ""

94

                                Funkmodul_found_startzeichen = False

95

                                Funkmodul_found_stopzeichen = False

96

                                j = 0

97

                            Else

98

                                j += 1

99

                            End If

100

                        Else

101

102

                        End If

103

104

                    End If

105

106

                End If

107

108

                Funkmodul_lese_pointer += 1

109

                If Funkmodul_lese_pointer = UBound(Funkmodul_fifo) + 1 Then Funkmodul_lese_pointer = 0

110

111

            End While

112

            System.Threading.Thread.Sleep(3)

113

        End While

114

115

    End Sub

116

117

 Private Sub Funkmodul_Work_Data(ByVal dIN As String)

118

        ' InvokeRequired required compares the thread ID of the 

119

        ' calling thread to the thread ID of the creating thread. 

120

        ' If these threads are different, it returns true. 

121

        'Invoke the sub to allow cross thread calls to pass safely

122

        If Me.InvokeRequired Then

123

124

            Dim del As New Funkmodul_Work_Delegate(AddressOf Funkmodul_Work_Data)

125

            Dim args As Object() = {dIN}

126

            Me.BeginInvoke(del, args)

127

128

        Else

129

130

            If bol_funk_init Then

131

132

                Select Case dIN

133

134

                    Case ACK_AMBER_KOMMAND_MODE '2. Variable: in welchem Kanal bin ich bei Programmstart

135

                        bol_funkmodul_kommandmode = True

136

                        bol_funkmodul_tranzparentmode = False

137

                    Case ACK_AMBER_TRANSPARENT_MODE

138

                        bol_funkmodul_kommandmode = False

139

                        bol_funkmodul_tranzparentmode = True

140

                    Case ACK_AMBER_SET_CHANNEL_0 '2. Variable: in welchem Kanal bin ich bei Programmstart

141

                        bol_funkmodul_channel_0 = True

142

                        bol_funkmodul_channel_1 = False

143

                    Case ACK_AMBER_SET_CHANNNEL_1

144

                        bol_funkmodul_channel_1 = True

145

                        bol_funkmodul_channel_0 = False

146

                    Case Else

147

148

                End Select

149

150

            Else

151

152

                RC_ID = dIN.Substring(9, 8)

153

154

                Select Case True

155

                    'Case dIN.Contains("CU") And dIN.Contains("BV") And dIN.Contains("CV") And dIN.Contains("BT") And dIN.Contains("BN")

156

                    '    'ERSCHÜTTERUNGSSENSORTEST

157

158

                    Case dIN.Contains("KP66") 'nochmal überprüfen, da es ein up and down Event sein kann und vielleicht beide gesetzt sein müssen

159

160

                        If (Login_Test = False) Then 'Taste_OK_pressed

161

162

                            If (Taste_F1_F2_pressed = True) Then

163

164

                                Taste_OK_pressed = True

165

                                Me.pic_Tasten_getestet.SizeMode = PictureBoxSizeMode.StretchImage

166

                                Me.pic_Tasten_getestet.Image = My.Resources.Tasten_Pfeil_ok

167

168

                            Else

169

                                'Log-File

170

                            End If

171

172

und so weiter ...

naja, der code ist so leider sehr schwer lesbar. Bitte als Anhang.

Aber die ganzen

System.Threading.Thread.Sleep(3)

sind schon mal falsch. Es gibt überhaupt keinen Grund zu warten. Du 
bekommst einen event wenn neue Daten reinkommen. Warum sollte man extra 
noch warten?

Max schrieb:
> Also das Funkmodul macht "auch" Probleme und funktioniert bei 2
> aufeinanderfolgenden Testvorgängen meist nicht.

Wenn kein ausreichendes Zeitfenster ist, alle Pakete GESUND zu 
empfangen, ist Dein Zug schon abgefahren. Entwerder behilfst Du Dir mit 
Werten aus dem Cache oder wirfst diese falschen Ergebnisse rechtzeitig 
weg.

nächsten fehler:

> Funkmodul.GetRxBytesAvailable(count)
>
>            If count > 0 Then
>               Funkmodul.Read(din, 1, bytesread)

was ist wenn mal mehr als 1 Zeichen kommt? Dann liest du nur das erste 
zeichen. du musst alles lesen was da ist!

oszi40 schrieb:
> Wenn kein ausreichendes Zeitfenster ist, alle Pakete GESUND zu
> empfangen, ist Dein Zug schon abgefahren. Entwerder behilfst Du Dir mit
> Werten aus dem Cache oder wirfst diese falschen Ergebnisse rechtzeitig
> weg.

das habe ich nicht verstanden. Welche Werte und wie bekomme ich die?

Die Pausen habe ich wegen der Systemauslastung gemacht, aber lasse ich 
gerne weg.

Code kommt gleich in einem Anhang.

Max schrieb:
> Die Pausen habe ich wegen der Systemauslastung gemacht, aber lasse ich
> gerne weg.

dann arbeitest du nicht mit events. Schau dir die doku von FTDI an. 
Normalerweise brauchst du nicht mal einen Backgrundworkder zum einlesen.

Peter II schrieb:
>> Funkmodul.GetRxBytesAvailable(count)
>>
>>            If count > 0 Then
>>               Funkmodul.Read(din, 1, bytesread)

ist eine Schleife, die solange Daten da sind jeweils 1 Byte in den 
Buffer schreiben. Den Fehler verstehe ich nicht.

klar hier ist das Problem


>  Private Sub Funkmodul_DataReceived()
>        While True
>
>            Funkmodul.GetRxBytesAvailable(count)
>
>
>        End While

das ist der falsche weg. Entwedewr macht man einfach einen

while true
   Funkmodul.Read(din, 1, bytesread)
end while


oder man arbeitet mit GetRxBytesAvailable und events. So wie du es 
gemacht hast ist es aber falsch.

Max schrieb:
>>>            If count > 0 Then
>>>               Funkmodul.Read(din, 1, bytesread)
>
> ist eine Schleife, die solange Daten da sind jeweils 1 Byte in den
> Buffer schreiben. Den Fehler verstehe ich nicht.

ich kann zwar nicht VB aber wo ist da eine Schleife? das ist eine IF 
abfrage und keine schleife.

Aber die Prozedur ist sowieso falsch, siehe vorherigen beitrag.

Also probiere das gleich aus.

@ Peter: ist doch in einer while(true)-Schleife und fragt dann if ab.

Und was mich durchgehend beschäftigt, wenn hier der Fehler liegt. Wieso 
funktioniert das dennoch an 2 PCs und an einem nicht, denn daraus kann 
ich mir keinen Reim machen.

also hier noch der Code, habe den in eine vb-Klasse.

Max schrieb:
> @ Peter: ist doch in einer while(true)-Schleife und fragt dann if ab.

ja hatte ich übersehen, ich bin davon ausgegangen das das die Sub nur 
bei einem event vom FTDI aufgefufen wird.

> Und was mich durchgehend beschäftigt, wenn hier der Fehler liegt. Wieso
> funktioniert das dennoch an 2 PCs und an einem nicht, denn daraus kann
> ich mir keinen Reim machen.
das ist bei Softwarefehler immer der Fall, mal geht mal nicht. Ändere 
ist mal das auslesen und enterne die sleeps. Die CPU lasst darf dabei 
nicht steigen! Wenn doch hast du noch einen fehler. Dann Teste noch mal.

Robert L. schrieb:
> doch das wird sie,
> ein kern wird 100% ausgelastet:
> warum sollte sie auch nicht tun???

weil man nur ein Read macht, diese Read blockiert bis daten ankommen und 
bracuht dabei keine CPU zeit.


> die sleep sind (prinzipiell) nicht sooo falsch, ...
> nur 1 Millisekunde warten, nach jedem Byte ist etwas "lang"
doch ist es. Sleep hier absolut falsch.

Also der Änderungsversuch hat nichts gebracht. Mache die ms im 
receiveThread noch weg.

Nochmals @ Peter: zu dem Softwarefehler. Auf den anderen Pc's gibt es 
keine Fehler, der Test wurde an verschiedenen Tagen mehrmals 
wiederhohlt. Von diesem Gedanken ausgehend habe ich halt versucht dem 
Problem auf den Grund zu gehen.

Eure Vorschläge neheme ich tausend dankend an und probiere alles aus, 
doch wieso das einen Unterschied ergibt? Wird es an den anderen Pc's 
dann möglicherweise nicht mehr laufen und ich brauche 2 
Softwareversionen?

Max schrieb:
> Eure Vorschläge neheme ich tausend dankend an und probiere alles aus,
> doch wieso das einen Unterschied ergibt? Wird es an den anderen Pc's
> dann möglicherweise nicht mehr laufen und ich brauche 2
> Softwareversionen?

nein nur eine die funktioniet. Hat der andere PC die gleiche CPU anzahl?

Max schrieb:
> Also der Änderungsversuch hat nichts gebracht. Mache die ms im
> receiveThread noch weg.

dann zeige mal bitte wieder den code (als anhang) damit man sieht was du 
gemacht hast.

8 kerne a 3,2 ghz und und 4 a 2,4 ghz funktioneriert es. und bei 4 a 2,4 
ghz funktioniert es.

        While True

            Funkmodul.GetRxBytesAvailable(count)

            Funkmodul.Read(din, 1, bytesread)
            Funkmodul_fifo(Funkmodul_schreibe_pointer) = din(0)
            Funkmodul_schreibe_pointer += 1
            If Funkmodul_schreibe_pointer = UBound(Funkmodul_fifo) + 1 
Then Funkmodul_schreibe_pointer = 0

        End While

passt so?

und die 3 ms weg bei dem Backgroundworker

und meinte bei 4 Kernen a 3,1 ghz funktioniert es nicht. (anstatt von 
"und bei 4 a 2,4 ghz funktioniert es.")

das

> Funkmodul.GetRxBytesAvailable(count)

kann auch weg


> und die 3 ms weg bei dem Backgroundworker
das kannst erstmal bleiben, sollte aber auch später entfernt werden. Und 
zwar durch ein event

http://msdn.microsoft.com/de-de/library/system.threading.eventwaithandle.aspx

dann braucht man keine wartezeit mehr.

Robert L. schrieb:
> die Funktion schaute für mich (auf den 1. blick) NICHT blockierend aus..
> ist sie aber anscheinend (allerdings mit Default timeout von 500ms???)
> d.h. man sollte hier wohl auf exception achten (vielleicht ist dass das
> problem?)

eigentlich sind alle read funktionen standardmäßig blockierend.

> die blockierende funktion sollte dann aber (trotzdem) ein timeout haben
> (z.b. 1 sekunde)
> um zwischendurch prüfen zu können ob man  den thread gegebenenfalls
> korrekt zu beenden hat....
nicht zwingend. Dafür kann man auch einfach das Handle schließen und 
damit kommt das Read mit einem fehler zurück.

Robert L. schrieb:
> ja, in VB (.net) vielleicht..
> das kann schon sein..
> kenn ich nicht..

wo denn nicht? In C ist es auch der Fall. In Perl auch. Welchen Read ist 
denn standardmäßig nicht blockierend?

Robert L. schrieb:
> ich halte es weiterhin für möglich, dass es nicht blockierend ist..
> bytesread ist nämlich 0

bytesread ist der rückgabewert, wie viele zeichen gelesen wurden. Und ja 
Read blockiert nicht wenn das Handle geschlossen wurden oder man 0 
zeichen lesen will.

Robert L. schrieb:
> laut
> http://msdn.microsoft.com/de-de/library/ms143549%2...
> nicht

wie solle es ohne blockierung denn zu einer TimeoutException kommen?

Viel sinnvoller als die Zeit mit dem PC zu verplempern waere die 
zeitkritischen Dinge auf einen Controller auszulagern und den PC nur als 
Control- & Visualisierer zu verwenden.

Viktor N. schrieb:
> Viel sinnvoller als die Zeit mit dem PC zu verplempern waere die
> zeitkritischen Dinge auf einen Controller auszulagern

es gibt hier überhaupt nichts zeitkritisches.