Jump to content

Some help streamlining my new tool


Recommended Posts

I need some help figuring out how to streamline a new tool.

I wrote a tool that is invoked by my SCC server; when a change is submitted, the server scans any submitted VIs and controls for revision changes and records them into the SCC's change spec. This allows me to track changes at a very atomic level.

But here's the trouble... the code for reading the history WITHOUT opening up VI dependencies only runs in the development environment. So the original EXE script that I wrote to do this doesn't work.

OK. I'll just invoke Labview with a command line argument to launch the VI I want and pass in the relevant SCC info. No dice. If LV is already running, the command line arguments are the ORIGINAL ones, not the ones used to call it the second time.

So what I have is a LV EXE that is invoked by the SCC. It calls my revision tool via VI server. This works, as long as LV is running. (I suppose I could start and stop LV, but I don't want to deal with that latency every time I submit- which can be often).

So now I have LV running 24/7 on my windows machine (windows 7 pro, no server). Is there a way to run the Dev environment as a service so that it's not running in the UI?

Any other ideas?

Thanks!

Link to comment

I need some help figuring out how to streamline a new tool.

...

OK. I'll just invoke Labview with a command line argument to launch the VI I want and pass in the relevant SCC info. No dice. If LV is already running, the command line arguments are the ORIGINAL ones, not the ones used to call it the second time.

...

Any other ideas?

One thing you can do is make a copy of labview.exe and invoke that one with your new command line arguments. That way it doesn't matter if you have LabVIEW running or not. This will have the overhead of LabVIEW starting up each time, however.

Link to comment

One thing you can do is make a copy of labview.exe and invoke that one with your new command line arguments. That way it doesn't matter if you have LabVIEW running or not. This will have the overhead of LabVIEW starting up each time, however.

I thought about that. It may come to that!

Link to comment

Options:

  1. Don't use the revision history at all. That's what the SCC is for. Of course, that means you have to remember all the changes you made in order to log them.
  2. Try using an older version of LV (such as 7.0) to read the data from the VI, as it will load faster. My guess is that this will probably not work, as it will fail when trying to open a reference to the VI.
  3. There's apparently an option of activating scripting support in an EXE. This might be enough to allow the EXE to also read the revision history property. See here - http://decibel.ni.com/content/message/10063#10063

Link to comment

What SCC are you using?

If you use the integrated SCC provided by LabVIEW you can alter those VIs (vi.lib/sourcecontrol/providers) to actually store the parameters, however there is a small glitch: the LabVIEW SCC interface doesn't know which LabVIEW instance is actually running...

Ton

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.