Forced Input Status

[Grizzy]

A very useful tool used in industrial control system program design, development, and trouble shooting was the ability to FORCE a digital input to a true or false status.

 

For the ISY it also will be an indispensable tool in program development and testing.

 

This allows the program to execute a given probable real life condition. The programmer can easily do this from the console without the hassle of tricking an actual field sensor to change states.

 

This can be accomplished from the device right click menu. Any device when FORCED to a value would have its icon with a circled F, showing it has a forced status.

 

This also allows an easy method to assure a program will follow a given path when executed.

 

Also it is an easy way to disable a partial or full program sequence.

 

Another side benefit is simple method to ignore a sensor:

Say we have 6 motion sensors that trigger an alarm system. We have guests for the night but they will likely trigger 1 or 2 sensors, so we don't arm the system. If we could just force those 2 sensors to a false value we could still arm the alarm system.

 

Many advantages !

 

In the industrial programming this was our most valuable tool for program development and testing.

 

Anyone familiar with ladder logic will know exactly what I'm referring to, but it will work in any programming environment.

 

Thanks for your consideration

Don

[Teken]

Hello Don,

 

Currently in the ISY the end user has the ability to run any of the conditions whether it be IF, Then, Else, simply by right click mouse.

 

Does this not meet one of the criteria? 

[Techman]

Don

 

Re: the motion sensors, you can right click on a device and disable it.

 

and/or submit a product request to have UDI include "disable / enable" as a program option

[Grizzy]

Hello Teken,

 

That is a terrific feature, one that I had not seen until I got the "ISY".

 

With that terrific feature the program must still execute with the device input status being what it actually is.

 

When trying to " RUN IF " I would have to get the hardware input device to send me the desired true or false status before hand to see the results.

 

On a simple single block program I could " RUN THEN " or "RUN ELSE " and not have to worry about the device status because I will see the result true or false.

 

However on a complex multiple block ( sub programs or subroutines ) the device status could again be a conditional that would effect the outcome without having the desired device status.

 

If I had the ability to force a device status to true or false I could run the program without messing with the actual device trying to get it to send me the desired true or false ( on / off )

 

 

Does this make sense , sometime it is difficult for me to adequately put in words what I'm thinking.

 

Don

[Grizzy]

Hello Techman,

 

Thank You for the information, I did not see that option.

 

Can you tell me in a multiple "IF" conditional with say 6 motions sensors OR'd together if I disable one how does the program treat the disabled sensor?

 

Is it treated as "Ignored, Treated as False or Treated as True"

 

Don

[stusviews]

You could force the "IF" to evaluate as false by including a false "AND" condition.

[stusviews]

Can you tell me in a multiple "IF" conditional with say 6 motions sensors OR'd together if I disable one how does the program treat the disabled sensor?

 

OR statements are evaluated as true unless each and every statement is false. AND statements are evaluated as false unless each and every statement is true.

[Grizzy]

Hello Stusviews,

 

Good work around I had not considered. Thanks

 

I have temporarily replaced a device with one that I can easily manipulate to do my testing.

 

Again this has to be done everywhere the device status is used and in a complex program with subs (pgm1, pgm2, pgm3 etc) it would require substantial changes.

 

Having the ability to "FORCE" the status would be simple clean and easy to undo.

 

Don

[Grizzy]

OR statements are evaluated as true unless each and every statement is false. AND statements are evaluated as false unless each and every statement is true.

 

I agree, However if one is "disabled" how is it treated ?

[stusviews]

If the device being queried is disabled, then how it is evaluated will depend on the state it was in when it was disabled. The device will not be ignored in a program.

[Grizzy]

If the device being queried is disabled, then how it is evaluated will depend on the state it was in when it was disabled. The device will not be ignored in a program.

 

BUMMER,

 

I was hoping it would just be ignored, like placing a "REM" command in front of basic program line.

 

Thank You VERY MUCH that is something I will have to keep in mind if I disable a device.

 

So again if I had the ability to "FORCE" a status this would not be an issue as I would force it to a value true or false depending what was required to disable it.

 

Thanks Again for the valuable feedback.

 

Don

[Techman]

.

 

Another side benefit is simple method to ignore a sensor:

Say we have 6 motion sensors that trigger an alarm system. We have guests for the night but they will likely trigger 1 or 2 sensors, so we don't arm the system. If we could just force those 2 sensors to a false value we could still arm the alarm system.

 

 

 

Don,

 

Another (simple) option would be to put the 2 motion sensors that you don't want active into a separate program. You could then disable/enable that program using a button on a KPL.  The light on the KPL button would show you the status of those sensors.

[Grizzy]

Don,

 

Another (simple) option would be to put the 2 motion sensors that you don't want active into a separate program. You could then disable/enable that program using a button on a KPL.  The light on the KPL button would show you the status of those sensors.

 

Good idea. I have not yet had the pleasure or heart ache of programming a keypad. I get the idea from some of the posts they can get complicated.

 

My goal when starting this post was hopefully there was already an option to force a status and  I was unaware of it.

 

AND if not , try and get enough feedback to get the folks at UD to consider adding this to their honey-do list.

 

Given the suggestions thus far, the simplest means would be an option to "FORCE"  a device status to a predetermined level for testing and functionality. 

 

I know from years of experience in industrial control programming, the "FORCE" option was without any doubt an indispensable tool. 

 

I appreciate hearing the different alternatives,  as with any program there are as many ways to get from point A to point B as there are programmers. I always learn something new when seeing how someone else got from point A to Point B.

 

Have an open mind and there always room for more

 

Thanks and please keep the suggestions coming.

 

Don