LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

I can't add a .txt file to the project to get it recognized in the executable

Solved!
Go to solution
Solution
Accepted by topic author LeftLaneLeader

Hello LeftLaneLeader,

 

Based on your previous and current post, it sounds like you've come pretty far in the last few months!

 

As for the problem you're currently facing, there are a few things to check:

 

1) Is the text file being exported (included and copied) with the executable build so that the exe has a local copy to read?  If it isn't you'll want to add it in the build specification and designate a path to export it to alongside the executable.  The default "data" directory created by the build is probably a good place.

2) How is the path to the text file specified in your application?  Is it a static path? If you're using a static file path constant on the block diagram, keep in mind that this path will not change the new disk structure when compiled and you may need to build it dynamically.

3) Are you using a read file express VI?  If so, you may need to configure the file path outside of the express VI.

4) As a temporary measure, place an indicator on the path wire going into your read file function or on the FileName Out output of the express VI you're using to give you an idea of where your executable expects the file to be.

 

One thing to keep in mind is that files that aren't *compiled* into the executable won't be re-linked during the build process or automatically incorporated into the exe.  You can add just about anything to a project, but for things like external text files, dlls, or anything else that you need to specify by path this is mostly for bookkeeping purposes.  This also includes dynamically linked VIs but you probably don't need to worry about that for now.

 

For reference material, try searching "path" "exe" "labview" "build" "dynamic" "file" "load" or similar phrases on ni.com or your search engine of choice.  Knowing what to look for can still be tough, though.  Here's a few documents to get you started:

 

NI Community Example: Introduction to Using File Paths in LabVIEW

https://decibel.ni.com/content/docs/DOC-11613

 

NI Community Forums: Build exe and file path

http://forums.ni.com/t5/LabVIEW/Build-exe-and-file-path/td-p/984137

 

You may also want to consider self-paced online LabVIEW training, which you can access for free if you have an active support contract.

 

Also- providing more information on what you've already attempted, including screen captures or VIs including relevant portions of your code goes a long way.  There are quite a few forum users that would be able to look at the section of your code that loads this file and diagnose the problem within a few seconds- help others help you!

 

Best Regards,

Tom L.
0 Kudos
Message 11 of 16
(935 Views)

Thanks for the help and the links. I will check out the on-line courses.

 

I have viewed (multiple times) all of the on-line tutorials that have been uploaded to youtube and also all of the other help from Enable Integration, etc. back to version 2007.

 

I still believe it is unreasonable to think there won't be more questions. Based on what I saw since I was able to search what Dennis pointed me towards, I am not alone out there. The question, and issue I have seems legitimate with my building the executable file pointer issue.

 

I sincerely want to know how I can do a better job using the forum and not wasting your time. Any suggestions?

 

Thanks and again, I appreciate the help.

0 Kudos
Message 12 of 16
(927 Views)

No problem!

 

As a place to start, this one's pretty good:

 

Quick Introduction to the Forums for New Users

http://forums.ni.com/t5/Feedback-on-NI-Discussion-Forums/Quick-Introduction-to-the-Forums-for-New-Us...

 

(that's also available as a link) under "New to the Forums?" from the top-level board hierarchy page.  I'd never actually clicked on it before, though, so don't worry if you missed it the first time around.)

 

In general, I've seen that "good faith" posts will get you pretty far- elaborate on what you've done to date, specify what you're trying to fix or find out as narrowly as possible, link documents you've already referenced or that you think might be related, etc.  "What could be causing this" questions without a lot of background information or code attached are extremely difficult to answer concisely.

 

Posting code showing what you're working on also helps a lot, and if you can't provide that information for some reason (company policy, can't access at the moment, etc.) then mentioning that reason can't hurt. Thanking people and applying kudos and solutions liberally is probably also a good idea. 

 

A response indicating that the same or a similar question has been asked before is often a quick way for other users to let you know some more digging through old threads and KnowledgeBase articles might be the quickest way to find an answer, so some of it is still going to be figuring out the jargon and massaging search engines to give you the information you're looking for.  If you're still feeling like you're out in the weeds, try pointing out the areas or ideas you're not sure about.  Once you've found an answer, posting a link or two to the document(s) that led you to that aha! moment will also help the next person looking for similar information.

 

Tom L.
0 Kudos
Message 13 of 16
(910 Views)

Tom -

 

Thank you much for the post and help. I am done for the night but will pursue your suggestions in the morning for my current issue and future direction. Based on what I scanned and saw in the post, I think I will get there.

 

I actually thought I had done a "good faith" post and elaborated as much as I could in the original question but I guess I need to elaborate more. Maybe the "New to the Forums?" link and suggestion will get me to the correct group for help in the future.

 

Thanks again...........

 

 

0 Kudos
Message 14 of 16
(897 Views)

Tom -

 

Got it. Thanks for the help.

 

Based on some of the info I found using your links, I decided to use an application property node to determine in which environment I was in. It allowed for a single strip path for developemt and a double for the executable. Works great. Still have a few bugs adding the file into the build correctly but I am sure I will get it figured out at this point.

Steve P

 

0 Kudos
Message 15 of 16
(868 Views)

No problem- glad to help!

 

You may already have figured this out, but in case it's of use there's a quick and easy walkthrough for adding and configuring additional files in your build here:

 

KnowledgeBase 292B1BB5: Installing Support File in the Same Directory as a LabVIEW Executable

http://digital.ni.com/public.nsf/allkb/2EBA44FCF6EF0F5686256A41005DA1F5

 

Regards,

Tom L.
0 Kudos
Message 16 of 16
(839 Views)