Emerson Exchange 365

• Not Answered

Issues Restoring Graphics Back-Up

Hi All,

I restored a complete set of project graphics onto a new development/testing proplus by copying the entire Graphics-iFix directory into place in DVData. This results in a script error when trying to start DeltaV Operate.  I've made changes to various settings including thisnode.SCU but no major improvement.  My questions are:

1. Is there a defined procedure for restoring graphics backups to a new pro+?

2. Is there a well-defined explanation anywhere of how the various settings, layout files and scripts all interact when Operate is starting?  It is a bit convoluted and I've only had to adjust minor settings in the past.

3. My monitor resolution is 1920 x 1080 which isn't supported by versions < 13.3.1.  Will this simply result in the graphics looking squashed/stretched, or cause errors when trying to run?

Any advice on any or all of these is much appreciated.

Len Walker

• 27 Jan 2022 11:20 AM
• Cancel

8 Replies

• Cedric Dawnhawk

  

  • 27 Jan 2022 1:52 PM

  What is the error message? At what percentage on the Operate startup progress bar does it occur?

  • Cancel
• Len Walker

  

  • 27 Jan 2022 11:13 PM

  In reply to Cedric Dawnhawk:

  'A compile error was detected in a script that was about to run. The script will not be started.' Error Number: 0 (00000000). Gets to 14% starting Operate Config.
  
  I have fiddled around and successfully had Operate Configure start, but then get the same error trying to start Operate Run.
  
  I know this is related to me copying global script/settings and/or config files into place, but I'm struggling to find the actual error. There is obviously something about the settings files I am missing.

  • Cancel
• Cedric Dawnhawk

  

  • 28 Jan 2022 10:42 AM

  In reply to Len Walker:

  In DeltaV Operate configure mode open the Usersettings picture in the Standard folder. Open the Visual Basic editor and try compiling the code for Usersettings. You may have to make a dummy change to the file (modify a comment say) in order to enable the Compile command. If you have a workstation specific setting picture do the same for that.

  • Cancel
• Len Walker

  

  • 31 Jan 2022 10:19 AM

  In reply to Cedric Dawnhawk:

  Thank very much Cedric Dawnhawk .
  
  I did find a compile error in UserSettings script related to User.gn_EnableAreaOvwTrends.CurrentValue, User.gs_AreaOvwTrendName.CurrentValue = "G2_Trends". Commenting these out removed the initial compile error and DeltaV Operate will now start. However, following startup the compile error continues to pop up repeatedly. When I OK the error box, I can manage to navigate between graphics before it comes up again, so Operate is working in to an extent.
  
  I'm not sure which script is called once Operate has started successfully, with no operator interaction. Though I am starting to suspect I am missing a User variable or colour them.

  • Cancel
• Cedric Dawnhawk

  

  • 1 Feb 2022 9:35 AM

  In reply to Len Walker:

  What was the error when you compiled UserSettings? The only thing I can see that might be wrong with the statement you mentioned [User.gs_AreaOvwTrendName.CurrentValue = "G2_Trends"] is that gs_AreaOvwTrendName does not exist. If this is the case it would suggest that the User.fxg file you are working with is not the same as the one on the workstation you copied the Graphics folder from. This would tie up with your last statement about other(?) missing variables.
  
  As to the compile error that pops up periodically, it could be related or might be something different. There are a lot of things that happen behind the scenes even with no operator actions. The VBA procedures are often triggered by schedules. To try and pin it down you could try setting "break on all errors" in VBA (tools | Options | General). You could try doing this once DeltaV Operate is in Run mode but it may not be effective. Otherwise you need to set it in configure mode then try to change to run. However you will probably get a number of "errors" which are normally ignored so it can be misleading. Have you looked at the TraceBox? Unlikely but there may be something there.

  • Cancel
• Len Walker

  

  • 10 Feb 2022 8:27 AM

  In reply to Cedric Dawnhawk:

  Thanks again. Using Break On All Errors and your hint about schedules, I found that there is set of schedules called APGSchedules which don't actually exist in the original project. Not exactly sure where they came from, but I disabled them (changed to one-shot) and my issues disappeared. Among the schedule items is AlarmSummaryServiceRawDataCollection. This, along with the two other schedule items were calling scripts which threw errors.

  • Cancel
• Cedric Dawnhawk

  

  • 10 Feb 2022 2:40 PM

  In reply to Len Walker:

  Glad you got to the bottom of it. I haven't come across APGSchedules but maybe someone else would know if this is a standard or custom schedule. From your description it sounds as though you disabled individual entries in the schedule. It is also possible to stop the complete schedule APGSchedules running. However it might be advisable to find out what else it does and why it is there before you do that!

  • Cancel
• Matt Stoner

  

  • 10 Feb 2022 2:56 PM

  In reply to Cedric Dawnhawk:

  APGSchedules is NOT a schedule from Emerson and removing/disabling might cause some issues with your system so I agree with Cedric that you need to find out what it was doing before removing totally.

  Based on your comment that within that schedule contained a named item AlarmSummaryServiceRawDataCollection I would assume it has to do with some Alarm Management logic that is either internal to the workstation/system (ISA 18.2 alarm counts) or an external system to get Alarm information but names are deceiving and it can be doing something completely different 

  • Cancel