Edit code during execution

[EMAHJ]

It would be great to have possibility to change/edit the code when a VI is running in "Suspend when called mode".

This would be a code developer ultimate dream when you are into development of new code or just fault finding in old code.

During development or fault finding when/if you are using "suspend when called"-functionallity for a sub VI in your code.

I mean when the sub VI is "paused" and waiting for you to press the "run" button, right there, possibility to edit the code for that VI and run it ones, change the code (perhraps changing some timing or changing a formula of an calculation or both or change execution order for some settings of the DUT etc etc) a little bit and run it again, tweak it a little bit more and run it again... AND THEN exit the sub VI (with "suspend when called") and CONTINUE with the rest of the CODE like nothing have changed!

A kind of possibility to change the code during execution, just for  VI/s that you have chosen "suspend when called" for.

What a functionality when you are into fault finding and testing out of new developed code! ! ! !

I think that this functionallity would make a big difference between text-based coding and using LabVIEW in matter of how easy development or fault finding can be done.

[altenbach]

If this is a normal subVI (not reentrant or subroutine priority), the front panel controls will be populated with the actual values when the VI is called AND the front panel is open. So simply open the front panel before running the calling VI to populate the controls of the subVI with typical data.

Now stop the main VI. At this point to can re-run the subVI as many times as you want and edit in-between and it will always have the last data in the controls. Maybe temporarily add some graph indicators to show the generated data in more detail.

This is probably sufficient for most typical cases. 

[Norbert_B]

altenbach's recommendation is (as most often) very good. But it does not cover cases where you use specific parameters like references to that subVI in question. Point is that the reference is most likely not valid when re-running the VI.

To add an important side note:

LV is a compilation language. So code has to be recompiled each time you make changes and start an execution. Due to optimizations made by the compiler, a change in a subVI will result in a recompilation of the calling VI as well.

With that information and from that point of view, your product suggestion is very close to "impossible to implement". Also, if it would be possible (and done), each execution had to use its own data, so for medium/large sized project, it will run out of memory quickly if not a pure 64bit application. And even there, you will run into performance impacts quite fast.

Last point: I cannot think of useful use-cases other than the one altenbach already provided a good workaround. Another option which could be more your requirement is "Retain Wire-Values", which is a feature already available for a couple of versions. So if your use-case is different to something these two approaches cannot solve, please explain it in detail. Finally, i still doubt an implementation of this idea as mentioned above: close to impossible to be implemented.

just my 5 cents,

Norbert

[Manzolli]

QuickBasic 4.0 documentation cover in 1987. This and the following versions allow the user change the source code, up to certain point, with no need to restart.

[Intaris]

Doh. That is possible due to the dual nature of Quickbasic (Interpreter within the IDE and compiler for outside the IDE)

From Wikipedia (All hail Wikipedia!)

Microsoft's "PC BASIC Compiler" was included for compiling programs into DOS executables. Beginning with version 4.0, the editor included an interpreter that allowed the programmer to run the program without leaving the editor. The interpreter was used to debug a program before creating an executable file. Unfortunately, there were some subtle differences between the interpreter and the compiler, which meant that large programs that ran correctly in the interpreter might fail after compilation, or not compile at all because of differences in the memory management routines

^{This request would require an interpreted version of LabVIEW to run within the IDE when debugging.....}

^{That would be a MAJOR piece of work.}

[Norbert_B]

Ah, i completely forgot: The request does have parallels to repeated module tests. Therefore, i think that Unit Test Framework could also be a suitable answer for this request.

Norbert

[EMAHJ]

Woobsi, sorry, didn´t know about QuickBasic..

Then LabVIEW is some step behind in this area.

I think you all are more wise than me..

I know about the compiling stuff and that the possibility I "want to have" might/is hard to implement, no doubt!

But hey, future enables new solutions!

Like Norbert_B have written, just stop the application will not help, not me anyway.

Of course I/you can always change the architecture due to the fact that Labview lacks of this functionality and code for easier debugging.

But I would love to focus more on fault handling than code for debugging..

Yeah I know you can do them both, if you are a good programmer, I know, but hey, all of us are not that good, not in the beginning 😉

As an example, I’m running a big mobile base station system and there are many things to configure, some of the configuration needs to be done in a certain order enable other configurations by entering different modes etc.

In some cases the system need a restarts (15min) just because of a change in the configuration..

The system is in its development phase and the software functionality seems to change often which effects the behavior/conditions for the configuration, doing things in the wrong order/setting will make the system turn into fault mode.

Sometimes the wrong configuration might be possible to over write but sometimes the system needs a reset (15min). In this development work I would love to have the functionality of editing the code during execution, it would help me..

Regarding the compilation of the code..

I’m not an expert in anyway just a novice programmer in LabVIEW.

But setting a sub VI to “suspend when called” before execution starts would enable some kind of Compilation of the code that is before the “suspend VI” and then compile the rest each time the “suspend VI” executed.

I’m just thinking freely without knowing what I’m talking about, you who are compile experts can tell for sure!

In my little “dream world” this “edit-during-execution-functionality” would ONLY occur when a VI is set to “suspend when called” not in any other case!

Thank you all for very interesting comments to this post ! ! !

[Intaris]

Don't misunderstand me, I think the possibilities which would be made possible by this idea are really wonderful it's just that having some knowledge of HOW this would need to be achieved makes me think it's lovely but not really very realistic due to the amount of work which would be required for this.

Then again, wasn't LabVIEW 1.0 an interpreted language?

[EMAHJ]

Ok Initaris, thank you for supporting the idea!

I know that this feature is not like changing the structure of a cluster or making a loop functionality more easy to use.

This is a completely new feature in LabVIEW, making LabVIEW even more user-friendly, and that is what I think of LabVIEW, it enables the user ! !

Perhaps the idea is out of the box, but it is an idea of how I would like LabVIEW to work, it would a difference for me, in my daily work.

[Norbert_B]

Honestly, most programming languages don't provide that feature because of the issue Shane (Intaris) already quoted.

And just for the book: Quickbasic is "dead". It is connected to DOS, an OS "dead" for more than a decade now and there will never be any new development/bug fix/... for those products anymore.

Stating that a product, which is on the market for more than 20 years now, but STILL evolves and expands its functionality and usability, is "steps behind" a "dead" product somehow sounds.... strange.

To wrap things up:

- Compiling languages will never provide this feature as changes to the code requires recompiliation. An execution of code cannot swap its code during a break and resume with another piece of code. So the request would require LV to (re)introduce an interpreter, which is not likely going to happen.

- Interpreter always do lack performance compared to compiling languages. That is one of the major reasons why interpreter languages are not "default". But even interpreter languages do not provide the requested feature by default.

- There is no real use case i can think of which requires the feature you request. True, it could be nice if handling interfaces, which require a long period of preparation each time. So keeping the interface open would be a nice thing. But is that an issue for the ADE (application development environment)? NO, it is not. It is an issue of your application an how you design that interface into your application.

As a recommendation for your specific situation:

Write a second application handling your mobile base station. This application is a pure "communication interface" to the base station.

Define a well-documented interface between your "user application" and your communication interface application. As you have two separate applications, this would be something like TCP based.

Developing your "user application" is very easy now. Communication to the base station is done through the communication interface, which is running standalone in the background. So debugging of the "user application" is simple and can be done at any time using default debugging and error removal techniques....

just my 5 cents,

Norbert

PS: Shane is right, LV 1 was an interpreter. NI moved away from that for very good reasons.

[EMAHJ]

As I have written before, there is wisdom here..

So, reading your answer Norbert, I understand that it is a feature that will never happen.

I have already created an IP based cumunication class for my application.

It is easy to break out and run stadalone almost the same as your proposal.

So I manage, no problem, but it would have been nice.. 😉

I think this post can be closed now, thank you all for your time!