MsComm to Weigh Bridge Scale 3

[Boris10]

Hi Everyone i am trying to write a software that aquires the measurements taken by a scale at a weighbridge. I have written the below code, however, i am not getting any Mscomm1.input information. What am i not doing right?
Please find the code below:

Private Sub UserForm_Initialize()
    Call Ports.GetPorts
End Sub
Public Sub GetPorts()
With MComm

On Error GoTo PortTest:
 Dim i As Long
 Dim ComPortAvailable As Boolean
 
For i = 1 To 400
    .MSComm1.CommPort = i
    .MSComm1.PortOpen = True
 If .MSComm1.PortOpen Then
    .cmb.AddItem VBA.str$(i)
    .MSComm1.PortOpen = False
    ComPortAvailable = True
 End If
Next

End With
PortTest:
 Resume Next
End Sub

Private Sub cmdConnect_Click()
With MSComm1
    .CommPort = cmb.value
    .Settings = "9600,n,8,1"
    .RThreshold = 1
    .InBufferSize = 4096
    .PortOpen = True
    .SThreshold = 1
    .Handshaking = 2 - comRTS
    .Output = "AT"
    Call GetData
End With
Private Sub GetData()
    Dim MyData As String
    'MSComm1.InputLen = 0
    MSComm1.Output = "AT"
    MyData = MSComm1.Input
    TXT1.Text = MyData
    MSComm1.PortOpen = False
End Sub
End Sub

Thank you for your help!

 

[strongm]

<sigh>

Don't have time to respond in depth right now. I shall return.

 

[strongm]

Let's start here:

Firstly, the code shown here is an example of how we deal with receiving the remote display data as binary. And a simplified one at that, given the challenges the OP was experiencing. It is not production code. I generally do not provide production code in this forum. I provide examples of how to approach a problem, then leave it up to the user to figure out how best to use it that example. In this case, as noted in the comments, I therefore use an extremely lazy method of dealing with the documented protocol (you'll note I don't provide code to turn the weight into tonnes, either)

Now, let's take your comments

>I would suggest that if only say 30 bytes was received, you wouldn't have the opportunity to indicate a faulty reading and the next read say an hour later

What read an hour later? This suggests that you still have not read the protocol. The Remote Display data is sent every 140ms. So this problem does not arise.

>Wouldn't using the "<If MSComm1.InBufferCount > 33" method create a problem if you temporarily disconnected it while it was running then reconnected? You possibly could get parts of 2 different strings mixed together?

Only partially true. If we use the protocol properly, rather than my lazy implementation, there is a checksum (it comes immediately after ETX), specifically designed to allow you to check the integrity of the data that has been received. So we'd simply validate the checksum and if it was the wrong value (in which case either the checksum is corrupt for some reason, or the data itself is corrupt), we simply throw the data away. The next block is due in 140ms, so who cares that we missed one?

The use of >33 is carefully selected to ensure - given the protocol indicates the entire data is encapsulated in 17 bytes - that we get at least one full block of data (assuming no transmission errors, which we have already shown is pretty easy to deal with without materially changing the example presented by simply checking the checksum) starting with STX and ending with ETX somewhere within the > 33 bytes. And miraculously this means that "it ignores the possibly of spurious or previous data at the head of the last complete string"

>If there is no unique end of data character
There is. ETX (followed by a checksum)

>using Instr
This is binary data. Instr really isn't the best thing to be using.

>you wouldn't have the opportunity to indicate a faulty reading
Personally, I'd simply check the CommEvent value in the OnComm event. That way I'd identify exactly what the comms error is, more or less exactly when it occurred. The only thing I wouldn't be able to simply detect is if the weighbridge simply stopped transmitting data whilst maintaining a perfectly valid connection, in which case the use of a triggered timer as per your suggestion might be one valid solution

 

[tedsmith]

I too was only indicating that one should take into account every unforeseen possibility when using communications routines and not providing "production code". It was not a criticism of illustrative code offered by others.

Unfortunately there is always a danger in providing 'illustrative code' that contain another basic weakness because it is quite possible that methods suggested to simply illustrate a point might end up in a production code situation if the writer is not aware of all issues or blindly assumes that the suggester is believed to be so well regarded that 'it must be OK".

Regarding the reference to "one hour", this was again 'illustrative' of the reason but breaks will happen if there were intermittent poor connections in the wires or plugs. If there was a dodgy connection for long enough you could get more wrong readings than right ones.

It is easy to write "lazy" mscoms routines that lock up under unexpected conditions with noisy wired connections with spikes of electrical noise that corrupt the data bytes or it the cable length is marginal so the full 12 volts is not delivered.

I agree the checksum is the really reliable method but this is possible only if checksum protocol is published (which it often isn't)