8 replies to this topic

[Daklu]

I have a cRIO project that uses shared variables to transfer fp control states to the RT engine. The shared variable library is located under the RT target. Whenever I transfer the project source code to a different computer the shared variables used in the UI Main (under My Computer target) break, and I get errors stating the shared variables are not linked.



I suspect I'm misusing them somehow. Can anyone explain this behavior?


[Edit - The broken variables are actually digital I/O signals exposed via NI's Scan Engine. They are all related to one specific module; none of the other modules have this problem. I think these are the only Scan Engine variables that are used in the UI. Are Scan Engine variables supposed to be used only on the RT target? Is it "bad" to use them on a pc target?]

-----------------

I don't think this is directly related to what's happening above, but when opening UI Main I get this unusual error:



I've never seen this before. Cancelling lets the vi open normally (albeit broken due to the previous problem.) I'm guessing it's because I didn't set up a cRIO through NI Max on this pc?

[asbo]

It is okay to use Scan Engine variables in your host application (I think they get published as network variables?), but I have little exposure to them so that's all I can say.

For the latter problem, have you tried a force re-compile? Someone else posted about that particular error on these forums a bit ago, but I forget who/when/where. I've seen this dialog (outside of the LabVIEW context) tied to hard drive corruption (run chkdsk /f?). Try pulling another copy out of version control and see if it still presents.

[ShaunR]

I don't think this is directly related to what's happening above, but when opening UI Main I get this unusual error:



I've never seen this before. Cancelling lets the vi open normally (albeit broken due to the previous problem.) I'm guessing it's because I didn't set up a cRIO through NI Max on this pc?

I have
Strange Disk Error

Try turning off Windows Defender.

[JamesMc86]

Can you still browse to the variables when you select the SV nodes? I presume it is the whole project that you are taking over as is.

The link is contained within the project so it doesn't matter if you haven't done anything in MAX with that cRIO. It would be interesting to know whether the two errors could be linked.

[Daklu]

Thanks for the info Shaun and asbo. I'll try to track it down later when I have more time or get tired of dealing with it.

Can you still browse to the variables when you select the SV nodes?

Yep, I can still browse to the correct variables.

I presume it is the whole project that you are taking over as is.

Erm... sort of. The customer wanted a quick-and-dirty app to test and characterize a system they're building. I don't have much experience (or infrastructure code) with cRIO so I copied an existing project and heavily modified it. But yes, the entire project was copied to another pc using a usb stick.

It would be interesting to know whether the two errors could be linked.

Given the info from Shaun and asbo, I don't think it is. I have seen broken scan engine variables when the "no disk" error didn't appear.


----------------------------


Another question regarding shared variables: Are shared variables dynamically namespaced? I ask because something else occurred a while back I did not expect.

The shared variable library is located under the RT target. While working on the host app I noticed the shared variable library was showing up in dependencies, like how a vi used in the host app and RT app will show up under both targets. I moved the shared variable library from the dependencies and grouped it with the rest of my host app source code for convenience. That didn't work so well. Later on I discovered the variable YC-301 dragged from the pc target is not the same as YC-301 dragged from the cRIO target.

(As an aside, even though I am using the shared variables in the host app the shared variable library no longer shows up in the pc target dependencies. I have no idea why it was there in the first place or why it isn't there anymore.)

[Jordan Kuehn]

Can you find the variables in the NI Distributed Systems Manager? If so, are they updating and reading correctly?

[Daklu]

Can you find the variables in the NI Distributed Systems Manager?

Can't say, as I already repaired the broken code and am not too inclined to rebreak it to check.

If so, are they updating and reading correctly?

Doubtful. The variables in question are to give users direct control over digital output lines. Since the UI code is broken due to the error, the UI can't run and the values aren't updated.

[Jordan Kuehn]

Doubtful. The variables in question are to give users direct control over digital output lines. Since the UI code is broken due to the error, the UI can't run and the values aren't updated.

The cRIO code should still be executing, and you can manipulate shared variables with the DSM. It can be a pretty handy tool when working with cRIOs. Won't get you inside the FPGA, but it can give you a peek inside the RT side and the CPU.

[Daklu]

you can manipulate shared variables with the DSM.

Ahh, I see. Good question, I'll have to try that if I encounter the problem with a live system handy.