Jump to content
jgcode

Get 'Actual Data Type' of LVOOP Object

Recommended Posts

[LabVIEW 2011]

Howdy

If you probe a LVOOP Object it tells you the Actual Data Type e.g. the wire maybe that of a parent, but it will display the child's name if the child ran on that wire.

Is there a way to get the Actual Data Type of an LVOOP Object at edit time from a terminal input reference / wire reference (assuming the VI has been run and the wire has been 'executed' on).

There is a datatype property for the terminal but it just returns the parent class in the above use case.

I managed to locate this control which is part of the probe (<resource>\dialog\NI.LVClass.Probe.NameStr.ctl) hoping to find the complete probe and see the code - still searching tho:

post-10325-0-28846600-1326461314.png

Cheers!

-JG

Share this post


Link to post
Share on other sites

Use the Flatten To String primitive and take the name off the front. The details of doing this are posted somewhere on LAVA... I forget where. Try searching the OO category for "flat format".

  • Like 1

Share this post


Link to post
Share on other sites

Use the Flatten To String primitive and take the name off the front. The details of doing this are posted somewhere on LAVA... I forget where. Try searching the OO category for "flat format".

I searched and found this prior conversation.

Thanks for your replies, but I am unsure how to use this to solve the OP:

... at edit time from a terminal input reference / wire reference

I.e. How do I tell what Class data is on the wire with an arrow...

post-10325-0-63053600-1326636910.png

...(assuming that it is run at least once and Retain Wire Values in ON) using a terminal (or wire) reference for that node?

post-10325-0-46503500-1326636828.png

Can you please provide more detail.

Cheers

-JG

Share this post


Link to post
Share on other sites

For that you need the actual value on the wire, which I'm pretty sure is not exposed through VI server (probably since before the retain values option was introduced this was considered to be dangerous, because it meant LV could not safely reuse buffers and after the option was added no one bothered to add such a property).

Share this post


Link to post
Share on other sites

Thanks for the VI AQ, but I am unsure how to use it correctly in the use case I presented.

If I pass in the Terminal's Data Type it always returns the Parent (even if a Child has run on the wire).

Here are the scripting properties I am browsing through which are available for terminal (left) to the wire (middle).

As Yair has mentioned - can it be done? What should I be using?

post-10325-0-48169200-1326697006.png

Cheers

-JG

Share this post


Link to post
Share on other sites

AQ, I think the problem is that you're misunderstanding what Jon wants - he wants to find the specific class on a wire in another VI, since this is supposed to be an edit-time scripting tool. For that, he needs the actual value in the wire.

  • Like 1

Share this post


Link to post
Share on other sites

Thanks for your replies, but I am unsure how to use this to solve the OP:

Sorry, I had mistakenly thought you were making custom probes, rather than wanting scripting access to the data retained on a wire.

I’ve never tried scripting, but just a thought: can one use scripting to connect a probe to the wire? I see from your last image that there is a probe reference that you may be able to set. If so, you could connect a custom probe and have the probe send (via a queue or whatever) the retained object on the wire back to the VI doing the scripting. Then you could use AQs code on it.

— James

Edited by drjdpowell
  • Like 2

Share this post


Link to post
Share on other sites
If so, you could connect a custom probe and have the probe send (via a queue or whatever) the retained object on the wire back to the VI doing the scripting.

Well what do you know... :)

I had looked at probes quickly before but with no luck - so I just went back in, found some nodes, converted AQ's VI to conform to a probe, tried it out and have my code 'working'.

Need to neat up the process, but I think I definitely have the tools to do it now.

Thanks everyone!

-JG

Share this post


Link to post
Share on other sites

JG,

Can you add a probe to a running VI, also? What about a clone VI? (I have a use case that would be valuable, and perhaps I’ll dive in to scripting.)

— James

Share this post


Link to post
Share on other sites

JG,

Can you add a probe to a running VI, also? What about a clone VI? (I have a use case that would be valuable, and perhaps I’ll dive in to scripting.)

— James

Don't know - I am 'swimming' myself at the moment with this probe thing.

My use case is edit time - that's what I am testing at the moment.

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 bbean
      I put together a simple xnode to relabel event registration reference wires that feed into dynamic events of event structures.  With the increasing use of event based messaging systems, I found myself manually changing the name of event registration references to clarify the event name when multiple event registration references were used in an object. I did this by manually creating a cluster constant on the build cluster before the dynamic registration terminal on the event structure and renaming each registration reference.  Being a lazy programmer, this seemed tedious after a few times so I decided to attempt to create an Xnode to accomplish the same thing faster.   This video shows the "problem" and the potential solution using the xnode: 
      Re-Label Xnode - Event Registration
      Here's another example showing another use case with ShaunR's VIM HAL Demo code:
      Re-Label Use Case ShaunR HAL Demo
      This may have been done before or there may be an easier way to do this, but I wanted to throw it out here to see if there's any interest and to see if people will try it out and give feedback.  I've found it works best using quick drop for initial use (highlight wire, CTRL-Space,type re-label, CTRL-I, type new name in dialog) and for replacing or renaming an existing instance on the diagram (highlight existing xnode, CTRL-Space, type re-label, CTRL-P, type revised name in dialog).  You can also use directly from the palette, but I found much faster from quick drop and also seen a couple crashes replacing through the pallete.  
      The Double Click ability is also a work in progress.  Its purpose is to allow you to quickly rename the relabel with the same dialog box, but when it executes it breaks the wire on the output connection.  You can still re-wire it to the event structure, but you will have to open the Event Structure Edit Events menu to get the event to "Re-link".  Something I'm trying to avoid.
      The Xnode generated code is simply a pass through wire with the output terminal renamed to the label of your choice.  This seems to update attached event structures.

      - B
      sobosoft_llc_lib_diagram_tools-1.0.4.1.vip
    • By bI0ndin
      Hi everybody,
      While I was having some time to develop new scripting stuff i wondered "would it be possible to add somme scripting stuff in the VI toolbar ? " (the one with run, run-continuously, abort, police stuff and so on). My point is to add kind of a combobox that populate with every events in the current vi for a control when clicking on it. And of course show the effective event and make it blink when selecting it in the combobox.
      The scripting part is almost done but i now come to the real problem : 
      "How can I add this piece of code in the VI toolbar ?"
      I know i can create either a Quidrop Plugin or a shortcut menu plugin but they don't fit the way i wan't to use this plugin.
      I asked some NI guy that told me the only options where the one above but I can't imagine that LabVIEW is not in some way developed around a "plugin architecture" so if any of you as plunge deep into LabVIEW's files and know where and how to achieve this goal it would be really nice
      Thank's everybody and I hope my question was clear.
    • By Tripmeister
      Hey guys,
       
      I'm trying to do some scripting on a Realtime-VI wich uses the FPGA Interface "Read/Write Control". I open a Reference to a VI containing a Read/Write Control, and when scrolling through the BD-Objects I find it with the class-name "nirviReadWriteControl".
      I used the "to more specific class"-VI to check wich class i can cast it to, and i tracked it down to be child of the GObject->Node Class. But i can't cast it to any of the childs offered in the class specifier constant.
      I also found out, that the "nirviReadWriteControl" is a xnode.
      I have never worked with those, is there a way to access theyr methods (I think they're called "abilities" for xnodes)?
       
      The goal of the application is to make the Read/Write Control display all available FPGA FP-Elements, and connect Controls/Indicators to them.
       
      There is the same Problem with the "Open FPGA Reference"-Node (Classname "nirviOpenFPGA").
       
      I really hope somebody dealed with the xnodes a bit and can help me programmatically controlling them!
       
      Best,
      Trip
    • 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 pylb
      Hi,
      i am trying to automate building a code, deploying it on an RT target and rebooting the target. I've got everything working but I do have a dialog box saying that the connection to the target was lost popping up.
      I would like to disable this notification during my process and re-enable it after.
      Anyone has an idea how to do this?
       
      I tried the "suppress Project Dlgs" invoke node of the target but it does not work.
      I changed the target Tags to prevent the "periodic check of the responsiveness of teh RT protocol" but that did not work either.
       
      I found this invoke node for the project that us called SuppressChangeNotification. I am not sure if that would do it since it could just be change of the content of the project not changes in the state of a target in the project. But the problem is, since it is part of the SuperSecretPrivateSpecialStuff the inputs are not documented and it needs ItemIDs of the notification that will be suppressed.
       
      Anyone know what those IDs are? or has a better way to suppress that diakog box?
      thanks,
      Pierre-Yves
×
×
  • Create New...

Important Information

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