last data point dsc

[viScience]

Ok, now I understand about ghost points but the question, as Ben mentioned, is there a way to access this data?

Also, why isn't this functionality built into the DSC read Trace(s) vi?

[viScience]

OK, the bottom line is that the Extrapolate to Now option in the Read Traces vi within the DSC toolkit does not work as advertised. 

Could someone at NI please confirm if this is a bug or not.

[viScience]

Jeez, nevermind then!  I just wrote my own solution which appends any traces that are not extrapolated or empty, with the latest current value of the NSV attached to the trace.

IMHO, I think this is something that NI should be taking care of.

[Ben]

---

sachsm wrote:

Jeez, nevermind then!  I just wrote my own solution which appends any traces that are not extrapolated or empty, with the latest current value of the NSV attached to the trace.

IMHO, I think this is something that NI should be taking care of.

---

Is it any wonder why I get the impresion that DSC is the redheaded step child?

Ben

[Joachim082]

Ben,

you're wright.  We think that NI hasn't recognized or can't sell the great options of the DSC product. We are working with the DSC module for many years and the combination of shared variable, OPC communication data logging via citadel makes a great job. Maybe the marketing department of the DSC team can push the module a little bit more?

[jareds]

sachsm,

It appears that this occurs when logging is interrupted in some way, such as a system reboot.  I'm looking into what is expected when this happens and will post back here with what I find. 

[viScience]

Unfortunately that is not the only way to create this problem.  In my case there is not interruption or rebooting.   My test all include multiple traces being read from the db.  Some traces (analog with no deadband) see to come out ok.  The problem channels are those that do not update regularly, such as setpoint channels.  The channels do not seem to extrapolate to current time under any circumstances.

[jareds]

If you look in Distributed System Manager at the variables that aren't updating regularly, what is there value listed as?

[viScience]

That depends on where you look,  if you probe the variable or look at it in the variable tree then you will see the correct current value

and also an updating timestamp.  If you look at a historical chart (hypertrend) then you will see that the trace does not continue beyond the last significant change of the variable in question.

My contention is that the problem is not in Citadel or Hypertrend but rather in the read traces vi that does not extrapolate correcting and also does not attempt to offer an option to return data for a trace that did not contain any transactions during the given time interval.  This last feature some may consider to be outside of the domain of the read traces vi but I think considering the common use cases should be offered as an option.

[Luis_AM3C]

Hi,

I got the same trouble, and after many time searching a solution, I did one.

Best Regards,