Michael Aivaliotis

I guess nI needs to update that article. 😉

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:

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.

What is the goal of the communications? Is this a DUT? Or are you just wanting to know when windows is on battery?

Yes, I discovered that recently and am using that technique as well.

Send an email to: jim.kring@jki.net

Well. yes. It does. That's what the built-in wifi is for. 🙂

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.

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

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.

The keys can be any type. A for loop will do it easily: Watch this presentation by @altenbach :

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.

Curious, does this change your choice in using them or is it purely academic?

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.

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.

@Rolf Kalbermatter, PM me your address and I will send some your way.

i watched the video. Yikes, ya, that's pure garbage.

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.

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.

I can't live without them.

Oh, so it selectively only works for clusters then. Well at least NXG is consistently inconsistent.

So I guess NXG doesn't support dot notation unbundling.

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.

I have the same board. This is what I did. Download the RaspBerry Pi Imager v1.2 and used that to format a microSD card used for the Raspi. Select the first recommended OS: Raspbian Boot up the Pi with keyboard and mouse. Walk through the startup config (installing updates, etc) and wifi setup. When asked to enter a new password, ignore this and just click next. Reboot as suggested. Go to RaspBerry Pi configuration and on the Interfaces tab, enable SSH Open a command prompt on raspi and type: sudo raspi-config Select 7: Advanced Select A1: Expand file system. (this will expand the file system if it's not already expanded) Reboot In LabVIEW select from the Tools > MakerHub > LINX > LINX Target Configuration Click the connection button and it should connect. Hostname: raspberrypi, username: pi, password: raspberrypi. These are all the defaults. Click the Installation button. Click the Update button on the installation page. it should go through the process of doing the update. At some point the raspi will reboot. this is part of the process. When the raspi reboots, the LINX target configuration dialog will lose connection and give an error. This is normal. it will take a while to reconnect. Eventually, it should come back. If not then click the Connection button and try to connect. The Installation panel should now show the installed version: Click on Launch Example. In LabVIEW, right-click on the Raspberry Pi Target and select connect. This should should show the deployment progress dialog and after connection a small green indicator will appear in the target tree You should be able to execute (run) the VI now. Everything should be good to go now. Sometimes you will try to connect, in the project, and then you will get an error not connecting. If that happens, just wait and try again. I find that the connection is more reliable if you use the IP address of the raspi instead of the DNS name. To specify an IP address, right-click on the Raspberry Pi target and select Disconnect. Then right-click again and select properties. In General, enter the IP address of the raspi. Then click OK. To find the IP address of the raspi, type: hostname -I in a raspi command prompt. I think the reason why the log message states Raspberry Pi 2 B, is because the LINX toolkit is old and that message was probably not updated to handle all the new boards that have come out since release? Not sure. i'm getting the same message on my system even though the board is Pi3.

Considering development was started years before even the CABs were a thing. i'd say too much money. For a product that is not used by the majority of veteran developers, this is a problem. This is similar to the Star Wars franchise that was taken over by Disney. They decided to move forward with new characters and stories and burn the past. I'm hopeful that this will still evolve and improve over time. ...while I'm still alive.