I have a Labview project containing several classes and a few VIs associated with each class.
The project and all the associated files are contained in a single directory.
When I duplicate (or even rename !) the project dir, I am able to load it but Labview warns me that several "Conflicts" exist. I wasn't able to resolve them by myself.
I understand that Labview can get confused if it loads a few identically-named VIs from another folder ; but why do problems appear even when renaming the folder ?
Isn't there a way to tell Labview to look first in the relative path and load in priority whatever it finds there, without looking elsewhere ?
Why is an operation that is so easy in text-based languages (recursive copy of a folder) so complicated and troublesome in Labview ?
I also tried duplicating the whole hierarchy through "File -> Save", but this also produced conflicts..
Renaming or copying a whole project usually work, since project's VIs are specified by paths relative to the project file.
However there are cases where other VIs referencing VIs inside the project folder. In this case you get conflicts, unless you save the project to another location using "Save as" dialog and specify "Duplicate .lvproj file and contents"
My solution is that I don't think there is a solution. I have the same problem and I have even talked to NI about it with no help.
I did find that, even when the list of conflicts is large, you only need to resolve a few conflicts before LabVIEW figures out the rest. Also don't panic if LabVIEW won't let you resolve a particular conflict. Just move on to the next conflict that you can resolve. As I said before, in time, LabVIEW will figure out the rest.
Related
In VB6 I had (example) the following directories:
CommonCode
Parser
OrbitalDynamics
DnD
RelativisticBang
The first is standard inclusions I use (constants.vb, science.vb, constAstro.vb, DnD.vb...) while the others are projects who all use one or more of the common code files.
If I loaded OrbitalDynamics and, while in it, added a new constant in constants.vb then the next time I loaded the others, they also had the new constant immediately available.
I've rebuilt the common code files for VB2008Exp. I'm now trying to rebuild some of the projects. The problem is that I've not found a way to bring in the common code files. Every time I've tried it's copied them into the project rather than referenced them. Copying is, obviously, useless for the idea of common code.
Hopefully someone out there knows what I've missed, or knows some other method of using common code files in VB2008Exp. I can do this sort of thing in CPP, in C (both in Linux), and in VB6, but so far VB2008Exp has been very intractable.
I'm trying to get a Cocoa development environment working in Emacs, and I'm 80% of the way there. The one feature I miss is Xcode's "Open Quickly", which basically performs a fuzzy match of the string you type against the filenames referenced in the Xcode workspace and the symbols defined in those files.
My problem is that our project is huge: if I generate a TAGS file using etags for the .h and .m files in our project's sub-directories, the result is over a gig in size and Emacs complains "TAGS file is large. Really open?", and if I say yes, then Emacs hangs and becomes essentially unusable. Of course, this is before I've even considered indexing tags for system libraries. I've also tried projectile, but unfortunately it's similarly unusable on a project of my size (on the order of a full minute to find a match).
It occurs to me that all the indexing information I really want is in the Xcode projects themselves, so if I had an Emacs package that could parse them and traverse their dependencies, that might be a start, but I'm not aware of any such package.
Any suggestions/solutions in this respect?
I've never found a single function quite as convenient as Xcode's "Open Quickly", but these days I use
helm-projectile-git-grep when I want to match on strings I know to be in the filenames, and
helm-git-grep for quick searches through the contents of the files themselves.
I've found that this gets me really close to what I wanted in my original question.
I am developing a data acquisition program in Labview that uses multiple translation stages, cameras, a high speed digitizer, and other instrumentation. I'm developing the application on one computer, and will be deploying it to another computer. The development computer has labview 2013, and computer the application will be deployed on currently has Labview 2012, but we will be upgrading it to Labview 2013 when we move the application over there. Some of the drivers need different versions of the driver to function under Labview 2012 than they do for Labview 2013.
I'm trying to keep all of the vi's, subvi's, and drivers for the instrumentation in one directory tree so that I can move the whole tree over to the computer it will be deployed on.
When I load the project in Labview I'm getting a lot of "Resolve Load Conflict" dialog boxes popping up. When I go to investigate, Labview says it can't find one of the files that is causing the conflict, but yet it popping up the dialog. An example is below:
This happens every time I load this project - saving all doesn't enter the new paths into Labview. I also tried creating a new project, and pulling these vi's in, but the new project has the same load conflicts.
Evidently Labview or these vis think that these vi's that no longer exist are still there.
How do I fix my project, vi's, or Labview so that it only uses the vi's that it should, and I don't get all of these conflicts, many of which are with nonexistent files?
I just had this same problem, but solved it like so:
In your project window, expand the Dependencies group. You should see each of the undesired subvi's listed there.
Right click on each one and select 'Replace with item found by project...'. This will bring up the familiar conflict resolution dialog box, go ahead and select the proper path and click OK.
Now, because the dependency has changed, Labview is going to change the dependency path that is saved in the calling VI. You'll see a save dialog asking if you want to save the changes to the VI(s) that is/are calling the dependency whose path you just changed. You want to save changes.
Do this for all the dependencies and you should be good to go.
I've found that when it is necessary to move driver files and libraries from the NI default locations, renaming the files prevents further confusion.
For instance if you have a "instr.vi" that you need to move to a custom directory location, renaming the file "my_instr.vi" and linking to the renamed file prevents future conflicts.
Of course, this may initially involve some amount of work in renaming all the files and then directing your calling VIs to use these newly renamed driver files, but after that initial time invest you shouldn't have any more problems.
I'm trying to build a solution that has three VB projects; one that I'm working on, and two others that have interdependencies (although one says "unavailable").
In trying to compile, I get regarding the ancillary project, "Unable to find source file 'J:\DSDPAGE_T.xsl' for file 'DSDPAGE_T.xsl', located in '[TARGETDIR]', the file may be absent or locked."
J? I searched the solution to see if "J:" is hardcoded anywhere, and it's not, so...?!?
The "missing" files are right there n the project! Why is it looking in J? If that is hardcoded somewhere, why doesn't 2-clicking the err msg take me to the spot? When I do, a "File System " tab appears with two panes. On the left:
File System on Target Machine
Application Folder
System Folder
User's Desktop
User's Programs Menu
...and on the right pane, a listing of the files in that project (the same ones I see in Solution Explorer), many of whom are the subject of err msgs that they cannot be found...?!?
Is this a "VB thing" (I've never worked with VB before) or...?!?
Maybe I can create a J drive and put those files the compiler is wearing blinders about in there just so it will compile - it's not that project I need to work on anyway, I just need to let the solution compile, so I can update the other project.
UPDATE
Looking at one of these files that is visible in the project, but for which the project exhibits acute myopia, its "SourcePath" property does say "J:\DSDPAGE_T.xsl" but that property is readonly/grayed out.
UPDATE 2
In response to user2701753:
I know what you're talking about; I'm used to having these in C# projects; but in this case, there are no References folders. There is only:
Solution 'HDP' (2 projects)
HDP [project#1]
ReportFormats [folder]
[a bunch of .xsl files]
[a bunch of .vb files]
HDPSetup [project#2] <-- the problem child
DetectedDependencies [folder]
[various files: .dll, .xsl, .exe, .chi, .chm, .mdb, .bmp, .ico]
The "Detected Dependencies" folder (which I thought was maybe the VB version of References) is apparently empty - 2-clicking it does nothing; it doesn't expand or open up.
UPDATE 3
Here is perhaps a good clue: When I look at the project files in Windows Explorer, many of the files that display in Visual Studio are not seen there! For example, C:\Project\ccr\Handheld\Development\Development\HDP\HDP\HDPSetup only has this:
Debug [folder] <- empty
Release [folder] <- empty
HDPSetup.vdproj
HDPSetup.vdproj.vspscc
ccr.bmp
ccr.ico
According to VS, I would expect to see those files that it complains about being on the (nonexistent) J: drive.
UPDATE 4
This is related to the issue above.
To recap the gist: I am trying to port/upgrade a VB.NET (.NET2/VS 2003) solution to .NET4/VS2010.
The solution is comprised of three projects; the Setup project was wreaking more mayhem and malevolence than a marauding crash of rhinoceropuses (it was thought to be on drive J, apparently), and I don't need to do anything to that project, so I removed it from the solution.
That removal reduced my error count from 35 to 14.
However, the remaining errs seem related to the "other" project. There are now two; I'll call them HDP and HHTConvert (because those are their names, and my current employer doesn't seem to be as paranoid about divulging any info that would identify the company or project as my previous one was).
Although the Project Dependencies allows me to set one as dependent on the other, no matter which way I set it, it fails:
0) Both depending on each other - disallowed, circular jerk tailchasing considered bad juju
1) HDP depending on HHTConvert: Type 'HHTConvert.HHTConverter' is not defined.
2) HHTConvert depending on HDP: ""
3) Neither depending on the other:""
So it doesn't matter what I do, the same err msg appears. The line the err points to is:
Public hhtConvertThread As HHTConvert.HHTConverter
What do I have to do to introduce the HHTConvert project to the HDP project? It would seem them being in the same solution - especially when one "depends" on the other - would be enough. HHTConverter is apparently not very dependable.
UPDATE 5
Correction/amendment to my original statement: "I'm trying to build a solution that has three VB projects"
Actually, I successfully removed one project, so it is two projects, and one is C# (the "main" one, HDP, is VB).
Could that (the C#/VB "mismatch) cause the two projects to look askance upon each other, akin to the renowned Star-bellied Sneeches and the "plain vanilla" Sneeches? (I consider the plain ones to correspond to VB).
UPDATE 6
So I've got it compiling now (see my answers), but I'm getting a subsequent (runtime) error, namley: "Unable to load DLL 'cdbmenu1.dll': The specified module could not be found."
And sure enough, one of the VB files does references a DLL with that rather bland name several times, with lines such as:
Declare Sub GetLastMenu1Error Lib "cdbmenu1.dll" (ByVal Msg As String, ByVal Length As Int32)
So, I searched the local (work) network and found some copies of that DLL. I copied the newest version (2.5 years old) to HDP's bin folder, and tried to run the app. Now I get, "An attempt was made to load a program with an incorrect format"
Is this the part of the story known as "DLL Purgatory" or a rendition of "DLL Perdition"
(geschweige denn "Extraordinary DLL Rendition")?
Look at the 'References' in the projects in the Solution Explorer, these have a 'Full Path' if that's wrong drop the reference and readd it.
In the visual studio setup project have you added "active content" from VB project? Open your VB project file in a notepad, check the different files included in your project file, your setup project will try to include all those files as a part of your MSI. So open the project file and you should see the J drive there.
All those files can be taken out from the project and then re added.
I solved it: I had to add the .DLL from the C# project to the VB project's References. Once I did so, all errors disappeared. Why that wasn't already there, I have no clue.
I know there are a lot of questions on this topic, and I've looked through a fair number of them. However I am still having problems.
I started writing a test program for a prototype PCB, and now that it's grown to nearly 1000 lines I'm trying to break it up into libraries that I can use for particular functions.
I thought this would be very simple. Make .c and .h files for each library that I need. I.e. I would have OLED.h and OLED.c for functions that control an OLED display. Copy the appropriate functions/definitions into each file. Then copy these files into the solution in Atmel Studio. I put them into the src folder under the project name.
However, this doesn't work! I get an exceedingly long list of errors. All of the things that are defined in the .h file are apparently undefined as far as the compiler is concerned. I also get many error messages of the type "unknown type name int16_t/uint16_t/uint8_t/etc..." That part is really baffling to me. Why should it matter that functions are in an external library, now the compiler doesn't understand what those data types mean?
So, this is probably a stupid problem to have. I don't want Atmel Studio to control my libraries by wrapping them up in some "library project" or somethig, I want to put them in a folder of my choosing and add them when I need them. I've searched for answers to this problem and I find long tutorials about changing the compiler settings for the project, the linker settings, etc... I tried this tutorial and still no dice: http://www.engblaze.com/tutorial-using-avr-studio-5-with-arduino-projects/#setup
I also can't find a way to add something by right clicking the project and clicking "Add." It wants me to find .a files. The "Add Library" dialog box in Atmel Studio is awful, it seems.
Surely it can't be that convoluted to just add a library to an existing project and have it function normally?! I've used PICs in the past and coming to Atmel I've found horrible documentation and a weird super-slick super-fly whizz bang interface that can't leave well enough alone and obfuscates simple function. What can I do to add these libraries?
UPDATE: Seemed to answer my own question. Turns out I needed to include all of the libraries to recognize data types and whatnot into the .c file. I somehow assumed this only had to be done in the main file but obviously I was mistaken. Adding asf.h seems to work well as it includes all of the MCU specific port definitions/names and all of that. All good for now!
Adding library files to a solution should be simple. Go to the Solution Explorer, right-click on your solution, and go to "Add->Existing Item". If you want to add a pre-existing library and keep it in a separate folder from your solution, click the arrow next to "Add" and choose "Add as link". That saves many headaches due to having a duplicate copy of your library in your solution folder, and files not staying up-to-date.
You are right in saying that you need to include the necessary header files in the .c files where they are used.
The compiler compiles each C file separately, and then links them together at the end, so you got the error unknown typename int_* because the compiler had not seen the relevant header in the context of compiling that C file.
You also seem to be in some confusion as to the difference between definition and declaration.
A function is:
Declared in the header file. This means there is a function prototype, e.g. int some_func(char some_var); which tells the compiler that the function exists, but does not tell it what it is. This is necessary because the compiler only looks at one C file at a time, so needs to be told that other functions exist.
Defined in the C file.This is the actual function body, i.e. int some_func(char some_var) { do_stuff(some_var); }. After compilation of each individual C file in isolation, the linker is called to put all the pieces together and give you your final binary, which you flash to the device.
A function can be (and must be) defined only once, but may be declared many times - even in the same file, so long as the declarations are not conflicting.