rss
0

Pressure Cycle Tracker Program

An oil & gas equipment manufacturer requested that their current pressure-temperature test software be revised to track the pressure cycles on components in their lab. The revision included the below scope of work.

  • Define tracked items, pressure cycle, and expected operating life values.
  • Develop a working simulation of the cycle tracker in LabVIEW.
  • Develop a working simulation of the database program in LabVIEW.
  • Revise existing program with the cycle tracker.
  • Commission the revision at 7 test stations.
  • Train technicians on use.

The client added the following requirements toward the end of the project: the ability to programmatically edit the list of components, and the ability to select cycling based on bore pressure or open/close cycling. A screenshot of the end product is shown below.

Pressure Cycling Program

 

Several complications, in addition to the added requirements, required resolution. These are listed below.

Resolutions to potential complications:

  • 6 parameters were used to define a pressure cycle. The following sequence of steps must be completed to increment # PsiCycles. (1) PSI<=Peak_L for a cumulative elapsed time of t_L seconds, (2) PSI>=Peak_H for a cumulative elapsed time of t_H seconds, (3) PSI <=Peak_L.  We did not want pressure transducer noise near target pressure to falsely iterate cycles. We also did not want to reach target pressure, leak below target pressure, then bump up above target pressure to falsely iterate cycles.
  • No detailed fatigue analysis was intended which would require values like component pre-load, mean stress, stress amplitude, etc. Only the number of cycles was requested.
  • Only this tab of controls would be “disabled and grayed out” at program start to eliminate safety hazards.
  • A dialog window pops up once per increment of part to 300 cycles or more. The pop up does not freeze the program.
  • The cycle tracker was added to the existing pressure-temperature test program. A separate cycle tracking program and database program was not created. The program reads from a configuration file on a server computer before a test, then writes to the same configuration file on a server computer after a test. Periodic writing was not done because multiple computers writing to one computer greatly complicates the program. The commands could interfere. Network bandwidth requirements go up and so does the vulnerability to network reliability. Someone could accidentally write a blank file and erase all data. The program does not write to the file if it is accidentally shut down.
  • A chosen configuration must be “locked” which disables and grays out the selections so the data is not unintentionally edited during testing. Additionally error checks are done to check for duplicate selections or blank selections.

Comments are closed.