j_meier

The last time I had this problem I found this: http://digital.ni.com/public.nsf/allkb/FB79ED8B6D07257B86256E93006E31FA Written for LV 8.2, still true in 2011 AFAIK.

Just for the record, in case someone runs in the same issue: - I uninstalled everything NI-related from the computer showing the problem - During uninstallation some NI-services refused to shut down (webserver-related). Had to kill then manually with the task-manager. - After installation of the latest RTE and drivers from the NI website the issue is gone. Now I only have to figure out if my local installer cache is corrupted and propagated the corruption to the installer I built. I fear a new installation of Labview will be necessary to make sure I build working installers... Thanks again to everyone!

Interesting how things change... I see now that I don't need it, but as cause of problems it got eliminated, too. The answer to this will depend on this question: If I draw the diagram disable structure around all of my code, does Labview still load driver, dlls or .net assemblies in memory and starts them enough to allow them to hang? I hope not! Assuming it doesn't, I'll download a (hopefully) clean version of the RTE and install it on my test computer. The taskkill solution does work. For now this gives us something we can work with, but it has to go, the sooner the better.

Thanks to everyone for the suggestions - problem is that they didn't solve the problem. What I tried: - remove "Quit Labview" and replace it with a "Close Front Panel" - remove Splash Screen and start Main app directly. - deactivate SSE2 optimization - comment out all code calling dlls or hardware drivers - comment out ALL code Now I have an application that displays a front panel and a start button on the toolbar. Which does nothing, of course. I can now go to File->Exit and close that window. Guess what, on a computer with DevSystem my "application" goes out of memory (true for all edits to the code I tried), on the one with only the RTD the window disapears, the entry in the task manager stays. Specifically, if I don't hide the root window with the .ini file, I can actually observe how the application windows disapears for a moment before a new window shows up in the taskbar. I believe this is this root window, it doesn't display if I select it. What is this "root window" for, anyway? A place for the RTE to live in? I'm now going to implement the "taskkill" suggestion to give our users something to work with and have a chat with the folks from NI. General comment: For years now I was living under the impression the "Quit Labview" vi is intended to shut down the RTE (Who needs to shut down the dev system?). Thats why I thougth it had this boolean input (RTE or not?). It always worked, I never questioned it... Thanks again, Ciao, Joachim

Hi there: I have an issue here that has me stumped: I can not completely exit an application when it is built in a executable and running with the Run-Time Engine unless the development system is also installed. Full story: - The application should close when the user clicks on a "Exit" button. - An event sructure catches this value changed event, closes all running loops, i.e. shuts down hardware, saves the vi configuration and exits. - To close the built executable I execute the "Quit Labview" vi, with the boolean input set to true if the vi is not executed under the development system. - I have now added some dignostic code around this, an indicator to see if the bool is truly true, and a delay to keep the window open to see it. - From this I know that with the RTE the "Quit Labview" vi is called with a TRUE input, and it should close everything (the vi and the RTE) - The "Quit Labview" vi is the last vi in my code, this was verified by tracing the execution in the development system (Labview 2011 SP1). - On MY computer this works, in the development system and with the built application. - On a second computer that has the development system and the RTE installed it works, too. - On a computer that has only the RTE installed the window of my application closes, but the application remains in memory, as seen in the windows task manager. I have to kill it there. - If I use HideRootWindow = False in the ini file of the executable the RTE root window survives in the taskbar. - This last computer is fresh out of the box, has a clean installation of the OpSystem (XP, don't ask why) and only the RTE and Labview drivers installed to execute this one application. - The RTE was installed with an installer created for this application, on my computer, pulling the installers out of the cache created during the installation of Labview on my computer. I'm lost in two ways now: - I don't know why this does not work on the computer without the development system. - I don't know how to debug this. Due to the commercial nature of the project I can not post the code here - hopefully my description is enough to understand the problem. Any hints would be greatly appreciated. Ciao, Joachim

Hi Rolf: Thanks for taking the time to reply. Always good to hear the history of other software packages. Just make one thing clear: I don't see MView as a competition to LuaView. I would advise anyone in a commercial environment to not use MView. I can not give support beyond posting here, and the moment you have to dig through the source code to make a small change or fix a bug you have lost any savings on the initial investment. On top of that I'm building on the work of two other "lone" projects (parser builder and the lexer/parser engine) which may become unusable in an other environment (think new version of the OpSys or Labview, 32/64 bit etc...) The reason I like it is that it decouples the script from the Labview application - you do get full access to all features of the non-scripted application without work for the Labview developer. On the other hand, this can be a desaster when someone writes in FPOs nobody has a business to write (MView does no check if a FPO is an indicator or a control or if the control is disabled, it just tries to set the value via property node). A second advantage is that the script can actually react to a changing FPO while it runs. Like watching for a FPO value to settle down and then continue. This changes the form of use from "Do something and give me the result" to "interact with the FPO and/or the hardware the FPO represents". The two combined were the reasons I set it up that way. Something a LabView developer could just drop on the diagram and give his user the ability to use scripts within the final application. I never thought about something that resides inside the LabView application and is inaccessible to the end user. Apart of that I have no clue how to make a script node. The more I think about that the more curious I get - do you have a description how you did this for LabPython somewhere?

Considering that you mentioned low cost and NI rarely falling in that category: Check this out: http://labjack.com/ Labjack offers a Labview driver that I found to work well. I would still expect that you need a current amplifier to drive relays, and independent on your choice of hardware I would strongly recommend a flyback diode. An interface PCB like Brenton suggested would be a good solution. Another alternative would be: http://www.toradex.com/products/Oak/OakRelay With this you get the interface problem solved (at least for low currents in you relay...), but you need five of those boards. Toradex also offers a Labview driver that works well.

Sam: First, thanks for the feedback. Perhaps I should use this to give a feedback what happened to this projekt, considering that I posted first on June 17, 2010 and it's been now two years: The big thing I intended to do did not happen - cleaning up the code. I did change some parts of it, but mainly to fix bugs and add some functionality, but it gets nowhere to the standard for a submission in the LAVA code repository. And extrapolating from the last two years this will not happen... I can say that the tips some of the residents gave me two years ago have been helpful for my work. This is in general true for a lot of threads on the LavaG forum and the reason I follow the RSS feed. (That's why I saw your post!) Kudos to all the regulars! I've attached the latest version I have, I would be happy if someone can use it. It is now for Labview 2011, and I had to delete the old atachments to stay below 10MByte - so the 8.6 version is gone. MView.zip This file does not contain the OpenG vi's I'm using! Considering the trouble I had the last time to upload something useful, please let me know if you run in trouble opening the project. About your questions: I'm using the Report Generation Toolkit, so yes, if you don't have it the old version won't work. Sorry, not been thinking. In the version I uploaded I commented it out. I believe this will allow you to open and run everything. If you run in problems, the offending vi is a subvi in MViewFunctions.vi just delete the one disabled vi in the Default case. The Mathscript node is totally removed - I hope. It's been a long time. IIRC, I only used it for the colon operator; if you want to know why I did this in the first version look in Colon.vi and at http://www.mathworks...lution=1-4FLI96 Using the Mathscript node was an order of magnitude easier to do what Matlab does. After I got Labview 2011 I switched everything to formula nodes and changed the colon.vi to do what the m-file on the Mathworks website does. About LabPython and similar scripting solutions like LuaView: Yes, I know them. But my original objective was not to redo their work, but to learn something. I'm programming since I was 12 - 28 years ago - and in all this time I never learned how a compiler or interpreter works. One day I wanted to know, and reading books alone gets boring after some time, so some programming was needed. Next thing I did was cheating and using the GOLD Parser builder as lexer/parser. But the interpreter is mine. And it's Labview all the way. When you come from the application side: Cons: - My code is slow compared to everything else. - Handling different datatypes is pretty limited - it only knows bool, double and string arrays up to dimension 2 (i.e. scalars, row/column vectors and 2D arrays) - Don't try to work with huge amounts of data, the internal memory management is bad - everything in a huge array of clusters of arrays... The ability to dynamically allocate memory would help here, but this is Labview. Love it or... (Hey, I just had an idea: Dynamically calling a vi that acts as buffer - similar to a functional global - but is reentrant, use the reference to the clones like a pointer in c...could mimic malloc... I have to think about this...) - There is no such thing as a manual...just a few demoscripts. If you know any textual language, I'm sure you figure out what is going on. - There is one lone developer who did this for fun, and has now found other fun things to do, and LabPython and Python, well, I heard some rumours that there is more than one. Pros: - You can change the script at runtime. The Labview Formula Node can't do that. LabPython can as long as you don't use the script node but the vi's. I'm not sure about LuaView. - It can get and set the data from any front panel object that can be mapped in the above listed datatypes. AFAIK, LabPython needs to be feed with data with the Set/Get Data vi's, and those need to be hard-wired. I don't know how LuaVie does this. Anyway, everything MView needs is that the user knows the name of the FPO. - If you understand the interpreter code, you can call native Labview vi's (Look into MViewFunctions.vi and it's sub-vi's - The absence of comments make it probably unreadable, but that's my fault.). Then it gets actually fast! - I'm able to train someone who has a basic knowledge in textual programming within one hour to use this to script everything (well, almost ) an user sitting in front of a Labview application can do. - Compared with LuaView it's cheap. I hope this helps you, if you have more questions - if I can I'll answer.

Take a look at this: http://zone.ni.com/d...a/epd/p/id/3971 HTH, Joachim

Good tips. Now I only need to learn to do something like that CONSISTENT. I'm weak, I'm weak, ... I dream of free-hand wires... Just kidding. Have to check this out. It's obviously better to read. Gosh, how do you sustain this during debugging/trying out when your not sure what will work best? A little addendum to the project: Included here is a modified version of the demo vi and reworked example scripts. The demo assumes that there is a loop handling the user interface, a loop doing some hardware stuff (I'm imitating a temperature controller), and one want's to include scripting. I hope anyone who has experience with a text-based language can understand how MView works after reading through the example scripts. And a LabView question: The memory management of this code is...well...lets say not great. I wanted something quick and easy to implement, so I ended up with arrays in clusters in arrays, and I see problems with speed and expect problems with memory allocation because of the requirement to have arrays in continuous memory. For now I won't change it, but just a thought: Labview has an interface to it's memory manager for external code, with ways to dynamically allocate memory when needed. Is there a way to use this from within LabView without writing an extensive wrapper? Ciao, Joachim

You are right. And a test-vi is broken. Here they are: Put them in the MView directory and it should work. I also had to learn that some of the included demo-scripts don't work since my last round of ..ahhm.. bug-fixes. I'm preparing a new release with this issues resolved. Thanks. Thanks to you and asbo for the tips. I knew already how to force empty space into a diagram. I have two problems with it: What you said - the movement off all other code. It makes it sometimes look worse. And in a vi like this interpreter, with its endless sequence of case-structures, should I force space into one of them, I have a larger number of mainly empty cases. Most of the time no issue, but if the vi grows over my screen-size, I stop. The cleaner way would be to make a sub-vi. But one little change still fits in, right? To avoid the work of making a new icon, wiring up the front panel, giving good names to the FPOs, etc. And then another fix is need...lets squeeze everything a little closer together, right?

Hi Neal, Hi everyone: thanks for your reply in general and for the positive response on top of it And sorry for the long time for me to come back to my own thread...summer vacation, and then all hell broke loose at work. I hope you DON'T know what I'm talking about. ..difficult to follow... Yeah, after taking a long break working on it, I had the same problem. ...straight wires... My big weakness: good planing. First there is so much space, and then it gets crammed, and then...curves, bends, this vi could still fit in that white space, now where to put this wires? etc. How do you fight this? ...icons... Learned this now. I'm not good with graphics, so I'm just typing the vi-name in the icon. Helps a lot about readability. ..SVN... Yes, I'm using TortoiseSVN. As I'm working alone on a hobby project, it's more of a backup system, but the most useful I know. I'm using the Labview Builder to export the project with it's dependencies, and it grabs the .svn folders when I'm embedding directories in the project. I'll ignore that for now About the project: In the time I found to work on it some changes happened: The tree-control did eat a lot of time. It's gone. It was nice to visualize the syntax tree, but...so much CPU time, for so little! The recursion is gone. It was the second time-waster. Now the interpreter uses a stack. To implement this was fun, but the code is now totally unreadable. Better planning would have helped. To much trash is now left from the first version and then while I was figuring out how to do this some concept errors happened that are now not fixable. Without rewriting most of it again. The grammar is almost fully implemented, the only important thing I put in the definition file for the parser that is not in the interpreter are the switch structure and the break/continue commands for flow control. Ability to call subroutines (functions like in Matlab, and other scripts with a "call" command) works now. And there are predefined functions implemented in Labview in this version. See the file "internal functions.m" in the "Scripts" folder for a list. I recompiled Ege Madras parser engine with a higher limit for the token stack. Modified source code and compiled dll is in the attachment. What is still missing: Cleaning up the code. Bug-fixes. Manual. Yes. A manual. Anyway, code is attached, if I find the time I'll clean it and hopefully bring it to certified standard. Might be a while, though... HTH, HAND, Joachim

Hi all, Hi jgcode: Been working on the attachment issue... Had to disable all Add-ons in Firefox, now I see a "Attach This File" Button. Hope this works... Will need th hunt down what this is in my browser. Joachim

Hello there, first post here, so perhaps I should start with introducing myself. I've used LabView for about 10 years. For work to hack together some quick automated test routines for instrument control and data acquisition. Outside work I use it like a kind of hobby program language, mainly just messing around with it to see how it works and what it can do. For many reasons (read the NI ads...) it has become one of my favourite program languages, next to Matlab. I never released any code to the public. I never had formal training, and I thinks this shows in my code. What I'm releasing here is something I worked out in the last few weeks as a hobby project, it's now at a point where I think it could actually become useful. I'm looking for comments and criticisms on the code and the general question if this is useful and should be completed. What I tried to achieve is to add a script language to Labview. It should be a simple language, text-based, capable to interact with arbitrary front-panel objects, easy to add to an existing vi and working in the absence of the development environment. In difference to the MathScript or formula nodes it should be able to interact with anything on the front panel and not being limited to controls hardwired to the node. The script should be exchangeable at run-time, even when an executable has been built. Basically, it should be able to do everything a person can do with the front-panel. My approach was to use the GOLD parsing system ( http://www.devincook.com/goldparser/ ) to create a language similar to Matlab, the Intel x86 Assembly Engine by Ege Madra ( http://www.devincook.com/goldparser/engine/assembly-x86/index.htm ) to parse the user created scripts, and the attached Labview code to make it work. Somehow. It's not finished by far. What is working so far: - basic math and logic operations - comparisons - variables (doubles, strings, 1D and 2D arrays) - flow control (for loop, while loop, repeat until, if-elseif-else) - reading and setting values on the front panel. The attached zip file contains all vi's necessary to run what I have so far, inclusive dependencies (OpenG vi's and the Tree Control Toolkit by Norman J. Kirchner). A demo application is TestLoop.vi, there are three scripts in the script-folder that work with this application. Flaws I'm aware of are that it's slow, verging on sluggish (I've used a recursive interpreter design pattern, and recursions are a weakness with Labview, eh?); that I changed it so often to get to this point that I would need to do a serious cleanup of the code; that there is no documentation and of course, IT'S NOT FINISHED. Anyway, please take a look, and as said above, any sort of feedback is welcome. Ciao, Joachim