JackDunaway

I'm not sure what you mean its not recognised.

Referring to the screenshot where `libstringtools.dylib` is greyed and disabled when the LabVIEW dialog filters only files of type "Shared Libraries". When the filter is changed to "All Documents" (i.e., any filetype), the shared library becomes un-greyed.

Additionally, `*.dylib` is not recognized as the shared library type on OS X. 

This was worded poorly, making it sound like the bug is in OS X. In this dialogue, LabVIEW apparently only considers `.framework` filetypes as being a "Shared Library", but not `.dylib` filetypes.

I'm saying that dataflow, in a dataflow paradigm, has a specific operational meaning and is a defined concept. It is not is just an analogy to a river flowing to aid comprehension for data being produced and consumed. I'm just picking you up on watering down (no pun intended ) the definition by conveniently ignoring state.

 

Do "Channel Wires", "Asynchronous Wires", "Pipes", "Conduits", "Meanders", "Dunaway Dynamic Data Doorways" or whatever you want to call them   implicitly impart execution state? The answer is the answer to whether they are part of a dataflow paradigm or not.

Does a Channel Wire fall within your definition of "dataflow"?

Sorry. I'm not going to let you get away with that conflation. Dataflow has a specific architectural meaning

For clarity: are you saying that Channel Wires (this is the official name and a much better name; my usage of `async wire` is I believe what it used to be called until being replaced by the better name Channel Wire) are not `dataflow`, and considering them as such conflates concepts to a point of confusion?

You must be using LV2011 or below.

I came to the conclusion (rightly or wrongly) that dylib support was an incremental development on the Mac with the dialogue one step behind.

LV2010 and below cannot use dylibs at all (the library won't load). In Labview 2011, you cannot choose them from the drop down in the CLFN (must be Framework), but they do work, So if you create the call in 2012 and back-save or type the path and function name in;, it will be fine (the library will load).

2012 and later are fine and you can select them in the drop-down..

It appears that in LV2015 LabVIEW does not populate the drop-down with exported functions, but "everything works" if you manually set it up.

In other words, you can type or paste into the `Function name` box on the configuration window and the code executes as expected -- you just miss the UI affordance of that cozy feeling seeing the drop-down arrow go from disabled to enabled once pointing to the library, and the type-ahead autofill for function names.

Additionally, `*.dylib` is not recognized as the shared library type on OS X. 

Now with async wires, it's important we more clearly define our historical usage of the word "dataflow" to mean "synchronous dataflow", also acknowledging "asynchronous dataflow" is a better way to describe we've historically called "breaking dataflow".

The undecorated word "dataflow" just means that data moves, either temporally or spatially. Synchronous and asynchronous dataflow are desirable for different reasons at different layers.

Async wires are a huge opportunity to explore innovation on procedural logic at the functional/diagram level (this syntax at systems/application layer right now is less interesting). I would recommend checking out an awesome example AQ posted on: https://decibel.ni.com/content/docs/DOC-42942 

You purchase it by contacting NI and they tell you how to get it.

True. Unless something has changed for LV2015, you can request a copy from your sales contact, and they will ship you a DVD. (Yes. A DVD. For a Mac.) Word on the street, this might be changing to USB drive soon? (Which is also kinda jokey, unless there's a USB-C option as well!!)

Mac version doesn't have all the same license controls on it to limit piracy, so it isn't just downloadable the way the Windows version is.

The licensing technology is basically a pinky swear. One thing that's totally awesome is how fast it installs.

All this needs is the ability to specify terminal allowed types, including matching output types to inputs.   For example: “A must be a string", "B must be a numeric", “output C must be the same type as input Dâ€, etc.  Then it would be extremely useful (and would implement my long-declined idea).

Yep. This would help begin to bring parity with other languages' Generics (or Templates) abilities (the most concise read explaining this is Rust Generics annotated with Trait Bounds. If the word Trait muddies the waters here... just replace that with `Datatype, but totally super-awesomer`)

Additionally, I've built just enough XNodes (8-10 or so) to be of the opinion that VIM's are a little too underpowered to be considered over XNodes for the framework/middleware layers and below, but miiight be useful at the one-off application layer (extrapolating here, not based on battle scars and victories), where "saving development time" knob is tuned a bit higher, and "most elegant/usable syntax imaginable" is a bit lower.

To make a more familiar analogy on the LabVIEW Front Panel -- at the application layer, I would plop a subpanel and insert a VI long before considering creating an XControl, because making XControls takes marginally more time and introduces finitely more risk/liability. On the other hand, middleware/framework functionality to be reused many times warrants investment into more polish to provide that rich experience and in the words of Professor Steve Watts "Fewer WTF's".

That's all -- just jumping in to mention that the concepts of XNodes and VIM's "look a lot alike", but I don't feel are competing technologies, since their merits are tuned for different layers of the software stack.

And comparing XNodes and VIMs in LabVIEW to Generics of other languages -- VIMs fall short in capability, but XNodes can go far beyond the basic value proposition of a Generic function to enrich your DevX and IDE. (Let's save the conversations for how XNodes could be drastically improved for another day and another thread   )

It appears `<vi.lib>:\resource\lvstring.rsc` has not been updated since sometime before LV2014, so for that reason it's not a great "central source of truth" for discovering Abilities. Instead, here's a list that's perhaps a bit more updated, parking here so it's indexed by search engines.

This list was generated by simply searching the <labview> directory for all files of type `.xnode`, then using XPath queries to extract all `NI.XItem.Name` abilities. It appears that many of these "correct" names map closely to the stale `lvstring.rsc` names -- for example, it appears that what used to be called "GetImage" is now just called "Image". One important one you'll need: "UpdateState*" is now "UpdateStateWithRef"

Well sure but I wanted to avoid this technique because when LabVIEW 2015 comes out, this will make XNodes in the 2014 version.

Can bypass this detail too:

I'm a bit disappointed that NI have just made a rats nest bigger rather than trying to make creating xnodes easier.

I hear your sentiment, but want to at least commend the continued investment by NI into more XNode capability/stability over the past several years. But yes, they remain hard to develop and opaque and under-powered and quirky and rude to LVClass types, but hooovahh's efforts here will help some of these issues :-)

When it comes to Xnodes/controls. There is only one aspect that I'm particularly interested in and that is a replacement for a polymorphic VI.

Here, Generics could be a lighter-weight syntax to accomplish the same thing (where XNodes are currently the only reliable implementation of Generics in LabVIEW), but XNodes can do *way* cooler things in the IDE than just type propagation and define function signatures. But totally agree with the sentiment that replacing PolyVIs is keen and high-value with C++esque Templates

Oh it's not hard, it's you just need to use unconventional tools.  A while ago I posted a bunch of VIs that open up the VI file structure.

`YourExample::Get All Block Data.vi` == `lvrt::REdLoadResFile()` 

I'll be there!  Looking forward to the BBQ again except for the ten block walk from the convention center in 100 Deg heat

Protip: attend Challenge the Champions in the Tech Theatre during the Block Diagram party on Tuesday nite -- there, you will find dozens of people headed to the BBQ. I'll email the moderator of that event to make an announcement to help facilitate BBQ-goers find each other in order to share cabs or walk together in droves. See you there!

Unless something has changed since LV2010, determining whether the BD exists in the RTE will be hard: http://labviewwiki.org/Loading_vis

It appears that `Metrics: Block Diagram Loaded` "works" in the RTE, but it is hard to test since it is hard to load the BD (as per above link)

Have you tried exported LVRTE function `REdLoadResFile()`? That might not be so flaky as the naïve approach to examining the bits. Good luck!

copy the appropriate INI keys from labview.ini into your exe's ini file and the runtime will allocate the right number of threads on launch.

True.

Are you saying that the # threads can be increased past 8 per execution system

Yes. Quick battle story. I was dismayed on a project mid-2014 to realize the root of an inexplicable bug was due to thread exhaustion, which would have been costly to refactor (as in, "let's move this big chunk of the application from LabVIEW to another language"). The failure mode was terrible to debug -- any part of the system could arbitrarily fail at any time! I was delighted to find that manually editing `LabVIEW.ini` to increase values beyond the arbitrary limit of 20 threads per executionsystem/priority imposed by `threadconfig.vi` actually worked! Said another way: "As a LabVIEW developer, you don't have to worry about threads*... until you do... and you will, given sufficient non-trivial applications."

* `threads` is interchangeable with `memory allocation` here

create more execution systems

False... to my knowledge and testing.

Does anyone know how to find out the status of an orphan CAR?  I have one from a few years ago (313508) and the same issue is biting me in the backside, again.  So it looks like it wasn't fixed.

 

Cat

Searching `site:ni.com 313508` leads to: https://forums.ni.com/t5/LabVIEW/Process-freezes-for-a-few-seconds/td-p/2309090

Does your application have a similar number of parallel "actors"? (the original post in the thread above mentions 52 parallel "actors) What does CPU usage do during this pause?

If you have a lot of parallel loops, and if CPU drops to near-zero during these "pauses", you might be exhausting the thread pool per execution system in LabVIEW.

If this sounds like the case, try bumping the thread count higher than 20 (the default). To do this, use `threadconfig.vi` which will then create 25 or so entries in your `LabVIEW.ini` file, then manually edit those numbers using a text editor to be higher (e.g., 50).

There's a few of us at NI -- in several different products -- that saw this trend a couple years ago when Adobe first started trying it out; we preemptively raised objections to LabVIEW moving in that direction,

 

So you might want to occasionally mention to Field Sales, "You know, I really like owning my own software." Express not just objections but also advantages with the current situation. Doing so will help keep the allergy strong!

+1.

Steve Wozniak is credited for saying "Never trust a computer you can't throw out a window"

Does this mean old code will be 'broken' in 2013+?

Likely; mine was, and it appears @hooovahh's was also. One patch for backwards compatibility is to dynamically dispatch via CBR a version saved in LV for <2012 and another for >=2013.

Okay did NI change something, or am I crazy?

Both, pal! But in LV13.0bxx era, I asked the same question, and the unofficially-reworded response was "yep; we [NI] changed this because previous to this change the AppRef was leaking; just keep it open til you've done what you need to do with the newly-created VIRef, then `Close Reference` on the AppRef and it'll work like it used to, just less-leaky".

I've used that guidance for 2yrs now with success; your independently-discovered `*Edit` is the correct way to use this method now.

I've been getting my hands dirty with embedded C programming lately for AVR chips. A fascinating reversal of perspective from LabVIEW where resources are so abundant you don't need to think of them. I think it's good to rotate skills from time to time, lest one become overly focused on a single tool.

I spent more time in cross-platform C than LabVIEW in 2014. My respect and awe for LabVIEW was previously naïve and fanboy-ish, and is now tempered with scars inflicted by kernel-level resource management.

Will report back in 2016 on how my 2015 view of LabVIEW was naïve.

(eyeballing Rust)

Hi all,

 

I'm having problems with a program I've written that hangs after some period of running. The program is fairly simple but it does a lot of xml parsing so to fix the problem I'm looking for things like references that are not closed. I have found one unclosed reference in one of my subVI:s but I can't close it without breaking the program so I look to you for help.

 

The reference in question is the "Node Out" reference in the NI_XML.lvlib:Get First Matched Node.vi marked in the attached file CloseRef. What I would like to do is really to wire it to the invoke node (and not use the "Refnum in" there) but that does not work because somehow the reference has changed from a document reference to a node reference. If I just close the "Node Out" reference my program doesn't work (I guess it kills the "Refnum in" reference which I need later on).

 

CloseRef.PNG

 

Any ideas on how I could handle the matter?

Maybe this is not the cause of the program hanging but it's the best candidate I found so far.

 

Thanks

Martin

Eyeballing your code, the leak could still exist, but not for the reason initially considered that Rolf explains. Below, demonstration how the dtor conditionally destroys only when no error is input (and an unrelated but additional digression from POLA, returning no error destroying an already-destroyed object).

The fix at the app-code layer would be to ensure dtor executes unconditionally (by guaranteeing no error flow in), then merging output errors with upstream.

We will have a private section of the Discussion Forums set up for beta users to discuss the beta version of the LabVIEW 2015 Platform.  All questions or comments regarding a LabVIEW product that is in beta must be discussed in this private forum. 

Lisa, welcome to LAVA! +1 for posting the announcement here.

To all who have never joined the LabVIEW Beta -- this private forum Lisa mentions used for Beta discussion is an excellent resource for the latest in-depth LabVIEW topics. LabVIEW R&D historically has been active and responsive on this forum, and it's your opportunity to influence the product while there's still a little churn remaining before release.

Last month I ran into a problem building an application with LabVIEW claiming a certain VI was "broken."

 

The VI wasn't broken, but in one of its subVIs there was a FOR loop with a conditional indexing tunnel. When I replaced this with the old-style of conditional indexing (shift register, case register, build array) the program was able to build.

 

Today I ran into the same problem, where adding a conditional indexing tunnel caused a build to fail with the same error.

 

I remember running into LabVIEW crash problems when conditional indexing was first introduced, but I was told it would be fixed for 2013. Is this not the case? Does anyone know if a "real" or "complete" fix has gone in for 2014?

Step 1: clear your compiled object cache. Same result? Or do you get a "VI Failed to Compile" error after this action?

An issue was reported in 2012 for conditional-autoindexed composite types (e.g., LVClasses) in parallel For Loops. Although not mentioned in your original post, is this a Parallel For Loop or not? And is the datatype primitive (integer/bool/string) or composite (LVClass/typedef)?

The ways I can see of dealing with this are:

1. Extend the interface to include a frequency cut-off parameter (redundant for 90% of messages.)
2. Break down the interface and expose different sub-interfaces (pass complexity on to calling code...)

Any other ways?

Search Liskov substitution principle (abbreviated LSP in OO circles). Your #1 choice above is a violation of LSP, and therefore probably not a good idea.

---

Using your case study of a signal generator configuration, let's consider our design dilemma centers around the ConPane of "Configure Signal Generator.vi", which is intended to be an abstract method of parent "Signal Generator.lvclass" marked as "Must Override" for implementation by all subclasses. As you point out, this method requires different arguments (input parameters) that are specific to the subclass.

This dilemma has at least 3 resolutions that are correct:

• Use dynamic typing rather that static typing for input/output arguments. JSON is a good choice in 2014 that provides both strong typing and dynamic typing (as opposed to weak typing and static typing). XML is your second choice. INI is a suboptimal choice. Your Own Clever Protocol (YOCP) is a significantly suboptimal choice. LvVariant... exists as a choice (with editorial value judgement reserved at this time).
• Use dependency injection (DI) and/or constructor injection (constructor is sometimes abbreviated ctor). But! If the constructed object you are injecting can have purely by-val semantics with no by-ref or active object requirements, this could be a code smell. Specifically, since it represents an "OO purist" idiom of circumventing dynamic typing, which represents far less syntax and bloat. (Plus, joke's still on you! You've just deferred and complicated the exact same problem, abstracting the problem of concrete input parameters to the Configuration class constructors rather than implementation methods. Said another way -- object configuration is probably not best solved with DI in LabVIEW.)
• Acknowledge that "Configure Signal Generator.vi" is an inappropriate abstract method of the supertype, but should instead be reserved as concrete methods of subclasses that "look and feel like they ought to conform to an inheritance relationship but just don't because they don't really IRL and i accept this".

There are more incorrect resolutions. Here are some obvious ones where I have tried and failed:

• Bloat the superclass with subtype-specific methods. Why is this wrong? This violates LSP, enables (encourages?) incorrect usage of subclasses, and throws run-time errors rather than compile-time errors.
• Bloat ancestor methods with descendent-specific parameters (input and output). Why is this wrong? This violates LSP, enables (encourages?) incorrect usage of subclasses, and throws run-time errors rather than compile-time errors.
• Inject Signal Generator Configuration.lvclass into the Signal Generator.lvclass "ctor" method (LabVIEW does not have canonical object constructors, hence air quotes around "ctor"). Why is this wrong? I was once excited to have "discovered" this solution, and gleefully coding the Configuration classes, only to realize, on completion of this dual hierarchy of redundancy, the exact same problem existed with the ctors of the Configuration classes.
• Use #1 or #2 "correct" solution above, when I should have chosen #3. After doing this many times, I realized eventually LVOOP might not contain sufficiently-expressive constructs to represent object models of my application domains. Mixins (or traits), available in modern OO languages, might be a solution, and a construct we could consider rooting for in LVOOP.

YMMV! Hope this helps. All bolded terms are searchable.

Justin, thanks for the Win8.1 walkthru; indeed it's a little different than my screenshots from Win7.

One thing -- can you provide another walkthru on where you found that "Restart" button on Win8.1? Bonus points for avoiding the word "gesture".

( )

Forgive the stupid question, but is this a setting you changed in Windows or in OS X?  It's fantastic to hear that someone finally got to the bottom of this!  I'm having a little trouble figuring out exactly what you did though - forgive me for being slow...

No worries! It's TOTALLY buried in the Windows settings:

First, from Control Panel, search for "Region and Language", then click on "Change Keyboards"

That brings up this window. If you see in your VM what we see below -- only a single "(Apple)" locale -- it's likely your keyboard shortcuts are not working in LabVIEW:

To solve the problem, "Add" a new keyboard, selecting the US keyboard and setting it as the default. Be sure to relaunch LabVIEW if it was open!