03-15-2012 03:37 PM - edited 03-15-2012 03:38 PM
I am using the Channel Fault Manager Tool to debug my models. Here is the problem:
The model is such that I know what model1.a is, and hence what model2.b is. This is confirmed by using the Channel Data Viewer tool.
Now I pop the Channel Fault, and set model1.a = faultvalue. In turns, model2.b = faultvalue as shown by Channel Viewer. However, and this is where I am losing my mind, it appears that model2.b is not overriden, but remains to its original value set in model1.a, despite the fact the Channel Viewer indicates so. To test this, model2 includes a comparison test that checks model2.b against the original model1.a value that I know is a cst.
So am I using the Fault Manager the wrong way? Is there a bug ? I don't see why the Channel Viewer shows a channel data that is incorrect.
L.
03-15-2012 05:20 PM
yeah... Unfortunately that is a known bug. #332403
We hope to have it fixed in a future release.
the only work arounds are to not run your models in parallel or to implement your own software faulting logic inside the model.
03-15-2012 05:57 PM
wow... rough day! After this debugging approach not being workable, now the Channel Fault is buggy...
Is there more details available on the bug? It looks like it works when the source is a hardware channel, or a user channel, but not with a model, is that what you guys observed ?
Thx.
Laurent
03-15-2012 06:09 PM
yeah... I appologize for the inconvience.
the details:
a model output mapped to a model input of a model in a later execution group can be faulted (normal), but the faulted value is not observed by the model input in the later execution group... only the actual value (bug). so the work around is to put them in the same execution group or if you must maintain the execution ordering, implement your own software fault logic into the model(s).
03-15-2012 06:28 PM
Thx Stephen.
L.
12-11-2012 03:43 AM
The #332403 bug doesn't appear in the list of NI VeriStand 2011 Know Issues.
The work around is to run the models in parallel (and not "to not run").
Regards,
Hubert R