Can I create a Citadel Database within Compact Fieldpoint?

[HWJ]

I have a SCADA project using Compact Fieldpoint as controllers. As there is a need for network redundacy, i am thinking of creating a database within fieldpoint. when the network is down, it will log to the internal citadel database, when the network is up, the data in this database will be merged over at the server end. is this possible?

if yes, how to create hte database?

if no, is there any advice on how to provide the redundacy ? thanks.

[Matthew_Williams]

Hi HWJ.  I can't answer definitively on the Citadel on FieldPoint question, but my guess is that won't work.  Hopefully
someone with a certain answer will chime in.

I can suggest a method to accomplish what you describe that we have used with good results in a number of applications.

Basically you create a queue on the FieldPoint controller that accumulates your data, then read that data to the PC.
As long as the queue can contain enough data elements to cover your longest projected network outage, you will be fine.

Our systems are setup to accumulate 10-50k readings in the FieldPoint, although in normal operation (network up) the
queue will have at most two or three readings.  The data comm portion keeps the queue essentially empty.

The advantages of this approach are that you don't have to code anything specific to happen when the network goes down
(unless you want an alarm); the FieldPoint doesn't have to check the network or PC status; and you have a built in buffer
for when the network is slow but not down.

There are several ways to do this, but the current best practice suggestion we have from NI (August 07, 8.2.1) is to
use Shared Variables hosted on the PC side.  The datalogging loop on the FieldPoint gathers and queues data, then there
is an independent loop in the FieldPoint that takes a copy of the top element from the queue and posts it to the Shared
Variable.  When the PC acknowledges receipt of the data (in another SV flag), the FieldPoint drops the top element and
moves to the next.  This way we never delete a queued element until the PC confirms receipt.  Even if the network crashes
after the FP has posted the data but before the acknowledgement we still won't lose it.

Lots of other ways to do this, but this works for us.

Matt

[nickf]

Hi HWJ,

   The Citadel database is only supported on Windows with the LabVIEW DSC Module.   However, you can develop a custom VI solution that will allow you to temporarily store data on the FieldPoint, and then integrate that data into the Citadel database at a later time.  To do this, you would need to setup the FieldPoint to periodically verify communication with the server.  If communication is lost then the FieldPoint would need to store data in a local temporary file.  When communication is restored you could transfer the data (automatically or via manual FTP) to the server.  The DSC Module includes a "Citadel Writing API" which you can use to write the data to a Citadel database.

This NI Developer Zone article describes the process (look for "merge" in the "Archiving Data" section).

-Nick

[HWJ]

Hi Matt & Nickf, thanks for the suggestions!! :smileyvery-happy

i thought of the method nickf suggested, however, i believe both r feasible.. i have another concern. when there is a network breakdown, it is true that the data will be temporary stored in the fieldpoint .. however when the network is up, upon retrieving back all these data to the server, may i what will be the time stamp for these data ?

the time of logging will be the time when they are actually logged to the Citadel? meaning for example, if the network is down between 1pm to 2pm. network is resumed at 2pm, these data are retrieved, they are logged from 2pm onwards in the citadel? wont that have any conflict with the real-time data that are going to be transmitted? or maybe if i'm using Matt's method, it will only release those data from the queue, so this wont be a concern, but then there will be some time delayed when i trend back the historical data?

or if i'm using Nickf's method, then i may also face the similar problem on the time? or actually these data do carry a time-info with them when they are logged every second?

any advice? thanks!!

[Matthew_Williams]

In our systems, what we actually queue is a cluster of timestamp, reading, alarm booleans and sometimes the error cluster from
the FP Read.vi.  This gives us all the information to properly sort and store the reading, without regard to when it eventually gets to
the PC.

I'm sorry I can't comment on the Citadel approaches; we concluded that there wasn't a good match between our application
requirements and the features Citadel has to offer, but it certainly has a lot to offer if there is a match.

Matt