JKSH

6 hours ago, LogMAN said:

The palettes are auto-generated based on the source directory defined in the Build Information tab. I suppose it is set to <ProjectRoot>, so change it to <ProjectRoot>/Source/LabVIEW and the palettes should be correct.

D'oh! So simple. Yep, that did the trick.

Thanks!

(I miss the old "Mark as solution" feature from the previous forum)

6 hours ago, LogMAN said:

I would like to suggest a way for you to check it yourself: Keep the original file and change one character in your description in VIPM, then compare the two files. If there is a checksum there will be an obvious change in one line.

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???)

6 hours ago, LogMAN said:

If that's not the case you might have broken the package by saving the file in the wrong encoding (UTF-16 instead of UTF-8). Maybe try another editor (Notepad++ is what I work with mostly).

I mainly use Notepad++ too

I know it's definitely not a problem of mis-encoding, because:

1. 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.
2. 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...

On 1/19/2016 at 5:54 AM, Jim Kring said:

Thanks, LogMAN, for the helpful info!

 

Filipe, it sounds like editing the XML worked for your needs. I hope it's all going well for your project.

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 )

4 hours ago, Shravan Raghu said:

i thought there might be a vi for that

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:

1. 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
      
2. 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?

1 hour ago, mohamad said:

I cannot bring rate down

Could you collect all your data first, and then plot them afterwards?

1 hour ago, mohamad said:

it should not be impossible,because I have already saw this feature in another app

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.

On 6/15/2016 at 4:52 PM, drjdpowell said:

But that requires the User to learn what the funny circles are, and what “white circle to the left” means.

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...

On 6/14/2016 at 8:59 PM, drjdpowell said:

My question is: what of the multiple LabVIEW switches do people actually use? 

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.

On 6/14/2016 at 8:59 PM, drjdpowell said:

I’m having a hard time coming up with something that is flat and non-skeumorphic, but also clearly a switch.

http://ux.stackexchange.com/ is a good place to find enthusiasts + experts who are happy to share their ideas and discuss yours

14 hours ago, mohamad said:

But after about 5000 of overlay,it begin to slow.

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.

12 hours ago, hooovahh said:

I can already hear some of my users when they see the switch the first time, and see the text "OFF" they will ask, "Does clicking this turn it off or is it off right now?"

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)

1 hour ago, smithd said:

Also, note the "Notify me of replies" when you post here on lava after the upgrade. Having the check or the x makes it pretty easy to understand the meaning, but thats because its also labeled well..."Notify me of replies" is an obviously true or false statement.

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.

4 hours ago, rolfk said:

In my experience almost all forum searches suck badly in comparison to the standard set by Google. So I would say: Disable it!! 

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

(EDIT: D'oh, half an hour too slow)

2 hours ago, Aristos Queue said:

I don't understand. Why would you expect VIMs to have changed anything with respect to events? This is an edit-time feature, not a run-time feature. Can you explain the link that you're seeing? 

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

4 hours ago, ShaunR said:

Do #1 should be a don't. The site search is useless and we all use Google

Norm's point is a tip for using Google.  Type "site:lavag.org ShaunR" into Google and see what happens

3 hours ago, ARC5200 said:

So my question to everyone is, is there a work around that would give me the same result or is there a more LabVIEW acceptable way to do this?

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

3 hours ago, ARC5200 said:

I believe I understand the reason for this error, which is that technically we are recursively creating these EM’s and therefore can have essentially an infinite amount in memory to interact with.

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).

2 hours ago, ShaunR said:

This is what LavaG is here for.

No-one has even seen this new structure yet and we are already trying to figure out how we can abuse it

"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)

12 hours ago, pato7 said:

for example if I have a server with 5 sensors related to it and another server with 10 sensors related to it. Is it possible to connect these two servers or let them communicate and share data in a labview VI on the same PC?

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/

12 hours ago, pato7 said:

Is there any blocks special for linking nodes to their parents? Or do you have any other solution for linking several items to the same folder?

• 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)

13 hours ago, pato7 said:

Moreover, After exiting the for loop, I am getting an error while wiring the OPC UA blocks to the Start Server Block due to connecting two terminals of different types but I don't know if I can change the data type exiting the for loop without affecting the data structure created inside the loop.

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.

3 hours ago, hooovahh said:

You can put things in various menu bar items, like Tools, and File which can be useful for calling VIs to perform actions on the open VI.

I'm interested! Where can I find info on how to do this?

3 hours ago, hooovahh said:

And there is the Project Provider Framework, which has the ability to add items to the project toolbar, but not many people do this because it can be a pain to work with, and is somewhat incomplete.

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)?

On 5/17/2016 at 10:57 PM, mwebster said:

It was the one you actually mentioned in your documentation with the dynamic GUI composition, where selecting Tab Widget, Splitter, or MDI Area causes LabVIEW to freeze when transitioning back to edit mode.

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.

On 5/17/2016 at 10:57 PM, mwebster said:

I do agree that the learning curve would be easier to absorb into a large scale project.  I guess my problem is I work on too many medium scale (1 or 2 developer) projects.  The intimidating thing to me was the thought of using this for the entirety of the project, I'm much more comfortable with using a piece of it to implement something LabVIEW can't do on its own.

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?

On 5/17/2016 at 10:57 PM, mwebster said:

I was wondering though, can you get any events from the widgets besides the signals they emit (valueChanged, sliderPressed)?  i.e. mouseover, mouse down with modifier keys, etc?

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.