PVSStoolCreateDb always uses fixed dpCommentSeparator when creating_DpGroup datapoints

[RudiKreiner]

In this issue
https://portal.etm.at/index.php?option= ... =5011#5903
I had noted that there are dpGroups with names like OPCUARead@%s@ displayed in the DP Groups panel
and always wondered what the @%s@ meant.

I finally figured it out, silly me, should have thought of this earlier. Here is the explanation:

We have the following entry in our config file
dpCommentSeparator = "!"
because we had some problems with the default separator @ with the asian multibyte fonts before we switched to UTF format.

Therefore the @ character is not interpreted as a separator so I see OPCUARead@%s@ in the desription.
If I change the description to OPCUARead!%s! then I only see OPCUARead in the description and %s in the format as I would expect.

The config entry already exists in the config file when we call PVSStoolCreateDb
but it looks to me that this tool ignores it and uses @ as the separator anyway.

I would classify this as a small bug that should be fixed up for the next version, so that PVSStoolCreateDb uses the configured separator when setting descriptions for these datapoints.
Maybe other datapoints are affected too, though after a quick look I couldn't find any others. If they are, they should be fixed up too, of course.
Do you agree?

[leoknipp]

I think you are talking about WCCOAtoolCreateDb and not the tool with the old name PVSStoolCreateDb.
When creating a new database some standard files are imported where the "@" is used as separator, e.g. /dbdfiles/version_/configs.txt.
If the tool would use the config entry importing the standard files would lead to incorrect alias names.

When you are importing own ASCII files during the creation of a new database you have to ensure that the same separator is used.
Or you start the import of the own ASCII files when starting the project for the first time, then the separator can be used in the ASCII files.

Best Regards
Leopold Knipp
Senior Support Specialist

[RudiKreiner]

You are right about the new tool name, sorry. Old habits are hard to break.

When we import our own ascii files, we have no problems because they use ! as the separator.

We only have the problem when creating a new DB, because WCCOAtoolCreateDb imports the configs.txt file which contains the default separator @ which doesn't match our !.
Strictly speaking, WCCOAtoolCreateDb should correct the separator to match the dpCommentSeparator entry of the config file, before importing it.

I wouldn't want to change the @ to ! in version>/dbdfiles/version_/configs.txt file because if you distribute a patch then that could overwrite my changes again.
I guess the easiest thing for us to do would be to write a little script that updates the descriptions of those datapoints, changing @ to !.

[RudiKreiner]

Here is the control script that I wrote to fix up the descriptions for our application:

Code: Select all

main()
{
  const string DEFAULT_SEPARATOR = "@";
 
    // read required information from WCCOA config file
  string configFile = getPath(CONFIG_REL_PATH, "config");
  dyn_string separators;
  paCfgReadValueList(configFile, "general", "dpCommentSeparator", separators);
 
  // if config file contains no such entry, then default separator is OK, so nothing to do
  if (dynlen(separators) != 1)
    exit();

  // also nothing to do if the new separator is same as the old one
  if (separators[1] ==  DEFAULT_SEPARATOR)
    exit();
  
  // now fix up the comment (description) separators for all datapoints where it is wrong
  // ie. those created at new db from dbdfiles\\version_3.14\\configs.txt 
  fix_comment_separator("_DpGroup*_Public.",         DEFAULT_SEPARATOR, separators[1]);
  // etc....... 
}

// for all datapoints that match 'pattern', replace the comment separator 'old_separator' with 'new_separator'
void fix_comment_separator(const string pattern, const string old_separator, const string new_separator)
{
  dyn_string dps = bms_DpNames(pattern);

  // there are no such datapoints
  if (dynlen(dps) == 0)
  {
    DebugN( __FILE__, __FUNCTION__, "no datapoints found to match pattern: " + pattern);
    return; 
  }
  
  // nothing to do if descriptions no longer contain old separator
  string description = dpGetDescription(dps[1]);
  if (strpos(description, old_separator) < 0)
    return;
    
  for (int i = 1; i < dynlen(dps); i++)
  {
    langString desc = dpGetDescription(dps[i]);
    
    for (int langIdx = 0 ; langIdx < getNoOfLangs(); langIdx++)
    {
      string txt = desc[langIdx];
      strreplace(txt, old_separator, new_separator);
      setLangString(desc, langIdx, txt);
    }
    dpSetDescription(dps[i], desc);
  }
  DebugN( __FILE__, __FUNCTION__, "corrected comment separators for " + dynlen(dps) + " datapoints that match pattern: " + pattern);
}

[leoknipp]

I now see what the problem is, thanks for the description.
In our internal database I've created a new entry and forwarded it to our development department.

Best Regards
Leopold Knipp
Senior Support Specialist

[RudiKreiner]

That is what I was hoping for, great.
Thanks.