Originally, before I duplicated the threshold tabled in User, when I switched themes on an Operator workstation the theme selected would not load. This is what led me to believe the tables needed to be in the User folder. Being that I wasn't completely sure why the threshold tables needed to be duplicated in User, I conducted a test. I deleted the duplicated threshold tables in User from my Pro station to see if it still worked, and it does. For good measure, I also restarted my Pro station and the theme still load properly. So, I retract my statement that the threshold tables need to be duplicated in User.
↧
Forum Post: RE: Can you dynamically change DeltaV Operator Theme Color set?
↧
Forum Post: RE: Can you dynamically change DeltaV Operator Theme Color set?
OK, we have been doing this since v11 and didn't have to do that unless we needed customizations and then we did replicate them. Great that you have it working now, you can now customize the "how" you change the theme any way you like. We use a combox box with the theme selections and a confirmation prompt after the theme selection has changed.
↧
↧
Forum Post: RE: MX Controller Cross Communications
The DeltaV Communication layer is built to facilitate cross controller communication. Given the values above, there is no indication that you need to change anything. I can't comment on whether you've got anything to be concerned about based on exactly how your configuration is designed. What version are you one? An MX controller at 26 % Free time is getting close to full, with recommended minimum Free time at 20%. Having a remote reference is fully supported and expected. The added communication update time must be considered, and usually we done doe closed loop control with the input on one controller and the output on an other, though nothing but loop performance limits this. Here are a few fun facts to know. - How many parameters can be communicated between two DeltaV nodes? There are no limits to the number of parameters you can reference between controllers. But, there are limits to how many values are received and sent per second via unsolicited exception reporting. The Unsolicited Send parameters in diagnostics indicate the number of values being sent per second from that controller to all nodes in the system that have requested data from it. Unsolicited data is sent by exception, which significantly reduces the number of values sent from the number of parameters mapped. Much of the parameters requested by consoles are static, like Engineering Unit Scaling parameters, Alarm limits, Tuning variables, etc. So although the consoles receive way more parameters, the values per second is a fraction of the total number of parameters. In addition to reducing the number of values sent by exception reporting, each controller has a maximum number of values per second it can send (SX/MX = 4000, SQ/MQ/MDPLUS= 2000, as documented in system Limits in BOL) To prevent one client node from monopolizing this pipe, there is also a limit of 750 values per second to each requesting node. Finally, the communication layer prunes parameters that are no longer used. This pruning primarily impacts the data serving Operator Graphics or Control Studio, further optimizing data transfer to the consoles. As you can see in your example, the normal unsolicited is 440 and 750 for all data being exchanged. This is typical. - What happens if you reach the 750 values per second to one node, or the 4000 values per second for the controller? Data up dates will slow such that the average per second does not exceed the limit. So if 1500 values needed to be sent to one node, it would take 2 seconds for all the data. IF the total number of values sent exceeds 4000, then all parameters will be throttled to keep the rate at 4000. Burst load conditions are typically due to Operator graphic navigation, where a user cycles through multiple displays and calls up detail parameter pages. although this activity may add many parameters to the communication layer, exception reporting will still keep the number of values sent relatively low. Other traffic to Controllers, Historian and OPC connections will generally be stable. - How does DeltaV manage peer to peer communication between controllers? There are two mechanisms for sharing data. The most common one is unsolicited communication. The second is the Asynchronous Write mechanism. A module running in one controller requires a value in a different controller. This is configured as an External reference, and defined by the Host Module name. So if MODULEA wants to read parameter called PV in MODULEB, the external reference is defined in MODULEA as //MODULEB/PV.CV. When MODULEA is downloaded it determines the need for a remote connection and sets up what is called a PROXY CLIENT for MODULEB, and adds parameter PV to the list of parameters. The PROXY CLIENT locates the controller hosting MODULEA and that controller sets up the PROXY SERVER for MODULEA, and retrieves the parameter PV. All this happens automatically at runtime. To monitor the health of this remote parameter, the Connection Status (.CST) field provides the destination with the ability to check the communication status of the parameter. (CST=0 means good). The update rate for this parameter is based on the execution speed of MODULEB, the requesting module. The PROXY SERVER checks the MODULEA/PV parameter at this frequency for a change. Of course, the parameter can only change when the MODULEA updates. If there is no change, the parameter is not sent. If it is flagged as changed, the value is sent. So the update rate of remote parameters is the slower of the two modules involved. The second mechanism is the Asynchronous Write mechanism. This mechanism uses another status field called AWST, for Asynchronous Write Status. When a module writes to a parameter located in a different controller, the remote reference is established as an unsolicited read, and the proxy objects are created. So if MODULEB wrote to a parameter in MODULEA, say a parameter called SP, the same proxy Client/Server objects would be used, and Parameter SP would be added. When MODULEB executes and writes to MODULEA/SP, the SP.AWST is set to a pending status, and the value is handed off to the AW task. The write will be executed within 200 ms, and the result of the write will be reported to .AWST. If the write is successful, the .AWST goes to 0. It may fail if the value was out of range, or the block is in the wrong mode or the value does not match. (writing a string to FLOAT or setting a Named Set to a value not defined.). This allows the writing module to execute the write and move on. The AWST provides a mechanism to verify if the value was changed. By having the proxy client report the current value, logic can check if a write is required, if CST is good, and after the write can confirm if the write was successful. Every parameter has the .ST, .CST and .AWST fields. .CST and .AWST will always be 0 when read by a module in the same controller. So if you write logic to check if CST or AWST are good (=0), they will always be good for local parameters. So the same logic will work for local and remote parameters. The .ST field will show BAD if CST is also bad. IF CST is GOOD, you know that .ST reflects the status of the remote parameter. So if you add an action to write to a remote parameter, the controller will first setup the proxy to read that parameter and make it available for the logic to check. It is recommended that writes be used sparingly. They should always be done by exception. It is always recommended to read a value rather than write. Here's the difference. The unsolicited reads are handled in the communication layer and the data is made available to all modules in the destination controller. If a parameter is read by one or more modules in a controller, a single proxy client is created there and all modules can read that value. It is sent once based on the fastest requesting module and the source module execution rates. When you write a parameter, the AW task must confirm the success of the write and must check the state of the parameter for limits, data type and block mode. This action is done at a medium priority and takes CPU time. Too many writes into a controller can take away CPU from medium and low priority control tasks. This can result in module slippage. Writes should be done by exception by checking if the value needs to be changed. SFC Action statements are the mode common use of writes and by their nature are typically one time events. Avoid a module with a wired connection to an External reference to a remote parameter. This creates a write action every scan. Emerson recommends less than 20 writes per second. Note this is from the point of the controller being written two. Writes can come from any controller, so if you have 20 controllers and all of them write 2 parameters per second to a 21st controller, that will be 40 writes per second. So read rather than write, wherever possible. -What is the limit on Unsolicited receives per controller? This is in BOL as well, with SX/MX at 500 and SQ/MQ at 250. This is not a hard limit, like with Sends, where data is throttled. However, exceeding this limit can result in a reduced capacity to send data. There is a limited amount of CPU allocated for unsolicited communication, ensuring CPU is allocated for things like Control. From a controller perspective, the unsolicited receives reflect external references to remote parameters. In most cases those values are process values that change every scan. So although there is no limit on the parameters mapped, respecting the limit of Unsolicited receive values means you likely have no more than 500 or 250 parameters to any single controller. If you map static values like EU range or a SP that is infrequently changed, these parameters will not have changing values and will not count in this limit. Note that once a parameter is mapped between controllers, it is never pruned. Pruning of parameters is only done by consoles, when the value is no longer used by any client application. For controllers, the expectation is that once a parameter is mapped, it will be required and should always be available. The controllers there don't benefit from pruning. - How many proxy server/clients are created? DeltaV uses Uni-Cast Ethernet messaging to send data between nodes. Each Proxy Server serves data to exactly one Proxy Client. So if a console needs a value every second, and the historian needs the same value every 5 seconds, no problem. The Proxy client at the console sets up the 1 second update Proxy Server, while the Historian sets up a 5 second Proxy Server. On a controller, a module will have multiple Proxy Servers, one for every node that is requesting at least one parameter from that module. In each console or controller reading data, there will be a Proxy Client that is managing the unsolicited data received. All applications or control modules running in that node will get parameter data from the same proxy client. In this way, data is managed to each destination with a dedicated Proxy Server, each dealing with one Proxy Client. A module sent to 20 consoles will have 20 Proxy Servers in the controller and one proxy client in each console. - How loaded can the DeltaV network get? As you can see, this mechanism limits the bandwidth usage of each controller, and prevents the system from becoming overloaded, even at 100 MB network speeds. A heavily loaded MX controller reaches about 1 % of the network bandwidth. One would have to try very hard to do everything wrong to create a DeltaV network that would be overloaded, but I know there are some clever people out there so I'm sure someone might be able to. - What happens on a controller switch over? This is where .CST and other configuration options come in to play. in version prior to v11 and v10, a controller switchover would cause existing Proxy Servers to "disappear", and the Proxy Client Connection Status would go to BAD briefly. The recommendation was to evaluate for .CST and to use the feature "ABORT ON READ ERROR" in Calc and CND blocks. This would allow an expression to stop executing when the connection was BAD, and to explicitly define how the control should respond to a BAD connection status. In v12, enhancements were made to better handle the switchover condition, where parameter and status are held on a switchover. A loss of connection due to controller failure or network outage will still result in the loss of connection status. The appropriate response to a loss of connection must still be considered, but the controller switchover is now more robust as a result of these enhancements. So as a rule, - control strategies that are tightly coupled should be in the same controller. - Remote parameter values should be read whenever possible. - Parameter writes should only be done by exception to avoid continuous writes to a controller. - And Status handling should be considered to properly respond to loss of communications.
↧
Forum Post: RE: Speed of Communication between I/O Card and the control module
Knowing "The Speed" is unnecessary. The bus is sized to support 64 io cards. Unless you are doing something really "weird" you will run out of CPU / memory capacity for you configuration long before the IO card bus will even get close to capacity.
↧
Forum Post: Modernization and Optimization Opportunities
Over the past few years, I am starting to hear from our customers and read in the literature that it has become important to not just replace obsolete control system equipment, but to also provide operational improvement. I am very pleased to see this trend, since I really think automation can play a large role in optimizing process unit performance. However, I still think quite a few projects are still justified on replacing obsolete equipment or what is sometimes called a sustaining based justification. One problem with a production sustaining based justification is that a lowest cost to migrate philosophy may be required by management. Many times that means no consideration is given to operational improvements and the control strategy basis is a simple functional replacement of what is already there. Some words of wisdom: The key word here is a “functional” replacement, meaning that the operating objectives and control strategies of the old system are captured, but the configuration code is not copied. Any old code that has been discarded, but not deleted needs to be found and noted to make sure it is not copied into the new system. Also it would be nice if at least a simple session with plant operations, including the operators takes place to identify loops that are run always in manual and other control strategies that just do not work. The opportunity for operational performance optimization is not lost just because the new system was installed without consideration to improvements. Once the new system is installed the major infrastructure cost has been removed. Now it is much easier to justify automation based process improvements based on return on investment means. One thing that can be done during the system migration process is to develop a plan that allows future expansion of additional control strategies and new I/O in the spirit of continuous improvement. I recommend to resist the temptation to just maintain the system as is, but to look for improvement opportunities, develop financial improvement estimates and the cost to implement the improvement. Then an ROI based capital request may be submitted. Finding these improvement opportunities and estimating the potential gains is what will be discussed during the Show Me the Money! Need to Justify Your Automation Project? - Let’s Dive into the Methods workshop at Emerson Exchange this fall in Austin, Texas. Migration and Modernization consultants will also be available during the evening exhibits to discuss your specific plant situation and future plans. See you in Austin
↧
↧
Forum Post: RE: Speed of Communication between I/O Card and the control module
The speed is always an interesting question. The real criteria is the update rate and its suitability for the application. DeltaV does not discuss the actual baudrate of the IO bus. It is a proprietary architecture and is designed to a specific purpose. This information is not available. What is important is that the localbus IO will update every 50 ms or better. DeltaV CHARM IO cards have a configurable update rate of 50ms, 100 ms, 250ms and 500ms. The DeltaV ACN will be 100 MB (Full Duplex) to CHARM IO and controllers. So if the requirement is to have a better than 2 MB link between controller and IO cards, we can do that with CHARM IO and a 100 MB link. For localbus IO, the protocol is proprietary and designed to deliver IO data to the controller at better than 50 ms as a closed system. I would indicate that the 2 MB bus speed does not apply because DeltaV localbus is a proprietary IO solution.
↧
Forum Post: RE: DeltaV Communication Issue
So what causes an ACN switch over? DeltaV uses a redundant network, two completely separate networks. All the data management on these networks is handled by the end devices, so the networks do not make any decision as to which is used or not. Each DeltaV node communicates to other nodes using Unicast messages with the UDP transport protocol. A UDP packet is highly efficient. DeltaV communication layer takes care of confirming data is received and has timeouts built in for retries. By preference, all DeltaV "process data" uses the Primary network. Data is sent to each destination in separate packets. When a packet is sent, a response is expected. If a response is not received within the timeout period, the parameter values are resent (the latest available value). After several retries, if no confirmation is received, the network between that node and the destination is marked bad and the packet is sent on the secondary. THis is called an ACN Switchover. The source node does not know how or why the packet is not confirmed, just that it is not. So, if you disconnect the primary cable from a console, all nodes sending data to that console will experience an ACN Switchover to the Secondary. Diagnostic messages are still attempted to the console on the primary so that when it returns, an ACN switchover to the Primary will occur. If an intermediary switch is turned off, all traffic through the switch will stop and any affected nodes will report an ACN switchover between it and its destinations. As you can see, one event can generate a significant number of ACN Switchovers. If this point of failure is intermittent, say a bad cable, improperly seated connector, bad Port on a switch, bad NIC in a computer, and traffic is intermittently getting through, the ACN messages can toggle. If it is a hard failure, you will get the switchover to the secondary and it will stay there till the problem is addressed. To isolate the problem, you can look to see if there is a common device involved. One device has lost connection on the Primary to all others, and all others have lost connection to one device. This will point to that device's primary port, network cable or Smartswitch Port. If the Switch shows issues on that port, it could be the switch, and changing ports can confirm this. If there are multiple devices that loose connection to all devices, one has to look for a common point in the network that sees all affected traffic. Some say that a normal healthy DeltaV network will still see some ACN switchover events and that a few events per day is of no concern. But every ACN switch over is the result of a failure to receive confirmation of receipt of a DeltaV packet, three successive times resulting in a time out and switchover. Early on when DeltaV used hubs and common collision domains, this was more likely as a 10 MB half duplex network became saturated. Today, all Smart Switches provide a separate full duplex connect to each controller and IO card, virtually eliminating collisions. 100 MB bandwidth at full duplex eliminates network pinch points. What is left is either corrupted data packets due to EMI noise, damaged cables, bad connections, bad network ports, high db loss on fiber or bad NIC cards at the devices, or a software issue that prevents a device from responding. Other normal causes of ACN messages are activities such as rebooting a console, or cycling power on a switch. If these events occur, then the ACN messages are expected and can be ignored. The system will stabilize once the nodes are restored. In this case, sorting the Event Chronicle messages by Source device, you are able to determine if there is one common device or a common network point. If a cable is disconnected, and ACN messages stop because of the hard fault, it is likely that cable, and restoring connection with a good cable should result in one last ACN flurry as things switch back to Primary. Using the Smart Switch Command console, confirm that the switches involved are reporting any error counts, such as bad packets or other. Remember, if the packet is corrupt, it cannot be delivered and a confirmation is impossible. If the Confirmation is corrupt, it cannot get back to the source. If a console has a cyber security threat that is disrupting network traffic, this too could result in lost confirmation packets. The latest Smart Switch firmware limits broadcast and multicast storms, but the affected Computer may still have issues. Hope this is useful information.
↧
Forum Post: User Manager & DeltaV Operate Configure
Hi friends, i have a serious problem. is it possible to allocate an special picture (on DeltaV operate configure) for an special user (as operator or other)? for example, it means that operator could not see some pages on DeltaV Operate (Run).
↧
Forum Post: RE: User Manager & DeltaV Operate Configure
It depends on how the operator calls (open) the graphics. If you use buttons to call a graphic, you can put code behind the button to check which user is logged on. You can also use visibility on the button to prevent it displaying if the correct user isn't logged on. Unfortunately, if they use the regular open graphic popup from the toolbar, this will list all the graphics in the pic folder, which means they could bypass your button selection logic. It might be easier to use visibility on the objects you don't want less privileged users to see, the graphics still opens regardless of user, but the sensitive data is not visible, this prevents any chance of bypassing your security mechanism.
↧
↧
Forum Post: RE: User Manager & DeltaV Operate Configure
Dear Adrian, thanks for your answer. i don't want to use software key by code. there isn't any way for this by User Manager or other program?
↧
Forum Post: RE: User Manager & DeltaV Operate Configure
Unfortunately user security is not that granular, while you can restrict user actions and access to plant areas, it is not possible to restrict opening of individual graphics, certainly not with the standard tools. Why not use visibility on the graphic? The objects will only be visible if the correct user is logged on, that kind of meets your requirements. Just have a text object that display a warning the graphic is only for authorized users, this message would disappear if the correct user is logged in. I can't think of another way without some major VBA coding.
↧
Forum Post: RE: User Manager & DeltaV Operate Configure
i must do what you say. Thank you Adrian for your help :)
↧
Forum Post: RE: MX Controller Cross Communications
Andre Dicaire, thanks a lot for very helpful and detailed description. I haven´t read Books Online for this issue recently, but recall the content wasn´t written as well as you did. I recommend the Books Online should be updated with many of the valuable information given by you. Reynir Kristbjörnsson
↧
↧
Forum Post: Configuration of ALM_FLOOD_SUP module in DeltaV
Hi, I am trying to configure the advanced alarming module ALM_FLOOD_SUP for alarm masking following a compressor trip and have a few questions - 1. Once the unmasking logic is triggered following AUTO_RESET and the chosen TIMEOUT_OPT is None Suppressed, is it possible to delay the actual unmasking of the alarm to the operator by a specified period of time configured on an alarm by alarm basis (e.g. using the HI_AUTO_UNMASK/TIME_DURATION parameter for a particular High alarm) ? Or does the unmasking to the operator happen instantly after AUTO_RESET? 2. Can the SUP_TIMEOUT parameter be configured to start counting down once the AUTO_RESET condition block is satisfied before unmasking all alarms? The aim is to have this timer to be longer than the individually configured unmasking timers above. 3. What is the logic that would be needed in the DYN_PRIORITY action block if the alarm priority state required is Mask? Any other configuration tips would be appreciated, thank you.
↧
Blog Post: 구매 담당자가 전하는 - 무한 경쟁에서 벗어나기 위한 4가지 핵심 요소
구매 담당자가 전하는 - 무한 경쟁에서 벗어나기 위한 4가지 핵심 요소 Samer Haddad 오늘날의 비즈니스에서 구매(Procurement) 및 공급망(Supply chain)은 모든 시장과 각 세계 및 국제 조직 내에서 빠뜨릴 수 없는 분야가 되었습니다. 그러나 구매의 중요성은 여전히 증가하고 있으며 시장과 비즈니스 수요에 따라 동적으로 빠르게 진화하고 있습니다. 오늘날 필요하고 또 예상되는 기술들은 공급망과 자금 이동에 관한 피상적인 지식만으로 상위 1-2 단계의 공급자만을 다루는 전통적인 구매와는 거리가 멉니다. 과거에 비해 기업과 시장 모두가 기대하는 최상의 성과를 이루기 위해 조직 내에서 구매에 많은 노력이 필요하다는 사실은 모두가.......
↧
Forum Post: Monitoring of Manhole Covers & Confined Spaces can save lives
During a previous article on how WirelessHART can improve your overall Plant Safety I would like to highlight a solution around manholes and confined spaces. Every year alone, in the UK, 15 people are killed by entering confined spaces or entering manholes they shouldn’t enter. The article shows a WirelessHART solution that can deployed in a very simple way with high effectiveness www.linkedin.com/.../monitoring-manhole-covers-confined-spaces-can-save-lives-vandeput
↧
Comment on I am a woman in STEM. But, it hasn’t always been easy.
Thanks, Tonya. I am sorry you had to face similar experiences, that's never fun. On the other hand, I think we can be happy with what we achieved, we had to work hard for it and we deserve it.....
↧
↧
Forum Post: RE: Configuration of ALM_FLOOD_SUP module in DeltaV
In the DeltaV V13 edition of the ALM_FLOOD_SUP module, the suppression bit that is used is OOS (Out of Service) where in prior DeltaV versions the suppression bit used is OPSUP (Operator Shelving). OPSUP is automatically cleared by the configurable timers available for each alarm in the alarm properties dialog, independent of the ALM_FLOOD_SUP module. OOS has no unsuppression timer so it must be manually or programmatically cleared. In DeltaV V13, OOS and OPSUP are both available, plus there is another new bit SUPRSN to set a reason for suppression using a name set. There are actually two timers at work in the module. The first one is the TIME_DURATION parameter on the function block SUP_TIMEOUT. When the module is armed and the trigger conditions are present the alarms are suppressed and this timer starts counting down. When either the conditions necessary to trigger the module are no longer satisfied or this timer reaches the end, the module will take one of three actions per the TIMEOUT_OPT. I see that you chose the action None Suppressed, and thus all alarms would be unsuppressed (OPSUP cleared or OOS cleared per your system version). The second timer is specified by the TIME_DURATION parameter of the function block AUTO_RESET. The block is intended to automate the rearming of the ALM_FLOOD_SUP module. The default logic in the block is a simple check that the conditions necessary to trigger the module are no longer present. The idea here is to prevent an immediate retriggering of the module. Getting to your questions. 1) The TIME_OUT option (action taken) is related to the SUP_TIMEOUT/TIME_DURATION, not to AUTO_RESET. If the module is using the bit OPSUP, then individual alarms can each have a different maximum suppression duration. When the AUTO_RESET logic is satisfied for the AUTO_RESET/TIME_DURATION every alarm will be unsuppressed as part of rearming the module. 2) The design intent for the two blocks SUP_TIMEOUT and AUTO_RESET are different and both have their own timer. I’d suggest experimenting with the two timers and perhaps also with the TIMEOUT_OPT choices to attain the desired behavior. Given you've selected the option 'None suppressed' all alarms will be unsuppressed when the first timer times out so it's a moot point how long it will be after that until the module is re-armed by the AUTO_RESET block. 3) The function block DYN_PRIORITY default logic can reprioritize alarms, when the module is triggered and when it is rearmed. The function block uses the PRIORITIES parameter, which is an array where each row corresponds to one of the alarms and each column corresponds to one of the index values of the PRIORITY_STATE named set. The default name set is Alarm_Group_Mode where 0 is Disabled, 1 is Normal and 2 is Tripped. The DYN_PRIORITY logic will set an alarms priority according to the array. If the cell in the array is 0, the alarm is left at its current priority. If the cell contains a non-zero value the alarm is set to that priority; e.g. 7 = Advisory. By default the ALM_FLOOD_SUP module does not change any alarm priorities when the module is tripped or rearmed (normal) because the array contains all zeros by default. There is a whitepaper available that provides information on the technical workings of this module, and also of the First-out module FO_ALM_SUP. See the website www2.emersonprocess.com/.../index.aspx The downloadable zip file at the bottom of this webpage includes the whitepaper.
↧
Forum Post: RE: User Manager & DeltaV Operate Configure
What about removing the OPEN PICTURE Button on the ToolBar, or hiding it based on logged on User. And using a controlled Picture list or navigation scheme. Although the pictures are on every workstations, and there is no User security to manage them, one needs to have access to the picture via the interface. The Picture Directory popup can be customized to list only the pictures an operator can select. This list can have custom dynamics added to manage access to pictures based on current user. This is available as standard. For many customers, we implement a custom navigation scheme, where we control which displays a user has access to, and the first thing done is to remove the generic Open Picture button from the tool bar. And as Adrian suggests, additional visibility options are added in graphics where certain information is reserved.
↧
Forum Post: RE: MX Controller Cross Communications
BOL has some very good information, but it is not written to solve problems. most of this information is in BOL. Here is a bit more detail on .CST and .AWST values, from a table in BOL under "Dynamic Reference Parameter" CST: -3 means 'external reference not resolved' -2 means 'parameter not configured' -1 means 'module not configured' 0 means 'good' 1 means 'not communicating' AWST: -4 means 'write rejected' -3 means 'external reference not resolved' -2 means 'parameter not configured' -1 means 'module not configured' 0 means 'success' 1 means 'not communicating' 2 means 'write pending' AWST = 4 results from an invalid parameter state or out of range. It does not tell you why it failed, but a value of 4 tells you the write got all the way to the parameter before it was rejected, so it's the value and current state of the destination module at issue.
↧