Jump to content

Recommended Posts

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

image.png.aef58560c4333ffbd640da20f61feca5.png

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.

 

Link to post
Share on other sites

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.

Link to post
Share on other sites
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).

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

  • Thanks 1
Link to post
Share on other sites
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...

Link to post
Share on other sites
  • 1 month later...
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.

Link to post
Share on other sites
Posted (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)

image.png.e311dcc55cd6140ac5baa7fbc186430a.png

image.png.76b3cb3a4859182e37e52dc500e1f0ad.png

Edited by Neil Pate
Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

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