"No Data" in MAX, but my variables are reading. What gives?

[Pcorcs]

Would it be possible to provide more specific information on the NI software being used in this system? Version of MAX? Version of LabVIEW? Does the user account permissions level mentioned previously, change the behavior in any way? 

Is the Hypertrend Viewer you have displayed in the post logging to a Citadel Database, as part of LabVIEW DSC? Is there a difference in shared variable types that are working vs. the ones that are not; i.e., variables bound to I/O Serves are logging but standard SVE libraries are not? Even though Null is displayed in the viewer, are complete traces being written to the database if you read back the information programmatically?

Are the variables you are logging being hosted on the machine you are using to view traces in MAX? Are all system clocks relatively close if not SNTP synchronized? Have you verified that the time stamps of the shared variable data being viewed in DSM are current? (I have seen data logged to sometime in 1964 due to a system clock issue, that was displayed as NULL in the current time hypertrend view) 

I very much appreciate your time in answering these questions. I look forward to your response. 

Cheers, 

[Orion HE]

Version of MAX

4.6.of1

Version of LabView

2009

I have all permissions.

I am using DSC to log all my values.  Most values log all of the time and some only some of the time.  The pc running this application is hosting all of the variables.  My clock is synced to a network time server.  All of the variables are bound and were created programmatically so there should be no difference in setup of the variables.  A visual inspection of the multiple variable editor confirms this.

[Pcorcs]

Would it be possible to do a comparison between a Library created manually in the LabVIEW project, and a Library programmatically generated? I would be looking to qualify the possibility that the programmatic creation has caused an issue in the way objects are registered with the Citadel service. 

Thanks, 

[Orion HE]

By programmatic I mean that I wrote a VI that reads from spreadsheets and builds the library based on a naming convention that works for me and the OPC server we use.  I cannot believe that it would select to make some variables with different attributes and on top of that, attributes that are hidden from sight upon inspection within the variable editor.

[Pcorcs]

I am not suggesting that your method is wrong. I am suggesting that there may be a problem in the way programmatic generation is working. The manual creation is simply a troubleshooting step, to ensure that 100% of manual variables log successfully in MAX, as opposed to the 50% of variables that log after they were created programmtically. I am not proposing this as along term solution, I simply have been unable to recreate this exact behavior on a system on-site; ergo, I cannot try these options independently. 

I also realize that this is a step you 'should' not have to take, we are simply working to better isolate the source of this communication error.

Thank You,

[Orion HE]

I do appreciate that you are giving my issue some consideration.  I can't see this as a scientific approach though.  For instance, if I make 5 variables manually, and they work, then one could state that since manual creation works, I should remake all 1400 variables manually.  On the other hand, if I make the 5 variables manually and 4 of them log but the fifth doesn't, it implies I set up the variable incorrectly and therefore doesn't work as expected.  This second scenario leaves room for operator error.  I hope you can see why I don't see this avenue as a viable course for problem resolution.  

I also understand that you haven't had this problem yourself and therefore can't offer a solution without more data.  

[Pcorcs]

Is it possible to post the VI that is being used to generate the variables for deployment on my systems? I'd like to see if I can replicate this when bound to simulated data?

Thanks, 

[Orion HE]

I need to make a correction.  Upon searching for the VI that I made to programmatically generate variables (and not finding it), I found the VI that I was using.  It turns out my method for creating variables was to "create bound variables" within labview, then to use my custom VI (enclosed) to rename the variables should I need to (and I did), and still keep the correct path.  

Within the Multiple Variable Editor, I am able to highlight all of the variables and select data logging, or buffering of whatever I chose, and have it apply to all of the variables.  What I was not able to do in Labview, as it is not included as a feature, was to change a group of variables by exporting the variable list as a .csv, and opening it in my custom VI.  This allows me to change a path accross multiple variables with ease, rather than manually for hundreds of variables.  Stupid thing to exclude if you ask me, the ability to change the path accross multiple variables.

So the long and short of it is, all of my variables were created manually, but changed programmatically.  This still doesn't indicate why my variables would be read sometimes, not read other times.

[Pcorcs]

Thank you for posting the VI. Are all variables that display NULL of the same datatype? Do all variables in the data set conform to the DSC tag datatypes listed here?

Also, when the software was moved to a new system, are the variables that display NULL the same variables that did on the original machine? 

Thanks,

[Orion HE]

As far as I can tell, I don't have a Tag Configuration Editor.  I had to search for it on the Labview site to learn what it is, and the site says it's located in the tools menu.  It's not in my tools menu, so I assume I don't have it.

I have to PCs running the application that I have built that is doing the logging.  The older installation, as far as I can tell has never logged the values.  The newer installation logs them with varying levels of inconsistency.  Most of my values log on both machines, and both machines run the same logging application.