RSI Modules - Re-Install problem

[CoastalMaineBird]

I'm moving my huge project to a new computer (i9-11900K, Win10)

I've Installed LV 2018-SP1, NI-DAQ, LVRT 2018, NI-CAN, EtherCAT, NI-XNET.

I'm using a PXI-Controller that did not change.

On the new computer, when I load the project, and load the main code of the RT portion, it loads fine (unbroken).

However, if I try to RUN it, it deploys everything up until the "Container" and then breaks (broken arrow).

The message is "This VI is broken or otherwise not in a deployable state."

And sure enough, the VI it's referring to (along with dozens of others) is broken.

There are a LOT of errors, but I think it boils down to this:

(This code has worked for years).

Notice that the item that I'm typecasting to is described as a "Variable".  That's wrong.

Notice that there are FOUR options on that last menu.

Here is the same section of code from the computer where it works.

Notice that I'm casting it to an "RSI MODULE".  That option is not available on the new computer.

I must have missed something in the installation process.  But what?  LabVIEW is not smart enough to tell me what's missing, it just changes my code and then complains that it's wrong.

Any ideas?

[rolfk]

Those numeric entries in that menu look like C module numbers. And RSI may stand for RIO Scan mode I/O. Could it be that you use some CompactRIO or FlexRIO hardware here?

[CoastalMaineBird]

Those numeric entries in that menu look like C module numbers.

Yes.  I'm using EtherCAT chassis with some of these modules installed.

I later use constants with those numbers to cast the generic module ref to a specific module ref, for configuration.

Could it be that you use some CompactRIO or FlexRIO hardware here?

Not sure if EtherCAT falls under the "cRIO" header.  I have a DIFFERENT project on the old computer which uses cRIO.  Haven't ported that one yet.

[CoastalMaineBird]

Looks like the EtherCAT installation process is broken.

The README file for EtherCAT 18.5 says this:

 

However, that link goes nowhere.

Searching for "ecatdriver1850" on NI.com leads me to the README page with the same broken link on it.

[CoastalMaineBird]

I re-ported the original source code (to eliminate any inadvertent SAVE operations I did).

This time I paid attention to the  WARNING message:

On the old computer, the file "cRIO.rc" is in Program Files (x86) - National Instruments - LabVIEW 2018 - resource - objmgr

It wasn't installed on the new computer.  I don't know why.  There were "crioRefnum.rc" and other RC files there...

Looks like LabVIEW WAS smart enough to tell me what was missing. I was not smart enough to pay attention.

HOWEVER...

Copying that file over changed some things, but it's still not right.  The code that LV "changed" for me the first time is now left alone.  The FIVE options are now on the menu, the last being a list of module numbers.  YAY !

But it still won't deploy.  I get the same message as before:

 

Notice that it says the VI loaded with errors, yet it's not broken. (this is the same VI that was broken before).

[CoastalMaineBird]

Weird.  Even though I can BUILD the RTEXE (with a build spec) from the new computer and RUN AS STARTUP, and have it work correctly, it STILL complains if I try to RUN it from the DevSys. 

It tells me that this one VI loaded with errors on the target and was closed.

Yet, it's not broken.

[CoastalMaineBird]

More weirdness.

It kept telling me that this VI was broken when loaded on the RT box.

But it didn't show broken in the DevSys.

I tried to run it by itself from the DevSys - it loaded broken (would not run).

I chased pieces (the subVIs it calls.) Some ran OK, one loaded broken.

I chased it further down - some sub-subVIs ran OK, one loaded broken.

The lowest one (of my code) that was broken was a SUBROUTINE priority.

I couldn't run it directly (because of it being SUBROUTINE - no ARROW available).

So I changed it to NORMAL, and it ran OK.

I changed it back to SUBROUTINE and the parent ran OK.

All the way back to the main VI and now that will deploy and run OK.

Somewhere, something got gorched, and now it's OK.

Maybe Cleaning of the project would have helped that.

[rolfk]

The objmgr/xxxxrc files are an interface description for a software component. The real implementation is in a shared library (so on Linux, DLL on Windows, out on VxWorks (although EtherCAT is not an option for VxWorks if I'm not mistaken),

Now what happens here is following. The rc file is i principle enough to define the interface that the LabVIEW compiler creates the correct shared library calls. But you did not install the component that provides this interface but only copied the rc file alone. So on your Windows system the according DLL is not present and the LabVIEW environment correctly complains about the lack of this shared library. When you compile and deploy the code, LabVIEW uses the rc file to recompile the code for the RT target. On that target there is probably the correct shared library installed so the code will work there.

The difficulty here is that the objmgr interface is a little prickly. LabVIEW is not really handling the case properly when the availability of the shared library interface changes. It remembers simply the status of the last time the VIs were saved. Normally this is not a problem. The according VIs, shared library and rc files are all installed by the same installer. They are either all present or none, so you should not get into this intermediate state. Either a (sub) component installation of the EtherCAT driver was missed or failed on your machine or something got borked during install of that. 

[James_W]

Hi Steve,

I've got an issue that might./ might not have a bearing on your broken VIs...
some of my common VIs in my projects get checked into SCC by others in the company. Not everyone knows about checking in without compiled code and some code is quite old or comes from VI packages.
The first time I port the project to a new machine (or checkout), I usually have a broken top level VI - simply due to these VIs and the project failing to mark the VIs as seperate compiled code from source. Opening the project properties, selecting all VIs, and marking them all seems to be much more effective than a mass comipile (which I have tried on all of the externals) - looking forwards to GIT instead of SVN.

as I say, don't if it'll help, but it might!

James