Current Value Table (CVT)

[Mads]

---

@smithd wrote:

---

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.

---

One small step for the CVT, one giant leap... 😉 

Deletes would require a full reinitialization sure, but it could still be included as an option to do it on the fly, and you could control access to avoid race conditions (read operations halted while the values are uncertain). If performance is more important than having run-time configurability the developer can always choose to not provide the option in his application.

Thanks for the answer and tip. I'll check out the Point Value Map...and put the above mentioned CVT modification on my wish list 🙂

[Mads]

BTW: The Dictionary Library has much of the functionality I am missing in the CVT. Its performance looked very bad at first, compared to the CVT, but that was mainly because it has debugging enabled by default. I posted a performance comparison of many of the comparable options available (might be useful for other LV users) on their discussion page here.

[carrasquel]

Hello Mads, I have been following up all your comments about the CVT and alternatives to this library, and I see that the functionalities "missing" in the CVT would sacrify performance, and a lot, specially in the case of creating API o Layers on top of this one, for instance  CDL and CCC, mainly because just knowing on what specific tag to access you can then access to it by its static index, function available in the CVT Palette. Recently I created an API of OPC Comm on top of CVT and I found that using the static index Write and Read, applications can have really high performance for higher number of tags. Perhaps you may want to compare using a test like this, and propose those original coders or do it by your own, API for datalogging and tags over TCP/IP with those libraries, wich CVT already have them with CDL and CCC.

Another thing, it seems that Dictionary Library leaves those developer with older versions of LabVIEW out of the picture, best regards.

[Mads]

The CVT is very fast to begin with, and dynamic read and writes will cache the index for the last given tag, so the absolute difference between dynamic read/writes of a static tag vs. static read/writes is extremely small. The static calls could, like the dynamic, also monitor the reset counter, making it viable to do dictionary changes without breaking the functionality (this would shave off some of the minute difference but not all). 

Much of the value of CVTs/dictionaries come from the ability to do dynamic access. If you really do not have a need for run-time reconfigurations of the tags I will agree that there is still much value in not having to recompile (if the alternative was hard-coded variables...), but then again if such tiny performance gains we are talking about here are really that critical, the chances are you might need the extra performance of hard-coding variables after all...;-)

[smithd]

---

Mads wrote:

Much of the value of CVTs/dictionaries come from the ability to do dynamic access. 

By my old benchmarks the fast lookups are something like 100x faster (maybe more, this was like 4 years ago now) than anything requiring access to the variant lookup. The fast lookups are what I've used almost exclusively. They aren't hardcoded, they are loaded from a configuration file when the cRIO boots and used in a stable configuration from that point forward, generally with the usage mentioned by carrasquel. In this situation, using the CVT as the abstraction layer between different tag-based protocols, having the fastest possible data access is very important and reconfigurability has almost zero importance.

[carrasquel]

I agree with Smithd, I'm kind of confused when Mads says about tag creation at run-time, I use the API at run-time loading the configuration from a XML file, and if this configuration changes, well I make a halt on the loops and states machines execution and reload the CVT (Stop and Run functions of the CVT API again), this takes some time (about 200 to 400 ms I believe) but it can be achieved, so it will depend on the control philosophy, PLC (some of them) can be programmatically changed at running state, and some systems need to reboot, so choosing technology will depend on almost everything from hardware to software implementation

[Mads]

---

@smithd wrote:

---

@Mads wrote:

Much of the value of CVTs/dictionaries come from the ability to do dynamic access. 

By my old benchmarks the fast lookups are something like 100x faster (maybe more, this was like 4 years ago now) than anything requiring access to the variant lookup. The fast lookups are what I've used almost exclusively. They aren't hardcoded, they are loaded from a configuration file when the cRIO boots and used in a stable configuration from that point forward, generally with the usage mentioned by carrasquel. In this situation, using the CVT as the abstraction layer between different tag-based protocols, having the fastest possible data access is very important and reconfigurability has almost zero importance.

---

What do you men by fast lookups? The way the CVT works now (not 4 years ago) its lookups are super-fast because they are only used to find the index of the data. The data itself is not stored in a variant (which it was at an early stage of the CVT). AND the lookup is skipped if the value you are requesting access to is the same as on the previous call (static tag). There is an even faster mode where you hard-code that this is a fully static call (meaning the tag to be accessed will never change at run-time), but the difference is very small, its a factor of around 1,3x - not 100x (and even this mode could be changed to accept run-time changes to the table if needed without much of a penalty).

[Mads]

---

@carrasquel wrote:

I agree with Smithd, I'm kind of confused when Mads says about tag creation at run-time, I use the API at run-time loading the configuration from a XML file, and if this configuration changes, well I make a halt on the loops and states machines execution and reload the CVT (Stop and Run functions of the CVT API again), this takes some time (about 200 to 400 ms I believe) but it can be achieved, so it will depend on the control philosophy, PLC (some of them) can be programmatically changed at running state, and some systems need to reboot, so choosing technology will depend on almost everything from hardware to software implementation

---

I understand that you guys are using this for relatively static programs (controller type where reconfigurations are rare and can/should be done in a very controlled (but interruptive) manner).

The changes I propose do not change any of that, it just makes the CVT a better solution for use in more dynamic applications where users might for example add or remove devices regularly, which in turn means that there are new tags to include/exclude in the CVT. It is fully possible to add this functionality as an option in a way that will make such table changes happen with minimal disruption to a *continously* running application.  All processes in the application can access the values they want with no risk of hitting a temporarily empty table due to reinitialization for example. Such functionality will *if used* cause jitter, but that is perfectly fine for many applications, so the CVT could have it available.

So this is about making *more* people happy, not about removing/ruining anything for those (like you guys) who like the CVT (only) as it is.  If it does not happen then that's fine. Personally I can always use one of the alternatives instead, or develop my own variant. 

[DowNow_]

Hi,

When you add or remove devices regularly, how does your UI change to view the new tags? Do you just have a big table showing all tags or subsets of tags? Adding the new tags to datalogging and an alarming processes seems all automatable, but do you have to add new HMI displays too? What design do you have for that? Just wondering, thanks. 

cc

[Mads]

A bit off topic, but OK:

New devices just show up as nodes in trees, multicolumn listboxes, menus, trends, modbus registers, OPC tags etc and if a user (mostly remote client applications) want to access any of these it will instantiate an appropriate GUI component (or separate client) for that device/task. These migth access relevant tags that might be held in a CVT.

So the HMIs we have are semi-generic and auto-scale. It is not like in a DCS-system for example where you have very customized displays identifying devices on a plant layout (which I suspect is closer to what you have just by the fact that you refer to it as the HMI...). To do that you obviously need some manual redesign too. You can make a run-time editor for such a thing but often the easiest way to do it based on how LabVIEW works is to use the LabVIEW IDE for it - manually and/or with VI scripting. Designing the HMI as a set of plug-ins or clients can make it possible to change/extend it on the fly, without having to recompile the core of the application or even restart it.