Cursor: Bring to Center via Property node?

The pop-up menu on the Cursor Legend for graphs includes an item: Bring to Center which moves the active cursor to the center of the plot.
Is this capability available programmatically? An Invoke Node method or Property Node? I would like to have a button on the FP which "retrieves" a free cursor.  I can see complicated ways using Cursor Position and Scale: Range property nodes. I could not find anything as simple as the pop-up menu.
Lynn

Bublina wrote:
It works OK, but I used it and I remember it failed to work for extreme zoom levels (nothing happened)
Do not remember if the inbuilt functionality failed aswell.
Edit: It did
I take the Edit as "it fails as well". At least, it wouldn't surprise me if you meant it differently.
The reason:
Extreme zoom levels usually mean, that both endpoints of the scale do have a very small difference. Since the center is (at least in altenbach's code and i assume that the context menu function works similar) the average of both endpoint values, the difference between endpoint and average cannot be covered by the used numeric representation. So it computes an average, but that equals to one of the endpoints......
So this is rather a "works as expected" issue, even if not very nice and most likely considered a bug by the user (without above explanation).
Norbert
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.

Similar Messages

  • How to read the configuration of a FXP number via property nodes or other methods.

    Hello all,
    I am attempting to store in plain-text the value and configuration specifics of the LV FXP datatype. (please do not suggest I cast it to integer).
    The ini config format does not support FXP. So we'd like to; using property nodes, interrogate the specifics of a FXP numeric control on the FP.
    It appears this is not exposed by control ref's and property nodes.
    Oddly enough, you cannot even interrogate the detailed type of an INT if it is a U8, I8 or I16 etc?! via property nodes, the deepest you can go is 'digital'.
    Specifically, you need to know the following to 'reconstruct' a FXP:
    1. Value
    2. Signed\unsigned
    3. Word length
    4. Integer word length
    Without this, there is a risk of corrupting the value during conversion.i.e we want to load initial FXP from disk at application startup. This is a critical application and we cannot tolerate rounding\conversion errors accumilating with numerous reads\writes of FXP settings.
    It is odd that you cannot interrogate via property nodes the details of a numeric type. ie. you cannot 'discover' via the property node of an INT if it is a U8, I8 or any other type.
    Regards
    Jack Hamilton
    PS: Don't suggest XML either....

    Aristos Queue wrote:
    Alias name here wrote:
    ..second post telling me the 'propertys' of a control have nothing to do with the value is bizzare - via 'properties' for a LV control is the ONLY way to configure the specific type of a numeric...so via the numeric 'property nodes' should\would be able to query it's configuration.
    I do not see any way to set these things through the properties...
    I think he means by right clicking the control on the front panel and configuring with the properties dialog. The properties are exposed there, but not within the property nodes.
    Edit: You beat me.
    CLA, LabVIEW Versions 2010-2013

  • Cursors - bring to center (Labview 8.0 only)

    Bring to center does not bring cursor to center unless scale multipler = 1.0
    if multiplier is 1.0 and your x-scale is 0.0-100.0, then bring to center will set the cursor to 50.0 (correct)
    Waveform graph , graph, properties, scales, multiplier = 2.0 (anything but 1.0) then
    scale will be 0.0 - 200.0 and  "Bring To Center" for that cursor will not consider the scale factor and will put cursor at 50.0 (not in center).
    If your scale multiplier is 0.5 (your graph scale is 0.0-50.0), Bring To Center will set cursor at 50.0 which is at end of graph(not in center).
    Labview Version 6.1 worked fine in this area. Is this a Labview 8.0  bug?

    Hi Ceties,
    Here is an excerpt from LabVIEW help :
    Bring to Center—Centers the cursor on the graph without changing the x- and y-scales. When the cursor mode is Single-Plot or Multi-Plot, this option centers the cursor on the plot on which the cursor is currently positioned and updates the cursor coordinates in the cursor legend. When the cursor mode is Free, this option centers the cursor in the plot area and updates the cursor coordinates in the cursor legend.
    There is no built-in property to directly bring the cursor to center programmatically. However you can use the Cursor Position property to change position of the cursor programmatically.
    Hope this helps,
    Ankita

  • Error 1082 when setting Strings[] property of a menu ring control via property node.

    I've attached a VI in which I attempt to set the Strings[] property of a menu ring control via a property node.  Can anybody figure out what I'm doing wrong here?  I'm using LabView version 7.1.
    Thanks,
    Mark Moss
    Attachments:
    Bug Test.llb ‏69 KB

    Open up your Stations Parameters Control.ctl file and change it from a Strict Type Def. to just an ordinary Type Def. (the pull down menu is located next to the font selector).

  • Populate ENUM RING via Property Node String[]

    Can you populate an ENUM Control using it's Property Node String[] Element? If not, is there a way to do this programmatically? So far I have failed to do this.
    I am Using LV6.1.
    Thanks

    Mr. Kring can probably come up with a much better example, but here's a quick one-off example in LV 6.0.2.
    Download both attached files. Open enum_target.vi, and note that the enum shows only a single choice, "Before". Open Change_enum.vi, and point the file control to the enum_target.vi. Run the Change_enum.vi. The contents of the Enum control in enum_target.vi should have changed to the string array in Change_enum.vi.
    This is a simplistic example, but it should work. Explanations are given on the diagram of Change_enum.vi of how references are pushed around in it.
    Attachments:
    Change_Enum.vi ‏39 KB
    enum_target.vi ‏7 KB

  • Can the cursors in a property node be changed to the LabView 7.X format instead of 8.X?

    I plotted data and used the property node thing to create cursors so that I can select individual data points.  The LabView 7.0 or 7.1 format for the cursors was useful because I could punch in a number and the cursor would then jump to that number.  But with LabView 8.0, this option is apparently no longer available, and I must manually move the cursor to where I want it to go.  This is very time-consuming, and I would like to know if there's a way to revert to the LabView 7.0 format, or change the existing format so that I can tell the cursor where to go by punching in a number.  Any ideas?
    Attachments:
    question 090504.jpg ‏233 KB

    Sorry but no. You are stuck with the 8.0 style cursor option. I find the labview 8.x cursor display ugly and useless. Even my customers are very quick to specify that they do not want Labview 8.x styled cursors. I really miss the 7.1 type cursor display 
    Besides which, my opinion is that Express VIs Carthage must be destroyed deleted
    (Sorry no Labview "brag list" so far)

  • Executing "bring to center" on a free cursor in a log XY graph brings the cursor to the top rim of the graph (instead of the center)

    Dear support,
    dear LV users,
    selecting "bring to center" for a free cursor in a XY graph does not
    bring the cursor into the center of the graph, but instead the command brings it to the
    mean/average value. This is not an issue for a linear mapping
    of the axis [due to the fact that the center of the axis is equal to
    the middle/average value of the end points on the axis]. But when
    mapping of the axis is logarithmic, the cursor ends up on the top of
    the screen. That is because the average value of the end points
    (min(y_axis)+max(y_axis))/2) is not equal to the center of the axis.
    Is that a wished behavior, please?
    Example: For an y_axis = [1..100], the awaited center position would be at
    10 and not at 50.5. The center position for the logarithmic mapping
    should be calculated as (log(min(y_axis))+log(max(y_axis)))/2, IMHO.
    Kind regards,
    Solved!
    Go to Solution.

    You are right, LabVIEW chooses this form (min(y_axis)+max(y_axis))/2).
    You can go to "idea exchange".
    Link:
    http://forums.ni.com/t5/ideas/v2/ideaexchangepage/blog-id/labviewideas
    here you can see how many people like your idea.
    Perhaps it will be considered in the next version of LabVIEW.

  • Linking property nodes to two cursors in one graph

    Hello,
    I have got one graph with 2 cursors. And I need to by able to set the coordinates of each cursor by using property nodes. However, if I click right button mouse button - create - property node - cursor - cursor position - -then there are only 3 possibilities "All elements", "X", Y" which links only to one of the cursors (actually I don`t know which). How is possible to link 2 cursors`s position property nodes to 2 cursors in one graph?
     Thank you a lot for discussion.
    Martin Pekar
    Solved!
    Go to Solution.

    Also, if you have more than a few cursors, you can make the code more scalable by using an array of positions and a FOR loop as follows.
    Now the code automatically adapts th the number of cursors you actually have.
    (Of course all other common sense applies, for example only set this when the position changes. Don't write the same cursor postions with every iteration of the loop over and over. )
    Message Edited by altenbach on 05-06-2009 06:25 AM
    LabVIEW Champion . Do more with less code and in less time .
    Attachments:
    MulticursorII.png ‏4 KB

  • Property nodes are severely affecting performanc​e

    LabVIEW Gurus,
    I am continually running into some serious performance hits using property nodes to update attributes of FP objects. Attached is a classic example.
    I have 8 XY plots that are being fed 600 SGL points every 200 msec - a very modest data rate. Each plot is a dynamically instanciated .vit placed into one of 8 subpanels in a container VI. The container VI also acts as the data server for the charts, sending each one their data in their own single element queue. The entire architecture runs great (~4% CPU load, see attached picture) until I being updating a property node to display the value of the cursor y-value. When I enable the "Caption.Text" property node of the XY Graph to display the cursor value, the CPU usage soars to over 30%.
    As an aside, I am developing on a dual core 2.1GHz platform with 4G memory with LV8.5.1, and the target machine is not nearly as beefy. That's why 30% CPU on my powerhouse is an issue - it basically brings the embedded target to its knees.
    I have included an example VI for you to run on your machine. Consider it "representative" of my bigger issues. The VI runs about 10% CPU without the caption update, and 20% with the caption updates.
    Finally, I have tried putting the VIs into the UI execution system. I have also tried Defer Panel Updates, but this actually slows down performance.
    Best regards,
    Jack Dunaway
     With Captions
    Without Captions:
    Message Edited by mechelecengr on 10-10-2008 11:23 AM
    Message Edited by mechelecengr on 10-10-2008 11:27 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:
    WithCaptions.png ‏102 KB
    WithoutCaptions.png ‏96 KB
    GraphPerformanceProblems.vi ‏23 KB

    Yes, property nodes force synchronous execution and if you do that too often, other things suffer.
    The above solution is good. You can simplify things even more by removing all that unneeded extra code that just complicates things.
    Here's a quick draft. Let me know if you have questions.
    Message Edited by altenbach on 10-10-2008 09:58 AM
    LabVIEW Champion . Do more with less code and in less time .
    Attachments:
    samewithlesscode.png ‏9 KB
    GraphPerformanceProblemsMOD.vi ‏19 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)

  • 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

  • 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 to create a specific property node w/ VI script

    I am writing a VI script to work with some multi column listboxes.  I need it to create a property node that gets a reference to the ItemNames field.  I see that I can create a property node via the invoke node method Create.Property Node, but how to get the ItemNames field specifically I so far can't figure out.  Can anyone help?
    To be clear, I am writing code that looks like this:
    ...and when I run the script, I want it to produce this:
    Right now it produces the MCL as expected, via the New VI Object node...but I don't know how to get the ItemNames created automatcially.  I thought it might be in the PropItems array but so far no luck.
    thank you
    Solved!
    Go to Solution.

    The output of "PropItems[]" will be a one element array.  Index that element and wire the reference to an invoke node.  Select the method "SetProperty".

  • Bring profit center and cost center  hierarchy from R3 to BW in BI 7.0

    Hello,
    I need to get the hierarchy from R/3 to BW. Can someone send me a link or mention steps i need to do to bring profit center and cost center hiearchy from R3 to BW.
    Thanks
    Laura.

    As you would for any other infoobject
    Activate the business content hierarchy datasources on R3 for cost centre and profit centre
    Go into BW - replicate the metadata
    Then just connect via transformations or transfer rules the datasources to yoru infosources or master data objects
    Create an infopackage per hierarchy!!!!! - press the button available hirachies from OLTP - click the one you want on the left - fire it off
    Then repeat new infopackages for all hierachies

  • 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 Champion

    Marc,
    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

Maybe you are looking for