Jump to content

Yair

Members
  • Posts

    2,869
  • Joined

  • Last visited

  • Days Won

    44

Posts posted by Yair

  1. I don't know the actualy answer, but I can say that in the past booleans were actually kept in a single bit and this was changed (presumably with LV 5, which would have been some time before LV FPGA came out). If you right click certain data conversion nodes (such a type cast and unflatten), you can tell them that your data is in 4.x format.

    Pure guess - maybe this was done because of alignment and performance issues (i.e. everything else uses at least a byte)?

  2. You're doing something in your application to try to open the front panel of this VI

    I have seen something like this in VIs where I call a C++ DLL even if I don't do anything at all with the front panel (these were VIs which were generated by the automatic DLL wrapper VIs tool which ships with LV). Forcing the VIs to include the FP in the build did stop this from happening and I never investigated further. I saw it in LV 8.6.

  3. Hmm, I stand corrected. The Tick Count (ms) primitive seems to be returning 1 ms increments to me. Has it always been like this? I swear I used to see granularity in the return value...

    As said, tick count has always returned ms resolution. Get date/time used to have a lower resolution (in XP), so it would only update once every ~16 ms, but that has changed with either Vista or 7, presumably because MS stopped relying on old functions they had to rely on up to that point.

  4. Of course this is only after LV10 when they fixed an annoying bug which affected the combination of variants and feedback nodes (like they went out of their way to target two of my favorite things).

    Ugh, don't remind me of that. I based a low-level widely used component on this combination and I stress tested it before I started writing the relevant application to make sure it performs well, and it did. Fast forward to a couple of months later, when I test the app and lo and behold, this performs really badly. For a while, I thought that maybe my original tests were flawed (or worse, imagined). It took some debugging to understand that the bug only manifests itself with a particular combination which wasn't there when I ran the tests (I think it was if you use the initializer terminal to globally initialize the variant, so I ended up initializing it using a first call and select primitive).

  5. I haven't looked at the code too closely, but here are some quick comments:

    1. You don't stop the VIs cleanly when they are in a subpanel. I don't like the Abort VI/Close FP method. How about creating a stop user event in ViewComponent:init.vi and then triggering it in ViewComponent:stop.vi? I haven't worked through all the potential race conditions, and it would require the view VI to be more complex, but it seems cleaner.
    2. Instead of entering the SP names in the init VI, how about moving this code out to the view VI and then simply give the start VI an array of VCs and a parallel array of SP references? Again, this would complicate the view VI, but it would make the code safer and more readable.
    3. This reminds me of what we played with here, although there it was inheritance - http://forums.ni.com/t5/LabVIEW/An-experiment-in-creating-compositable-user-interfaces-for/m-p/1262378#M529154
      Note that AQ's implementation there is considerably more complex than what you probably need here. My code there is more in line with this, but it does automatic ordering of the front panel, which is probably not what you want.

  6. I'm not sure what updates you want to make, but it's certainly possible to use VI server to obtain a reference to the CLF node and then change its configuration according to what you want. Here's one way:

    1. Enable scripting access.
    2. Create a VI that goes over a directory of VIs and opens a reference to each.
    3. For each VI, use the traversal VI in vi.lib (I think it's in Utility\traverseref.llb) to get all the CLFNs in the VI (presumably there's only one in each).
    4. Cast the reference down to the correct class and use the relevant properties.
    5. Call the Save method on the VI.

  7. I haven't looked at the code, but this is a relevant general point in LV and refers to crossrulz's post - references in LV are "owned" by the hierarchy they were created in. The hierarchy is determined by the top level VI. So, if you're opening references, you will want to call the VI opening the reference from a hierarchy which will stay in memory.

    Error 1 means invalid input, which usually refers to the reference in something like this, since it's the only input which can have invalid values, so it makes sense that this is your problem.

  8. You can't capture the event (at least not with G code). You can use the input VIs to detect the scroll (one of the outputs should give a relative position of the wheel), but that would require you to poll it (and then you can create an event there). Since you're talking about an XControl, you would probably want to look at this -

    There is an idea for this in the IE - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-a-quot-Mouse-Scroll-quot-event/idi-p/921547

  9. I don't use LV real-time, but my understanding was that anything that has to do with the UI doesn't work in those targets.

    You could try using the picture control VIs to generate the graph there (if they work in RT) or you could simply save the raw data and then transfer it to a computer.

  10. Chinese people are apparently very superstitious and the sound "4" ...

    Exactly. One thing I like here is that 23 is missing as well. I guess that after 13 it was just easier to keep going like that? ;)

    I also heard that on her fourth pregnancy a Chinese woman would automatically have twins, but I'm not too sure about that one...

    How many Chinese women (in China) get to a fourth pregnancy?

  11. That's because LV recompiles the machine code in certain cases (such as changing the way you move data through the VI) and the machine code is saved inside VIs. One way of handling this in 2010 and later is setting the separate compiled code check box in each VI's properties, but I understand that sometimes has bug-producing behavior.

    You're probably also going to want to read this - https://decibel.ni.com/content/blogs/Matthew.Kelton/2011/09/30/labview-and-versionsource-code-control--introduction

  12. index.php?app=core&module=attach&section=attach&attach_rel_module=post&attach_id=6273

    One additional comment: I'm personally not a fan of providing the name of something in more than one place. If ignoring controls on the front panel is common (and I'm guessing it actually isn't very common), then I would prefer if the template included a for loop which iterates over every control reference given to it and extracts its Label.Text property to use as the filtering array.

    Of course, since the default is to have no control, this code could be in a disable structure, or you could feed it one of the built-in controls, which I assume is meaningless, since it filters them anyway.

  13. If the framework only runs the page VIs when they are put into the SP (and I'm assuming that's the case), then maybe you can try a trick - I'm assuming the Page Ready Notifier you send at the end of the Setup state tells the framework that you're done and you're ready to put the VI into the SP. What if before you do that, you open the FP (maybe hidden), then register the event, then close the FP again and only then send the notification?

    • Like 1
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.