From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.


Showing results for 
Search instead for 
Did you mean: 

Current Value Table (CVT)

Thanks for the reply.


1) Not using IO Server, using ModbusTCP Function Block Pallette(s).

Labview is 2011.

NI RIO is 4.0.0

I implemented case statements for the ModbusTCP read/writes such that if a slave returns any error or does a timeout, the timed loop dt is changed until a succesfull TCP create happens again...In any case CPU utilization is not effected when slaves drop in/out. I watched this closely in NI dist. syst manager as I changed the config in my inverter - nothing untoward happens - and all other slave coms were built upon the inverter comms.

2) OK - but network publishing is not needed - I will look to reduce scan engine down a bit 50ms should more than suffice. Good tip.

3) I am using timed loops.  Fastest loop speed currently is 100ms and this is step with a power quality meter that has 3 data points samples at 6 cycles. 6cycles/60hz = 100ms. Remaining loops are 250ms to/from inverter (this is the highest priority loop) and 250ms to/from an HMI. These are reasonable and prudent values (I could slow down the HMI as the SQL logging is no faster than 1 sec). Then 1000ms again from the PQM for 60cycle data.


I am leaning towards keeping the shared variable engine as well. The I/O alias is of less use to me as I must pass the Raw I/O data (DBL) through EU scaling that I wish to be adjustable at runtime, and during that scaling, I change them to SGL as the extra resolution is not needed for the applciation and my ModbusTCP slaves handle 32 Bit floats - not 64bit floats.



0 Kudos
Message 31 of 164

"I implemented case statements for the ModbusTCP read/writes such that if a slave returns any error or does a timeout, the timed loop dt is changed until a succesfull TCP create happens again.."



This sounds like it could end up being dangerous. If i'm reading this right, you increase the loop period until successful comm is established:


1) What happens if communication is never established?

2) once you have increased the loop period, you are now stuck with a loop that takes longer to execute. I would prefer to benchmark how long TCP communications take, then add a safety margin (30% maybe?) and make that your loop period. If you are getting consitent timeouts, it could be a sign that something is wrong in the network, or the Modbus Slave. That information could be lost if you keep increasing the loop-rate (allowable timeout value)


LV 6.1 to 2015 SP1
0 Kudos
Message 32 of 164

We should probably move this discussion offline until CVT content returns...


I PM'd my reply.


0 Kudos
Message 33 of 164

@S1ack wrote:

CVT vs. Shared Variable Engine


What would be a 'pro' argument for implementing CVT vs using the shared variable engine? Because as far as I can tell they are a dead heat in CPU usage.


CPU Utilization:

Entire Project SVE w/NP: 99% vs. No NP = 31%

Single Slave SVE w/NP: 36% vs. No NP = 18.8% vs CVT Implemented for that slave = 18.5 %.

All were deployed as 'run as startup' to avoid front panel coms effecting measurement.


You are correct that the CVT is on par with Single Process Shared Variables (SPSV = SV without NP) performance wise. One benefit that the CVT provides is that you can define your list of tags/variables at run-time (read the list from a file or create it dynamically) and that you can access tags/variables dynamically by name. This is not possible for SPSV. The varibale API does support dynamic name-based access for NPSV, but not for SPSV.


authored by
Christian L, CLA
Systems Engineering Manager - Automotive and Transportation
NI - Austin, TX

Message 34 of 164

@HMalik wrote:

Hi, Could someone please tell me if there is a way to print all in TAGS in the tag editor for documentation purposes. If I open the Tag file as an XML there is a lot of garbage. Thanks

If you use the File Load function to read the tag configuration file into LabVIEW for use with the CVT, you should be able to parse through the tag array and write the pertinent information about each tag to a string or text file.

authored by
Christian L, CLA
Systems Engineering Manager - Automotive and Transportation
NI - Austin, TX

Message 35 of 164

Thanks, thats exactly what I did and I was able to read tags, data type and description and was able to write it all to a text file. Thanks again 🙂

0 Kudos
Message 36 of 164

Today was my first look at the CVT library and so I began by viewing the examples.

When running CVT Index example, I noticed the Remote Index indicator of the CVT Index did not increment.


Viewing the diagram I found an error and wanted to share so the next release might include the correction.


This is the diagram as found:



This shows the required change:



I hope this feedback is useful.





Tech Advisor - Automation
LabVIEW 5.0 - 2020
0 Kudos
Message 37 of 164

@rwunderl wrote:

I have been using the CVT at the core of an embedded controller test project for a few months now, and I just found what I consider to be a flaw in the CVT design. I have several different controllers that I want to test, each with a different section in the Tag Configuration file. So far so good. The user selects the section according to the controller that needs to be tested. Awesome. I had set up my program to load one of the sections, run the tests, then end the program. Still good. I now tried to loop the main program so that I can exit one control test and load another without having to end the main program. PROBLEM!


The problem is that the CVT StaticRead VIs use that damn thing called First Call? that returns True the first time the subVI is called and does not reset until the highest level caller is "idle" (has ended). It took me awhile to figure out that this damn thing was causing the StaticRead funtion to use "outdated" indices in the CVT memory block and loading bogus data for all of the values that I reference "statically" throught he CVT StaticRead VIs (the ones with the same static name across different sections of the configuration file).


I would recommend exposing an "Initialize" terminal that is OR'ed with the First Call? primitive that resets the static index link to the data in the memory block. That way, the user can decide when to update the reference. I have made this modification to my CVT functions, but I would expect others to experience similar problems if they tried to do a similar thing.


I think that using First Call? is, in general, always a terrible idea. Especially when it is used as the only means to initialize something. In my code, I always have a manual initialize input (or a separate init VI, as appropriate). I can see how using the First Call? prim could be a good way to force an update if the coder fails to wire the init terminal, but it should never be the only means of initialization.




CLD, LabVIEW 2011

I have encountered some strange behaviour using the static API as well. I am debugging an application (in LV2011) using the CVT static API which I am deploying to a compactRIO. Deploying the application to the target in interactive mode, it seems like a similar problem is occuring. I start and stop the program,  but using static read API gives seems to give "random" values when I read. Doing a replace all with the standard API stopped the problem. I am trying to figure out exactly what part of the static API is causing the problem. Maybe the already deployed VIs of the CVT are holding some unitialized data??? Very puzzled. 

Message 38 of 164

Not sure what the issue could be, but keep in mind that your code is compiled differently for the PC and cRIO targets. As such, I never use User Lib for my projects anymore. Things like the AMC and CVT and STM packages need to have a presence (including some of the same VIs) on both the PC and cRIO, which compile differently. My solution (even though it is terrible from a source code control aspect) is to copy all the libraries that would normally be in User Lib into my application's project folder under BOTH the PC's SubVIs folder AND the cRIO's SubVIs folders. This ensures that the file is not compiled for one target and then downloaded to the other. Remember that the same physical file in User Lib would be shared between two incompatible targets.


In other words, I always have a folder structure like this for my subVIs:






And the User Lib stuff just gets thrown in there too:





Again, this may not be the cause of your problems, but I learned long ago to physically separate the files that are common between incompatible targets. You can tell if the file is incompatible if you drag it from one target in the project to another and then open it, if it has the "modified" star, then it's probably because it needs to be recompiled for that target (and is therefore incompatible). You can also check the changes log from the save dialog to see if that's the case.



"Computers are useless. They can only give you answers." - Pablo Picasso
Message 39 of 164

thank you Rwunderl for the good advice on managing my files. I often hit the run arrow holding down shift+ctrl to recompile the entire hierarchy of the VI I am going to deploy under the target if I am going to run in interactive mode. Do you project libs to store your VIs for separate targets? Now that I have the hang of project libs they have really helped me in my project management. I put VIs that normally live in user.lib (like open G vis) into a project lib in my source controlled directory. This project lib is included in my project. The instead of being linked to the the VIs in user.lib, the project VIs are linked to the VIs in my project lib. That way SCC get all the dependencies and LV doesn't get confused by multiple VI copies.


 I think it might have been using the static API incorrectly when I posted that message: I had an array of tag names, and was autoindex through them with a for loop, with a static api write inside the loop Smiley Embarassed. This doesn't work because the static api is just the index api, except that the index corresponding to the tag name is looked up of first call and stored in a shift register!


I then started using index API, writing action engines where the listof tag indeces were looked up on first call.


with CVT you can save yourself time if you know what you are doing, especially if you are dealing with systems were the number of separate sensors inputs, modbus registers of slave devices etc exceed 100.  But I would caution that by using these you are breaking dataflow and you will, given a large enough program, even if you are careful, set up a race condition for yourself by inadvertently writing to a tag from two different places. Finding and debugging those is not fun. 


When you get to such a large number of variables, originating from several different producer loops, and many other consumer loops each requiring different pieces of data from those producer loops, CVT definitely beats trying to move that data around using the classic typedef enum + variant cluster queues.   


Looks like the CVT board has been relatively quiet.. is NI planning on coming out with a new and improved version?

Or has CVT been effectively been "obsoleted" by shared variables, which from what I understand can be looked up by name if they are network shared? I do like this API. It might be neat to improve speed of the by name lookup with variant hash instead of index search.


0 Kudos
Message 40 of 164