Normally, you should use only one timer control.
Within the timer event, you would have code that decides what needs to be done (or call a routine from the timer event that decides what needs to be done).
In the case of the MSComm1 control, the OnComm() event should be triggered when you receive data, so theoretically, you could open the port, and issue a command during the form load, and when the external device responds and triggers the OnComm event, you could parse the data, graph it, and issue the next command within the OnComm event.
You would then just wait for the next OnComm event.
In the above perfect scenario, you wouldn't need a timer, since the OnComm event would alert you to the response of one command, and you would then issue the next.
But, in the real world, devices may not be ready, characters may be lost, etc..., so you might want a timer control that has code in it that can serve as a "watchdog" timer to verify that things are moving along, or can restart the communication, if data doesn't arrive in a reasonable amount of time.
I haven't had to do two way communication over a serial port for quite awhile.
The last serial port communication program I had to do was about 8 months ago, and that was just interfacing to a joystick like device (the stick itself didn't move, but it had a bunch of buttons and a two axis transducer, and sent a 10 byte, oddly packed, message containing state information, constantly at 200hz). I had to take that input and translate it into mouse messages so that it could be used with regular windows programs. Anyway, I digress.
The messages were actually 11 bytes long, including a "Sync" byte of 42 at the end (or it could have been the beginning, but at 200hz, it didn't really matter, it could just be considered as a delimiter "between" messages).
In any case, the point is, to ensure I had good data, as I received bytes from the comm port, I copied them into a byte array counting them. When I saw the 42, if I had a count of 10, the data was processed. Whether processed or not, the count is reset and data gathering continued.
So, I don't know if it will help you in your efforts, but I'll include the basic outline of my OnComm() event handler.
Private Sub MSComm1_OnComm()
Dim i As Long, j As Long
Static Byts(0 To 31) As Byte 'to hold message as it's built (only 10 bytes used normally)
Static BP As Long 'Count of bytes copied to Byts array
' Branch according to the CommEvent property.
Select Case MSComm1.CommEvent
' Event messages.
Dim Buffer As Variant
Buffer = MSComm1.Input
' Debug.Print "Receive - " & StrConv(Buffer, vbUnicode)
' ShowData txtTerm, (StrConv(Buffer, vbUnicode))
' Debug.Print LenB(Buffer)
For i = 0 To UBound(Buffer)
If Buffer(i) = &H42 Then
If BP = 10 Then 'if we have a full message
'Do a lot of processing here...
BP = -1 'Reset BP because we received a sync byte
BP = BP + 1 'Increment our Byte Pointer
Byts(BP) = Buffer(i) 'Copy byte from receive buffer to collection buffer
EVMsg$ = "Change in CTS Detected"
EVMsg$ = "Change in DSR Detected"
EVMsg$ = "Change in CD Detected"
EVMsg$ = "The Phone is Ringing"
EVMsg$ = "End of File Detected"
' Error messages.
ERMsg$ = "Break Received"
ERMsg$ = "Carrier Detect Timeout"
ERMsg$ = "CTS Timeout"
ERMsg$ = "Error retrieving DCB"
ERMsg$ = "DSR Timeout"
ERMsg$ = "Framing Error"
ERMsg$ = "Overrun Error"
ERMsg$ = "Receive Buffer Overflow"
ERMsg$ = "Parity Error"
ERMsg$ = "Transmit Buffer Full"
ERMsg$ = "Unknown error or event"
I guess the 42 was at the start of the message after all, since the code above would copy it into the 0th element of the Byts array.