Exposing parameter #7 of IPASCII to allow unsolicited response processing

[Ryan.S]

Ed,

Yesterday I created a process with an ASCII object monitoring the port. After more than 1 hour, I saw the same problem! The ASCII doesn't receive the unsolicited data any more. I tried for several times later but didn't see it again. It seems to happen randomly.

Anyway, I have made some progress.

[erblock]

This definitely happens and is repeatable on my end.  Any luck identifying the "hang up"?

Ed

[erblock]

Ryan,

I need this fixed!  Any progress with the source code?  Right now my priority is with ASCII unsolicited hang-ups.

Ed

[Ryan.S]

Ed, Do you have any connection on offhook datamember right now? On or OFF?

The problem rarely happens on my computer, so I don't have much chance to debug it. Sorry for the delay.

[Ryan.S]

Ed,

I don't remember clearly. Did I give you an updated lkworks.dll which logs the unsolicited data?

If your lookout logs the unsolicited data now, could you make a diagnostic log file on the serial port? I want to know if the lkworks really gets the unsolicited data when you have the problem.

If lkworks gets the data, but you don't see it in ASCII object, it means problem when lkworks tries to give the data to ASCII object.

[erblock]

Hi Ryan,

It looks like most times this occurs, routine unsolicited data (every 2 seconds) from the remote device is interrupted by an external issue (network, power cycle, etc.).  There must be some sort of timeout that Lookout senses to stop listening for the data after it is interrupted.  For instance, we had an issue where the wireless access point script was corrupted and it would not let the device onto the network one night after the AP was rebooted.  Obviously the data stopped sending.  When the issue was corrected and the device was back online, Lookout would not recognize the incoming data (offhook?) until you manual go into edit mode in Lookout and open and close (with OK button) the property dialog box for the ASCII object.  Then the data is back.

Now for short term interruptions (simple 20-30 second power cycle) of a sending device, Lookout recovers on it's own and the data is only interrupted for the time it is not actually sent.

I do not have anything hooked to the offhook data member at this time.  I was wondering if I hooked a periodic (5 minute) pulse timer to this object, if it would auto recover the lost connection better when interrupted.

The other thing I was wondering was if Lookout had some protection coded to go offhook if certain corrupt data sequence was incoming such as what might happen when a device was disconnected from the network in the middle of a transmission.  Again though, it seems this only happens when the data transmission stops for a significant amount of time, not just a few minutes.

Ed

[Ryan.S]

Hi Ed,

What's your current lookout version? I made some changes in source codes, and want to give you an file to test. I can't test it here because it is not easy for me to reproduce the problem. So I'm not sure if it actually fixes the issue, but we can get more information from the test.

Actually lookout doesn't know what happens on the other end of the cable. For reading unsolicited data, Lookout just monitors the local serial ports, and repeatedly gets data from the port. The com port is not supposed to be released even if the data stops for a long time. So the issue is more like a bug in Lookout.

What do you mean by "hook a pulse to the object"? Do you want to hook the pulse to offhook datamember or the "send" datamember?

[jrcamenzind]

Ryan, On message #11 you were able to witness the same problem that I have been having for a long time (I use v6.02). I have about eight Ascii objects set up for unsolicited inputs and they seem to randomly stop accepting the input. Any progress on fixing this problem? It would be really great if this could be fixed! Thanks, Joe C.

[erblock]

Lookout 6.2

It is definitely a bug.

My workaround as follows:

Connect 5 minute pulse timer to send data member of ASCII object with a "\n" request format.  Note: Device does not accept incomming comms, so I did not have to set up dynamic request formating to prevent unwanted commands from being sent. 

Has not failed to recieve unsolicited data for 3+ months since that change.

Ed

[jrcamenzind]

Ed, I am trying your work around now. Thank you very much for your input. Regards, Joe C.