Petru_Tarabuta

Just wanted to say thanks. Yesterday I used the built-in Modbus Comm Tester for the first time in an actual project. It worked well and enabled us to validate the Modbus comms to a device that our team hadn’t used before.

This is an old thread, but if anyone else comes across this: If using LabVIEW 2020 or later, the best way to generate a GUID is to use the native Create NI GUID.vi which is found in the String >> Additional String Functions palette. If using LabVIEW 8.0 to LabVIEW 2019, the best way is to download the Create NI GUID.vi that is found at: GUID Generation for LabVIEW Versions Older than 2020 . This is the same VI as the one that exists natively since LabVIEW 2020, but "Saved for previous..." to LabVIEW 8.0. If using a LabVIEW version older than 8.0 on Windows, it's probably best to use the .NET Framework System.Guid object, as document in the following article: How to Generate a MessageID/GUID/UUID With LabVIEW? and as seen in the screenshot below. This comment was cross-posted at: https://forums.ni.com/t5/LabVIEW/Any-GUID-generating-VI-available/m-p/1246596

+1 kudos. I have just added a comment (comment page 2, comment number 15) to Greg's idea on the LabVIEW Idea Exchange: The Block Diagram should be the central VI component (not the Front Panel) . For ease of reference, I copy the contents of that comment below: " +1. Diagram-only VIs (VIs without a Front Panel) would constitute a massive improvement to LabVIEW. I strongly believe that LabVIEW is a "real" programming language. It certainly is Turing-complete (computationally universal). But I can see how the fact that each and every VI must have a front-panel (a GUI) can make LabVIEW seem like a toy language in the eyes of a professional text-based programmer (C, C++, C#, Java, Python, etc). In a typical text-based application the number of GUIs is much, much smaller than the number of routines (I use this term to encompass the terms methods, functions, and procedures). This is logical and efficient. As examples, why should the following routines have a GUI? A routine that takes "a", "b", and "c" as inputs, and outputs "3D_Distance = sqrt(a² + b² + c²)". A routine that takes a string as input and removes all the whitespace from the beginning and end of that string (equivalent to Trim Whitespace.vi). A routine that reads or gets a field from an object (a getter accessor method). And virtually all other routines in a typical application! These routines do not need GUIs. This is evidenced by the fact that millions of text-based programmers around the world have been implementing these sort of routines happily in their languages for decades without needing a GUI for each of the routines! Moreover, many text-based apps have no GUI at all (e.g. console apps, Windows service apps). This is a perfectly legitimate use case that LabVIEW should support too. The fact that each and every VI must have a front-panel costs us (professional LabVIEW programmers) dearly in at least the following ways: Having to spend a few seconds, a few tens of seconds, or more on “tidying up” each front panel. Tools like pressing Ctrl + U on the Front Panel help a lot but you still need to remember to do it and on occasion they still require the programmer to manually adjust the position of the FP controls and indicators. Our applications are bloated. They carry around lots of FP-related state data and/or settings for each and every VI that is part of the application, even for the VIs that will never show their Front Panel to the user once the EXE is built. This is extremely wasteful in terms of memory and disk usage. Some people say: “I like Front Panels because they help with debugging”. I agree that Front Panels generally help with debugging. I too like using Front Panels for debugging. But debugging is generally a very short stage in the lifetime of a VI. A VI may exist in a codebase for 30 years, out of which it may be debugged for a total of 1 hour. Solution: Give people the option to have a Front Panel or not, and to toggle between the two states. If I need to debug my VI, I will use a Front Panel during the debugging session. Once I’m happy that the VI works well and passes the unit tests I would remove the FP, thus removing the bloat of that VI. Let’s appreciate that text-based programmers have managed to create “small” applications such as operating systems (Windows, Linux) without needing a GUI for each routine they had to debug! For these reasons, I believe that the fact that each and every VI must have a front-panel is an anachronism. Diagram-only VIs would constitute a significant improvement and would be another step towards LabVIEW being considered a real language, even by professional text-based programmers. Around six months ago I unintentionally created essentially a duplicate of this idea: Block-Diagram-Only VIs (VIs without a Front Panel). That idea currently has 24 kudos. If possible, I would like those kudos to be merged with the kudos of this idea (45 kudos currently). Thanks! "