Showing results for 
Search instead for 
Did you mean: 

Im in trouble and I have a problem and error. Please HELP ME!!

Add "cmd /c " before your command.  Go read the help for the System Exec VI for slightly more details.

There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 11 of 16

The bat or rar file is not allowed.

0 Kudos
Message 12 of 16

zip file here

0 Kudos
Message 13 of 16

It looks like the OP might be using Python to do some simple LabVIEW tasks, such as reading in a Delimited Spreadsheet File, possibly changing from "comma" decimal point to "period", reading in 4 arguments from the User Command Line (could be passed to LabVIEW as a 4-element Cluster or 4 Front Panel parameters), doing some simple array calculations based on these parameters (bgleft and bgright), doing some (simple) computations on this array, and creating a text file, "spectrum_underground.txt".


Other than the possibility that the OP knows Python and doesn't know (or care to learn) LabVIEW, it is not clear to me why this is being done (maybe the missing "script.bat" explains it all).


Looking at, it appears to read the spreadsheet "spectrum.txt" (I recommend that you name Delimited Spreadsheet Files with the extension ".csv", Comma-Separated Values (which, I should note, is not an "Excel" file -- Microsoft has just "captured" the .csv extension and made an "Excel-lookalike" icon for it), do some calculation based of 4 Front-Panel Parameters (Left-Left, Left-Right, Right-Right, and Right-Left), then call Script.bat (which I suspect calls with these parameters, where I suggest more LabVIEW, possibly not needing to write the intermediate .csv file), then reading intermediate file and doing more processing.  Wow, that was a long sentence ...


This is a place where the use of sub-VIs that do "one thing" (and document it), and/or some well-placed comments saying what you are trying to do (documentation!) would be very helpful.  A virtue of a sub-VI is that it can "hide the messy details" (but if you give your sub-VI a meaningful Icon that says what it does, that really helps figure out what's going on).  Do try to explain.


These are the steps that I see:

  1. Take an Input Array and save it as the CSV File "Spectrum".  
  2. Using 4 parameters, perform some unexplained and undocumented computations on the Input Array for subsequent steps.
  3. Using 4 parameters, use Script.Bat to create a second CSV File, "Spectrum_Underground" that will be read in Step 4.  Note that it is not clear if this file is anything more than a vehicle to be read in Step 4, i.e. if this step could be simply replaced with a set of computations on Input Array.
  4. Do more processing on Input Array, the results of the computations in Step 2, and the results of the computations in Step 3 (either directly or by reading Spectrum_Underground).  Again, lack of documentation makes debugging or understanding a real challenge.

Bob Schor

Message 14 of 16

Dear Bob Schorr,
thank you very much for spent your time.
I am new in the labview. Can you say simply , how can i do it? Or can you show me.
Sorry for my bad english.

0 Kudos
Message 15 of 16

Dear AnnihilationSpectrummm,


     There was a famous TV/Radio Correspondent, Daniel Schorr, whom we always called "Cousin Daniel", even though he spelled his last name with an "extra r" (as you have done) ...


     The "secret" to writing good LabVIEW (C, C++, Python, Matlab, Java, etc.) code has been known for a long time -- Write the Documentation First.  This doesn't necessarily mean "write 5 pages that describe every step", but think about what data you have, what you want to do with it, what parameters you need to use, what intermediate steps you need to see, and what output you expect.


     I have a colleague whose code resembles yours (and he's been doing LabVIEW probably longer than I), and the first thing I say when he asks for help is "What are you trying to do?".  He then proceeds to tell me how he is manipulating the data, but I interrupt and say "Not How, but What?".  Notice the paragraph above says "What", not "How".


     I don't know (and can't be confident I'll be able to figure out from your code, it is so terse) what you are trying to do.  I know you start with a 1D array of Dbls ("What" do they represent?  I'm assuming data taken at equally-spaced time or space intervals).  You have 4 parameters -- "what" do they represent?


     From the answers to the above two "What" questions, the obvious next question is "Now what?", or "What" transformation do you want to do with the Data and the Parameters?  Again, not "how" (i.e. don't say "Use a For Loop to compare ...", but "Use Parameter 1 to split the Array into ..." or "Use Parameters 1 and 2 to ...".  As you identify intermediate quantities, name them ("Use Parameter 1 to ... and call this "X").


     Identify where you need to create Outputs (for example, you may want to display "X" in a Chart/Graph, or as a parameter).  Try to keep (in the initial Documentation) things at a fairly high level, concentrating on What.


     When you are done (this might take no more than 2-3 paragraphs, and will certainly lack detail), you are (almost) ready to start coding, or at least thinking about coding.  I sat down and in about 5-10 minutes knocked out the following Code:

Top Level VITop Level VIStep 1Step 1


The Top Level VI shows the Data (Array) and the 4 parameters, grouped in a Cluster (to expedite passing one or more of them to sub-VIs).  I showed only the sub-VI for the First Step -- you seem to have 2 or 3 steps in your data processing, each with several sub-Steps.  I also show Step 1, where you use Parameter 1 and the Data to get Data Out 1 (which might be all or some of the Input Data), use Parameters 1 and 2 to get Data Out 2, then combine them to get Data Out.  


     Some things to note.

  • Using sub-VIs allows you to abstract the data processing and concentrate on the inputs, outputs, and parameters, "hiding the details" for now.
  • As you go into the sub-VIs, more details are revealed, but you might still want some further abstraction.
  • Clusters are extremely useful for passing "clusters" of Controls and Indicators around -- keeps things together, and 1 "cable" is much neater than 4 "wires" coming and going everywhere.
  • Making Icons for sub-VIs (and TypeDefs) is easy, and allows you "self-document" your LabVIEW Code.

     Once you've written your Paper Documentation, see if you can recreate some of these sub-VIs yourself and start populating them with code from your Documentation.  Note that at the level I've shown here, the code is still concerned with "What" and is putting off to later the "How", i.e. the LabVIEW Loops, Functions, etc.  Remember, at the lowest level of sub-VI where these LabVIEW "details" appear, you want to be doing "one thing" that you can express in 2-3 words on your VI's Icon.


Bob Schor


Message 16 of 16