Naming DDT signals to write a file

[wlee87]

Hello! 

 ah... 

I'd like to name my data when I use 'write to file' express block.. 

 I found a way, and it is working, but it is definitely not a good way.. so do you guys have any suggestions? 

 At least I can replace the long line of naming queue into a single for loop.. which I will do it after taking a dinner...  but still the process calls the name of my variables every time while I am using the while loop, very waste of resources and doesn't look fancy. 

 For sharing experience, do not use the signal merge after changing the name of the signal - it will destroy the names you've assigned to them. 

 Thanks, and have a nice day! 

[GerdW · Accepted solution]

Hi wlee,

---

@wlee87 wrote:

 I found a way, and it is working, but it is definitely not a good way.. so do you guys have any suggestions? 

For sharing experience, do not use the signal merge after changing the name of the signal - it will destroy the names you've assigned to them.

---

Simple suggestion: don't use ExpressVIs and stay away from their evil twin "DDT wire"…

Another suggestion: don't use local variables when you can use wires instead! Race conditions everywhere…

---

@wlee87 wrote:

At least I can replace the long line of naming queue into a single for loop.. which I will do it after taking a dinner...  but still the process calls the name of my variables every time while I am using the while loop, very waste of resources and doesn't look fancy. 

---

Using a loop with just one instance of that SetName expressVI surely uses LESS resources than your long snake of chained "name set operations"!

Where do all those measurement data are coming from?

When they come from DAQmx functions you can already set the signal name when defining the channels. You just need to use the Waveform datatype later on to keep the names…

[wlee87 · Accepted solution]

 Dear GerdW,

 Thanks for your advice!

 Very unfortunately, we've started the system- it will run for weeks if there is no problem. we have no time to clean up the messy Labview file as well as it's functioning well. 

 I really don't understand the 'wiring' system - for example, if you are using C/C++ or Java, we can directly/indirectly control the variable in the memory including the entire class and we know when/what we access. For Python or Matlab, they are a little more ambiguous but still, we can imagine an abstract level. So I can set a very clear dataflow in my mind...

 But this wiring system in the Labview..... ah.. this is a disaster for me - I really don't understand what/when we access the information in this wire thing while the machine is running and, especially the DDT type, I have completely no idea what is this. 

 Anyway, for future upgrade, I have a little question

 - Is there any way to create a remote branch of the wire instead of using the local variable? 

 In my case, we gather multiple voltages from SCXI, and get some temperature readings from a network-based device and get a high-resolution voltage from a nano-voltmeter via serial communication. 

 and the relation between the data to data is intrinsically a spaghetti..(to convert this voltage, the temperature is needed and for this temperature, we need that with a curve fitting, and we need a graph for this and that too.. ETC..) so I cannot avoid the spaghetti wiring, and more importantly, cannot keep the wire ends and the source in one screen! 

 with over 30 signals, this problem driving me crazy. 

 with this local variable, I could separate those spider-net wiring. But as you said, there are race conditions. 

 All I need is the orange/blue portal thing for the wire... because I don't know how the wire works, I don't want/need to break it by using the local variables. 

 Anyway, thanks again! 

[GerdW · Accepted solution]

Hi wlee,

---

@wlee87 wrote:

I really don't understand the 'wiring' system - for example, if you are using C/C++ or Java, we can directly/indirectly control the variable in the memory including the entire class and we know when/what we access. For Python or Matlab, they are a little more ambiguous but still, we can imagine an abstract level. So I can set a very clear dataflow in my mind...

But this wiring system in the Labview..... ah.. this is a disaster for me - I really don't understand what/when we access the information in this wire thing while the machine is running and,

with this local variable, I could separate those spider-net wiring. But as you said, there are race conditions. 

All I need is the orange/blue portal thing for the wire... because I don't know how the wire works, I don't want/need to break it by using the local variables. 

---

Text-based programming languages usually don't use "dataflow", they use "top-bottom text": execute one line of code, then execute the next line of code…

LabVIEW uses DATAFLOW instead: please read that chapter in the LabVIEW help as it is elemental to LabVIEW programming!

("THINK DATAFLOW!": A node executes when all data inputs are available. A node outputs data when it is finished. Independent nodes can execute in parallel.)

---

@wlee87 wrote:

Anyway, for future upgrade, I have a little question … with over 30 signals, this problem driving me crazy. 

---

"With over 30 signals" you should be using one (1!) wire containing an array of waveforms: just one wire…

---

@wlee87 wrote:

and, especially the DDT type, I have completely no idea what is this. 

---

That's why (nearly) all users of LabVIEW past the "absolute beginner" experience level recommend not to use them (together with their "ExpressVI" counterpart) - we also don't know which data they may hide…

[RTSLVU · Accepted solution]

---

@GerdW wrote:

---

@wlee87 wrote:

and, especially the DDT type, I have completely no idea what is this. 

---

That's why (nearly) all users of LabVIEW past the "absolute beginner" experience level recommend not to use them (together with their "ExpressVI" counterpart) - we also don't know which data they may hide…

---

Stop using Express VI's and DDT wires as soon as possible!

Honestly these things were only developed for and are only useful for those half day LabVIEW seminars  sales pitches, to show managers and other non-programmer decision makers how fast you can just throw something together and be collecting data.

But as you see if you want any sort of control over the data, how it's collected, how it's presented, etc. these VI's quickly become worthless or as in your case more hassle than they are worth using.

If you want full control over your program, data collection, and presentation you are going to have to learn how to do it "the hard way". I suggest taking advantage of the online training NI provides.