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
Similar Messages
-
Error 1055 occurred at Property node
Generating the error:
"Error 1055 occurred at Property Node in ... Possible reason(s): LabVIEW object reference is invalid."
when I try to wire the IMAGE OUT output from the IMAQdx Snap vi to the value property of an externally referenced image display control.
To describe in more detail, I have a parent vi with an image display control and a child vi which has a control refnum linked to the parent vi display. In the child vi I create a value property for the refnum and try to write images to it, essentially to drive the parent display from the child vi.
The technique works elsewhere, though I can't think of what I could have done differently to generate this error?Hi Mike - looks like I may not need to. I've been working away at this and have found the original cause and something else a bit weird...
I deleted the objects from the sub-VI that was giving me errors, then cut and pasted the objects (image display refnum and value property) from a VI that was working and this solved the problem. So you might think that the issue was just some obscure configuration item, or I'd used the wrong type in my reference or something.
I found the display reference in the parent VI was not even wired to the sub VI - duh! Error between keyboard and chair. So at least the original error message made sense, but I have no idea why it actually worked after pasting in the new objects. Are these references using some sort of auto-magic? Who knows. Safer to wire up my sub-VI's properly methinks.
Sorry for wasting forum time on this one. -
Error -70038 occurred at Property Node in nimc.fb.power.power.coordinate.vi
HI,
I created a Real Time application with debugging enabled that only makes a straight line move and then finds center (using SoftMotion function blocks). When I run the VI from the project everything works fine. When I create the executable and run the application as a start up some times it moves beyond the limit switches and I have to abort the application, it never really works as smooth as it does when ran directly from the project.
I simplified the application. When connecting to the executable ( Operate>>Debug Application or Shared Library...)
I saw that sometimes I was getting an error that said the find center function could not be executed because the driver was not enabled. This was never needed when running from the project. I added the Power SoftMotion block and I enabled the driver before getting into the while loop that finds center. Again the VI ran without errors when ran directly from the project, but when I connected to the executable I found the following error coming out of the Power SoftMotion block (the name of my VI is: "Testing SEND to ZERO by itself.vi"):
"Error -70038 occurred at Property Node in nimc.fb.power.power.coordinate.vi --> Testing SEND to ZERO by itself.vi
Possible reason(s):
Motion: An unexpected error has occurred internal to the driver. Please contact National Instruments with the name of the function or VI that returned this error"
I am using cRIO 9022 as a controller and two 9512s.
LabVIEW 2009
NI-RIO 3.2.1
SoftMotion
Any idea why the VI works fine when ran directly from the project but does not work as expected when ran as a stand alone application directly on the cRIO?
Thanks,
Fab
Certified LabVIEW Architect * Certified Professional Instructor * LabVIEW ChampionMarc,
When I simplified my program, I forgot to put the Power Function block inside a loop and make sure I was sending a pulse for the execute input. I am guessing that could have caused the weird error.
If I see it again, I will let you know.
Thanks,
Fab
Certified LabVIEW Architect * Certified Professional Instructor * LabVIEW Champion -
Error cluster in XControls Property node
Hello!
Property Nodes of XControls do have Error Clusters, but how can I change those out of the Facade? I'm setting an object through a property node for tree data. It is possible that some of the object methods generate an error while executing in the facade and I would like to catch this error in the VI containing my XControl.You can't change the error output from a property node from within the facade since the facade only gets called after the property VI has run and modified the contents of the display state information. If possible try to catch invalid values in the property VI itsefl. If there are errors that the xcontrol will need to report you will need to provide a separate mechanism.
Something that I have used in the past to good effect is the idea of an error stack. The error stack itself is an array of error clusters that resides in the display state data and is maintained as a circular buffer by the xcontrol code. To access this value from the calling program create a read-only property that reads the contents of the buffer and then clears it.
Mike...
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps -
NI 845x USB: Error -301713 occurred at Property Node (arg 2) in General I2C Read.vi
Hello,
I am currently working with digital accelerometer LIS35DE from ST Microelectronics. I want to start with tests of this device. For that purpose I used NI 845x USB to connect with accelerometer via I2C. Unfortunately, when I made electrical connections and set up parameters of communication and run the program (I found it in examples) the following error occured:
Error -301713 occurred at Property Node (arg 2) in General I2C Read.vi
Possible reason(s):
NI-845x: An input parameter, or combination of parameters, is invalid. An example of this error may be setting an invalid baud rate or enabling I2C ACK polling while using 10-bit addressing.
The code can be found in attachements. I couldn't find any extended description of this problem. What could be a problem: incorrect device address, register address, configuration parameters?
Any help is appreciated!
Best regards,
Michael
Attachments:
General I2C Read.vi 24 KBHi MicMac89!
First of all could you please post which version of LabView are you using?
Could you please tell me which version of 845X hw are you using? (8451 or 8452)
I opened the example you attached. As you wrote the error occurs at the second argument of the property node. (I guess this is the first property node where the error occurs.)
This argument of the property node enables the onboard pull-up resistors. But not all NI-845x hardware support pull-up resistors. (Because of this is important to know which hw version are you using.)
Did you try the example with disabling the pull-up resistors?
I suggest you to go through the Manual of this product, (if you did this not yet) This could make it clear where and when to use what kind of pull-up resistors.
For example: If you are using 8452, you must enable pull-up resistors, for Vref ≤ 1.8 V for the FPGA to properly detect a low-to-high transition
Manual: http://www.ni.com/pdf/manuals/371746d.pdf
HW specification: http://www.ni.com/pdf/manuals/290598a.pdf
Please post if my suggestions helped. Of course if you have any questions, don't hesitate to post them.
Best regards,
Balazs Nagy -
Error 1073807202 occurred at Property Node (arg 1) in VISA Configure
I am working with the 30-day evaluation version of LabVIEW
(Version 9.0 32-bit). I am attempting to perform the serial loopback test
described in NI's Developer Zone Tutorial, executing Basic Serial Read and
Write.vi. When I click the Run arrow a dialog box appears with the
following legend:
"Error 1073807202 occurred at Property Node (arg 1) in VISA Configure
Serial Port (Instr).vi>Basic Serial Read and Write.vi. LabVIEW: VISA or
code library could not be located. ...required drive not installed..."
I can find the "smplserl.vi" driver in the /examples folder on my PC.
What's wrong?Did you do a search for that error? Install NI-VISA.
-
I am using a WaveformChart to display multiple traces of data, the number of traces is variable, I use property nodes to set the number of traces and whether the digital display is visible or not, as more data is available the number of traces is increased and the digital displays are made visible. Within the Labview design environment everything works well. However when running the built application if two or more traces are to be charted I see error 1055. I suspect it is related to making the digital display visible on two or more waveform traces. See VI attached.
Why is this error happening ?
Thanks.
Single trace
Two traces
Solved!
Go to Solution.
Attachments:
Setup Plot Style.vi 29 KBWF Charts only create their plots at development time.
If you attempt to access a plot that was never there you get that error.
To work-around this detail, simply size the legend for more plots than you ever expect to use at development time so that the plots are created and availabe when you do the build.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction -
Error 1055 occurred at Property Node, only the FIRST TIME I run the VI
hi !
I'm managing some object properties with 2 subVIs,
so I send to the first one a number and a cluster which contains the objects references, so that it controls the "visible" property depending on the number,
and I send to the second one the previous cluster and an other cluster which contain the objects data, so that it controls the data depending on some parameters.
VI is better than explaination, so find it attached !
at the first time you'll run it, the error occurs, so click "stop" button, and run it again, no error, and you'll understand the way it works.
To fond the error again, just close it completely and re-open it.
(I built an example VI as close as possible to my real VI, and I get the same error, so I attached only the example)
hope you'll understand (if no I can explain better)
thanks a lot.
Attachments:
tests erreurs.zip 57 KByoz'st wrote:
smercurio_fc a écrit :
You have to write to the control/indicator the local variable points to.
sorry but I don't really understand this... (I'm french).
A local variable points to a control or indicator. To "initialize" it you have to write a value to it. Or, you can set the value of the control/indicator to a default value.
I tried to use globals, but the same error occurs...
Of course it will. Because you're not understanding that you have a race condition. http://en.wikipedia.org/wiki/Race_condition -
The VI closed the connection : error 1074360302 at property node(arg 1)
hi!
I'm trying to running a code which apply the control of my myRIO through a VI on my host computer. A video stream of data is also going to be send from myRIO to the Host Computer VI. However, I am getting the "Host Computer VI" closed the connection. I have no idea why.
And at the Host Computer keep giving out error 1074360302 occured at Property Node (arg 1) in myRIO vi.
I would be glad if someone could help me.
Thank you.
Attachments:
Picture1.png 81 KBHi e_pah,
Thanks for your response, what sort of camera are you using? This error has been previously seen with a Stingray camera when the IMAQ drivers aren't quite up to date.
So firstly, we need to make sure the IMAQ drivers are updated.
Further questions regarding your application:
Did this VI ever run?
Does this error occur everytime the VI is run?
What is the the property node doing?
Many thanks
Ingram -
Property node standard error in functionality - odd behavior
I am getting what I would consider unusual behavior from a property node when there is an error on the error cluster input. The Help for the VI indicates this node has Standard Error In functionality, which I interpret as if there is an error on the input then the node does not run and the error is simply passed through to the output.
The behavior I'm getting is that the error gets passed through, but the properties of the node also get passed out with the data that was present the last time the node was called (including when it wasn't this specific node, but a different property node within the same VI that has the same property outputs).
In Psuedo code, this is what I'm doing:
Use Invoke node to call a method from a DLL (which sends a command to a device and gets its response).
Pass the method reference to a property node, which then outputs the properties of the method (the response from the device).
This works fine when everything is as it's supposed to be (device I'm communication to is connected, etc.).
If I disconnect the device completely and then run the VI again, I get the property outputs from the previous communication out of the property node, which are obviously not valid as the device isn't even connected. This happens even if the command I sent to the device is not the same; Command1 is sent and gets valid response, disconnect device, command2 is sent and I get response for command1 from the property node of command2. Command1 and command2 are in different cases of a case structure.
At first I thought there might be an issue with the DLL functionality (and there might be) reporting stale data, but before that is even an option it seems the property node shouldn't even be possible to have data output when the node is supposed to be bypassed entirely when an error is passed in.
Is this supposed to happen? Am I missing something?Coincidentally, this week I ran into what appears to be the same behavior with the Scan from String function, and I thought of this thread. It doesn't help solve your problem, but maybe it's useful to know that this behavior happens in other built-in functions, not just Property Nodes. I started a new thread to look at this more generally.
-
Display Property Node Error 1077
I have created a vi with multiple analog inputs (up to 20), and I want to be able to turn plots on and off on the front panel. I currently have this case structure set up to go through each input (i through N), and the front pannel array (LED buttons) can be turned on and off to choose which plot to display:
Turning the plots on and off work, but I am getting this error message:
Error 1077 occurred at Property Node (arg 1) in NetworkAnalyzer_UpdatedDAQmx.vi
Possible reason(s):
LabVIEW: Invalid property value.
Property Name: Active Plot
Any solutions? Thank you.
Solved!
Go to Solution.Are you sure the number of elements in the Boolean array matches the number of plots you actually have? That error implies that you have more elements in your Boolean array than you have plots.
-
Disabled property node hangs loop
I've got a parser loop, operating on streamed data from a CRIO via UDP. The loop operates at about 90Hz. In response to the user opening a file, the code will use a property node to enable (or disable and gray) a couple of boolean front-panel objects. When these property nodes execute, I see the CPU usage (in Windows task manager) go to close to 100% and coincidentally, the parser loop hangs. Other loops within the same VI continue to run. CPU usage stays at 100% until I force a VI abort.
With a small test-VI, I've noted that these property nodes require roughly 10ms to execute. This seems quite sluggish, but nonetheless, my thoughts are that my code, running at 90Hz, would be able to tolerate a single slip of the loop execution time, particularly because the UDP data is queued.
Any thoughts regarding this property node execution time or suggestions on how to improve the code? Thanks in advance.Mark, thank you for offering to look at a stripped-down version of the code. I just couldn't spare the time required to simplify our complex code. However, I've been working on this problem in the past couple of weeks since I originally posted the question, and have made some progress toward a solution. Although I still do not have a conclusive explanation for the Labview's behavior, I thought I'd follow up with a list of what appears to have made improvements to the code. I'll concede that these suggestions are not definitive, but the problems are not repeatable and without any transparency into Labview's internal behavior, my analysis of the problems and my attempts to find a fix are admittedly speculative in nature. Software development shouldn't be magic, but damn it seems like Labview requires we dance around a black candle. Frustrating. OK, exiting rant mode, here is a list of what NOT to do if you want Labview to be more stable:
-- Do not use frames around your front panel objects. Our main panel has approximately 100 front-panel indicators. In an attempt to make the interface more intuitive, in a recent code revision we grouped the objects using frames. The effect was a sluggish UI and a processor loading that went to close to 85%. I'm aware from posts on this forum that overlapping indicators forces Labview to update all when any is updated. This is an understandable coding contraint. OK, fine, we weren't overlapping any idicators. But for pete's sake, why should the same constraint apply to a purely decorative object like a frame? This strikes me as a fundamental philosophical flaw in LV's coding. Group N objects with a nice frame -- update the objects N-squared times. If this is the result of using a frame, I would have preferred that NI not even offer the option. Bad choice on the part of the Labview coders and bad choice on our part for assuming zero frame impact on performance.
-- Do not use property nodes. We occasionally gray-out front panel objects when appropriate for the state of the software. This appeared to be contributing to Labview's instability. I built a diagnostic routine that measures execution time for the "gray-out and disable" property node. Generally around 8ms, but occasionally as high as 16ms. Good grief. I've got a code loop running at 90Hz. A 16ms hit isn't easy to tolerate or frankly to understand. Particularly when slow execution is the BEST of the consequences -- the worst is that the property node seemed on occasion to precipitate a hung loop.
-- Do not use Labview's built-in queue structure. Our code was originally using queues to hand off packets of data from a UDP-listener loop to a packet-parser. The UDP-listener blocks on UDP reception, shoves the packets into the queue. The packet parser blocks on data available in the queue and subsequently writes the data to file. NI would have you believe, and I did believe for a while, that this is an elegant producer/consumer approach to this problem. When our problem would occur, the UDP-listener continued to put data into the queue, but the packet parser would never retrieve it. Just went off into nowhere, consumed and forgotten by the Great Labview Scheduler in the Sky. The loop would hang, wouldn't respond to the stop button, would require a forced-abort. Subsequently, if we simply restarted the code, we couldn't be assured that the packets retrieved from the queue would be in chronological order. Seemed to be just randomly retrieved. Clearly the failures had corrupted some of the Labview internal data structures that govern the queue operation. We couldn't assure proper behavior unless we shut down and restarted Labview each time the error occurred. The solution was to abandon code elegance in favor of sequential operation -- get rid of the queue, listen for the UDP packet then parse it immediately. No queue handoff. No further parser lock-ups.
I'm not sure what other bombs might be lurking in our code. Our listener and parser code hasn't lately hung, but the problem is starting to move on to other loops. They'll run for hours and then just stop. Dead. Frozen. In the most recent cases, even the abort button won't shut them down. We have to use Windows Task Manager to kill them. I'll admit to harboring some deepening skepticism for any of the more clever and powerful "features" that NI has added to LV. From my perspective, these more powerful features cannot come free of cost -- they must impose some unavoidable computational burden on LV itself, a burden that LV seems unable to handle, with unpleasant consequences. Must we impose a moratorium on Timed Loops? Event structures? To what level of simplicity must I drive our code to ensure stability?
Thanks, everyone, for tolerating my frustration, and for your comments, if you've got any guidance you can offer.
-dave sprinkle -
Hello everybody,
I am using Property Nodes to clear my Charts right at the beginning of the program. The Property Nodes (History) are outside a While-loop.
When I connect a Chart with the counter-variable "i" inside a While-loop, the first point I see in the Chart is (0,1) instead of (0,0). It looks like the Chart misses the first point !
If the Chart is outside the While-loop the Chart displays all points.
Can anyone please explain this behaviour ? How can I solve this problem ?
Thanks,
CesarMake sure you have the error output from the property node connected to
the loop border. Even if the error os not used in the loop, this will
ensure that the property node clears the chart before the loop starts
running.
What is probably happening is the loop start running at the same time
the chart is being cleared, so the first point is also being cleared.
Ed
Message Edited by Ed Dickens on 04-11-2006 09:50 AM
Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
Attachments:
Clear chart before loop.gif 4 KB -
How do I set a methods error out value in an XControl?
I'm working with an XControl and have created several methods. I can see two possible ways to return status when a method is invoked. One is by providing an output parameter in the method (this is my fall back). The other would be to set the error out value of the invoke node from within the facade VI. Is there a way to do this?
From what I've seen in the documentation it appears the facade runs after the method VI, so I don't see how it would be possible to return a value for the method VI to use in it's error out.Steven,
In a nutshell, I created an XControl that on the user interface is just a ring control, but always has '<Other...>' as its last option. If the user selects <Other...> a dialog is presented allowing them to add a new item to the ring.
One of the methods I created is to load the ring strings from an .ini file. This method has input arguments for the .ini file path and section name. If there is an I/O error, say the specified .ini file doesn't exist, I was hoping to be able to return error info to the VI invoking the method via the error out on the invoke node.
- DAD -
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
SorinHi
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
Maybe you are looking for
-
Issue with Apple ID, iPhone, iPad.
Hello all.. I am using two iPhones and an iPad, all with just one Apple ID logged in from. The problem is that now i am giving one iPhone to a cousin and don't know how solve the issue of the same Apple ID, as all my iMessages come on both the device
-
Diffrence between Codec C40 Premium Resolution Option & Multisite MS Option & Dual Display Option
What is the difference between Codec C40 Premium Resolution Option LIC-C40-PR Codec C40 Multisite MS Option LIC-C40-MS Codec C40 Dual Display Option LIC-C40-DD
-
AS3: outputting trace() content to external txt file
the question's in the title. ive got a swf but i've gotta run it on a nokia n800, which means trace() content will be lost and - boy! - do i need it! so how can i set my swf up to output its trace content to an external txt file?
-
Even though my favicon 32 x 32.png is loaded into each page site and added to upload files it often doesn't display, any ideas why?
-
When I download the Icelandic version of Firefox it says: "Downloading Firefox" or "Hlaða niðu Firefox". It is spelled wrong in Icelandic and should be spelled "Hlaða niður Firefox". Can you please fix it?