VeriStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Channel Fault Tool or Channel Data Viewer Tool Issue?

I am using the Channel Fault Manager Tool to debug my models. Here is the problem: 

 

  • model1 produces output a  ( it is a constant in fact, so I know what is is at all time)
  • model2 is set with input b
  • the following "plumbing" is set in VS:  model1.a ------->--------- model2.b  

 

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.

 

0 Kudos
Message 1 of 6
(6,512 Views)

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.

Stephen B
0 Kudos
Message 2 of 6
(6,506 Views)

Smiley Frustrated 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

0 Kudos
Message 3 of 6
(6,503 Views)

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).

Stephen B
0 Kudos
Message 4 of 6
(6,501 Views)

Thx Stephen. 

L.

0 Kudos
Message 5 of 6
(6,499 Views)

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

0 Kudos
Message 6 of 6
(6,307 Views)