Current Value Table (CVT)

[smithd]

It wouldn't be safe to have something that is both readable and writable. It would be subject to race conditions between the local code (running on the target) and the remote comms (running on the HMI). I'd recommend making two tags.

[carrasquel]

Greetings, I would like to know if anyone have extended the use of the CVT with more data types, like stric type def or type def, and if example exists I would be thankful.

P.S.: Sorry for my messy english!

[smithd]

We've thought about making a script for this (in fact all the current types are scripted) but decided it would be too confusing due to deployment issues (ie if you are using your custom data types on machine A but send your code to machine B, machine B may not have the same types). The generic package was the better fit.

That having been said if it just needs to be a generic container, but doesn't need to be global, these might work for you:

https://lavag.org/files/file/248-variant-repository/

https://decibel.ni.com/content/docs/DOC-36470

Alternatively you could flatten your clusters to JSON, XML, or a binary string and use the string data type to transfer the data.

[carrasquel]

Well, I "solved it" with JSON , converting a cluster to a JSON string, and using a string data type in the CVT, thanks

[xl600]

I'm attempting to use CCC in a way that seems like it should be allowed, but I'm not getting very good results.

• On my server, I create a tag database from a CSV file.
• I then add a tag called "ALL_TAGS" (String array) with the names of every tag read from the CSV file.  This represents the tags in the original order of the CSV file.
• I then add another tag "CVT_Flattened" (String) with a flattened copy of the tag database (Including ALL_TAGS)
• The server's CVT is then initialized with the tag database and everything is happy.
• Once happy, I start the CCC server.

On my client, I want it to adapt to whatever CVT the server is running.  So I do the following:

• Create a CVT tag database containing "REMOTE_CVT_Flattened" and "REMOTE_ALL_TAGS"
• Initialize a client side CVT with just those two tags
• Create a tag config to read just ALL_TAGS and CVT_Flattened.
• Initialize the client CCC with that config.
• Perform a read
• Close the client CCC
• Read back the REMOTE tags from the client CVT
• Unflatten the REMOTE_CVT_Flattened string
• Delete the client CVT
• Re-initialize the client CVT with the unflattened tag database
• This mirrors the tag configuration from the server to the client.  Everything works great.

Now here's where it falls apart:

• I take the REMOTE_ALL_TAGS array (Names of every remote CVT item except CVT_Flattened) and create a new CCC tag list
• Name and bound address are identical because the client and server CVTs are now configuration sync'd
• All tags are set to read mode from the client CCC (This is a debug monitoring tool so nothing gets written to the server)
• Data types are read from the local CVT since those are sync'd configuration wise as well
• I then start up a new CCC client with the new tag configuration

In the following sync or syncs, the resulting data is either all default values or some values are mixed up.  It appears to be coming from the SERVER side (When I probe the returning STM data it looks like the source of the issue is the server side).

Looking at the server, the CCC read group coming from the client looks fine.  The CCC server just doesn't seem to want to properly send the latest CVT data out for the read group.

Are there known issues with any of the following:

• Reconnecting a CCC client with a CCC server but with a different tag list?
• Re-defining a CVT group within the server?  The way I'm doing this, the same group name gets created twice with different data on the server side.

The VI's for all this are rather complicated and I don't yet have a demonstration of the issue so please bear with me as I try to work this out.

Thanks,

XL600

[xl600]

It appears that this is a basic disconnect between how the CCC and CVT were designed.  CCC allows reconfiguration of the list of tags being sync'd in both the read and write directions.  But in the CVT, Read Grouped Tags.vi and Write Grouped Tags.vi are designed to only re-read group indices if the group name changes.  It uses an uninitialized shift register in an attempt to increase the performance of group reads.  In my case, the second connection to the server CCC resulted in an identical group name with the previous group's indicies (And the ensuing disconnect on the client side).

I see two options:

1. Modify CVT and CCC to re-read group indicies upon CCC reconfigure (Add a re-read Indices option to Read Grouped Tags.vi and Write Grouped Tags.vi).
2. Have the CCC change the read/write group names on every reconfiguration

Thoughts?

Thanks,

XL600

[xl600]

And here's another idea which seems to be working:

For the server

• Add a new VI called "Server Handle Disconnect Message.vi".  The job of this VI is to delete the server read and server write groups so that they don't act as a memory leak (In CVT Group memory) when client reconnections occur.
• Modify Server.vi to call this VI in the disconnect case.
• Under Server Handle Configure Read Message.vi and Server Handle Configure Write Message.vi, add an incrementing index to the tail end of the read (and write) group names.

For the CCC client

• Within Client init.vi, add an incrementing index to the tail end of the server ID.  The groups will be closed when calling Client Close.vi.

I've attached a revised copy of CCC.lvlib.with these changes.

All these changes do is cause the CVT group names to change upon configuration/reconfiguration.  This causes the CVT read or write group vis to read indices on the first read or write of the new group name.  I thought about adding a dummy read or write at the location of the CVT Group Tags.vi call (Within configure server group.vi for the server and Initialize Address Lists.vi for the client), but that would have required additional changes to determine which CVT vi (read or write group) to call.  Unique names seems the easiest approach.

XL600

[DowNow_]

Hi,

I have an HMI Main VI that uses a LabVIEW subpanel to display a variety of display plugins. Each plugin is a LabVIEW VI dynamically loaded and inserted into the subpanel. The plugin VIs have CVT api VIs on their diagrams, and the HMI Main VI initializes the CVT and uses CCC to synch to a cRIO target.

My question is, how can I get the plugin subpanel VIs to share the CVT with the HMI Main VI when HMI Main is an .exe? Is this possible?

I could simply embed the plugin VIs in the Main .exe, but the end user would like to add plugins while the .exe is running. I have them in a separate directory. I realize this is a LabVIEW application builder topic, but I thought you all might point me in the right direction. 

Would it be easier to achieve this goal of using HMI display plugins with TBDF? Thanks.

cc

[xl600]

I do something similar.  I use CCC to share CVT of my host main to my pxie controller main.  I use a second CCC in my pxie main to share to a host debug exe.  And another second CCC in my host main to share to another copy of my debug exe  CCC instances can coexist as long as they are using different ip addresses (including loop back addresses like 127.0.0.1 and I believe 127.0.0.2 etc... Haven't tested that though).  It really comes down to inter process comms when dealing with multiple exe's or external communications.

[DowNow_]

Hi,

Thanks for the post. I was thinking about using a second CCC. Now that I know someone else uses it... Interprocess comm - I got it. Thanks again.

cc