From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
11-02-2021 10:46 AM
11-02-2021 11:47 AM
Bill, when you say this:
"Once the code has been sent to the machine via LabVIEW project"
Machine is the Rpi? or is it the machine where you are programming with Labview?
If it is the machine where you are programming, then do you take the files generated by Labview (.rtexe and .aliases) and transfer them via Rvnc to Rpi?
11-02-2021 12:24 PM
The "machine" I mention is the raspi. You do not need to manually transfer any files to the raspberry pi, that is for extreme cases and not advised for someone just starting out. Like I said, get the program running on there first (use the blink example). Headless operation is not a trivial matter, there are a lot of things that need to be understood in order to make it work reliably.
Here's a commented image of a project window for you -
11-04-2021 12:50 PM
Bill, I have managed to communicate to my Rpi remotely, using RealVNC. Now when I want to connect to the Rpi from the Labview project, I can't do it.
I have used, to try to connect, the same IP that I use in Real VNC.
Do I need a step to connect with Labview?
Thanks
11-04-2021 01:03 PM
It's quite unclear what you have done with the Raspberry Pi. When you install Linx onto it, the Wizard creates in fact a Linux environment inside the Raspbian host. So have you invoked the Linx Wizard for your Raspberry Pi?
Once this has happened you have in fact two Linux based OSes on your Raspi, one is the host OS such as your Raspbian OS and one is the LabVIEW chroot OS that runs as a sort virtual machine on the host OS. This is required since the LabVIEW environment uses a different binary execution format than what your Raspbian host OS uses, despite that both run on an ARM Cortex A architecture.
Only with this LabVIEW chroot properly installed can you connect to the Raspberry Pi from the LabVIEW project.
11-04-2021 04:13 PM
Rolkf, my Rpi is already running headless with a program made in labview. I can also communicate via VNC or HSS, but all this within my LAN.
Following Bill's recommendation, Labview tried to communicate with my Rpi outside of my LAN via RealVNC, which I have not been able to achieve, I have been able to see the Rpi desktop outside of my LAN.
I understand that Bill has been able to get Labview to connect to an Rpi that is outside the LAN to which the PC where Labview is running is connected.
I hope it is understood and thank you, as always.
11-05-2021 04:24 AM
Choke,
OK, I think I misunderstood your original post to me. I have been able using the RealVNC server running on Raspberry Pi to (besides viewing the desktop and running applications there) modify my running LabVIEW code via a number of methods, including changing the contents of ini files that configure my application. @DavidWilt has posted a method in this thread if you actually want to completely update your application or change it (by having a known IP address that the LabVIEW project can use to find the RasPi). Since the LabVIEW application is running on the RasPi (see post by @rolfk in this thread) it is difficult to change the startup.rtexe file and replace it remotely without the LabVIEW project method. I will investigate this further myself as I am involved in a large project involving the need to remotely update the running LabVIEW application on RasPi (among other issues to be resolved) and I will know the answer as soon as time allows.
11-05-2021 05:05 AM
Bill, I haven't tried it on the Raspberry Pi, but generally deleting or overwriting an exe file currently executing is not an option. However one trick I did in the past was to rename it first to a different name. Most OSes seem to allow that and then you can maybe place the new rtexe there. After that you need to do a restart of course.
There are a number of other approaches that could work. NI has embraced the opkg system and has some documents how to create your own .ipk files, which in essence are a lightweight form of .deb files. You could create such a package and then using NI System Control API supposedly install it directly on the target. The whole thing is however still a bit sketchy as they only slowly moved over from their old Component Description Format (cdf) system to the new opkg system as they introduced the NI Linux platform. So if you work with LabVIEW 2021 it might be the only format now, but with earlier versions you had a bit of a salad between the two.
If all else fails you could even try to devise your own method but that would require to hack into the startup scripts of the Linux chroot environment. Placing the new code somewhere, hack the startup script to move it to the final location and change the script back to do nothing. Then kick the restart command.
11-05-2021 05:46 AM
Rolf,
Thanks for sharing the details of NI's 2021 approach to NI Linux and the opkg system. That is an approach that I wasn't aware of.
As far as I current attempts go, the thing I see as an integral part is building the LabVIEW executable for the target without being connected to it. For this I have an identical (more or less) system locally. After building them locally I take the files (startup.rtexe and the startup.aliases), copy them to the remote RasPi into a known location, then open a terminal on the target RasPi using SSH and issue the necessary commands to copy them to the location /home/user/natinst/bin, overwriting the originals. Following that I adjust the file properties as necessary, then reboot the RasPi remotely.
I haven't tried renaming the original executable and alias first, maybe as time allows I will try that.
This has been rather low priority for me at this time as I have other tasks with a higher priority to attend to with my current project at work. I will update this thread with my findings as events unfold.
Bill
11-05-2021 05:58 AM
The Build shouldn't require you to be connected to the target. I do this all the time with cRIOs. Just program and then build the rtexe should simply work, even if not connected. When you try to run a VI interactively or want to deploy it directly from the project you need to be connected to the target of course. But editing VIs and also building an executable by running the Build Specification in the project should also work when you are offline.
Now getting an rtexe installed for the first time is something that requires more work than just placing the rtexe somewhere on the target. So I usually do that from the project which takes care to create the right directories, place the rtexe and other resources in the right location and modify the start scripts to launch the LabVIEW runtime with the rtexe on startup. The rtexe itself isn't really an executable but more like an archive that contains all the VIs in compiled form for your application. It needs to be started as a resource for the real LabVIEW runtime bootstrapper and while it is possible to figure that all out if you really want to, I simply let the LabVIEW project do all these messy things.
But once that has been done and the program has been configured to run on startup, it is very possible to replace the existing rtexe on the target with a new version, kick it in the ass to restart, and the new executable will startup unless you have programmed an error. 😀