Stop loop and wait for ONComm event

[DannyTmoov2]

I have a loop that part way through an iteration runs a function to send an output to an mscomm control and recieves a response from it. On each iteration I want to stop the loop at the point of sending the output and await for the response before continuing the loop.

How can i make the loop stop and wait for the on_comm event before continuing?

Any ideas much appreciated,

Dan

 

[TheVampire]

OK, you can do this, but you have to be carefull.

If you have a loop of code that is executing, the only way you can wait for the OnComm event is to have another loop inside the first one, with a DoEvents staement in there. Along with a couple of global variables. example

Global variables
Public OnComm_Trigger as Boolean
Public OnComm_Data as String


Inside your Mainloop, you send out the data to the COM port and then do this...

OnComm_Trigger = False
Do Until OnComm_Trigger = True
DoEvents
Loop


And inside the OnComm event, you would have to assign the incoming data to your OnComm_Data variable.

Comm1_OnComm

OnComm_Data = Comm1.Input
OnComm_Trigger = True

End Sub


OK, the problem is that:

1: The DoEvents statement will cause any pending events to be processed. This includes mouse clicks. So you have to protect yourself so that the user can't accidentally do something else in the middle of the proceedure.

2: You have to be sure that the OnComm event is going to get all of the data that you are expecting from the com port, so you have to set your OnComm threshold to the appropriate value.

3: You need to put some sort of timeout into the loop that waits for the oncomm event, so that if the com port does not get the data, it will not put your program in an infinite loop.

Sorry, did not have a lot of time to write this. Hope it helps you in the right direction.

Robert

 

[Homersim2600]

Dan,

MSComm has a function built into it to where the events which are received via the Com port can cause an interrupt in your program. As the Vampire points out, it is tricky, and usually uncommon practice to use a loop for the MSComm control. I was not sure if you were aware of this so I thought I would point it out...

Double click on the MSComm control that is located on your form and put the following code...

If MSComm1.CommEvent = comEvReceive Then
YourVar = MSComm1.Input
End If

Hope this helps a bit...


LF

 

[fissidens]

Don't use a loop! Put a timer on the form or create a reference to a timer on another form. On W2K /XP you can set the interval down to 10ms if you really need to. When the timer event _Timer() fires, it checks to see if a transmit operation is required. Set up a module-level variable such as Private mTxRequested as boolean in the form header. The _OnComm() event sets this variable to true. The _Timer() event tests the variable, does the transmitting part if requested and then, crucially, clears the variable to False.
This sort of handshaking, using a flag like this, is central to much RS232 hardware control. One nice by-product of this approach is that you can stop and start the comms just by enabling/disabling the timer.
Good luck!

 

[Homersim2600]

fissidns,
This statement...

"This sort of handshaking, using a flag like this, is central to much RS232 hardware control"

Is not totally complete. The proper way to implement this function, which you describe, is to use full hardware handshaking to insure that the MCU on the transmitting end does not send packets until the computer is ready. 10ms limits your transfer rate to right at 9600bps, and even at this rate you are sure to miss some of the incoming information due to the various other delays which may be imposed upon the computer processor without using handshaking.

Frankly, I cringe at the thought of using a loop to gather data from the Com port... But that's me.

LF

 

[fissidens]

Point taken LF, but I was assuming the information being received was not likely to exceed the size of the input buffer (which you can change if necessary). This approach would not be suitable to a continuous flow of incoming serial data, but I didn't think we were talking about that.

 

[Homersim2600]

fissidens,
I am with you with respect to the input buffer, however, what happens when the CPU has not read the information from the input buffer by the time the MCU on the transmitting end sends another packet becuase it is busy with some other CPU intensive process? Simply put, the previous packet that was in the input buffer is missed; this is what I was referring to in my previous post.


LF

"As far as the laws of mathematics refer to reality, they are not certain; as far as they are certain, they do not refer to reality."--Albert Einstein