TIMEPROP in Stages

[RBPLC]

I have a TIMEPROP running in a stage. When initially coming into the stage with the TIMEPROP instruction, the discrete output should be off based on the Continuous Input, 0% and 100% range. Sometimes the discrete output comes on after entering the stage even though the Continuous Input is lower than the 0% range. It does this only for a short period of time (I suspect tied to the cycle time of the instruction) and then turns the output off. When the Continuous Input rises above the 0% value, the TIMEPROP then seems to begin to function as intended. It looks like the initial turning on behavior only occurs if the stage was exited while the Continuous Input was between the 0% and 100% range of the instruction. I suspect this behavior is tied to the timer associated with the TIMEPROP, exiting the stage with some accumulated timer value in the instruction and upon reentering the stage the timer has to finish running to completion in order to rightly evaluate the output. For my application, I think I could get by with this behavior but it would be ideal for the instruction to not come on until the Continuous Input is between 0% and 100%. BobO or franji, can you guys confirm this is what is happening? Is this the intended behavior? Is there a way to prevent this? 

[BobO]

It's probably a side effect of the sampling code that was added to fix a previous complaint. If I'm recalling correctly, it was originally fully stateless and the complaint was that changes in the input could cause the current output cycle to glitch. The fix was adding a stored sample of the input that is only refreshed when the timer expires. I'm wondering if it is still holding the old value on the initial pass, then getting corrected. Should just be a matter of clearing the instruction workspace on termination. Maybe. Hopefully.

[RBPLC]

Is there a post of the previous problem you're referencing?

[BobO]

Is there a post of the previous problem you're referencing?

I'm sure there is, no clue where. It technically wasn't a problem, user just didn't like the way it worked. We tried to improve it by only sampling the input at the start of an output cycle. That forced storing state where we hadn't made provision to do so. In cases like that we use an area of memory we call the instruction workspace. I suspect there is some state hanging around from the last pass. I will look to see if there is an obvious way to clean it up. We generally try to do so in termination, but I'm thinking the workspace isn't getting cleaned.

[Mike Nash]

Is there a post of the previous problem you're referencing?

Maybe this one.

It was hugely helpful for me at the time.

https://forum.hosteng.com/index.php?topic=2946.msg23411#msg23411

[BobO]

Is there a post of the previous problem you're referencing?

Maybe this one.

It was hugely helpful for me at the time.

https://forum.hosteng.com/index.php?topic=2946.msg23411#msg23411

Yes. Blame Mike Nash. 

@RBC I looked through the code, and am almost certain it's the old value hanging around for one time cycle that causes the issue. It actually the opposite of the problem of run mode updates I mentioned in the other thread. In that case, the workspace gets cleared, forcing a new sample of the input. In your case, the previous sample of the input was hanging around. I added the code to clear the cached input on stage termination. That should eliminate the issue.

[RBPLC]

Thanks BobO. I assume with the next release, whenever that is  .

[BobO]

Thanks BobO. I assume with the next release, whenever that is  .

Soon. Whatever that means.