Search the Community

Hi. I’ve discovered what appears to me to be a quirk in the behavior of dataflow in LabVIEW. This discovery occurred while working on an application that contains a main while loop and housekeeping code that runs after the main while loop. I’m enforcing the order of execution in the VI by wiring the error cluster through the main while loop and over to the housekeeping code. Attached is a zip file containing a VI that reduces the application to its key components. The VI contains two while loops connected by an error cluster. The cluster passes through a subvi and sequence structure in the first loop, then passes through the second while loop and finally enters another subvi. A screenshot of the VI block diagram is also attached. When the VI execution property “Allow debugging” is selected, the VI operates as expected - the second loop will not start until the first loop stops. The quirk occurs when “Allow debugging” is de-selected. In this case, both loops begin running as soon as the VI starts! For some reason, the two subvis and the sequence structure are required to make this phenomenon occur. This phenomenon also occurs when the sequence structure is replaced with a conditional disable structure. This behavior occurs in at least the following two environments: 1) LabVIEW 2014 32-bit on Windows 8.1 running within Parallels Desktop 11 for Mac 2) LabVIEW 2015 SP1 32-bit on Windows 10 I suspect that the cause of this behavior is that the LabVIEW compiler is trying to optimize the VI performance by noticing that the second loop and second subvi are not dependent on any data generated in the first while loop. If this is the case, it’s great that the compiler is trying to improve VI performance; however, what’s not so great is i) this demo VI shows that the error cluster does not always enforce order of execution, and ii) a change in the "Allow debugging" setting can change the behavior of a VI without any indication to the developer. This apparent quirk raises two questions: - Are there other situations where the dataflow paradigm does not behave as expected? - Are there any tools available to find out about changes that LabVIEW implements behind the scenes that could cause this or other unexpected behaviors? A short video demonstrating this issue is available here: http://www.screencast.com/t/D3mCCqFyz Any thoughts on this issue would be much appreciated. -John Bergmans Data Flow Test.zip_remove_me

When I originally selected the name for my blog ExpressionFlow back many years ago, what I had in mind was functional dataflow programming and the ability to pass any subdiagrams (expressions) around as first class citizens of the language. Functional programming languages (haskell, clojure, lisp) have a lot in common with dataflow world. In principle, calling a function in a functional language is identical to calling a node in a visual language. Passing data between functions happens in an immutable way in functional languages, similar to the concept of data flowing between nodes in a flow-based programming languages. Monads determine execution order of functions with side effects, the same way as flow diagrams determine the execution order of nodes in LabVIEW. Functional programming is often seen as an alternative to object oriented programming. One can solve similar problems of dynamic dispatching either by passing functions around or passing objects with methods around. There are of course multi-paradigm languages supporting both objects and functions like Clojure and Scala. So what would LabVIEW look like if it supported concepts of functional programming paradigm? I posted an article on this on ExpressionFlow and I am intending to study the concept on ExpressionFlow in my future posts. Would you use functional LabVIEW if such a language existed? My post on how a functional programming could appear in a visual dataflow language: Synchronous Functional Dataflow Programming & Closures of Named Functions p.s. See Joel's quick intro to functional programming if you are unfamiliar with the concept of functional programming.

All, I am happy to announce that I am back in blogging on ExpressionFlow. I'm trying to cover more theoretical topics around visual programming and discuss new fresh approaches. I'd like to invite everyone to follow the blog and @expressionflow twitter account. url: http://expressionflow.com twitter: @expressionflow facebook: https://www.facebook.com/expressionflow Please let me know the kind of topics you'd like me to discuss. There's lots of cool topics on my mind already but I would love to hear from you, what would be something interesting for you all. Thanks, and happy Thanksgiving for everyone! Tomi

Recently I've been looking around at other dataflow languages, primarily because I'm curious to see how G's language design influences the way we think about dataflow. Last week I downloaded and installed Microsoft's Visual Programming Language, a dataflow language included as part of their Robotics Development Studio. On the surface VPL appears to be a direct competitor to Labview. If that concerns you, don't worry... imo VPL has a long ways to go before it can offer the simple workflow and overall ease of use as Labview. In fact, when Robotic Studio was first released MS did not publicly consider it a competitor to Labview. Still, it has interesting features that may (or may not) be useful in a Labview context. This post is not intended to be a criticism of Labview or question NI's design decisions surrounding the language and IDE. It's just pointing out a few of the differences and my reaction to them. The IDE The very first thing to notice is the MDI (multi-document interface -- docked windows) IDE. In my opinion Microsoft does a very good job creating developer-friendly IDEs. The VPL IDE, though sparse, has the look and feel many text language developers are used to. Although we've learned to accept it, Labview's window management can be a pain sometimes and it was refreshing to work in an environment where that wasn't a concern. The Basic Activities and Services palettes contain all the components I can use on the block diagram. The Project and Errors window are always visible, making it more convenient for me to use those features. The project window doesn't contain all the information I would expect it to and in fact some parts of my project can be difficult to get to. In particular, in this project I have a custom activity--roughly analagous to a LV sub vi--and the only way I've been able to get to that block diagram is through the error window. I can't say whether this is an oversight in the IDE design or me not fully understanding the programming model. In the diagram above I'm trying to add a string to an integer list, which is a type mismatch error. Selecting the List Functions error from the error list causes the corresponding error icon to throb, drawing the developer's attention to it. Does VPL's error highlighting provide better usability than LV's error highlighting? Not really, but having worked in LV's visually static environment for so long there was a certain amount of juvenile delight in seeing dynamic graphics on the block diagram. The Properties window shows the properties of the selected block diagram item. I'd love to have a similar feature in LV. LV's modal properties dialog box feels antiquated and clunky in comparison. To be fair, a sub vi has far more properties than any of the VPL nodes I used, so presenting all that information to the user is not a trivial challenge. The Services palette offers a search box, similar to LV's palette search, but extends it in an interesting and useful way. It is possible to save the search results in a custom palette group. For example, if I type in 'blob' the palette shows all the related services. Clicking on the '+' symbol creates a new grouping named 'blob,' making it very easy for me to locate commonly used palette items. I expect groups would be created and destroyed frequently during a development session. Also noteworthy is the blue information icons on the palette. Clicking on the icon opens the help associated help page in a browser. It seems insignificant, but it is more natural than LV's process of hovering over the sub vi and mousing over to the context help window to click the link. For reasons I'll explain later, in VPL visible pin labels are more important to readability than they are in LV. I like how MS has made them less obtrusive. The label is translucent, not transparent. Wires passing under a label are dimmed somewhat instead of completely obscured, preserving the visual connection while retaining readability. I've often wished for better transparency support in LV. VPL includes comment blocks, which are similar to free labels. Comment blocks have the added features of being collapsable and having scrollbars when they are needed. These are features I'd love to see ported to Labview. Oddly, comment blocks do not offer a word wrap option, something they would definitely benefit from. The IDE also offers something many LV users have lobbied for and equally many LV users have lobbied against: block diagram zoom. Insert religious war here. Debugging Running a program from the dev environment gives us some insight into what is going on under the hood with VPL. A dialog box opens telling me my project is running with a list of messages. As you can see from the image below, even simple programs have some pretty significant stuff behind them. If your program isn't behaving as expected, errors will show up here. In typical Microsoft fashion, there is an abundance of cryptic information to sift through. While perhaps intimidating for new users, I'm certain it would be very useful in the hands of experienced developers. I haven't decided if I like VPL's debugging features or not. It's very different from anything I've used in the past. For starters, the debug environment is presented in a browser window. Current Activity highlights the next step to execute in the block diagram and provides controls for single steps, running, and setting break points (not shown), but the block diagram is just an image; there's no interactivity with any of the elements. You cannot probe a wire to see what value was sent. VPL offers a "Log" service you need to add to the block diagram instead. One nice thing LV does that VPL does not is execution highlighting. In VPL's debugging view the execution jumps from node to node. The ommission makes it harder to follow the data flow--especially for LV developers--because VPL's concept of dataflow on the block diagram is very different from LV's interpretation. (More on this later.) In these ways VPL's debugging features feel very primitive compared to those available in LV. On the other hand, near the top of the debug window are links to the control panel. I haven't used VPL enough to understand how useful it is in a real application. In general I prefer too much information over not enough, and the control panel contains a lot of information. There are certainly times I've wanted more visibility into LV's inner workings to help troubleshoot a problem. I didn't even get to the parts I really wanted to talk about--activities, merge nodes, notifier pins, and the differences in data flow models. I'll post a followup covering those topics in the near future.

I have a multicolumn listbox where I would like a "right-click" to set the value of the MC listbox to the row that was right-clicked, then a shortcut menu will appear. Depending on the value of the MC listbox (i.e. row clicked) I determine what right-click menu options are available. To do this, I use the mouse down event, and if it's a right click, I set the MC listbox value to the row clicked. Then, the shortcut menu activation event is fired, and in there I use the current value of the MC listbox to enable/disable menu items. My question is this, can I always expect the mouse down event to occur first (it seems it does), or do I need to manage the order in which the events fire. I guess I could also handle all this logic in the mouse down case, inside my case structure, when checking which button was pressed. What I want to make sure I avoid is the shortcut menu activation firing first and having the wrong row selected in the MC listbox which may disable/enable the wrong menu items. Edit: After discussing w/ co-workers, I think the answer is yes, because the mouse-down is the event, the shortcut menu activation is the system response to that event. Please let me know if this is wrong.