VBA
Discuss AutoCAD ActiveX and VBA (Visual Basic for Applications) questions here.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MSCOMM - serial communication too slow

3 REPLIES 3
Reply
Message 1 of 4
OceanaPolynom
1675 Views, 3 Replies

MSCOMM - serial communication too slow

Hello

I am writing a program that we want to use to navigate a survey boat along lines in a dwg file.  I hvae three serial devices connected to the computer.  (GPS, echo sounder and digital compass)  Everything is working.  The boat icon moves around the screen showing heading and depth.  Data is recorded to a text file, including time stamp from the GPS.  The problem is that it is working too slow.  A record is saved to file every 2 seconds.  I need to record every 0.5 seconds.  The program must parse the relevant data from the different serial inputs, then "move" the boat (block) on the screen by deleteing the previous block (by handle) and inserting the block at the new position.  A text string showing heading and depth is attached to the boat and moves along with it.  Position, heading and depth are updated into text boxes on a form that may or may not be showing.  The view is regenerated each time the block is moved.  There is futher overhead from the conversion of co-ordinates from WGS-84 geographic to cartesian UTM, which entails a lot of trigo etc.  The code for the On Com event was copied from MS help and looks like this:

Private Sub MSComm1_OnComm()
         Dim InBuff As String

         Select Case MSComm1.CommEvent
         ' Handle each event or error by placing
         ' code below each case statement.

         ' This template is found in the Example
         ' section of the OnComm event Help topic
         ' in VB Help.

         ' Errors
            Case comEventBreak   ' A Break was received.
            Case comEventCDTO    ' CD (RLSD) Timeout.
            Case comEventCTSTO   ' CTS Timeout.
            Case comEventDSRTO   ' DSR Timeout.
            Case comEventFrame   ' Framing Error.
            Case comEventOverrun ' Data Lost.
            Case comEventRxOver  ' Receive buffer overflow.
            Case comEventRxParity   ' Parity Error.
            Case comEventTxFull  ' Transmit buffer full.
            Case comEventDCB     ' Unexpected error retrieving DCB]

         ' Events
            Case comEvCD   ' Change in the CD line.
            Case comEvCTS  ' Change in the CTS line.
            Case comEvDSR  ' Change in the DSR line.
            Case comEvRing ' Change in the Ring Indicator.
            Case comEvReceive ' Received RThreshold # of chars.
               InBuff = MSComm1.Input
               Call HandleInput(InBuff)
            Case comEvSend ' There are SThreshold number of
                           ' characters in the transmit buffer.
            Case comEvEOF  ' An EOF character was found in the
                           ' input stream.
         End Select

      End Sub

 I have made the Threshold number of characters a parameter that I can input from the program.  When it is too small, the program doesn't work, with any  combination of values for the three devices that works, a record  is written to the log file every 2 seconds.  This is the final problem.  Any ideas?

 

Thank you

John

3 REPLIES 3
Message 2 of 4
norman.yuan
in reply to: OceanaPolynom

I used the MSCOMM many years back in a VB app to receive data rom serial port via a modem connected to phone line, thus kind of knowing a bit what you are talking.

 

My question is which part of the whole process is slow: receiving data from the sierial port is slow or processing data/updating AutoCAD drawing/screen is slow once the data is reeived? What is the frequency of data arriving at the sierial port? every a few seconds, every second or a few times per second, or continuously?

 

It seemd your have a hard coupled process. That is, everything happes whenever a piece of data is arrived (e.g. the whole data processing/drawing updating things happen in the event handler of MSComm1_OnComm() event.

 

By "slow" do you mean the code in the event hander does not finish before next batch of data arrive? Or the next batch of data arrives long after the code execution completed?

 

You'd better decouple the data receiving process and data parsing/drawing updating process. That is, in MSComm1_OnComm() event handling, only receiving data and save it in a que-like structure. While the data parsing/drawing updating process only looks into the data que and pick up data to process. With VBclassiccal/VBA, there isn't many choices of "que"-like component you can use. You may still have to save it to a file and have the data processing code to do its best to check the data saved in file(s) and execute accordingly.

 

If you do it with .NET, you can use que to store recieved data in momory without use file (thus a lot faster, but you need to make sure not let the que eats too much memory), or you can use FileSystemWatcher to monitor a folder where data is saved as files.

 

But, if the slow is due to the complicated data parsing/drawing update, then there is nothing you can do other than optimizing your code of this part.

 

Norman Yuan

Drive CAD With Code

EESignature

Message 3 of 4
OceanaPolynom
in reply to: norman.yuan

Hello

Thanks for replying.  It turns out that the problem was on the com side, not the computer overhead.  I found out everything I needed to know at

 

http://www.xtremevbtalk.com/showthread.php?t=303259

 

Typically, this solved the problem

 

 

Private Sub MSComm1_OnComm()
      
        'GPS
                 
         Static InBuff As String

         Select Case MSComm1.CommEvent
         ' Handle each event or error by placing
         ' code below each case statement.

         ' This template is found in the Example
         ' section of the OnComm event Help topic
         ' in VB Help.

         ' Errors
            Case comEventBreak   ' A Break was received.
            Case comEventCDTO    ' CD (RLSD) Timeout.
            Case comEventCTSTO   ' CTS Timeout.
            Case comEventDSRTO   ' DSR Timeout.
            Case comEventFrame   ' Framing Error.
            Case comEventOverrun ' Data Lost.
            Case comEventRxOver  ' Receive buffer overflow.
            Case comEventRxParity   ' Parity Error.
            Case comEventTxFull  ' Transmit buffer full.
            Case comEventDCB     ' Unexpected error retrieving DCB]

         ' Events
            Case comEvCD   ' Change in the CD line.
            Case comEvCTS  ' Change in the CTS line.
            Case comEvDSR  ' Change in the DSR line.
            Case comEvRing ' Change in the Ring Indicator.
            Case comEvReceive ' Received RThreshold # of chars.
               InBuff = InBuff & MSComm1.Input
               If InStr(1, InBuff, "$GPGGA") Then
                    cbuff% = InStr(InBuff, "*")
                    If cbuff% > 0 Then
                        InBuff = Mid(InBuff, 1, cbuff% - 1)
                        Call HandleInput(InBuff)
                        InBuff = ""
                    End If
               Else
                    InBuff = ""
               End If
               
            Case comEvSend ' There are SThreshold number of
                           ' characters in the transmit buffer.
            Case comEvEOF  ' An EOF character was found in the
                           ' input stream.
         End Select

      End Sub

 John

Message 4 of 4

I forgot to add that

 

MSCOMM1.RThreshold = 1

 

Must be set equal to one

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report

”Boost