Jump to content

Michael Aivaliotis

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Michael Aivaliotis

  1. All the videos for VIWeek are live: https://labviewwiki.org/wiki/VIWeek
  2. So just adding info here for future googlers. There is an NI KB article on how to cleanup the cache here: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019KdtSAE&l=en-US In there it also mentions an ini token that eliminates cache creation completely:
  3. Right, if running LV community, you have everything you need. No need to install anything from VIPM. In fact it will make it worse. The reason why the log message states Raspberry Pi 2 B (I stated elsewhere), is because the LINX toolkit has an old hardcoded message internally that does not trigger off the actual board model. @Darren, this should be fixed becasue it's confusing.
  4. What is the goal of the communications? Is this a DUT? Or are you just wanting to know when windows is on battery?
  5. Well it kinda does apply to both considering NIPM should manage both CG and NXG. I've heard through a reliable source that NI is seriously intent in solving this problem in NIPM for both CG and NXG.
  6. Well, you could plug your computer directly into the raspi port, no router needed. Or purchase a cheap usb to ethernet dongle and add an extra port to your PC. This is what I do for my cRIO work. https://www.amazon.com/dp/B00M77HMU0/ref=cm_sw_r_tw_dp_U_x_AJJUEb7TVD7CS
  7. Was this developed for a customer, with the understanding that you would make it open-source? If it was done under a "work for hire" agreement then there might be a problem of ownership.
  8. The keys can be any type. A for loop will do it easily: Watch this presentation by @altenbach :
  9. I've been able to connect and deploy code over wifi. However, I can't use the DNS name over wifi so I use the IP address. I'm sure there's a way to get that working but haven't needed to figure it out yet.
  10. Curious, does this change your choice in using them or is it purely academic?
  11. My understanding is that Maps are the same as variant attributes. Except with maps, obviously you don't have the overhead of VariantToData or DataToVariant, when inserting data or looking up data. That can be a huge overhead in some cases. Plus you need support code to prevent variant conversion errors when using the wrong typecast. Variant attributes are slightly more powerful than Maps because you can insert any type. However, one could argue that this is a characteristic that leads to messy designs. The same variant wire could contain mixed values types within it. Each with its' own type conversion VIs. I think if you've been using variant attributes and it works for you, I don't think you need to rewrite everything. But they definitely need to be considered in new designs. Because you don't have the overhead of creating all the glue VIs for the data conversion, they are frictionless to use and start using out of the box.
  12. Lack of NIWeek content has prompted @Steve Watts, to start VIWeek. See his post here: https://forums.ni.com/t5/Random-Ramblings-on-LabVIEW/VIWeek-Making-Trouble-Again/ba-p/4044162 LabVIEWWiki Page.
  13. @Rolf Kalbermatter, PM me your address and I will send some your way.
  14. Inconsistent to a post i made 10 years ago? Besides, that was related to CG. I'm not advocating for removing an engrained CG feature. I thought we were discussing NXG. My assumption is this feature hasn't even beed implemented in NXG. There is a lot more work required in NXG to make it even barely usable. Lack of continuous run is not a problem in NXG. Lack of everything, is a problem.
  15. I can live without it. On the level of priorities for NXG, this has to be the least important. Just drop the vi on the diagram and wrap a while loop.
  16. Oh, so it selectively only works for clusters then. Well at least NXG is consistently inconsistent.
  17. So I took a look at the code that pulls the device info and ya, my assumption was correct. Actually, not sure why they are even reporting on the model type. It should just return the generic type. Like Raspberry Pi. No need to report the exact model, since you will always be wrong and really, it doesn't matter.
  • Create New...

Important Information

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