Path to refnum

How can I convert path to refnum? Currently I am doing it with Get File Size. But it seems an overkill. Any other simpler way?
Have a very nice day!

Hi rashid,
see the attached example.
Mike
Attachments:
Unbenannt 11_LV80.vi ‏9 KB

Similar Messages

Converting path to refnum ?

I am working with a custom VI that I made that writes a 2D spreadsheet to a file during a measurement. The 2D data may later be appended, or optionally (at the start) the file may be created for this purpose (with a header file).
However, during a recent measurement, someone tripped over the power cable for the computer and all data (representing about 15 minutes of sensitive measurements) was lost since it was not flushed to disk.
The flush VI needs a refnum input. I want to place this VI just before the return of the call, so that this does not happen again (say - the computer crashes, or if I need to abort the measurement because some of the parameters went out of range, but do not want to lose the data already acquired).
So, how do I generate a refnum from a file path. If it matters, I am using Labview 8.6 on a Fedora 10 machine.
Message Edited by m-s on 03-26-2010 01:36 PM

Please post an image of your code so we can help out.
I suspect you are using an Express VI and it will have to be converted to real code so you can drop the flush inside it. Just opening another ref to the same file and flushing on that ref will not guarrentee the buffers asscosated with the other ref gets flushed.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

NaN/PathRefnum? function producing useless answers for Path, Refnum

I have found similar threads to this, but not quite the same, AFAICT.
I'm trying simply to see if an INI file exists, so I created the following snippet:
I also created a small file, put it in my C:\ directory, which I have attached here.
When I run the LV program with C:\test.ini, my indicators come out as NaN/Path?: False, NaN/Refnum?: True
which I tried to interpret as (1) a valid path (file exists) and (2) a nonexisting refnum (although the refnum came from an LV-supplied subVI).
I then changed the control (file to find) to C:\test.in (lopped off final "i") and the two indicators gave me the same results. That blew away my first interpretation, and I can't come up with anything else which makes sense.
So, for paths and refnums, what is going on here, if anything?
I did see that the second test threw an error from the "Open Config Data" subVI, so I can use that for my test, but I'd like to know if the NaN... function is actually good for anything but numbers. If not, IMHO LV should change its designation on the palette.
Cameron
To err is human, but to really foul it up requires a computer.
The optimist believes we are in the best of all possible worlds - the pessimist fears this is true.
Profanity is the one language all programmers know best.
An expert is someone who has made all the possible mistakes.
To learn something about LabVIEW at no extra cost, work the online LabVIEW tutorial(s):
LabVIEW Unit 1 - Getting Started
Learn to Use LabVIEW with MyDAQ
Solved!
Go to Solution.
Attachments:
test.ini ‏1 KB

Thanks, Nathand,
That clears it up a lot (and then digging down into the layers below the "Open Config Data" VI brings back the opacity). That's just one of the things which has confused me about the Config File VIs subpalette, but the explanation and the fact that you have to use a special "Not a Config Data Refnum.vi" with these instead of the normal "NaN/Path/Refnum?" (I never saw it until you pointed it out) answers several of the other questions, too. Like I said at first, in this case I just wanted to see if the file was there, so there are alternatives. But when I need to do more than what the prepackaged VIs do (which I expect I will), then it's just a matter of digging down in with my hip boots on. (Yuck.) But it's all fun, or I wouldn't be doing it in the first place.
Cameron
To err is human, but to really foul it up requires a computer.
The optimist believes we are in the best of all possible worlds - the pessimist fears this is true.
Profanity is the one language all programmers know best.
An expert is someone who has made all the possible mistakes.
To learn something about LabVIEW at no extra cost, work the online LabVIEW tutorial(s):
LabVIEW Unit 1 - Getting Started
Learn to Use LabVIEW with MyDAQ

Need Expert's Advice - How to use LabView Efficiently and to increase Readability

My application is fairly complex. It is a real world testing applications that simultaneously controls 16 servo motors running various stress testing routines asynchronously and all at the same time. The application includes queues, state machines, sub VI's, dynamically launched VI's, subpanels, semaphores, XML files, ini files, global variables, shared variables, physical analog and digital interfaces and industrial networking. Just about every technique and trick that LabView 2010 has to offer and the kitchen sink as well.
Still I am not happy with the productivity that LabVIEW 2010 has provided, nor the readability of my final product.
Sometimes there are too many wires. Much of my state machines have a dozen or more wires just going from input to output, doing nothing, just because one or two states in the machine need that variable in some state. Yeah, I could spend alot of time bundling and unbundling and rebundling those values, but I don't think that would improve things much.
We have had a long discussion about the use or misuse of Local variables in this forum and I don't want to repeat that here. I use them sparingly where I think it is relatively safe to do so. I also have a bug whenever I try and copy some code that contains one or more local variables. On Pasting the code with local variables, the result is something other than what I expected, I am not sure what. I have to undo the paste and rebuild the code one object at a time.
I am also having trouble using trouble using Variable Property Nodes. When I cut and paste them, they often loose their reference object and I have to go back into the code and redo the Link To on each one. That wastes alot of time and effort.
Creating subVIs is often not appropriate when the code makes many references to objects on the Front Panel. Some simple code will turn into a bunch of object references and dereferences which also tends to take alot of work to clean up and often does not help overall readability in many cases. I use subVIs when appropriate, but because of the interface overhead, not as often as I would like to. My application already has over 150 sub VIs.
The LabView Clean Up Diagram function often works poorly. It leaves way too much empty space between objects, making my diagrams 3 to 4 24" screens wide. That is way too much and difficult to navigate effectively. The Clean Up function puts objects in strange places relative to other objects used nearby. It does a poor job routing wires and often makes deciphering diagrams more difficult rather than easier.
My troubleshooting strategies don't work well for large diagrams and complex applications. The diagrams are so complex that execution highlighting may take 20 minutes for a single pass. Probes help, but breakpoint aren't of much use, because single stepping afterwards often takes you to somewhere else in the same diagram. I can't follow the logic well doing this.
Using structures, I may have Case structures nested 5 to 10 levels deep inside some Event Structure inside a While Loop. Difficult to work with and not very readable.
All and all, I can make it work, but I am not happy about the end result.
I am hoping to benefit from some expert advice from those that are experienced in producing large complex applications efficiently, debugging efficiently and producing readable diagrams that they are proud of.
Can anyone offer their advice on how best to use the LabView features to achieve these results in complex applications? I hope that you can help show me the light.

I'm not an expert but I'm charged out as one at work.
I am off today so I'll share some thoughts that may help or possibly inspire others to chime. I have tried to continually improve my code in those areas and would greatly welcome others sharing their approaches and insights.
Note:
I do refactoring services to help customers with this situation. What I will write does not represent what we do in a code review since our final delverable is a complete final design and that is beyond the scope of this reply.
I'll comment on your points.
dbaechtel wrote:
My application is fairly complex. ...
While watching Olympic figure skating competion slow-motion replays, I learned how the subtleties of how the launching skate is planted while entering a jump can make the difference between a good jump and a bad one.
In software, we plant our foot when we turn from the design to the development. I have to admit that there where a couple of times when I moved from design to development too early and found myself in a situation like you have described.
How to know when design is done?
Waterfall says "cross every 't' and dot every 'i' " while Agile says "code now worry about design latter" and Bottom-up "says "demo working why bother designing" (Please feel free to coment on these over-simplifications gang).
My answer is not much more helpful for those new to LabVIEW.
My design work is done when my design diagrams are more complicated than the LabVIEW diagrm they describe.
dbaechtel wrote:
simultaneously controls 16 servo motors running various stress testing routines asynchronously and all at the same time. The application includes ...and the kitchen sink as well.
Have you posted any design documents you have? These will help greatly in letting us understand your application. More on diagrams latter.
Anytime I see multiple "variations on a theme", I think LVOOP (LabVIEW OOP ) . I'll spare you the LVOOP sales pitch but will testify that once you get your first class cloned off and running as a sibling (or child) you'll appreciate how nice it is to be able to use LVOOP.
Discalimer:
If you don't already have an OOP frame of mind, the learning curve will be steep.
dbaechtel wrote:
Still I am not happy with the productivity that LabVIEW 2010 has provided, nor the readability of my final product.
Sometimes there are too many wires....going from input to output, doing nothing,... spend alot of time bundling and unbundling and rebundling those values, but I don't think that would improve things much.
Full disclaimer:
I used to be of the same opinion and even used performance arguements to make my point. I have since, changed my mind.
Let me illustrate (hopefully). This link (if it works for you, use lefthand pane to navigate hierachy) shows an app I wrote from about 10 years ago when I was in my early days of routing wires. Even the "Main" VI started to suffer from too many wires as this preview from that links shows.
Clustering related data values using Type Definitions is the first method I would would urge. This makes it easier to find the VIs that use the Type def via the browse relationships>>>callers. If I implement my code correctly, any problem I believe is associated with a particualr piece of data that is a Type def has to be in one of the VIs that use that type def therefore easier to maintain.
When I wrote "related data" I am refering data normalization rules (which my wife knows and I picked-up from her and I claim no expertise in this area) where only values that are used together are grouped. E.G. Cluster named File contains "Path" and "Refnum" but not "PhaseOfMoon". This works out nicely with first creating sub-VI since all of the data related to file operations are right there whe I need it and it leads into the next concept ...
When I look at a value in a shift register on the diagram taking up space that is only used in a small sub-set of states, I concider using an Action Engine . This moves the wire from the current diagram into the Action Engine (AE), and cleans up the diagram. The AE brings with it built-in protection so provided I keep all of the opearations related to the the Type def inside the AE I am protected when I start using multiple threads that need at that data (trust me, it may not make a difference now but end users are clever). So that extra wire is effective encapsualted and abstracted away from the diagram you are looking at.
But I said earlier that I would not sell LVOOP so I'll show you what LVOOP based LV apps look like to contrast what I was doing ten years ago in that earlier link. This is what the top level VI looks like.
And this is the Analysis mode of that app.
I suspose I should not mention that LVOOP has wizards that automatically create the sub-VI (accessors) that bundle/unbundle the clusters, should I?
Continuing...
dbaechtel wrote:
We have had a long discussion about the use or misuse of Local variables...I also have a bug whenever I try and copy some code...
If you can simplify the code and duplicat ethe bug. please do so. We can get it logged and fixed.
dbaechtel wrote:
I am also having trouble using trouble using Variable Property Nodes....
That sounds like a usage issue. Posting code to illustrate the process will et us take a shot at figuring out what is happening.
dbaechtel wrote:
Creating subVIs is often not appropriate... My application already has over 150 sub VIs.
"Back in the day..." LV would not even try to create a sub-VI that involved controls/indicators. I use sub-VIs to maintain a common GUI often but I do it on purpose and when I find myself creating a sub-VI that involves a control/indicator, I hit ctrl-z immediately!
I figure a way around it (AE ?) and then do the sub-VI.
Judging by your brief explanation and assuming you do a LVOOP implementation, I would estimate that app need 750-1500 VIs.
dbaechtel wrote:
The LabView Clean Up Diagram function often works poorly....
THe clean-up works fine for how I use it. After throwing together "scratch code" and debugging the "rats nest" I'll hit clean-up as a first step. It guess good enough on simple digrams and in some cases inspires me to structure the diagram in a different way that I may not have thought about. If I don't like, ctrl-z.
Good deisgn and modualr implementaion led to smaller diagrams that just don't need thrre screens.
dbaechtel wrote:
My troubleshooting strategies don't work well for large diagrams and complex applications....Can anyone offer their advice on how best to use the LabView features to achieve these results in complex applications? I hope that you can help show me the light.
Smaller diagrams single step faster since the sub-VI run full speed. I cringe thinking about a 3-screen diagram with multiple probes open ( shivver!).
Re: Nestested structres
Sub-VIs (wink, wink, nudge, nudge)
If it works you have prven the concept is possible. That is the first step in an application.
I hope that gives you some ideas.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Dynamic Event Registration in Reentrant VI

I have a VI running two reentrant Clients. The client uses a subVI (not reentrant) to handle keystrokes. The client passes a VI refnum to the subVI to dynamically register the keydown event. When I run the main VI I receive the FP not open error (1001). I have made the subVI reentrant and did not change the error output, any ideas?
Attachments:
NRKI.vi ‏6 KB
TwoClientTest.vi ‏6 KB
NonReentrantKeyInput.vi ‏22 KB

I have attached a modified VI testing the difference between the "This VI" refnum constant and the "This VI's path" -> open refnum constant. The comparison equates both, but the hex values are different. The FP 1001 error still occurs with the Dynamic event registration, the DER requires that the disk FP is open...Why? I don't know.
Odd show...
Attachments:
NonReentrantKeyInput.vi ‏18 KB
TwoClientTest.vi ‏6 KB
NRKI.vi ‏15 KB

Stream data from a subvi to the main vi - path refnum

hello everyone
sorry my english
http://forums.ni.com/t5/LabVIEW/stream-data-from-a-subvi-to-the-main-vi/m-p/2205150/highlight/true#M...
- refnum boolean worked
- refnum graph worked
- refnum numeric worked
how to create a path refnum? stream data from a subvi to the main vi
where do I start?
thank
Solved!
Go to Solution.

Bom Dia Saille,
Eu acredito que o que você tenha hoje seja isso aqui (Desenho bem simplificado):
Hoje o que você tem é o Aplicativo do Medidor + USB Driver controlando o seu medidor. Basicamente, sua aplciação está dividida em três camadas:
Aplicação - Onde estão as funcionalidades principais do programa (interface com o usuário, apresentação de dados, geração de arquivos, etc.)
VISA - Uma arquitetura de Software para controle de instrumentos. Basicamente, ele se comunica com o Driver USB para poder enviar e receber pacotes de dados através do barramento USB.
Device Driver - Intruções de SW de baixo nível para controlar um periférico através de um barramento.
No desenho, eu aponto duas camadas onde você pode tentar atuar para automatizar suas medições:
Aplicação - Você pode usar o VI Server para controlar o Aplicativo do Medidor (Se este aplicativo tiver sido desenvolvido em LabVIEW, o que eu suponho ser verdade). No entanto é necessário saber se o desenvolvedor do produto permitiu isso (Veja Using VI Server to Pass Data Between a VI and a LabVIEW Executable). Outra alternativa é conversar com o fabricante para ver se ele desenvolveu alguma API (Application Programming Interface) para que você consiga controlar o instrumento diretamente.
VISA - O LabVIEW Fornece uma API chamada NI-VISA para poder enviar e receber informações através de diversos barramentos (Veja Serial Instrument Control Tutorial)
É possível acessar o Driver diretamente também, mas eu não recomendo. O resultado não compensa o esfroço!
Espero ter esclarecido suas dúvidas e espero que você tenha sucesso na sua aplicação!!
Atenciosamente.
Felipe Flores
Engenharia de Aplicações
National Instruments Brasil

In LV6.1, can I get the run-time menu refnum of a VI from the VI Path?

Actually, for any version of LabVIEW, can I get the run-time menu refnum from the VI Path (or the VI reference)?
Thanks!
Enrique
www.vartortech.com

I just thought of a workaround...you could have a Menu Bar Ref indicator on your main VI front panel. When your VI runs, you could have the Current VI's Menubar function wire the refnum into that indicator. Then, in your subVI that has the VI reference, you could use VI Server to read the value of that indicator, then cast the value into a refnum wire, then you'd have access to the menubar reference in the subVI without having to pass it in to a subVI terminal. Would that work?
Oh, another simpler idea would be to simply wire the Menubar reference into a global, and read that global in the subVI.
-D
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

Refnum to path

Hi
I need to reload a VI through a front panel control. I want to obtain VI's path using the refnum to path function in order to reload the VI using Load and Run. There is an error although according to the context window both source and sink are of same type.
P.S already checked detailed explanation
Attachments:
1.jpg ‏28 KB

To explain a bit possible reasons for this constraint:
References are first of all only pointers to some space in memory; that means, they are only numbers where the actual number is the address in memory of the data space the reference is pointing to.
That being said, most references are completly incompatibel to a "path" or a "string". So casting a reference to a path or string makes only sense for references pointing to file-based data spaces, aka "file streams".
VI RefNum is not necessarily a "file stream" as you can acquire a reference to any VI you haven't saved yet, but is in memory. So it must not be compatible to a file-based reference (like a file handle you get from "Open File").
Norbert
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.

Create a default path into Automation Refnum

I'm currently writing an app which should display a nice graph (chart) on
its front panel. I choose to use Mapinfo Active X.
To do this, I've placed an Automation Refnum on my front panel, and in the window
'select object form Type Library', I choose "Mapinfo.tlb" .
It works quite well, but :
When I re-open this Vi, I should re-setting the Automation refnum. I try to use Active X container, it doesn't work. Can I create a default path into the Automation Refnum or any other method which can solve this problem.
Thanks for your help.

You shouldn't select the type lybrary, in automation refnum, when you want to select te type, available types appear if properly registered in your system, if not, you should register your tlb.
Hope this helps

Refnum to path problem

Hi,
I have many subVI. I am working with binary files and I want to open them only one time. If I make subVi(1) which opens:
and then subVI(2) which reads the first 4 elements and store them in array:
Then subVI(3) which uses previous one and reads only 4.element from array
Then I can't connect the first subVI with last one because they have different types.
What should I change/do not right?
Andy
Solved!
Go to Solution.

You need to change the filepath control in the later subVI's to a refnum control.
Copy and paste the refnum indicator that is the output of the first subVI and drop it into the later subVI's. Right click, change to control. Then wire that up to the file functions instead of the filepath control you have now.

"Not a Path?" is not working

Hello,
i added a simple example vi where i have a path-control and a "Not-a-Number/Path/Refnum?" and as output a boolean.
The boolean should be false if the path is correct and true if the path is invalid.
Then i insert as path the value "c:\abc|||def.txt". When i run the vi then the path is valid.
But this is not a valid name in Windows so why is it displayed as valid? I cant create a file manually in with this name.
Thanks for any help
Attachments:
validpath.vi ‏7 KB

Not a path is the Tag <Not a path> and can be found under File-I/O -> path constants as a Not A Path Contant.vi
Several file vis will also return that constant if cancelled (file dialog) or an error occures.
Felix
www.aescusoft.de
My latest community nugget on producer/consumer design
My current blog: A journey through uml

How can I display the name of my refnum on the front panel?

I am writing data to a file. To do this, I am using "Open/Create/Replace File" to prompt the user for a filename, which is then output to my VI as a refnum. I then write strings to this file with "Write to Text File".
How can I display this filename (with the path) on the front panel after the user has input it?
Michael
Solved!
Go to Solution.
Attachments:
refnum.JPG ‏45 KB

Use the Refnum to Path function, in File I/O -> Advanced File Functions palette. You can wire this to a path indicator.

File path of open data storage

Hello all!
Now I'm using the blocks of open data storage, write data and close data storage for storing and extracting result data. For the file path issue, before I
set the data path by double clicking the "open data storage" block and inserting the file location in the indicated place, and that worked!
Now since I made a stand alone application of this program and shall use it in other computers, the file location I inserted in open data storage block isn't
valid any more in other PCs. So I modified my source code by connecting a "current vi path" to the open data storage block's file path node instead of
inserting it inside the block, and this doesn't work! During running there shows an error in the write data block saying that the storage refnum isn't valid!
I'm wondering why I couldn't specify the file path like this. Any way to allow me to specify the file path as the current vi path?
Thanks!
Chao
Solved!
Go to Solution.

You need to account for the path changes when built in to an application, have a look at this example.
https://decibel.ni.com/content/docs/DOC-4212
Beginner? Try LabVIEW Basics
Sharing bits of code? Try Snippets or LAVA Code Capture Tool
Have you tried Quick Drop?, Visit QD Community.

Deny Access function with invalid file refnum causes LabVIEW to crash

Hi folks,
I have LabVIEW 8.5, and today encountered something interesting that consistently causes LabVIEW to crash. Essentially, if you find the "Deny Access" function under the advanced file IO palette and wire up an invalid refnum, Windows (XP in my case) reports that LabVIEW has to close. I checked in task manager, and the LabVIEW process is still active and using a disproportionate amount of the CPU.
To reproduce the issue, simply drop the function on your block diagram, create a constant from the refnum input terminal, and run the VI. Has anyone else seen this behavior?
Thanks,
Jim

Hi Carla,
I'm glad to help, and thanks for looking into it. The way I ran into the bug was while I was working on an action engine VI to log certain text values (see attached picture). While logging, I didn't want other programs to access the file. When a new file had to be generated, I wanted to stop denying access and close the reference. However, if the value on the shift register was invalid, LabVIEW crashed instead of throwing an error (I guess a crash qualifies as an error).
If you look at the attached picture, my workaround was to use the "Not A Number/Path/Refnum?" function. If the reference is bad, I don't try to use the "Deny Access" funtion or close the file. That worked just fine and seems like a good solution for now.
Jim
Attachments:
Logger.png ‏6 KB

Not A Path Comparison not working.

I ran across this tonight, and it seems a little weird to me. I have a path that shows as "<Not A Path>" in probes and in the control/indicator, but the NaN/Path/Refnum? function returns false. I suspect it has something to do with how this path was created (I used path to string, some string operations, and then string to path on it), but I would still expect the comparison to return True. Any thoughts or insights? I used Flatten to String to look at the path, and it is clearly different from the Not A Path Constant. I can use File/Directory Info instead, and then check for an error, but this is annoying. The vi is saved in LV8.6.
Chris
Message Edited by C. Minnella on 02-05-2009 06:39 PM
Attachments:
Not a Path Weirdness.vi ‏7 KB
Not a Path Weirdness.png ‏31 KB

Darren wrote:
P.P.S. - Is this worth a nugget?
Here's an example of the nugget:
Message Edited by JoeLabView on 02-06-2009 02:58 PM
Attachments:
nuggetExample.PNG ‏16 KB

Path to refnum

Similar Messages

Maybe you are looking for