LabVIEW Idea Exchange

The name of the "Get Date/Time in Seconds” function is misleading. The function should be renamed.

Details

• The current name does not make it clear which Date/Time it is going to return. The words "now" or "current" are missing.
• The "In Seconds" portion is misleading and unnecessary. The function correctly returns a timestamp data type. The timestamp represents a moment in time that is expressed not just in seconds, but also using lots of other time units such as days, hours, minutes, ms, us, ns, etc. I understand that when a timestamp is converted to a DBL, the value represents the fractional number of seconds since the beginning of the epoch, but this is an implementation detail. It should not be part of the name of the function.
• “Get Date/Time in Seconds” would be a suitable name for a conversion function that takes in a formatted Date/Time string and outputs a DBL that represents the number of seconds since the beginning of the epoch.

Names of equivalent functions in other languages

• .NET: System.DateTime.Now
• C++: std::chrono::system_clock::now()
• Python: datetime.now()

Notice that the equivalent function names contain the word "now" and omit "in seconds".

Perhaps the best new name for the function would be “Get Date/Time Now”. This name would be very much in line with the .NET, C++ and Python equivalent function names. This name would earn the "let's not reinvent the wheel" prize.

Nevertheless, I would be happy with the following names too:

• “Get Timestamp Now”
• “Get Current Date/Time”
• “Get Current Timestamp”

Notes

• Changing a primitive name may break VIs that use VI scripting to find or create this node. This is a downside. I believe that in this case the long-term benefits would outweigh the relatively minor annoyance of hopefully relatively few developers having to modify those scripting VIs to use the new primitive name.

In a recent version of LabVIEW the height of Unbundle By Name and Bundle By Name elements, Local Variables and Global Variables was standardised to 16 pixels. This was a welcome improvement. (I'm fairly sure that the improvement was suggested by a LabVIEW Idea. I would have liked to link to that idea here but unfortunately I can't find it right now.)

The size of Boolean constants is currently 16 pixels (width) x 14 pixels (height). This should be standardised to 16 pixels x 16 pixels. A vertical stack of Boolean constants would better align with a stack of local variables, global variables, or UBN/BBN elements. They would also align better with the default sized LabVIEW grid (16 x 16 grid).

Thanks!

Hi all,

image processing is not anymore the "tough stuff"/"niche" of the past. Videos are everywhere now, maybe even more than sounds. So functions that handle video should be included in the cross-platform standard labview, at least for the essential functions (reading/writing files with a minimal set of codecs, acquisition of frames through ip or usb for common protocols, conversion between image format for display and processable data). This would attract a lot of young users. It would also jumpstart future developments of labview in the direction of AI.

Thx

VI Analyzer is great tool but can only perform static analysis on VI (as far as I know). It could be nice to run some tests on libraries / classes or even projects files as well to enforce good practices. 

PPLs are a powerful tool in LabVIEW, and when working on larger plug-in based applications, they're almost essential.

As a developer, I do my best to not reinvent the wheel. This means building modular libraries for common functionality. Sometimes this includes base classes and interfaces, sometimes this includes functional globals. If I'm calling either of these from a PPL, it's necessary to first put this common code in a PPL too -- otherwise there will be class conflicts or conflicting instances of functional globals.

I would love to be able to distribute this common code as a VIPM package to vi.lib so that it's reusable across multiple projects -- however that's simply not possible now. While yes, you can technically put a PPL in vi.lib, you're guaranteed to be met with failure as soon as you build an application that relies on PPLs calling the vi.lib PPLs.

There are workarounds to all of this of course, but they all come with compromises, typically maintainability -- such as including a copy of all of your PPLs (and in my case, a library of public VIMs that sits next to each PPL) with every project, while not having access to the common functionality outside of any of these projects.

The solution could be as "simple" as this:

• When PPLs are compiled, they currently expect each dependency to be at an exact relative path.
  • Why not support loading from one of a number of paths similar to, say, how .NET finds DLLs?
    • Search order could be something like: exact relative path, current folder, common LabVIEW folders, and custom (where custom could be defined in build specs)
  • When building a PPL/application that relies on PPLs, if you don't exclude dependencies, this would now allow all of those dependencies to actually find each other.