Jump to content

shoneill

Members
  • Content Count

    850
  • Joined

  • Last visited

  • Days Won

    24

Everything posted by shoneill

  1. I my test (After setting all to disable debugging) User Events are second only to Queues and Notifiers. They're 20% faster than Channel (High Speed Stream). And Notifiers and User Events are very close in performance. Sometimes User Events win, other times Notifiers, depends on which other methods are running concurrently. This is in a VM with only 2 cores.
  2. I would always recommend wiring up the output of the read nodes to an array indicator (outside the sequence so that it has no effect on timing). Compiler optimisations can do weird things when you're not actually wiring up certain outputs. For example, you're not using the data output of the variant but you are of the map. Not saying it explains the differences, but I've seen things like that wildly affect performance in the past. I would look at the code, but I'm currently trying to get 2019 installed in a VM.
  3. shoneill

    Game of Thrones

    I'm an avid GoT fan, but I'm waiting for Season 8 to arrive..... 🀣
  4. Even God appears to agree with Shaun.... Mark 1:34 β€œAnd he healed many who were sick with various diseases, and cast out many demons. And he would not permit the demons to speak, because they knew him.”
  5. No problems. I understood from the previous post you were teaching LabVIEW as opposed to using LabVIEW to teach something else. All clear now. And either way, the community is always ready to help.
  6. Also, I don't mean to be mean, but are you sure you're in the position to create code to teach people LabVIEW? This isn't advanced LabVIEW. If this is the quality of material students will be using to learn LabVIEW it might be best not doing it at all. Again, I'm not being mean, I'm being honest (and if anything I'm being diplomatic). Don't you have access to people who have (a lot) more experience in LabVIEW to help you out?
  7. Your sub-VI does not have a loop. It will run once and once only per Event. If you leave the FP of the sub-VI open, you can click on the boolean when it is not running and it will be applied whenever it is run. If you want your sub-VI to keep running, it also needs a while loop around it(either in the sub-VI itself or ourside). Just make sure you have a stop criterium for the loop. If you go into the properties of the sub-VI you can also set the FP to open when called. This still won't make it keep running, but it will at least make sure the FP is opened.
  8. A picture is not a VI. You say you added a while loop. How? There are still a lot of variables which could go wrong. Post your code or we can't really help.
  9. Something can't be in a peer group and not be in a peer group at the same time. This is how the LV diagram "Group" works. What NI has is a parent-child grouping which is something different. Not saying this couldn't be an interesting idea, just that it's not comparing apples with apples.
  10. On the other hand: What is "too slow". What should "faster" be?
  11. You might want to get in touch with Wiebe for that....
  12. You are setting your offset to 0.001 of a single sample. That's not going to be visible. The top value in your clsuter is your offset (zero X value). The second top value is the time spacing between adjacent data points (not the entire length of the plot). If you need 100 data points before the trigger, try Top: 0.001, Middle 0.00001, Bottom, your data You SHOULD use proper timing data. If your data is recorded at 1MHz, the middle value should be 1/millionth in order to have your X-axis in seconds. Please note this also only changes the DISPLAY of your data, it has nothing to do with the data's ACTUAL position relative to your trigger. You need to set up your acquisition properly in order to guarantee that.
  13. But which bit? Some bits are actually quite tasty..... πŸ₯“
  14. Did not know about that function. Nice.
  15. So your job is to make it as hard as possible for NXG to ever catch up with with LV 20xx? πŸ˜€
  16. It was listed as part of the roadmap, with the added caveat, that such extension would be available only in C#. I certainly remember it being communicated as the way forward with regard to replacing XControls. It was certainly used as a carrot, even if the word "promise" is not accurate. Then at the CAB in Austin some years back, we were told that won't be happening, that the existing control classes won't be extendable. I can't recall exactly who and when, but it was definitely communicated.
  17. Is the existence of XControls one of those bugs?
  18. I'm pretty sure XControls are dead in the water. But I sure hope they are working on an alternative, at least for NXG.
×
×
  • Create New...

Important Information

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