[Bug] Writing to the same trace in Citadel from two Sources at the same time

[jgcode]

Howdy

I am experiencing an issue and am looking to get some NI support:

I have two distributed applications that can write to a Citadel database at the same time.

And I am investigating the possibility of what would occur if both of them were writing to the same variable at the same time, with possibly the same timestamp data.

I did this in the attached VI by using the same timestamps with a constant for the data (either #1 or #2).

This generates an error, as expected, stating you cannot have two references open at the same time.

The data file, dumped from Citadel, contains 1000pts with all data from only one of the arrays (in this case #2) and everything looks fine:

However, what appears to be happening randomly tho, is that the same portion of code can also returns no error.

When the data is dumped from Citadel this file contains 2001pts - 1000pts from each array and one separator (or break) point:

You cannot write an older timestamp to Citadel without it throwing an error, but from further testing it seems you can write the same timestamp repeatably. So I am guessing what is happening above is race condition that is somehow allowing two references to be opened to Citadel which should throw an error but it does not and this is somehow allowing both sets of data to be written by both loops??

The data, IMO, is now corrupted.

Is being able to write to the same timestamp a desirable feature?

Or is this a known issue or a bug?

What about acquiring two references - bug?

Is there a workaround to protect the data from multiple distributed-application writes?

Cheers

-JG

Attached VI was coded and tested using LabVIEW 2009 SP1, DSC 9.0.1, MAX 4.6.2f1

[Ben_S]

jgcode,

Hello! Thanks for the info, code, and pictures! I've modified your code a bit and attached it. My modifications allow me to run multiple successive tests that can overlap the timestamps if I want. When I run both your code and my code, I get error -1967386570 and not error -1967386569. I am using the same software as you.

-----------------------------------------------------------------------------------------------------------------

Error -1967386569 occurred at an unidentified location

Possible reason(s):

Citadel:  (Hex 0x8ABC1037) There is already an open writer for the selected trace.

-----------------------------------------------------------------------------------------------------------------

Error -1967386570 occurred at an unidentified location

Possible reason(s):

Citadel:  (Hex 0x8ABC1036) Data has back in time timestamp

-----------------------------------------------------------------------------------------------------------------

Questions:

1. Is being able to write to the same timestamp a desirable feature? - Investigating
2. Or is this a known issue or a bug? - Not that I know of or can find.
3. What about acquiring two references - Investigating
4. Is there a workaround to protect the data from multiple distributed-application writes? - You can use notifiers, or something similar over a network.

[jgcode]

Hi Ben

Thanks for your reply.

I have applied for a service request (Reference#74887) with NI here (Australia) for this thread.

I was able to corrupt the database using your code just running by itself:

I still think there is an issue/bug with allowing two open references in the same VI.

However, I am wondering if the Test Case presented is valid.

I will not be opening two references to write in parallel in the same VI rather, there is the possibility that two writes may occur from two different VIs and that is what I was investigating

E.g. Running two VIs writing at the same time always seems to create an error which is good news, I haven't managed to corrupt the DB that way.

Additionally I may have come across another issue:

I changed your VI from a .vi to a .vit and it became broken:

The Open Trace.vi (polymorphic) now becomes "missing" 

All I have to do is drag and drop it and it relinks, and after that it seems to be fine

But I have had builds break in the past with this VI.

The workaround is to use the actual referenced VI on the BD, not the polymorphic VI.

So I think something maybe weird with the polymorphic VI. 

Can you replicate this?:

[Ben_S]

jgode,

I did some more research and am able to answer all the questions now.

Questions:

1. Is being able to write to the same timestamp a desirable feature? - Yes, this is intentional. The reason is that often "soft breaks" can occur on a very low level where due to DSC needing to log an event/alarm/etc you can write data with the same timestamp.
   
2. Or is this a known issue or a bug? - No
3. What about acquiring two references - This is not technically a bug as much as it is strongly reccomended you not do it. This is actually a race condition, and you should avoid programming your application to be able to do this.
   
4. Is there a workaround to protect the data from multiple distributed-application writes? - You can use notifiers, or something similar over a network.

I am unable to replicate the .vit issue that you are seeing. Can you attach the .vit that is broken to this forum and I will open it up on my end to see if it is broken as well.

[jgcode]

Hi Ben

Thanks for all the info.

Just to confirm - the race conditions only exists within a VI, but is guaranteed not to occur in separate VIs?

Attached is the VIT with the issue, I simply downloaded your VI and changed the extension.

I have done this on two PCs both of which .VITs are broken.

[Ben_S]

jgcode,

When I run two seperate VIs I still get Error -1967386570 (Back in time timestamp). The race condition of opening the refererence in two places at once should still apply to two different VIs running at the sametime.

If you open up the code and save it as a .vit, you don't get any missing VIs. Only when you change the extension without the aid of LabVIEW.

[jgcode]

---

@Ben S wrote:

The race condition of opening the refererence in two places at once should still apply to two different VIs running at the sametime.

---

Will a CAR be lodged for this?

---

@Ben S wrote:

If you open up the code and save it as a .vit, you don't get any missing VIs. Only when you change the extension without the aid of LabVIEW.

---

No VI should have missing members by simply renaming its extension outside of LabVIEW???

I think there is an issue with the VI.

Can you replicate the following and verify what I am seeing?

Attached is a Project with Main VI (contains a call to the Open Trace.vi polymorphic only), a Class and a Build Spec

If you Build the spec with the Main VI outside of the Class it works

If you place the VI in the Class, save then Build, the Spec fails with the error:

Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:

Error 1003 occurred at AB_Application.lvclass:Open_Top_Level_VIs.vi -> AB_Build.lvclass:Build.vi -> AB_Application.lvclass:Build.vi -> AB_EXE.lvclass:Build.vi -> AB_Engine_Build.vi -> AB_Build_Invoke.vi -> AB_Build_Invoke.vi.ProxyCaller

Possible reason(s):

LabVIEW:  The VI is not executable. Most likely the VI is broken or one of its subVIs cannot be located. Select File>>Open to open the VI and then verify that you are able to run it.

Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:

Error 1003 occurred at AB_Application.lvclass:Open_Top_Level_VIs.vi -> AB_Build.lvclass:Build.vi -> AB_Application.lvclass:Build.vi -> AB_EXE.lvclass:Build.vi -> AB_Engine_Build.vi -> AB_Build_Invoke.vi -> AB_Build_Invoke.vi.ProxyCaller

Possible reason(s):

LabVIEW:  The VI is not executable. Most likely the VI is broken or one of its subVIs cannot be located. Select File>>Open to open the VI and then verify that you are able to run it.

Next place a disabled structure around the Polymorphic VI (as Class Member or not, it doesn't matter)

Save the VI

Close the VI

Open the VI - the Open Trace.vi polymorphic is "missing"

Cheers

-JG

Code in LV2009

[Ben_S]

jgcode,

Thanks for the info! I can replicate both of the issues that you show.

I was able to resolve the first issue by following step 2 in the document, Error 1003 Occurs When Trying to Create an Executable. It appears there is an issue with that Polymorphic VI that causes it to need to be relinked. I bet this is the same issue that causes it to go missing with the diagram disable structure. For the missing VI issue, I created CAR (Corrective Action Request) 243120.

In regards to the .vit issue, that is to be expected. A .vit file contains additional information that is added by LabVIEW when you save it from the Programming Environment. By chaning a .vi to a .vit in windows, you are meerly changing it's extension which can change what kind of a file a program recognizes it to be. For example, if you create a .txt file and rename it to be a .docx file, word will recognize it as a word file extension, but will not be able to open it as it is not actually formatted in the word format.

[jgcode]

Hi Ben thanks for the CAR.

---

In regards to the .vit issue, that is to be expected. A .vit file contains additional information that is added by LabVIEW when you save it from the Programming Environment. By chaning a .vi to a .vit in windows, you are meerly changing it's extension which can change what kind of a file a program recognizes it to be. For example, if you create a .txt file and rename it to be a .docx file, word will recognize it as a word file extension, but will not be able to open it as it is not actually formatted in the word format.

---

I have been changing VIs to VITs for years and never had any issues before.

Since the issue in this case is a problem with the VI that you have issued the CAR for, I am pretty sure that, that VI, is the cause of this problem.

Cheers

-JG