Waitfor and missing the data

[pyutian]

Is there a way to "Bullet Proof" the waitfor command when I am trying to fire off of it.

I am working on a Meridian system and as we know there are various error codes that hit the screen while you are programing. So a simple waitfor "REQ: " will work sometimes but not all the time.

If anyone has a suggestion I would appreciate it.

 

[pyutian]

I was thinking mabey capturing to a text file then doing an strfind. Or mabey a timeout feature that transmits my string after a certain amount of time?

Not really sure how to do either one, but I will play around with it.

 

[knob]

Instead of using waitfor, you might try using a few when target commands. When target can be used to "look" for several different strings (one string per command) and call a specified procedure when that string is received.

Another option is some code that another user sent me some time ago. It uses when target under the covers by looking for the a number of specified strings (three in the version of the code on my site) and returning which string, if any, was received first. If you go the samples page on my site and search for "Josh" you will find discussion on the script and a link to the source. My assumption is that this solution, while a little trickier, would probably work best and I've used it myself several times for a similar purpose.


aspect@aspectscripting.com

http://www.aspectscripting.com

 

[lost115]

Bullet Proof mean extra coding ...

First, use a when statement to be notified of the "REQ: "
Second use a when quiet call and transmit a "*`r" in the event the "REQ:" gets destroyed. The M1 will retransmit the "REQ:" and your script should pick it up or just asume it's there "when quiet triggers".

 

[johnpoole]

bad thing with the m1 some load transmit the last command you typed at the req: prompt.. i haven't seen the missed req prompt as a problem.. do a capture on req: and the spaces behind it..in most of my files when using loop: i move the req to the end, making type my line after loop. then i don't have the problem of a carrige return timing causing m1 to retype the new (etc) prompt because it saw a ^M at the req

john poole
bellsouth business
columbia,sc