LabVIEW
Averting LabVIEW auto update of prior code, is this how?
@3d0g wrote:
compiled code vs source
LabVIEW is always compiled on the fly as you edit it. The LabVIEW compiler is absolutely amazing, details here.
If separate compiled code" is checked, the VI is stored without compiled code (the "source" is in the diagram) while the compiled code is cached elsewhere. This makes the VIs smaller and simplifies SCC because recompilations without code change no longer trigger a change flag.
What is the "inline programming world"?
Who is "you" in your last sentence?
@3d0g wrote:
"inline programming world"
Sequential, text-based programming. ...I need to read that linked LabVIEW compiler doc. It'll likely clarify what is meant by "source" vs "compiled." I understand that for LabVIEW, I create a "program" using a block diagram, and then when I run it, my "program" is compiled and runs, unless the run-arrow is broken, which shows me my "program" couldn't be compiled due to an error. You seem to be saying there can be compiled code and source code to this, somehow. I'd see the vi as source code, but the compiled code part... ...not so clear there. I can understand that I can create an executable. But the idea of source code and compiled code in the LabVIEW world is unclear. I didn't see my saving my vi as saving anything but the source code.
As far as the "you" goes, when I click to respond to you and what you've said to me, I know you get flagged that you got a response from me. However, as a general reader, reading a thread, how does one know who is responding to who? ...aside from the obvious:
altenbach: clearly I am responding to you
rotfl: this isn't to you
the rest of the world reading: now I am speaking to you
I give you this link to NI's explanation of this feature because, quite frankly, they are better at explaining it than I am:
https://www.ni.com/docs/en-US/bundle/labview/page/lvconcepts/saving_vis_compiled_code.html
@3d0g wrote:
"I do sometimes enable the View File Path option to verify in the project view that the physical file hierarchy matches (often not strictly) the logical project view, especially when I have to maintain a project that someone else wrote. "
Back to the old fashioned way.
I don't understand "View File Path" option. I don't think you mean the project's "Files" tab I was referencing.
This is the Files view (which I never use, haven't even looked at that in any project in years).
And this is the project view (Items View) with Project->Show Item Paths enabled.
I'm not really using those paths all the time, but for projects that I haven't created myself it can be helpful to be able to control if files belong to some group based on the directory they are in (and then fixing the mess) so it is more consistent.
So unless you were talking about something else than the first image, I'm standing firm on my statement, that the Files view is not necessary at all to be able to maintain a clean project files structure. And I'm not arguing this with you as you like to want to. If you feel different, that is totally fine with me. Do whatever you feel more comfortable with. But you asked for our opinion and kind of chided on Santosh (if not even tried to belittle him) for not taking your bait about who agrees or disagrees with you.
@3d0g wrote:
However, thank you for clarifying what you meant via an image. Using the "Show Item Paths" option is the "Files" tab selection, as I see it, where "Files" does it in a graphical/hierarchical manner. ...or does it, completely? Hence, my question. It seems from what I read there can be an issue when hardware is involved, because one piece of hardware can have only a single driver for it. Therefore, something written in LabVIEW version X can get broken by something else written in LabVIEW version Y if they both use the same piece of hardware, for they'd have to use the common driver. So, would "Files" reveal that to a green LabVIEW user such as myself? This is the kind of thing I am asking.
Starting with LabVIEW 2022Q3 hardware drivers will be generally installed in a common location and LabVIEW 2022Q3 and newer will be able to reference those driver VIs without causing them to be recompiled to the newest and greatest version. That's at least the plan, I'm sure there will be a few kinks in the cables that need to be ironed out to make this fully work. And yes if you use older versions of LabVIEW, they won't know about this and work the old way, which is hardware driver VIs have to be installed into the respective LabVIEW folder (one of vi.lib, instr.lib or user.lib folders) or be part of your project hierarchy, so this is the opposite of what you are describing.
A proper hardware driver interface for LabVIEW before version 2022Q3 should never be installed in a common path but always into the LabVIEW version for which it is intended to be used (or optionally be included in the project tree as an alternative). Anything else is asking for trouble if you intend to use multiple LabVIEW versions and/or more than one project.
