Request New Feature...Disable/Enable Communication Objects

[erblock]

It would be quite useful to be able to enable/disable communication objects such as Modbus, Ascii and others.

For example, if you have several modbus objects and some of the clients are out of service, the entire process gets bogged down testing and timing out on communicating with the dead device. This can greatly diminish the reponse time to the remaining, working devices on the same port. Lookout currently has no way to easily turn off the objects which may hamper process performance due to device failure or power down.

[Khalid]

Hello,

Being able to enable/disable the communication would indeed be a great functionality.

It's very likely you know this already, but wanted to mention just in case, and for the benefit of others, the following:

You can in effect "disable" the communication for you driver objects by changing its poll rate to a really large number. For example, you can have a switch with the following connection:

Modbus1.PollRate = IF(Switch1, 99:59:59, 0:10)

We are basically asking the Modbus driver to poll every 99hrs-59mins-and-59secs IF the Switch1 is On. And if its False, poll every 10sec. This way we do not tax the systems unnecesarily by polling the device when we know it's offline.

Hope this workaround helps.

Regards,

Khalid

[erblock]

Thanks Khalid.

Yes, this will stop the system crawl, but it will also give you a false sense of "everything is OK" (or the reverse)! You will either loose your red "X" warning of communication inadequacy, or the red "x" could be present when all is actually OK.

An enable/disable could allow accurate status and if done right, even a third status indication to alert of the disabled condition.

Ed

[Hill1221]

With the OMRON communication devices:

I monitor the COMMFAIL, feed it to a counter and when the value exceeds my limits, activate an alarm.

I use the alarm to change the state of the expression in the POLL data member to false. This stops the communication of the device until the alrm is reset.

I do not depend on the red X's, I prefer a large warning indicator to be shown on the screen.

[erblock]

Khalid,

Will the answer in this link by Zork help here?
http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=506500000008000000632B0000&UCATEGORY_0=_9_&UCATEGORY_S=0

I wasn't aware of the Modbus.ini files existence. Is there a setting to change "input" updates to 0 or null?

Ed

[Carl_Finley]

This option does exist on most drivers. If you will go to "edit data members" for your driver, there is a logical data member for "POLL". You can link this to a simple switch object to turn polling on or off. If polling is turned off, you will NOT get a comm fail and therefore will not see the red Xs. You could however display on any relevant screen a simple logical expression that will indicate that polling to that node has been turned off. This should alleviate anyone falsly assuming all is OK. I did notice that you also mentioned the ASCII driver, this driver does not have the "poll" data member.

[erblock]

Hi Carl,

Unfortunately, that is not true for the Modbus object (the one currently giving me the most trouble due to several client devices out of service). It will always poll on startup, even if I set the poll parameter to false and poll-rate very long. It also will generate the alarm and red-X's. Of course this behavior is undesirable for a known disabled client device.

I might be able to avoid the startup poll by connecting the parameter to a table and then database the table. I'll give it a try. This has worked for other startup initialization problems in the Modbus/Table combo.

Startup polling would normally be required for any devices you want online, else Lookout would not ever verify their true status.

It would be nice if all communicati
on objects (especially ones which are able to share a single COM port) had a Enable/Disable feature. This would allow a clean shutoff of startup and subsequent device polling which is something you ONLY want when you know devices are not there or when you simply want to disable communication with them without altually removing the object and it's dependencies.

For now, I just reduced the retries and lowered the response windows to limit communication delays with the remaining clients on the same port.

[Carl_Finley]

Sorry for the mis-information. My applications run 24/7, I didn't realize Lookout would poll on startup regardless of whether or not you want it to. Thanks for that info, I'm sure I will need to know that at some point. Now in the advanced settings for the MODBUS driver there is a box that is checked by default that says "Immediately write outputs". Is that box checked fir your driver? If so, will it help to uncheck that box?

[Khalid]

Hello Ed and Carl,

What Ed really needs is the SkipImmediatePoll entry in his Modbus INI file. This will prevent the Modbus driver from polling when the process gets loaded.

Here are the details for the Modbus INI settings:
http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/2e64d5cf87ca6a1086256bb30070dc1a?OpenDocument

As for the "Immediately write outputs" setting, if TRUE, Lookout writes any changes (outputs) immediately. Whereas if this is FALSE, Lookout waits till next poll to write the changes.

Hope this helps,

Khalid

[erblock]

Thanks Khalid.

I'll check this out soon.

Ed