i2dx

My problem is the following: It's really slow, if i read more than 30 values in 100 ms my CPU works at 100 % !! I think that's come from the active X mechanism, is there something i can do to improve my program, or should i use another technologie ??? What are the others solutions.. i think dlls will not run faster ... 

do you write into an Excel table via ActiveX ? that is really slow, and there is nothing you can change about that, except buying a faster CPU.

if you want to write the values into a file on disk and evaluate it with excel later you should think about writing a *.CSV file ?

best regards,

cb

You can add, duplicate, and delete case frames but there does not appear to be a way to sort/change/reassign them.

4045[/snapback]

that's what i experienced, too

Is it possible to create (or simulate) an MDI in LabView?  I would like to have a parent VI that handles common chores and some number of identical child forms for simultaneously testing multiple DUT's.

I have done this previously in VB and it was a very effective interface solution.  I would like to duplicate it in labview.

Any ideas on setting up this front panel architecture would be appreciated.

Kirk

3531[/snapback]

maybe its possible, if you use subpanels, but it will never be se same like in VB, and it will be verry diffucult, because you have no framework like in Visual Studio, but have to develop it all on your own ....

best regards,

cb

Try Help-->Find Examples-->NI Example Finder-->Analyzing and Processing Signals-->Tone Measurements

maxbe some of the examples there may answer your question ...

Michael,

sorry for the inconvenience with the large images. if you can manage that i will edit the original post and use attatchments. now i am unable to edit because you moved the topic ?

----

Do you mean that if you do NOT call a "Sub-VI" with an event structure in it, everything works fine?

Exactly. This is the problem, and i can not figure out, why this happens. MY guess is, that i have found a very nasty bug in LV OR i am to stupid. In my experience strange behaviour like this (especially if you know that it is working in other projects) is either a very very very stupid bug in my software or a very nasty bug in LV ...

You guess right, i do not split the user event. In fact i dont use it in this project. It's part of my project template and i did not remove the user event till yesterday, but that did not solve the problem anyway.

finally i have removed the subpanel in this project and do it the "old style" with pop-up SubVIs, but i still would like to know what's went wrong ...

best regards,

cb

In order to build a windows application, you need to acquire a copy of LabVIEW Application Builder  from National Instruments for your version of LabVIEW ($600 ish or so?). 

Also, computers that will be running your EXE version of software will have to have the appropriate version of the LabVIEW Run Time Engine installed.

3390[/snapback]

maybe you should have mentioned that you can build an installer package of the vi which allready contains the LabVIEW Runtime Environment (LV Runtime Environment is Freeware ...) with the Application Builder.

If you don't want to use an installer but only the .exe you have to ensure that the LV RTE is allready installed on the target machine. the application builder reminds you of that after finishing the compilation ...

best regards,

cb

(tell me if i am a "know-it-alls" )

thanks for the help

unfortunately this did not help. the control terminals are in the event structure, and i dont need the value but only the event on the latching boolean (to start an action ...)

the strange thing is: one of my former co-workers has build a large application (1000+ vis) based on subpanels / multiple event-structures and did never experience such problems. unfortunately i can't show him the code, because he is working for a competitor now.

best regards,

cb

Hi Folks,

i have a problem using multiple event-structures with subpanels. to be more precise:

i have a main VI with a subpanel in which several VIs are called for different tasks. These "Sub-VIs" are called via VI-Server (Reference --> set Controls --> Run VI [wait until finished: FALSE, auto dispose Refnum = FALSE]) and terminate themselfes. I have allready checked if they maybe do not terminate correctly before unloading from the subpanel, they are terminated.

the problem is:

the event structure in the main VI misses events:

i have 2 booleans and a cluster of 6 booleans on the front panel of the main VI and the events on the single boolean controls are not recognized by the event structure (even if there is a allready terminated sub-vi without event-structure in the subpanel) after calling a "Sub-VI" with an event structure in it. on the other hand, the events on the booleans in the cluster are still recognized.

an easy way to "fix" this problem would be to drag all boolean controls into the cluster. But i would prefer to know why this happens.

If anyoune knows what's going on there, please let me know. If you need some code examples, i have uploaded some screenshots to my homepage. i cant show you the complete code, because the project is very large. if you need more information, please let me know

the Main VI (Queued State Machine)

running a "Sub-VI"

Main-Frontpanel the Buttons "Einstellungen" and "Ende" arre the missed ones

I just replied, but it didn't seem to register so hopefully this isn't a duplicate.

Is there a reason most of the queued state machine examples presented here use strings to refer to the state machine case, instead of typedef'd enums?  It would seem a typedef'd enum would be easier to manage, and couldn't result in an invalid case.

3305[/snapback]

i prefer typdefed enums, simply to eliminate the possibility of mis-spelling ;-). My experience is that the "most used way" is not allways the best way (what ever best way does mean ...)

but it does not really make a difference, you can use numbers if you want. i think it's just a "oppinion" and a kind of approach what is "perfect code"

best regards, cb

P.S: where's the limit for a "large application" from your point of view ? 200 (self-written) VIs ? 500 VIs ?

I use LabVIEW to create fully automated Test-Systems in the Automotive-Industries, eg. end-of-line testers, development-test-systems, laboratory test rigs, ect ...

most of my software contains: Hardware IO (DAQ, DAQmx) in 99% of all cases with National Instruments Hardware, Database Connectivity, etc..

currently i am working on an ECU testing system (since 3 month, time left: 2 month)

i think they are both very usefull.

if you want to launch a tool on a frontmost VI the App.MenuLaunchVI is the best method to get the reference.

if you have selected somethin in the block-diagram App.ActiveVI is the fastest method to get the selected items list ...

best regards

cb

Back on topic, I think that what you need to determine from which VI Tool menu a tool was launched is the Application property App.MenuLaunchVI. It returns the name of the launching VI. Use that name to get a reference.

3255[/snapback]

that was the missing link !

thank you very much !

:worship:

best regards,

cb

Hi,

  i have vi property reference and invoke node to open the front panel of another vi from the main vi, but since the both the vi property refernce and invoke node are within a while loop( used to continously monitor whether we want to close or open the sub vis front panel ) the subvi's front panel open continuously . is there any way to presvent it.

help me out

bye

karthas

3251[/snapback]

it would be easier to help you if you could show us the code, either as a screenshot or as the vi itself. its hard to imagine how it really works ...

best regards

cb

Even though this excellent set of forums (for which I heartily thank Michael for creating and tirelessly maintaining) is part of a group named LabVIEW Advanced Virtual Architects, it's still a public website. As we've seen countless times, participants vary widely in their LabVIEW experience

even though this opposes my goal (seeing your code ) i understand this argument and have to agree.

what i liked to see was, how you deal with the problem of finding the objects. in many of my scripting applications this is a verry uggly accumulation of nested for/while loops and case structures. you surely know well why and how ;-)

i have a half finished wiring tool myself. maybe if its ready we can do a "code exchange" and learn from each other ? :thumbup:

best regards,

cb

I've been reading these posts at length and I haven't heard a single comment on what a piece of crap LabView is. Our company forced us to move away from a clean C++ environment to this clumsy product and all we have is constant crashes and high CPU utilization. 

i have seen lots of LabVIEW code written by professional C/C++ Programmers* and i can approve that LabVIEW Code WRITTEN BY THESE GUYS results in constant crashes and high CPU utilization.

But it's not a problem of LabVIEW, rather a problem which resides between the ears of the programmers ... they try to create graphical C/C++ code with LabVIEW, not LabVIEW code.

best regards,

cb

*edit: with none / low LV Experience

Thanks for posting this to the forum.  As a past user of other software that was more or less killed by NI's legal actions, I'm very interested in watching how this plays out.

329[/snapback]

which one ?

DASYLab / DIADem ?

best regards,

cb

Okay, Dave, if the only reason is messiness, could you consider releasing the code at this time. I absolutely, completely, honestly and truely promise that none of us will laugh.  :laugh:

Perhaps some of us could add an extra feature or so and do a little sweeping in the process.

Your utility is cool,  :worship:  but it would save us  :headbang:  if we didn't have to recode it all

Thanks in advance! 

3192[/snapback]

100% FULL ACK !

posting password proteced VIs here is useless i think, because it's the code we are all worrying about ...

best regards

What you a searching for is somethins that simply does not exist in "pure form" in LabVIEW and will never exist in LabVIEW due to its structure.

I call this "the dynamic cluster", which is a construct of a cluster that can chance its components at run time. Of course you can never create a control/indicator/constant and so on. And because there are no Pointers in LabVIEW (all Work is done Call by Value ...) a "dynamic Cluster" can not be created in "the LabVIEW way" but you can use brute force

And after a lot of heavy brain-work i realized, this construct is allmost useless. If you need reusable VIs with changing datatypes is different projects, use Typedefs ...

If you want to see, why its useless, take a look at the example. The dynamic cluster is built in the while loop ...

best regards

CB

Download File:post-885-1104397595.zip

if you are searching for an easy way to connect to an Access Database you can use this example.

NI Database Connectivity Toolkit is needed !

Best regards

CB

Download File:post-885-1104395934.zip

it's quicker and easier to use a right-click on the connector pane of a rendezvous-VI and select "create constant/control/indicator"

somebody konows something about labview 7.1 ...if have any problem with windows xp sp2 ...because before i install sp2 i have many problems with labview ...if somebody know tell me plz

3123[/snapback]

can you please be more specific ? which problems ?

super duper secret INI file settings turned on

2908[/snapback]

AFIK the super duper secret INI file settings only cause that the vi-scripting properties/methods are visibile in the properties/methods right-click-menu ...

there is no difference if you copy the nodes from an other vi or create them by right-clicking ...

best regards,

cb

another question:

i have some self written tools (like automatic tunnel wiring wizard, etc ..) but all these tools lack of the possibility to use them directly from the tools menu for the frontmost vi.

Using the "Active VI" property will give me back a reference to the tool-vi, not to the frontmost vi i am working on. what i do now is, to open an application reference, look for all vis in memory and show all these in a listbox, who do not have callers and let the user (me) select the top level vi.

but that's not the best solution, i think and if someone knows how to get the reference to the frontmost vi i would really appreciate some help.

best regards,

cb

Hmmm, curiouser and curiouser...

[...]  I think this is a dead end for the moment.

Best regards,

Dave

2559[/snapback]

sad but true ...i did not find a solution, too

but, that was not really a problem, because building a poly-VI with 800 instances would have not been a really good idea ;-)

i found a way to solve the problem on a more "low level" way.

by the way: waiting 4 LV8 will last longer than usually. the beta version is expected in august 2005

best regards

cb

My, you've been busy   

I can't find this in the 'bag of tricks'.  You can get a reference to a 'Case Selector', and it has properties and methods to get references to its subdiagrams, add/duplicate/delete cases, get/set the default case, and GETTING the array of selector strings, but I see nothing that allows one to set the selector values.

So, another one that probably has to 'wait for eight' .

Best regards,

Dave

2561[/snapback]

thanks for the labour anyway...

i was searching very long, but now i am convinced, that there is no way to do this. i tried to handle this problem by using enums and creating a new enum (using VI scripting) for the cases i need ...

best regards,

cb