bbean

I know the title of your post is "CRIO-style architecture for Raspberry Pi" and briefly looking over the architecture I think it looks fine.  But have you or anyone tried this architecture on the Rpi:

Front Panel Publisher

What are the limitations of the Rpi LabVIEW runtime?  When I get some time I'd like to investigate more.

On 7/15/2016 at 7:34 AM, ShaunR said:

I'm still waiting for you to modify the named event macro to be an xnode that labels the event ref the same as the indicator label and makes the need for the re-labeler in your example, moot   (Especially now that it looks like it won't be fixed in LV 2016)

Sorry, I'm a little tied up right now with work stuff.  maybe we could chat offline regarding what you want in detail, so I don't accidentally go off on a tangent when/if I do actually work on it.  I think what was stopping me in my tracks before was figuring out how to determine the "name" to put on the output control based on an upstream connection (input wire)

On 7/11/2016 at 9:30 AM, lordexod said:

New non-xnode update for "Re-Label Wire Xnode" popup plugin Relabelizer.llb , copy to ..\LabVIEW <version>\resource\plugins\PopupMenus\edit time panel and diagram.

lordexod.  I tried your new Relabelizer popup plugin and its a nice solution.  Seems to have a small bug that the terminals may not get wired up properly depending on where you right click to execute the script. See:

Relabilizer Plugin Bug

I still like my solution better  because it looks better on diagram.  Yours is more elegant because of its simplicity though.

Bean,

Thanks for the response.  I clicked your link and then went down the black hole of MS again trying to find a reseller for the license.  Doing a google search resulted in this possible link to purchase:

Microsoft MSDN Platforms License & Software Assurance 1

Is that a similar license to what you are using?  

I may be hijacking the thread at this point.

To be a little more helpful, I googled speed up gifs and found this:

Ezgif speed up site

and sped up the above gif by 200% and inserted it into the attached VI.  Then inserted the original gif saved from the site at 100% (for some reason the original gif wouldn't drag/drop into the VI, but ones run through the website would). 

Anyway it seems the speed up works on my machine/vi.  

staythirsty.vi

13 hours ago, hooovahh said:

I admit I don't use GIFs in my UI's much, and when I do I usually don't care about how fast they run.

Stay thirsty my friends

On 4/26/2016 at 6:05 PM, Michael Aivaliotis said:

I've been away from the LAVA forums for a couple years. Recently, due to some site maintenance. I decided to hang out and check out some of the cool discussions here on LAVA... I'm still trying to find them.

I don't know what the definition of cool is, but here are some posts that I've found interesting / very instructive:

VI Macros (includes comments from someone named jeffK)

• HAL Demo / Named Events (an offshoot of this discussion by ShaunR)

Turn your front panel into an interactive HTML5 site

LVTN Messenger Library

I am probably leaving out a bunch of others....

I think another potential cause of the downturn in use of lavag is the move of advanced users to their own company/personal blogs for people to present / discuss new ideas.  The motivation I presume is to drive internet traffic / SEO / twitter / instagram / facebook / myspace (was once cool ) links but results in the scattering of the community.  

I don't know about everyone else, but usually when I disappear from lavag for a while it means I'm to busy with "real" (billable) work.  Maybe its a good sign that lavag use is going down 

how many points are in each plot of graphs you shown in your last post?  8192 or 30-50

Is the template trace pre-calculated before starting or is it an average of some set of the white traces (exceeding some threshold)?  I guess I'm asking if you have multiple different thresholds for each color shown in the graphs?

28 minutes ago, mohamad said:

I cannot use of way of "decimate the data for display".because I only have 30-50 data points for  each of overlaid curves .you can see it and its source code in first post.

I'm a little confused.  On your first post you show code and an example where you do a peak detection and than pop off traces from the data around those points (samples before and after).  Is that all you need to do?

Or do you need to do additional post processing on the samples before and after the peaks (analyze each set of data around the peaks).  For example in the post with these screenshots:

you show another threshold line.  Is there a second post processing step (on the traces that were pop'd off of the original signal) that you want to do "online" with another threshold?

Also do you want to be able to change the samples before and after in real-time as you are collecting data or can it be fixed for each session?

11 minutes ago, mohamad said:

For this,Why should not I change their colors?

And,how should I implement this "transparency"?

Changing the colors of individual plots occurs in the UI thread and is "expensive".  The secondary XY graph avoids this by making all plots the same color...in your case yellow?

Some other things to think about:

1.   if you change your threshold value, do you want to remove the old yellow traces from the display if they no longer meet the threshold criteria?  It gets more complicated that way.
2.   how long does the daq read take, you should explore pipelining to help speed up things as well.  In the link A would be your DAQ and B would be your update of the buffer and display

12 minutes ago, mohamad said:

And,how should I implement this "transparency"?

You make an exact copy of the graph and then use the tools pallette paintbrush, switch the color to transparent T, start erasing things on the graph that aren't needed (everything except the signal plots for the most part), and then move that graph over top of the other graph.   Some ppl will call this a "cluge" and you have to make sure that if the x or y scale change on the visible graph, it also changes on the transparent graph.  So programming challenges arise for instance if you allow the user to autoscale.

1 hour ago, Norm Kirchner said:

Is that snippit working for anyone else? I'm not having any luck w/ it

the last snippet from ensegre is not working for me either.

33 minutes ago, ShaunR said:

Isn't the issue that the OP is referring to, that when large data amounts are sent to the graph (regardless of how they were acquired or organised) that the indicator is slow at rendering them? Yes. Ring buffers are great for recording data at high rates but you are still left with the rendering problem, are you not?

I think the OPs issue becomes a little clearer if you make your 500 plots 8192 data points in length instead of 128

Point taken re 8192 points.  On my laptop it takes about 20ms per plot update.  How long does the daq take?  Maybe pipe-lining would help here.

Option 2 - decimate the data for display

8192 points or more exceeds the pixel width of the graph indicator area (unless he needs a super big xy graph and has a super monitor).  For display purposes he could decimate the data with min/max and only display the #of points = pixels width of graph indicator.  Then store the actual data in a separate buffer.   

55 minutes ago, ensegre said:

"mine is faster..."

Ha! I knew someone would be able to make it more efficient.  Is the visible property faster than defer panel updates?  

Is there anyway to do the array operation inplace? or is there a "rotate 2d array" primitive hidden somewhere? Also I'm guessing a good portion of the execution time is redrawing all the plots when they shift 1 plot location on each iteration...but maybe I'm wrong.

2 hours ago, ensegre said:

But OTOH, to my great surprise, a plain waveform graph with 500 plots is faster:

YMMV...

Nice.

Building off of ensegre's solution, here is another option for ring buffer (below).  I think its an order of magnitude slower, but it allows older plots to fade away.  

I think you will have to create two ring buffers and two graphs, one for displaying realtime data, and another for displaying your "selected plots", then make one graph transparent and overlay it over the other

Sorry don't have too much time to help here, but try example code here for some guidance maybe:

C:\Program Files (x86)\National Instruments\LabVIEW 2014\examples\Graphics and Sound\3D Picture Control\Using Meshes.vi

15 minutes ago, JKSH said:

(EDIT: D'oh, half an hour too slow)

Naming user events is an edit-time operation.

If I write a subVI that generates and outputs a user event refnum, call the subVI twice, and then register both events at the same event structure, I will get two cases with the same event name (which equals the label of the subVI's output terminal). The workaround consumes a large amount of real estate:

See also this highly-kudo'ed idea, which seems to be catalysed by the desire to name user events: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Officially-Support-quot-Coerce-to-Type-quot/idi-p/1213153

Some self promotion here, but have you tried or seen this:

Make sure all your power options are set so that the computer doesn't turn off when not being used (no hibernate, no sleep, no usb suspend, etc)

3 hours ago, ShaunR said:

Well. The fist thing I will do is fire up the VIM Hal Demo. If that works without having to replace all the VIMs and has meaningful event names; I will be a very happy bunny.

Maybe this can help a little until 2016...Re-label Event Wire Xnode

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

43 minutes ago, jeffk said:

To further pique your interest in macros, there is a new one in LabVIEW 2016 / User Libraries / macros  called Norm.vim.

It is not meant to be rigorous from a mathematical perspective (it's just my best guess) but rather to illustrate a new (experimental) structure, a variant of the Diagram Disable Structure, called a Type Enabled Structure.  It has some interesting properties when used within a macro.

Here is how it works.  When an instance of the macro is inlined and types are propagated to the inputs, each subdiagram attempts to propagate types;  the first subdiagram (in subdiagram order) which successfully propagates types without any errors is enabled and all the others are disabled;  the enabled subdiagram is the one which is compiled for this instance of the macro.

The new structure is not in any palette yet, nor is there any documentation.  It isn't quite ready for prime-time, but you can copy it from Norm.vim and experiment with it and give us feedback.

Thanks for the heads up.  I guess I'll have to sign up for the beta testing to get a peak.

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