VI Server - Property Node (Execution: Close After Call)

I would like to dynamically call and run a VI and
have its front panel close after it is called.
The method I tried was:
1) Open VI Reference to the VI.
2) Set Front Panel.Open and Exec.CloseFPAfterCall
Properties to True.
3) Use Invoke Node (Run VI with Wait Until Done =
True)
4) Close VI Reference.
No matter what I do I can't get the Called VI's
front panel to close after the user quits or
exits the VI. What am I doing wrong?
My only thought is that the Exec.CloseFPAfterCall
Property only works on Called VI's that return a
value.
Also I'd like to avoid using VI server from
within the Called VI's diagram because I have a
lot of individual VI's that I would like to call.
Thanks,
Brian
Sent vi
a Deja.com http://www.deja.com/
Before you buy.

Similar Messages

Property node execution order

i've attached a picture similar to what i saw on my CLAD (I passed...yay!) and was curious what the answer was.
Its a property node and asked what order does it execute in
choices were along the lines
top down
bottom up
they all happen at the same time
its indeterminate what order
lemme know!
Solved!
Go to Solution.
Attachments:
property node order.PNG ‏4 KB

Congratulations Brent. I'm taking the CLAD (finally) either this week or next.
I would guess indeterminate.
-Matt Bradley
************ kudos always appreciated, but only when deserved **************************

Cannot find Close After Call in Labview 7.0

When I open VI's through a menu I cannot close them through my exit button. Also if I manually close it the menu is stuck on ON on that button and will only reload that VI

Brian,
I am not real sure I understand your question however I will take a shot at answering it.
Are you looking for the VI setting that closes the front panel after it finishes running? If so it is under VI Properties>>Window Appearance>>Customize. Here you can select show front panel when called and close afterwards if originally closed. With this you will be able to open the VI and then when the SubVI is finished it will close its front panel and then the main VI will continue running.
I imagine that the reason the button is stuck ON is that the SubVI is still running, so that the main VI has not reset the button.

Disabled property node hangs loop

I've got a parser loop, operating on streamed data from a CRIO via UDP. The loop operates at about 90Hz. In response to the user opening a file, the code will use a property node to enable (or disable and gray) a couple of boolean front-panel objects. When these property nodes execute, I see the CPU usage (in Windows task manager) go to close to 100% and coincidentally, the parser loop hangs. Other loops within the same VI continue to run. CPU usage stays at 100% until I force a VI abort.
With a small test-VI, I've noted that these property nodes require roughly 10ms to execute. This seems quite sluggish, but nonetheless, my thoughts are that my code, running at 90Hz, would be able to tolerate a single slip of the loop execution time, particularly because the UDP data is queued.
Any thoughts regarding this property node execution time or suggestions on how to improve the code? Thanks in advance.

Mark, thank you for offering to look at a stripped-down version of the code. I just couldn't spare the time required to simplify our complex code. However, I've been working on this problem in the past couple of weeks since I originally posted the question, and have made some progress toward a solution. Although I still do not have a conclusive explanation for the Labview's behavior, I thought I'd follow up with a list of what appears to have made improvements to the code. I'll concede that these suggestions are not definitive, but the problems are not repeatable and without any transparency into Labview's internal behavior, my analysis of the problems and my attempts to find a fix are admittedly speculative in nature. Software development shouldn't be magic, but damn it seems like Labview requires we dance around a black candle. Frustrating. OK, exiting rant mode, here is a list of what NOT to do if you want Labview to be more stable:
-- Do not use frames around your front panel objects. Our main panel has approximately 100 front-panel indicators. In an attempt to make the interface more intuitive, in a recent code revision we grouped the objects using frames. The effect was a sluggish UI and a processor loading that went to close to 85%. I'm aware from posts on this forum that overlapping indicators forces Labview to update all when any is updated. This is an understandable coding contraint. OK, fine, we weren't overlapping any idicators. But for pete's sake, why should the same constraint apply to a purely decorative object like a frame? This strikes me as a fundamental philosophical flaw in LV's coding. Group N objects with a nice frame -- update the objects N-squared times. If this is the result of using a frame, I would have preferred that NI not even offer the option. Bad choice on the part of the Labview coders and bad choice on our part for assuming zero frame impact on performance.
-- Do not use property nodes. We occasionally gray-out front panel objects when appropriate for the state of the software. This appeared to be contributing to Labview's instability. I built a diagnostic routine that measures execution time for the "gray-out and disable" property node. Generally around 8ms, but occasionally as high as 16ms. Good grief. I've got a code loop running at 90Hz. A 16ms hit isn't easy to tolerate or frankly to understand. Particularly when slow execution is the BEST of the consequences -- the worst is that the property node seemed on occasion to precipitate a hung loop.
-- Do not use Labview's built-in queue structure. Our code was originally using queues to hand off packets of data from a UDP-listener loop to a packet-parser. The UDP-listener blocks on UDP reception, shoves the packets into the queue. The packet parser blocks on data available in the queue and subsequently writes the data to file. NI would have you believe, and I did believe for a while, that this is an elegant producer/consumer approach to this problem. When our problem would occur, the UDP-listener continued to put data into the queue, but the packet parser would never retrieve it. Just went off into nowhere, consumed and forgotten by the Great Labview Scheduler in the Sky. The loop would hang, wouldn't respond to the stop button, would require a forced-abort. Subsequently, if we simply restarted the code, we couldn't be assured that the packets retrieved from the queue would be in chronological order. Seemed to be just randomly retrieved. Clearly the failures had corrupted some of the Labview internal data structures that govern the queue operation. We couldn't assure proper behavior unless we shut down and restarted Labview each time the error occurred. The solution was to abandon code elegance in favor of sequential operation -- get rid of the queue, listen for the UDP packet then parse it immediately. No queue handoff. No further parser lock-ups.
I'm not sure what other bombs might be lurking in our code. Our listener and parser code hasn't lately hung, but the problem is starting to move on to other loops. They'll run for hours and then just stop. Dead. Frozen. In the most recent cases, even the abort button won't shut them down. We have to use Windows Task Manager to kill them. I'll admit to harboring some deepening skepticism for any of the more clever and powerful "features" that NI has added to LV. From my perspective, these more powerful features cannot come free of cost -- they must impose some unavoidable computational burden on LV itself, a burden that LV seems unable to handle, with unpleasant consequences. Must we impose a moratorium on Timed Loops? Event structures? To what level of simplicity must I drive our code to ensure stability?
Thanks, everyone, for tolerating my frustration, and for your comments, if you've got any guidance you can offer.
-dave sprinkle

How to set property nodes for each of the multiple y-axes?

In Labview 6i, I have set up multiple y-axes on an xy graph. I want to change certain properties of each of the 2 y-axes independently. I believe I can do this using "property node".
However, after I have created a property node for the xy graph, I realised that there is only 1 y-axis selectable from the list of properties. How can I set the property of the other y-axis then?
Thanks for the help!

I believe there is a property called "active graph"... this allows you to
select the active graph to apply the property changes to...
Later...
meng118230 wrote in message
news:[email protected]..
> In Labview 6i, I have set up multiple y-axes on an xy graph. I want to
> change certain properties of each of the 2 y-axes independently. I
> believe I can do this using "property node".
>
> However, after I have created a property node for the xy graph, I
> realised that there is only 1 y-axis selectable from the list of
> properties. How can I set the property of the other y-axis then?
>
> Thanks for the help!

Reference a property node in a seperate VI

I have created a VI that calls on another VI, but before it does, I want to check the "connections to clients" property node in VI being called. Is there a way to get information from the second VI's property node into the first VI?
-Tek

Tek wrote:
I have created a VI that calls on another VI, but before it does, I want to check the "connections to clients" property node in VI being called. Is there a way to get information from the second VI's property node into the first VI?
-Tek
Hi Tek,
I didn't find the "connections to clients" property you mention, but here's an example of how to retrieve properties from a VI without actuallly calling it.
Hope it helps!
Cheers
When they give imbeciles handicap-parking, I won't have so far to walk!
Attachments:
Props.llb ‏36 KB

Window doesn't close wheh Call Library Function Node set to Run in Any Thread

This is a problem regarding Call Library Function Nodes running in the UI thread or any thread.
I have a camera which has its own API supplied as a dll. I have created a set of VI wrappers which each call a function in the dll through a Call Library Function Node.
Initially each CLFN was set to 'Run in the UI thread' (the default).
To start the camera streaming images I call (through a CLFN)
ICubeSDK_Start(int CamIndex, Hwnd, ImgHandle, bool Preview, bool callback);
If Preview = True then the image is displayed in a preview window.
If ImgHandle = NULL a default preview window
is used.
In the CLFN definition I define:
ImgHandle as a U32
Preview as a I32
To stop the camera streaming images I call
ICubeSDK_Stop(int CamIndex)
In the actual implementation I set ImgHandle = 0 (NULL) and Preview = 1 (true).
This all works fine, and a preview window is opened and images displayed. When I call ICubeSDK_Stop the preview window is closed.
However, I would prefer to set the CLFN to 'Run in any thread' because
a) when run in the UI thread the preview window randomly gets sent to the back when I switch focus between open VI windows (presumably because it is in the same thread as the VIs)
b) I don't want to put unnecessary stuff in the UI thread
c) my (naive?) understanding is that it is safer to run in any thread
So I have set all CLFNs to 'Run in any thread'
When I do this the preview window opens OK, and behaves like any other non LabVIEW controlled window in terms of focus. But when I call ICubeSDK_Stop() the preview window does not get closed properly, it just shows a blank image. I can't close it manually, there is no X in the corner and no option to close it from the taskbar. To get rid of it I have to close the LabVIEW project it is spawned from, which often results in a crash. It does appear as a separate item in task manager but if I 'end process' it, LabVIEW closes (and often crashes) as well.
If I change only the CLFNs that call the Start and Stop functions back to 'Run in the UI thread' then it all works fine again, except that the preview window gets sent to the back randomly as before.
So, what do I have to do to get the preview window to close properly if I set the CLFN to 'Run in any thread'.
Alternatively, is there a way to close the window programmatically (ie force it to close) after I have called ICube_Stop.
Thanks
DAve

Hi Dave,
The "Run In UI Thread" switches from the thread the VIs currently executing in to the user interface thread. If you select "Run in Any Thread", the Call Library Function Node continues in the currently executing thread. By default, all Call Library Function Nodes run in the User Interface thread.
Before you configure the Call Library Function Node to run in any thread, you have to make sure that the code is thread safe. Code is thread safe when it does not store any global data (e.g. global variables, files on disks, etc.), does not access any hardware, does not make calls to any functions, libraries or drivers that are not thread safe.
Unfortunately, since you said that your DLL accesses hardware, it is not recommended to use "Run in Any Thread." This is probably why you are seeing the crash.
If your preview window gets sent to the back you can programmatically bring it forward. Here is an example of how this can be done: http://decibel.ni.com/content/docs/DOC-4551
If you want to completely close the window down you can do so as described in this link: http://digital.ni.com/public.nsf/allkb/81E9C1441900FFCE8625748F0055DBB0?OpenDocument
I also thought you might find this useful: http://zone.ni.com/devzone/cda/tut/p/id/3009
I hope this helps.
Regards,
Mahdieh G
Applications Engineer
National Instruments UK&Ireland

After SocketChannel.close, must call Selector.wakeup

When I am reading from a tcp socket using NIO channels & selectors, I have the following problem when I go to close the channel.
If I close the channel in the thread where I called selector.select(), then the channel is closed and the client application gets the event that the channel was closed.
However, if I do the reading in a seperate thread, after calling channel.close(), I must call selector.wakeup() or the socket is not closed.
Any idea what is going on?
thanks - dave

The main point of NIO is that you don't need multiple threads to read and write multiple sockets. You can use multiple threads, but it complicates things. After you close a channel you must let the select run one more time, this is the reason that I try to close channels from the thread that is running the select. You probably already have a queue of runnables to process interestOps and register in the select thread. You should use that for the close activity as well.
I've posted a lot of topics on NIO, that cover this and other tricks of using NIO. Here are the most useful.
Taming the NIO Circus, NIO Server Example, NIO Client Example

Connection remains opened even after calling conn.close

i have a need to copy records from one table in a database (say db1) to another table in another database(say db2). I open connection to both databases, and get a Recordset (say rs1) by executing a query that contains all rows that i have to insert in the database db2. Next i get an empty recordset(rs2) on the table in the database db2 (with locktype batchoptimistic, clientside cursor). i loop on rs1 and for each row in rs1 i insert a row in rs2 and copy the fields. after all rows are done, i delete the rows from db2 that will be affected and do an updatebatch on rs2. then i close the recordsets and the connections
everything works fine except that the connection with the db2 is not getting closed, neither is it throwing any exception. when i comment the updateBatch code the connection closes normally.
can anyone please help me out, where am i going wrong.
thanks
Vijay Sharma

Hi,
There is one more thing that I want to add to the above question. After calling conn.close() I checked the status of the connection and it was not 'OPEN' but when I checked session information through DBA studio it was showing one connection. I enabled trace of Oracle provider for OLE DB. Trace showed that two sessions were opened but only one session was closed.
Thanks,
Vijay

Can you make core center automatically close after being called on startup?

Can you make core center automatically close after being called on startup so it can set cpu fan speed to a slower fixed speed then exit?
If core center really cant do such a simple task then can speedfan or another program?

Quote from: bassmadrigal on 13-July-05, 07:42:36
Why don't you want them running. Speedfan has a very small footprint.
Just seems unnecesary seeming as it does its task as soon as it runs and its changes then stay applied. Speed fan is probably better but core center takes 10mb.
Quote from: syar2003 on 13-July-05, 07:57:02
You dont have to have it running to set a user specified fan rpm .
Once it's set it is stored in the corecell/cmos chip on the motherboard .(until a cmos reset) .
So to answer your question .
There is no need to have it autostarted at each boot ...
Thats how i have used it .
Only reason to have it running is with MSI's "CnQ" control of the fan , varies with the load of the processor
Thats strange for me the speed resets to default as soon as I restart my pc (about when the bios engages which is however tangibly after the graphics card fan revves up to its full speed). Depending on the temperature of the proccessor it goes to 3300rpm (less than 42c) or 4500rpm (too loud for ~45c IMO and MSIs "cool&quiet" option seems to agree, it doesn't even set it as high as 3300rpm)

Property nodes are severely affecting performance

LabVIEW Gurus,
I am continually running into some serious performance hits using property nodes to update attributes of FP objects. Attached is a classic example.
I have 8 XY plots that are being fed 600 SGL points every 200 msec - a very modest data rate. Each plot is a dynamically instanciated .vit placed into one of 8 subpanels in a container VI. The container VI also acts as the data server for the charts, sending each one their data in their own single element queue. The entire architecture runs great (~4% CPU load, see attached picture) until I being updating a property node to display the value of the cursor y-value. When I enable the "Caption.Text" property node of the XY Graph to display the cursor value, the CPU usage soars to over 30%.
As an aside, I am developing on a dual core 2.1GHz platform with 4G memory with LV8.5.1, and the target machine is not nearly as beefy. That's why 30% CPU on my powerhouse is an issue - it basically brings the embedded target to its knees.
I have included an example VI for you to run on your machine. Consider it "representative" of my bigger issues. The VI runs about 10% CPU without the caption update, and 20% with the caption updates.
Finally, I have tried putting the VIs into the UI execution system. I have also tried Defer Panel Updates, but this actually slows down performance.
Best regards,
Jack Dunaway
With Captions
Without Captions:
Message Edited by mechelecengr on 10-10-2008 11:23 AM
Message Edited by mechelecengr on 10-10-2008 11:27 AM
a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"] {color: black;} a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"]:after {content: '';} .jrd-sig {height: 80px; overflow: visible;} .jrd-sig-deploy {float:left; opacity:0.2;} .jrd-sig-img {float:right; opacity:0.2;} .jrd-sig-img:hover {opacity:0.8;} .jrd-sig-deploy:hover {opacity:0.8;}
Solved!
Go to Solution.
Attachments:
WithCaptions.png ‏102 KB
WithoutCaptions.png ‏96 KB
GraphPerformanceProblems.vi ‏23 KB

Yes, property nodes force synchronous execution and if you do that too often, other things suffer.
The above solution is good. You can simplify things even more by removing all that unneeded extra code that just complicates things.
Here's a quick draft. Let me know if you have questions.
Message Edited by altenbach on 10-10-2008 09:58 AM
LabVIEW Champion . Do more with less code and in less time .
Attachments:
samewithlesscode.png ‏9 KB
GraphPerformanceProblemsMOD.vi ‏19 KB

Access DB (& .ldb file) does not close after crystal reports

Post Author: mgold
CA Forum: Crystal Reports
Access DB (& .ldb file) does not close after crystal reports
Hi! We have a VB application using Crystal Reports 6 that has worked successfully on hundreds of systems for over 10 years. Now, on one network, the application and access database does not close. It seems to hang on the [.Close] command.
When we open the application an peruse the screens without opening up a report (using crystal reports), the application and access db closes fine. But as soon as we run a report and then close the report and try to close the application, the access db does not close. Many of the screens open the db and grab data from the access db, but it's only after running crystal reports that we have this problem. (Please see more information below.)
Setup: Application and data (access 97 db) reside on a server in the same folder, but application shortcut is kicked off on client PC. Kicking off the shortcut on the client PC means that the image/process runs on the client PC (not on the server). In this problem case, the application shortcut is on a Windows XP Pro Version 2002 SP2 PC with the app & data on a Windows 2003 server. Users are local Admins on their PCs with "Full Control"over the directory and files on the server where the data (access 97 db) resides. This type of setup is typical and has worked without any problems for clients.
The application is written in Visual Basic, using Crystal Reports 6 (using DAO). We close the recordset, set it to zero and then it hangs on closing the db (.Close command).
A few key pieces of information:
- The application closes fine if the app & data (access 97 db) are on a local PC. This includes closing fine if the application is run directly on the Windows 2003 server where the data is stored.
- It worked on this client's network until sometime in the last few weeks.
- One thing that changed is that the company is using VMWare on its servers. Not sure if they started using VMWare at the same time as it started failing. This may be unrelated. Possibly other things changed, but can't get any more information ... yet.
- It works fine running the application from a Windows Vista PC with a user who is a domain admin.
- The access db and application hang for about 10-20 minutes and then eventually closes. It appears that somehow
Crystal Reports is keeping the db open, but I'm not sure why.The application doesn't quit and the database doesn't close even if I try to end the task with the Task Manager.
- The Crystl32.ocx version being used is 8.0.0.4 (if that matters).
- I copied 6 month old program files and database files to a test folder on the Windows 2003 server. It fails using these files that worked fine 6 months ago.
Any ideas or help would be greatly appreciated! If you know of another good place to post this, please let me know.
Thanks!
- Mark

Crystal doesn't support tables in HTML interpretation.
You can probably work your way around this by doing Replace() calls on the relevant tags.
See:
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/oss_notes_boj/sdn_oss_boj_erq/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/scn_bosap/notes%7B6163636573733d36393736354636443646363436353344333933393338323636393736354637333631373036453646373436353733354636453735364436323635373233443330333033303331333233313337333033383334%7D.do
The supported HTML tags are:
" html
" body
" div (causes a paragraph break)
" tr (causes only a paragraph break; does not
preserve column structure of a table)
" span
" font
" p (causes a paragraph break)
" br (causes a paragraph break)
" h1 (causes a paragraph break, makes the font bold
& twice default size)
" h2 (causes a paragraph break, makes the font bold
& 1.5 times default size)
" h3 (causes a paragraph break, makes the font bold
& 9/8 default size)
" h4 (causes a paragraph break, makes the font bold)
" h5 (causes a paragraph break, makes the font bold
& 5/6 default size)
" h6 (causes a paragraph break, makes the font bold
& 5/8 default size)
" center
" big (increases font size by 2 points)
" small (decreases font size by 2 points if it's 8
points or larger)
" b
" i
" s
" strike
" u
The supported HTML attributes are:
" align
" face
" size
" color
" style
" font-family
" font-size
" font-style
" font-weight

Can I use the 'Export Signal Property Node' on a quadrature encoder?

Hi,
So I don't know which counter board I'd be using yet for this (it's used in conjunction with a PCI-6280--the PCI-6280's counter inputs are all taken and so I need another board), but assuming this is possible at all in DAQmx I wouldn't mind knowing whether, say, the PCI-6601 (or any other timer board for that matter) could do this. I'm programming this in LabVIEW 2010 by the way.
I want to have a counter which counts the number of pulses on one channel (I'll call this the 'clock' channel) between when another channel goes from low to high (which I'll call the trigger). It's basically a pulse width measurement, but I only care if there are more than n clock pulses between triggers. I need to have a hardware-timed digital signal which goes from low to high if there are ever more than n pulses between trigger changing state from low to high.
What I am planning to do is this:
Wire 'trigger' to the z-input of the quadrature encoder, and set the z-input value to some arbitrary large value such that, at the quadrature encoder counter task's settings, the counter reaches terminal count in n pulses.
Configure the quadrature encoder counter using DAQmx Export Signal Property Node (tutorial I was looking at is here: http://zone.ni.com/devzone/cda/tut/p/id/5387 ) to toggle a digital channel ('counter event output') from low to high if the counter reaches terminal count (ie, if the encoder reads n pulses).
If the encoder ever reads n pulses on 'clock' between two rising pulses on 'trigger', it sets counter event output high.
Is this possible? Reading through the manual of M series PCI-62xx devices, the index pulse loads the counter with a particular value so it seems like you could conceivably set the counter to the terminal count if you wanted. My only real problem is whether DAQmx Export Signal Property Node works on all counter tasks or just on edge counting tasks.
Thanks in advance for your help. If this isn't possible, I can reply with more details on the problem this is supposed to solve so that you can help me figure out an alternate method.
Solved!
Go to Solution.

There is probably a way to do it, but it it may be easier to use an X-series board for the job. They support a new counter capability for count reset on a digital edge without needing to be configured in encoder position mode. I am not sure exactly how that feature's been implemented however, so maybe it won't make things easier after all.
The plan based on the hoped-for behavior:
1. Configure an X-series counter for pulse generation based on "ticks" of your clock channel.
2. Set both initial delay and low time to the critical # of ticks.
3. Configure for count reset on a digital edge (if possible in pulse generation mode)
4. Configure the count reset value to be the critical # (or possibly 1 less, if possible in pulse generation mode)
5. If you want the output to remain high indefinitely, configure the counter task to use its own output as a
pause trigger, and pause while high.
The way pulse generation works is to preload a # of "low time" ticks into the count register. Then every source edge will decrement the count. When the count reaches terminal count (0), the counter's output is toggled (or can be configured to pulse). The register is then loaded with the # of "high time" ticks and the process continues.
You would be perpetually interrupting the count-down process as long as you got your triggers in time. The count would keep getting reset to the # of low counts, keep decrementing toward 0 without reaching it, and so on. If ever you did reach 0, the output state would toggle high, then the high state would prevent subsequent clock signals from decrementing the count.
You can conceivably do a similar thing with a 6601, but I'm pretty sure you'd need 2 counters working together to get it working.
-Kevin P

Asset query execution performance after upgrade from 4.6C to ECC 6.0+EHP4

Hi,guys
I am encounted a weird problems about asset query execution performance after upgrade to ECC 6.0.
Our client had migrated sap system from 4.6c to ECC 6.0. We test all transaction code and related stand report and query.
Everything is working normally except this asset depreciation query report. It is created based on ANLP, ANLZ, ANLA, ANLB, ANLC table; there is also some ABAP code for additional field.
This report execution costed about 6 minutes in 4.6C system; however it will take 25 minutes in ECC 6.0 with same selection parameter.
At first, I am trying to find some difference in table index ,structure between 4.6c and ECC 6.0,but there is no difference about it.
i am wondering why the other query reports is running normally but only this report running with too long time execution dump messages even though we do not make any changes for it.
your reply is very appreciated
Regards
Brian

Thanks for your replies.
I check these notes, unfortunately it is different our situation.
Our situation is all standard asset report and query (sq01) is running normally except this query report.
I executed se30 for this query (SQ01) at both 4.6C and ECC 6.0.
I find there is some difference in select sequence logic even though same query without any changes.
I list there for your reference.
4.6C
AQA0FI==========S2============
Open Cursor ANLP                                    38,702 39,329,356 = 39,329,356      34.6     AQA0FI==========S2============   DB     Opens
Fetch ANLP                                         292,177 30,378,351 = 30,378,351      26.7    26.7 AQA0FI==========S2============   DB     OpenS
Select Single ANLC                                  15,012 19,965,172 = 19,965,172      17.5    17.5 AQA0FI==========S2============   DB     OpenS
Select Single ANLA                                  13,721 11,754,305 = 11,754,305      10.3    10.3 AQA0FI==========S2============   DB     OpenS
Select Single ANLZ                                   3,753   3,259,308 = 3,259,308       2.9     2.9 AQA0FI==========S2============   DB     OpenS
Select Single ANLB                                   3,753   3,069,119 = 3,069,119       2.7     2.7 AQA0FI==========S2============   DB     OpenS
ECC 6.0
Perform FUNKTION_AUSFUEHREN     2     358,620,931          355
Perform COMMAND_QSUB     1     358,620,062          68
Call Func. RSAQ_SUBMIT_QUERY_REPORT     1     358,569,656          88
Program AQIWFI==========S2============     2     358,558,488          1,350
Select Single ANLA     160,306     75,576,052     =     75,576,052
Open Cursor ANLP     71,136     42,096,314     =     42,096,314
Select Single ANLC     71,134     38,799,393     =     38,799,393
Select Single ANLB     61,888     26,007,721     =     26,007,721
Select Single ANLZ     61,888     24,072,111     =     24,072,111
Fetch ANLP     234,524     13,510,646     =     13,510,646
Close Cursor ANLP     71,136     2,017,654     =     2,017,654
We can see first open cursor ANLP ,fetch ANLP then select ANLC,ANLA,ANLZ,ANLB at 4.C.
But it changed to first select ANLA,and open cursor ANLP,then select ANLC,ANLB,ANLZ,at last fetch ANLP.
Probably,it is the real reason why it is running long time in ECC 6.0.
Is there any changes for query selcection logic(table join function) in ECC 6.0.

Property Node in VI throws Error 7 in LV 7.1 but runs OK in LV80 and LV86

Hi everybody
I build a custom IVI instrument driver and using the LV tool <Generate VI Interface from Instrumnet CVI Driver> I was able to get a LV wrapper for each driver method. From LV86 I saved first in LV80 and from LV80 I saved as LV71. I have all these LV versions on installed on my PC.
I have no trouble in using these LV wrappers in any of these LV versions as they work OK.
Now my IVI driver has also Properties that the Import Driver Tool does not convert as a wrapper and for that reason I had to create a Property Node Warpper myself and saved in the same LLB under LV/instr.lib folder.
Once I have all these method wrappers and the property node wrappers I made a small VI
1. Initialize IVI With Options on a TCPIP instrument
2. Set-Get an IVI Timeout property
3 Close IVI driver on TCPIP instrument.
Good part is that in LV 86 and in LV 80 the VI is running fine when I use these LV version wrappers from their coresponding instr.lib folder.
As soon as I am going to use the LV 71 wrappers in LV 71 I could create the same small VI to Set/Get Timeout and the VI look OK nothing is broken but when I run it the Initialization is OK but as soon as is reaching the Timeout Set Property Node gets out an Error Code 7.
To run this VI the user need to install the jdCMR IVI driver then add the LV71 jdCMR wrappers inside LV71/instr.lib and then he may build any VI using these LV warppers.
The only problem is that the Property Node get out an Error Code 7 and the same error code get out from Property Node if I am picking the Property Node from VISA Advanced Pallette, connect this node to jdCMR driver, set Timeout property inside the node and after connecting the input and output references plus the input and output error to Initialize and Close LV wrappers I still get this error at running time.
The same LV 71 VI if I open in LV80 or in LV 86 runs without any problem?
Does anybody knows why LV 71 is not working the same way as LV80 and LV86 with respect to Property Node?
Btw When I save my VI from LV 80 to LV 71 I get this warning...
IVI Error Message Builder.vi
    Cannot save VI from VI.LIB to previous version.
Merge Errors.vi
    Cannot save VI from VI.LIB to previous version.
Thanks
Sorin

Hi
For further testing of the IVI driver Property Node bug with LabVIEW 7.1 IVI drivers I download and installed two different IVI drivers from two very known instrument companies, Rodhe-Schwarz and Agilent Technologies.
I have to mention that both these companies releasead their IVI NI LabVIEW 7.1 drivers under NI Instrument Driver Network and ready to be installed and used by any customer of these two instruments.
The bug is present only in LabVIEW 7.1 version as if I take the same VI that breaks in LabVIEW 7.1 I could run it without any problem in LabVIEW 8.0 or LabVIEW 8.6 versions.
Anybody could test this bug for these two NI released IVI drivers in simulation in LabVIEW 7.1 by following these links below.
Agilent ag81150ni IVI Driver for LabVIEW 7.1 install from here. Run in simulation only by setting Simulate=1
http://sine.ni.com/apps/utf8/niid_web_display.download_page?p_id_guid=55798957B1A633BDE0440003BA7CCD...
   Rodhe Schwarz rsngpt IVI Driver for LabVIEW 7.1 install from here. Run in simulation only by setting Simulate=1
http://sine.ni.com/apps/utf8/niid_web_display.download_page?p_id_guid=E3B19B3E91D6659CE034080020E748...
After installation complete close LabVIEW 7.1 if was open, then restart LabVIEW 7.1 and now you may see under the LabVIEW Instrument Driver Palette two new IVI drivers ready to be used as LabVIEW 7.1 wrappers.
Open a new blank VI and from Instrument Driver Palette use two well known Vis that are Initialize With Options.vi and Close.vi add them on your blank VI block diagram and connect thm together. Accept all default parameters except Simulate that must be Simulate=1.
Both Vis run OK in simulation mode without errors. Now pick a Property Node from VISA Advanced Panel and squeeze this between the Initialize With Options VI and Close VI and make the instrument reference in-out and error in-out connections.
Now run these two simple Vis in simulation
I run Rodhe Schwarz IVI driver and Property Node passes OK until the end
I run Agilent IVI driver but Property Node is getting out Error Code 7 that is the same as my own driver error.
Both these IVI drivers are under NI Instrument Driver Networks and have been built and integrated as native NI IVI instrument drivers.
Question is why they behave so different with respect to Property Node from the VISA Advanced Panel?
I attached the screen shots as PNG files that show clearly the difference of VISA Property Node behaviour when used under the same circumstances.
Thanks  Sorin
Attachments:
ScreenTestShots.zip ‏152 KB

VI Server - Property Node (Execution: Close After Call)

Similar Messages

Maybe you are looking for