LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Stub out Error Cluster from Error Code.vi?

When I profile my application, I find that the biggest consumer of CPU time is the Error Cluster from Error Code.vi, called from a number of locked NI libraries.  How can I stub out this .vi, replacing it with basically a pass-through?  I tried creating a project specific .vi with the same name, and when I open my project all the project and vi.lib .vis used link to it, but they all come up broken and have to be re-linked, which I can't do in the locked .vis (I matched the ins and outs and connector pattern).  I can't edit the Error Cluster...vi directly, getting a message about the .vi being used by another application even with a clean start of LV and going directly to that .vi in the library (and I would prefer to not mess with the vi.lib version anyway).  Any suggestions?  Thanks.  LV 2011.

 

Matt

0 Kudos
Message 1 of 12
(1,733 Views)

If I open the Error Cluster From Error Code.vi throught the C:\Program Files (x86)\National Instruments\LabVIEW 2013\vi.lib\Utility\error.llb, the VI is locked. But if I open a new VI and place the Error Cluster From Error Code function into it, the code is modifiable, when the function is opened (double-click). I can save the Error Cluster...vi and the error.dll is updated. How is it at you, please?

Message 2 of 12
(1,727 Views)

In my LV 2013 I can open the .vi and save as or edit, as you describe; 2011 won't let me do that.  Interesting.  I will give that some more thought.  Thanks.

 

Matt

0 Kudos
Message 3 of 12
(1,713 Views)

Lets handle these questions in reverse order.

 

Error Cluster from Error Code.vi is shared clones re-enterant  So you need to work with the re-enterant original to modify it.  Opening the Re-enterant original from a clone is done with a ctrl+M or a double-click on the block diagram of a vi that is already in edit mode.

 

Got you covered ghi...?

 

Modifying a vi.lib member is not to be undertaken lightly!  (And that is an understatement!)  Matthew, I applaud your restraint!  

 

Especially this VI!  A large number of toolkits and addons and NI Device Drivers use this highly flexible vi.  Any change to the vi would force a recompile of all callers since source code is not seperated from the vi object.  Many of it's callers are locked and password protected so you cannot save those callers or make changes to them which, is exactly why NI Locked them!  to protect you from you (or the guy in the next cube without the same restraint)

 

HAVE I GOT your attention?  That thing you are playing with is a loaded gun!  put it down.

 

A quick peek over at the help file will explain why Error Cluster from Error Code.vi is appearing as a CPU hog.  It is shared clones re-enterant.  If enough clones are needed at the same time a new clone must be spawned and added to the clone pool and that takes time from time to time.  The trade-off is memory usage.  Overall,  perhaps, on some CPUs and for edge case usages, you could theoretically change the settings of that vi and get improved performance (If you had all the passwords for every caller so you could save the changes)  99.999.....% of the use cases you might just worsen your applications performance.  (I bet some brainiac at NI tested it)

 

To wrap up I'll paraphrase Obi-wan "This is not the vi you are seeking....(hand wave)"  Optomize elsewhere.


"Should be" isn't "Is" -Jay
Message 4 of 12
(1,706 Views)

If you have the LLB manager open it reserves your VI in a different appliation instance, therefore it is locked and no editing.  Simply close the LLB manager and you can whack away at that VI.

 

I doubt that the shared clone setting plays much of a role here, there are some deeper issues.   A rather amusing VI in a few ways:

 

ErrorCodeFun.png

 

In order to show the VI Title instead of the Name you Open a VI reference which is going to stick you into the root loop.  10 reentrent clones simply means 10 copies waiting in line for the root loop.  A non-reentrent version would simply have 10 copies waiting to run.  Minus the root loop issue, reentrency is the way to go, and on a desktop machine shared clones is typically quite effective.

 

It can't be a slow VI, look Trim Whitespace was inlined manually to avoid a performance hit!  In a loop maybe, but really, shaving off the overhead of a single subVI?  That's optimization.

 

But wait, all of that and much, much more is given right back by the use of Delete From Array to remove the first element of the Array.  Bad on so many levels.    Delete From Array is a data copy machine, and now you are doing one needlessly.  Array subset is your friend here, tells the compiler you are only reading, nothing to get excited about. Pull it outside the case structure, you are ditching the first element twice in the two branches.

 

Concatenating strings in a loop, also a recipe for fun.  Often there are ways to leverage Array to Spreadsheet string for better performance, or build a string array and then concatenate at the end.  Probably not a big deal here, how big are call chains really, but if you are inlining subVIs by hand then you should really be frying the bigger fish.

 

I find myself in your shoes fairly often.  Some clunker in vi.lib causes a bug or sluggish performance.  You either ditch the NI code and roll your own, or make it work on your machine but not others, or chalk it up to the cost of doing business.  I have tried on numerous occasions to suggest that all patches to vi.lib be made readily and freely available to all previous versions of LV that are compatible.  Let's say this VI got tweaked so it was a bit more performant for you, at least enough to be viable.  Then you could happily use the patched version in LV11, and if you went to a different machine you would simply make sure vi.lib was up-to-date.  These types of patches could roll out incrementally as needed, less need to cross your fingers that you won the CAR lottery with each new version of LV.  (I guess most lottery winners don't shell out $$$ to collect their "winnings" though).

 

After all that what would I do here?  I would wrap that sucker inside a disable structure (provide minimal functionality, like pass through caller name, code and error instead).  Then I would check the performance again.  Now you have a data point as to whether or not it is worth it to proceed.

 

Message 5 of 12
(1,689 Views)

Hi Jeff.  Thanks.  I really don't want to mess with the vi.lib Error...vi, for the reasons you mentioned.  I am willing to risk relinking the half-dozen or so protected .vis to a project specific Error...vi stub, if I can determine that I won't break anything else and I can link those .vis back to the original in other projects.  I think I can make that work.

 

This one .vi is using up about 4x the cpu time of the next on the list, even after allowing for startup, spawning, etc.  This is actually an RT application on sbRIO, but I don't think that makes a difference as far as the linking.  I have plenty of memory, just want a little more breathing room for the cpu.

 

Thanks for the insights on the reentrancy; never occurred to me to check.

 

Matt

0 Kudos
Message 6 of 12
(1,674 Views)

Hi Darin.  Just what I was thinking, wrap in a disable and pass errors through.  Tough part is getting the protected .vis to use the wrapper.  I am tempted by the same optimizations you mentioned, but really don't want to mess with it.  I don't need the functionality for this project anyway.

 

I took a quick glance at the 7.1.1 version, the only differences appear to be the execution platform conditional disable and the whitespace not being inlined.  Not sure why the platform conditional disable isn't taking; the target is RT on sbRIO, which I thought would take the Embedded case but my testing (with a similar case in a test .vi) indicates the Default case is being selected.

 

Thanks for the input.

 

Matt

0 Kudos
Message 7 of 12
(1,668 Views)

As long as you understand the risks and scope (I believe you do now)  Check the hierarchy to see which callers are locked and which are unlocked first.!  Its possible you can get enough CPU "Breathing room" by sucking renamed copies of the callers you can edit into your project and just blowing out the convert error with a simpler bundle error (Sure you'll lose some functionality but you don't plan on throwing errors anyway do you?)  

 

 

I'm thinking something like NI DCPower uses

!1-1.png

which I bet out-performs the snot out of error cluster from error code.vi

 


"Should be" isn't "Is" -Jay
0 Kudos
Message 8 of 12
(1,657 Views)

The main performance bottleneck of this VI is where it calls VI Server.  This was reported to R&D as a performance problem in CAR 384767, and the call to Open VI Reference was removed in LabVIEW 2013.  The VI should be much faster in the latest version of LabVIEW.

 

Chris M

Message 9 of 12
(1,632 Views)

@CMal wrote:

The main performance bottleneck of this VI is where it calls VI Server.  This was reported to R&D as a performance problem in CAR 384767, and the call to Open VI Reference was removed in LabVIEW 2013.  The VI should be much faster in the latest version of LabVIEW.

 

Chris M


Very nice Chris!  I will not check now but, the next time you pass by a peacock in the halls of the nidiface ask ..... does your work-around  use error rings?   To be honest I pulled the OPs source into 2013.   That CAR needs to go on a specific list IMO.  there was no change to the source code

 

 

Some R&D discourse would be appreciated!  A nugget from someone, or a white paper<hint> would help aliviate developer pain.

 

----Jeff


"Should be" isn't "Is" -Jay
0 Kudos
Message 10 of 12
(1,619 Views)