Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Darren last won the day on November 13 2021

Darren had the most liked content!


About Darren

  • Birthday 10/02/1977

Profile Information

  • Gender
  • Location
    Austin, TX

Contact Methods

LabVIEW Information

  • Version
    LabVIEW 2020
  • Since

Recent Profile Visitors

4,357 profile views

Darren's Achievements

  1. It calls a private internal method, yeah. NI policy is that VIs that call private properties/methods/events are password-protected.
  2. There's also the Create NI GUID.vi in LabVIEW 2020 and later.
  3. For DQMH, the term "singleton" means that the Main VI of the module is non-reentrant. A "cloneable" module has a reentrant Main VI. So if you have a reentrant instance running (of Power and IG), then that instance will also need its own associated reentrant instance of PS class.
  4. From your description it sounds like the PS Class module has to be cloneable. Otherwise all Power and IG instances would be sharing the same singleton instance of PS Class, which I'm guessing is not what you're going for.
  5. Individual apps have to include long path support in order for this setting to have any effect. And LabVIEW 20xx currently has not added this support. Please kudo this idea (if you haven't already) to increase the visibility of the feature request with LabVIEW R&D.
  6. FYI to anyone using Bean's VIs. I was successfully using them in an application, but they had a peculiar side effect. Whenever another application on the system (G-Force) was in full-screen mode, the LabVIEW application windows were non-responsive to mouse clicks. If I switched G-Force out of full-screen mode, the LabVIEW windows started behaving properly again. It took me a while, but I figured out that in order to fix the issue, I needed to add another call to 'AttachThreadInput' at the end of Bean's code IF AttachThreadInput had been called earlier. In Bean's code, the 'fAttach' parameter is set to '1' to attach the thread. If you do this, you then need to call AttachThreadInput again at the end of the code, but with an 'fAttach' value of '0' to detach the thread. When I made this change, my application remained responsive to mouse clicks even when G-Force was in full-screen mode.
  7. Do you see similar results when running the benchmarks separately, i.e. one at a time in separate VIs as opposed to in parallel in the same VI?
  8. Hmm, I should have actually looked at the Help before doing that... our tech writer kindly pointed out that Visible Items > Error Explanation Text is already present in the Error Ring help.
  9. I updated the Bug report to mention that this should be in the help. Also, I talk a lot about use cases for the Error Ring (including mentioning several of the points I brought up in this post) in my What To Expect When You're Expecting an Error presentation here: http://bit.ly/dnatterrors
  10. I have reported the documentation issues (both the 'page not found' error, and the suggestion about placing error rings in case structures) to R&D as Bug 1413653. Don't forget you can deselect Visible Items > Error Explanation Text if you need your Error Rings to be more compact:
  11. During code reviews I always tell people to remove 'No Error' error rings and replace them with error cluster constants. As for non-0 Error Rings, they should always be in a case structure that only executes in the situation where you need that Error Ring value.
  12. I've worked a bit with the node and Python 3.9.1 and have had no issues so far.
  13. I checked with LabVIEW R&D, they said there is no way to determine this information in G code.
  14. (I'm not at a machine with LabVIEW at the moment, so I apologize if I'm not remembering some of this correctly) I see that the static VI reference in your screenshot does not have the little orange star in the corner, which means it's not a strict reference. If you were to wire that reference into a Call By Reference function, you wouldn't see a connector pane pattern. So as your diagram is currently implemented, the types of those wires are identical since the static VI reference wire doesn't contain any type info. Isn't that right? Can you right-click the static VI reference and select something like "Include Data Type"?
  15. Are you talking about inspecting the data type of the two wires with the blue arrows to discern which one is strict and which one is not? Or are you asking for something else?
  • Create New...

Important Information

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