What will be the best way to handle this data handling?

[Fernando Castro]

On my current application I am reading and writing recipe values from a data table, the recipe will have a variable number of steps, I already had the logic to navigate thru the recipe employing indexing numeric values in the screen ( 8 x 8 ) values of mixed data, some MI, ML, MB, and T.
The user requested a way to detect if there are some changes on the recipe that haven't been saved, and flag that row to ease the visibility of the changes made on the actual recipe.  The values of the recipe also should be required to be saved only if you press the save button since the recipe should be able to be edited "live" while the process is running and you want to execute all the changes of each step at the same time.

so, I was wondering if the best way to do it will be using a struct to store the values of each row on the screen to a vector each time the screen is refreshed (that happen when the user touches the Next or Previous pages, that changes the indexed number + 8 and reads the Data table corresponding to that indexes values and stores it to the variables that are on the screen), then have another struct that stores the variables that are on the screen to a different vector, and compare those 2 vectors to detect if some value has been changed but not saved ( since the values on the data table will be different from the ones on the screen).

However, my main concern is to do that with 8 structs for the DB, 8 structs for the screen, or use 2 structs only (1 for Data table 1 for the screen) and make a "sweep" thru the 8th current indexed values. that second option will implicate reading the data table 8 times per program scan rather than reading 8 times per page update. 
The main concern is rather to use more addresses in the memory or more time for each scan.

The other question that I have is what about using the Map function instead of a struct, there is a significant difference between those 2?

or is there a way to detect if the user has touched some variable  on the screen?

I personally dont want to keep using more vectors in the memory because at this point it may be difficult to keep track off all the memory addres that are being used

[Ausman]

On 7/9/2021 at 2:03 AM, Fernando Castro said:

The user requested a way to detect if there are some changes on the recipe that haven't been saved, and flag that row to ease the visibility of the changes made on the actual recipe.  The values of the recipe also should be required to be saved only if you press the save button since the recipe should be able to be edited "live" while the process is running and you want to execute all the changes of each step at the same time.

I'm reading this as meaning that the original and ALL the newly saved recipes want to be available for later viewing.  Is this correct?  If so, surely there is going to be an allowable limit to this.

On 7/9/2021 at 2:03 AM, Fernando Castro said:

I personally dont want to keep using more vectors in the memory because at this point it may be difficult to keep track off all the memory addres

Using many vectors is not necessarily a bad thing.  The main point to remember is to mark each operand of all the used vectors with a label showing that they are in use, and if "static" what that use relates to.  Without doing so the risk of vectors over-writing each other becomes high as the human writing the program misses the used part of a vector above/below the new one they are starting.

cheers, Aus

[kratmel]

I recently made a program for a plastic extruder. The user makes settings in 5 windows that will adjust to one recipe. Within each screen, I used the comparison method for a single part of the recipe (part of data table line of the recipe), not for the whole line. So there was a way that shows the user that the data on the screen is different from that specified in the recipe. I did this by hiding the SAVE button when the data is the same within the window. When at least one of the data is different, it changes color and the SAVE button appears, which disappears if the user has already saved the data in the recipe and they are the same as on the screen. There is a separate window for viewing the whole recipe - but as practice has shown - users like to display individual parameters within the window. The main task of employees is to use only permitted recipes. Therefore, after some time, managers have a wish that the SAVE key not only saves the changed data in the recipe, but also asks for a password before saving. So the manager sees the data changed by the operator in the process - if they are correct in his opinion, he saves them to the current or new recipe. As for scrolling the entire line of the recipe, this is possible only if all the data is visible on the screen at the same time. If there is more than one screen then scrolling recipes requires switching windows and leads to errors.

[Joe Tauser]

In a Vision PLC, the memory is always there whether you use it or not. Your double copy buffer / look for changed data idea is the way to go.

On 7/8/2021 at 11:03 AM, Fernando Castro said:

or is there a way to detect if the user has touched some variable  on the screen?

There is a system bit (SB 16) that activates whenever the screen is touched.   There is also a pair of system integers (SI 40 and SI 41) that return the coordinates of the touch point.  Since you have Previous and Next buttons a slick way of determining whether the user touched the recipe area would be to combine an MB tied to the Recipe screen active and then look at those coordinates to see if they touched something in the recipe fields area.

However, this does not tell you if the user actually changed the value.  As there is no "Data Table Compare" function, you'll have to go through comparing each record as they are edited.

On 7/8/2021 at 11:03 AM, Fernando Castro said:

The user requested a way to detect if there are some changes on the recipe that haven't been saved, and flag that row to ease the visibility of the changes made on the actual recipe.

  The only way I can think to do this is to add another field to the recipe table and set a bit or a count for a detected change, and then display this along with the recipe data.  A bit would do if it's only going to change once, but if somebody gets in there and starts having a tweaking party you could make it an integer that incremented each time it changed.  A "Manager Approves"  button could reset it.  You do have a user table with different access levels, right?

I have often said that the code to drive the displays can get a lot larger than the code to run the process.  This application sounds like it qualifies.

Joe T.

[Fernando Castro]

On 7/10/2021 at 9:43 PM, Joe Tauser said:

I have often said that the code to drive the displays can get a lot larger than the code to run the process.  This application sounds like it qualifies.

Joe T.

Oh boy! it surely does, the ammount of small details im implementing for this is crazier each time... the end user will be requesting new changes until there is no more time to do changes