Forgive me if this is a redundant post. I have been in search of a resolution or even similar questions in regard to what I am looking to accomplish but so far have found nothing.
All I'm really trying to do is design a sleek interface for our operators to select recipes from. I have something built now that is functional, but it's a bit crude and elementary.
The way it works now is the operator can change the selected recipe number (1-100) and it will display the part number, recipe name, and fixture name for that selected recipe. Through indirect tag addressing, I've tied the selected recipe number to the index of the recipe list.
The problem is how would anyone know what recipe they need until it's selected on screen and they can see the contents?
Out of all the component options, I was hoping the dropdown list component would be what I needed. That way the operator can see the part number, and name of the recipe before making their selection. The reason I've not been able to get that to work is because I can't just drop in static names and numbers in each of the rows of the drop down list. All of those parameters of the recipes can be changed.
What would you do in this situation? Is what I have set up currently my best option?
You don't need to make it static. I would make some kind of script that looks up your recipe tags and populates a dataset tag with the dropdown options. I don't know how often you expect to update the recipes but you can set up the script to execute at least that often, either once a day or on startup or something along those lines.
The recipe list is a multi-layer UDT called "Master_Recipe_List" that is stored in the PLC and imported into my Ignition Designer project.
When editing parameters, the user just selected which recipe they'd like to manipulate and that selected recipe number is the index in the master recipe list.
Thanks Felipe. I was worried that scripting is my only option... In regard to the second half of your comment. The user would be able to go into the recipe parameters and update/change them at any point in the day. They may also want to turn around and use them instantaneously. I do have a toggle button that needs pressed before any parameter changes can take place. I suppose I could just have the script run anytime that button is toggled from on to off.
This looks like vision but I don't want to make any assumptions.
What's stopping you from generating the dropdown list at runtime, then the Recipe Number becomes the value for the dropdown. Just don't populate the fields until a recipe has been selected. You can still do everything pretty much the same wat with indirect bindings, just you'll be using the selectedValue of the dropdown.
Thanks for feedback Rose. Perhaps I'm getting the names of the subdivisions of the software confused. The images are SnagIt screenshots of Designer but the project is interfaced with via Vision Client Launcher.
If I'm understanding your recommendation correctly, I thought about binding the selectedValue, selectedStringValue, and SelectedLabel through indirect addressing but that leaves me in the same boat. The user won't see the name and part number of the recipe until it has already been selected. I'd like to have a list that the user can choose from. That way instead of picking a recipe based on a number, they can choose the recipe they want based on the name or part number.
There are two visualisation packages, Vision and Perspective. They use different technology so we need to be clear which you're using - and it's Vision in this case. I've added the "vision" tag to your title.
What I am suggesting is that you generate a dropdown at runtime, when the window is first opened/activated.
The dropdown would have an initial value that was something like Select Recipe.... All other objects would be disabled and/or have no value. When the operator selects a recipe (by name) then the selected value will change allowing the other values to be shown. So instead of selecting a number, they are selecting the Recipe name.
Regarding the recipe selection, what you should be aiming for is,
Use a dropdown for recipe selection. The dropdown has a "data" property which takes a two-column dataset, "Label" and "Value".
You will want a script to automatically run through your recipes, and stuff (I think) your Part Name tag value into the Label column and the Master_Recipe-List_x folder name into the Value column.
When the user selects the plain English name the dropdown will return the Master_Recipe_List_x value and you use that to transfer that recipe by script to your PLC.
Thank you all for the feedback. I'm going to play around with some of the suggestions you've provided to see if I can get what you are recommending to work.
So, I ended up opening the binding options for the "Data" parameter of the drop down list component. Under the Cell Update section, I used tag binding for each row of the table and pointed each row to the appropriate recipe.
I also bound the "selectedValue" of the drop down to the PLC tag that recognizes when the user is selecting a new recipe.
Now, I can use the drop down to select the appropriate recipe based on the "name" or enter in a number in the numeric input field next to it. Either way, both update correctly.
While I'm happy it works, it was a bit time consuming entering (x100) rows in the cell binding section and changing everything manually. I can also see this being time consuming to change if I'd like to reuse this screen for a future project. Is there a way to shortcut or improve this? I'll admit my knowledge of scripting is limited but I'll follow along as best I can if that is the solution.
In this instance I believe that scripting is the answer to having this be dynamic in that if a recipe is added to the UDT it will automatically update in the dropdown.
Give it a shot and post back, we're happy to point out how you can improve your script, and as a bonus you improve your knowledge of scripting while you're at it.
Start with system.tag.browse() and system.tag.readBlocking()
