Error -307736 in case of using a channel in an alarm from an other target then the controller

[SteffenSchmidt]

Hi,

we often have the problem that we selected in an Alarm condition as target a channel outside the controller (in our case the Siemens Simatic Box PC). The Veristand config did not notice this as a fault or error, but in case of loading it occurs the Error -307736. The error description does not give a hint which channel causes the problem, so it is hard to find the won with the not allowed connection.

Is there a possibility to get more information where the corrupt channel is, to find faster the root cause ?

Exists there a tool to analyse the *.nivssdf file for such problems ?

This file looks like a xml file and it should be possible to scan the alarms for target channels outside the controller and mark them.

<Target Name=Targets
 <Section Name=Controller
  <Section Name=Custom Devices
   <Section Name=Alarms Management
    <Section Name=Alarms List
     <Section Name=MyCorruptChanelFromTheSimatic
      <DataSourceNode Channel="Targets/Siemens Simatic Box PC/Custom Devices/ASAP3/From AULOS/CWEVAB" />

     <Section Name=MyCorruptChanelFromTheSimaticAsAlias
      <DataSourceNode Channel="Aliases/ASAP3/ASAP_rl_w" />

Is the target connected via an alias the Target information have to be found in the alias structure

<Section Name=Aliases
 <Section Name=ASAP3
  <Alias Name=ASAP_rl_w
   <DependentNode Path="Targets/Siemens Simatic Box PC/Custom Devices/ASAP3/To AULOS/rl_w" />

[Darin_G]

Hi SteffenSchmidt, 

I have never heard of anyone building a System Definition sanity checker, sounds like an interesting idea though!

Because VeriStand errors can often be confusing and not lead you to what is broken, users in this situation often move to using VeriStand's .NET APIs to generate System Definitions in an automated way in order to minimize the introduction of errors that might 💣 blow up the ability for the SD to function correctly. Often users will start down this road by having some kind of golden base configuration SD XML checked into source control and then modify it via scripts. This may make it easier to do diffs of the XML before/after to determine what changed, though be warned that I've heard complaints that the SD XML diffs can be hard to read from revision to revision due to VeriStand internal GUIDs changing often (how much this will impact you really depends on what Custom Devices you are using).