Jump to content

Recommended Posts

Hello All, 

 

Long time reader, first time poster.  I have learned a lot from lavag, and really appreciate what you all do here.  

 

I am building an LVOOP architecture that sort of straddles the line between AMC and AF.  One of the most frustrating things I have run across (as with most AF type architectures) is debugging shared clones.  I've run into some behavior that I did not expect and wanted to see if anyone knew what was going on.  First some definitions:

  • Behavior A: Opening a Shared Clone Reentrant subVI from the block diagram of a running VI opens the original, "uncloned" VI, reserved for execution.
  • Behavior B: Opening a Shared Clone Reentrant subVI from the block diagram of a running VI opens the active, running clone VI, which is capable of being debugged.

I once thought that behavior A was how LabVIEW worked, however in developing this framework, I have found that some subVIs show behavior B.  Behavior A and B seem to correlate to dynamic and static dispatch methods respectively, but I can't make sense of why.  If I create a simple example without OOP (see attached), I get behavior A.

 

Has anyone ever seen this behavior, and if so, am I missing something really obvious?

 

Secondly, does anyone have any tricks or best practices for getting into active clones to debug?  My only idea at this point is to include some sort of notifier/queue/etc to active a Front Panel Open Method.

 

Thanks in advance!

 

Drew T.

CLA, CTA

Share this post


Link to post
Share on other sites

WOW, drjdpowell, it's not often I learn about such an amazingly useful feature, and I've been down some pretty deep rabbit holes in LV.  THANK YOU!  That View menu trick is going to be so helpful!!

 

As for the show front panel message, that is how I am opening the top level endpoint (actor/whatever), but when I would open it's DD subVIs (message router, message handler, ui, auxiliary, etc.), I would get their original copy, which is where your first trick comes in so handy.

 

The View menu trick will pretty much resolve my struggle here, but I am still curious about the behavior if anyone has any thoughts!

 

Thanks,

 

Drew

Share this post


Link to post
Share on other sites

"Shared Clone" reentrant subVIs are assigned to a callsite from the pool of free (not currently being run) clones *at the last minute*.  This means that generally if you go click on a callsite, LabVIEW can't possibly know which one will actually be run by the caller VI, so LabVIEW just opens the "master copy".

 

However, if that callsite DOES have an assigned clone because the clone is running exactly when you click on the callsite, then LabVIEW can open the right clone!  This can be very hard to do unless the subVI takes a long time to run or you are already debugging thanks to hitting pause or hitting a breakpoint or stepping.

  • Like 2

Share this post


Link to post
Share on other sites

Djed,

 

That's a good line of thinking I hadn't gone down yet.  Unfortunately, it doesn't fully explain my behavior.  True enough, in some cases where I experience Behavior A, the reentrant VIs are being called inside a loop, meaning they may or may not be running at the split second I click.  However, in several other cases, the VIs themselves contain a loop and are running continuously.  Any thoughts on how that detail may affect things?  Just in case it helps, it does seem to correlate (in this, but not all cases) to DD vs static dispatch.

 

Thanks,

 

Drew

Share this post


Link to post
Share on other sites

The exact details of when the exact clone is exactly "reserved" do vary for many reasons.  It's not necessarily deduce-able from the diagram since the compiler tries to optimize things.  The caller VI might grab a clone once and hold onto it for a while or it might grab it exactly as it needs it.  And yes, SD versus DynD also play into this.  Dynamic Dispatch I believe is always grabbed at the last minute because we have to deduce the right VI to call and it might vary between loop iterations, etc.

  • Like 1

Share this post


Link to post
Share on other sites

I've seen behavior A almost explicitly with VIs set to "shared clone reentrant execution", and behavior B almost explicitly with VIs set to "preallocated clone reentrant execution" (nomenclature from 2013).  I had assumed that this setting was what caused each of these behaviors.

Share this post


Link to post
Share on other sites

Djed,

 

Thanks for taking the time to reply.  I agree with what you and Chris said, and at this point, I think I'll accept that I can't know everything, and close this discussion out.

 

Thanks!

 

Drew

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Similar Content

    • By Ryan Vallieu
      I have seemingly found an issue with the shipping example code for Nested Malleable VIs.  Another user has verified that he saw the same behavior in 2019.
       
      I am working through the examples and the presentation from NIWeek 2019.  In running the Lesson 2b code (C:\Program Files (x86)\National Instruments\LabVIEW 2019\examples\Malleable VIs\Nested Malleable VIs) I found the Equals.vi in the class was not being leveraged and the search failed.  When I went to my LabVIEW 2018 machine and ran the Lesson 2b.vi the code worked to find the element by correctly leveraging the in-class Equals.vi.
      One difference I see is that in the 2018 example the Equal.vi is in the example folder with the code, and in 2019 the Equal.vi has been moved to VI.lib - otherwise the code looks to be the same.  The Equals.vi code looks identical, and the calling VIM look identical.  I posted on the LabVIEW NI.com forum here: 
      https://forums.ni.com/t5/LabVIEW/LabVIEW-2019-Malleable-VIs-Shipping-Examples-Lesson-2b-Nested/m-p/3966044/highlight/false#M1129678
       
      I am trying to determine what may have broken or changed between the implementation in 2018 and 2019, visually the code looks the same.
    • By Voklaif
      Hello all,
      I am programming with LabVIEW for around 2 years and was recently stumbled upon LVOOP.
      I am required to write a communication protocol to work with a micro-controller, which later will be also used for ATP and debug purposes.
      I want to build the program "correctly" from the beginning so it will be maintainable and flexible to additions and changes.
      My natural way of building a program would have been a queued state machine, with several loops, each loop is in charge of a different module (one for GUI obviously), but as I stated in the beginning, I want to use LVOOP.
      Does anyone have a LVOOP project I can use as reference? I've searched online and found some nice examples, but they are small and teach you the basic stuff.
      For me it's important to see the how to use the project tree wisely, where to place the classes, see the managing loop and to learn as much as possible before I create one of my own.
      Thanks in advance,
      Voklaif
    • By GregFreeman
      I have an array of classes, let's call the object TestPass, of size 1 (but it is an array because it can scale out to multiple test passes). In this class, there is one other nested class which is not too complex, then various numeric and string fields to hold some private data. There is also an array of clusters. In this cluster there is a string, two XY pair clusters, and an integer. Not very confusing.
      This array of clusters gets fairly large, however, upwards of 80-100k elements. What I am finding is when I index the array of pass classes it is crazy slow. On the order of 30 ms. Doesn't seem like much, but we are indexing the array in our method to "Get Current Pass" which is used in various places throughout our code. This is adding potentially hours to our test time over the 80k devices we are testing. 
      So, I started digging. When I flatten the class to a string and get the length, it's 3 mb. But, when I run the function with the profiler is is allocating close to 20 mb of memory!
      My gut feel was that the string is causing the issues. So I removed the string from the cluster and the index time went to 0 ms. 
      Luckily we can normalize a bit and pull the strings out of the cluster since a lot of them are duplicates. But it makes our data model a bit uglier. 
      Has anyone seen these kind of performance issues before? I saw them in 2013 and 2017.
    • By TimVargo
      View File LabVIEW Task Manager (LVTM)
      LabVIEW Task Manager v1.10.0 (for LV2013+)
      This code is Open-Source, and free of charge
      Authors: Ravi Beniwal, Tim Vargo
      LabVIEW Versions Supported:
      LabVIEW Versions Tested on:
      Dependencies:
      GPower Error & Warning = 1.2.0.14 lava_lib_tree_control_api >= 1.0.1-1 NI SmartBalloon = 2.0.0.2 OpenG Application Control Library >= 4.1.0.7 OpenG Comparison Library >= 4.0.0.3 OpenG Array Library >= 4.1.1.14 OpenG Error Library >= 4.2.0.23 OpenG File Library >= 4.0.1.22 OpenG LabVIEW Data Library >= 4.2.0.21 OpenG String Library >= 4.1.0.12 LAVA Palette >= 1.0.0.1 Description:
      LabVIEW Task Manager is a debugging tool for use during LabVIEW code development. An expandable/collapsible tree diagram displays detailed information (both static and dynamic) on all VIs in memory, belonging to a selected project/target. It allows for interacting with single or multiple selected VIs at a time, and includes the following major features:
      Selection of project/target Lists all VIs in memory, grouped by class/library or disk folder, or a flat list Searches for and enumerates clones in memory DropIn VI for including dynamically referenced clones (Clone Beacon) 'Refresh Now' (F5) re-reads all VIs in memory and adds new ones to the tree Displays VI name, owning class/library, state, path, data size & code size Displays VI FP Behavior, Reentrant?, Reentrancy Type, Paused? & Highlight? Group by Class/Library or Folder, or display a Flat List Sort by any column, ascending or descending Filter out item types vi, ctl, and vit/ctt Filter out vi.lib and global VIs Filter out items from being displayed, per folder paths. Tracking of, and ability to toggle, execution highlighting on multiple selected VIs Tracking of paused VIs with ability to Pause/Resume/TogglePause multiple selected VIs DropIn VI for pausing only while debugging If a clone initiates a pause, a different pause symbol is used for all clones of that same reentrant original VI Select multiple VIs and open or close their FPs or BDs Double Click a VI from the tree to bring the BD (first choice) or FP to front, if already open Select multiple top-level VIs and Abort them Remotely close any VI's Front Panel Installation and Instructions: 
      Install this tool by using the VI Package Manager to install its associated package file (.vip). Installation requires VIPM 2014 or higher, which is available for free from jki.net (http://jki.net/vipm). Invoke the LVTM tool from your dev environment menu: Tools > LAVA > LabVIEW Task Manager Known Issues:
      Cannot abort SubVIs launched from remote VI Server or local Asynch Call By Ref Submitter TimVargo Submitted 07/01/2014 Category LabVIEW IDE LabVIEW Version    
    • By TimVargo
      LabVIEW Task Manager v1.10.0 (for LV2013+)
      This code is Open-Source, and free of charge
      Authors: Ravi Beniwal, Tim Vargo
      LabVIEW Versions Supported:
      LabVIEW Versions Tested on:
      Dependencies:
      GPower Error & Warning = 1.2.0.14 lava_lib_tree_control_api >= 1.0.1-1 NI SmartBalloon = 2.0.0.2 OpenG Application Control Library >= 4.1.0.7 OpenG Comparison Library >= 4.0.0.3 OpenG Array Library >= 4.1.1.14 OpenG Error Library >= 4.2.0.23 OpenG File Library >= 4.0.1.22 OpenG LabVIEW Data Library >= 4.2.0.21 OpenG String Library >= 4.1.0.12 LAVA Palette >= 1.0.0.1 Description:
      LabVIEW Task Manager is a debugging tool for use during LabVIEW code development. An expandable/collapsible tree diagram displays detailed information (both static and dynamic) on all VIs in memory, belonging to a selected project/target. It allows for interacting with single or multiple selected VIs at a time, and includes the following major features:
      Selection of project/target Lists all VIs in memory, grouped by class/library or disk folder, or a flat list Searches for and enumerates clones in memory DropIn VI for including dynamically referenced clones (Clone Beacon) 'Refresh Now' (F5) re-reads all VIs in memory and adds new ones to the tree Displays VI name, owning class/library, state, path, data size & code size Displays VI FP Behavior, Reentrant?, Reentrancy Type, Paused? & Highlight? Group by Class/Library or Folder, or display a Flat List Sort by any column, ascending or descending Filter out item types vi, ctl, and vit/ctt Filter out vi.lib and global VIs Filter out items from being displayed, per folder paths. Tracking of, and ability to toggle, execution highlighting on multiple selected VIs Tracking of paused VIs with ability to Pause/Resume/TogglePause multiple selected VIs DropIn VI for pausing only while debugging If a clone initiates a pause, a different pause symbol is used for all clones of that same reentrant original VI Select multiple VIs and open or close their FPs or BDs Double Click a VI from the tree to bring the BD (first choice) or FP to front, if already open Select multiple top-level VIs and Abort them Remotely close any VI's Front Panel Installation and instructions:
      Known Issues:
      Cannot abort SubVIs launched from remote VI Server or local Asynch Call By Ref
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.