Götz Becker

Is something like this: allowed if I want to reset the version number together with the history? The direct write access to the library version using VI server is probably not allowed on purpose?!?

This is what I did and do regularly (ignoring the mess this leaves in the SCC )... It did not fix it.

On the main VI. All VIs are therein placed as normal SubVIs and one as strict VI reference. A side node: If build with debug enabled, the exe did run, but a normal build with all FP & BD set to be included did not run (my first idea lend towards a missing FP).

One of the first things I did was Crtl+Shift+Run for a rebuild. This issue is currently under investigation with NI Germany.

I still can't find any info about LV2010SP2. Or did you mean SP1, with this I already work?

Oh, I didn't knew about SP2... I'll try to find it. About a problem with class properties in LV2010 (Known Issue ID 246263) I did know... but as always I try to avoid x.x.0 releases. SP1 should have this fixed, but maybe I see some other bug!?!

Hi, does anyone knows about problems with dynamic dispatch accessor VIs for property nodes in general? I spent about a week hunting down the cause of application freezes. In the end some LVOOP property nodes just never did return and the OS flagged the app as "Not Responding" (LV2010SP1). I generated all my accessor with the dynamic dispatch wizard/template by default, a bad choice at last. After switching all to static dispatch the app finally works again.

The problem then is, that I could choose between blocking the program at every unkown object while getting the FQN (including high cpu load, visible spinning mouse cursor wheel) and additional application startup time of at least 30++ seconds by preloading/caching all lvclasses/FQNs (timing after limited testing, 65-80 LVOOP-based commands). I guess I'll stick with the flatten/parse version until LV gets a real object to FQN primitive.

Thanks for another idea! Unfortunately this approach is to slow for my use case. My first benchmark showed about average runtimes of about 300ms for the file/project api and about 0.1ms for the flatten/parse version. Since my goal is to analyze every message object sent inside the application, speed is very important.

Thanks, but that only gives the FQN for the class of the wire, not the info for the current actual class. fqn_test.zip With the GetLVClassInfo.vi approach, I guess I could include a must override VI in every lvclass in which itself the GetLVClassInfo.vi gets called... but then I could just return a string constant since I know the value at edit time.

A small speed improvement (I've done very limited testing/benchmarking with this): Kudos to Daklu, I found the neat code snippet for getting the default value from a .lvclass somewhere in the LapDog source.

I really like the idea of a more callback oriented UI handling in LV, but currently it's unusable. LV just hangs/crashes on filter events CAR: #42806 The other caveats are that you have to check if the FP of the control to un-/register is open. Unregistering the callback to a control with its windows closed leads usually to a VC++ runtime error "R6025 - pure virtual function call" at application termination. During development and "abnormal" program termination aka Stop-Button often the callback VIs are blocked for editing because of running/"reserved fo run" reentrant instances of them.

I was very scared as I opened the Chat project the first time. The possible usage for distribution malicious code is really scary. On the other side, automatic launching of some helper VIs when I open a project might be a nice feature (e.g. forced update file state when working on a slow connection to a Perforce server, where LV-SCC integration is sometimes just unusable) Thats why I want to understand how this works and what the load triggers are. After I saved all VIs in the nutshell (they were not flagged as recompiled/edited) the auto-execution did stop in my machine at work. The .lvclass and .lvproj files didn't change, the VIs of course did.

Very strange... I just tested both versions on a different machine and now both show the auto-execution. My first version didn't show the behaviour at my home machine.

Hi again, after random edits to my nutshell I finally got one version that runs the Init.vi at project load. Still I haven't found what triggers the execution. I guess I have to invest more time to get behind the logic. xcontrol+lvclass_v2.zip (LV2010)

Hi all, I recently found some interesting code at the german labviewforum.de. Basically it looks like a not so funny prank. LV-Chat The included project starts an embedded VI after opening the .lvproj. Warning: I am not 100% sure if this is all harmless. As far as I can tell it displays some dialog boxes, writes a virus test pattern and opens notepad.exe with a temp file. My current guess is, that the combination of a Xcontrol and the way LV loads lvclasses leads to the execution of the Init ability at load time. I tried to copy the concept in the attached file xcontrol+lvclass.zip. But the Init.vi in my project doesn´t get executed before I manually open a VI that uses the XControl (this is of course the expected behavior). Anyone has an idea what else is necessary to get this auto-execution at load time?

Code Repositry

Thx for the clarification with some behind the scene knowledge . For doing real benchmarks on my own, I would have to convert some real-life code to LVOOP and compare the results... too bad I just don't enough spare time . I guess I have to convince my management to give me free (payed) time at every major release of LV to play with new features .

Thx for the quick reply. Same size as the class itself or same as self+parent(s)? I guess dynamic dispatching on FPGA is then some hierarchy of hidden case contructs in the background? (too bad all the intermediate .vhd file are encrypted these days )

Hi, I just played a little with LV2009 and the FPGA module. I even could compile a small VI with LVOOP in it. Does anyone know some examples for LVOOP on FPGA? Or even benchmarks of the possible hit on size and speed of such code? Currently I don't have access to our cRIO so I can't test myself. Greetings from Munich Götz

Only 30% surprises me. Just hitting the deploy button takes currently about 2-3 minutes and after a hopefully successful deploy (sometimes I get just the message "Deployment completed with errors" without any indication what went wrong, restarting LV usually fixes it) it takes additionally 2-3 minutes until LV is aware of all VI states and is usable again. Using probes often leads to a local LV crash which means loading everthing again (opening the project alone takes about 2 minutes with SCC disabled). Memory leaks usually not a problem and if we suspect something we log the CPU/Mem status over night in a TDMS file. Our PXI targets are 8106/8130/8108/8110 and the development machines are all dualcore notebooks. Götz

QUOTE (Götz Becker @ Mar 12 2008, 02:05 PM) We recently started to get strange errors when using the Inplace Variant function. Just a word of warning, if you get "???" errors out of the inplace error cluster, replacing the Inplace with normal Variant functions (e.g. rightclick menu "Remove In Place Element Structure" is enough) fixes it. The problem is reported, CAR not available yet. Edit: CAR #164718 Edit 2: Pharlab (PXI) RT 8.6.1

Hi, how much more development time do you usually expect when planning a LV RT application in comparison to Windows? My current guess is about a factor 3-10. Included all the little extra times of deploying, rebooting (restarting or crashed LV and/or LVRT), extra code for debugging e.g. reentrant code, extra test time etc. Greetings Götz