Unicode property nodes

Hi,
I'm struggling with the implementation of Unicode in an application.
The main issue holding me back is:
Although I have added UseUnicode=True to my LabVIEW.ini (currently using LV2011 SP1) I cannot create the necessary property nodes such as "BoolText.InterpAsUnicode".
I have checked the display Vi scripting in the vi server options and restarted LabVIEW to no avail.
Does anyone know what this is about?
Regards Florian
Solved!
Go to Solution.

Hi Eden,
thanks for the interest.
I've contacted local NI support about the LabVIEW 2012 issue and they said they would escalate it to the developers. That was almost a month ago - maybe they're working on it, I haven't heard from them since then. I just wrote them an e-mail asking for progress or a way to track progress on the issue.
Here is the short version of my problem:
In some of my projects I can no longer create installer builds to distribute my applications. The error message says the preview failed, and indeed creating a preview of the exe required for the installer fails (although creating the preview by pressing the preview button in the exe built works ONCE after a restart of LabVIEW 2012 and after that fails every time - weird).
The error message for the preview says it can't find certain files like "Clear Errors.vi" or "Get Text Rect.vi". The nonsensical path where LV looks for these files reads "C:\Program Files (x86)\utilitySD\build\2012\Core\LVEnglish\vi.lib\Utility\error.llb\".
I tried everything local support could advise (even if I had already tried that myself): Repair LV installation, mass compile, check LV lookup folders in the options...
When nothing worked they sent it to the devs.
Regards
Florian

Similar Messages

What is difference between local variable and property node ?

What is difference between local variable and property node ?
" 一天到晚游泳的鱼"
[email protected]
我的个人网站：LabVIEW——北方客栈 http://www.labview365.com
欢迎加入《LabVIEW编程思想》组——http://decibel.ni.com/content/groups/thinking-in-labview

To make things clear, here are two small examples that show how nasty locals and value properties can be to the naive programmer.
- Open the diagram of the race condition.vi before running it and try to predict what will be the values of the two counters after the third run.
- Use the Compare Locals Properties and Wires.vi to find out how slow locals and value properties can be (times 1000+).
This being demonstrated, I must add that I use globals and value properties quite often, because they are often very convenient
Chilly Charly (aka CC)
E-List Master - Kudos glutton - Press the yellow button on the left...
Attachments:
Race condition.vi ‏9 KB
Compare Locals Properties and Wires.vi ‏18 KB

Is there a way to reference the property node value of a control in another VI?

Let's say that I have a situation like the one shown in the attached image.
I have an interlock system which is basically a bunch of booleans
If for example the "RF Enable" button in the "interlock VI" is true, then I should be able to flick the ON switch in my other VI (in the back), but if the value is FALSE, then it shouldn't allow it.
In other words, how do I check the value of a control across 2 separate VIs (running simultaneously)?
Thanks!!
Attachments:
sample.jpg ‏295 KB

Is one VI launched by the other, or are they launched independently? If it's the former then you just need to pass the control reference to the subVI via terminal node. If it's the latter there are a variety of ways to handle this:
Use a global variable - somewhat "sloppy" as it requires a global variable, and can lead to race conditions. In the "Interlock" VI you just set the value of the global variable when you change the value of the Boolean. In the other you're just reading it.
Action Engine - Ben wrote a Community Nugget a while back. Similar concept to a global variable.
Queue - The "Interlock" VI simply pops an element onto the queue with the value. The other VI just monitors the queue for a new element. It just needs to have something like a shift register to keep track of the last state.
Use the VI Server to access the controls of the "Interlock" VI. You can do this by accessing the "Interlock" VI's pane and get the control references. With the control reference you just need to get the value with a property node.
... (I'll let others chime in)

Is it better to use Invoke nodes or property nodes to set/get control values?

I have a series of VI's that run in parallel, each to manage different functions- pumping, sensing, a fluid flow model, an experiment generator/runner.
These need to exchange data, which I am currently doing using invoke nodes (that are all in subVIs), using methods "Set control value" and "Get control value". I find that every now and then (perhaps 1% of the time) the data isn't exchanged correctly and therefore the system doesn't work. I can imagine how "set" could go wrong if they happen simultaneously, and can devise ways of preventing this. However, the "Get" method suffers from the same problem. This is a major problem, because I want to leave it running for several hours.
I could in
principle achieve the same thing using property nodes and find myself wondering if this might be more reliable. But I don't want to change over only to find it makes no difference!
Can anyone advise?

You can use some kind of syncronization such as queues, occurances, or notifiers but I think the easiest way would be to create and action engine. This was only one action can execute at a time avoiding a "race condition". Possibly a write action and a read action might help. You also can add queues or notifiers into this concept. hope this helps.
BJD1613
Lead Test Tools Development Engineer
Philips Respironics
Certified LV Architect / Instructor

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.

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 KB

Hi 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.

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.

How to show/hide sliders on a slider control using property nodes?

If I have a slider with multiple sliders on it how do I change which sliders are visible using property nodes? The only property I have found is making the entire control to be visible or not. This is a possible solution to have two different controls, one slider with only one slider and another slider with two sliders overlapped, but not desirable.
I found on a thread in the forum that it is possible but the user did not provide any specifics about which property it was. (http://forums.ni.com/ni/board/message?board.id=170&message.id=181279&query.id=34404#M181279)
I would appreciate an example VI if possible (Preferred version is 8.5 but versios 8.2, 8.0, and 8.6 are available to me).
Thank you in advance for the help,
Aaron

Just make them transparent! Here's a quick draft.
LabVIEW Champion . Do more with less code and in less time .
Attachments:
HideSliders.vi ‏20 KB

How to use Property nodes?

Hi everyone,
I am a beginner of LabVIEW. So I want to know about Property Node in detail. Please Please someone help me know the function of each property node......
Thank You in Advance,
Solved!
Go to Solution.

Achuthaperumal wrote:
I am a beginner of LabVIEW. So I want to know about Property Node in detail.
Property node allows you to programmatically read/write that particular property of associated object. For example, say you have a String Control, and you want to modify its 'Display Style'... for that you need to create and use that particular property node (of the String control).
Check the attached example.
I am not allergic to Kudos, in fact I love Kudos.
Make your LabVIEW experience more CONVENIENT.
Attachments:
Example - Using Property Node [LV 2009].vi ‏11 KB

How do I use the Index Values property node with a multidimensional array.

I am using a 2D array to store operator inputs on my front panel. I only want to display one element to the operator at a time. I am trying to use the Index Values property node to change the displayed element. However, I can only get the Rows index to work. How do I direct the Columns index as well? The help says to use one per dimension. I need clarification on what this is talking about. I've tried adding a second element to the property node, 2 seperate property nodes, and diferent wiring techniques. (series, parallel)

If you only wire up one of the inputs (col or row) what you get out is a 1D array of either the column or row. If you wire controls to both, then you will get one element out of the array. Getting a single element in a 2D array requires you to specify both a row and column.
Message Edited by Dennis Knutson on 02-08-2007 08:34 AM
Attachments:
Index 2D Array.PNG ‏2 KB

How can I make a "property node" for a VI?

Hello!
If I add a boolean button on the FP then I am able to make a property node for that button in the Block Diagram. But how can I make a property node for a VI? I have several VI:s an that together is one program. What I need to do is to verify what kind of VI some of my VI:s is. I need to verify if it is .exe or .vi-file, and if it is .exe then I want to disable run, abort, run continuously bottons otherwise not. I have hard that this is possible to do programmaticaly but I can´t figure out how. I am aware that I could do that manually in the File->vi properties->customize->windows appearance but theese choises makes it last forever.
I want to be able to stop and run and everything if it is a .vi file, but if it is .exe-file then all those buttons should be disabled.
Anyone have an example on this?
In an other message at this Forum I read "You can use the `Front Panel Window. Allow Runtime PopUp`" property to disable run-time shortcuts menues programmaticaly, but still I dont know how to create this property node.
/Amir

You really shouldn't open a new thread. If you don't understand something, ask and we will explain it.
Like I said in the other thread, you can check if you are running in LV or an EXE by using the Application>>Kind property. To get it, place a property node (from the Application Control palette) on the diagram, click it and find the property.
To set the properties for the VI, place another property node, right click it and select Select Class>>VI Server>>VI. You should have the properties you want under Front Panel Window.
To learn more about LabVIEW, I suggest you try searching this site and google for LabVIEW tutorials. Here and here are a couple you can start with. You can also contact your local NI office and join one of their courses.
In addition, I suggest you read the LabVIEW style guide and the LabVIEW user manual (Help>>Search the LabVIEW Bookshelf). I believe chapter 17 of the user manual explains about programmatic control of VIs.
Try to take over the world!

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

How can I change the precision of a numeric array indicator using property nodes ?

I want to change the precision of a numeric array indicator programatically using property nodes. I tried to see all the array properties but I couldn't find it. URGENT !!!

If you want to change the precision of an element in an array you must first get the reference to the array element. Then raise the reference to the more specific class of a digital numeric. Use a property node connected to that reference to set the precision. See the attached vi for an example.
Brian
Attachments:
ArrayElementPrec.vi ‏27 KB

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

Unicode property nodes

Similar Messages

Maybe you are looking for