Citadel database redundancy with PXI

[HHasan]

Hello, I'm trying to make a redundancy system that includes a PXI that acquires readings of 100+ sensors to log data into a Citadel 5.0 database on my computer obviously . I am aware of the problem that Real-time devices dont support DSC.

The system works simply as follows:

a. Computer and PXI are connected

- PXI reads data every set time interval and communicates it using TCP to computer

-Computer takes the readings and stores them into shared variables

b. Interrupted communication between computer and PXI

-PXI cant make TCP communication

-PXI writes the data every set interval into a file (binary is what first came to my mind) and saves it into the PXI

-Computer retrieves data when connected again and adds the data from the file (readings + timestamp) to database

Problem is, I can't write traces back in time. I've heard about a way to do it here but I couldnt find backInTimeToleranceMS without sucess. I also tried to use Server based VIs but I couldnt install TCE successfully because of my runtime engine

-Extra into: I use LabVIEW 2013

I hope someone knows of a way to do this. I have been trying for almost a week now with no use

[MichaelBalzer]

I did a project several years ago which did exactly this (but with a cRIO rather than PXI). The solution we came up with was to include a sequence number with every data packet sent. The receiving computer would then buffer all packets, and only log data when it had the next packet in sequence. It was a bit of extra work to add, but guaranteed writes to Citadel were always sequential.

Another (less desirable) option would be to log data to a new database when the connection comes back online. You can then merge the old and new databases by performing an archive of one over the other. This can be very time consuming depending on the size of your databases. This may be suitable if TCP comms loss is very infrequent, but I'd only recommend it as a last resort.

[HHasan]

Those methods seem pretty good. I did think of the second one myself but I like the first one more.

The problem I have here is that you aew suggesting one of two things:

1- That the new data will be logged in the new time stamp (the timestamp when the computer later reads the sensor data) o2

2- That you can log the new data with the older timestamp. This is where I have the problem since you can't possibly log things back in time, can you?

[MichaelBalzer]

Ah yes, I'd forgotten about the variable time stamping. I think the only way around this is by using the manual Citadel trace writes rather than shared variables to write to the database.

[HHasan]

Unfortunitely, Right Trace.vi will not return a back-in-time error if there is no data store after the PXI is disconnected which is easy to do but it's not that simple.

If I write a trace like this, I will get the values like this DATA+TIMESTAMP , CORRUPTED DATA+TIMESTAMP , DATA+TIMESTAMP , CORRUPTED DATA+TIMESTAMP, . . . 

The Corrupted data is as follows: Value = NaN , Timestamp = 00:00:00PM  00/00/0000

[Kelly_B]

Hello HHasan, 

This KnowledgeBase article might help shed some light on the NaN data you are seeing and how to remove it by copying only the good data into a new trace.

I also agree with MichaelBalzer, using the Write Trace VI rather than shared variables is a good way to proceed in this case.

[HHasan]

Hello Kelly,

Thanks for the response. I will look into this method