I have a query that has about 60 data points that I would like to use to populate components. Currently I have the components expression bound to the data, but I'm thinking I need to have a bidirectional binding, so it seems a UDT memory tag might work. I could bind the tag's parameters to each data point from the query (to read the data), then have a bidirectional binding from each component to the parameters on the tag. Then, I could pull the values from the tag when I need to write to other tags to update the PLC.
Creating a persistent copy of data in a tag where the values are already stored in the database is rarely the best option IMO.
Since the data is coming from the database then the database would need to be updated to change the data.
Why not use lookup expressions and a custom property to hold the raw dataset? What are you trying to accomplish that you think you need it to be bidirectional?
Not in this case. The data coming in may get adjusted, then pushed out to their respective PLC tags to setup the equipment for the next run. Then, after some additional tweaking and the product looks good, that data would then be inserted to the DB.
from my limited experience, using something besides the raw dataset to hold edited values makes it simpler to push the data to it's destination. A custom prop does store the dataset, and each component has an expression binding to it's respective data point.
So the incoming data from query on the left, and this component is editable, and the current value on the right, which will update to what's in the text box on the left when the Load button is clicked.
Don't mind the spacing of the buttons, still working out the details.
A bidirectional binding implies that the source and the destination are the same. Meaning that the PLC/DB is both the source and where an immediate update will occur.
I would still not store this data in a tag. I would at most store it in a persistent variable in a project library script. I would have the named query bound to a single point and then any modifications would occur and be stored to be written to the PLC.
If these modifications to the data are fixed or deterministic then I might explore transaction groups as an avenue.
I'd use a custom property to run the query (no polling) and lookup expressions to populate the Incoming KW numeric entries. Bi-directional shouldn't be needed here.
I would avoid putting this in a tag, as anyone with access to the tag could, conceivably, affect the process simultaneously.
The Current KW boxes would be set up for Bi-directional, so that you can get both the current value from the PLC, and write to the value property with the load button and, by extension, the PLC.
Of course, my opinion and $2.00 will get you a coffee from Speedway-- adjusting for inflation.
Yes, that's what I'm thinking. EDIT: It is a recipe.
I might have over complicated things with the memory tag. I guess I was thinking of some intermediary... eh, well I'm still learning about Tags and Vision, tbh.
There is a Speedway near me, but it is an actual race track, probably sell coffee too, but might cost more than $2.
One more thing:
the Current KW may have a NULL, in which case I was told I could use an expression binding, BUT then it would not be bidirectional! So, I could do one of two things: 1) use an intermediary object to store the data to write to the PLC and update each tag using scripting on the button? 2) just update the NULLs to zero's in the DB...
Remember that memory tags are stored in the internal DB, so any mass amounts of data (not that 60 points is all that much) can be detrimental to performance just by being there. This is why I generally avoid dataset memory tags (particularly when they can/will grow over time).
Just wanted to give some insight into where I was coming from.
As a point of reference, for our recipe system I use a named query to pull the data into the project, a scripted transaction to download that recipe to the PLC using system.opc.writeValues(), and a transaction group to pull the data from the PLC to the DB on save.
Modifications are accomplished in another system (I haven't quite got it replaced with Ignition yet other people keep finding things they deem more important for me to do).
