LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

iPad picture2.jpg

 

This idea is similar to two other ideas:

1) http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Support-for-HTML5-and-SVG-in-Web-Publishing-Tool/idi-p/1437488

2) http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Remote-Access-to-LabVIEW-using-HTML5/idi-p/1944781 ,

 

However, this idea has the following unique aspects/extensions:

 

1) In the past, it appears that the decision needed to be made between a Native App (like Data Dashboard) or a Web App. However, I believe both should be developed by NI. See http://www.ericbrynsvold.com/2011/11/native-vs-web-app/ and http://www.webmonkey.com/2010/08/how-do-native-apps-and-web-apps-compare for more details and an examination of the pros and cons. Facebook has both a native app and a mobile app and the user interface looks the same! So, the important thing is, it’s not one or the other, with both having their place.

 

2) Don’t develop the LabVIEW web app fully and then release it. Follow the path taken by the Data Dashboard for LabVIEW and release bits at time. This way we get something to use relatively quickly. Just simple numeric controls and indicators and Boolean controls and indicators would do to start with.

 

3) Put as much development effort into the web app as is currently going into the native app (Data Dashboard for LabVIEW).

 

4) The web browser user interface should reflect the contents of a VI. Also, multiple VIs / sub-VIs can be addressed. This last part is important since different devices may need different interfaces. For instance, for my upcoming home automation project, the user interface for the bedroom would be different to that for the home theatre.

 

Although Native Apps like Data Dashboard give a rich user experience, the effort required to handle multiple platforms can become onerous, as detailed in https://decibel.ni.com/content/docs/DOC-19388#comment-23928 . The Web App does not have to have the performance of the Native App. What is lost in performance (and I think this is not a big issue) it gains in universality.

 

I believe the need for both LabVIEW remote access using native and web apps, the concept of releasing early and releasing often and putting the same level of effort as the native app are the essence of this idea.

 

It important that the web app be able to use a standard web browser without any plug in. This way any mobile device can be targeted.

 

Wouldn’t it be great to use any web browser to provide a great remote user interface for LabVIEW?

With NI-DAQmx 9.0 and later, you can log data to TDMS files from directly within the DAQmx API. By configuring logging via the DAQmx Configure Logging VI, you can easily integrate TDMS logging into existing applications. Tests with the DAQmx Configure Logging VI have realized data streaming rates of more than 1.2 GB/s. See TDMS Direct Integration in NI-DAQmx Logging.

 

 

 

I propose extending a similar capability to IMAQ Sessions so that when IMAQ Grab Acquire.vi is executed, the raw image data would automatically be streamed to disk (without having to create a copy of all the image data).  One of the most difficult and time consuming efforts when acquiring images is saving the data to disk efficiently. It would be highly beneficial and save lots of development time to create a similar functionality for IMAQ.  ie an "IMAQ Configure Logging (TDMS).vi"

 

TDMS IMAQ.png

 

 

 

 

 

Since I'm working with LV-DLLs there is a very very annoying Bug. I just made my first tries in LV 2012 (up to now I'm using LV 2009) and I recognized that the bug is still there but an information/warning dialog opens now when it takes effect. With other words: The bug became a feature ;-( So it's time to make a suggestion for changing in the LV behaviour.

 

Here are the steps you have to take to reproduce the problem:

1) create a new, empty LV project

 

2) first create a cluster, store it as type def and add the type def to the project

typedef.jpg 

 

3) create a new VI (called test) that uses this cluster as output (input will work, too). Add the VI to the project, too.

 2.jpg

 

4. Create a DLL-Spec with this VI as exported function (sorry, I’m using a German LV):

 3.jpg

 

5. Usually the default prototype is not the best. So we re-configure it like this.

4.jpg

Click to ok and store the project and all files.

 

 

6. Ok, last step: Building the DLL 🙂
 – Ups, we forgot to change the element “n” inside of the typedef-cluster to U16 (it’s still set to double).
But no problem – changing the typedef will correct the bug everywhere where the ctl is used.
Open the typedef, change and store it. Now re-build the bug-free DLL - finished! .. or not? No, you're not. Because you changed the type def LabView has reset the hard configured prototype to default *grmpfl* Smiley Mad

 

Now you might say: “Hey, where is the problem, just re-configure it.”

Currently I have a single project which uses up to 25 DLLs created in LV. All are using the same data cluster typedef. Each DLL has approximately 10 exported VIs. This makes 250 prototypes I have to re-configure if there is just one little change within my cluster!!!

LV resets the prototype even if a VI-IO changes from “required” to “recommended” – a change that does not have any effect to the behaviour of the exported VI.

 

So NI, please change this “feature” to a real feature as soon as possible!

 

Meanwhile I have to go on using variant elements to send data to my DLLs and back.

 

 

Appended you'll find a very similar example. Don't forget to save the VI after you've changed the type def.

 

ipad_hor_lights[1].png

One of my planned projects is to write home automation software for my new house. I already have three iPads installed in the wall (kitchen, theatre and upstairs), all my awning windows are motorised, I have a solar powered hydronic in-slab heating system that needs the right type of control, earth tubes, a whole-house fan, solar chimneys, many other passive climate control features and plenty of data cabling throughout the house. User interface access would also be via iPhone, which I carry in my pocket at all times, and mobile iPads.

 

The intention is to automate the house for climate control, lighting, theatre control, security, monitoring electricity usage, monitoring phone costs, controlling the hot water system, seeing who’s at the front door and letting them in (even if I'm not home), setting up a in-house phone/intercom system, limiting phone use, changing TV channels, looking at weather forecasts for activating systems in anticipation of tomorrow’s weather, remotely viewing the inside of the house, and plenty more. You could call it a life-long project!

 

I’d like to use LabVIEW for programming since it’s the most fun language I know. The only problem is that when it comes to easily programming a great user interface, I can’t find the way.

 

1) Data Dashboard for LabVIEW is too limiting with only 6 indicators and no controls (and needs work at the iPad end?)

2) Web UI builder is way too expensive (I need a free solution) and cumbersome

 

What’s also important is that different rooms can have different user interfaces. Perhaps each can reflect the front panel of a sub-VI.

 

There are plenty of examples on the web of great looking Home Automation iPad user interfaces. Apart form the example shown above, http://a2.mzstatic.com/us/r1000/089/Purple/v4/d9/23/ec/d923ec9c-0a31-6a62-cb7c-e74a4f8feecc/mzl.uayvvtoo.480x480-75.jpg looks good. Such great user interfaces and there is no way (or I don’t know how) to make them happen using LabVIEW.

 

This may not need to be a product development, per se, but may actually just turn out to be a step by step set of instructions on how to achieve the outcome using existing tools and an example application. Given what I imagine as a wide appeal for such a LabVIEW user interface, I think it’s worth the effort and could be used for many other application such as process control.

 

The basic criteria are:

1)    Must work with iPhone, iPad (and Android devices)

2)    All programming at the desktop (I don’t want to stand in front of multiple iPads setting them up/updating)

3)    User interfaces must look as good as the examples on the web (and sampled here)

4)    No additional cost

 

Wouldn’t it be great to have a LabVIEW based Home Automation user interface that is versatile, easy to use and free?

Remark: I'm using LV2015SP1, maybe there is already a change in LV2016 which I do not know!

 

Question:
Why is the decoration-element-palette of the block diagramm located inside Functions => Programming => Structures ??

In my opinion it's just a styling element which can be used for everything and nothing.
So my simple idea is to move it to the top level Functions-palette so that it can be easily found and reached.

Even to this day, I still use the Simple Error Handler, for times when I'm writing throwaway code, normally when I'm stress testing a new API.

 

When that dialog is thrown, you should have the option to bring up the block diagram of the VI where it occurred.  Kind of the way breakpoints are done.  Just another button on the dialog that says "Take me there."

 

This is not a high impact improvement, but it also has no chance of hurting anything, and I think an intern could do this.  I guess I could just do it myself, but it should be baked into LV.

 

 

~~~~

Post edit:  holy cow!  Your spell checker is from 1996.  Terrible!  You guys have the best technology, I'm shocked by how retarded it is when you hit the 'Spell Check' button.  What does that message even mean?  I'll translate:  Do you not want me to not undo something that may not have happened?

 

I am sure that someone has suggested this before, and yes I know the workaround for floating point numbers, but being able to do regular expressions, comparasons and maybe simple bits of code (C/Matlab) would be nice.  

 

FP case structure.png

Hi all

I am still missing some kind of SubVI structure. The third representation - SubVI displayed as icon, expanded icon or its own block diagram in new structure. A modification in one structure of one vi reflects immediately in all others. This could increase code readability in some cases.

 

lv1.pnglv2.png

 

  1. click (select it) on a subvi(s)*
  2. press shift
  3. LV suggests the next vi with auto connections
  4. use that or simply scroll through the alternate choices suggested by lv
  5. click it

sweet!

 

*should be only for low level / driver APIs

 

 

new 3.jpg

I know we have some ways to personalize the Getting Started window but to my taste, it's not enough!

What exists right now could be integrated into a SubPanel to keep the same functionality and that would also let anyone make it's own little plugin into this windows.

 

Here's a little example :

 

gsw.PNG

A BD control/indicator/constant can be changed to either other type by contextual menu. For individual objects, Constant as well as Show/Hide are a choice; but for multiple selections, not -- why?

Screenshot from 2015-05-14 00:24:24.png  Screenshot from 2015-05-14 00:25:03.png

 

Note that this is not exactly a duplicate of Every GUI Programmer's Dream... (completed in Labview 2012), rather a part of the implied request which has been left out.

I would like a feature similar to Control-Click-Drag which creates room within a diagram.  However, this version (Alt-Click-Drag) would create a rectangle of empty space bounded by the endpoints fo the drag, but only move those objects which within the new area.  Those objects would expand outward and push any objects which they bump into while expanding.  Objects which are distant would not be pushed.

Sometimes / often it happens that I add an existing VI to an exiting class or lib.

In this case the icon of the added VI stays at it is and does not change to the libraries icon. I could use the lvlib-option-function "apply icon to VIs" but this changes all my VIs which is not appreciated!

 

What I suggest to add is a right-click option to the VIs icon "set library icon" (see attached picture).

 

It should be nice to be able to create a "typedef enum" for the pages of a tabcontrol ...

So the modification of a tabPage label could be automaticaly propagated to constants ..

 

 

The problem is ... When you modify the pages labels, and if you use the constant value associated with the pages ...

The associated wires are then brocken ... They are not automatically modified Smiley Mad

 

When you only want to modify the Label of a tabPage (For example to correct a mistake), the Vi will no more work !

 

An other idea would be to add a kind of "Caption" to the tabPages, in order to disociate the 'Display name' and the Variable name ...

 

Here a short example ...

 

TabPage1.PNG

 

TabPage2.PNG

 

Other Idea : (From the well known Roms)

 

It should be nice to create the TabPages of a TabControl automaticaty  from a typedef enum, and keep the link between the two items.

 

=> Modification of the TabPages modifies the typedef enum

=> Modification of the typedef Enum, modifies the TabControl content

 

 

 

 

Simple Idea:

There should be a timed FOR loop.

 

All the same awesomeness of the Timed (While) Loop, but stops when the auto-indexed array finishs or after N executions.

 

A picture because Ideas with pictures get more Kudos:

Timed FOR Loop 2.PNG

 

Hello all,

 

What Happens

When I move my project hierarchies to different directories on disk, often I notice that build specs lose most of their configuration.

 

Why?

I've theorized that this may be due to references to absolute paths, but when I look in the XML of the .lvproj file, this doesn't seem to be the case.  My other theory is that it has something to do with auto-populating folders, which I use extensively.  (Maybe I shouldn't?)

 

Is there some practice that I should be avoiding?  Nonetheless, I'd appreciate it if this were fixed.

 

More Context

I use source control in my everyday development.  (Peforce, in case you're curious)  I notice that when I switch workspaces on different PCs or a different developer uses another location on disk, I often have to reconstruct build specs by hand.  It's really annoying, especially because there's no easy way to export or import a build spec.

 

Has anyone else experienced this?  If so, please vote for this idea.

 

 

 

Currenly we have the option to set default control style (System, Modern, Classic). But it would be great to be able to specify a control as the default for a particular data type.

 

Use Case: whenever you convert a boolean constant to boolean control, you get a boolean radio button when your default controls are the System controls. Unless you have at least two options to choose from, a readio button is kind of pointless. So, call it a preference, but I always end up changing it to a check box, copying the label/caption to the boolean text (so you can click on the text to change the value, I guess people have learnt to expect it), and then hiding the label.

Wouldn't it be great to specify these parameters in preferences and always get a checkbox with the boolean text visible (and label hidden?), and boolean text being the same as the label? OK, may be I'm asking for too much, but at least getting a checkbox would be a good start.

 

An extension of the idea could allow us to specify may be a custom control as the default control for a data type. This already works when creating constants or controls are the wire whose data type is a typedef.

I just noticed the Find VI's Callers option isn't available when trying to find callers for a vim file.

 

this_vi_callers_vim.png

 

So the idea is to allow this option for malleable VIs!

There are two undocumented events for arrays:

 

APP_SC_DELETE_ELEMENT

APP_SC_INSERT_ELEMENT_BEFORE

 

which are unfortunately lost when you replace the array contextual menu by your own.

 

They could in principle allow finding which element a user has deleted or inserted. Indeed, sometimes "OldValue" and "NewValue" are not enough to infer this information (think about identical values in an array).

 

BUT

 

The only additional information currently provided is "Coords", which tells where on the FP the user event was generated.

In principle, it should be feasible to get back to the location of the element involved and from there find out the element's index, but add scrollbars, panels etc, and that rapidly becomes a project by itself. Moreover, you can "insert" a value to the end of an empty array control and the inserted element will anyway be "inserted" as the last element (which also be the first and only element).

In other words, after having carefully computed where the click took place, you will still have to figure more about the control itself to make sure all the corner cases are covered. Big PITA.

 

Instead, I'd suggest to have both events also output the array index (or colum/row, in the case of a 2D array (*)) where the event occured. This is a known information to LabVIEW, since the control is updated just fine.

 

Now there is still the issue that the insert and delete element events are accompanied by a synchronous "Value Change" event, but that can be dealt with in a rather simple way (as long as you are aware of it).

 

So in summary, my suggestion is, as the title indicates, to provide an "Array Index" output for the "insert..." and "delete element from array" events

 

(*) Notice that there is no such shortcut event for array with higher dimensions...

Hello all,

 

I'd like to suggest some improvements to the run-time menu editor dialog:  (This is found under Edit->Run-Time Menu...)

 

1.     Allow the window to be resizable.  (Scroll bars are no fun)

 

2.     When using source control (Perforce in my case), prompt the user to check out the .rtm file upon the first edit. (Same behavior as when editing VIs)  At present, if I forget to check out the menu file I get a very ugly dialog followed by an "Emergency Backup Destination" prompt.  [insert muttering of naughty words]

 

PermissionError.png

 

I'm then faced with two choices: Either I can save an "emergency backup," as the prompt refers to it, or lose all of my changes and edit my menu all over again.

 

3.     The manner in which the tree manipulation works seems kind of wonky to me.  I've been using it for a long time, but I'm getting to the point where I stop and ask, "Why does it do that?"  For instance:

 

Let's say I select the root node of my "Edit" menu which has several items under it, and I've got that menu open.  If I press the yellow, down arrow, the whole Edit menu relocates itself under my File menu.  The file menu is above the Edit menu!  Why does pressing "down" move the menu up?  Intuitively, I'd expect the entire Edit menu to move as a unit and appear after my View menu, exactly as it would if the whole "Edit" subtree was closed.  (This is hard to explain and I understand if my explanation is likely confusing.)

 

4.     When dragging and dropping tree nodes, there's no visual cue as to where the item will land.  You start dragging the node, mouse over the general area and cross your fingers.  Alternatively, you can eschew dragging and dropping altogether and opt for the yellow arrows of wonkiness.  Okay, in fairness the arrows are usually alright.

 

5.     I would really like to see Edit->Undo and Edit-Redo on this editor dialog.  Having to revert entirely and reopen the file can be frustrating.  Mistakes happen often, especially when dragging and dropping.

 

6.     This is less important to me than the other suggestions, but... is there any reason why the menu files couldn't be encoded in XML?  Right now they're not very text editor friendly.

 

 

Of course, as I offer these suggestions I intend no disrespect toward whomever developed the dialog - I'm simply perceiving room for improvement.

 

Thanks very much,

 

Jim