[VB] Probleem uitlezen compoort

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

  • mkleinman
  • Registratie: Oktober 2001
  • Nu online

mkleinman

8kWp, WPB, ELGA 6

Topicstarter
Ik heb een probleempje met een stuk logsoftware wat ik wil gaan maken voor het uitlezen van mijn Soladin 600 omvormer. Ik krijg wel data terug van de Soladin alleen is de data die ik terugkrijg regelmatig leeg ( 31 bytes &h00 ) of de input die ik krijg is precies 1 byte verschoven. Ik verwacht in het begin 00 00 11 hex maar soms krijg ik 00 00 00 11 hex.

Uitlezen doe ik dmv een click op een button.

Code voor het versturen van de instructie.

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
        If Not comportSoladin Is Nothing Then

            If comportSoladin.isOpen = True Then
                comportSoladin.ReadTimeout = 200
                comportSoladin.WriteTimeout = 100
                comportSoladin.ReceivedBytesThreshold = 31

                soladinResponse.Clear(soladinResponse, 0, soladinResponse.Length)
                SoladinOutputTextBox.Text = ""

            End If

            'getting data.
            comportSoladin.Write(soladinGetValuesCommand, 0, soladinGetValuesCommand.Length)

        End If


Ontvangen gebeurd zo.

code:
1
2
3
4
5
6
7
8
9
10
11
12
    Private Sub SerialPort1_DataReceived(ByVal sender As System.Object, ByVal e As System.IO.Ports.SerialDataReceivedEventArgs) Handles comportSoladin.DataReceived

        Dim bytes As Integer = comportSoladin.BytesToRead
        Dim comBuffer As Byte() = New Byte(bytes - 1) {}
        comportSoladin.Read(comBuffer, 0, bytes)

        soladinResponse = comBuffer

        Dim hex As String = BitConverter.ToString(soladinResponse)
        SoladinOutputTextBox.Text = hex

    End Sub


Waarom is de output af en toe 00 00 00 00 etc. en waarom verschuift de output af en toe 1 byte? Er komt als het goed is altijd 31 bytes binnen wanneer commando B6 wordt gegeven aan de Soladin omvormer.

Duurzame nerd. Veel comfort en weinig verbruiken. Zuinig aan doen voor de toekomst.


Acties:
  • 0 Henk 'm!

  • voodooless
  • Registratie: Januari 2002
  • Laatst online: 10:35

voodooless

Sound is no voodoo!

Waarom maak je een buffer die kleiner is dan het aantal bytes dat je leest (regel 4)? Als VB hier niet over gaat zeuren zul je waarschijnlijk altijd een byte missen. Lijkt me dat dat wel eens een oorzaak voor je probleem zou kunnen zijn.

Do diamonds shine on the dark side of the moon :?


Acties:
  • 0 Henk 'm!

  • mkleinman
  • Registratie: Oktober 2001
  • Nu online

mkleinman

8kWp, WPB, ELGA 6

Topicstarter
voodooless schreef op maandag 03 mei 2010 @ 19:37:
Waarom maak je een buffer die kleiner is dan het aantal bytes dat je leest (regel 4)? Als VB hier niet over gaat zeuren zul je waarschijnlijk altijd een byte missen. Lijkt me dat dat wel eens een oorzaak voor je probleem zou kunnen zijn.
Dat klopt wel de array begint op index 0. Dus om hem te dimensioneren doe je size - 1.

Overigens moet ik 4x op de button klikken om een update te zien. 8x4 = 32 bytes aan data en dus bij de 4e keer klikken zie ik mijn data pas. Als ik hem terugzet naar 1 byte en eerst een buffer vul met out put dan krijg ik mijn output ook niet.

Ik doe dus ergens nog iets ergs fout het met ontvangen van de data van de compoort.

Maar wat.

Duurzame nerd. Veel comfort en weinig verbruiken. Zuinig aan doen voor de toekomst.


Acties:
  • 0 Henk 'm!

  • voodooless
  • Registratie: Januari 2002
  • Laatst online: 10:35

voodooless

Sound is no voodoo!

flitspaal.nl schreef op maandag 03 mei 2010 @ 20:07:
Dat klopt wel de array begint op index 0. Dus om hem te dimensioneren doe je size - 1.
Dat lijkt me onlogisch. De index waarop je begint te tellen staat toch geheel los van hoeveel er in kan. Je maakt een array aan voor X items, en niet voor X-1 items. De index loopt dan van 0 tot X-1. De lengte is X.

Do diamonds shine on the dark side of the moon :?


Acties:
  • 0 Henk 'm!

  • FireWood
  • Registratie: Augustus 2003
  • Laatst online: 12:33
Stel dat het volgende niet true is.
.
code:
1
If comportSoladin.isOpen = True Then


Wat gebeurt er dan? Aangezien de com-poort dicht zit maar er wel geprobeerd wordt om gegevens te versturen krijg je mogelijk een niet betrouwbaar response terug.

Handiger is om even een else te maken en dan een error op te gooien, als deze opkomt weet je dat je het in deze hoek moet gaan zoeken. (alleen voor debug doeleinden, in werkelijkheid netter afhandelen)

Verder die eerste byte verschuiving, wanneer zal die extra byte in de buffer komen? Grote kans dat dit erin komt voordat je het signaal hebt verstuurt voor gegevens ophalen, mogelijk zelfs nog een antwoord van de vorige vraag (31 bytes is zeker?, aangezien mij 32 logischer klinkt.) of is het iets van een wakeup byte.
Misschien even per byte ophalen i.p.v. de hele handel in 1 keer en dan even het volgende doen:
.
code:
1
SoladinOutputTextBox.Text = SoladinOutputTextBox.Text + hex


Kun je in iedergeval zien waar het ongeveer vandaan komt.

Noobs don't use "F1", Pro's do, but they can't find the information they needed


Acties:
  • 0 Henk 'm!

  • mkleinman
  • Registratie: Oktober 2001
  • Nu online

mkleinman

8kWp, WPB, ELGA 6

Topicstarter
Probleem is gevonden.

RTS ( request to send ) moest op true worden gezet. Op die manier blijft er een lijntje hoog in de stekker waardoor de Soladin z'n data goed verstuurd

comportSoladin.RTS = true; of iets dergelijks was het om toe te voegen.

Duurzame nerd. Veel comfort en weinig verbruiken. Zuinig aan doen voor de toekomst.

Pagina: 1