SLOW Xbench User Interface Test

Hi all,
MBP early 2008 2.5GHz, 2GB RAM, 250GB HD (130GB free), 10.5.7 and all updates.
Since I got this machine, it has not seemed any faster than my 867MHz TiBook running Tiger. Today I ran Xbench twice and it showed an extremely low User Interface Test result (12.91 at 59.25 refresh/sec).
I know Xbench hasn't been updated for awhile, but looking at a few other Intel Mac scores, I didn't see any scores even close to this one.
So, has anyone else run Xbench? Anyone care to give it a try and report results on that part of the test?
Thanks
(PS I've run all the maintenance I can think of, checked Activity Monitor, etc etc etc. Next step is to reinstall OS, but rather not if there's anything more to learn about this first.)
(PSS First run I had Time Machine turned on and external FW HD connected, so disconnected that. Also, just remembered I am running File Vault, and wondering if that's the culprit.)
Message was edited by: tjk

no idea...
but try to disable filevault...
If you want to dream on the old days and to see what Apple don't want us to use now, make a ram disk (it will not be consistent after a reboot, as Apple prevent it... )
try to run a xbench on it...
yes, 908 ...
try to run your hardisk benchmark.
yes, only 27 or a little more...
So, what all the buzz around with flash disk is just bullsh.t, as , since 1995 at least, Apple made RAM disk, and BOOTABLE until the G3...
I'm quite sure that we could have a 400 % more quick os X sytem if we could run it on Ram disk...
I used it for second life, as browsers can have another cache location (or, I didn't find how to do it)
it's about 20 % faster, and it is not shocking the hard disk, as the more you write and erase, the more your disk work.
Sorry to be a little of topic, but a Xbench thread could be good in that 'using your mac book pro , original" just to see how we can speed it a little bit, or not
(I use "Make RAM Disk 1.0", no bug , on 10.4.11)

Similar Messages

Slow Modem Users-Please Test Download Speed & Report Back

Dear iMac G5 Users,
Several of us have tested download speeds using our built-in 56K modems. Nobody has been able to get our iMacs to download at anything over about 29 kbps or 3.6 KBytes/sec. That looks to be about half of what is advertised. (No surprise really - I can only burn DVD-R's at half Apple's advertised speed). My old G3's modem will easily download at least 5.8 KBytes/sec or 46K. That's much more reasonable for a 56K modem.
Could you users check your download speed at some place like: http://www.speakeasy.net/speedtest/ and post your results here?

I did the Speakeasy test from my home, and I got 24 kbps. However, this is the same speed
I got on an iMac DV with its built-in modem.
Yesterday I took my G5 iMac over to a friend's house; I wanted to test the modem
speed from a better line, and to verify that the airport card worked properly.
When I connected, Internet Connect app reported 50667 kbps.
When I did the Speakeasy test, it reported 43 kbps. This location used to
get 40000 on a Bondi iMac when it first came out (OS 8.1) so I figured this was about right.

User interface lags severely on my 2.2GHz mbook pro 3,1

I usually run my laptop just plugged in without battery ever since i had my first battery totally fry on me within 6 months of usage. And i needed to use my computer intensively the last few days so i plugged the battery in reset the computer reset power management controller and started working. Directly after bootup the computer runs fine and fast but shortly after the interface lags greatly. Scrolling in safari becomes painfull, mouse movements not as smooth, and response time to lots of things are ridiculous. Wanted to figure out what was going on. So i downloaded xbench and ran some tests, everything seems normal except for user interface tests.
Directly after boot i would get a score of 130
after some time when i notice it's not working well it drops to 11-15
what could this be? I heard from some other posts it could be skype, i never launched skype still same thing. Activity monitor reports nothing unusual.
Please help. This is ridiculous. I couldn't even use aperture when touching up a photo i took for a billboard ad.

As Allan says, Rani, running without the battery will indeed slow down your processor, which puts it at something of a handicap right from the start.
It sounds as if something else may be adding to this lag, though. You say that Activity Monitor reports nothing unusual. Does this apply to both CPU and RAM usage? When the problem is occurring what sort of CPU percentage is being reported for the most "CPU hungry" processes? What about the "Page ins / page outs" when you look at "System memory"?
How full is your HD? If it is , say, less than about 20% free then it is quite possible that you are suffering from a lot of free space fragmentation. Aperture is one application which can add to fragmentation effects , too.
As far as Aperture goes, have you tried rebuilding the Aperture database files?
How about corrupt or duplicated fonts? It may be that the slowdown is occuring after an attempt to access such an item in one program or another. Check for corrupt or duplicated fonts with Font Book , and get rid of any that it reports.
Have you booted up from your OS DVD and run Disk Utility to "repair disk" recently? If not give it a try. It is not uncommon for some directory corruption to build up over time. Alternatively you could try a "Safe Boot", though it won't directly provide you with as much information as using Disk Utility. (see http://support.apple.com/kb/TS1417 for a description of various options for directory repair).
You might also want to check your HD with Smart Utility.
Cheers
Rod

User interface threads

Ok let's say you're writing a user interface and nothing involves
special-resources like a daqcard so there's no constraints on using things
at once. These are some kind of stupid questions and ideas but I'm really
not sure how to write a quality app with user interface at the moment.
My current design is bad, it is a mainVI which checks the menu and
frontpanel buttons, decides which operation or calculation (if any) is
selected, and sends that to a case structure to perform the operation.
This is sloooow but the most common way in examples that I've seen. The
major problem is that while processing the interface isn't checked and
therefore mouseclicks might be lost. Let's say the processing takes like
500ms on average, that is kind of slow between user-interface querys so it
would feel unresponsive in the mean time.
So here's my three ideas so far, I'd love some comments on what will be FAST
and what would be worthwhile to spend my time on:
1. Leave the app as-is, latch the booleans. However you can't latch
mouse-clicks on a picture indicator that I knew of. I emailed NI before
about this and they just suggested adjusting execution priorities. Anybody
else messed around with this? Probably the worst option, but would take zero
programming.
2. Divorce the user interface and the processing. Create two parallel
while-loops in the same VI, one checks the buttons/menu on the front panel
the other processes the request or calculation. Let's say on average UI
checking takes 1.2ms and processing takes about 500ms. Also in this case is
the watch icon still really my best option (since checking buttons/menu only
takes like 1.5ms on average) for not wasting time repeatedly checking when
there's no input and dividing up cputime accordingly? Seems like there'd be
some overhead in switching back and forth repeatedly.
3. Going all-out and changing to somewhat of an object structure. That way
the UI could create a new "execution" refnum, maintain some list of created
objects, process, return values, destroy any object, so everything could be
going on in parallel. That way one slow calculation won't bog down the rest
of the things the UI requests. The idea is far too abstract to me at this
point, but on a single CPU w98 system is it even worth my thinking about
such a structure? I get the feeling I'd see zero performance change between
the two, in fact maybe worse from any labview thread overhead!
Thanks for any comments. I have seen DAQ intensive apps discussed often, but
don't usually catch much on large user interface apps.
-joey

Hi Joey
First check are you are not recalculating the values on ever iteration of the user interface loop but are you only recalculating
on any change in the user interface values.
Otherwise I would use idea No. 2 but with these changes.
1. Only check the whole user interface every 200-300ms, 1.5ms loop time will unnecessarily load the CPU.
2. Each user interaction could be given a string representation and then placed in a queue to wait for the calculation loop to
have time to process it.(So the user instructions are not lost)
3. Have separate loops for faster and slower calculations (or more) with each having their own queue.
4. The extension to the idea's of having separate loops, is to have each loop in a separate independently running VI (see
VIserver). Still use the queue's to pass the data. This method would allow the calculations and the user interface to run on
separate threads and also lets you alter the execution priority for each VI to fine tune the execution times.
Following these instructions you would produce a basic client-server architecture for your user interface, as long as the UI
doesn't require too many slow calculation results before continuing then this should work well.
If this is still not fast enough then, if you have used suggestion No.4, the calculations can be moved off the users computer to a
faster server (using VIserver) also assuming they are networked.
Hope this gives you some ideas.
Tim S
Joseph Oravec wrote:
> Ok let's say you're writing a user interface and nothing involves
> special-resources like a daqcard so there's no constraints on using things
> at once. These are some kind of stupid questions and ideas but I'm really
> not sure how to write a quality app with user interface at the moment.
>
> My current design is bad, it is a mainVI which checks the menu and
> frontpanel buttons, decides which operation or calculation (if any) is
> selected, and sends that to a case structure to perform the operation.
>
> This is sloooow but the most common way in examples that I've seen. The
> major problem is that while processing the interface isn't checked and
> therefore mouseclicks might be lost. Let's say the processing takes like
> 500ms on average, that is kind of slow between user-interface querys so it
> would feel unresponsive in the mean time.
>
> So here's my three ideas so far, I'd love some comments on what will be FAST
> and what would be worthwhile to spend my time on:
>
> 1. Leave the app as-is, latch the booleans. However you can't latch
> mouse-clicks on a picture indicator that I knew of. I emailed NI before
> about this and they just suggested adjusting execution priorities. Anybody
> else messed around with this? Probably the worst option, but would take zero
> programming.
>
> 2. Divorce the user interface and the processing. Create two parallel
> while-loops in the same VI, one checks the buttons/menu on the front panel
> the other processes the request or calculation. Let's say on average UI
> checking takes 1.2ms and processing takes about 500ms. Also in this case is
> the watch icon still really my best option (since checking buttons/menu only
> takes like 1.5ms on average) for not wasting time repeatedly checking when
> there's no input and dividing up cputime accordingly? Seems like there'd be
> some overhead in switching back and forth repeatedly.
>
> 3. Going all-out and changing to somewhat of an object structure. That way
> the UI could create a new "execution" refnum, maintain some list of created
> objects, process, return values, destroy any object, so everything could be
> going on in parallel. That way one slow calculation won't bog down the rest
> of the things the UI requests. The idea is far too abstract to me at this
> point, but on a single CPU w98 system is it even worth my thinking about
> such a structure? I get the feeling I'd see zero performance change between
> the two, in fact maybe worse from any labview thread overhead!
>
> Thanks for any comments. I have seen DAQ intensive apps discussed often, but
> don't usually catch much on large user interface apps.
>
> -joey

Logging user interface actions

I have a requirement that operator actions within the user interface be logged to a file or database. Short of creating a user interface from scratch, how would you go about adding this capability to one of the user interfaces provided by NI with TestStand?
Is there a way to intercept and log TestStand's Engine API traffic? Does the engine keep some sort of log?
I need to capture events such as these:
User A logs in at 2:35 p.m.
User A open User Manager and add new user, User B.
User A logs out at 3:15 p.m.
User B logs in at 3:20 p.m.
User B opens MySequence.seq
User B calls Configure Report Options configuration entry point
Etc...
Any help is appreciated.
Chuck Cox
General Dynamics SATCOM Technologies
Longview, Texas
Solved!
Go to Solution.

Hi,
You could look at the TestStandUIControlsReferencePoster.pdf document to see the objects and events that you can handle in the operator interface.
And look for the UI Messages in the TestStand help.
The default ProcessModels use some UI Messages to send informations to the user interface (--> "Test UUTs" entry point).
You can post your own messages (called UserMessages) from the ProcessModel.
Look at the PostUIMessage method of the thread or engine objects (TestStand API).
The interface operator can intercept these UIMessages if you handle the UserMessage or UIMessageEvent of the ApplicationMgr object.
I give you a starting point.
Hope that helps you.
Bruno

How to get the value of the global variable of test stand in labview User interface?

Hi.
Can anyone Please share examples and tell me to how access the test stand global variable using labview user interface.
Solved!
Go to Solution.

I'm not surprised that what you are doing doesn't work. The Start Execution UI Message is triggered when the user clicks a button to start an execution. Realize that most executions go through a process model. So you could be looking at the sequence context of the process model and not your client sequence file.
I recommend reading that link I posted above. UI Messages are your best bet but you cannot just piggy back on an existing UI Message like this. They may not be getting sent at the time you need them to be. The only way to ensure you get what you want is to trigger one yourself at the right time.
Regards,
jigg
CTA, CLA
teststandhelp.com
~Will work for kudos and/or BBQ~

Has anyone seen the TestStand 3.5 User Interface disappear during testing?

The user interface disappeared while a test sequence was executing. The Windows Task Manager showed LabVIEW (8.2) and TestStand running but nothing was present on the taskbar for TestStand and the window could not be found. This has only happened once but I am being pressed to explain this hence the question.

plf,
By user interface you mean an operator interface?
If this is the case, what operator interface are you using?
Have you seen this several times?
What kind of sequence were you executing?
Regards.
Antonio Lie.

Slow User Interface Performance on a Mac Pro

I've recently purchased a late 2013 6-core Mac Pro with 16gb of memory and the 256gb SSD. While the general performance of Final Cut Pro X is outstanding (applying filters, transitions, analyzing for dominant motion, optical flow retiming, rendering, etc.), the user interface seems to still start to slow down the further along I am in my project. It is most noticeable when I click a clip in my timeline to modify a video property in the inspector, then hit play (spacebar) again to resume editing. At the start of a project, I can fly through my clips and edit without any hesitation, but as I near the 90 second-ish mark (with an edit/clip every 5-10 seconds), the responsiveness of the user interface starts to waiver just like my previous early 2011 Macbook Pro (something I thought was related to the graphics and/or system performance of computers from that era).
I've tried creating proxy and optimized media projects and even edited my h.264 footage in native, compressed format - regardless of what I try, the performance of the user interface is nearly identical until I start to hit a few minutes with some colour corrections on 25% of the clips. I've also experimented with the playback quality during editing (i.e., best performance vs. quality) which resulted in minimal performance improvements.
Clearly, this Mac Pro has been designed to tear through video footage and process mass amounts of data, but I wonder if there is something else looming in the code of Final Cut Pro X that, regardless of the computer in use, the user interface just gets sluggish at a certain point when a critical mass of edits/clips are in a project.
Any comments or feedback would be greatly welcomed, as I may decide to return this beast and settle on an iMac if this symptom exists regardless of what Mac I use.
Sincerely,
Ryan Smith

1. All of my media was located on the SSD installed inside the Mac Pro and is the startup disk of the computer
This will slow you down. Get a secondary drive for the media and Libraries.
2. The SSD had between 50g and 150g (depending on the project) available
That drive is becoming too full, and slowing down.
3. The project consisted of a single event from one import, about 100 files totalling 40g
A good USB 3 or Thunderbolt external RAID will fly through that without issue. The system drive will get bogged down.
4. I haven't paid close enough attention to Activity Monitor; I will start doing that, but FCPX is the only application I ever have open when editing and consumes about 12gb - 16gb.
16GB RAM should be plenty for FCPX. I've never seen it eat up that much RAM, even on very large projects. But more RAM won't hurt if the system is using that much RAM. How are you getting those RAM usage numbers?
The issue seems to be your drive. First, don't use the system drive, that will bog things down, no matter what type of drive it is. Second, get your media and Libraries on a fast secondary (external) drive.
Finally, are you running with the dual D500 or D700 GPUs? There is a significant performance difference between the two in FCPX and Motion 5. But I highly doubt that's your issue. I think you simply are eating up too much of your drive, and running off the system drive, both are huge no-no's.

Oracle User Interface slowness

Hello All,
One of the prerequisite requirements of Oracle RAC 11gR2 is to have a DNS server.
For this reason I configured a DNS server on Windows Server 2003.
What I discovered that from any client where I add the DNS server, any client I mean, windows, AIX .., all OUI become to slow, netca, dbca, Oracle Universal Insatller ...
any reason ? any solution ??
Regards,

Hello All,
To clarify my issue:
I configured a DNS server to resolve the SCAN Name.
Every thing is going OK on my servers.
I am able to ping the DNS server.
able to nslookup the SCAN Name.
able to ping the FQDN ....
The Only issue I am facing is that when I add the DNS setting to any client, Oracle user interfaces like (netca, dbca, OUI....) become to slow to move from one screen to another.
Regards,

Slow user interface

Hello all,
I have a program that's been getting fatter and slower as of late (about a hundred panels!). The CVI profiler doesn't work (there's another thread discussing this) but gprof and valgrind run fine on it. I discovered that most of the time is spent inside the cvi runtime engine in functions I have no access to but from some hints I think they are related to the user interface. I have a simple question: If I call SetCtrlVal repeatedly without changing the value (or SetCtrlAttribute without changing the attribute), does the user interface wastes time updating the control in the user interface ?
Solved!
Go to Solution.

In case of a hevy user interface vs. a fast acquisition process I have used a thread safe queue to pass data between the acquisition thread and a slow timer used to update the user interface. The timer works at 2 or 3 hz, while the separate thread is notably faster. I use a 1-element queue with auto flush so that the timer retrieve the last value put in the queue.
This system guarantees that the acquisition thread can run as fast as required while user interface updates do not stress the system unnecessarily.
In the timer of course SetCtrlAttribute (..., ..., ATTR_CTRL_VAL, ...) is mandatory.
Proud to use LW/CVI from 3.1 on.
My contributions to the Developer Zone Community
If I have helped you, why not giving me a kudos?

Why do I get -18001 Errors using Customised TestStand User Interface

Hi all
I have a problem when attempting to run my application on my host NT PC. I have a customised operator interface to TestStand written using Labview 5.1.1 and built using the LabVIEW application builder. I am running the TestStand Development (Run-Time) System on my host PC.
The problem is that as soon as I go to run my sequence of vis (mass compiled using the same version of LabVIEW and assembled for run-time distribution) I receive the error '-18001 VI Not Executable.'
I think this is probably to do with how I've included the ActiveX server in my LabVIEW User Interface application, but knowing very little about ActiveX I'm not sure exactly what the problem is.
If anyone
has any ideas, I would be extremely grateful for any assistance you could offer. My TS version is 1.0.1
Thanks
Dave

David,
I would like to add to Richard's input. The typical reasons a VI cannot be executed that cause this message are:
1) There is an error in the VI such that the run arrow of the VI is broken when the VI is open in the LV development environment. This problem is usually easy to debug because you should get the error (shown below) when running your sequence in the sequence editor using the default "LabVIEW" ActiveX server provided by the LV development environment (not the LV ActiveX server provided by your operator interface which is by default named "TestStandLVGUIRTS" ).
An error occurred in the 'MyVIStep' step of the 'MainSequence' sequence in 'MySequence.seq'.
LabVIEW : VI is not executable.
An error occurred accessing the LabVIEW ActiveX automation server. Error Code: -18001
2) The same error will occur when
a. you are using any LV ActiveX server other than the "LabVIEW" server provided by the LV development environment, AND
b. at least one of the called VI was not assembled for distribution properly. This means that not all test VIs and their *entire* hierarchy were distributed.
I am not sure exactly what you have done so have compiled some information that I think will help. Below I have included the document, Overview of Distributing TestStand when your Sequences use the LV Standard Prototype Adapter, which will appear in the NIDZ shortly. Another useful document is the NIDZ document Distributing LabVIEW Test VIs, which you can obtain from our website. Read these documents before preceding with the steps immediately below, which give you an example process for distributing. This may help provide a better understanding and guidance in the distribution process. We are working to simplify this process in future versions of TestStand.
For the following example distribution I recommend that you are use default shipping code so that the problem is not complicated with potential errors added through customizations you have made.
Building The Operator Interface
The following are steps if you are using a LabVIEW operator interface.
1) Copy the contents of \OperatorInterfaces\NI\LV to \OperatorInterfaces\User\LV.
2) Open a new VI in LabVIEW. Make sure all other VIs are closed.
3) In LabVIEW Select Tools>>Build Application or Shared Library
4) In the builder click the Load button and load \OperatorInterfaces\User\LV\testexec.bld. This build script is configured to create testexec.exe that contains the LV ActiveX server with the name of TestStandLVGUIRTS (see the Application tab of the builder).
5) In the builder click Build.
6) Once the application testexec.exe is built, run it once so that the server TestStandLVGUIRTS is automatically registered. You do not need to run a sequence. Close texec.exe.
Creating a LabVIEW Run-time Server
If you are using the LabVIEW operator interface then skip this section. The following steps are meant for those who use an operator interface written in a ADE other than LabVIEW. They provide you with a LabVIEW run-time server that is used by TS to run your VIs.
1) Copy the contents of \Components\NI\RuntimeServers to \Components\User\RuntimeServers.
2) Open a new VI in LabVIEW. Make sure all other VIs are closed.
3) In LabVIEW Select Tools>>Build Application or Shared Library
4) In the builder click the Load button and load \Components\User\RuntimeServers\LabVIEW\TestStandLVRTS.bld. This build script is configured to create TestStandLVRTS.exe that contains the LV ActiveX server with the name of TestStandLVRTS (see the Application tab of the builder).
5) In the builder click Build.
6) Once the application TestStandLVRTS.exe is built, run it once so that the server TestStandLVRTS is automatically registered on your development machine. Close TestStandLVRTS.exe.
Assembling the Test VIs for Run-Time Distribution
This distribution process uses one of the shipping TS examples that calls LV VIs.
1) From LV mass compile all VIs in the directory \Examples\AccessingArrays\UsingLabVIEW\. Please make sure that there were no error messages in the Status tab of the Mass Compile dialog box.
2) In the sequence editor open \Examples\AccessingArrays\UsingLabVIEW\AccessingArrays.seq
3) Confirm that the sequence runs without problem.
4) In the sequence editor select Tools>>Assemble Test VIs for Run-time Distribution.
5) If you are using TestStand 2.0 select \Examples\AccessingArrays\UsingLabVIEW\AccessingArrays.seq as the file from which the VIs should be assembled.
6) Set the target directory to be something distinct like C:\temp\AssblVIs.
7) If you are using TestStand 2.0 skip adding Dynamic VIs
8) Save with or without diagrams. Its your choice.
Change Search Directories
Once the VIs are assembled successfully, you must add the new target directory to the TS search directories.
1) In the sequence editor select Configure>>Search Directories.
2) Add your target search directory (e.g. C:\temp\AssblVIs) to the search directories.
3) Close the Edit Search Directories dialog box.
4) Confirm that your sequence steps now reference the assembled VIs. Right click on a step in the sequence and select Specify Module.
5) The dialog should show that the code module is found in the target directory (e.g. C:\temp\AssblVIs) that you just added to the search directories.
6) Run the sequence. This is the initial test to see if the VIs are assembled properly.
Switch the LV Adapter to use the TestStandLVRTS server or TestStandLVGUIRTS
1) In the sequence editor select Configure>>Adpaters.
2) In the Configurable Adapters control select the LabVIEW Standard Prototype Adapter and then click the Configure button.
3a) If you are not using the LV operator interface then switch the ActiveX server to TestStandLVRTS.
3b)If you are using the LV operator interface then switch the ActiveX server to TestStandLVGUIRTS.
4) Close the adapter configuration dialog boxes. You will get a couple of questions boxes. Just click OK each time.
5) Now run your sequence. If successful you are no longer using the LV development environment to run your VIs. This shows that the VIs were assembled correctly, the LV ActiveX server is working properly and that the search directories are configured properly.
You can now try and run the sequence using your operator interface on you development computer. If this test works it means that you have also confirmed that your operator interface is working correctly with all the other components. Now it is just a matter of moving all the component correctly to the target machine.
Distributing Components
-To distribute your operator interface use the distribution tool of the application development environment (ADE) in which you built your operator interface.
-To distribute the TS engine using the Run Engine Installation Wizard tool. This tool is typically not used for distributing your sequences and VIs, which you will probably distribute more frequently than the TS engine. It does distribute and register your LV run-time server (if you are using one) as long as you have stored it in \Components\User\RuntimeServers. It also distributes other TS components that you have stored under the directory \Components\User\.
-You can use whatever distribution system you like to distribute your VIs and sequence files (e.g. ZIP and network transfer are popular) . Ensure that you distribute the assembled VIs and not the development VIs. Also ensure that the location of the VIs on the target machine is one of the TS search directories.
Hope this helps.
Regards,
Kitt
=========================================
Title:
Overview of Distributing TestStand when your Sequences use the LV Standard Prototype Adapter
The general outline of the components to be distributed and the actions to take are followed by a more detailed description.
Components that need to be distributed:
TS engine
Operator interface
LabVIEW executable that will act as a LabVIEW ActiveX automation server (If the operator interfaces is written in LabVIEW, it can function as the LabVIEW ActiveX automation server.).
LabVIEW run-time engine
LabVIEW test VIs
Test sequence files
Actions before distributing:
It is recommended that you test the distribution components on the development machine before you distribute them to your target machine. In this manner you can more easily debug errors that you may encounter
Create the executable that will serve as your LabVIEW ActiveX server on the target machine (components 2 or 3 above).
Assemble the test VIs for distribution.
Update the TestStand search directories so that the sequences reference the assembled VIs.
Configure the LabVIEW Standard Prototype Adapter to use the LabVIEW ActiveX server that you will install on the target machine.
Test the distribution components on the development machine.
Enter section headings, separating each section with a line break:
TS Engine Component
Operator Interface Component
LabVIEW ActiveX Server
Configuring the LabVIEW Standard Prototype Adapter
LabVIEW Run-time Engine Component
Assembling your Test VIs for Distribution
Note
TS Engine Component
With any TestStand distribution you must install the TestStand runtime engine on the target machine. The Run Engine Installation Wizard tool, found under Tools menu of the Sequence Editor, facilitates this process. The wizard tool will create two files, SetupTSEngine.exe and TSEngine.cab. Move the two files to your target machine and run SetupTSEngine.exe to install the TestStand engine.
These installation files include the current configuration settings that exist in the Sequence Editor at the time the tool is invoked. It also includes all process models, TestStand types and step type modules. If you have customized components of TestStand and saved them under the directory TestStand\Components\User, then the components will also be included with the engine installation.
You must purchase at least a base deployment or debug deployment license for each machine on which you install the TestStand engine.
Operator Interface Component
You will also need to install an operator interface executable on the target machine. This program acts as a client to the TS runtime engine, controlling the execution of sequences and displaying their progress. TestStand ships with several versions of TestStand operator interfaces, which are written in different application development environments (ADE). For distributing the operator interface executable, refer to the application development environment in which it was created.
LabVIEW ActiveX Server
You must have a LabVIEW ActiveX server on the target machine. TestStand uses the LabVIEW ActiveX server to run VIs using either the LabVIEW development environment or the LabVIEW runtime engine. The LabVIEW ActiveX server is provided by either LabVIEW development environment or by any LabVIEW executable that has been built with �Enable ActiveX Server� selected. This setting can be accessed in the LabVIEW Application Builder during the build process. When this preference is enabled, you must enter a server name. You will use the server name to configure the LabVIEW Standard Prototype adapter in TestStand.
If your operator interface is written in LabVIEW, then it can act as the LabVIEW ActiveX server on your target machine. TestStand ships with two operator interfaces written in LabVIEW. The standard LabVIEW operator interface is located in TestStand\OperatorInterfaces\NI\LV, while a simplified version is located in TestStand\Examples\OperatorInterfaces\Simple LV. LabVIEW buildscripts are provided for these applications to facilitate building an operator interface in the latest version of LabVIEW. The settings of these buildscripts are such that the applications are LabVIEW ActiveX servers with the server names of TestStandLVGUIRTS for the standard operator interface, and TestStandSimpleLVGUIRTS for the simple operator interface. The applications register the servers the first time they are executed. If you want to manually register or unregister one of the servers, you can invoke the executable with the /RegServer and /UnregServer command-line arguments respectively.
If your operator interface is programmed in a language other than LabVIEW, then you will need a separate LabVIEW executable to provide the LabVIEW ActiveX server on your target machine. For this purpose, TestStand ships with a LabVIEW run-time server application located in TestStand\Components\NI\RuntimeServers\LabVIEW. A LabVIEW buildscript is provided for this application to facilitate building a run-time server in the latest version of LabVIEW. The settings of this buildscript are such that the application is a LabVIEW ActiveX server with the server name of TestStandLVRTS.
Note: When an ActiveX executable server is accessed, the executable is launched automatically if it is not already executing.
Configuring the LabVIEW Standard Prototype Adapter
When TestStand runs a VI using the LabVIEW Standard Prototype adapter, it does so using a LabVIEW ActiveX server. By default the adapter is configured to use the �LabVIEW� server, which is provided by the LabVIEW development environment. If you do not have the LabVIEW development environment on your target machine then you must configure the LabVIEW Standard Prototype adapter within TestStand to use a different server (e.g. TestStandLVGUIRTS, TestStandLVRTS, or TestStandSimpleLVGUIRTS).
To configure your LabVIEW Standard Prototype adapter, select Configure>>Adapters from the menu. In the Adapter Configuration dialog box that appears, select the LabVIEW Standard Prototype Adapter in the Configurable Adapters section. Click the Configure button. You can select or type a server name in the Select or Type Which LabVIEW ActiveX Server to User control. If your server name is not in the list you will need to type it.
As explained in the LabVIEW ActiveX Server section above, TestStand ships with LabVIEW buildscripts to build a LabVIEW operator interface and a LabVIEW run-time server application. These applications are LabVIEW ActiveX servers with server names TestStandLVGUIRTS and TestStandLVGRTS, respectively. You can configure you LabVIEW Standard Prototype adapter to use one of these servers.
LabVIEW Run-time Engine Component
If any of your sequence steps use the LabVIEW adapter or if your operator interface is written in LabVIEW, then you must install the LabVIEW runtime engine on the target machine. It is important that your LabVIEW run-time engine is the same version as the VIs that TestStand executes.
You can find installation files for the LABVIEW 5.1 run-time engine in the LabVIEW installation directory, Labview\APPLIBS\installs\RunTime. In addition, you can choose to automatically distribute and install the LabVIEW run-time engine with the distribution of a LabVIEW executable. Refer to LabVIEW documentation.
Assembling your Test VIs for Distribution
After distributing TestStand, you must ensure that your sequences are able to locate the VIs they call, and the VIs must be able to locate their required resources.
One common mistake is to simply copy the original VIs from the development machine to the target machine. Once you have configured your LabVIEW Standard Prototype adapter to use a LabVIEW ActiveX server other than LabVIEW, your sequence will not be able to execute your original test VIs that your sequences call.
TestStand provides the Assemble Test VIs for Distribution tool, which gathers test VIs and their required resources, and places them in a common location for distribution. You can then modify your TestStand search directories so that your sequences reference the assembled VIs. These topics are covered in the NIDZ document Distributing LabVIEW Test VIs.
Links: See Distributing LabVIEW Test VIs below
Note
Remember to test your distribution components on your TestStand development system before distributing TestStand. If the execution does not work on the development system it is not going to work on your target machine. On your development machine you have more ability to debug problems you may encounter.
Note: One common problem of testing distribution components on your TestStand development system is that your sequences reference the original Test VIs instead of the assembled test VIs. Refer to the NIDZ document Distributing LabVIEW Test VIs for assistance.
Once the components work on your development machine, you are ready to install them on your target machine. The order in which you install these components on the target machine is irrelevant.
==============================================

Error -17501 flxCVIadp.dll when starting CVI full featured user interface on Windows 7

We see the following error dialog when we launch the CVI full-featured user interface (TestExec.exe):
"Error:
Unable to load test environment adapter 'flxCVIadp.dll'. Run setup to re-install or remove this adapter.
Could not connect to TSAutoMgr.exe server. DCOM permissions might be incorrect because of configuration changes for remote execution. To fix this issue, ensure that the current user is in the default DCOM access permissions or that no users are in the access permissions section of the dcomcnfg.exe dialog box. You can use the dcomcnfg.exe program, located in the Windows System directory, to change DCOM access permissions.
Error code: -17501, Unexpected Operating System Error."
When this error happens, we can't run any calls to CVI code from within the User Interface.
We are running Windows 7. We don't see the error if we run TestExec.exe from the default location:
C:\Users\Public\Documents\National Instruments\TestStand 2013\UserInterfaces\Full-Featured\CVI
We get the error message if we copy the CVI directory to somewhere else on the C:\ drive (C:\MyUserInterface for example). The error happens when we run TestExec.exe directly, but it does not happen if we are already running Labwindows/CVI and we launch TestExec.exe from CVI.
We are seeing this error with both TestStand 4.2.1 and TestStand 2013 running on different PCs. This error happens on Windows 7, but not Windows XP. Though we get the same error with our custom user interface, we see the same error with the stock CVI full-features user interface provided by NI.
Any ideas about why we can run this from the TestStand directories, but not any directory on our C:\ drive?
Thanks,
Peter

Hi Peter,
Based on the error messages it looks like this might be a Windows 7 security issue, which would be why it doesn't occur on XP since security is handled differently in that OS. Have you gone into dcomcnfg.exe and checked the DCOM permissions as described in the error message?

Row currency has changed since the user interface was rendered.

Hi All,
we have developed and deployed an Application in Production, before four months,
Suddenly for the past two days we are getting an error after the page being idle for 2- 3 minutes.
Row currency has changed since the user interface was rendered. The expected row key was oracle.jbo.Key[3259 ]Once we get the error, the session scoped beans are resetting the values, and all the vo's cache are getting cleared(All the buttons in the page will get disabled and the menu will disappear).
but the same EAR is working perfectly in UAT and QA environments.
We have changed the "Enabletokenvalidation" as false and tested again, but the page itself is not loading after the change .
We have checked the Production and UAT weblogic server settings , but didn't find anything wrong.
WebLogic Server Version: 10.3.3.0
Studio Edition Version 11.1.1.2.0
if any ideas,
please help us...
Regards,
Ranjith

Hi All,
We have checked the error "Row currency has changed since the user interface was rendered. The expected row key was oracle.jbo.Key[3259 ]", we tuned the view objects, we changed the application page flows, and it is found that once we turn off the statevalidation (statevalidation =false), the error is not popping up, but it is getting fired in the server side as
oracle.jbo.JboException: JBO-35007: Row currency has changed since the user interface was rendered. The expected row key was oracle.jbo.Key[3259 ]
     at oracle.adf.model.binding.DCBindingContainerState.throwRowNotFoundException(DCBindingContainerState.java:318)
     at oracle.adf.model.binding.DCBindingContainerState.validateIterator(DCBindingContainerState.java:341)
     at oracle.adf.model.binding.DCBindingContainerState.validateStateFromString(DCBindingContainerState.java:482)
     at oracle.adf.model.binding.DCBindingContainerState.validateStateFromString(DCBindingContainerState.java:492)
     at oracle.adf.model.binding.DCBindingContainerState.validateToken(DCBindingContainerState.java:602)
     at oracle.adf.model.binding.DCBindingContainer.validateToken(DCBindingContainer.java:4852)
     at oracle.adf.controller.v2.lifecycle.PageLifecycleImpl.prepareModel(PageLifecycleImpl.java:117)
     at oracle.adf.controller.v2.lifecycle.Lifecycle$2.execute(Lifecycle.java:137)
     at oracle.adfinternal.controller.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:192)
     at oracle.adfinternal.controller.faces.lifecycle.ADFPhaseListener.access$400(ADFPhaseListener.java:21)
     at oracle.adfinternal.controller.faces.lifecycle.ADFPhaseListener$PhaseInvokerImpl.startPageLifecycle(ADFPhaseListener.java:231)
     at oracle.adfinternal.controller.faces.lifecycle.ADFPhaseListener$1.after(ADFPhaseListener.java:269)
     at oracle.adfinternal.controller.faces.lifecycle.ADFPhaseListener.afterPhase(ADFPhaseListener.java:72)
     at oracle.adfinternal.controller.faces.lifecycle.ADFLifecyclePhaseListener.afterPhase(ADFLifecyclePhaseListener.java:54)
     at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl._executePhase(LifecycleImpl.java:364)
     at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:177)
     at javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)
     at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
     at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300)
     at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:27)
     at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:57)
     at oracle.adf.model.servlet.ADFBindingFilter.doFilter(ADFBindingFilter.java:191)
     at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:57)
     at oracle.adfinternal.view.faces.webapp.rich.RegistrationFilter.doFilter(RegistrationFilter.java:97)
     at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl$FilterListChain.doFilter(TrinidadFilterImpl.java:421)
     at oracle.adfinternal.view.faces.activedata.AdsFilter.doFilter(AdsFilter.java:60)
     at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl$FilterListChain.doFilter(TrinidadFilterImpl.java:421)
     at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:247)
     at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:157)
     at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)
     at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:57)
     at oracle.security.jps.ee.http.JpsAbsFilter$1.run(JpsAbsFilter.java:94)
     at oracle.security.jps.ee.http.JpsAbsFilter.doFilter(JpsAbsFilter.java:138)
     at oracle.security.jps.ee.http.JpsFilter.doFilter(JpsFilter.java:71)
     at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:57)
     at oracle.adf.library.webapp.LibraryFilter.doFilter(LibraryFilter.java:160)
     at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:57)
     at oracle.dms.wls.DMSServletFilter.doFilter(DMSServletFilter.java:330)
     at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:57)
     at weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27)
     at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.doIt(WebAppServletContext.java:3684)
     at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3650)
     at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
     at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2268)
     at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2174)
     at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1446)
     at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)No Difference in server side configurations of prod and UAT
we are not using back button press or any other rowItearation in these pages and we are not changing the row key through code.
Simple Master page, with inline edit , add and delete with thousands of records.
Error is popping up after the page is being idle for 2- 3 mins. on the next request after the idle time, the error will pop up .
once the row currency error came, the current state of the view objects will get reset to the initial state(First row).
we don't know how to fix this issue, this issue is coming in production server only...
if any body comes across such an issue, please help us to resolve this issue..
Regards,
Ranjith C

JBO-29000: JBO-33035: Row currency has changed since the user interface....

I've a problem related to ADF that I don't understand very well:
JBO-29000: JBO-33035: Row currency has changed since the user interface was rendered. The expected row key was null
I read that is due to the Token and the functionality "Enable Token Validation" set to true (http://www.oracle.com/technology/products/jdev/tips/muench/paging/index.html)
this error appears rarely, and try again to do the same operation it work correctly.
Could be this problem related to the slow performances of the system(i.e. network problems, as performances, db performances that reduce speed of the system)?
thank you
Francesca

This error is not related to performance.
It can only be caused by submitting a page whose current row token contains the value of a key which does not match the key of the current row in the corresponding iterator when the server processes the request.
Often, it can occur if the user uses the browser back button to go back to a page whose current row token now no longer matches the actual current row in the iterator.

How Do I Reset Indicators in User Interface?

I have a VI that has got out of control. I have created several test sequences that were developed, proven and built into individual VIs. I created a Main VI and placed (cut and paste) each invidual test VI into a sequencial Frame. Long story short; The main screen looks good, but the test values and status indicators do not reset everytime the test is initiated (there is no loop).
Question- How do I reset each of my indicators on my user interface when the test completes?
Thanks in advance,
Rick Horwitz

Try the following: Got to "VI properties...execution". Now place a checkmark for "Clear indicators when called". That might be enough.
(If you are looking for a programmatic solution create an invoke node in the first or last frame as desired, wire it to a reference to the current VI and select method "renintialize all to defaults".)
LabVIEW Champion . Do more with less code and in less time .

SLOW Xbench User Interface Test

Similar Messages

Maybe you are looking for