Neil Pate Posted July 21, 2020 Report Share Posted July 21, 2020 Urgh, I am working on a new framework for RT and LabVIEW has gotten itself so confused. I am getting really weird things when I try and duplicate some of my (homegrown) actor classes. LabVIEW is searching for some of the RT utilities in totally the wrong directory. I have tried mass compiling and often that just crashes, but I did manage to get this log message: Search failed to find "NI_Real-Time Target Support.lvlib:RT Get CPU Loads.vi" previously from "<vilib>:\Utility\RT Get CPU Loads.vi" +=+ Caller: "System Status Actor.lvclass:Update.vi" Now, this library does not exist at that directory, rather there is another vi.lib in Targets\NI\RT and it lives in that vi.lib directory Now I am kinda stuck... My code runs sort of ok. Sometimes it just refuses to run on the cRIO (but I have seen this behaviour with RT for years now so just gotten used to it) but I cannot mass compile it or it just crashes. I have tried resetting the class mutation history but his also crashes LabVIEW 😞 Any ideas what I can try? This is a real pain. I do of-course have my history in git, but I don't really feel like trying to step back in time and figuring out what the heck actually happened. Quote Link to comment
PiDi Posted July 21, 2020 Report Share Posted July 21, 2020 Those RT utility VIs get broken whenever you try to open code in My Computer project context instead of RT. On which target do you develop your framework? Do you have any shared code between PC and RT? If yes - try to get rid of it. Quote Link to comment
Neil Pate Posted July 21, 2020 Author Report Share Posted July 21, 2020 20 minutes ago, PiDi said: Those RT utility VIs get broken whenever you try to open code in My Computer project context instead of RT. On which target do you develop your framework? Do you have any shared code between PC and RT? If yes - try to get rid of it. Currently the only code I have in the My Computer bit is the helper stuff I have to reset the class mutation history. I did not think I could run that from the RT context. It is so weird as I have VIs that have nothing to do with the RT Load VI that want to try and load them when I save them. Like somehow it might be in the mutation history (which it might be as I did clone an actor that had some stuff like that). Quote Link to comment
Neil Pate Posted July 21, 2020 Author Report Share Posted July 21, 2020 Seriously hate the class mutation history. What a terrible feature. Quote Link to comment
hooovahh Posted July 23, 2020 Report Share Posted July 23, 2020 Just anecdotally I'd say my 2020 RT is more stable than 2017 and 2018. I do use a couple RT utility VIs, but I have separate projects for the Windows Only and the RT Only portion. In the past I had issues with opening things in the other context causing problems and long recompile times. With two separate projects there is no code under the other target. Quote Link to comment
MarkCG Posted July 23, 2020 Report Share Posted July 23, 2020 I have seen this too -- looking for RT Get CPU loads.vi in the wrong place, breaking the VI. Not sure how LabVIEW gets into that state but it's been a bug for years. Deleting all RT utility VIs in your code, then adding them again seemed to fix it. 1 Quote Link to comment
Neil Pate Posted July 23, 2020 Author Report Share Posted July 23, 2020 1 minute ago, MarkCG said: I have seen this too -- looking for RT Get CPU loads.vi in the wrong place, breaking the VI. Not sure how LabVIEW gets into that state but it's been a bug for years. Deleting all RT utility VIs in your code, then adding them again seemed to fix it. I am about to reimplement my System Status actor from scratch. This time though though I am staying far away from the RT Get CPU Load and am going to try and read it using the linux command line (maybe "top" or similar). Urgh... Quote Link to comment
Rolf Kalbermatter Posted August 27, 2020 Report Share Posted August 27, 2020 On 7/23/2020 at 8:50 PM, Neil Pate said: I am about to reimplement my System Status actor from scratch. This time though though I am staying far away from the RT Get CPU Load and am going to try and read it using the linux command line (maybe "top" or similar). Urgh... Actually, I'm using the System Configuration API instead. Aside from the nisysconfig.lvlib:Initialize Session.vi and nisysconfig.lvlib:Create Filter.vi and nisysconfig.lvlib:Find Hardware.vi everything is directly accessed using property nodes from the SysConfig API shared library driver and there is very little on the LabVIEW level that can be wrongly linked to. Quote Link to comment
Neil Pate Posted August 27, 2020 Author Report Share Posted August 27, 2020 (edited) Yes I probably should have used that. Instead it was not too tricky to just read it from the OS directly (at least the easy ones like memory and disk usage) Edited August 27, 2020 by Neil Pate Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.