bbean

Thanks, I'll probably try the Copy ability.  For future reference, can you upload an example Post-Install VI with the actions you described?

Also is there a list anywhere that describes the syntax for "Reply" commands/states in the Xnodes?  For instance, is there a way to force the AdaptToInputs ability.. (UpdateInputs maybe?)

I created an Xnode that pops up a dialog when the user drops it on the block diagram for configuration.  However, when I put the Xnode inside a Merge VI (so I can add it to a function palette menu), the On Drop Ability doesn't fire when the merge VI is used.  I guess this is because its not really dropped but merged.

Is there another ability that will handle this situation in a Merge VI? Couldn't find an OnMerge ability  so  I tried using "On Owner Change" ability, but it fires anytime you put code around the xnode (like a case structure, etc) or copy it to another diagram which could make the popup dialog very annoying quickly.

On a separate note, why can't I add an Xnode directly to a functions palette menu?

9 hours ago, hooovahh said:

One method that does work, but might not be desired is to use the control reference in the event, then go to a property node and read the Value then get the name from this.  I'd recommend getting the name the way you currently have, and then use this method if the name is empty.  

Thats where I was headed, but wasn't sure what the downsides to using the control reference were (other than speed I presume).

In the attached example, I'm having trouble figuring out why the references Traverse G - objects.vi returns for typedefs do not have the control name embedded in variant data when they are registered for Value Changed Events (enabled diagram).  It seems to work fine for controls that are not typdefs.  If I explicitly find the controls using VI panel properties (disabled diagram), everything works fine but I have situations where the traverse Gobjects would be preferred since it can go through nested tabs / controls etc.  Am I missing something simple.

Typedef Value Change.vi

On 5/16/2016 at 2:58 AM, lordexod said:

VI Macro technology update :

 

Code looks the same as before.  Where is new technology?

Hi Porter,

Very nice library you put together.  One quick question.  Is there any reason the RX/TX data and timestamps are not available as a Read Property from parent Modbus Master Class.  In situations where a device could be either a serial or tcp modbus, it would be nice to have access to that information at the parent level since it appears (unless I'm missing something) that the data is common to both the TCP and Serial Class.

Brian

Can anyone give a link to Amazon or CDW to purchase the Microsoft Windows 7 license they run on their Virtual Machines (for a single developer/machine)?  You will be my hero and I will owe you multiple rounds of beers.  Or do people develop on Win7 VM's in the cloud on Rackspace or AWS?

Or a tutorial about how to accomplish developer VMs / snapshots with a Windows 7 license?  Added bonus LabVIEW version snapshotting/licensing.   

I gave up on Windows VMs after getting stuck in an infinite loop entering the Microsoft Licensing Vortex .  

 

This would basically mean having a separate copy of OpenG for every project you are working on.  Personally i think this makes sharing code a lot easier than running a VIPC file every time you change projects.  It compartmentalizes project specific dependencies away from the IDE/Program Files location and into a specific place.  It also prevents one project from touching the dependencies of another.

 

So there may be more downsides than not, i'm not sure, but i think its a better approach than global dependencies.  

 

I like the idea of having separate project based configurations stored on the local machine and being able to switch quickly between them.  Would there be a way to "trick" VIPM/LabVIEW  to point to "project specific" user.lib / vi.lib directories using symbolic links?

Your code looks Ok.  Have you tried using a serial sniffer (such as device monitoring studio) while the OEM software is running?  This will give you a clearer idea of how it communicates if you are able to make the OEM software work.

It looks like you have a bunch of duplicate COM ports left open, probably a result of not stopping the program gracefully.  You can modify or use the attached VI to close these duplicate ports.  (There may be a better version out there to do this but I can't find it right now) But I don't think thats the root cause of your problem.

Also, try starting at address 1 (instead of address 0)

VISA Close All.vi

The best way to debug would be if the mfg'r provided a test software and you get that working first (without labview open) that will verify your hardware layer.  Then move to LabVIEW and software layer.  99% sure its not the "functions" you are using. 

If you don't have access to the mfg's software, start at the hardware level and read the OEM manual (i couldn't find it on line):

Is the interface RS-232, RS-485, or RS-422?

Does your USB to Serial converter support the hardware layer above?

If its RS-232 to you have the TX and RX lines swapped incorrectly?  

Are you sure the COM port is assigned to COM1? Plug and unplug the converter and see if COM1 disappears from windows?

Moving to the software layer

What does the manual say the default COM settings are?

Baud Rate = ?

Parity = ?

Data Bits=?

Stop Bits= ?

What is the default Modbus device address?

Based on your screenshot, it looks like you are trying to read from a starting address of 0.  Usually the address is a higher number.  Do you have the address list from the mfg?

Is it OK to put an Actor's "Internal Data" into its class control? or does it need to be empty?  I ran out of space on the actor diagram and had to make SubVIs to parse some messages and handle some follow on actions.   The internal data is a relatively big cluster and takes up a lot of space on the front panel of the SubVIs and could be cleaned up if it was a class wire.  Do you try to keep everything on the top level block diagram as good practice?  I think I remember one of JKI's style guidelines for their "state machine" recommending to keep the state string constants at the top level for clarity.

Also opening another can of worms...do you often have parent-child inheritance situations where an actor inherits from another?  For instance, for an "instrument" do you have an abstract parent and implementation in a child actor or do you make the messages abstract (message names shared between the same instrument type) such as "measure" and "set range" and the actors of the same instrument type do not inherit?

I can't really narrow down what causes it.  But it seems like if you copy the read var xnode from the existing diagram and wire the same cluster type to it, its fine.  But if you select a new instance of the xnode from the addons pallette and place it on the diagram and wire to the same constant, then save it crashes.  I don't know if that helps narrow it down to an ability or not.  Also it doesn't seem to happen with the string data type.  So far I have just seen it on clusters.  It may be a labview bug and be unrelated to the xnode.  I have no idea.

I've been having problems with intermittent crashes and LabVIEW hangs recently using the Variant Repository xnodes in LV2015SP1.  More specifically Read Variant Repository.xnode.  Has anyone else had problems in LV2015SP1?

http://www.screencast.com/t/tj15qFGRc

Instead replace vi to vim.

Macroizer.llb copy to "..\resource\plugins\PopupMenus\edit time panel and diagram" and right-click on subvi and "Convert To Macro". 

Been waiting for an excuse to install 2015

 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.