Wrong channel value

[thumble]

Hello,

We’re using VeriStand 2011 SP1.

We have experienced twice a weird thing:

After we had started a nivssdf on a real-time target, we noticed that a channel was displaying a strange value regarding to its definition.

We thought it was because an error in the scaling, and looked at the “Calibration & Scaling” tool. We were surprised to observe that the physical value was totally unrelated to the raw value (each raw and physical values were living their own lives). We tried to change the scaling polynomial with no effect.

In case 1:

-       A fault applied with the “Fault manager” had no effect.

-       An error check in the “System Configurator” points to a problem relating to a channel ID (unfortunately I didn’t capture the error)

-       The problem was fixed by deleting and recreating the channel.

In case 2:

-       It seemed that the value was actually a copy of another channel.

-       A fault applied with the “Fault manager” applied to the physical value.

-       An error check in the “System Configurator” states no error.

-       The problem was fixed by deleting and recreating the channel.

Is that a known issue? How can I detect / prevent this to happen?

Any explanation will be welcome.

Best regards

[thumble]

Additionnal info: issue reproduced after removal of a custom device from the vssdf. Please check error message in attachement.

[rajamodol]

Hi thumble ,

I have seen that you are using custom device. Trying to answer your question:

Case1/2:

- Check your channel in custom device. Make sure if "Faulted" set to true.

- Make sure in system definition if your channel doesn't have mapping to other channel. If you delete and recreate the channel, it will delete also it's mapping. So, i am sure that your channel was mapped to other channel. Or at least, there is another channel which try to overwrite your channel value. Check your mapping again.

Hope it could help.

Regards,

Rajamodol

[thumble]

Hello Rajamodol,

We have checked the mappings and it looked right.

The problem is that it’s our customer how makes changes in the definition (using VeriStand, not patching XML), the tool does not report the problem in a reliable way and the ssdf get deployed with no error.

Depending on the affected channel, very strange side effects can appear that could lead to a miscontrol of the bench. The detection of the issue is also quite difficult.

The question is: what kind of operation(s) can lead to this case, and how can we prevent it or at least detect it in a reliable way.

Best Regards

[rajamodol]

Hi thumble,

If your costumer is alloewed to modify sysdef, then it should be on their responsibility. What you can do just, having a backup of your sysdef and compare of what your customer modified. May be you can start from this point.

What did you find after comparing the correct sysdef and the wrong one? 

Regards,

Rajamodol 

[thumble · Accepted solution]

Re,

I may have the explanation (TBC by my colleague when he’s back in office).

One of our custom devices declares blocks of channels to be exchanged through reflective memory. Each of these blocks can be declared in read or write depending on the direction of exchange. The bench is composed of 6 independent nodes that share information through the RFM, so each has 6 blocks defined (1 in write and 5 in read mode).

On one node the write block has been changed to read mode (changing the channel direction from output to input) as there were still existing mappings to it. The result is that they don’t appear anymore in the mapping interface but the data source channel in the vssdf xml is still connected to another input channel.

This case leads to an abnormal mapping (input -> input) that is not detected by the configuration check tool as soon as the data source is valid, and the effect in real-time ends with value overwrite. An error is reported only when a data source channel is deleted.

To summarize, this issue can happen when the read/write direction of a custom device channel can modified (this is common in bus interface).

Regards,