11-28-2007 10:40 PM
01-27-2009 11:02 AM
01-28-2009 02:47 PM
This parameter is no longer mentioned in the help for Lookout 6.2. This parameter is hard coded and is set to True. Do you need to turn off unsolicited response processing?
Thanks!
Andy F.
01-29-2009 01:57 AM
Hi Andy,
I have had problems with Lookout's response to unsolicited IPASCII on occassion. I is really weird because usually Lookout will restart response simply by opening the IPASCII properties box and closing it again.
I would like a way to programatically "wake up" the unsolicited IPASCII response upon detection of data stream stoppage or periodically to inhibit Lookout's "falling asleep" on unsolicited ASCII data.
I was thinking that if you made the enable parameter exposed for dynamic processing, we could test this issue further and it may be a work around to the "sleeping" problem I still encounter.
Thanks,
Ed
03-04-2009 12:18 AM
I'm actually having the same problem with ASCII objects and unsolicited data. Lookout just stops "seeing" the data sometimes. "Touching" the object via the properties dialog box open/close restores the link.
Updates please?
03-04-2009 08:08 PM
When the problem happens on ASCII object, please open MAX, go to Device and Interface->Serial&Parallel, select the com port that ASCII uses, click Validate. I want to know if the com port is still handled by the ASCII object. If the validation is fine, it means the ASCII object has released the com port unexpectedly.
For the IPASCII object, I guess there is logical problem in the source code. To edit the property, it is not only "touch" the object, but also reset the object.
03-23-2009 09:48 PM - edited 03-23-2009 09:50 PM
Ryan,
Devices and Interfaces is not available in max. The ports are Moxa virtual ports mapped with NPort Windows Driver Manager 1.6 Build 07082417.
Max only shows NI ports?
Other ways to check? I have the problem right now and I have verified devices are still sending ASCII, but lookout is not showing. The device was powered off for calibration then returned to service. Lookout never picked up the return to service, although most of the time, it does. Unlike some devices, this one gets data sent to it every 5 minutes or so, so I don't know why Lookout sometimes won't wake up to the incoming data (solicited or not-solicited).
I will wait for advice before recovering this channel by restart or other means.
Ed
03-24-2009 04:07 AM
Sorry, the devices and interfaces is not available if you just install lookout. You need NI-DAQ or VISA to get it in MAX. This way is easy to test the port. Besides it, we can use a serial port monitor software to do so. I download the Ultima software for serial port monitoring. If the port is being handled by lookout, you cannot open the port by other software.
Do you mean that this device gets data from lookout and sends both solicited and unsolicited data to lookout computer? If so, we can firstly test if lookout is still sending data out to this device by the diagnostic file. Does it use the same ASCII object to send data?
I'm wondering if it is possible for me to set up a simple system with ASCII object to reproduce the problem. Frankly saying, I don't have much idea without reproducing the problem.
04-15-2009 12:44 PM
Ryan,
I was able to determine that Lookout is sometimes hanging up the port for the ASCII object used for unsolicited monitoring. It seems to happen if the device stops sending data for a period of time (not sure how long but Lookout hangs up after less than 15 minutes.
Can this be fixed?
Alternatives to reset ASCII objects occasionally to find these devices again?
If I cycled the OFF-HOOK data member occasionally, would this work? Does the off-hook data member actually prevent the communications and release the port (as I assume it is designed to do)? How about occasionally sending data to these devices? I need whatever I send to be benign to the devices....
Thanks,
Ed
04-16-2009 05:04 AM
Let me first check out the source code in which condition Lookout releases or hangs up the port.