PID objects stays frozen if process is loaded from .lks File

[alex m]

I noticed from customers that if I update their process file, usually I send them a new .lks file and they compile it at their machine.

It is required to send them the .lks file since there is a Lookout version difference and it doesn't want to accept .L4P created in older Lookout.

If the Process contains any PID objects.  PID's stay frozen without any output, equal zero and not responding to setpoints.

User has to go into Edit mode and has to click at any of the PID Object yellow fields and OK to exit the object, it works immediately.

Basicaly there is no change made in the Lookout Code it is just a Edit Object, Mouse click, Close Object.

If you look on this from programmer side this doesn't make any sense since the code remains unchanged.

(I tried to load the process from .lks file on my machine and it happens the same.)

[Ryan.S]

It's better if you can attach that .lks file or a simple demo and let's reproduce  the problem.
What's your and your customer's lookout version?

[alex m]

Here is the PID Object.

Input is Temperature reading from PLC, Setpoint is a Pot 0-100, set to 90.

However, even if PID works as ON/OFF only, it is the same thing.

There is no problem with the code since the code remains unchanged, it is a just a click at yellow field which "awakes PID from sleep".

Lookout versions: It was varying from 4.5 to 3.8 , 4.5 to 5.1. or latest 6.0 to 5.1

Versions 3.8 through 5.1 are not backwards compatible with 6.0

Most arger comes from our customers, who lets say they paid 3000$ for Lookout 5.1  two years ago and 6.0 upgrade would costs them additional 500$ just because the Header in first 20 rows of .lks code is different between 5.1 to 6.0. About other software improvements made in 6.0 version  they just don't care.

For me also is unconvenient to send them an process upgrade compiled in 6.0 to work on their 5.1 machine since I have to manually reedit the code every time.