Components

cancel
Showing results for 
Search instead for 
Did you mean: 

Current Value Table (CVT)

Ferdinand,

 

I agree with Jim, you need to benchmark sections of your code to figure out what section of your code consumes the most resources. In the project that you posted above there was no RT VI. Is there a VI running on your cRIO? If yes, can you tell me which VI is it in your project? 

If you update your shared variables manually using Distributed System Manager do you get faster update times? (vs when HMI is being updated by cRIO)

Another way to reduce the CPU consumption on the cRIO is to remove some of the unused software (like LabVIEW webserver) from the cRIO.

Sev K.
Senior Systems R&D Engineer | Wireless | CLA
National Instruments
0 Kudos
Message 61 of 164
(8,856 Views)

Sev K.

 

All the VI's are running from the cRIO. In the file that I upload they are under My Computer since I am running the application from there in order for the machine to run properly. The main vi is "PAC.vi", that one call all the other vi's. On Monday, I will try to use the trace toolkit to benchmark the code and will post the results here. I will check the softwares installed in the cRIO and uninstall the onex not needed if any. Thanks a lot for the advice.

Ferdinand Martinez
FMO Automation LLC
0 Kudos
Message 62 of 164
(8,850 Views)

Hey Ferdinand,

 

I finally got a chance to look at your code and have a few points of feedback. Some may be workable right now, some may not, but I will leave that to you.

 

1) I noticed you already have a number of single-process variables configured. My recommendation would be to continue changing anything possible over to single-process, especially for frequently accessed items. The execution time difference is very large.

2) Buffering and queues will not change the access times above too much, but it requires additional effort on the part of the variable engine, so turning these things off if you don't need them is a good idea.

3) NP-SVs are, by their nature, going to have some delay and that delay can't be controlled very well. If you need to have more immediate, manually-performed updates, you could use something like the CVT/CCC.

4) Data communication in general: I recommend trying to include multiple methods, because you probably need them. When I say methods, see pg 50-51 here: http://www.ni.com/pdf/products/us/criodevguidesec2.pdf

In your case, it looks like you have a ton of loops that are waiting on the value change of a boolean from false to true, at which point it takes some action. This is basically the definition of an event/command/message. For you, at this point, it would likely require a painful rearchitecture, but it is something I would recommend beginning to look in to. A very good example of this is the "LabVIEW FPGA Control on cRIO" or "LabVIEW RT Control on cRIO" sample project. This sample project contains both a message-based communication system (queued message handler like AMC, sent via a connection manager which uses network streams) for infrequently-updating information--like your booleans--and a tag-based communication system (shared variables) for continuously updating information. Moving from a polling architecture to an event-based architecture for slowly-updating information can give a huge performance boost. For example, instead of Start, Stop, Alarms.vi continuously polling to see if one of those events occurred (and they are probably occurring very infrequently, is my guess), you can sit at a "dequeue element" with an infinite timeout and wait for one of these events to occur. Once it occurs, it can take appropriate action. It also prevents you from missing any events (meaning you can eliminate some of that logic where you reset the alarm state).

5)I notice you have a VI, inside of a loop, which does this in many places:

speed.jpg

This by itelf is very expensive. Here is why: First, you open the file. Then, you read the whole file and load it into memory. Then you parse every single key-value pair out of that file (this parsing is robust but very slow). Then, you write a value into the table you loaded into memory. Then you reform that table of data into a file. Then you write your data to the file. Then you flush it to disk. Then you close the file. This appears to be happening as much as 5 times per loop. There is *no* way this is happening within your 100 ms timeframe. You should open your file during initialization and write to that fixed reference from the appropriate loop without having to reload everything.

 

Thats all I have for now. Hopefully it helps.

 

Thanks,

Daniel

Message 63 of 164
(8,830 Views)

Daniel,

 

Thanks for taking the time to look at my code, I know there is a lot to look over there. As you mention, I will start to look at different methods and check what can I improve taking in consideration the required time for the change. About the screenshot that you make reference above, it's true that I have it in a loop, but also inside a case structure and only will execute when the operator press a determined button on the HMI. Probably as you mention this is not the best approach, but is not like the code will execute every loop iteraction. I will also take a look  to the document that reference and make a research on the "AMC" that you mention. Thanks for the support, your advice look like another way to take some load from the processor. I feel that if I am able to compile all the sugestion that you guys make me I will be able to run smoothly from the cRIO without the need to upgrade it. But I am still a rookie and it will take me some time of research and learning to acomplish it.

 

I couldn't benchmark the vi's yet with the trace toolkit, yesterday the machine was shouted down to send some components to calibration and until thursday or friday it will not be turned on again, so I still have that task pending.

Ferdinand Martinez
FMO Automation LLC
0 Kudos
Message 64 of 164
(8,811 Views)

Hello,

 

I am using the CVT for transfering sequencing information from the HMI to the RTOS in a 9081 + 9144 chassis's. So far the CVT has worked great but now I am noticing that some data is not getting updated from windows (HMI) and the RTOS. Specifically I am updating my CVT tag, which is an enum string and then using a STM message to tell my sequencing loop to begin testing. The loop executes but the CVT tag always stays at its initial value. So it appears to me that the CVT table is working well for RTOS to HMI but is not working for HMI to RTOS.

 

I have quite a bit of code so I was going to see if someone else has worked through a problem like this before I post some code on here.

 

Thanks,


Eric

 

more info on project: Labview 1012+RTOS+FPGA+PID kit etc. I am using STMs, CVTs, for process communications; Qeues, and TCP to communicate between RTOS and windows.  I also recently ran into a problem where a different RT OS behaved differently and am wondering if this is a similar issue. I upgraded from a 9074 to a 9081 and the RTOS's (Vx to pharlap) are different enough to cause compatibility problems. As for myself, I have used labview for several years but am just getting past the DAQmx type programming and learning to do it the right way.

0 Kudos
Message 65 of 164
(8,734 Views)

Hey Eric,

 

Based on the description, a few things come to mind that may or may not be helpful.

-First off, it sounds like you are reproducing the functionality provided by the CVT Client Communication library (http://zone.ni.com/devzone/cda/epd/p/id/5328), and I wanted to make sure that you were at least aware of that code.

-You also mentioned the use of an enum tag in the CVT. I don't personally know of any problems with enums in the CVT, but I can say that the more recent versions of the CVT have deprecated that functionality. I'm not sure if that was just because it was not useful, or if there were bugs, but it is worth noting.

 

 

If neither of those help you, then my next suggestion would be to create an extremely simple version of your code to reproduce your problem. I'm guessing that in the process you will figure out what the issue was, and if you don't then you have something that is easier for others to troubleshoot 🙂

 

Thanks,

Daniel

0 Kudos
Message 66 of 164
(8,720 Views)

Thanks for the Reply Daniel and I apologize about the delay.

 

After performing more testing I realized that trying to squish an enum control with text to a string is not possible. My first fix just used a number instead of text string to correspond to each case, but this was difficult to add new cases. Now I just use send the message through an initialization cluster that is flattened to a string.

 

Best,

Eric

0 Kudos
Message 67 of 164
(8,657 Views)

@Etarkleson wrote:

"...trying to squish an enum control with text to a string is not possible."



Eric,

 

If I hear you correctly, you say you cannot convert an enum into a string, but this is actually a simple matter. Converting back is also possible (see the snippet below). You should always typedef your enums, of course, which this quick example does not show.

 

Enum to String

 

Hope this helps,

Richard

_______________________________________________________________
"Computers are useless. They can only give you answers." - Pablo Picasso
Message 68 of 164
(8,653 Views)

Thanks Richard!

 

I was trying to use a flatten to string, without any luck.

 

Eric

0 Kudos
Message 69 of 164
(8,644 Views)
I would like to use CVT (version 3) as the tag repository of a Labview RT control/logging system that communicates via OPC UA with a Siemens PLC, Via Profibus to electric servo drives and Over Ethernet with a host Labview application running on a PC.

I have around 4000 to 5000 tags in the control system and have created some test code to import tags from MS Excel.

However to efficiently communicate via OPC UA, ethernet etc. I need to get data changed information from the CVT table so that I can write changed tags (or tag groups) only to OPC UA, rather than the whole table.

Can the CVT table be modified to signal data changed events?

Can CVT version 3 interface with the existing CCC library?

The CVT version 2 library was quite a comprehensive solution which included a tag editor, tag read/write vi's, communication library and logging. Are there any plans to do this for CVT version 3? ( I would prefer NI to officially go this route, rather than persist with shared variables)
Message 70 of 164
(8,322 Views)