JKSH

D'oh! So simple. Yep, that did the trick. Thanks! (I miss the old "Mark as solution" feature from the previous forum)

Good idea, thanks. So I made sure my LabVIEW code remained unchanged, and I altered 1 character in Basic >> Display Information >> Product Description Summary (from 'o' to 'a'), then re-saved. The following items changed in the *.vipb file: The "Modified_Date" attribute in the top-level "VI_Package_Builder_Settings" tag The "ID" attribute in the top-level "VI_Package_Builder_Settings" tag Every single "GUID" value under the "Functions_Palette_Data" tags. I'm pretty sure these fields existed in the previous version of VIPM too.., but perhaps they've been given a new role. (If so, why???) I mainly use Notepad++ too I know it's definitely not a problem of mis-encoding, because: I used a hex editor (HxD) to alter exactly 1 byte in my Product Description Summary text (from 'a'==0x61 to 'o'==0x6F). That triggered the same error message. I then used the hex editor to change that byte back from 'o' to 'a'. That removed the error message. Perhaps I should uninstall the latest version and go back to the previous...

Hi Jim, I just tried editing the XML on a VIPB file, but VIPM 2016 complained, "VI Package Builder was unable to open the build spec due to an error." Even changing a single letter in the product summary/description triggers this. Has some kind of checksum system been implemented in VIPM 2016? Is there a way to continue making manual edits on VIPB files? Thanks!

I have a project structure like this: <ProjectRoot> (Project.vipb) Examples Example1 Example2 Source Cpp LabVIEW LVClass1 (Method1.vi) LVClass2 (Method2.vi) The auto-generated Functions Palette is structured like this: [Functions] >> [Company] >> [Project] >> Source >> LabVIEW >> LVClass1 >> Method1.vi [Functions] >> [Company] >> [Project] >> Source >> LabVIEW >> LVClass2 >> Method2.vi However, I would like a simplified palette structure like this: [Functions] >> [Company] >> [Project] >> LVClass1 >> Method1.vi [Functions] >> [Company] >> [Project] >> LVClass2 >> Method2.vi Is there a way to get VIPM to auto-generate the palette that way? I can think of a few workarounds (restructure my project, or add every palette folder manually) but I'm hoping I don't have to resort to them. P.S. Sorry if this is the wrong place to post this, but I'm unable to post on the JKI forums

If you want to make every child of Class B a friend of Class A, that means that A needs to know about every child of B. If you ever need to handle a new status byte, that means you need to create a new child of B, and you also need to update A (to add the new class to its friend list). That's definitely not ideal. However, if you make only Class B a friend of Class A (such that the child classes don't call A's non-public methods directly), I think it's fine. Some more details about your system would be helpful for identifying the "best" design. However, here are some thoughts: Do you truly need one child class per status byte? Would you consider putting one big case structure in HandleStatusByte.vi, that uses the byte as the selector? Do you truly need a separate class to handle the status bytes? Would you consider letting Class A do it directly? (I presume Class A is the interface between your controller and the hardware; all commands are sent through Class A and all status bytes are received through Class A)

There's a few good reasons to separate compiled code from VIs. Now, the option is also available for custom controls/type definitions. I'm wondering if there's any benefit whatsoever in separating compiled code from these? None of the reasons for separation apply to *.ctl files, after all. In fact, it might even be slightly detrimental -- in a few quick experiments, separating compiled code increased the size of the *.ctl files! (Cross-posted at http://forums.ni.com/t5/LabVIEW/Should-I-quot-Separate-compiled-code-from-source-file-quot-for/td-p/3318096 )

You could also write and run a VI that outputs 0 V Alternatively, switch off the cRIO and turn it on again.

Hi, You need to do two things: Make sure you shut down your program properly... not using the Abort Execution button. See http://zone.ni.com/reference/en-XX/help/371361M-01/glang/labview_toolbar/ for a description of the Abort Execution button When your program is shutting down, make it output 0 V.

The speed seems fine to me. @Jordan Kuehn, have you tried a different browser/computer?

Could you collect all your data first, and then plot them afterwards? Out of curiosity, what is the name of this other app? It's possible that your other app was especially designed and optimized for one specific use-case (visualizing a huge number of ECG graphs). LabVIEW graphs are general-purpose and very flexible, so it can be out-performed by a single-purpose, less flexible graphing tool.

True. All icons/glyphs/symbols need to be learnt from somewhere first. The key is creating controls that are consistent with what the target audience is already likely to know, and are unambiguous. (e.g. you can safely assume that smartphone-savvy young'ns already know what "white circle on the left" means :D) Back to answering your original question... For user-facing GUIs, I use the Silver push buttons (the middle column of the gallery in your original post) The leftmost columns are too ugly for my liking, unless the customer specifically asks for the old-school look. http://ux.stackexchange.com/ is a good place to find enthusiasts + experts who are happy to share their ideas and discuss yours

That's normal, because plotting 5000 graphs requires lots of computing resources. May I ask why you want to plot so many overlays at the same time? After all, it's very difficult to see them.

To take another page from Google's Material Design, their switches convey state by using colours without "ON"/"OFF" labels at all: (From https://material.google.com/components/selection-controls.html#selection-controls-switch) I actually experienced the issue that @hooovahh described. It showed "Notify me of replies", with an "X" next to it. I wondered to myself, "Does clicking the 'X' get rid of notifications?" because, from prior experience, clicking 'X' closes windows. Thus, I had to play with it to discover its meaning.

Or, embed Google into your forum: https://support.google.com/customsearch/answer/2630969?hl=en

(EDIT: D'oh, half an hour too slow) Naming user events is an edit-time operation. If I write a subVI that generates and outputs a user event refnum, call the subVI twice, and then register both events at the same event structure, I will get two cases with the same event name (which equals the label of the subVI's output terminal). The workaround consumes a large amount of real estate: (Image taken from http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Name-User-Events-at-Runtime/idi-p/2592841 -- ignore the "runtime" part of the title) I haven't dug into VIMs myself yet, but if they provide a nice way to label the output refnum, that would be very very nice. See also this highly-kudo'ed idea, which seems to be catalysed by the desire to name user events: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Officially-Support-quot-Coerce-to-Type-quot/idi-p/1213153

A very sensible list! Do #5 and #7 could be merged, or at least presented one after the other (#5 sounds like a specific way to do #7) Do #4 should include error messages and error codes whenever applicable. You might also find other useful gems at http://stackoverflow.com/help/how-to-ask Norm's point is a tip for using Google. Type "site:lavag.org ShaunR" into Google and see what happens

I don't have LabVIEW 2015 on my home PC so I can't open your code, but I'll hazard a guess: Is your "recursive" VI configured as Shared Clone Reentrant? This article might lead you to more clues: http://digital.ni.com/public.nsf/allkb/3FBC5856A4BAACB886256D270001A91F I'm not convinced that the error message is talking about recursive object creation, because it clearly flags Abort_EM.vi is the problematic VI. It sounds more like LabVIEW doesn't want to let you call a VI that eventually calls itself again. Do my 2 points above help? However, if it is indeed problematic to include an Abstract Equipment Module instance as a member of the child class, try storing the member as a Variant instead of an Abstract Equipment Module. (You will need to convert the Variant back to an Abstract Equipment Module before running its member VIs).

"Abuse" is such a strong term. I prefer "innovative use", or "thinking outside the box"

Does the user have multiple screens? I've noticed that when one LabVIEW window is moved to a screen with a different resolution and/or different DPI, all LabVIEW windows will change size. (I haven't seen the font shrink by itself without changing the window size, though)

Not directly. Servers are designed to provide data to Clients, not to other servers. If you want, you can write code that uses a Client to read reads the data from one server, and then copy the data to the other Server. However, I suspect you should re-design your code instead. Why do you have 2 separate servers on the same PC? Would it make sense to only have one Server, and put your sensor data under different Folders?

I've seen a Q-DAS DataPlugin to READ these files, but not write: http://www.ni.com/example/31431/en/

To put an item in a particular folder, you need to input the folder's name into Add Item.vi's "parent folder path" input: http://zone.ni.com/reference/en-XX/help/370622N-01/lvmve/opcua_add_item/ Similarly, to put a property in a particular item, you need to input the item's path into Add Property.vi's "item path" input: http://zone.ni.com/reference/en-XX/help/370622N-01/lvmve/opcua_add_prpty/ According to the CSV file that you posted, The "parent folder path" that you need to use for your items is "Process". (This path is outputted by Add Folder.vi) The "item path" that you need to use for your properties is "Process.Temperature". (This path is outputted by Add Item.vi) You're using Indexing on your loop outputs. This creates an Array, which you probably don't want: http://digital.ni.com/public.nsf/allkb/B85025233861378A86256CE700491E34 Have a look at Shift Registers instead: http://www.ni.com/getting-started/labview-basics/shift-registers

Overview VI: The closest thing for now is the "Dynamic GUI Composition and Management" example. The Input Widget contains both QDoubleSpinBox and the QFontComboBox. QDoubleSpinBox: Like a LabVIEW Numeric Control that holds DBL values only. (In contrast, QSpinBox holds I32 values only.) I plan to create a hybrid widget with a selectable numeric Representation, just like what LabVIEW users are used to. QFontComboBox: A drop-down menu that lets you choose a font. This page might also help: http://doc.qt.io/qt-5/widget-classes.html Charts: The pre-existing class (QwtPlot) require users to manage the data arrays manually, which is a bit unwieldy. I created LQChart specially for LQWidgets; I want it to be as similar to a native LabVIEW chart as possible. It's currently incomplete. Right-click popup menu (a.k.a. "Context Menu"): You can create a menu using QActions. The menu items emit the triggered() signal when selected. The "Porting XControls - Dual Mode Thermometer" example uses this. Darn, I just found a bug. In the code below, only the first item will appear in the menu... but once that's fixed, this is how you can code it. As a workaround, you can call QWidget.lvclass:addActions.vi multiple times, and only pass 1 QAction into each call. QML: That's the next-gen GUI framework. The road to full LabVIEW integration involves quite a bit of work, but it's doable I'll probably release QML support incrementally.

I'm interested! Where can I find info on how to do this? The application form sounds like this is meant for companies with a serious product. Do you know if NI accepts applications for hobby projects (or projects not ready for prime time yet)?

This one looks like a LabVIEW bug. I've reported it at http://forums.ni.com/t5/LabVIEW/BUG-Certain-code-paths-make-LabVIEW-deadlock-freeze-when/m-p/3299411 (I hope they won't say something like "callbacks are only meant for use with .NET...") If you modify the example and manually create the new Growable Widget yourself (without triggering any callbacks), you can dynamically add tabs/splitters/MDIs to the top-level tab without causing the freeze. Agreed, using LQ Widgets to complement LabVIEW front panels is the most sensible way to start. Regarding the learning curve in general: What are your thoughts on the "Hello World - Introduction to Widgets" example/tutorial? Was it easy to follow, and was it complete enough? Kind of (not in LabVIEW yet). In C++, the most common way to act on these events is to override the widget's mousePressEvent method, for example. In your override, you can query the event parameters (which does include modifier keys) and run custom code. To integrate this mechanism into LabVIEW, we need to make the C++ side call your LabVIEW-defined event handling code and wait for your result before continuing. I've got an idea but haven't tried it yet. Do you have a use case in mind? Perhaps there's an alternative solution that doesn't involve handling these events.