Quantcast
Channel:
Viewing all 15475 articles
Browse latest View live

Forum Post: RE: Delta v Distributed control systems

$
0
0
Have a look here: www2.emersonprocess.com/.../PDS_S-series_Traditional_IO.pdf

Forum Post: Module Error 32 / Attribute Override Error

$
0
0
We are having two issues when downloading a control module. All modules mentioned below are assigned to the same simplex SX controller, so it's not an inter-controller or redundancy issue. DeltaV version is v12.3.1. All our CMs have a reference to a Boolean (without status) parameter to the Unit Support Module, like this: In addition, the USM itself has a reference to bring #THISUNIT# as a parameter in the module (this is just an Input Parameter which is an ext.ref). Now, this is what happens when we download: First question is: what is Attribute Override Error? What is the problem with the reference? The second, more important question is: why do our control modules have MODBAD when we download the USM? What it Module Error 32? It only lasts one scan and it is not happening consistently on all CMs, even though they all reference USM/UNIT_MAINT exactly the same way. Since we noticed this, we could also reproduce it on other modules having external references. When the referenced module is downloaded, sometimes we get Module Error 32, sometimes Module Error 64. Additionally, it also impacts phases. E.g this condition in the Hold Monitor of a phase became TRUE momentarily after downloading the USM, sending the phase to hold: The reason was some kind of read error, because setting the ERROR_OPT of the block to False solved the issue, it does not trigger. (needless to say, the HELD parameter this condition is monitoring was false all along) Cold Restart on the controllers was Disabled and Enabled (maximum time) and Disabled again in the last couple of weeks. Could it be related? We'll open a call with GSC, just wanted to check if someone can help us faster.

Forum Post: type miss match error

$
0
0
Hello i replace project toolbar in deltav ver11.3.1 with default deltav toolbar but when i click on tag search button, the type miss match error (error 14) appears and after accept error the button works Best regards Mohsenv

Forum Post: RE: type miss match error

$
0
0
Check the VB _OnClick event script behind the two buttons and see if they differ. You can also try to compile the code behind the problematic toolbar and see if the compiler flags anything. There are many unanswered questions. When you say "project toolbar" are you referring to a customized toolbar that was created as part of your specific project? If so, you can compare the VB code behind the two buttons and ask whoever developed your project toolbar about the discrepancies.

Forum Post: Creating Area Sets in DeltaV Analyze

$
0
0
An aspect of DeltaV Analyze which may not be well known is the ability to create Area Sets. Area sets allow reports to be created based on specific plant areas. You can group your plant areas and produce reports of alarm frequency by Area Set. An Area Set can correspond to an operator station's control areas and can indicate how many alarms are experienced by one operator position. If one operator station is responsible for Area A and B and another operator station is responsible for Area B, C, and D, you can create Area Sets for both operators and schedule reports based on the area set. To create an Area Set, follow these steps in DeltaV Analyze: 1. From the Admin functions, click Area Sets 2. Click the New Area Set button 3. Complete the Area Set name field 4. Add a description to help identify the Area Set 5. Select the Data source 6. From the available Members list, select the listed areas (you can select multiple areas) 7. Click the << button to move the selected areas to the Current Members list 8. When done, click Submit Changes 9. Continue creating new Area Sets as needed You can modify the Area Set by clicking the name of the set in the Area Sets list To delete an Area Set, click the box next to the name in the Area Sets list and click the delete button.

Forum Post: RE: type miss match error

Forum Post: Configured values for DCC block not getting passed to controller after download Version 13.3.1

$
0
0
We are experiencing an issue with the I_DELAY_ON parameters in the new DCC block in Version 13 where the values configured in the database are not being passed to the controller. No matter what we change the value to in the database, when downloaded the online value remains at 0. Additionally, we can change the value in online mode and after being downloaded again, the parameters will hold on to the value they were changed to in online mode even while choosing not to upload the parameter values. I checked the download script in the powerup directory to verify that it contains the correct values configured in the database and it does. But it still is not getting passed to the controller. Note this is on a development system and we are using a SVIRTUAL controller. Has anyone else experienced this problem?

Forum Post: RE: Configured values for DCC block not getting passed to controller after download Version 13.3.1

$
0
0
Try checking the parameter download behaviour for your module. One of the settings means it never takes the configured value. Cant recall which it is without looking but this behaviour is what you get The smart switch modules have the parameter download behaviour set that way.

Forum Post: RE: Configured values for DCC block not getting passed to controller after download Version 13.3.1

$
0
0
Here you are Possibly those DCC parameters are classified as critical block parameter Below extract from DeltaV BOL:- "Parameter download behavior Select the download behavior. The choices are: Preserve critical block values - The controller copies critical function block values from the executing module to the new module during a download. This selection typically minimizes disruption to the process. Preserve user-defined and critical block values - The controller copies user-defined parameter values from the executing module to the new module during a download in addition to copying the critical function block values. Make sure to use this value if any parameters reference OPC Mirror data. If this is not selected the parameter values will change to their configured default after download rather than retaining the value from OPC mirror. Use configured values - The controller does not copy any parameter values from the executing module but uses the values from the configuration database. "

Forum Post: RE: Configured values for DCC block not getting passed to controller after download Version 13.3.1

$
0
0
I was about to type exactly the same when I saw the post pop up.... The setting that will never use configured values is "Preserve user-defined and critical block values", it essentially just downloads new parameters (or probably changes of type - FP,Int, Bool, etc) and logic. For more info on this, Books Online -> Configuration -> General Configuration -> Downloading data

Forum Post: RE: Configured values for DCC block not getting passed to controller after download Version 13.3.1

$
0
0
Thank you both for the response. I checked in BOL and the Delay on and Delay off parameters of the DCC block are critical block parameters. I changed the download behavior to "use configured values" and it worked.

Forum Post: RE: Configured values for DCC block not getting passed to controller after download Version 13.3.1

$
0
0
Although I am confused as to why the set points for the on and off delays are considered critical block parameters. It makes sense for the timers to be (I_timer1, etc.) but I am not sure why the time set points are.

Blog Post: Learn From our Flow Experts at the International School of Hydrocarbon Measurement

$
0
0
Improve your measurement practices by tapping into our deep application expertise at the International School of Hydrocarbon Measurement (ISHM) in Oklahoma City, May 16-18, 2017. Join our flow experts for hands-on classes and presentation sessions and learn how you can improve the accuracy, efficiency, and reliability of your measurement operations. Take part in in-exhibit product demos by visiting our booth C 9,10,11 & D 9,10 . Let our experts show you how our wide range of flow measurement devices are designed to take complexity out of your flow measurement and address your toughest measurement challenges. We also look forward to having you join us for a hospitality event  and a magical night at Bricktown Brewery on May 17, 6-9 pm. Engineer-turned-Magician Michael Carducci will be performing his amazing mind-blowing sleight of hand tricks and more. We’ll also have plenty of food and ice cold beer to help you unwind and take a well-deserved break after a busy day of classes. All ISHM students are welcome. Please RSVP here if you plan to attend. Lecture Classes Presented by Emerson Flow Subject Matter Experts 1200.1 Mass Meters for Gas Measurement Presented by Marc Buttler 1270.1 Orifice Meters – Operation and Maintenance Presented by Steve Ifft 2010.1 Application of Densitometers to Liquid Measurement Presented by Dean Minehart 2090.1 Design, Operation, and Maintenance of LACT Units Presented by Dean Minehart 2490.1 Advanced Diagnostic Measurements and Verification with Coriolis Flow Meters Presented by Marc Buttler 4140.1 Theory and Application of Pulse Interpolation to Prover Systems Presented by Dave Seiler 6120.1 Controlling Surges in Liquid Pipelines Presented by Dave Seiler Hands-on Classes Led by Emerson Flow Subject Matter Experts 911.1 Daniel Orifice Fitting & Tube Inspection Presented by James Boettcher, Steve Ifft, Rick Bell, & Ana Vigil 912.1 Daniel Senior Orifice Fitting Operation & Maintenance Presented by Steve Ifft, Rick Bell, & Ana Vigil 915.3 Daniel Ultrasonic Meters (attendees are encouraged to bring their laptops to this class) Presented by David Brown 917.1 Micro Motion Gas Coriolis Meters Presented by Cole Bowen 921.1 Daniel Liquid Turbine Meters Presented by Dave Seiler 923.1 Micro Motion Liquid Coriolis Meters Presented by Dan Elze The post Learn From our Flow Experts at the International School of Hydrocarbon Measurement appeared first on Emerson Flow Solutions .

Blog Post: Siemens SIPART PS2 FF Rev 3 DeltaV and AMS Interoperability Test

$
0
0
In Emerson’s continuing commitment to open and interoperable standards, the Siemens SIPART PS2 FF Rev 3 has passed the rigorous and comprehensive testing of the DeltaV and AMS Stress Test labs. Using the Device Installation Kits for Emerson Products website at  http://www2.emersonprocess.com/en-US/documentation/deviceinstallkits/Pages/deviceinstallkitsearch.aspx , these fieldbus device files are now available for use.

Blog Post: Emerson’s Flame and Gas Detector Technologies Improve Safety at North Sea Gas Platform

$
0
0
By Chris Duncan, Business Manager, Emerson Automation Solutions Detecting flammable gas that has the potential to threaten people and property in areas where gas clouds easily disperse is a problem in many applications. This recent case history is a classic example. A UKCS (United Kingdom Continental Shelf) operator was issued an improvement notice from the Health and Safety Executive after a large volume gas leak went undetected on one of their North Sea platforms. The release had not been picked up by the platform’s existing flammable gas detection system because the gas had been dispersing as soon as it escaped. The company contacted Emerson for help. The solution was to provide the Incus , an ultrasonic gas leak detector that, while working in conjunction with the existing gas detection system, added another line of defense and provided an early warning when gas releases occurred. Most importantly, it increased the safety of platform personnel. Ultrasonic gas leak detection uses acoustic sensors to identify fluctuations in noise that are imperceptible to human hearing within a process environment. The sensor and electronics are able to detect these ultrasound frequencies (25 to 100KHz), while excluding audible frequencies (0 to 25KHz). Unlike traditional gas detectors that measure the accumulated gas, ultrasonic gas detectors “hear” the leak, triggering an early warning system. The sensors respond to sound generated by escaping gas at ultrasonic frequencies. Leak rate is mainly dependent on the size of the leak and the gas pressure. In most facilities, the majority of process noise is in the audible range, while limited ultrasonic noise is generated in normal operation. Highly pressurized gas releases produce ultrasound (25-100 kHz) which the sensors are able to pick up despite the presence of audible noise. Ultrasonic (acoustic) gas leak detection technology has several advantages over conventional gas sensor technologies: it does not have to wait until a gas concentration has accumulated to potentially dangerous concentrations; it does not require a gas cloud to eventually make physical contact with a sensor; and the response is instantaneous for all gas types. The Incus is ideally suited for monitoring outdoor applications such as on an oil platform. The Incus has been engineered to withstand even the most extreme conditions. Performance is not affected by inclement weather, wind direction, leak direction or any potential gas dilution, with an instantaneous response to all gas types. It is an excellent addition to many safety systems adding another layer of detection to existing technologies. The Health and Safety Executive subsequently inspected the platform and approved the solution provided, resulting in a very happy customer! Do you have an application that might require the addition of ultrasonic detection? It might be worth a discussion. Contact us HERE today. The post Emerson’s Flame and Gas Detector Technologies Improve Safety at North Sea Gas Platform appeared first on Analytic Expert .

Forum Post: Reciprocating Compressor vs Centrifugal Compressor

$
0
0
This is one of the Q&A topics I'm collecting about compressors and antisurge control. Will post them here from time to time to discuss with the community. What's the difference between centrifugal and reciprocating compressor from the control system standpoint? From time to time I receive requests for an advice or even a detailed design for reciprocating compressor automatics. I guess it's a good idea to describe here the difference between compressors and compressors. The question can be stated a bit broader: what's the difference between dynamic and positive displacement compressors?. Dynamic compressors are centrifugal and axial. They operate by transferring momentum to the gas via a high-speed rotor (1). It's a device that has an open internal path. If you fix the shaft, you can blow it through from one side to another in both directions, no matter if it's axial or centrifugal. It compresses the gas by increasing its speed and then converting it to pressure in the diffuser. Positive displacement compressors are reciprocating, screw, vane and scroll types. They collect a fixed volume of gas within a chamber and compress it by reducing the chamber volume (1). A displacement compressor has some sort of a mechanical part inside that would block the internal passage and would not allow you to blow it through. That mechanical part can be a screw or a piston or any bent piece of metal of various shapes. It is something that's used for reducing the gas volume, thus increasing its pressure. The foregoing basically means that a dynamic compressor can surge and a positive displacement one can't. A surge is a consequence of compressor stall. You can very briefly read about it here or more detailed in this Wikipedia article. When a stall occurs in the dynamic compressor, it suddenly has no force to resist the pressure raise it was creating all the way before. So, now the gas starts moving in a direction determined by the natural forces - from the area of higher pressure to the area of lower pressure, in this case, from discharge to suction. A positive displacement compressor is not prone to stall and it has an internal obstacle on a way of a reversed gas flow so it can't surge. What I always have to answer is that a reciprocating compressor doesn't need any special treatment. Just consider it being a pump. You need to start and stop it properly, design safety valves and vibration measurements in the right places and make sure it's constantly sealed and lubricated. A volumetric flow rate of the gas in a positive displacement compressor is just a volume of its chamber multiplied by the number of the piston movements per minute (second, hour, whatever) or vane/screw rotation frequency. If you want to change the throughput, somehow you need to change the crosshead or shaft rotation frequency. That's about all you'd need to consider about positive displacement compressor automation. Mechanically reciprocating compressor is a more complex device, but from the control automation standpoint it's way simpler than centrifugal compressor. (1) a definition by MARKS' Standard Handbook for Mechanical Engineers

Forum Post: Compressor Stall vs Pump Cavitation

$
0
0
This is one of the Q&A topics I'm collecting about compressors and antisurge control. Compressor stall, airplane stall and pump cavitation: are these all the same phenomena? Well, compressor stall is indeed absolutely the same effect as an airplane stall. Compressor blade and airplane wing utilize the same mechanism of energy transfer between gas and the wing (or blade), just in opposite directions. In case of a compressor, the mechanical force of the shaft rotation is transferred to the gas in a form of kinetic energy. Basically, the blade speeds up the gas. For an airplane, when the wing is moving through the air, it converts the kinetic energy of the gas (air) stream to the mechanical energy of the lift force. In order to maintain this energy transfer, the gas should move along the blade with relatively high velocity and the blade should be positioned against the gas flow with a certain angle of attack. When the gas speed goes down to some critical level or the angle of attack becomes too big, the gas stream separates from the aerofoil and the energy transfer decreases and eventually stops. This has very little in common with cavitation in a pump or control valve. Cavitation is the formation of bubbles in a liquid, caused by the low pressure with associated lowering of the gas solubility. The gas evaporates from the liquid to these bubbles and the bubbles grow. When the pressure recovers, bubbles collapse and create hydrodynamic shock waves that cause all the damage. The only similarity between stall and cavitation is that they're both associated with the voids in the steam of gas or liquid, but the further development of the process in gas and liquid is very different.

Forum Post: The growing availability of light tight oils is resulting in a choice for refiners between upgrading metallurgy, or chemical inhibition and corrosion monitoring to manage the increased corrosion risk.

$
0
0
The availability of light tight oils (LTOs) is driving U.S. refiners to take advantage of the significantly higher margins available from processing this feedstock. But, these LTOs also pose corrosion issues. J ake Davies, director of Permasense Technologies products at Emerson Automation Solutions, writes in his article, Continuous Corrosion Monitoring of Crude Overhead Systems , in Hydrocarbon Processing magazine, how continuous corrosion monitoring can help refineries find problems and avoid shutdowns. Jake explains the problem. The production of LTOs relies on the use of fracking fluids, a cocktail of chemicals is used to stimulate oil to flow from the field. In many instances, these chemicals can end up in the crude oil feedstock to the refinery. In addition, the transportation of LTOs by railcar requires the addition of H 2 S passivator chemicals that can introduce other corrosion-related problems. Processing of LTOs at a refinery increases the risk of corrosion across a wide area of the crude overheads system. This can result in unplanned shutdowns driven by unacceptably high corrosion activity. If unnoticed and unmitigated, increased corrosion can lead to a hydrocarbon leak and, in the worst case, result in an explosion or fire. Continuous corrosion monitoring using Permasense sensors solves the problem, and Jake says the technique is being widely used. Oil and gas facility operators worldwide are solving this puzzle by deploying continuous wall thickness monitoring systems to track corrosion in critical locations. Not only does tighter monitoring enable cost-effective tracking of corrosion in areas of concern, it also enables a refiner to pinpoint specific feedstock or process operations causing accelerated corrosion rates. Jake goes on to explain that crude tower overhead systems are particularly susceptible to corrosion and offers a detailed description of how Permasense corrosion sensors work, and where to place them in the overhead systems. A typical overhead monitoring system would consist of 20-30 measurement locations, with between two and five sensors per location, for a total of 40 to 150 sensors, depending on the system configuration, metallurgy and operating conditions. Real-time corrosion data from ultrasonic sensors installed in the crude overheads system provides an effective understanding of the equipment integrity and the effectiveness of the overhead chemical treatment program. Jake offers two examples of refiners using corrosion monitoring with great success. In the first case, corrosion monitoring is used to adjust chemical treatments. In the second case, a refiner is identifying differences in batches of crude that caused increased corrosion. A European refiner used a network of ultrasonic sensors installed across the overhead system to adjust the treatment chemical dosage to stabilize corrosion. Once the chemical dose was optimized, the sensor data showed that the corrosion trend had been stabilized. A North American refiner was able to monitor corrosion rates in the overhead system attributable to specific batches of crude. Analysis showed a high and unusual level of organic chloride in the crude oil, probably due to the use of well-stimulant chemicals in the upstream oil production process. This refiner now routinely tests every new batch of crude feedstock for organic acids to pre-empt any corrosion problems.

Forum Post: RDP with 1920x1200 Resolution

$
0
0
When I try to login to DeltaV remotely using a resolutin of 1920x1200 it shows operate fills part of the screen on the right like its running a 1680x1050 while at 1920x1200 resolution however we are running that same resolution on the desktops in the plant and everything looks fine. Any ideas on how to fix it? The reason I want to do this is that when I work on the graphics here and look at them in the plant they look different. I develop them on 1680x1050 since thast the max resolution I can run operate in Run mode while remoted in.

Forum Post: RE: RDP with 1920x1200 Resolution

$
0
0
In DeltaV Operate Configure Mode: Click on the DeltaV User Settings button on the DeltaV Edit Toolbar Ensure the Bypass option is NOT selected Then make sure that the layout files (copy them) from the desktop machines you referenced are also on the term server machine This files are located in the DVData\Graphics-iFix\local directory and have .layout file extensions FYI these files can be computer specific and named COMPUTERNAME_Picture.layout
Viewing all 15475 articles
Browse latest View live


Latest Images