bbean

 Then in your code for that VI you could read what the type is, and do specific things if needed.  I honestly think we could make something like this today, just given enough time.

In the spirit of dreaming, I think what would also add to this idea would be a new LabVIEW primitive called TypeDetectDisableCase Structure that would work like a case selector for datatypes, but would automagically (like an Xnode) disable the irrelevant case and enable the relevant type case for the inputs.  I think having all the code in one VI (even for different types) is key so you don't end up with a Xnode solution that circles back to the polymorphic situation where you have a bunch of template subVIs to manage.

 Well if you put on your front panel of a VI a control named "Generic LabVIEW:Adapt To Type States", have the data type be a 2D array where columns 0 is control labels, and column 1 defines what that control should be.  I believe FT means fixed, and unspecified are adaptive (which is why all inputs are adaptive by default).  Of course when I go to use this it doesn't do some other things properly, like icon, and terminals aren't right so this isn't very useful yet, but I was just so excited I had to share, even if it doesn't do anything yet.  Of course even if you do get some inputs adaptive and some fixed, you still have the issue of limiting some inputs to say scalar, or say 1D array but no other size.  That again is where the flexibility of XNodes is needed at the moment.

Interesting.  Good find.  If you look at the front panel enumerator for Terminal Behavior there is another option "Depends" and also a "dependency chain array" control and "index of dependency" control below it.  Any speculation as to what that option would be for.?

VI Macros (VIM) supports "XMacro.xnode".

Are you suggesting one could copy/modify that Xnode to extend its capabilities to their liking?

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.  

Open the Example Changed.vi and review.

Changed Example.zip

The fluid layer will continously be monitored and once a bubble of a certain size occurs, labview should notice.

Just a quick warning....based on the image you attached you have some parallax going on so the measurements of particle size will become more inaccurate (appear larger than actual) as you move away from the center of the image.  You can see it in the ghosting of the droplets in the upper-left corner of the image.   

Depending on how accurate you need to be, you may have to go to a telecentric lens or move your camera farther away so that the majority of the image is in the center of the FOV.

Does anyone have any experience good or bad with the PicoLog 1000 and LabVIEW?

https://www.picotech.com/data-logger/picolog-1000-series/multi-channel-daq

I'm trying to open a remote panel in Internet Explorer from a cRIO-9014 running Labview 2014.  Whenever I try to connect, the panel begins to open then IE crashes (see attached image).  I have tried using Firefox and I get a message "plugin needed" but I have the latest plugin installed.

 

Any ideas how to get either browser to work for remote panels?  I'm at the end of my rope with this one. 

Also - I have tried from 2 different computers on the network with the same results so I assume it is a problem with my real time web server configuration?

I have been having problems with Remote Front Panels not working anymore with IE as of the lastest MS security update.  See here  https://lavag.org/topic/19216-labview-ie-plugin-blocked-following-latest-win-7-update/

After a recent Windows Automatic Update (possibly KB3092627) , Internet Explorer (v11.0.9600.17959) no longer shows LabVIEW webserver pages using the LV2014ActiveXControl.dll. Internet Explorer appears to block the webpage even though settings for the plugin have been "approved for all websites" in the more information section. Since the Chrome plugin is no longer supported on up to date Chrome versions, there is currently no working options to monitor the webserver on up to date IE and Windows 7 machines. Looking at "Manage Add-Ons" item "toolbars and extensions" in IEv11 shows the LabVIEW 2014 control class as "(Not verified) National Instruments" other versions are shown as verified. Not sure if this is a clue to the problem.

NI is still working on the issue, but based on my discussions it appears support for Remote Front Panels is bleeding a slow death.  Here's how I would summarize the situation to date if you have the latest and greatest software versions and OS (Win7) updates:

Internet Explorer - Does not work, reason unknown (may be an ActiveX signing (Not Verified) or registration issue), being investigated (slowly) by NI

Chrome - DOES NOT WORK, npapi plugin no longer supported by Chrome and will not load in the latest version of Chrome

Firefox - Does not work by default, requires changing plugin settings to work.

Opera - Works currently, but plugin will not be supported in the future according to Opera

Regarding your situation with Firefox, I think you should be able to get it to work.  My colleague was able to get Firefox working by changing some plug in settings.  I am having trouble finding a link to the steps he took.  This page looks old but may work:

http://digital.ni.com/public.nsf/allkb/CF91AE26198992A686257B79006959C0

Opera browser should work out of the box

With your multiple axis motion controller; I disagree. In the service model you would just have a Motion Controller Service and send it X, Y and Z commands or more likely "TABLE>MOVE>PRESET1" or similar.

There should be no reason why you cannot have multiple versions of the same type unless I'm missing something.

Think of the scenario where you were a manufacturer who made single axis motion controllers and sold them to LabVIEW developers.  You want to create a single axis "service" so the user can just plop down the VI as many times as he has axis (SP?) and you have no idea how many axis are in his system. could be 1 could be 100

I mocked up a crappy example in the project file

After going through the exercise, I think you may be right even though it was unintentional   .  You just have to add an extra item to the event cluster contents that describes which axis sent the message.  But the reason I went down the path of trying to have a variable name for the SREvent was so that there could be separate unique events / event handlers in the caller VI to handle each axis separately.  But looking at the approach I took in the code attached, I think its cleaner and less work.

VIX Event w Motion 2014.zip

 Glad you are finding some of my code useful, but it incorrectly identifies what the code is a part of and where it comes from.

Should be fixed in this one.  Sorry about that.

VIX Event 2014.zip

Ok.  I updated the code as follows

• renamed the project to VIX Event to avoid confusion since this version doesn't use VI Macros but rather the Xnode.
• Added the TCPIP Telemetry Service and Client

• Updated the SREventXnode Help to show help and also the terminal name in the help indicates what the event created is named 
• Modfied the SREventXnode Image so it updates with datatype 
• Fixed some bugs in the SREventXnode code

I tried to downsave to 2012 but had some problems converting and errors when I ran the code.  The Xnodes needed to be manually updated and for some reason the in place element structures threw an error saying their reference was invalid in user event cases associated with the Xnode.  This might have to do with UpdateState2 ability in the Xnode which I'll have to look into.

Also, I think I want to add back in the variable "name" terminal to the top left of the SREventXnode as the way to name the lookup SEQ.  Automatically generating the SEQ name from the data passed in limits the ability to have multiple "services" of the same type on a diagram.  For instances if you had multiple motion controller axis you would want to have three of the same VI services on the diagram and pass in a name to the service and its VIX events.

The other weird thing that happens when you update the name of an input to Xnode is that when its finished generating the code, a mouse click is generated on the diagram and a selection box appears.  Don't know why this is happening.

VIX Event Test 2014.zip

Are you thinking about putting the xnode in the CR?

Sure, just don't have time now.  It needs a few more ability VIs to make it robust and a lot more testing but I don't see why not.

This is a continuation of conversation from here https://lavag.org/topic/19163-vi-macros/?p=115771

So I decided to update ShaunR's VIM Event Demo with Xnodes.  Its still rough around the edges, but I think it cleans up the diagram pretty well and adds some benefits to displaying relevant Event names in the Event Structures.  For now I got totally rid of the "name in" input on the event / event register Xnode so you have to name all the constants or controls that go into the Xnode or it won't work.  I could put the name in back in and make it so it would override, but I don't have time right now as I'm preparing for more important things...vacation.

Take a look and tell me what you think.  Hopefully I didnt leave out any VIs.  Many thanks to hooovahh as I used his Variant Write repository Xnode as a starting point and have learned a bunch of stuff from his Xnodes.

Xnode Event 2014.zip

One other comment after looking at the VIs a bit more.  Why do use different conventions for identifying the recipient/sender for MSG Get (the caller VI's name or name override) and MSG Send (parsed out of the Msg input string)?  This is confusing.  Why not just do the Msg Send the same as Msg Get (using the caller VI name)?

• I would normally put both in a sub VI (look inside the get VI) so that get refnum and Generate event is a single VI, drop in replacement, for the Generate primitive. As I said before, The "Name" is preventing me from doing that and I'm still umming and arring about it because I don't like that it is not a single VI. It annoys me enough that I keep the "Name" unbundle even though I could make it a separate terminal on the "type VI" to remove it, It keeps me thinking about how to get rid of it.as it is a blight in all VIs I have to work on

I have an idea regarding the "Name" issue.  Would an Xnode be a better solution instead of a .vim file?  I think you could use the AdaptToInputs and GetTerms3 functions to figure out the "Name" of the data input (at development time only of course) when it was wired to a variant data terminal. Then in GenerateCode wire up a static name to the SEQ input of your template VI.   Not sure if its possible, but you may also be able to dynamically (in dev env again) rename the "Data" input terminal in GetTerms3 to have the same name discovered during AdaptToInputs... potentially also fixing the generic "Data" Event in all event structures to something more meaningful.

Attached is a demo using the VIM events. It works pretty well, when it works, but the VIM technology is far from production ready as we were warned..

Thanks for the example of VIM events and the hard work that went into that example.  I noticed the VIM Event Test.vi ran a little choppy on the first run, hesitating every now and then.  After stopping and restarting it seemed to be fine.  Wonder what's happening here.

Attached are recompiled versions for 2012 / 2014 to save others the pain of manually re-linking the .vim file.  Do .vim files work more reliably if they are placed in the user.lib/macros/ ? 

Just a quick question....In your "subsytem" VIs (File and Sound) is there a reason for putting the srevent.vim file inside the while loop?  could it be outside the while loop to prevent unnecessary calls to the subvi to just return the reference? Or is it necessary to be in the while loop for some reason?

Edit - Updated 2014 zip file to have relinked Main.vi

VIM MSG Example 2012.zip

VIM MSG Example 2014 - Rev1.zip

Played for a few hours with vim and event generation.

I wanted to create universal vi for creating and adding UE. It seems that we can create one vi for registering and sending UE data, but registering more than one UE will require xnode

I added one flag to decide when to register and when to generate.

vim needs to be extracted because I couldn't attach it.

Coffee hasn't kicked in yet and I feel a little slow this AM.  Can you explain:

• the use of the queue primitives and what they are for in the .vim? 
• why register flag doesn't get passed to the "created new" True case and wrap around the Reg Events Primitive?

And is the jist of the naming issue:

 That being said not being able to pass wireless data into our out of subVIs, or even structures is pretty limiting.  Thanks for sharing.

Still waiting on this front.  LabVIEW needs to move to 3d diagrams like CAD programs.

Sorry but I just can't figure out what the picture represents on the 'receiver' side 

https://en.wikipedia.org/wiki/Dalek

http://www.thedoctorwhosite.co.uk/dalek/

Why, for example does the "Return Settings" need file terminals? How could we tell the wizard to not wire and create those terminals for that enum?

"Return Settings" doesn't need file terminals.  If you look at the code I added to delete terminals, I use a very rudimentary approach where I check to see if the case selector tunnels are wired to anything in the case structure and delete the controls with the same name as the tunnels that are unwired.  Its crude and probably not very robust at this point.  

I agree with you concerns about code bloat which is why I dislike polymorphic VIs.  Would there be a generic way to do this with an Xnode FGV wrapper that goes through similar operations as hoovahs script, but self creates its inputs and outputs based on the case (enum) you selected from the Xnodes menu item?  Would it be worth it?  Or do you just transfer the complexity to the scripting environment where the potential for mistakes (and code errors) is more likely and less transparent?

I added a delete feature to your latest version that will delete the controls for each case if they are not wired inside the case structure of the FGV.  Its not perfect and I had to rename the initialization constant in the example FGV so it doesn't delete the input terminal (the constant had the same name).  Anyway thought I'd throw it out there.

Generate VIG Wrappers with Delete 2014.zip

However, I think the reason why my code is inefficient is because I am stopping and clearing every time in my while loop. 

Yes

 And my stop button logic has way to many not gates I could probably combine it into one not gate and send that out to multiple writes.

 

Is that something that would fix my inefficiency? 

No

Use a DAQ Assistant (1 for each device) in a loop.  Its a beginners friend (and sometimes advanced users).  It automatically sets up things for you so you don't have to worry about starting and stopping every loop.  If possible write to the whole port at the same time.

Hint:

Your "final" looks cleaned up to me.  Sure the terminals aren't quite right, and wires are a bit long, probably indicating that the terminals are added after the code generation (just a guess not sure XNodes actually do this).  But you don't have wires on top of each other like the first image.

 

Since this XNode lives in the VI that calls it, and is pretty much inlined as far as we can tell, the terminals are probably added when you right click the XNode to look at the generated code, and before then an interface to the XNode is this nebulous thing (at least to you and I).

That makes sense. Thanks for the help.

hoovahh I implemented the same operation as your subvi and it did not appear to work when I looked at the generated code.  So I went back and created some debugging code to get the block diagram image before and after cleanup to compare to the final code:

The result of probing these images is that it appears block diagram cleanup occurs but then gets lost:

Before BD.Cleanup:

After BD.Cleanup (just what I want):

Final "Generated Code" (somewhat crapified)

The only other thing that happens after the Generate Code Ability VI is that I do an  "Update Image" (calls the Image Ability).  Could this cause the diagram to get screwed up?

Rookie question here.  I'm getting lazy and don't want to click the cleanup diagram button when I'm debugging generated code in the Xnode.

Is there a way to clean-up the Xnode diagram with scripting?  I tried putting some cleanup commands on the diagram reference in generate code ability, but I'm guessing the code is not actually generated until after this VI is completed.  Or maybe I'm doing something wrong.  Is there another ability that can run after the code is actually generated where I can cleanup the diagram for debugging purposes?  

Tnx for the reply

So if i understand correctly. I still use consumer producer. In the producer there is only DAQ blocks that fill up queue. In the consumer loop i can than use circular buffer and later save the data?

You can still have a producer/consumer loop if you want.  The nice thing about Hoovah's circular buffer is that its DVR based so you could spit the wire and read the data in parallel if you want.  

I haven't seen your code and do not know how you want to trigger the save data.  Do you need to analyze the whole buffer every iteration to determine whether to save or are you doing something like just triggering on a rising edge level and only need to look at each daq read chunk?

You can probably do all the DAQ reading/triggering/saving in a single loop if you use pipe lining.  But I can only speculate unless you attach code.  A crude example using the Circular Buffer Demo.vi as a starting point: