Re: Timing issue while accessing serial port

Thinking out loud, here are my thoughts on how I personally would go about debugging the situation.

First, I'm assuming from your use of the Win32::SerialPort module that you're on a Windows box. My first step would be to try using Hyperterminal or putty to manually test issuing the commands and to see what kind of responses that you get back from the device.
$PortObj->are_match("CorrRsp", ""); # correct response for CMD1
If I'm reading the documentation and your code correctly, you're telling the module that null ("") is a valid possible end string to determine the end of a response from the device. That might be correct, but it doesn't look right to me. In my mind, going with "\r" and/or "\r\n" makes more sense, but that may be completely wrong for your device.
$gotit = $PortObj->lookfor(100); #blocking read
Based on the documentation, you're read blocking until 100 characters are received. Unless you're 100% sure that you'll get at least 100 characters in response, this might create some problems. For debugging, you might want to try following the example "until" loop in the Win32::SerialPort documentation in the Methods_for_I/O_Processing section. Also, that particular example loop that I'm referring to has a $PortObj->lookclear; line to clear out the buffer. Your code is not calling this function. If you're going to reissue the command, it makes sense to me to clear out the read buffer to ensure that the next read call is reading the response to the latest issued command instead of previously issued commands.
Timeouts: Near the end of the Configuration and Capability Methods section of the Win32::SerialPort documentation, there's some notes about timeouts. Speaking from personal experience with using an older version of this module, I had to read this information several times to wrap my head around the timeouts in the module so that I could add in the proper delay (via sleep command) between sending a command and reading the response back. It might be worth it to take a few minutes to look at that stuff and your code to make sure that you're not trying to read before the device sends a response. Might not be a problem in your case, but it definitely was a problem for me when adding retries of commands in my code.
The Lookfor and I/O Processing section of the Win32::SerialPort documentation discusses the lastlook method, which can be used to "view" the "actual match and the characters after it (if any)". For debugging, it might be helpful to add a few lines inside your "until" loop to print out this information when the lookfor method doesn't find the proper success message from the device. That might help you figure out if you're reading too early or if you're hitting some edge case that you have not anticipated.

Well, those are my thoughts on what I personally would do to try to debug the problem. Hopefully one of these thoughts will either help you or at least trigger better ideas/suggestions that will help you solve the problem.

Good luck in your debugging efforts!

Comment on Re: Timing issue while accessing serial port Select or Download Code

Replies are listed 'Best First'.
Re^2: Timing issue while accessing serial port by Marshall (Canon) on Jan 20, 2011 at 14:22 UTC
First, I'm assuming from your use of the Win32::SerialPort module that you're on a Windows box. My first step would be to try using Hyperterminal or putty to manually test issuing the commands and to see what kind of responses that you get back from the device. This is a fantastic idea and the right way to go. I wish I would have suggested it!	[reply]
Re^2: Timing issue while accessing serial port by vrn (Initiate) on Feb 02, 2011 at 06:56 UTC
Thanks a lot. 1) I have used HyperTerminal to check the command response behavior between PC and the device. And it is same as expected. 2) As per my understanding the are_match("rsp1", "rsp2") is used to check the "rsp1" or "rsp2" pattern in the incoming data from the serial port. I had taken the are_match("rsp1","rsp2") as it is from the example given in Win32::SerialPort documentation as standard syntex for using are_match, as i want only single pattern to be matched that is "CorrRsp" i thought i will use second parameter as "" (null), I did not use "\n" or "\r\n" because if "CorrRsp" is not received then the script will look for "\n" as the required pattern and once it gets "\n" it will come out of loop and i don't want that to happen. If i have misunderstood something regarding the are_match function please let me know. 3) I have not used lookclear because i want to print the data received before the pattern which is stored in $gotit. If i clear the buffer then i will not able to print the data. If i misunderstood something or if there is any other way to print the data received till the pattern is matched then please let me know.	[reply]