PJM_labview

I had the same problem.

By error and trial I figure out that you have to change the icon of the help ability and the palette will display it. Just to be safe I typically put the icon I want in both the XNode and in the Help ability. If you don't have a help ability I think you can use the initialize ability icon.

PJM

QUOTE(Tomi Maila @ Nov 5 2007, 01:33 PM)

Do you have any idea where these two ability VIs can be called from?

Tomi

Well, I know by experience that you can call them from the DoubleClick ability. There are probably more but I don't know them.

PJM

QUOTE(Tomi Maila @ Nov 5 2007, 05:37 AM)

...

The problem is that I find out the queue element type only after I've generated the code by inspecting the element output terminal type of the generated Preview Queue Element node. Now I should update the Xnode terminals according to this new information I receive after I've generated the code but I cannot get LabVIEW to call the GetTerms3 ability multiple times per input change. Even if I send the Update Terms message multiple times, LabVIEW only calls the GetTerms3 ability once.

...

While I don't have a solution to your specific issue, I can confirm having seen LabVIEW preventing multiple call to abilities through the reply output.

I also notice that some reply will be completly ignored. For instance, ReplaceSelf or AugmentSelf called from ResponToDrop have no effect.

I have come to the conclusion that XNode could benefit from having an ability callable at anytime so the XNode data could be updated bypassing the XNode expected behavior.

PJM

QUOTE(thevoiceover @ Oct 30 2007, 03:51 PM)

Yes and I am broke.... Oh well..

Use the following code to write your own "HSL to RGB.vi" in LabVIEW. It does not take that long.

/******************************************************************************   FUNCTION: HLStoRGB   PURPOSE:	 Convert from HSL to RGB   IN:		 Hue, Saturation, Luminance from 0 to 1   RETURN:	 RGB color (0xRRGGBB)   COPYRIGHT:1995-1997 Robert Mashlan			 Modified for LabWindows/CVI, 1999 Guillaume Dargaud ******************************************************************************/ typedef unsigned char  BYTE;		// 8-bit unsigned entity  COLORREF HLStoRGB(const double H, const double L, const double S ) {	 double r,g,b;	 double m1, m2; 	 if (S==0) r=g=b=L;	 else {		 if (L <=0.5) m2 = L*(1.0+S);		 else		 m2 = L+S-L*S;		 m1 = 2.0*L-m2;		 r = HueToRGB(m1,m2,H+1.0/3.0);		 g = HueToRGB(m1,m2,H);		 b = HueToRGB(m1,m2,H-1.0/3.0);	 }   return MakeRGB((BYTE)(r*255),(BYTE)(g*255),(BYTE)(b*255)); }/******************************************************************************  FUNCTION: HueToRGB  PURPOSE: 	Convert a hue (color) to RGB  COPYRIGHT:1995-1997 Robert Mashlan			Modified for LabWindows/CVI, 1999 Guillaume Dargaud******************************************************************************/static double HueToRGB(const double m1, const double m2, double h ) {	if (h<0) h+=1.0;	if (h>1) h-=1.0;	if (6.0*h < 1  ) return (m1+(m2-m1)*h*6.0);	if (2.0*h < 1  ) return m2;	if (3.0*h < 2.0) return (m1+(m2-m1)*((2.0/3.0)-h)*6.0);	return m1;}

PJM

What do you mean? this look very "Chic"!

PJM

"The Consumerist is reporting that a Best Buy customer recently purchased a hard drive only to discover that the box contained six ceramic bathroom tiles instead of the Western Digital ..."

Read More...

I wonder if it cames with a chisel too...

PJM

What you are experiencing is a LabVIEW bug I reported a while back. I actually though it was fixed, clearly this is not the case.

Basically starting in LabVIEW 8.0, NI broke the variant capability to preserve the data name (see this thread).

The good news, is that there is a work around. If you change your code as seen below everything works fine.

PJM

I don't know if you care about the display side of it, but if you do, attached below is one way to do this.

Note: OpenG VIs Required.

PJM

Download File:post-121-1193433707.vi LV8.2

QUOTE(Darren @ Oct 24 2007, 02:04 PM)

The XDataNode is the "ear" that sticks off the side of the Timed Loop. The Timed Loop itself is a native LabVIEW structure. I'm fairly certain that there currently exists no way to create a G-based structure.

-D

Ah, that's too bad

Well may be combining the use of VI inlining + XNode + XData Node something might be possible.

Have the code in a subVI, have the XNode display an image of the code instead of the SubVI icon, then attached ear(s) to control execution (if possible/needed). When the user want to edit the XNode code, inline the subVI/Xnode...

This are stream of consciousness ideas... might not lead to anything.

PJM

QUOTE(rolfk @ Oct 24 2007, 01:13 PM)

Which VI/Xnode file would you suggest to look at as starting point for that?

Rolf Kalbermatter

As per the wiki page: http://wiki.lavag.org/XNodes' title='LabVIEW Wiki article on XNodes' alt='Wiki article on XNodes' style="border-bottom: 1px dotted #3366BB; color: #3366BB; cursor:pointer; text-decoration:none;" class="wiki">XNodes, this is where the timed loop XNode code is located (vi.lib\Platform\TimedLoop\XDataNode\XDataNode.xnode). There is a lot of stuff in that folder (password protected of course).

PJM

Well this have to be possible with the existing XNode stuff since I am pretty sure the timed loop (or timed sequence) is an XNode.

Figuring out how to do what you describe though, is probably not going to be easy.

PJM

QUOTE(mballa @ Oct 19 2007, 06:50 AM)

Thats interesting it still doesn't work for me. I don't have the scripting keys enabled and I see my property node it a different color than yours.

So is it true that I have to have the keys enabled to run the vi. That wasn't true for the 7.1 stuff.

If this is the case I will not be able to use this function. I bring this tool with me when I work on clients machines and I'm not going to put the scripting on it.

Mark,

Try this VI (LV8.5). This does work with and without the ini keys (I just tested it). It is pretty much the same that Ton post, except it does not use event registration.

Notes:

• The VI Activation provide the app instance, so no need to launch it from any place special.
  
• To be able to see this event (to create it in the event structure) you have to enable the ini keys.
  
• Since (I believe) the Navigation Window is using this event to find out which VI has the focus, it has to work on every machine, regardless of the ini keys.
  

Download File:post-121-1192810815.vi

PJM

QUOTE(mballa @ Oct 19 2007, 06:50 AM)

Thats interesting it still doesn't work for me. I don't have the scripting keys enabled and I see my property node it a different color than yours.

So is it true that I have to have the keys enabled to run the vi. That wasn't true for the 7.1 stuff.

If this is the case I will not be able to use this function. I bring this tool with me when I work on clients machines and I'm not going to put the scripting on it.

Mark,

Try this VI (LV8.5). This does work with and without the ini keys (I just tested it). It is pretty much the same that Ton post, except it does not use event registration.

Notes:

• The VI Activation provide the app instance, so no need to launch it from any place special.
  
• To be able to see this event (to create it in the event structure) you have to enable the ini keys.
  
• Since (I believe) the Navigation Window is using this event to find out which VI has the focus, it has to work on every machine, regardless of the ini keys.
  

Download File:post-121-1192810815.vi

PJM

Did you try logging out and back in?

PJM

QUOTE(Jim Kring @ Oct 17 2007, 02:54 PM)

Lately, it seems that the LabVIEW upgrade process is just trading problems. Get some new features and bugs fixed, but have deal with the new bugs. Granted, the new features are really nice, but it's pretty frustrating working around the new bugs and "inconveniences" (like waiting several minutes for your project to close or a typedef change to propagate). :headbang:

<Warning Thread Hijack>

So true, and don't even get me started on the hierarchy windows which has become unusable since LV 8.0.

Used to be snappy and handy in 7.1, no longer the case...

</Warning Thread Hijack>

PJM

QUOTE(JDave @ Oct 17 2007, 01:44 PM)

I had a few ideas that might align with your workflow. But a few questions - How would you envision handling controls that you don't want connected? Would they be required to be made not visible, or would you restrict the wiring to selected controls, or would you have a special place to put controls you don't want connected?

Do you envision your visible front panel area to mimic the connector pane, so the relative positions of the controls on the front panel are in roughly the same place as the terminals?

David

David:

1) I hardly ever have controls on my FP that I do not want to connect to the connector pane.

2) Best attempt at connection will do the following (in order of priority):

• Connect error clusters (if present) to lower left and lower right respectively (regardless of the connector pane pattern).
  
• If references are present (like ref in, ref out), connect them on the upper left and upper right respectively.
  
• Connect any control/indicator pair having the same name pattern (ex: data in; data out or data in; data dup) at the same level on the connector pane respectively on the left and right side.
  
• Connect the remaining controls like they are mimicking the connector pane (see example below).
  

3) If there are controls/indicators I don't want to connect, I am not sure what the best approach is. Maybe if the controls/indicators are not in the visible window frame, it should not be connected (yes I think I like this).

PJM

QUOTE(mballa @ Oct 17 2007, 10:58 AM)

...I was going to hold off and wait until I had this perfected and I didn't want to hijack the thread.

But with all the discussion on this topic that I have been working on for the last 2 years and JDave mentioning my old fixer, I can't resist showing what I have currently.

...

Mark,

This zip file seem to be missing a bunch of "universal utility" files located in user.lib.

http://lavag.org/old_files/monthly_10_2007/post-121-1192650375.png' target="_blank">

PJM

Very nice tool.

This is still a little bit too much work and is against my work flow.

I think, for my use case, I would like a tool that auto connect to the connector pane, given the relative position of controls.

So I would position my control the way I want (no grid), then run the tool (which will attempt to connect doing its best effort, following a few simple rules). It will default to the 4x2x2x4 (4815) connector if no connector selected, else use the existing one.

But this is still a very nice utility :thumbup: (I might even use part of it to write my version of it).

PJM

Go even further and start from a classic control and you will get system scrollbar. You can then make it look like a system one.

In the same vein, here is another very poor experience I had today with the NI installer builder.

I have a project (8.21) that depend only on NI DAQmx 8.6.

So in the additional installer I have selected:

• LV Runtime 8.21
  
• NI DAQmx 8.6
  

So after swapping cds and DVD for about 40 min (by the way with the Aug 07 device driver, when the installer say "insert Aug 07 cd1" one has to read "insert DVD"...) I end up with the installer builder asking me to insert NI Vision 8.0 CD!!!!

I have the vision stuff install on my Laptop, but my project does NOT depend on vision, my customer does not even have vision ...

To make a long story short, since I did not have (nor did my customer) the NI vision 8.0 CD, I was not able to build the installer, and I had to install the executable (and NI DAQmx) manually on the target machine.

It used to be a lot more straigthforward to create an installer in LV 7.1 and lower; since LV 8.x has been released, the installer builder has - in my opinion - getting way more difficult to use.

PJM

Here is another thread on this topic (on LAVA).

PJM

QUOTE(PJM_labview @ Sep 30 2007, 10:43 AM)

1. If no grid settings are selected (either on the BD or FP) on a given VI, apply the user defined settings automatically.
   

Just a quick note.

It turned out that LabVIEW does just that for file that were created prior to the existence of the grid (I just noticed this on a LV 4.0.2 file).

PJM

Here is my perspective/use case for this.

I have been using the grid for both BD and FP for years. None of my colleagues or customer ever use the grid, but LabVIEW is not aware of this fact, because by default there is always a grid setting selected (whether the grid is visible or not). When I opened a VI created with this invisible default grid, I have to change the grid to my defined preference every single time (and I have been doing it for years). If the VI is a User Interface I understand your argument of why it could be useful to preserve the FP grid, but honestly I do not do it. I have no problem not messing with the existing controls, and if I have to add some user element I have no problem using the arrow keys and alignment tool.

So what about adding a couple of ini settings to LabVIEW:

1. If no grid settings are selected (either on the BD or FP) on a given VI, apply the user defined settings automatically.
   
2. Always overwrite grid settings with user settings (which is basically what I have to do manually constantly) and let the user deal with the consequences.
   

PJM

QUOTE(Aristos Queue @ Sep 28 2007, 10:37 PM)

Developer A writes a VI with grid size 10. Developer B opens the VI on his machine to add a control to the FP. His default grid size is 13. If we used the environment setting for VIs when they were opened, instead of having each VI remember its alignement, then no matter which grid square Developer B uses, the new control does not drop aligned with respect to the other controls already on the FP.

The environment setting is the grid size for new VIs so that you can define the layout for each new VI. But after a VI is made, edits to that VI should stick with the layout chosen for that VI. Thus each VI remembers its own layout.

No, there is no programmatic interface (not even with some magic .ini token) for setting the alignment grid size on a VI.

I have to say that the reasoning behind this does not convince me. So develloper B grid is 13, and he can't snap his new control to be aligned with the existing one, and??? He can still align it manually (

PJM