In a project I’m working on the customer wants an indication if the dynamo faceplate (dt/fp) is open. If the faceplate is the active window the dynamo should be surrounded with a white rectangle. If the faceplate is open, but not active the rectangle should be gray. If the faceplate is not open the rectangle is to be hidden.
The white rectangle is implemented calling the frsSetModule “ModuleName”, True in the CFixPicture_Activated() and calling frsSetModule “ModuleName”, False in Close and Deactivate. Then a visibility animation of the rectangle is like this DVSYS.MODULE/IDISP.F_SELECT_PRIVATE. The result is a nice white rectangle on activation of the faceplate
But this does not solve the issue regarding the inactive and open fp/dt. What I’m looking for is a parameter like this: DVSYS.MODULE/IDISP.F_MYFACEPLATE_IS_OPEN and a function to set the parameter. Using this parameter and an edge color animation on the rectangle I will be able to implement the requirement. I do realize this might not be an existing feature if so what is my options.
Question: Is there a function call which returns true if a faceplate is open or not? How can I use this function to support my animation ?
Regards Geir
Geir,
This type of information is not part of the DVSYS.MODULE (controller-based) information; you are looking for application run-time information. The documents collection within the application should return all open documents, including the faceplate. You should be able to interrogate the collection to determine if one of the open documents is your faceplate, but since every member of a module class typically opens the same document, you might have to dig into a child element of the document to see if it is the one you are interested in....that is a lot to ask of an animation object.
You might be able to short-cut this by creating a new parameter for the module class which is written to true by the faceplate opening, and false by the faceplate closing; that is if you want to know whether anybody on any workstation in the whole network has it open. I can see this easily getting out of sync, however, if operate crashes or some other abnormal termination occurs.
In reply to Youssef.El-Bahtimy:
Thanks for quick replay
It was a long shot, but since I'm quite new to iFix and DeltaV I was hoping for just another magic parameter to help me out. To access the open faceplate it is possible to interrogate the “application”.Documents.Items collection and look for the faceplates. But I do not like the idea since faceplates might be opened from various locations and multiple instances of fp/dt (referencing the same module) can be opened at the same time. Keep track of this will be quite challenging. My guess is that I will be chasing bugs for a long time implementing such solution. I have already thrown away the design of adding a module level parameter. My conclusion was the same as you, ‘this solution will easily come out of sync’. Another reason is that I do not like to put iFix related code or parameters into the controller. I will discuss this with the end users, might be the "inactive-open" faceplate rectangle can be dropped.
regards Geir
In reply to geir.falkevik@emerson.com:
Hi,
The control module information would be global, & would not be specific to one HMI, where the faceplate would be open. So, you can rule out the use of control module.
As you correctly mentioned, the continuous check for application.documents.items property is not good, as the faceplates can be opened arbitrarily & this is not specific event triggered always from the dynamo.
This leaves you with the option to use the global variables.
You have to somehow restrict the number of faceplates that can be open at any given time.... let's say 4. Then create 4 string parameters in SI-Global or User. When the faceplate is open, write the tag name to the last unused (empty) parameter. In the close code, write the code to set it to empty again. (See the code to close DT, when FP is closed from PCSD.)
The Dynamo can check for these 4 parameters to compare the tag name & display the highlight.
Reset of operator interface would set the parameters to default blank value.
Since the global file is individual to each HMI station, the solution would be individual per station from point of view of working, but still global from point of view of implementation.
We have used this way of working before, & it works good.... Only now, you will have to think on how to restrict number of faceplates open in the application at any given time, for all type/instances of faceplates... :-)
Best Regards,
Amod Bobade.
Yes, after I posted yesterday, I realized that global variables would actually be a good way to keep track of application specific activity on each workstation in this regard. Thanks for mentioning it.
Yes, I agree the global variables are probably the easiest way to solve this issue. We have already restricted the number of faceplates (4-fp and 4-dt). That gives us the total number of 8 global variables on each module, that's a lot of variables, with 20-30 modules it gives me 180-240 new global variables, is that a problem ? ( Remember I’m new to iFix, VBA and deltaV. My background is .net so globals really scares me). Why someone need to fill the screen with 8 faceplates…...requirements. Thanks a lot for your opinions,
When I meant to restrict the number of faceplates to 4, I did not mean per typical, but I meant alltogether..... Including different faceplates for different classes..... (e.g.: check number of open popups & if a request for 5th is given, close the first one!)
If you create 180-240 parameters, then you would not be able to chck all of them on the dynamos.
Creating extra parameters would work fine, even with higher number. Only the size of the global file would increase, but it would be difficult to keep their track in the dynamo animations.
Regards,
Amod.