Argold

I'm confused. There is also a 4.0.0.4 version on Github. Which is the one that is available on the LabView tools network via VIPM?

Thanks Rolf: After the discussions here and in the thread about using Python to create user events. I think I do want to look under the hood of LabPython. But I am a bit confused about the source relation between Github and the version on the labview tools network. Both of these are 4.0.0.4 (2011) Do your know who, if anyone is maintaining it?

So i did a little searching down this path, and it does look like you can make calls to/from Python via LabWindows/CVI. However I do not have that (yet) and wonder if I need to get it. I'm thinking instead if there is a similar thing like a PVI" that anyone has thought about... This actually looks promising: http://www.ni.com/white-paper/8911/en/ It talks about calling C-style DLL's from Scripts..

I don't see how getting the reference from LV each run would be a problem. The communications would need to be two-way but they need to be anyway, so it should be do-able. What you suggest about passing strings to LV is what a wrapper for the clonable modules would need to do. Again, I'm looking for a solution where I can use the modules pretty much as designed (much more elegant and does not break the way they are already used within a LV framework). I'm still hoping it can be done, and thank's for all your advice so far, Eric.

Thank you but No, I use user events all the time. I need the Python code to generate the User Event, I'm studying up on "PostLVUserEvent" right now. if it can be done in C, it should be able to be done in Python!

Yes, pretty simple. Still looking to see if anyone knows how to generate a user event....

funny, that is not there for me: In either Chrome or IE.:

Thank you for taking the time to do this. FYI, my colleagues here pretty much stick with Py 2.7, telling me that many of the scientific packages have not yet been ported to 3.x. I am new to Python. I noticed that same thing on the GitHub. I spent some time with the Actor Framework a while back and decided it was overkill for even some of the big projects I do. So i ended up making my own stand-alone, cloneable/pluggable module template that depends on user events for communications. I have been developing hardware abstracted (IVI compliant) clonable modules for instrumentation in my lab. My (new) goal is to use python for test automation so folks do not need to be labview coders to create new test rigs using my modules. So for me, event generation really is key because I don't want to go back and re-write my modules. An alternative would be to make wrappers for them, but it would be best if I can just natively generate the user events. I am encouraged by the post from ShaunR in the other thread. So for now I'll keep looking for a way to generate events. I'm out of town next week (at the IEEE PES JTCM) so there will be a break from this discussion for a bit... Allen

Thanks: Ok, so when I do that and select "See my Activity>Status updates" it shows "nothing here yet". I am unable to locate the place where I enter my status update.

I don't see this status widget, but I would like to use it. Has it been "updated away?" Where can I set it?

Thank you again Eric: Can you do me a favor and save the .vi as LV14? I choose not to upgrade under my motto: "if it ain't broke, don't fix it" Allen

Thank you Eric for the reply and all the reading. I looked at Enthought and came to a similar conclusion from their marketing materials. Yes, that GitHub does look interesting. I'll check it out. I'll pass on Featherweight for now while I try to learn the basics. Later it might be interesting. On your last comment, believe it or not, I'm already there. Each of my major functions are completely stand-alone cloneable modules which are abstracted using plugins. They are launched by, and use user events to communicate with, a framework. The framework can be LabView or Python assuming I figure out how to generate the user events in Python, hence my subsequent thread which you already replied to. Allen

The title asks the question.

Thank you Rolf: It is really great to hear from the original creator and I'm glad you are keeping an eye on things. I was hoping that I could use some kind of scripting language such as Python or LUA and LabVIEW could pass references to the controls which could be overwritten by the script language. It sounds to me that that is the difficult and brittle (if not impossible) thing to do. In the meanwhile I have been trying to write a crude script Interpreter state machine completely in LabVIEW and have gotten as far as being able to handle nested FOR loops. However I am not sure how to do things like have a script create local variables (such as "A=3.5"), then later use things like A = A+B, etc. Even more difficult would be to have a variable set to a reference to a control then use it to perform math. this project seems to be very limited and would require my users to learn a strange sort of syntax that the LV interpreter can handle. So I'm still hoping for some way to use an existing scripting language and will continue my search and trying out a few things.. It does not sound like you are recommending looking into Lua for LabVIEW ether...

Hello there: I have a big project, pretty much already coded in Labview, designed to perform monte-carlo analysis on a set of applications that use data from time synchronized measurements across the electrical power system. The project is designed to be open source and distributable using both built .exe and vipm. Therefore I include ONLY libraries that either come with LV or are OpenG (no third party tools that need to be purchased, and no TestStand). A part I have yet to code is the monte-carlo engine which needs to be end-user programmable. I have an idea for creating my own set of commands and a labview interpreter, but before I do that, I'm thinking that many of my end users will already have some python ability. So I'm trying to decide to use labPython. The problem is that I have not found any documentation or examples for it yet. What I need to do, is have the python script, written by the user, access controls (mainly clusters or 2-D tables), overwrite the LV control values, then start a test run. This is essentially test automation. Python would be nice because then the user can use local variables to calculate the values to be written into the controls. So I'm looking for your advice: Should I give LabPython a try? If so can someone: 1) point me to some documentation 2) point me to some example code (especially how to access controls). 3) tell me where to go when I need to ask for help (this forum or another) Thank you so much.

O.K. so it sounds like the preferred answer is to launch it with a VI server and time that out. It is not a matter of trust, I cannot control who the users are. I'm just trying to provide them an environment where they can develop their matlab scripts with some decent error handling.

I'm writing an application where users can plug in their own matlab code via a Mathscript "wrapper". I need a way of timing out the matlab in case the user creates an infinite loop. Does anyone know if mathscript provides a native timeout (google didn't find anything when searching "mathscript timeout"). If not, does anyone have any good (hopefully simple) suggestions? Thanks!

I just posted my take at updating the error handling core on: https://lavag.org/topic/10741-updating-the-labview-error-handling-core/ I can cross-post here if there is any interest. -Allen

I have attached my first take on an Error library. TestError.vi demonstrates its use. The ideas behind this are: The Labview native error system can only carry one error at a time, this carries an array of errors. This uses a tag for severity <sev> and a tag for priority <pri>. I decided to make the severity tag a string rather than a enum so programmers can create their own severities on the fly. They may or may not choose to modify the error handler to accommodate these. An enum of severities might be better, I'd like to hear what folks think. The error handler dialog has native support to the following severities: Fatal: some applications that can be stopped dead may want to do an immediate stop on Fatal (like the native system does when you press "Stop"), other apps that must cleanly shut down can try a minimum clean shutdown) Critical: must stop but the application should do its best to cleanly exit. A difference between a non-immediate-stop Fatal and Critical might be Fatal will evoke a minimum required shutdown while Critical can evoke a full clean shutdown) Abort: processes or state machines can be aborted (for example a state queue can be flushed) but the application can continue to run) Warning: warn the user about something and continue Inform: like a warning but it evokes an error, not a warning. Log: No dialog is shown but gives the programmer a chance to log the error or warning. The priority tag is used to sort multiple errors. The ParseErrors.vi will place the lowest number priority first in the array so they can be handled first. The test application is only one way to use the library, there are many other ways. For example, in the test program, when multiple errors occur, all of them are shown to the user before the program exists or continues. Another application may want to stop on a fatal error without trying to show the lower priority errors to the user. I'd be happy to hear some critique of this. Allen ErrorLib.zip

As I understand Labview convention, if the code is non-zero and the status is false, then it is a warning.

To give this thread a bump, and to redirect the discussion to a different thread: I have been commenting recently on an old 2009 thread that was the result of a 2009 NI week presentation. The thread had some good code examples and a video of the presentation and some slides. I'm working through that all to understand it and possible continue the work. There was a nod to this thread in an earlier post: Unfortunately "Handling Core" is a bit of a misnomer, because the code was not about error handling but a means to carry multiple errors or much more error info (such as priority and severity) in errors. One method used OO-in-Native Error Clusters (NEC) and allowed for special error classes, The other allowed for multiple errors to be carried by putting NEC into OO. A suggestion in the thread suggested both: NEC-in-OO-in-NEC. and that is where I'm thinking of taking it. The beauty of this is that it "may" be able to coexist with NEC alone, which would keep the overhead down as it would only be used where needed. Anyway, go on over there and see what I mean, this may be some valuable stuff. -Allen

Yes, that was the actual point of this thread and the 2009 NI week lecture that it was based on. I don't think "handling" really belonged in the title of this thread... I'm working through the example code right now and it looks kind of promising, once I wrap my head around it all, (possibly needing to do a UML diagram of both the OO-in-NEC and NEC-in-OO examples), I might take a crack at implementing the NEC-in-OO-in-NEC idea. That other thread does look interesting, I'll look through it. Because of the nature of my project, an application which has launched clones of stand-alone, pluggable modules, needs to know: 1) When a clone has a fatal error, so the clone can be unloaded as gracefully as possible and the launching app can decide what to do. 2) When the user needs to perform some action (for example, point to the correct file when a file is not found, or tell the program to cleanly abort the operation) in progress. 3) When some kind of parameter is input beyond it's operating range, so the system can either limit the parameter and try again, reset the operation and inform the user that the parameter must be changed before trying again. 4) When something needs to be logged but the user does not need to know (though my system also has status message broadcasts). 5) When there is an issue in a state machine such that it needs to be reset and/or the user informed of the issue. Just a few handling examples off the top of my head. The above discusses severity, priority is important when sorting the order in which the errors are handled. For example, if 5 errors occurred and one of them is fatal, then that should probably be handled first, However severity and priority do not always go hand-in-hand. These are all handler issues, but as you say, first what is needed is a better core system.

Thanks again Shaun: I had a look and see what you are doing in the source string by formatting the codes into it. This is not really what I'm looking for however. Since there are multiple clones with plug-ins in my project, we may not know all the error codes at design-time. Plug-in child classes can be made by the user and new error codes may be created after code release. I'm hoping to find something following the NI week lecture from 2009. I'm looking for both multiple concurrent errors and priority/severity. As I said earlier, the idea of NEC-in-OO-in-NEC is very interesting and I'm looking to see if anyone has followed up on the work started in '09.

Thanks Shaun: I'll have a look at it and get back to this thread. From the log image you posted it looks like it has a type, which I guess could be a priority or severity or possibly treated as, for example, a 2-nybble uint-8 with 16 priorities and 16 severities...

So if there is any interest, I'd like to either get this thread started again or get some links to other threads or discussions. I have been programming in LV for about 6 years (I've been programming for over 30 years now in several languages). I have never been really happy with LV native error handling. I'm architecting a new, large project, leading 5 programmers, and I want to make sure we start off with a robust error system. The project will include hardware abstraction using plug-ins, clonable modules that run independently and communicate through Request and Broadcast events (one of the broadcasts being an error event). So I need an error handling system that encompasses the concepts of severity and priority and allows for multiple errors to be carried. I'm intrigued by the idea of NEC-in-OO-in-NEC that was mentioned earlier in this thread and would like to explore that further. The best thing would be some example code, but barring that, a discussion here or links to other discussions would be helpful, thanks. I'll post next week about some of my ideas for the specifications for an error system... Cordially, Allen Goldstein, NIST