I think I found a bug in the visilogic software?

[Fernando Castro]

Hi all first, I want to say that although I really hated unitronics at the beginning I am quite impressed by the capabilities of the PLC+HMI all in one.
so, I am using the Linearization function as follows: I convert a timer into a numeric value and then ramp up or down some variable, in function of time, my values are X2,X1, Y2,Y1, X, Y...a simple linear function. let's have this example  going from 6000 to 600 in a period of 5hrs, so the variables are as follow
X2=0 (End value as timer goes to 0)
X1=1800000 (timer value 5:00:00:00 loaded on ML)
Y2 = 6000
Y1=600
So far is a simple Linearization larger time value =minimun value, smaller time value = maximum number value the time is going down while the output is going up? So the linearization function "works" but at some specific time values boom! the output ..overflows?

 

 

The green line is the timer going down, about at a remaining time of 3:53:40 (1402000 in the ML) the output value of the LINEAR function suddenly increases by 2400 then goes back and then increases by 2400 again, this happened again at another time with another set of variables 3:00:44:13 (1084413 in the ML ) going from 3500 to 500

 

 

 

 

I know that the linear function has its limitations but even with these limitations I am working within the range  :
"
Note ♦
The X and Y values must not exceed the range of -2147483648 to +2147483647.
Known Issue
Note that the Linearization function cannot be used in cases where one of the following is close to the value FFFFFFFF:
One of the inputs
An intermediate calculation"

So in conclusion, I am doing something wrong, or is this some stupid bug?.... this particular issue was about to be catastrophic for my application

 

 

 

I added a test program that runs on V700  hardware to demmostrate the issue

TEST.vlp

[kratmel]

Hi,

maybe i know what is wrong.

Your application works in real time. Then sometimes linearization maybe do not end at the time when ML must be reloaded.

In ladder code you send timer to ML and after that do linearization.

Please try to change ladder net - first linearization - then copy timer to ML.

 

P.S.   This problem appear only in this two times at every working cycle or bug happend in different time point at every new cycle?

[Ausman]

Why do people constantly focus on timers for a time based need?  Maybe it's the name....Timer!

I've often harped on the often huge benefits of not using timers, instead using counters based on SB13 & 15. For particular needs the method is far easier to work with and offers way more complex possibilities throughout the run.  In this case I think it would make things much simpler with a little bit of maths instead of using the converted timer through the Linz function, and would likely get around your issue which I doubt is a Linearisation error, but rather some other reference being done to your ML which is upsetting things.

A quick look at your program and there are glaring errors in that you are conditionally calling your subroutine, that also involves sets and resets of the thing that calls the sub.   It is all just way too complex and likely to cause issues.  Also, split up your ladder work.  Rung 1 in your Step.Run is an example.

However, a simple test for you to do to narrow down the error would be to use a vector of MLs to check on each scan whether it has changed each scan, and if it has to record it sequentially in the vector on a FIFO basis.  If the output error occurs let the system run a few more scans and then stop the process and look at the stored MLs.   Things can happen in scan times that aren't picked up by online monitoring.   Kratmel is possibly on the right path as your procedure might  fall into the "An intermediate calculation" ruling.  But my main thought is that something else is going on that you have missed, like the ML being inadvertently part of a vector etc.

Honestly, I'd start again and think of using my counter method instead.  If you wrap your head around it properly you'll find it way easier for what you appear to be wanting to do, and will use far less ladderwork that will be much easier to follow.  Especially in years to come where you'll be going "what the *&^% have I done here?"

cheers, Aus

 

[Fernando Castro]

The problem is not the ML being part of another vector, the program that I uploaded was done in a new project, I extracted the part of the code that was having problems to a subroutine, (That why is being called as a part of the main routine on START RUN), ignore the Sets since this is not the full program I just did not bother adding the Resets. the uploaded program was only for test and was intended to be downloaded into a PLC and start once, I just wanted to test the issue without anything else in the PLC.
I know that Rung 1 on Step.run looks weird but if you look closely MB1988 is the same contact just NO and NC on each branch so is technically correct for the software... I mean MB1988 can not be Open and Closed at the same time... just the same as doing this at some point : 

 

Why do I use timers instead of counters and ticks... well this is a good point and the main reason is kind of complicated to explain, but In my defense, I am not doing anything that isn't supposed to be done. Long story short I need to load recipes with many times that could be as many Hrs, minutes, and seconds as the user wants and many many steps, ok so the easiest way to handle that is to have a time input on the screen and then load the time into ML that way I have a number that can be counted and easy to handle in the recipe and changed at any point, I mean I guess I could have the input for HH MM SS and then convert to a number and count but it's having more steps than load the timer value on a ML, since the ML is updated ever time the time changes I don't need to count anything so...

In short, the weirdness of the program is de a "copy and paste" and some things deleted but the logic is not complex at all, and I am following all the indications in the manual, any way you had a good point if this is a LINEAR function problem I should have the same behavior using number counting instead of time conversion I will try that and test.

By the way, my logic is already solved and runs great, I decided not to use the linear function since the problem was there and do the math instead with the time loaded on the ML.

[Fernando Castro]

20 hours ago, kratmel said:

Hi,

maybe i know what is wrong.

Your application works in real time. Then sometimes linearization maybe do not end at the time when ML must be reloaded.

In ladder code you send timer to ML and after that do linearization.

Please try to change ladder net - first linearization - then copy timer to ML.

 

P.S.   This problem appear only in this two times at every working cycle or bug happend in different time point at every new cycle?

I already did the change and same thing happen but kind of different, instead of a step looks like a spike but still overflows above 7000 while the maximun value in the LINEAR function is 6000

I am going to test with a counter and let you know if the same happens

[Fernando Castro]

Me again, I tested those 3 options:

• The red one is using the time loaded on an ML and then the LINEAR function as mentioned before.
• The green one is obtained by loading the initial ML value of 5 hrs (1800000) at the beginning, and then subtracting on each SB 13 (They don't match because I tweaked it to do it at a different rate than the real-time ) using the LINEAR function.
• The Yellow one is the mathematic formula that does the same as the linear function using time loaded on ML in real-time as an input.

So based on this evidence, seems to be an issue with the LINEAR function as I suggested before, not with the Time or the ML used to store the variable being used on another vector (There is nothing else running in the background of this program)

 

[Ausman]

Pls upload the program you've done for the example above so that others can run it and check.  I can't as I don't use 700s.

 

9 hours ago, Fernando Castro said:

still overflows above 7000 while the maximun value in the LINEAR function is 6000

Reading the above makes me think that you don't know a crucial thing that linearisation needs to work properly.  It does NOT stop at the Max and Min values you specify.  If your program is going to possibly give readings that will overshoot you have to have Max and Min compares going on that store the max or min value if an overshoot has happened.  This is done directly after the linearisation in the ladder.

This is a confusing thing for first time linearisation users.  Pls read this entire topic: 

As far as I know this hasn't been done yet. One for  @Cara Bereck Levy to ask?  .....Again.    I've always said I don't think it could be too hard, but I do know that the Vision system has limited "space" for mods.

cheers, Aus

[Fernando Castro]

11 hours ago, Ausman said:

Pls upload the program you've done for the example above so that others can run it and check.  I can't as I don't use 700s.

 

Reading the above makes me think that you don't know a crucial thing that linearisation needs to work properly.  It does NOT stop at the Max and Min values you specify.  If your program is going to possibly give readings that will overshoot you have to have Max and Min compares going on that store the max or min value if an overshoot has happened.  This is done directly after the linearisation in the ladder.

This is a confusing thing for first time linearisation users.  Pls read this entire topic: 

As far as I know this hasn't been done yet. One for  @Cara Bereck Levy to ask?  .....Again.    I've always said I don't think it could be too hard, but I do know that the Vision system has limited "space" for mods.

cheers, Aus

🤦‍♂️ @Ausman  you keep assuming I don't know what I am doing.... so, ok I will assume that you are NOT being arrogant and that maybe I was not clear on my previous statement due to a language barrier.  of course, the LINEAR function will not stop at ar min or max value, that's the point of a linearization you gave the "initial" and "end values" to calculate the "slope" you don't expect that the linearization ends at certain values, I have that on consideration on my actual program, and I handle the min arnd max values in a particular way to prevent being out of range.

what I was trying to explain is that it overshoots over 7000, and the max value is 6000 which corresponds to 1800000 value on ML100, and at that point, since ML100 is near 1402000, then it couldn't be possible that the value at the output of LINZ is more than 6000 which is the value at 1800000 since 1402000 is less than 1800000 (you know... math).

but, let me give you more information, in the machine that I was running the program I noticed the issue looking at the data after an imminent failure involving this LINZ problem:

In this case, blue is what was sent to the analog output, in my program I have a condition to no update that value if it's out of range, I am not sending the max or min possible values if it is reached, instead I am just not updating the output (this is better for my particular process, and it helped in this situation because that spike after an hour the start of the ramp down would be very very bad, at least I got 1 HR of stable conditions after that )
anyway, as you see in the red line that I have drawn (which is what I concluded was happening in the background), at some point the value overshoot at above 7000, and then continue going down but 1 hr after that the value reached 6000 again (since was going down from 7000 now) since 6000 is within range, the output was updated again, that's what we see a "step" at the last 3 minutes, after that the system was shut down and then reset to the initial conditions, that's why it goes to 0 and 600 ( initial PW =600) 
the orange line is what was desired to happen .... a linear and consistent ramp down from 6000 to 600 while counting downtime.
I am not going to upload any other program, I already did it.
It will be better if you could do a test and prove on your hardware,  maybe is a v700 issue, maybe is a Visilogic Issue, who nows!
test different hardware could be good. 
Start the countdown with these values
X2=0 (End value as the timer goes to 0)
X1=1800000 (timer value 5:00:00:00 loaded on ML)
Y2 = 6000
Y1=600
countdown to 0 and wait.
the overshoot happens near X= 1402000 (Not exactly at that number but I always override the timer at (3:55:00) and wait for until happens (a couple of minutes later)
I already did it counting down from 1800000 and the same happens.

 

 

[Ausman]

12 hours ago, Fernando Castro said:

you keep assuming I don't know what I am doing

Not once have I said that.   My responses are based on I don't know how much you know, as you are new here. 

Don't forget I am not paid, I am a volunteer who has put in countless hours on this forum often explaining the same thing again and again to people who can't be bothered to look up help files or delve into the forum.  Think how you might react if you were again asked how to turn on a light switch!

I have never had this issue myself, but I also only do linearisations on MIs.  What happens if you convert your input numbers to MIs?  Your needed output will still give the same accuracy on the smaller input range that is available with MIs.  Using a counter based on SB13 will let you test this easily with your wanted time of 5 hours.  I can't as I don't use 700s.

cheers, Aus

[Cara Bereck Levy]

On 6/18/2021 at 2:39 AM, Ausman said:

 It does NOT stop at the Max and Min values you specify.  If your program is going to possibly give readings that will overshoot you have to have Max and Min compares going on that store the max or min value if an overshoot has happened.  This is done directly after the linearisation in the ladder.

This is a confusing thing for first time linearisation users.  Pls read this entire topic: 

As far as I know this hasn't been done yet. One for  @Cara Bereck Levy to ask?  .....Again.    I've always said I don't think it could be too hard, but I do know that the Vision system has limited "space" for mods.

cheers, Aus

I'll check with the team and get back to you 🙂

 

[AlexUT]

This problem is "invented".

Vision timer has format:

HH:MM:SS.mm -> 5:00:00.00

Not X1=1800000 (timer value 5:00:00:00 loaded on ML)

Minimum timer interval for timer is 10 mSec.

For 5 hours interval you do not need precision of 10 mSec.

So value in ML for 5 hours (in seconds) should be 18000.

Hope that precision of 1 sec will be more than enough for your linearization.

Even 1 minute step will be good.

In this case linearization should work.

If not - use formula from Help.

 

[Fernando Castro]

2 hours ago, AlexUT said:

This problem is "invented".

Vision timer has format:

HH:MM:SS.mm -> 5:00:00.00

Not X1=1800000 (timer value 5:00:00:00 loaded on ML)

Minimum timer interval for timer is 10 mSec.

For 5 hours interval you do not need precision of 10 mSec.

So value in ML for 5 hours (in seconds) should be 18000.

Hope that precision of 1 sec will be more than enough for your linearization.

Even 1 minute step will be good.

In this case linearization should work.

If not - use formula from Help.

 

Yes, I don't need the precision of ms but, that's the way the time works, if set a timer of 5hrs y got an MLof 1,800,000.

the point is using a time input directly stored on an ML, and handle a TIME input as a number that would be easy to handle, what you suggest is to use minutes as hours, seconds as minutes, and 10msec as 1 sec. that would work for having an input of "REAL TIME" to an ML but I could use the same timer counting down as an input.
My core logic is simple:
1. Have a TIME input on the screen
2. Load that TIMER on the ML
3. Start the TIMER
4. Get the output as a function of time.

Again, that's the "easiest" way to handle a recipe with MANY time inputs, that way I use the screen variable timer as an input because I have 1 input per time value and I don't need to convert HR:MM: SS and count, since a single LD does that conversion and just need to start the timer.

As mentioned above I solve the problem by not using the LINEAR function and using the math of linearization on a formula, I am not asking for a solution. I already solved it and the software has been running without problems.

Maybe I am using this in a way that was not thought before (I get that using a timer to count down and that as an input on a linearization is not a usual thing) In my opinion that was a very creative solution to a very specific problem that I needed to solve.

The issue here is that this conditions on the LINEAR function: 
X2=0 (End value as the timer goes to 0)
X1=1800000 (timer value 5:00:00:00 loaded on ML)
Y2 = 6000
Y1=600

should work for every value from 180000 to 0, because every value is within the ranges that the help file listed, I read that before even try.... and to be honest the solution worked until the right conditions meet and then it did not.

 

 

 

 

[Fernando Castro]

On 6/18/2021 at 8:51 PM, Ausman said:

Not once have I said that.   My responses are based on I don't know how much you know, as you are new here. 

Don't forget I am not paid, I am a volunteer who has put in countless hours on this forum often explaining the same thing again and again to people who can't be bothered to look up help files or delve into the forum.  Think how you might react if you were again asked how to turn on a light switch!

I have never had this issue myself, but I also only do linearisations on MIs.  What happens if you convert your input numbers to MIs?  Your needed output will still give the same accuracy on the smaller input range that is available with MIs.  Using a counter based on SB13 will let you test this easily with your wanted time of 5 hours.  I can't as I don't use 700s.

cheers, Aus

Fair enough @Ausman. 

 

I doubt this issue will be happening with an MI since the MI can't store 1,402,000. however, maybe this will be happening with another set of numbers? that is difficult to know.

By the yaw ML are accepted by the LINEAR function that's what HELP file says:

You can convert values contained in the following operand types:

• Memory Integer (MI)
• Memory Long Integer (ML)
• Double Word (DW)
• System Operands:(SI) (SL) (SDW)

 

I am just reporting what I think could be a bug, also reported directly to unintronics support as soon as I spot it, if I am doing something wrong I will be glad to know, maybe I am just being stupid but so far I haven't found an explanation of why this is happening.

 

 

 

[AlexUT]

1. After loading timer value to ML, divide ML by 100 and it will be in seconds.

2. The fact that linearization accepting big values (ML or MI) does not mean that you should use big values.

There are multiplication and division inside linearization FB and in some cases result may surprise you.

2.1. You always should test worst case.

2.2. In case of not accepted results you have to optimize used numbers.

B.R.

 

[Flex727]

19 minutes ago, AlexUT said:

There are multiplication and division inside linearization FB and in some cases result may surprise you.

This is what I suspected all along. There is math behind the scenes to execute the linearization function. Trying to linearize very large numbers can result in a register overflow somewhere in that math. Use AlexUT's suggestion to divide the ML by 100. It's very simple, can be in the same ladder rung, and doesn't even require another operand.

[kratmel]

I pulled a V700 out of my cave and tried to experiment with this strange case of linearization block behavior.

My goal was to determine if the problem was dynamic or static. That is, whether the sequence of actions affects the result. The answer is no.

The result of research for the data submitted by the author:

the first transition to the wrong result 1402485 to 1402484

then return to the correct one 1402318 to 1402317

again going abroad 1402152 to 1402151

The result is repeated in both directions of calculation.

The problem changes if you change the number 6000 to a smaller side. But as I understand it does not disappear but moves to another range of values.

Replacing 600 and 6000 gives the same result only on the contrary - we fall into the negative values of the result. So my conclusion is: the problem is the result of a combination of values.

In the case of microcontrollers with a limited calculation data bus and a problem with negative values, it is this combination of data that goes beyond the calculations.

Therefore, for practice we have the solutions defined above, and from the point of view of the linearization block, working with large values gives the probability of exceeding the capabilities of our PLC.

Working with the formula, we can predict overflow and bypass it, taking into account the order of calculations.

It is impossible to do this for a closed standard block.

Therefore, if you saw a problem in the operation of the standard linearization and solved the problem via formula - PLC generally corresponds to your task.

 

[Fernando Castro]

11 hours ago, Flex727 said:

This is what I suspected all along. There is math behind the scenes to execute the linearization function. Trying to linearize very large numbers can result in a register overflow somewhere in that math. Use AlexUT's suggestion to divide the ML by 100. It's very simple, can be in the same ladder rung, and doesn't even require another operand.

🤔I get what you are saying, basically a decimal point shifting, I guess that's a good and simple solution... I solved it by doing the math with floatings and discarding the decimals which in a way is the same but yea the div seems simpler, I also thought that has to do with some calculation in the background.

anyway now I trust more in the math than in the linear function

[Fernando Castro]

Probably no one else cares about it, but I found another bug in visiologic software. I don't know what happened but I edited one line of a program, then did the same change in another revision. both lines of the program are identical but one works the other does not.
 
I Just exported the working subroutine and replaced the nonworking one but. this kind of thing is not supposed to happen, at least is the first time that I see something like this on PLC software. 😤
 
I could be spending weeks trying to figure where was the problem
 
I looked at the STL view and seems that the data from the formulas is somehow different from one to another.

 

100,7,42,3,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,66,10,0,0,0,5,15,200,66,0,0,6,5,37,0,0,0,2,255,0,0,0,0,1,255,0,0,0,0,5,5,35,0,0,0,6,15,200,66,0,0,40,40,68,101,115,105,114,101,41,42,49,48,48,47,77,77,95,80,69,82,95,82,69,86,41,42,83,84,69,80,95,80,69,82,95,82,69,86,47,49,48,48,79,80,66,0,10,0,5,0,37,0,5,0,35,0

vs

 

100,7,42,3,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,66,10,0,0,0,5,37,100,0,0,0,6,5,37,0,0,0,2,255,0,0,0,0,1,255,0,0,0,0,5,5,35,0,0,0,6,37,100,0,0,0,40,40,68,101,115,105,114,101,41,42,49,48,48,47,77,77,95,80,69,82,95,82,69,86,41,42,83,84,69,80,95,80,69,82,95,82,69,86,47,49,48,48,79,80,66,0,10,0,5,0,37,0,5,0,35,0
 

I am not sure what those numbers mean but seems to be the formula translated to some decimal or other format.

 

anyway the formulas are the same in the text format

((Desire)*100/MM_PER_REV)*STEP_PER_REV/100

vs

((Desire)*100/MM_PER_REV)*STEP_PER_REV/100

 

or ... maybe the data was corrupted?

 

Feel free to take a look, even the software handles both same routines as being different if you try to download a projet that has one instead of the other.

 

P.D. I am not the original autor of this program, I just  changed the result of the formula to be at MF instead of ML then because I needed more precision

find the difference..vlp

[sgull]

If you have done a lot of downloads to the PLC data can get stored in registers where you might not have intended.

Every now and again it is a good idea to download a blank program and do an initialize and reset.

then try your program again.

[Ausman]

4 hours ago, Fernando Castro said:

I Just exported the working subroutine and replaced the nonworking one

Importing and exporting subroutines has to be done with extreme caution.  The imported one over-writes any operand references in the "importee".  I have asked for a "blank" subroutine export to happen, but it hasn't and I don't think it will.

https://forum.unitronics.com/topic/4188-subroutine-import-with-dummy-ids/

As Sgull has said, many issues are overcome with an Init and Reset and/or a blank program.  Point 13 in pinned "Topics almost worth pinning."

Cheers, Aus

[Fernando Castro]

4 hours ago, sgull said:

If you have done a lot of downloads to the PLC data can get stored in registers where you might not have intended.

Every now and again it is a good idea to download a blank program and do an initialize and reset.

then try your program again.

yes, I also have experienced that a lot!. I need to finish a new version of the software and update near 200 devices, but so far I haven't found a proper way to do a "backup"  "update" and "restore" the old values for some settings, and also change others on each download. 

 

It's crazy how I can do multiple downloads on the same device and same computer after some tests and have some settings now to be different. I mean most other brands ask you to keep or change values stored in memory, but unitronics seems to do, it only for timers... and also what about everything being persistent in the memory 

 

I really like the hardware but the software Is so Confusing and frustrating!! 

[Flex727]

14 hours ago, Fernando Castro said:

I mean most other brands ask you to keep or change values stored in memory, but unitronics seems to do, it only for timers... and also what about everything being persistent in the memory 

This is correct. I, likewise, wish there was an option for integer registers during download like there is for timers. However, no integer register should be affected by a download. The only reason a register's value might change is due to ladder logic or a Power-Up value when the PLC is reset. Do you perhaps have some Power-Ups you're unaware of? Downloads sometimes reset the PLC then the Power-Up would take effect.

[kratmel]

17 hours ago, Fernando Castro said:

It's crazy how I can do multiple downloads on the same device and same computer after some tests and have some settings now to be different

For a long time i try to solve this problem.

Then my solution - use little different style of programming.

Then all my current application has default settings option (copy from datatable to user settings).

I use datatable - that it can be downloaded separately - used for change something default in process of project modification (save user settings to datatable as default option present on PLC  via password).

If user need to change something  (not recipie) - it have printed table with default and user changed settings. Then if something goes wrong - user can load default option -and change only small amount of parameter to start machines.

Maybe this idea need more time for programming but it help to restore and modify project whithout problems.

17 hours ago, Fernando Castro said:

I haven't found a proper way to do a "backup"  "update" and "restore" the old values for some settings, and also change others on each download. 

 

User settings for working application (all operand) - can be exported to txt file (Visilogic menu option) and saved in current downloaded project directory  named as PLC serial# and time of modification.

I can compare the same format files with different operand settings. And load specific operands backup to PLC.

 

 

[Fernando Castro]

19 hours ago, Flex727 said:

This is correct. I, likewise, wish there was an option for integer registers during download like there is for timers. However, no integer register should be affected by a download. The only reason a register's value might change is due to ladder logic or a Power-Up value when the PLC is reset. Do you perhaps have some Power-Ups you're unaware of? Downloads sometimes reset the PLC then the Power-Up would take effect.

I have a case in which a particular setting was changed after downloading a new revision, I downloaded a beta version of the software on Friday, tested and worked ok. then keep adding features over the weekend (minor aesthetic changes requested by the user) then on Monday downloaded the newer version to test the process with the product. Long story short one of the settings on the calibration screen was changed and the pressure reading was off by 10 mbar which caused a very unstable process. I am not sure what happened since that particular MI can only be changed on the settings screen password protected, I guess that the MI on the project could be changed while running online on the plc that I use for testing. I did backed up the operands from the machine just for precaution before updating it but I did not think that I would be needing to restore it... the machine have not been running since Friday.

 

16 hours ago, kratmel said:

For a long time i try to solve this problem.

Then my solution - use little different style of programming.

Then all my current application has default settings option (copy from datatable to user settings).

I use datatable - that it can be downloaded separately - used for change something default in process of project modification (save user settings to datatable as default option present on PLC  via password).

If user need to change something  (not recipie) - it have printed table with default and user changed settings. Then if something goes wrong - user can load default option -and change only small amount of parameter to start machines.

Maybe this idea need more time for programming but it help to restore and modify project whithout problems.

 

User settings for working application (all operand) - can be exported to txt file (Visilogic menu option) and saved in current downloaded project directory  named as PLC serial# and time of modification.

I can compare the same format files with different operand settings. And load specific operands backup to PLC.

 

 

Maybe the online carries out some operands with it after you log off and if the project is saved some values too?
maybe the best way is: go online, export the operands, then download the project then import the operands again?

Anyway, the data table seems to be a tempting option to be able to manage the 200 devices in the future or at least have a subroutine for loading the default values, the other issue that I have is the standardization of the process 😑 having that option is pointless if every system had different settings due the nonstandard and manual adjustments that each one needs. 

One of my professors used to say that a good design needs fewer adjustments 

 

[kratmel]

2 hours ago, Fernando Castro said:

best way is: go online, export the operands, then download the project then import the operands again?

Yes! It is my standard process of upgrade.

 

2 hours ago, Fernando Castro said:

One of my professors used to say that a good design needs fewer adjustments 

I newer change current version of PLC program. First of all i  "Save as" current version to the new one #+1 and then make changes.

After implement changes - type on paper what is changed and what new settings appear.

Than last machine project go to user with #15 software realase.  One more increment needed after onsite testing.

After all is OK - operand is exported to file and saved with last used project version #.

 

2 hours ago, Fernando Castro said:

Anyway, the data table seems to be a tempting option

But data in table  is not owerwriten when new project update is downloaded.

Separate data table synchro needed.