codcoder

I was afraid the answer would be something along the line "just do it properly" The thing is the application does have that feature. It is just that the option to command reboot on system level is so appealing as it works in those cases where the application is non responsive.

Hi, We have a PXI-system with a PXIe-8821 controller running LabVIEW RT (PharLap). On this controller we have a deployed LabVIEW developed application. So all standard so far. From time to time the application ends up in an erroneous state. Since the overall system is relatively complex and used as a development tool for another system, it is tedious to detect and debug each situation that leads to an error. So the current solution is to regularly reboot the controller. Both at a fixed time interval and when the controller is suspected to be in an erroneous state. To achieve this remotely we send a reboot command by spoofing the HTTP POST command sent when clicking on the "restart button" in NI's web based configuration GUI. I was surprised that this worked, but it does, and it does so pretty well. But there is an issue: we have an instrument that can get upset if the reference to it isn't closed down properly. And since this reboot on system level harshly close down our application this has increasingly started to become an issue. So I have two questions: Is there a way to detect that a system reboot is imminent and allowing the LabVIEW application to act on it? Closing down references and such. Is there another way to remotely reboot a controller? I am aware of the built in system vi's but those are more about letting the controller reboot itself. What I'm looking for is a method to remotely force a reboot. Any input is most welcome!

Done!

A heads up though: all PXI modules aren't fully supported. We replaced a PXI controller running Pharlap to one running Linux and there were some issues. The LabVIEW application transferred smoothly if I remember correctly (this was last year, August ish) but we never got one of the modules to fully work. The 6683H timing module I think. And NI was aware of this. We ended up keeping the Pharlap controller. In this application.

Here is a picture of the module in all its glory.

So on a lighter side of everything: was browsing the NI website and discovered that atleast one PXI module has been updated to match the (heavily discussed) new graphical profile: https://www.ni.com/en-us/support/model.pxie-8301.html Cool grey instead of boring beige. Still waiting for a green chassis though. Will NI be offering compatability stickers to allow older modules and cover plates to match the new graphic profile? Will they update older modules? Or will we have to live with mismatched colour combinations for the coming decades? 😜 (posting this in the lounge section instead of hardware for obvious reasons)

Do you have any examples about this you can share? Becuase I tried using NI-Trace -- and perhaps it's about my lack of knowledge about the tool -- but to my understadning what was logged was nothing but the "high level" writes to property nodes and sub-vi's which I did in my top-level vi's. There were no information about the underlying USB communication.

For posterity: I've been in contact with NI Technical Support who confirms that the USB-8451 isn't designed to work with PXI Real Time controllers.

Thanks for quick answers. I was afraid changing hardware would be the answer. Doing that isn't that easy either as the hardware configuration is quite fixed at the moment. My current "temporary" solution is to use a Windows PC connected directly to the USB device running a looped LabVIEW *.vi which constantly writes i2c to the device every second or so. This works. I will look into other neater solutions as soon as I get the time. I promise to post an update here if I figure out anything useful.

Hi, I have a problem here. Hope I can get some help for a solution. The task at-hand is to use an NI USB-8451 to communicate with a device over I2C. This would have been trivial if it wasn’t for the fact that the USB-8451 is connected to a PXI controller running LabVIEW Real-Time OS (Phar Lap ETS) and not a Windows PC. I haven’t chosen the hardware combination personally and the person who did just assumed they would work together. And I did too… I mean, it's NI's eco system! Just download the NI-845x Driver Software from NI’s webpage, install it on my PC and then install whatever software needed on the controller through MAX. Easy right? But no. It wasn't that easy. So I wonder: (1) Has anyone had any success controlling the NI USB-8451 from anything but a Windows PC? And if so… how?? The PXI system finds the USB-8451 and lists is as a USB VISA raw device but the supplied vi’s/drivers cannot be executed on the controller. (2) Since what I want to do is actually very little (just writing a couple of bytes once to the I2C device) I have started to toying with the idea of recording the USB traffic from the Windows laptop somehow via Wireshark and then replaying it on the PXI system… has anyone had any success doing something like that? (3) And finally. If it is impossible to get the USB-8451 to work with my PXI system, is there some other I2C hardware that is known to do? I’m getting the impression that NI only has this USB device apart from implementing the I2C protocol on a dedicated FPGA and that seems a little too much. Sorry for the long post. Getting a little desperate here. Deadline approaching. I'm running LabVIEW 2019 SP1 by the way and the controller is a PXIe-8821 if that makes any difference. BR, E

Couldn't agree more. I also believe NI really need to push LabVIEW more aggressively to the maker community. This is a group of people who adores things that are "free", "open", "lite" and today, LabVIEW simply doesn't make the cut. Of course the coolness factor will still be an issue (a night/dark mode could probably help?) but surely there must be a way to position LabVIEW as a great tool to help creative geniuses to focus less on grit and more on, well, actually creating stuff. I work in the aerospace-defense-industry. With hardware. But we are fewer and fewer who does. The majority of the engineers now are software engineers who either work purely with software or come from that background. To explain to them why NI's offering makes sense is extremely difficult. Of course, for now, what we do is relatively complicated and closely tied to the performance of the hardware. So using NI’s locked-in eco system saves us time and money. But NI’s pyramid is crumbling from the base. At other companies I’ve seen well-made LabVIEW application been ripped out and replaced with “anything” written in Python. Of course it didn’t work any better (quite the opposite), but it was Python and not LabVIEW. And that single argument was strong enough.

Extremely bold. I work in a conservative organisation who uses NI's offerings a lot and I know many collegues who will not take this lightly. And it will probably bug me a little that any future NI hardware we purchase will not visually match current gen. But subjectively I like it. Feels contemporyary. But will it stand the test of time?

I like the side discussion here. About the future of LabVIEW. I've been in the field for close to seven years now and I constantly ponder if relying my carrer on LabVIEW is a wise decision. Because I mean, I'm no junior anymore, and just as much as by chance as by choice LabVIEW has become my speciality now, and changing track is harder and harder for each year. Last year I attended my first NI Week and to judging from NI's marketing it was clear, according to me, that they have moved away from the use case of an engineer/scientist with a benchtop instrument controlled by a Windows PC with LabVIEW. Measuring a voltage or communicate with a IC-circuit or something like that. And I can understand why. That is a solved problem and you can just as easily do it with Python/Arduino/Raspi (everybody knows atleast one scripting language these days). A lot more focus was on (physically) big system wide solutions, mostly for testing within the semiconductor industry and radio/5G. And I guess that makes sense aswell. These are areas where hardware matter and the price point is still quite high. Perhaps their vision is that you will buy a full solution from NI in the future and only use the GUI (LabVIEW) for some small tweaks? So where does that leave full-fledged LabVIEW developers? I don't know. As a career advice I wouldn't recommend anyone who wants to be a pure software developer to go for LabVIEW. But I honestly believe using a high-level tool like LabVIEW has its benefits like allowing you to be a domain expert in the field you are operating in while also allowing you to be a develop the stuff without having to focus too much on grit. And I hope having that combination will still make me employable.

This is simply amazing! Speedy answer, working solution. Thanks enserge! To be clear for anyone with the same problem it is the two steps YScale.ScaleFit=0 and YScale.ScaleFit=2 that does the trick (I guess you force LabVIEW to internally update the chart or something). Will you report this to NI enserge?

Hi guys, I'm trying to programmatically update the names of five plots in a digital waveform graph. The plots are in a particular order which corresponds neatly withe the order in the legend as in the order under the "Plots" tab in the properties window. However when I try to update the Plot.Name property for each plot by stepping through the ActPlot property the order seems to be 1-2-3-4-0, i.e. when I try to change the name of ActPlot=0 it affects the last plot instead of the first. What gives? Is there any other indexing property instead of ActPlot I can use which LabVIEW uses to keep track of the plot order? I'm just updating an old vi so it would be nice if it could be solved without altering the waveform used as an input to the graph.