Jump to content

Darren

NI
  • Content Count

    591
  • Joined

  • Last visited

  • Days Won

    53

Everything posted by Darren

  1. 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.
  2. 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
  3. 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:
  4. 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.
  5. I've worked a bit with the node and Python 3.9.1 and have had no issues so far.
  6. I checked with LabVIEW R&D, they said there is no way to determine this information in G code.
  7. (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
  8. 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?
  9. Dr. Powell pretty much gave my answer (stated more eloquently ). It's something to look out for when branching wires... by-value data is now a copy, while by-reference still refers to the same thing. Be aware of that when you start mixing by-value and by-reference inside class member data.
  10. Probably best for a new thread, but I'm curious about why you claim it's easier to use git with files with no spaces. In my (admittedly non-advanced) dealings with git I haven't seen any problems with files with spaces. Now repo names with spaces? Yes, that has caused issues. But I've been working with very large codebases in git containing VIs and project libraries/classes with normal naming conventions (including spaces) and have had no issues.
  11. I've been following this thread with interest, I love SC2. Looking forward to seeing what you come up with next.
  12. It's likely referring to an internal discussion forum within NI.
  13. I remember having to figure this out when generating tokens for the LabVIEW Cloud Toolkit for Azure. I remember that there was some weird stuff I had to figure out, but I've long since forgotten how I did it. On the bright side, the toolkit is open source, you can browse through the source code here to see how I did it.
  14. Yup, Quick Drop itself (along with several other G-based LabVIEW features) uses Global Data Get/Set. Standard disclaimers apply (private methods are not documented or supported by NI), but these should get you what you need. I agree with Yair that you need to make sure to namespace your data appropriately so it doesn't potentially collide with other Global Data.
  15. I'm glad that helped. But that also tells us that your installed compiled cache for core LabVIEW was either missing or somehow broken. You may want to consider repairing your LabVIEW 2020 install, or doing a mass compile of the whole LabVIEW folder, to make sure your core compiled object cache is up to date.
  16. Try mass compiling the [LabVIEW 2020]\resource folder? LabVIEW should install the compiled cache for this already, but maybe something got messed up?
  17. I've noticed that too. I think it's because, for whatever reason, different UIs resonate with different people more than others. Of the several I've tried, Fork is the one I prefer. I can say that in the couple of months I've used Fork the UI has made my (admittedly simple) workflows straightforward, to the point that I've never encountered the detached HEAD issue, or any other major issues for that matter. And the authors of Fork provide incredibly responsive tech support as well.
  18. Excellent point. I will propose to NI upper management that we take every single bug fix in the latest LabVIEW version and patch that same fix into every previous LabVIEW version we've ever released. I'll let you know how the proposal goes.
  19. No need to assign ill intent. We screwed that up, and we fixed it in LabVIEW 2020.
  20. Aspiring to be the World's 2nd Fastest LabVIEW Programmer is indeed a noble goal. One of the things that makes me fast is the fact that I know exactly what the first three menu options will be, 100% of the time, whenever I right-click on any data type (terminal or wire) on a diagram. 👍
  21. Here's the relevant NI Forums thread on this topic: https://forums.ni.com/t5/LabVIEW/New-LabVIEW-2019-Feature-Create-Constant-Create-Control-and/td-p/3933878 Come at me, bro.
  22. LabVIEW 2020 Community Edition includes the LINX Toolkit. Do not install LINX from VIPM or anywhere else. I've suggested they edit the Digilent LINX Toolkit description to mention this.
  23. What versions of LabVIEW and the LINX Toolkit are you using/installing?
×
×
  • Create New...

Important Information

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