Marcus J

A LabVIEW SDK is now available for the i-Speed 3. The price is quite steep though, around 3k€, and I have not yet been able to find any documentation, specs, screenshots or the like. 

/Marcus

Hi Folks,

I think perhaps this discussion is in part related (or will be when I post my next comment) to an idea i have posted at LV idea exchange: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-a-Package-Manager-to-LabVIEW/idi-p/1670074 check it out.

Cheers,

/MArcus

Hi,

The conversion utility is built in, at least in the latest version.

Use with care (keep backups)

Cheers

/MArcus

Hi,

Not knowing how to handle the whole LAVAG / NI duality, I started out by posting this question here:

http://decibel.ni.com/content/thread/8817?tstart=0

but I'll copy it :

During the holidays I started thinking of creating a build system for LabVIEW.

I would like to see if there is any interest in a shared effort on such a project.

The high level spec is:

Log in to a web page,

Specify a build (SVN URL, version, lvproj, Build Description (tests etc))

Press play on tape

..... Magic .....

Download the built software from a link

Does anyone have this ?

Would you want this?

Rough draft / Mindmap:

http://prezi.com/veoj-lrmcd5s/laym/

Code:

https://subversion.assembla.com/svn/Laym/trunk

/MArcus

Hi Martin,

With a reference to the TL-VI wired to the VIs that are loaded into the subpanel, you should be able to do what you are trying to do, for instance get a ref to the TL-VIs menu, and manipulate it.

But with just the information about the apps, it's hard to know if the sub-panel approach is recomendable.

Here are some random thoughts about some of the alternatives i see:

1. Independent apps with launcher
   This is simple, your apps do not share any GUI functions (not the old fashioned way at least) and have no natural common denominator or shared resources. You could build your apps as source distributions and the launcher could easily launch new apps you add to the suite.
2. Subpanels
   I'd use this if the apps have a limited set of behaviours, and more important, they have some common ground. Perhaps all the apps use different sets of hardware but the report is the same.
3. Kind of Object Oriented approach
   Regardless if you use subpanels or not, if your apps are somewhat alike, it could be good to try and sort out how they are constructed. Perhaps you could put all the common functionality of the TL-VI into a few VIs that use some kind of repository (perhaps an uninitialised shift register).
4. Straight Edge OO
   Using classes and inherritance you get some pretty good ways to handle this kind of a problem, but with legacy code it's more like shoulda-woulda-coulda

Hope you stopped reading before I messed it up completely.

If you didnt, and you are indeed messed up, you have my deepest apologies.

/Marcus

QUOTE(proximableu @ Sep 11 2007, 04:04 PM)

Gratulate me, I started to work for Endevo company!

Welcome aboard!

/Marcus

(oddly enough the only Marcus at endevo)

[quote name='Lars-G

Hi folks,

I