Current Value Table (CVT)

[smithd]

Im actually surprised by this question. Since FGVs are a per-context data store, I would assume that if an exe loads a VI into a subpanel, thats the same context and therefore the CVT should just work. Have you found this to not be the case? Are you doing something else, like building into a lvlibp? Or are you generating a source distribution and not forcibly excluding the CVT lib?

---

also saw your solution to the CCC issue. It sounds reasonable enough. As I said in the other thread, feel free to post issues on the github page, as that broadcasts to the whole team.

[DowNow_]

Hi,

I built a source execution for the plugins and did not forcibly exclude the CVT lib ('m pretty sure). So then you are implying I might try removing the CVT lib from the pluins source distribution? I was surprised too, and I did some googling and it wasn't crystal clear but it sounded like there might betwo contexts, plugins and .exe. I will try the forcible exclusion.

What other ways are there to distribute the plugins? The end user wants to be able to add plugins while the .exe is executing, so I couldn't just paste them into the main VI somewhere. Thanks so much for your reply.

cc

[xl600]

For my project, I compile multiple exe's so they have different data stores.  For my sub-panels, I don't need to use CCC since, as you pointed out, they will share the same CVT.

If I use VI server to call a VI remotely on the same machine, will that also share the same CVT?  I guess I can try that easily enough.

Thanks,

XL600

[BeCeGa]

Also you could distribute the plugins just as VIs with password. And load them through VI server. WHen you program starts in can verify all the VIs in the folder and load them. This way they will be on the same excecution context. You can still password protect the VIs.

Best Regards

[DowNow_]

Hi,

I'm using VI server. So my distribution challenge is to have a plugins folder that contains the top-level plugin VIs, and any subvis that are not already contained in the .exe. Right?

So I used LV source distribution to gather all the plugin VIs and subvis, and ** maybe this is my mistake. ** I see that the VIs are recompiled and there's many other subvis included that I know are already in the .exe.

One solution then is to lose the src dist. and manually identify top-level plugin VIs, and any subvis that are not already contained in the .exe. Then I could use LV installer to copy those files to a PC target. Any other ways to do this? 

cc

[xl600]

Can separate CVT's exist within the same application instance?  I have a standalone EXE which relies on its ability to create a private CVT and CCC client.  But I would like to also be able to call the top level VI of that EXE from within another application which also has its own CVT.  Both CVTs share large portions of the same CVT names.

If not, I can just call the exe.

Thanks,

XL600

[BeCeGa]

Hi xl600

   You can't have multiple instances of CVT on the same application space. Internally it is just a functional global.

As you mentioned if you need both of them running on the same machine you would need to run them as different exe and just call it or share information between them.

  This limitations is one of the reasons we developed Tag Bus, its is basically CVT on the wire, with that as long as we have 2 wires we can have multiple instances of the tables here. Also we have a complete framework Tag Bus Framework, that works based on this and allow you to create multiple engines each with its own instance of Tag Bus. For future projects you might want to look into this.

Community: Tips for Getting Started With the Tag Bus Data Framework

Best Regards

[xl600]

TBD looks like an exciting project.  Probably a bit too much for my current effort but most certainly useful for follow-on projects (Expecially if they start to get large and distributed).

Thanks,

XL600

[Mads]

Very seldom do I know all the tags up front. There will be (a need for) changes to the application configuration at run-time, and then we really need to add or remove tags without having to restart...Now I can understand that some systems will need to prioritize performance over flexibility here as changes to the CVT at run-time will cause jitter in the read/write access, but why hard-code that limitation into the API itself? Any users who do not want such operations to be allowed should just write their applications accordingly.

- One of the first problems I ran into when evaluating CVT for a recent project  was that there is no simple Add tag function - only the Create Tags.vi. That VI does not allow you to choose to keep old ones as they are, and just add new ones. If you do try to do that - you will either see it abort the second it hits an existing tag (which it should not as we still want to add the new ones) - OR, you can choose to overwrite existing ones. But we do not want to do that as their values are still fine. - Reading out all the old ones (no simple top level API call to do that, just for file dumps...for some reason) and then recreating the while table by feeding the old table with changes into the Create Tags function with "Clear Table" set to True would avoid the collsion error and replace an overwrite with a copy...but then we run into a race condition (readers of the tags might hit the period between the Clear CVT and the Tag Memory Add Tag calls within the Create Tags VI. Not good.

For removal we also miss a simple remove/delete tag function. Again - we can use Clear followed by New, but then we run into all the same problems as with the add tag scenario described above.

CVT has a lot of good features and great performance, but these small shortcomings a bothersome... The CVT is lighter and faster than NI's Dictionary Library (and there are subtle differences that makes CVT nicer to work with). GPower's VI Register solution is almost as fast as CVT, but amongst other things (use of variants instead of polymorphism in the read/write Vis themselves e.g.) its tag creation can actually too flexible; Tags are automagically created upon writes, which is not always ideal (its a nice option though, it would be cool to have that option in the CVT).  

PS. The low level functions of the CVT (which I would need to use if I wanted to replace the top level functions to bypass the issues) are not exposed on the palette so I suspect that we are not guaranteed to have them available or compatible in future versions...Or what is the philosophy there?

[smithd]

---

@Mads wrote:

but why hard-code that limitation into the API itself? Any users who do not want such operations to be allowed should just write their applications accordingly.

---

It wasn't a use case we saw a huge need for and its not so much "hard coded" as just not implemented.

---

@Mads wrote:

- One of the first problems I ran into when evaluating CVT for a recent project  was that there is no simple Add tag function - only the Create Tags.vi. ...Reading out all the old ones (no simple top level API call to do that..

---

Fair enough, I vaguely recall going back and forth on the overwrite behavior. Seems like the simplest solution (using the top level api) would be to take your list of tags, use the index lookup function to filter ones which exist already and then create just the ones which don't exist. The better solution would be to change the bool to an enum ("error on duplicate", "force new value", "ignore duplicates") or something. Would probably take all of 15 minutes to do if I'm remembering correctly, as its only used in one place.

---

@Mads wrote:

For removal we also miss a simple remove/delete tag function. Again - we can use Clear followed by New, but then we run into all the same problems as with the add tag scenario described above.

Delete is basically impossible in the CVT as written. You are allowed to fetch indices into the memory set and if you delete from the array, the indices are all wrong which would lead to bad behavior. It would only be possible to add this feature if we removed all of the higher-performance segments of the API. I mean yes, sure, technically we could maintain a set of "unused" elements and do some fancy stuff but (a) I think there would still be some race conditions (b) it would be slower and (c) the amount of memory used for each tag is so small I really can't imagine many situations where its worth the risk -- a few bytes for the data, a few bytes for the tag metadata.

---

@Mads wrote:

PS. The low level functions of the CVT (which I would need to use if I wanted to replace the top level functions to bypass the issues) are not exposed on the palette so I suspect that we are not guaranteed to have them available or compatible in future versions...Or what is the philosophy there?

---

I think its safe to say there is a non-zero risk that some of them could change in a future release (and I am not the one to make that judgement, since I am no longer the developer on it) but my philosophy would be that all of the core functions are FGVs and you should never expose a bare FGV to a user if possible. Something with a 10-element enum and 14 non-required inputs is not something a user should ever see. Its the right solution for performance reasons, but the wrong solution for usability.

I can't really speak to it, but for completeness its worth mentioning this:

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

If I remember correctly its kind of like a DVR based version of the CVT which supports the four core types+variants, and includes a timestamp for last update on every value. It looks like points are created manually 1x1 and can be deleted.