Experiment at ~24 Run Time - To Be Expected?

I've put together a pretty straightforward experiment using an SVM to address a classification problem. The experiment has run all steps successfully, but has now been in the "Evaluating" phase for ~21 hours.
As a cloud service, I was under the impression that there was some scalability behind it, so I shouldn't be seeing this. The model is only working on a moderately-sized dataset (~300k rows by ~20 columns).
Is this situation "normal"? To be expected? I've done this same project on a smaller subset on my local PC in R, and the result was that no classification predictions could be made. Is it likely that AzureML is having the same
problem - where a prediction can't be reliably made, and so it's just cycling forever?
Thanks for your input.

Experiment Link
However, I have no option to view the Output Log, either from the Properties Pane of the studio, or from Right-Clicking on the Evaluate Model module (the View Output Log is greyed out, and not selectable).

Similar Messages

Does the definition of "Execution State" equals "Bad" change between development environment and run-time?

My basic question is:
If the execution state of vi is "bad" under the development environment, shouldn't it also be "bad" under the run-time environment?
So here is the background:
So I use SVN and I ran into this problem where I would be working on one piece of code without having my top-level vi open and would inadvertantly break the top-level vi. And being in hurry or whatever I would not open the top-level vi to check the run arrow and I would check in my code, which of course breaks the top-level vi for everyone else and causes lots of problems.
So to solve this I wanted to create a Tortoise SVN client side hook to check the check the top-level vi(s) to see if the run arrow was broken before I commit my changes. I'm trying to use the Execution State to check this. I am using an Equals primitive to compare it to a "Bad" constant. (as a side question is checking the execution state the best way to do this? or is this even a valid way to do this? It's the only way I've found so far to check the run arrow.).
So the way I'm going about this is:
1. I create a executable (written in LabVIEW) which is run by TSVN
2. When TSVN calls it (I set it up as a start-commit hook) I pass it a parameter which is text file which lists all the top level vi(s)
I do these first 2 steps in order to make it as generic as possible. I can use it on any project with any number of top-level vis (or dynamically called vis) all I do is point it to a different text file.
3. Inside the executable I just read the list of vis, open a reference to each one and check the execution state. I do this inside a for loop, but keep the references open and close them after the for loop in case they share some subvis or libraries, so they stay in memory (could this be the cause of some of my problems??)
4. Then after the for loop executes and the references are closed I simply fire off a popup if any of them are broken.
5. Then I simply exit LabVIEW to return control to TSVN.
So my problem is this:
In the development environment everything works as expected. But when I try the exact same thing in the executable it tells me the run arrow is broken.
Why the difference? I'm checking the same list of vis and the runs arrows have not changed, they are still all good.
So it appears that checking the execution state to see if it is bad behaves differently in the run-time versus the development environment.
Can anyone confirm or deny that?
It seems to me that it should behave the same.
The help for the Vi.Exec.State property says that it works in the run-time (Read-only), so why am I getting different results?
On a side question if anyone knows of an easier way to accomplish what I want to do, please let me know. I went this route because I had some experience with writing TSVN hooks and I thought it would be pretty simple and it is if I can get this comparison to behave.
edited to fix a typo and to remove the duplicate attachment
Attachments:
Check Run Arrow_BD.png ‏6 KB

I believe that plugins rely on the libraries being located in a specific location. The installer can place these libraries in the specific location or some other installer can do that. You can create code that scans the library directly to "learn" what packages/libraries are available. Then you would build the path to that VI and open the reference to it.
Mark Yedinak
"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot

"no data found" run-time error masking SQL/report mismatch

Hi all,
At last, figured out a vexing problem and wondering if anyone else either:
a) has also hit the problem, and hopefully
b) has figured out a clever way around it.
Namely, in our AppEx apps, we rely on SQL query generation from PL/SQL packaged functions. This "best practice" promotes reuse, automated testing, etc. Great idea - works great.
However, we've repeatedly come across a situation where we go to run a page with a report on it only to get a "report error: ORA-01403: no data found" message where the report should be. Not much to go on. After trial and error, it turns out that simply going to the Region Definition page (where the PL/SQL function call is defined) and clicking the "Apply Changes" button cleared the problem up.
Mystifying because the actual SQL query generated by the PL/SQL is valid (we've got a nightly testing job that pulls the PL/SQL function calls out of the AppEx metadata tables, executes them to get back the SQL and then validates the SQL).
Turns out this problem looks to be a result of columns changing in the actual SQL itself, and hence not matching up to the Region Attributes (column names, one assumes) that AppEx knows about. Simply clicking Apply Changes causes AppEx to validate the returned query and then it adjusts the column attributes (one assumes) so that things match up.
So - the $64,000 question(s):
1) Are there any cool AppEx APIs to be able to try and detect this situation? Given an app of middling complexity (50-100 pages, each with various queries/reports), this is not an attractive issue to deal with manually.
2) Any cool AppEx APIs to fix, or auto-sync these situations? (Essentially programmatically calling the "Apply Changes" button if you will).
At a minimum, it would be great if AppEx could be updated to put out some kind of more informative error message when this occurs - maybe something along the lines of "Region Attributes Do Not Match Data Returned from Query", or something like that at least.
Thanks for any input/ideas,
Jim C.

Thanks to all for your prompt responses.
Vikas actually did me the favor of pretty much clarifying my info for me (tks Vikas). Yes, to all the above. It's PL/SQL code generating a SQL query, so 1 is (a); we want to use query-specific columns so it is (2a). And yes, the whole problem is that the something does change to cause the SELECT statement column list to change...nature of the beast, so "don't do that" doesn't really help here.
Scott - sorry, should have been more explicit. Basically, we have a PL/SQL function behind a report that returns a SQL statement for the report. If that PL/SQL code changes to add a new column to the report (without going to the corresponding Report Attributes page and clicking the "Apply Changes" button to get AppEx to revalidate the query), then you wind up with this "no data found" error msg, which doesn't exactly point you to the root of the problem.
It seems as though the "parse at compile-time" is really what's going on here. There must be some kind of "run-time" check going on as well, that is resulting in the "no data found" message. Seems as though it ought to be fairly straightforward to add some kind of check at run-time to handle that exception a little cleaner. Is there an official process to register a "Request for Process Enhancement" for AppEx to do this?
In the meantime, thank you Vikas for the pointer to the APEX_APPLICATION_PAGE_RPT_COLS view - that looks like it will do the trick nicely. Given that, we can now add logic to our nightly "app tester" job that can compare what columns AppEx expects to find in a given report (for a given page) with the actual SQL (coming back from the PL/SQL function call) to essentially "validate" the AppEx meta data and at least let us know when these things get out of sync.
BTW - if anyone would be interested in the actual contents of that "app tester" logic, I'd be happy to post it (someplace...here? Studio site?). It's basically just a PL/SQL block of code that currently runs in cron that just validates any SQL embedded in our app. (I suppose it is a little "hard-coded" since it does use our naming conventions for packages/functions to parse the PL/SQL calls from the Meta Data but it might still serve as a usefull starting point...) Since our AppEx app(s) sit on top of a database schema that is in fairly constant flux, we need the ability to know when somebody has changed something in the schema that needs to be accounted for in AppEx. The job primarily just parses the AppEx meta data to find PL/SQL function calls that return SQL, executes that PL/SQL to get the generated SQL, then just validates that SQL and reports back any invalid SQL calls. Perhaps we're in some unusual development environment (15-20 people working on a database schema with 700-800 tables/views) but it seems as though it would be fairly easy, for anybody using PL/SQL to generate SQL (which is a GREAT and powerful thing, by the way - thanks to whoever thought that up in AppEx land) to run into this issue.
Jim C.

Unable to run vi with labview run time engine

Hi All,
I have a VI that controls and reads from an NI PXI Spectrum Analyser (5600). The VI works perfectly as expected, I can make a project of it and create a runtime application and installation with no problems, using Labview 8.6.
When I make a call to it from Test Stand 4.1 it works lovely.
When I change the VI adaptor in Test Stand 4.1 from development to use the LV Run Time engine 8.6 it fails to work, Test Stand gives the following dialogue (see attached).
I have uninstalled all older versions of Labview as I've had similair issues before, I've mass compiled everything I think is associated with this VI.
I don't really understand! And am tearing my hair out.
The only idea I have is that perhaps there is something in one of the 5 DLLs that is causing a problem or the NI_AALBase.lvlib, NIAALPro.lvlib or NI_PtbyPt.lvlib librarys that are password locked and I presume don't get mass compiled.
I have attached the problemVI.lvproj.
Thanks for any advice or help.
Matt
Attachments:
problem VI.lvproj ‏41 KB
teststand.JPG ‏43 KB

Matt,
it sounds like you are having older versions of toolkit/driver VIs in your application. In developement environment, this works since the dev-system is capable to recompile older VIs just during loading and therefor not having issues with older versions.
Running the VIs using the Runtime Engine, recompilation is not possible. Because every VI knows "its version", the VI will not be executable unless the RTE version matches the VI's. If the VI is older (or newer, doesn't matter), the observed error occurs.
Please make sure that you have current versions of drivers and toolkits installed in your LV environment instead of simply copy them from older versions of LV (this would be the common source for such issues).
hope this helps,
Norbert
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.

LabVIEW Run-time Engine 7.1.1 installation failure on Windows 7 SP 1 32-bit

I am attempting an installation of LabVIEW Run-time Engine 7.1.1 on my Windows 7 SP1 32-bit OS computer and the installation hangs. This happens near the beginning. Is there a compatibility issue? The window does not have any error messages. It says: "Updating System, The features you selected are currently being installed." The progress indicator blinks periodically, but does not move forward. Please help. Thanks!

I recently tried to install the LabVIEW 7.0 runtime engine on my Windows 7 (64 bit) machine to try out an old software. Ended up removing it quickly again, since any LabVIEW version I started up after that, including LabVIEW 2013 showed an installation dialog on startup about (updating installation information, please wait!).
Basically there are so many possible problems why it could fail. Apparently the runtime engine installer had played with some other NI component that he had no idea would ever exist when it was created and caused that component to always think it needed to update itself to finalize its installation. In your case it could be anything from a missing Visual C runtime version framework that the installer simply expects to be present but doesn't since Microsoft has in the meantime released about 5 versions of Visual C and doesn't install all runtime versions anymore on newest Windows. Or it could be a conflict with your hyper-duper .Net Framework 4.5.x.y that the installer does not be prepared for. Maybe that or something else was not present on your 64 Bit machine where you could install the runtime engine.
Basically the reasons for the install to fail are legion, and trying to figure it out is always more hassle than moving on and let old software be old software.

"open vi reference" with run time menue

Hello,
I met some problems with "open vi reference" in labview.i can't parallel run this vi with the run time menue.i can't load the any vi then the run time menue has activation.(the "open vi reference" can run after the run time menue release.). it's means labview is serial running for this both function.but now i want to parallel running in the program.so would you give the some idear?

Now I see what you are talking about. What you are trying to do is expected behavior. If you click on the menu while any state is running that doesn't lock the front panel, then the menu will halt the VI execution until you choose a menu item.
You should check the option in the event to "Lock front panel until event case for this event completes" Then you will not be able to click on the system menu until tthe VI is launched and running. If you wire a True like I suggested before, then you will fall out of the case pretty quickly in non-hoghlight mode, and the user most likely will not notice. If the VI you are trying to open is quite large, it will take a little bit of time for LV to load the VI into memory.
In highlight-mode, you just have to wait for the event to process before you select the menu.
Message Edited by Matthew Kelton on 12-03-2007 10:56 PM
Attachments:
edit events.png ‏27 KB

Add Jcombo in Jtable at run time

hello,
i want to add jcombo box in jtable every cell & i also add column in run time.proble is when i add new column that time last column combo is add but prievious column its remove automatic.
so give me some code & where i can get see good example for add combo in jtable.
thanks

hi j-rg,
It was really appreaciating to c ur reply, regarding the specific problem.Actually wht i was facing the peoblem, Am adding a colomn in the run time and in that column am adding a combo in each cells of that column.AS i was expecting am able to add a new colum in th erum time with the combo in each cells of that column,now when am adding another column in the run time am getting all the required things,but the problem is " in the previous cloumn am not getting that combo"(only the combo is been added in the last column).
What am expecting is the combo should be there in each cell of the column(all columns)
Am also sending the code wht am using, plz have a look below,
df1.addColumn(result);
TableColumn aa= tb1.getColumnModel().getColumn(tb1.getColumnCount()-1);
aa.setCellEditor(new DefaultCellEditor(comboBox));
wating for ur reply
thanks and regards
sandeep

How to choose RT System at Run Time

Variations of this question have been asked, but I'm not sure if they've been answered.
We use LabVIEW RT to do a variety of behavior tests. We have multiple experimenters using the same hardware, and each has his/her own set of "What I want to do" requirements.
Originally, we used LabVIEW 7.0 (i.e. Before Project) to develop a Host and Remote (PXI) application. The Host application was built as an .EXE, while the Remote was saved as an .LLB, copied to the PXI, and "invoked" at Run Time by calls to VI Server. Note that this means that the code on the Remote might (is?) not be as compact, efficient, or optimized as if we had built an .EXE. But we definitely can have Bob's Experiment, Jane's Experiment, and Joe's Experiment on the PC (as separate executables), and each could respectively call Bob's RT, Jane's RT, or Joe's RT on the PXI at run time. No need to have LabVIEW (or LabVIEW expertise) on this system, and Bob, Jane, and Joe can be "ordinary users".
"Modern LabVIEW" takes a slightly different (and probably better) view towards Real-Time -- both the Host and Remote programs are built as Executables (the RT is built as an .RTEXE). We can "pre-deploy" the RT code to the PXI, and set it to run at Startup. This makes getting the RT side "running" semi-automatic -- all you need to do (if it isn't running) is reboot the PXI.
But what if you want Bob, Jane, and Joe's version, selectable by running (on the Host) Bob, Jane, or Joe's Host application?
I'm playing with the following algorithm, which seems to work. I'm presenting it here to get feedback, especially if there is a "better way" to do this.
The key to this method is that there is an .INI file on the Remote, C:\ni-rt.ini, that contains, among other things, the RT Target's Startup Application path (by default, this is C:\ni-rt\startup\startup.rtexe).
Consider three Projects, Project Bob, Project Jane, and Project Joe. Within each Project, a Host executable is built having a name like "UI Bob" (or "Jane" or "Joe"), while the Target executable is given the name "RT Bob" (or "Jane" or "Joe"). The three .RTEXE files are copied to the Target and placed in the Startup folder, C:\ni-rt\startup.
Now run one of the Host executables. It does the following:
FTP a copy of C:\ni-rt.ini from the Target to itself.
Get the name of the Startup .RTEXE.
If it is the "appropriate" name (i.e. if the Host program is UI Bob.exe, the Remote should be RT Bob.rtexe), do nothing, as the Target is already running the right code.
Otherwise, we need to force the Target to run the correct Target code. We can do this by changing the Startup entry in the .INI file to the Remote code we need (for example, RT Bob.rtexe), then tell the Remote to Reboot. When it comes back, it will be running the appropriate RT code.
The Host now goes ahead and tries to connect to the Remote. If a connection cannot be established (for example, the Remote code might have stopped), a Reboot of the Remote might fix things up.
Short of trying to write a single enormous program that encompasses every experimental scenario and situation (i.e. have a big Case Statement with a Bob, Jane, or Joe "choice", and a single executable that had everyone's code in it), this seemed to be a fairly simple way to have the robustness of compiled executables on both the Host and Remote machines, yet maintain the flexibility to let the (non-LabVIEW-guru) User choose which executable to run.
I haven't fully deployed this system -- I'm currently at "Proof-of-Concept" stage, but I've got the various "pieces" working. Does this seem like a sensible appropach? Are there other, simpler, ways to accomplish this?
Bob Schor

Hey Bob.
So I assume you're -completely- working with built executables? You're not going to work in the editor environment to modify your projects at all?
If this is the case, then having a generic deployment phase at the beginning of the executable (with a "setting up hardware for your app" splash screen) isn't a bad idea -
Check the binary on the target, ensure it matches the binary you have on the host machine (in case you ever decide to update).
If they don't match, FTP the new file down to replace the old one.
FTP the ni-rt.ini file, ensure the startup exe is enabled and is pointing to the correct location.
If it's not enabled or not pointing to the correct startup file, modify the .INI file and FTP back to the target.
If you had to update the INI file, ask target to reboot itself. Wait 30 seconds, and wait for target to become available again.
Connect to the target. If you cannot connect, reboot target. If the target comes back and you still cannot connect to the app, notify user.
That's almost exactly how we handle installation and deployment via MAX.
The big assumption here is that the built executables were all built with the same version of LabVIEW Real-Time. If not, you'd need a system replication step in there to make sure the proper version of LabVIEW is on the target before launching the built .rtexe.
-Danny

NI-DAQmx Run-time Engine

Is a run-time version of the NI-DAQmx v8.6 driver available yet? I'm distributing an application from LV 7.1 that requires DAQmx and want to include this as part of the installation. I found run-time packages for v8.3 but I'm using v8.6 in my development work so hate to switch to an older version. Are there any compatibility issues in using v8.3? Thanks.
Art

HI Paul,
Thanks for your suggestions. Just prior to receiving your response, I had in fact tried to build just an installer for the daq driver from LV 8.5. The problem is that it forces the project to be saved before it will create and installer and then proceeds to include the empty project and the LV runtime engine. In my case, I named the project test and the installer created c:\test on the target and installed the LV runtime as well as the daq driver. I also ended up with a regiestered application - test. Once I manually uninstalled test, I had the result I wanted, but too long a path to get there.
I bit the bullet and migrated the code from LV 7.1 to LV 8.5 so that I could build a comprehensive installer. Generally, things turned out well. My biggest question is why the application builder / installer insists on putting both LV 8.2 and 8.5 RTE on the target. I want, and expect, only LV 8.5 RTE. I'm have installed and am running off of the 3rd Q release for the NI developer suite. Why is 8.2 RTE loading and how do I correct this?
Another strange result is that my daq device and channels do not show up in MAX. I included the level 5 daq driver and MAX in my installer as well as the hardware configuration. The application works ok, and if I manully import from my *.nce file then I get a warning that my device will be replaced. Is this normal? The GPIB controller shows up as normal. The only thing that seemed odd during installation was that the daq driver didn't complete installation after restart because I forgot to plug in the daq device cable. Afterward it seemed ok.
I also have a couple of bugs with the application builder / installer. I converted my LV 7.1 build script and made needed changes. I see the following behaviors.
1) I have setup a file to install into a subdirectory. Every thing works ok except when I subsequently go back into the Installer Properties window and go to the Source Files. I see two problems. First, in the Project View my files are in the correct locations, but the icon for the one in the sub-directory is switched with the very last one in the list. Second, in the Destination View the next-to-the-last file from the Project View is the one shown in the sub-directory while the file that should be in there is listed directed below it in the list (but not in the sub-directory). Everything installs to the correct location, but this maked it very confusing to edit the installer.
2) Whenever I use the Build All command, the application builder fails with the following error. If I start the build individually from the Properties window, then the build completes successfully.
Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:
Error 1 occurred at Copy in AB_Engine_Copy_Error_Files.vi->AB_Application.lvclass:Copy_Error_Files.vi->AB_Application.lvclass:Copy_Files.vi->AB_Build.lvclass:Build.vi->AB_EXE.lvclass:Build.vi->AB_Engine_Build.vi->AB_Build_Invoke.vi->AB_Build_Invoke.vi.ProxyCaller
Possible reason(s):
LabVIEW: An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.
=========================
NI-488: Command requires GPIB Controller to be Controller-In-Charge.
C:\Program Files\National Instruments\LabVIEW 8.5\user.lib\errors\McPherson-errors.txt
Thanks again for help.
Art

Run-time error SAPSQL_ARRAY_INSERT_DUPREC occurred

When creating a new SyncBo (T51) instance after syncing eventually MI Clients shows the following message:
[20070315 01:28:14:343] E [MI/Sync ] Received exception info code 10 and detailed message "Exception while callSync: The ABAP/4 Open SQL arrayinsert results in duplicate database records. records in the data base."
In sm21 shows message:
AB0 Run-time error "SAPSQL_ARRAY_INSERT_DUPREC" occurred
AB1 > Short dump "070316 205056 sapnw ELDA " generated
Looking for SAPSQL_ARRAY_INSERT_DUPREC error in SAP Note we found the note 817849 (Runtime error SAPSQL_ARRAY_INSERT_DUPREC occurs during sync).
We have downloaded and applied this note in Backend as note requires and ALL prerequisites of this note. Also we have upgraded to SP19 and Kernel to 155 (part 1 and 2). But problem continues and the client that happened this problem does not work any more, all new SyncBO instances created goes to MEREP_MON as Waiting status.
The dump on duplicate record is happening when the user is synchronizing and when a record is getting inserted to table merep_10100.
The solution /workaround could be to do a client reset for those devicesand test again and see if it is happening, but error returns happening after this.
When this happen SyncBo instance keeps on Waiting status (MEREP_MON). We couldn't understand why this happen suddenly and then no more new SyncBo could be created, all goes to Waiting status. Reprocess (ShiftF5) or start handler (Shift10) does not take any effect.
Best Regards,
Rogério

Hi Ajith
I am getting the same error and below is the error message from ST22. The only change is I am using for MTR application and the sync fails for the 2nd time when synched for patches for the MTR application. As it is generic sync, could you please advice to get rid of the problem.
An exception occurred. This exception is dealt with in more detail below
. The exception, which is assigned to the class 'CX_SY_OPEN_SQL_DB', was
neither
caught nor passed along using a RAISING clause, in the procedure
"LOG_INSERT_DB" "(FORM)"
Since the caller of the procedure could not have expected this exception
to occur, the running program was terminated.
The reason for the exception is:
If you use an ABAP/4 Open SQL array insert to insert a record in
the database and that record already exists with the same key,
this results in a termination.
(With an ABAP/4 Open SQL single record insert in the same error
situation, processing does not terminate, but SY-SUBRC is set to 4.)
Thanks, Raj

Run time error while creating billing doc.

Hi all,
While saving a billing document I am facing runtime error every time. Can any one help me what are the possible reasons and possible solution to overcome this. Since it is on high priority, expecting response at the earliest.
Sunanda.P

Dear Sunanda,
Since it is on high priority, expecting response at the earliest.
You must get in-touch with your BASIS-Admin, for earliest resolution of the error, as he is the only one, who may find the reason and fix the same, at earliest.
Or,
If, you could provide System error-log, at the time of Run-time Error, then, some work arounf could be suggested.
Otherwise, It would be like Hit-n-Trail.
Best Regards,
Amit
Note: This is, what I feel and suggest, in such cases:
[ABAP/ Runtime Error|Re: update control terminated error]

Sequence will not validate with run time prompts in business rules

I am in Hyperion Planning v 1.1.1.3, with Workforce initialized. I am creating a sequence of business rules. The rules use run time prompts within them and validate when used on their own. However, when I insert them in a sequence the sequence will not validate, apparently due to the run time prompts.
The sequence returns the error: Cannot calculate. Essbase Error(1200323): Error parsing formula for [FIX STATEMENT] (line 7): expression expected after [(].
Line 7 in the business rule is as follows:
FIX ([rtpYear],[rtpScenario],[rtpVer],[rtpCC],[rtpBU],[rtpEmp])
The problem is not isolated to this business rule, it occurs with any rule I try.
Can sequences function with run time prompts in the included business rules?
Stephen

I have figured out that if any rtp is hidden in the business rule, the sequence will not validate. Is this expected behavior for sequences?
Additionally, hiding the variables in the sequence has no effect if the variables are not hidden in the rule. When launched from a menu in a web form, the user is prompted for values for all variables (except for the Execution Database Name) although they are prepopulated based on the members in the POV, Page, etc. Is this also expected behavior?
I also find that it won't validate if "Merge launch variables" is selected (I have included rules associated with different plan types and with different dimensionality, so this may be expected). The user is prompted to provide values for every variable in each rule in the sequence, many of them duplicates (though, again, they are prepopulated based on members in the form).
Stephen

Install labview 6.1 (or compatible) run-time engine with labview 2011

I have installed a trial period version of Labveiw 2011 in order to check for possible upgrade issues I may have if I decide to upgrade from labveiw 6.1. Well, needless to say there have been alot. That is as expected since I have not updated labview in many years. I am still not under any pressure to update; however, I would like to in order to get support and make sure I do not have any compatibility issues with new equipment purchases. I have been able to resolve most of my compatibility issues with simple code fixes and such. However, twice now I have run into an error when launching labview executeables compiled by two different equipment manufacturers. The equipment I am using is not even old...maybe a year or so. When I launch the labview executables to control this equipment on a PC that has the trial period labview 2011 installed, I get an error message stating something like " This requires a Labview 6.1 (or compatible) run time engine." I have tried to download and install the 6.1 labivew engine but I can't install this engine on a PC which has labview 2011 installed. Can someone explain how I am to run these executables under labview 2011. I can't imagine these executables were developed using 6.1 since this equipment is not even a year old now.
Solved!
Go to Solution.

Im not for sure I am on the same page with you here. Im not trying to develop any code myself. I have some labview executables that came with hardware we purchased in order to control it. We used to have labview 6.1 installed; so everything was working ok. But now that I have installed 2011, I get an error message when trying to run these executables. The error message states that this executable requires a labview 6.1 or compatible run-time engine. I have seen this error on both XP and Windows 7 machines. I did not develop the executable, it was developed by the hardware manufacturer. But since this hardware is only about 1 year old, I an assuming they used a newer version of Labview to develop this code. Certianly newer than 6.1.
So I guess my question is..is there a way for me to get this executable to work on a PC that has labview 2011 installed. I have tried to install a labview 6.1 run time engine but it will not install. Any other options?

Help needed to record an experiment for a running process

Hi Team,
While trying to record an experiment through Profile Running process option, we found issues in generating an experiment file.The error stated that the directory wasn't writable but we made sure all the permissions are available for the folder. The application is a C++ implementation.
Have attached the output message:
Running: /x/opt/SolarisStudio12.4-beta_mar14-linux-x86/lib/analyzer/lib/../../../bin/collect -P 16824 -o test.1.er -d /x/web/STAGE2LP14/xxxx -p on -S on
name test. is in use; changed to test.4.er
Reading xxxx
Reading ld-linux.so.2
name test. is in use; changed to test.4.er
Reading libppfaketime.so.1
Reading librt.so.1
Reading libpthread.so.0
Reading libcrypt.so.1
Reading libz.so.1
Reading libdl.so.2
Reading libkrb5.so.3
Reading libicui18n.so.36
Reading libicuuc.so.36
Reading libicudata.so.36
Reading libicuio.so.36
Reading libexpat.so.0
Reading libqpidmessaging.so.3
Reading libqpidtypes.so.1
Reading libxerces-c.so.27
Reading libstdc++.so.6
Reading libm.so.6
Reading libc.so.6
Reading libgcc_s.so.1
Reading libk5crypto.so.3
Reading libcom_err.so.2
Reading libkrb5support.so.0
Reading libkeyutils.so.1
Reading libresolv.so.2
Reading libqpidclient.so.6
Reading libuuid.so.1
Reading libselinux.so.1
Reading libqpidcommon.so.6
Reading libsepol.so.1
Reading libboost_program_options.so.2
Reading libboost_filesystem.so.2
Reading libsasl2.so.2
Reading ISO8859-1.so
Reading libcollector.so
Attached to process 16824
t@4133656384 (l@16824) stopped in __kernel_vsyscall at 0xffffe410
0xffffe410: __kernel_vsyscall+0x0010:    popl     %ebp
Process ID: 12981
dbx: The HW counter configuration could not be loaded
Elapsed Time: 85 ms
Run "collect -h" or "er_kernel -h" with no other arguments for more information on HW counters on this system.
Execution completed, exit status is 0
dbx: Creating experiment database /x/web/STAGE2LP14/xxxxxx/test.4.er (Process ID: 13736) ...dbx: Creating experiment database /x/web/STAGE2LP14/xxxxxx/test.4.er (Process ID: 13736) ...
dbx: Experiment directory not writable
Experiment aborted
error at line 16 of file 'dbxcol3wC1XU'
detaching from process 16824
Even we tried manually using the collect command the process started successfully but while terminating the process using CTRL+ENTER we got coredump error
f7f40000-f7f50000 rwxp f7f40000 00:00 0
f7f50000-f7f6b000 r-xp 00000000 fd:00 589838                             /lib/ld-2.5.so
f7f6b000-f7f6c000 r-xp 0001a000 fd:00 589838                             /lib/ld-2.5.so
f7f6c000-f7f6d000 rwxp 0001b000 fd:00 589838                             /lib/ld-2.5.so
ffbe7000-ffbfc000 rwxp 7ffffffe9000 00:00 0                              [stack]
ffffe000-fffff000 r-xp ffffe000 00:00 0
dbx: internal error: signal SIGABRT (sent by tkill)
dbx's coredump will appear in /tmp
We arent sure how to terminate the collect process manually.
/x/opt/SolarisStudio12.4-beta_mar14-linux-x86/lib/analyzer/lib/../../../bin/collect -P 16824 -o test.1.er -d /x/web/STAGE2LP14/xxxx -p on -S on
Please help us
Thanks
Sattish.

Hi Darryl,
We tried with the below mentioned option
./collect -P 24829 -o /tmp/test.9.er But still the same error
NOTE: No J2SE[tm] was specified for checking.
    The following J2SE[tm] versions are recommended:
      J2SE[tm] 1.7.0_25 or later 1.7.0 updates (preferred)
NOTE: You can download and install the J2SE[tm] from http://www.oracle.com/technetwork/java/javase/downloads.
WARNING: Java data collection may fail: J2SE[tm] version is unsupported.
Reading atlasserv
Reading ld-linux.so.2
Reading libppfaketime.so.1
Reading librt.so.1
Reading libpthread.so.0
Reading libcrypt.so.1
Reading libz.so.1
Reading libdl.so.2
Reading libkrb5.so.3
Reading libicui18n.so.36
Reading libicuuc.so.36
Reading libicudata.so.36
Reading libicuio.so.36
Reading libexpat.so.0
Reading libqpidmessaging.so.3
Reading libqpidtypes.so.1
Reading libxerces-c.so.27
Reading libstdc++.so.6
Reading libm.so.6
Reading libc.so.6
Reading libgcc_s.so.1
Reading libk5crypto.so.3
Reading libcom_err.so.2
Reading libkrb5support.so.0
Reading libkeyutils.so.1
Reading libresolv.so.2
Reading libqpidclient.so.6
Reading libuuid.so.1
Reading libselinux.so.1
Reading libqpidcommon.so.6
Reading libsepol.so.1
Reading libboost_program_options.so.2
Reading libboost_filesystem.so.2
Reading libsasl2.so.2
Reading ISO8859-1.so
Reading libcollector.so
Attached to process 24829
t@4133668672 (l@24829) stopped in __kernel_vsyscall at 0xffffe410
0xffffe410: __kernel_vsyscall+0x0010:   popl     %ebp
dbx: The HW counter configuration could not be loaded
Run "collect -h" or "er_kernel -h" with no other arguments for more information on HW counters on this system.
dbx: Creating experiment database /tmp/test.9.er (Process ID: 7769) ...
dbx: Experiment directory not writable
Experiment aborted
error at line 15 of file 'dbxcol61PZeE'
detaching from process 24829
Could you please review
Thanks
Sattish.

Combining package configuration and Execute SQL task at run time

Hi everyone,
I have an issue regarding setting values at run time
I use package configuration to manage different enviroments scenarios (DEV, PROD):
XML file to store the connections string of SSISConfigDB
and the actual values of parameters in that SSISConfig DB tables Filtered by ConfigurationFilter column
Now, one of my packages needs in addition setting at run time value of a flat file name
i used an Execute SQL task - within the task i read into a variable the file name using command line
then, the full path of Flat File Connection is set by expression concatenating the root folder and the variable
the problem is that the variable stays empy! as if the Execute SQL task was never executed!
Am i doing something incorrect? in the package configuration wizard the configured value are only XML file and the connection string of the DB.
to summerize - how can i combine package configuration, default value, Execute SQL task and expression at runtime?

1.EvaluateasExpression=TRUE (Full Path variable)
2. Do you mean to invlole a ISNULL() function in the expression? if so, no
3. Of course i recieve a valid value
4. The Full path expression is evaluated to the root folder - without the portion of the file name
here is the syntax in Execute SQL Task:
truncate table OnErrorFlagTable
Declare @Path varchar(128)
Declare @FileName varchar(128)
Declare @SenderID varchar(5)
Declare @INST_COD varchar(5)
Declare @Flag int = 0
Declare @FileType varchar(2)='01'
Truncate table TraumaRecords
Select @Path = 'C:\RootFolder\'
--***Insert into Temp table the file so we can take his name***--
Create Table #Tmp(Txt Varchar(Max))
Insert Into #Tmp(Txt)
Exec master..xp_cmdshell 'Dir *.txt C:\RootFolder\/b'
select top 1 @Filename = Txt From #Tmp
Where ISNUMERIC(substring(Txt,1,1))=1
order by Txt desc
Insert into OnErrorFlagTable
Select 2,@FileName
Select @FileName as TraumaFileName,@FileType as FileType
Then, in ResultSet TraumaFileName and FileType are mapped
Expression of @TraumaFlatfileFullPath is
@[User::TraumaFlatfilePath]+ @[User::TraumaFlatFileName]
where the variable @[User::TraumaFlatfilePath] is evaluated in variable window (default value)
and it's value is C:\RootFolder\
and @[User::TraumaFlatFileName] is the ResultSet of the ExecuteSQLTask
and for some reason when executed in SSIS return null while in SSMS return the expected value
Can you try making this into a procedure with required parameters and call it from SQL task to see if you get return value correctly? Use OUTPUT parameters for getting back required values
Please Mark This As Answer if it helps to solve the issue Visakh ---------------------------- http://visakhm.blogspot.com/ https://www.facebook.com/VmBlogs

Experiment at ~24 Run Time - To Be Expected?

Similar Messages

Maybe you are looking for