Tick colors Property node bug

I found a bug in 8.5 tonight. The attached VI will demonstrate the issue.
If you attempt to get the Tick Colors by cluster, you will get an error indicating that the property doesn't exist. If you get the Tick Colors by individual name, you won't get the error.
This applies to all plot types.
Message Edited by Matthew Kelton on 12-30-2007 02:30 AM
Attachments:
Plot Property bug.vi ‏22 KB

This was reported to R&D (4BA3OC8G) for further investigation. A possible workaround is bundling all the separate elements yourself.
Thanks for the feedback!
Charlie M. CLD

Similar Messages

Tick color property for XY graph

I wish to change the tick color of XY graph programmatically. Then my program written as below. My bar graph contains 4 y scales. So i think the for loop should not be a problem. However, i get the error which stated ' Specified property not found'. Can somebody explain to me what is the cause of this error? Thank you

Tim,
Thank you for bringing this to us. We are aware of the issue where using the XScale,TickColors,AllElements returns the error 1058 and are looking into fixes. Hopefully using the other two XScale,TickColors Properties will provide what
you need at this time.
Thanks again,
Scott A
SSP Product Manager
National Instruments

Changing the color property node of an indicator based on a certain condition

An upper level VI sends a set of conditions to a VI that SHOULD change the color of the indicators based on a set of t/f cases. However, the color of the indicators is changing in the lower level VI but not in the VI that is doing the calling. I am not using an while loops, just case statements. Help?!
Attachments:
status_reponse_coloring.vi ‏240 KB
upper_level.vi ‏33 KB

What you need to do is get a reference to the upper level VI control that you want to change to colour of. I have edited your VIs that you included to show how I passed the references to the controls into the subVI. The subVI can then change the colours, values, labels, etc. of the controls and changes are immediate.
Hope this is what you're looking for.
Rob
Attachments:
upper_level.vi ‏24 KB
status_reponse_coloring.vi ‏247 KB

Property Node in VI throws Error 7 in LV 7.1 but runs OK in LV80 and LV86

Hi everybody
I build a custom IVI instrument driver and using the LV tool <Generate VI Interface from Instrumnet CVI Driver> I was able to get a LV wrapper for each driver method. From LV86 I saved first in LV80 and from LV80 I saved as LV71. I have all these LV versions on installed on my PC.
I have no trouble in using these LV wrappers in any of these LV versions as they work OK.
Now my IVI driver has also Properties that the Import Driver Tool does not convert as a wrapper and for that reason I had to create a Property Node Warpper myself and saved in the same LLB under LV/instr.lib folder.
Once I have all these method wrappers and the property node wrappers I made a small VI
1. Initialize IVI With Options on a TCPIP instrument
2. Set-Get an IVI Timeout property
3 Close IVI driver on TCPIP instrument.
Good part is that in LV 86 and in LV 80 the VI is running fine when I use these LV version wrappers from their coresponding instr.lib folder.
As soon as I am going to use the LV 71 wrappers in LV 71 I could create the same small VI to Set/Get Timeout and the VI look OK nothing is broken but when I run it the Initialization is OK but as soon as is reaching the Timeout Set Property Node gets out an Error Code 7.
To run this VI the user need to install the jdCMR IVI driver then add the LV71 jdCMR wrappers inside LV71/instr.lib and then he may build any VI using these LV warppers.
The only problem is that the Property Node get out an Error Code 7 and the same error code get out from Property Node if I am picking the Property Node from VISA Advanced Pallette, connect this node to jdCMR driver, set Timeout property inside the node and after connecting the input and output references plus the input and output error to Initialize and Close LV wrappers I still get this error at running time.
The same LV 71 VI if I open in LV80 or in LV 86 runs without any problem?
Does anybody knows why LV 71 is not working the same way as LV80 and LV86 with respect to Property Node?
Btw When I save my VI from LV 80 to LV 71 I get this warning...
IVI Error Message Builder.vi
    Cannot save VI from VI.LIB to previous version.
Merge Errors.vi
    Cannot save VI from VI.LIB to previous version.
Thanks
Sorin

Hi
For further testing of the IVI driver Property Node bug with LabVIEW 7.1 IVI drivers I download and installed two different IVI drivers from two very known instrument companies, Rodhe-Schwarz and Agilent Technologies.
I have to mention that both these companies releasead their IVI NI LabVIEW 7.1 drivers under NI Instrument Driver Network and ready to be installed and used by any customer of these two instruments.
The bug is present only in LabVIEW 7.1 version as if I take the same VI that breaks in LabVIEW 7.1 I could run it without any problem in LabVIEW 8.0 or LabVIEW 8.6 versions.
Anybody could test this bug for these two NI released IVI drivers in simulation in LabVIEW 7.1 by following these links below.
Agilent ag81150ni IVI Driver for LabVIEW 7.1 install from here. Run in simulation only by setting Simulate=1
http://sine.ni.com/apps/utf8/niid_web_display.download_page?p_id_guid=55798957B1A633BDE0440003BA7CCD...
   Rodhe Schwarz rsngpt IVI Driver for LabVIEW 7.1 install from here. Run in simulation only by setting Simulate=1
http://sine.ni.com/apps/utf8/niid_web_display.download_page?p_id_guid=E3B19B3E91D6659CE034080020E748...
After installation complete close LabVIEW 7.1 if was open, then restart LabVIEW 7.1 and now you may see under the LabVIEW Instrument Driver Palette two new IVI drivers ready to be used as LabVIEW 7.1 wrappers.
Open a new blank VI and from Instrument Driver Palette use two well known Vis that are Initialize With Options.vi and Close.vi add them on your blank VI block diagram and connect thm together. Accept all default parameters except Simulate that must be Simulate=1.
Both Vis run OK in simulation mode without errors. Now pick a Property Node from VISA Advanced Panel and squeeze this between the Initialize With Options VI and Close VI and make the instrument reference in-out and error in-out connections.
Now run these two simple Vis in simulation
I run Rodhe Schwarz IVI driver and Property Node passes OK until the end
I run Agilent IVI driver but Property Node is getting out Error Code 7 that is the same as my own driver error.
Both these IVI drivers are under NI Instrument Driver Networks and have been built and integrated as native NI IVI instrument drivers.
Question is why they behave so different with respect to Property Node from the VISA Advanced Panel?
I attached the screen shots as PNG files that show clearly the difference of VISA Property Node behaviour when used under the same circumstances.
Thanks  Sorin
Attachments:
ScreenTestShots.zip ‏152 KB

Property node inverted color

Check out the inverted color on this property node - I have never seen it before. What does it mean? Bug?
Regards,
Jack
Message Edited by mechelecengr on 03-16-2009 10:15 AM
a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"] {color: black;} a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"]:after {content: '';} .jrd-sig {height: 80px; overflow: visible;} .jrd-sig-deploy {float:left; opacity:0.2;} .jrd-sig-img {float:right; opacity:0.2;} .jrd-sig-img:hover {opacity:0.8;} .jrd-sig-deploy:hover {opacity:0.8;}
Solved!
Go to Solution.
Attachments:
InvertedPropertyNode.png ‏11 KB

Like tst, I do not care enough about this nitpicky bug enough to report it. I just wanted to make sure that this phenomenon was not an INTENTIONAL way for LabVIEW to communicate some information to me about that property node. Further, I wanted it documented on the forums for anyone else wondering.
I would rather R&D focus on bugs that affect performance, not a hard to track anomaly such as this! This is the first time ever I have seen this behavior (I began programming with LabVIEW 7 Express).
Best regards to all,
Jack Dunaway
a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"] {color: black;} a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"]:after {content: '';} .jrd-sig {height: 80px; overflow: visible;} .jrd-sig-deploy {float:left; opacity:0.2;} .jrd-sig-img {float:right; opacity:0.2;} .jrd-sig-img:hover {opacity:0.8;} .jrd-sig-deploy:hover {opacity:0.8;}

Multiplot waveform graph plots are different colors when set to be the same with a property node.

The graphs were working yesterday. I made a few changes to another part of the block diagram and now the graphs do not plot all of the plots the same color. I am using a for loop with a property node with the elements active plot connected to the iteration terminal, and plot color to a color box. My for loop increments programmaticaly from another part of the code to create plots as it runs. I have replaced the graphs with new ones and they will work sometimes.
I am using Win2k and LV 7.1
Thanks,
Brett

Hi bh3560,
Have you tried chaging the color by right clicking on the line in the plot legend. There is an option to change the color of the plot.
Brian K.

Any alternate solution to using Waveform Chart Property Nodes 'ActPlot', 'Plot.Visible' for mulit-plot color problem on PDA?

Hello,
    On a waveform chart, 4 signals need to be plotted based on the status of 4 boolean inputs. Eg. if the first boolean input is true, the first signal needs
to be visible on the waveform chart; if the first boolean input is false, the first signal should not be visible on the waveform chart and so on. This can be
done on LabVIEW desktop using the Waveform Chart Property Nodes 'ActPlot', 'Plot.Visible' - a sample VI "BundleSignals_Select_Desktop.vi" is attached for
reference.
    But on PDA, since the Waveform Chart Property Nodes 'ActPlot', 'Plot.Visible' are not supported, some other method has to be used. I have done the
selection/de-selection of these signals using 'Insert', 'Delete' array functions as shown in the attached VIs "BundleSignals_PDA.zip" which works, but the
problem is that the colour of these signals do not work as desired when the selection/de-selection of these signals is done - It is required that the first
signal should always appear in White color, the second signal should always appear in Red color, the third always in Green color & the fourth always in Blue
color.
    I hope i have made myself clear of the problem. Has anyone faced this problem before & is there a solution?
Note: Version of LabVIEW that we are using: LabVIEW 8.5 Professional Development System for Windows Vista/XP/2000 and LabVIEW 8.5 PDA Module for Windows
Mobile.
Thanks & Regards,
Subhashini
Attachments:
BundleSignals_Select_Desktop1.vi ‏25 KB
BundleSignals_PDA.zip ‏26 KB

Unfortunately the only alternative to using property nodes is to set the properties manually on the development environement. The limited size of memory does limit us in terms of features for the module.
Mehak D.

Can you change the vi color background using a property node?

I was wondering if it was possible in Labview to use a property node to change the front panel background color for one iteration and then back to an original color afterwards. I dont think it is possible but would like to know for sure.
Thanks,
Jody
Jody M.
The Procter and Gamble Co.
Certified Labview Developer
Currently using LV2012.
Solved!
Go to Solution.

Yes you can
That's how you change it, you will just have to put some logic to change it back
CLA, LabVIEW Versions 2010-2013
Attachments:
FP color.PNG ‏4 KB

Tentative bug report: property node (and other objects) resizes structure in which they are dropped even when this is not needed

This one has bugged me for a while, so, since I am in a mood to report annoying features, here it is:
On the diagram, when you drop an object that could have its size increased by user action (for instance a property node in which you chose "Value", which is a short property, but you could later change this to a "longer" one, which admittedly might require more space on the diagram), a case structure in which you drop it, will automatically increase its size.
Let me illustrate this with ONE example (can be reproduced with other objects such as enums, clusters, etc...).
Here is a simple diagram:
Note that I am going to create a property node from the front panel. This, for a reason that makes the beauty of this "feature", is very important. Apparently, if you create the property node from the diagram, nothing weird happens. The exact location where I will drop the node is not very important but needs to be close enough from the border.
Here is the result (LV 2011 but as I said, this has bugged me for a few versions already):
Basically, the case structure (and the whole diagram as a matter of fact) has expanded.
This is particularly annoying, say, when you are creating a diagram with 10 cases in a case structure and you start dropping things such as property nodes in each case: the structure keeps growing, and growing, and growing...
That also works with Event structure, and I am ready to bet, with other as well.
As I said, it is also not limited to Property nodes. I have noticed that this happens if you drop a cluster constant that contains an enum (presumably because some of the enumerated strings are longer than others).
I could speculate why this is the case, but that is not my job.

Actually, this might not be true. I found a variant of this behavior. With "Place Structure with Auto Grow enabled" unchecked, here is what I observed while dropping a property node on my diagram:
Before:
After:
This is the expected behavior. The Property Node is partly hidden inside the Case Structure I dropped it in. Now that's not what I wanted to do. I wanted to drop it in in the innermost Case Structure:
The problem is that now this Structure has grown (as has the whole diagram) to leave space for the whole Property Node:
It is a subtle bug in the sense that I tried to reproduce it on a new VI with a series of nested Case Structures, but it did not result in this behavior.
Anybody caring to comment?

VI Snippet Bug (IMAQ Image Vision Display with Property Node)

Colleagues,
Just found small bug in LabVIEW - Creating snippet from selection with Vision Display together with Property node is not working (means that nothing happened - no save dialog appear):
VI in attachment (VAS or VDM software required). Can someone reproduce this?
Andrey.
PS
LabVIEW 2009f3
Message Edited by Andrey Dmitriev on 01-21-2010 03:29 PM
Attachments:
Snippet BUG.vi ‏40 KB

Hi Andrey
Thank you for your post, I will clarify if this is fixed in the LabVIEW SP1.
If it is not, I am going to write a CAR for that.
Kind regards
Beat
AE NI Germany

Color of error out of a property node

I have just noticed that the error out of a property node may be red or black. See below picture.
If I create a new property it will be black but if I copy the red one, it will remain red. What does this red color mean ? Any ideas out there ?
Message Edité par JB le 05-08-2008 03:35 PM
Attachments:
Example_VI.png ‏2 KB

Right-click on the red version and you will see that the option "Ignore errors" is selected.
Ben
PS: Mathan, See above.
Message Edited by Ben on 05-08-2008 08:37 AM
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Table property node.

Dear,
I am a beginner in using a table.
My attachment and image explain my problem.
By clicking the left mouse key, the cell background color can be changed.
This color is used as three states contoller.
A string in each cell represent the state of the color. (1:1 corresponding with color).
My problems are
1. I didn't write to modify the cell position. But some cells are moving horizontally(by 2 or 3 column) in one row.
One of attachement explained the snapshot of the problem.
2. In real time, I want to update the state string in active cell. the property node result, "Set cell value", is strange.
Of course, I tried to update whole table by using shift registered array.
But, only deactivating the cell by moving the activation to other cell, the string was updated.
3. I want to use the table as a indicator: I want NOT to write some string in any cells of the table.
As I mentioned, some mouse clicking is preferred. How can I do?
Attachement: 1: LV8.0 code, 2: snapshot image
메시지가 04-14-2007 02:17 AM에 labmaster에 의해 편집되었음
Attachments:
bbb.PNG ‏35 KB
table.vi ‏53 KB

Hi Labmaster,
This is an interesting issue, and something that I am going to investigate further. It appears to have something to do with using the invoke node to change cell values within an event structure that is not working. I tried putting a one button dialog box inside that event case to let the user know that the event had fired, and interestingly enough the value changes then. This is likely a LabVIEW bug of some kind.
By the way, you have some funky effects going on in that table!
Best regards,
-Sam F, DAQ Marketing Manager
Learn about measuring temperature
Learn how to take voltage measurements
Learn how to measure current

Just checking on another odd feature: Typedef enum Property Node "Value" not reflecting changes in the Typedef?

Just encountered this odd behavior in LV 2011 which I reduced to the following example:
- create a new VI and drop an enum control on te FP.
- make this control a typedef and open the corresponding typedef
- create a "case 1" item and a "case 2" item
- save the typedef (I used the name Typedef Control 1) and CLOSE it (this is to allow updating of the original control).
- drop a case structure on the diagram and connect the enum to it:
So far so good. Now create a "Value" Property node for the enum and use it instead of the terminal:
If I now go back to the typedef and add a "case 3" item, save the typedef and close it, the control is updated, but the Property node is not.
How do I know that? For one, the Case Structure contextual menu does not offer to create a case for every value. Also, if I add a "case 3" case manually, it turns red.
Luckily, the magic Ctrl-R key stroke actually does solve this problem.
Tested in LV 2011.

By Ctrl-R trick do you simply mean running the VI? That is one way to force a recompile, but if you hold down Ctrl while pressing the run button you can recompile without running. This should not be "dangerous" in any situation.
As you have drawn your example, I see no reason not to use a local in that situation (ok, maybe for vanity). Still, I view the behavior you describe as a bug, and it should certainly be fixed for the benefit of local haters out there. You have to be a little careful where you draw the line between what gets handled in real time and what gets handled only at compile time.

Multiline string color property is too slow, why is console so much quicker?

I have a *vi that I am trying to use to format a multi-line string indicator with colors. The idea is that the data represents network traffic and must be formatted as shown in columns. I realize that there is an upper limit on the horizontal size of the string control of around 2000 characters. The standard console can be 9999 character wide. Second issue is that when I use a property node the iterations take forever to process since I am not able to concurrently apply the formatting to the string as I right them to the string window. I realize that I am using white space as filler and that this is causing a delay but in general this is taking way too long to format. Is there anyway to speed this up and go more than 2000 characters wide? If not is there a simple way to invoke the windows console in Labview and use the format parameter show in the attached *.cpp file?
I have attached the vi along with a sample Dev C++ project showing how fast the console is in comparison when apply colors to large amounts of text data.
Solved!
Go to Solution.
Attachments:
main3.cpp ‏1 KB
Trial_071030.vi ‏236 KB

Ouch! This looks like a literal translation of text code whcih is not al all optimized for dataflow. All these local variables cause extra data copies. Your code constantly needs to switch to the UI thread.
Two ideas:
Defer panel updates while doing all the coloring.
Use shift registers instead of local variables.
Why is your 3D picture set to scale with the panel? How big is your monitor?
Message Edited by altenbach on 10-30-2007 08:23 AM
LabVIEW Champion . Do more with less code and in less time .

Can I use the 'Export Signal Property Node' on a quadrature encoder?

Hi,
So I don't know which counter board I'd be using yet for this (it's used in conjunction with a PCI-6280--the PCI-6280's counter inputs are all taken and so I need another board), but assuming this is possible at all in DAQmx I wouldn't mind knowing whether, say, the PCI-6601 (or any other timer board for that matter) could do this. I'm programming this in LabVIEW 2010 by the way.
I want to have a counter which counts the number of pulses on one channel (I'll call this the 'clock' channel) between when another channel goes from low to high (which I'll call the trigger). It's basically a pulse width measurement, but I only care if there are more than n clock pulses between triggers. I need to have a hardware-timed digital signal which goes from low to high if there are ever more than n pulses between trigger changing state from low to high.
What I am planning to do is this:
Wire 'trigger' to the z-input of the quadrature encoder, and set the z-input value to some arbitrary large value such that, at the quadrature encoder counter task's settings, the counter reaches terminal count in n pulses.
Configure the quadrature encoder counter using DAQmx Export Signal Property Node (tutorial I was looking at is here: http://zone.ni.com/devzone/cda/tut/p/id/5387 ) to toggle a digital channel ('counter event output') from low to high if the counter reaches terminal count (ie, if the encoder reads n pulses).
If the encoder ever reads n pulses on 'clock' between two rising pulses on 'trigger', it sets counter event output high.
Is this possible? Reading through the manual of M series PCI-62xx devices, the index pulse loads the counter with a particular value so it seems like you could conceivably set the counter to the terminal count if you wanted. My only real problem is whether DAQmx Export Signal Property Node works on all counter tasks or just on edge counting tasks.
Thanks in advance for your help. If this isn't possible, I can reply with more details on the problem this is supposed to solve so that you can help me figure out an alternate method.
Solved!
Go to Solution.

There is probably a way to do it, but it it may be easier to use an X-series board for the job. They support a new counter capability for count reset on a digital edge without needing to be configured in encoder position mode. I am not sure exactly how that feature's been implemented however, so maybe it won't make things easier after all.
The plan based on the hoped-for behavior:
1. Configure an X-series counter for pulse generation based on "ticks" of your clock channel.
2. Set both initial delay and low time to the critical # of ticks.
3. Configure for count reset on a digital edge (if possible in pulse generation mode)
4. Configure the count reset value to be the critical # (or possibly 1 less, if possible in pulse generation mode)
5. If you want the output to remain high indefinitely, configure the counter task to use its own output as a
pause trigger, and pause while high.
The way pulse generation works is to preload a # of "low time" ticks into the count register. Then every source edge will decrement the count. When the count reaches terminal count (0), the counter's output is toggled (or can be configured to pulse). The register is then loaded with the # of "high time" ticks and the process continues.
You would be perpetually interrupting the count-down process as long as you got your triggers in time. The count would keep getting reset to the # of low counts, keep decrementing toward 0 without reaching it, and so on. If ever you did reach 0, the output state would toggle high, then the high state would prevent subsequent clock signals from decrementing the count.
You can conceivably do a similar thing with a 6601, but I'm pretty sure you'd need 2 counters working together to get it working.
-Kevin P

Tick colors Property node bug

Similar Messages

Maybe you are looking for