LabVIEW Project IDE - Eclipse

[Jim Kring]

Has anyone looked at Eclipse? http://eclipse.org/

It is an cross-platform (written in Java) open source IDE for just about any type of project. According to their website... "Eclipse is a kind of

universal tool platform - an open extensible IDE for anything and nothing in particular."

I downloaded it and took it for a test drive. It is very slick, and has so many features and so much flexibility that it might be daunting for new users (it was for me). It has built-in CVS capabilities, which is useful Source Code Control integration. It is very extensible, but the plug-in API's are all Java. If nothing else, this platform could serve as a very useful example for implementing something similar in G. I think that it is worth some time investigating.

[jeffwass]

Has anyone looked at Eclipse? http://eclipse.org/

I haven't played with it yet, but there is a Lua plugin for Eclipse, which could be useful for LuaVIEW, which allows one to call LabVIEW modules externally.

[Mike Ashe]

... If nothing else, this platform could serve as a very useful example for implementing something similar in G.  I think that it is worth some time investigating.

3198[/snapback]

I downloaded it and was impressed. I also spoke to my brother-in-law who is a senior programmer for Fidelity Investments in Boston. Some of Fidelity's internal work is now being done on Eclipse which has been officially approved by the company. Fidelity is very conservative about the tools they allow to be used. This speaks well for the stability and safety of the code.

As to whether to try to put LabVIEW-Java plugins in or just use it as a model.... that is a very good question. I think for now we might want to continue to do our major tool development in pure G, but Eclipse should be added to OpenG/LAVA projects for three reasons:

1) development of those few cross-platform functions that might be better implemented in a text based language. (or for including existing open source text based code/libraries).

2) to get us into a good open source IDE since Microsoft has included verbiage in its Visual C/C++ license to try to preclude use for developing open source tools.

3) Future: for writing "OpenG" as an OpenG project in the next few years :thumbup:

[Jim Kring]

I downloaded it and was impressed. I  also spoke to my brother-in-law who is a senior programmer for Fidelity Investments in Boston. Some of Fidelity's internal work is now being done on Eclipse which has been officially approved by the company.  Fidelity is very conservative about the tools they allow to be used. This speaks well for the stability and safety of the code.

I, too, noticed is that it looks like a very mature and well thought out software product. It has major backing by IBM (the creator of Eclipse), CollabNet (driving force behind Tigris.org, home of SubVersion and TortoiseSVN) and hopefully Sun Microsystem. It really seams like it has a solid foundation as THE open source IDE.

As to whether to try to put LabVIEW-Java plug-ins in or just use it as a model....  that is a very good question.  I think for now we might want to continue to do our major tool development in pure G, but Eclipse should be added to OpenG/LAVA projects for three reasons: 

1) development of those few cross-platform functions that might be better implemented in a text based language.  (or for including existing open source text based code/libraries).

2) to get us into a good open source IDE since Microsoft has included verbiage in its Visual C/C++ license to try to preclude use for developing open source tools.

3) Future: for writing "OpenG" as an OpenG project in the next few years  :thumbup:

3202[/snapback]

What I think would be useful for OpenG to start doing, is to use the Eclipse IDE as the project-level environment for invoking the OpenG Builder, OpenG Package Builder, LabVIEW App Builder, and any other functionality needed by OpenG developers during the build/test/release process. Eclipse has good support for integrating external (command-line) applications into the build process. It would be fairly easy to build executables that allowed access to OpenG Builder and other functionality.

What we probably won't be able to do (w/o a great deal of help from NI), is to integrate the LabVIEW environment into Eclipse. Eclipse has an API for integrating breakpoints and other debugging tools directly into the target environment. This would be tough to integrate with LabVIEW.

By starting to use a "real" software IDE, I think that those OpenG Developers without experience developing in a traditional programming language/IDE will gain a lot of useful exposure to the types of tools and methodologies used for software engineering. This insight will go a long way for helping us define our direction in the context of G as a general purpose programing language. Also, I am looking forward to doing some exploration into Java and how the Eclipse plug-in/extension framework is architected. This research will go a long way for OpenG projects that wish to provide plug-in capabilities.

[Albert-Jan Brouwer]

I've used Eclipse for a small amount of Java work, and it sure has an amazingly broad scope, considering that it is free. Project management, refactoring tools, version control integration, unit testing, and lots and lots of optional plugins. And the C/C++ tooling has come along as well.

What we probably won't be able to do (w/o a great deal of help from NI), is to integrate the LabVIEW environment into Eclipse.  Eclipse has an API for integrating breakpoints and other debugging tools directly into the target environment.  This would be tough to integrate with LabVIEW.

I'm afraid so. At best we could write some kind of TCP/IP server that runs under the LabVIEW runtime and does things like open/close/pop-up/load VIs/run VIs and is messaged from an Eclipse plug-in. But the level of integration would be shallow, probably hardly worth it. The problem is that LabVIEW thoroughly mixes up language, tools, and libraries. That's mostly by necessity. Being graphical, a lot of infrastructure is required just to work with the language (G: while, for, case, sequence, etc.).

NI however would be able to do much better. Ideally, they'd target Java bytecode with the G compiler. That way G code could run inside the same Java runtime as Eclipse. And it would make G much more portable. A set of LabVIEW widgets that uses SWT would be highly desirable as well.

That maybe requires a bit of explanation. In the old days, Java only had AWT, the advanced windowing toolkit, which was anything but advanced. In response to the need for building more advanced GUIs, Sun architected Swing. Unfortunately, Swing is way over-architected and does not map onto platform-native widgets, which makes the GUIs look weird. As do LabVIEW GUIs, really.

The Eclipse developers instead implemented SWT (standard widget toolkit) whose primitive widgets map onto platform-native widgets. That's why Eclipse looks slick and is responsive (once it has loaded).

Of course, there is a lot of politics and strategy working away in the background. Sun is violently opposed to SWT, and IBM is a little loathe of pushing it too publicly because that might be considered trying to fragment the Java platform. What doesn't help either is the very name "Eclipse": it can be considered a dig at Sun, though the Eclipse people deny that that was the intent (yeah, right).

Why has IBM given away arguably the most advanced development environment (much more advanced than the LabVIEW IDE anyway)? My guess is that they consider it pouring fertilizer onto the open source and particularly Java community, with the intent of harvesting some of the resulting crop.

Also, IBM is trying to work its way up the food chain, and is intent on commoditizing the ingredients that go into their services and advanced products. Particularly those supplied by Microsoft (Eclipse is the main competitor to Visual Studio) and Intel, the two companies whose virtual monopolies were unintentionally spawned by IBM fumbling the ball back in the early days of the PC.

For instance, IBM recently sold their PC division. It is a low margin business. It will also allow them to work more closely with AMD and maybe even fab some AMD processors without AMD's customers having to fear that by using AMD instead of Intel processors they will subsidize a competitor.

Interesting times.

[Mike Ashe]

What we probably won't be able to do (w/o a great deal of help from NI), is to integrate the LabVIEW environment into Eclipse. Eclipse has an API for integrating breakpoints and other debugging tools directly into the target environment. This would be tough to integrate with LabVIEW.

Good point, but this is what LabVIEW Scripting is for. Speaking of that, has anyone managed to set a breakpoint programmatically using scripting?

Another good starting utility is one that "Finds" a specified set of wires, either in the VI-of-interest or optionally it's subVIs, and returns a list of them and their references, in a listbox and selecting the wire ref in the listbox connects it to a slightly tweaked version of Jim Krings universal probe tree.

One of the things we still don't have (LV 8?) is a decent variable watch window. The two items above would be a small start.

Perhaps we could call this type of stuff from Eclipse using ActiveX.

[Jim Kring]

has anyone managed to set a breakpoint programmatically using scripting?

Write a TRUE value to the Wire's Breakpoint property.

[Mike Ashe]

Thanks Jim, guess I should RTFM more often. Oh, we don't have a manual for scripting yet... still I should have caught that. I'll try to do penance by coding up some of the stuff I was asking for above.

[Michael Aivaliotis]

I'll try to do penance by coding up some of the stuff I was asking for above.

3282[/snapback]

I'm not sure how useful it would be to have a list of wire references with probes to them. I mean, probes are really useful in context. I have to "see" where it's probing. Just a list of them might not be useful.

What I would really like (and NI will not have in 8.0) is to have a list of ALL opened references. Control, file, vi, visa etc. references. This way I can see if I'm missing closing any of them. Of course, by the time this tool is developed, NI will probably add a feature that makes reference closing irrelevant. Perhaps they will auto close everything for you.

Any ideas?

[Mike Ashe]

In many text based languages you can open up what is commonly referred to as a "Variables Watch Table". You can specify a list of code modules, and which variable in them you want to see. Then you run your program, and in the Table you see the variables you have requested change as the program runs. All in one small convenient place.

I like being able to place probes, especially for more complex data like clusters, its much better that a simple text table. Still, I may have lots of probes open, floating over other things I want to watch. I also have to open and close them again *tomorrow* when I continue to debug what I am working on today.

What I want (and am working on) is a way to:

1. Specify which VI(s) I am interested in, either in memory or on disk.

2. Very quickly list the wires, sources and data types in each

3. Very quickly select only the ones I want and attach probes

4. Have those probes all report data back to a central display tool/table/tree

5. Be able to save and restore sets of the above so that if I see problem "X" six months from now I can open probe set "Y" in two button clicks and be looking at the data I want, across the whole VI hierarchy.

6. Lastly, log all this data. That would allow for a "golden data set" or "signature" to be used to recertify a module or entire hierarchy later after code mods, either by myself or others.

Right now I have code done (based on the "Clean up all wires" code that someone else did) that will let you select the VI off disk, list all the wires, their source, their type descriptor enum type, and attach a new copy of Jim Krings Universal probe. This all works okay, but is incomplete per the above wish list. Next is to make a modified version of the probe that sends the data (timestamped maybe) back to the Probe Table.vi and instead of putting it in a table it puts it in a single Universal Probe type tree, but using the probed VI's names as the first level tree branches.

I probably don't have time to do all the above in the near future, so when I get just a little more done I will post it here and also either start a new SourceForge project or include it in the initial utilities code for OSTE. Then others can contribute and incrementally add functionality.

Be advised that the initial code is really, really ugly...

[Mike Ashe]

Okay, here is the initial code. As I said, it is ugly, a hack and very minimal, but it gets the ball rolling and gets it out of my hands. For quickness sake I included a slightly modified version of Jim Kring's Universal Probe. You can get the original on OpenG.

Download File:post-45-1104631195.zip LV7.1 (if enough people get interested I'll resave in 6.1 or 7.0)

Here is what it looks like for now:

First open the zip file in a directory, then open Wires to Probe-Table.llb>>Probe Table.vi,

Now open Test subVI.vi and also its diagram, and browse to it in the path at the top of Probe Table.vi, run ...

If you click on a row of the table you should see the corresponding wire in Test SubVI.vi go to highlight mode. You can quickly click around and see highlights set and clear.

Now double-click a row to attach a universal probe to that wire and also open the probe. Open up a couple, then run Test subVI.vi and play around. Thats as good as it gets for now.

Enhancements:

1. Get All VIs and use to populate a listbox or menu of VIs as an option vs the file path of a VI.

2. Put this ugly hack into a proper queued state machine, ready to add lots of goodies to.

3. Look up a list of custom probes and populate another listbox on the front of Probe Table, and select from there for the desired probe type.

4. Even better: detect the type of wire, decode, and assign correct probe type(s) automatically.

5. All the enhancements from my list above

6. Timestamp the stuff in the probes.

7. Only have the universal probe update its front panel tree if the data changes

8. Logging, configuration save/restore - I know I said it above, but this is really important.

:clock: Anybody got a little time to add a few features?

:beer: Cheers

[pandaman]

I lub eclipse :thumbup:

[Rolf Kalbermatter]

What I would really like (and NI will not have in 8.0) is to have a list of ALL opened references. Control, file, vi, visa etc. references. This way I can see if I'm missing closing any of them. Of course, by the time this tool is developed, NI will probably add a feature that makes reference closing irrelevant. Perhaps they will auto close everything for you. 

3289[/snapback]

Aah, they do that already!! It is called garbage collection and kicks in as soon as the top level VI invoking the Open refnum function is going idle. This is actually a feature you can't turn off other than for VISA refnums (yeah I know they are now VISA resource names but the underlying mechanism is still a refnum) in the Options->Miscellaneous dialog.

Rolf Kalbermatter

[Albert-Jan Brouwer]

It is called garbage collection and kicks in as soon as the top level VI invoking the Open refnum function is going idle.

5643[/snapback]

Garbage collection (GC) is more advanced than that: when a language runtime supports GC, it tracks whether or not objects remain referenced and frees the memory of no-longer-referenced objects at runtime. What LabVIEW does is merely resource tracking: put the allocated stuff in a list and free it by walking the list when the top-level VI stops.

Unfortunately, stopping the VI that opened a reference does not necessarily imply that that reference is no longer in use: the reference may have been passed to a different still-running VI hierarchy. This makes that you have to be very careful when passing references around in your application. Make sure that such references are opened in an execution context that remains alive for the duration of use of those references.

Ironically, this tracking feature was probably added with the intent to make the life of the programmer easier. It does, for simple applications with only a single running top-level VI. At the same time, it serverely hampers LabVIEW's utility for large-scale programming. Of course, GC should have been used for tracking references to avoid the aforementioned problem. GC algorithms have been around for ages.

[Khalid]

Okay, here is the initial code. As I said, it is ugly, a hack and very minimal, but it gets the ball rolling and gets it out of my hands.

[clip]

Enhancements:

1. Get All VIs and use to populate a listbox or menu of VIs as an option vs the file path of a VI.

2. Put this ugly hack into a proper queued state machine, ready to add lots of goodies to.

3. Look up a list of custom probes and populate another listbox on the front of Probe Table, and select from there for the desired probe type.

4. Even better: detect the type of wire, decode, and assign correct probe type(s) automatically.

5. All the enhancements from my list above

6. Timestamp the stuff in the probes.

7. Only have the universal probe update its front panel tree if the data changes

8. Logging, configuration save/restore - I know I said it above, but this is really important.

:clock: Anybody got a little time to add a few features?

:beer: Cheers

Hi Michael,

This is an excellent idea, and a great first-jab at it. I was wondering if you (or anybody else) had a chance to work on this more. I would like to make some modifications and wanted to start-off with the latest version.

Thank you,

-Khalid

[Mike Ashe]

Hi Michael,

This is an excellent idea, and a great first-jab at it. I was wondering if you (or anybody else) had a chance to work on this more. I would like to make some modifications and wanted to start-off with the latest version.

Thank you,

-Khalid

Unfortunately, no, no more modifications. So please feel free to start with the version 0.1 above.

Sorry,

Mike

[dannyt]

Hello Michael,

Would it be possible to get a labview 7.0 version of you probe vi, I would like to have a little play with it.

cheers

Danny