Jump to content

Broken VIM "Log: Missing Callee"


jacobson

Recommended Posts

I am getting this strange error whenever I try to drop a .vim into a VI that is saved. If the VI is not saved, everything seems to work but as soon as I save it and try to drop in a .vim, I receive this edit time error.

missing callee.png

This happens to any .vim file, even blank ones that I have just created. If I double click on the error then it will highlight a specific object that I can delete but the object is otherwise invisible and unclickable. This started happening right after I tried to add a VIM through scripting. I can actually still add a VIM through scripting but it has some pretty interesting context help.

wut.png

So I guess the question of the post is what the heck did I do and how can I get LabVIEW to start behaving again.

Link to post

Clearing the cache didn't seem to do it.

After looking into this more, the error is being thrown by the VIM xnode but I'm still not sure under what conditions it throws that error. I also think the strange context help message is just what shows up if the context help of the VIM you drop is blank.

Link to post
  • 4 weeks later...

To follow up on this thread, the error above only seems to appear in LabVIEW 2016 if the .vim is dragged onto a saved block diagram from windows explorer and has been reproducible on multiple computers. You are still able to use VI macros either by scripting them onto the block diagram or dropping one from the palette (add it to user.lib as JeffK originally suggested).

This behavior is not the same as it was in LabVIEW 2015 SP1 or earlier which was confusing for me.

Link to post
20 hours ago, Steen Schmidt said:

I think I made that error go away by adding "ExternalNodesEnabled=True" to the LabVIEW.ini file, even though that shouldn't be necessary any longer from LabVIEW 2016?

Nope, didn't help after all. I get a huge number of Log: Missing Callee in 2016.

In fact, 2016 seems quite unstable, or perhaps it's just because of VIMs. I'll try porting my code back to 2015, even though that means pulling out my Type Enabled Structures :-/

Link to post

Just to add to the description of the problem, it does work ok if going through the right-click menu and Selecting a VI(M) - i.e. not on the palette.

Hope it can be fixed as the possibility of using Type Enabled Structures in VIMs is extremely appealing! 

Link to post

Dragging a vim onto a diagram from windows explorer goes through a different code path which is apparently not working so I would avoid doing that for now.  I believe everything works when dropping a vim from a palette or selecting it from the palette "Select a VI..." item.  In the latter case you will have to Enable "All Documents" in the dialog box.

Link to post

The "Log: Missing Callee" error happens every time you drag a VIM onto a saved VI's BD. As long as the caller isn't saved, you can drag VIMs onto its BD all you want. That's the difference as far as I can tell, and it has been so at least back from LV 2012 (didn't feel like trying further back).

It seems like a reference mistake in the VIM builder XNode, but I can't edit that, so I can't attempt to fix it. I know of someone who can though ;-)

Edited by Steen Schmidt
Link to post

If I'm feeling ambitious I might try writing a kludge of my own. The error is caused by the input to the update state ability being different based on whether the VI you are dropping the macro into is saved or not if someone wants to try fixing it for real.

Link to post

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 hooovahh
      Here is the Hooovahh Array VIMs.  This initial release contains VIMs for manipulating array data, which are intended to replace OpenG functionality, but with the added benefit of data type propagation, and increased performance using newer array manipulation techniques.  In later versions other Array manipulation functions were added moving all the OpenG stuff to their own palette. 
      Version 2.0 changed the suffix naming standard.  Updating may mean replacing calls to the new versions since the name on disk has changed.  This was for consistency and I'm sorry for breaking compatibility.  The added type defs in 2.0 may break compatibility too but these help avoid code breaking bugs since VIMs allowed any data type previously.
      Most of the OpenG functions are unchanged, but a few use the newer conditional and concatenating tunnels.  And a few functions have added performance based on other inputs.  For instance the Delete Array Elements can operate in a more efficient way if the input indexes are already sorted.  The Filter 1D array can also be more efficient if the input is known to not contain any duplicates.
      Because these packages contain VIMs, they require LabVIEW 2017 or newer.  Having these functions be VIMs mean all functions work with various array data types.  Included functions are:
      Conditional Auto-Indexing Tunnel Delete Elements from (1D or 2D) Array Filter 1D Array Index (1D or 2D) Array, Scalar, Row, Column Remove Duplicates from 1D Array Reorder (1D or 2D) Array Reverse 1D Array Slice 1D Array Sort (1D or 2D) Array Convert 1D to 2D Convert 2D to 1D Find Subarray Force Array Min/Max Size Foreign Key Sort
    • By hooovahh
      View File Hooovahh Array VIMs
      Here is the Hooovahh Array VIMs.  This initial release contains 14 VIMs for manipulating array data, which are intended to replace OpenG functionality, but with the added benefit of data type propagation, and increased performance using newer array manipulation techniques.  In later versions other Array manipulation functions were added moving all the OpenG stuff to their own palette.
      Most of the OpenG functions are unchanged, but a few use the newer conditional and concatenating tunnels.  And a few functions have added performance based on other inputs.  For instance the Delete Array Elements can operate in a more efficient way if the input indexes are already sorted.  The Filter 1D array can also be more efficient if the input is known to not contain any duplicates.
      Because these packages contain VIMs, they require LabVIEW 2017 or newer.  Having these functions be VIMs mean all functions work with various array data types.  Included functions are:
      Conditional Auto-Indexing Tunnel Delete Elements from (1D or 2D) Array Filter 1D Array Index (1D or 2D) Array, Scalar, Row, Column Remove Duplicates from 1D Array Reorder (1D or 2D) Array Reverse 1D Array Slice 1D Array Sort (1D or 2D) Array Convert 1D to 2D Convert 2D to 1D Find Subarray Force Array Min/Max Size Foreign Key Sort Submitter hooovahh Submitted 10/11/2017 Category *Uncertified* LabVIEW Version 2018 License Type BSD (Most common)  
    • By X___
      For those who have been playing with malleable VIs, the Type Specialization Structure has probably become a common sight and much abused tool.
      The basic use of it is that if the action it performs is meaningless given one of the inputs, the included code will break and the next case will be tried.
      This is great, but sometimes, it can be difficult to think of all possible variants of an action, and in particular, if the action needs to be different for two or more types, but two or more types are compatible with different codes, how to make sure which code will be executed with what type?
      Enters the Types Must Match function:

      I found this little gem in... Hidden Gems, within an odd-looking VI which I felt compelled to check out, Debug Write.vim

      Open its diagram and light will shine, opening grandiose vistas and parallel universes remaining to be explored.
      Of course, as the comment on the diagram says:
      "This structure and the type-testing primitive functions it contains are not public LabVIEW features. They are experimental and should not be edited, copied, or used in other VIs without conducting extensive testing. See Context Help for details."
      Here is the context help for Types Must Match:

       
      My apologies if this all well-known among expert users, but I couldn't find it mentioned otherwise on the site...
    • By bbean
      After reading this LabVIEW Idea exchange request:
      http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Provide-a-better-way-to-implement-a-polymorphic-VI/idi-p/920487
       
      I was inspired to create VI macro(s) to attempt to address the problem mentioned in the request.  Attached is my first attempt and I'm looking for feedback since I know people here have strong opinions.   The benefit of this method is that a single vim (or 2 could replace a polymorphic VI with over 48 separate VIs....unless I'm missing something.  I know that VI macros are not officially supported by NI, but that hasn't stopped us from using unsupported features before.  Some people have probably already done something like this, but I couldn't find an example.
       
      To use the files, unzip them and copy them all to your \LabVIEW (version)\user.lib\macros\ directory.  
      Create the directory if it does not exist.  For example: C:\Program Files (x86)\National Instruments\LabVIEW 2014\user.lib\macros\   And as described in the wait-ms-with pass through post below, modify your LabVIEW.ini file to have the following     ExternalNodesEnabled=True and Optionally     XNodeWizardMode=True   http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Wait-ms-with-error-pass-through/idc-p/3178218#M31820
       
      Open the Example Changed.vi and review.
      Changed Example.zip
    • By ShaunR
      This is an experimental demo to investigate VIMs (vi macros). It was a bit of fun to see if VIMs could be used to encapsulate events in LabVIEW which was a bugbear of mine for quite some time. You can see the entire thread here. VIMs are a NI experimental technology similar to Xnodes but less mature.
       
      The purpose of this release is to clarify the previously unstated licence since other forum topics are building on the original demo so they need a permissive licence (MIT). This release serves as an unambiguous statement to that effect. There are a few differences from the original which I have decided to call version 0.1 but they are minor.
       
      Note:
      This may or may not work for you out of the box. If it doesn't then please do not post. The purpose is to clarify the licence for others to build upon; not to provide a working example. The VIM technology is itself  experimental and unsupported by NI so most issues you will encounter will be due to this and It is unlikely there will be another version posted here.
×
×
  • Create New...

Important Information

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