A search button on perspective

I need to develop a mobile app for a pilot plant.

While googling ideas about the UI, quite often there’s search button on the UI page.

Is it possible to create a similar button on the perspective with the following functions:

  1. click on the button, there will be a little entry window displayed
  2. while entering tag name in the entry box, there will be a list of valves with same tag name displaying at its dropdown list
  3. operator can then choose the correct valve tag name
  4. after click is done, the main section of that page will display the valve status, like a faceplate.

Is there any button on perspective that has similar functions already? Or I have to script all of the functions, I can see it’s mainly query in database table of the device name list.Once name is chosen, the main container will display the faceplate of the valve.

Appreciate if anyone can share your thoughts about whether you have done similar configuration or how it should be done.


All custom code, none of this is standard functionality (I don’t even know how this would be made into standard functionality that would suit every environment).
I would either be storing this config (the window and/or view each device is displayed on) within the (1) UDT instance parameters (probably not), or I would be storing it inside a (2) dataset tag or (3) SQL database table. Just remember, SQL databases aren’t accessible from Ignition Edge, so using this for such an ingrained part of functionality would be my last resort.

You could also combine (1) and (2) by having a script that would traverse all UDT instance tags and pull out this config and store it into a dataset tag, then use the dataset tag in your functionality. It really depends on where you want your source to be located.

Thanks for the advice.

I am still at early stage of developing a mobile HMI.
I am thinking having a local edge device to collect the data from PLC and send to the cloud via MQTT, then having the cloud gateway to handle all other functions.

the dropdown has search functionality, you would just have to populate it with the tags.

But to make it appear and change view will be custom code

each dropdown has a value and label so you could dynamically fill that with the appropriate tagnames and for values maybe the path to the view. or an id/name

I would make a dynamic view with as parameter the valve id(or name). And on the dropdown when an action performed (or value change) go to the page with the selected id as param


Thanks for the comments.

I would go the same route as @victordcq . The Dropdown should be in either a docked view or a sort of primary View, and the value of the Dropdown should drive a param of an Embedded View, where the View being embedded expects a tag path param.

  • This would allow you to create one View which is a template for any valve, and the values for the valve are driven by a supplied tag, instead of making a View for each valve.
  • Your Embedded View can then use this single “template” valve View and supply a tag path param.
  • If you bind this param to the value of the Dropdown, then you’re all set.
  • All you need to do is bind the options of the Dropdown to a label/value pair.

I would certainly use a dropdown menu or more likely a list with a filter in order to search for the device equip ID from a populated list of device equips. The part that involves the work however is creating the lookup list that links the equip ID / path to device to the screen that it’s used on which is basically what I replied to in my first post.

In terms of displaying the device faceplate, I use a memory dataset tag that stores a lookup of UDT definition path to faceplate path (as I have a more generic set of faceplates that can be used by a number of different UDT types). To display the device faceplate, you would simply read the UDT definition path from the selection equip id in the list, then open the appropriate popup from looking it up in the dataset tag.

To display the P&ID page that the device is used on would require something similar to the UDT-to-Faceplate dataset, except it would need to include all UDT instances and the page path to them.

Although now that I read the OP again, the last part isn’t mentioned… I think it’s bed time