Mark VIE DCS Configuration

E

Thread Starter

ENGORABY

Hello every one,

As we Know MARk VIE DCS use cimedite to design and configure HMIs, and there are many types of objects like motor, pumps and valves. These objects when we double click on it in run-time it will open associated face plate. My question how can we map any block signals in toolbox to face plate. How permit to start, permit to stop, override trip, manual reject and froce in faceplate mapped to toolbox? if you have GE document please, give it to me.

<b>Moderator's Note:</b> I think froce is force.
 
All of the mapping between the HMI objects and controller logic is by variable name; usually the variable name is a combination of a device's tag name and sub variables. Usually there is a single block in the controller representing the device that has a corresponding tag name and variables. You can right click on the faceplate in Cimplicity and "go to logic" to open ToolboxST to the associated block.
 
Thank you very much for your help. Yes of course if i do right click on face plate from cimplicity, and I choose (Go to Definition in logic ) it will open associated block in the toolbox. but if I involved to make new logic for let us say (Pump) for example, so I will create the logic for this pump in toolbox and and I can imagine how to do it. but the problem when I will design the necessary HMI screen and choose pump object how will I determine which face plate? and how will I map Object signals to my toolbox logic?
 
There really isn't anything special to do; so long as the variable names on your Cimplicity object match the globals defined by logic it will just work.

The blocks in the Standard and DCS block libraries that have HMI faceplates follow a naming convention. Pins that are used by an HMI screen are marked as Global, on the $Default EGD Page, and have a Global Name Prefix of "Block", which causes the global name for each pin to be "Blockname.Pinname". The block name and one output pin are always named {Device} so that the Device attribute on the block drives the block name and global pin names. Because the the {Device} pin is a global, it enforces the Device tag's uniqueness within the device. The final global name visible in Cimplicity also prepends the Controller's name, guaranteeing system wide uniqueness.

I'd look at an existing block as an example.

One other thing, to enable drag-drop from ToolboxST to Cimplicity, the Attributes under the block include HMILinkSource and HMILinkedObject, which define the screen object template file and object within the file (there is also an XML file that can define these mappings, but I can't remember where it is).
 
What version of Toolbox do you have? if you have a version after 4.0, you can use "logic builder" logic blocks to write some code, and you can tie this into the Force On, Force Off, Trip overide pins. This will display automatically on the cimplicity screens.

Max
 
I should probably add the Cimplicity side of this; open your screen and the smart object cim file (by convention, these are .cim files that start with tp_) and drag the object type you want onto your screen. A popup window will let you choose options, including the Device and "Ctrlr", which correspond to the Device and Controller logic as my previous post described. You can change these properties later by double clicking on your object. Objects that have faceplates pass this information to the faceplate popup automatically.
 
B
The points need to be in the EGD list in order for it to be read by Cimplicity (or by any application outside of the controller.) If you are making new points, then you must also add them to the EGD list. If you are using existing points, make sure they are in the EGD.
 
ENGORABY,

did your question get answered? if you need more help, shoot me your email address and I can get you a more elaborate process to get it working.

Max
 
Top