Transferring code for a real-time target

[StevenHunter]

I built a client-server system in project. All of the code is in an auto-populating directory. Now I want to migrate the server to a NI Industrial Controller (NI-3171). When I try to move the code to the RT Target and build, all of the links to sub-VIs in the project are broken. I also tried creating a build that referenced the server VI and the same thing happened. 

Do I have to copy every sub-VI used down to the target part of the project?

[Bob_Schor]

My experience with LabVIEW Real-Time (I'm currently working on one designed to run with a RIO system as the RT Target) is that, in the LabVIEW Project, the Target appears in the Project Explorer and the code designed to be deployed on the Target is "placed" under the Target in the Project Explorer.  I have a few routines that are used both on the Host and on the Target -- I've created a Project Folder called "Common" in which I place these VIs/Controls, and make sure that Common is shown both on the Host and the Target.

In this configuration, I can run the code without building Executables.  LabVIEW will deploy the RT Code to the RT Target and will start it running there.  When you build an Executable (on the Target), you can deploy it to the Target and set it up to run as the Executable's Startup routine.  If you do this, then when the Target is turned on, it automatically starts running the code that it will need to run with the Executable.

Bob Schor

[StevenHunter]

I have a Code folder that both the Windows and Target project can see. 

Further investigation shows that the errors are all related to database calls. I haven't been able to fix that yet.

[Bob_Schor]

Assuming the database is accessible from the PC, the database functions better not be on the Target!

Bob Schor

[StevenHunter]

The plan was to have the database itself on another computer and have the RT system just read and write status and configurations to the database.

It appears that the database library is not available to the Target.

[Bob_Schor]

I'd say you need to take a step back and think about your overall design.  In a LabVIEW Real-Time environment, the Host (PC) system should handle that which the Host does best, namely all of the User Interface, including all direct interaction with the User, all I/O involving external files, all operations that are not "time-critical", leaving all of the time-critical operations to the Real-Time Target, running an OS that is optimized for precise and accurate timing.

I have found that writing a Document that describes, in broad strokes, what you need to accomplish, and who should "be in charge" at various stages.  Generally, there is some setup, where parameters are updated, perhaps from a database or through interactions with an operator (slow, not time-critical, able to access external files and interact "at human speeds" with the operator), which involves setting up the RT Target to do a time-critical, precise, acquisition/control sequence characteristic of LabVIEW Real-Time, with "control" temporarily given to the RT side until the time-critical task is complete.  During Setup, "control" resides with the Host PC, but during Acquisition, it passes to the RT Target, with the Host acting as a "helper" to do such non-time-critical tasks as stream data (from the RT Target) to disk.

This can take a few days/weeks to accomplish.

Bob Schor

[StevenHunter]

We don't need real-time speed. We need a system that does not require a login that the computer security people can accept. 

[Bob_Schor]

---

@StevenHunter wrote:

We don't need real-time speed. We need a system that does not require a login that the computer security people can accept. 

---

Ah, that's a different (and, sometimes, more difficult) problem.  Usually the best way to handle this is to have everything that you (ever) need on one Machine, with no need for ever getting on the Internet -- this way, there is no way to have the PC "corrupt" the network, or "be corrupted" by the network.  Of course, this can make getting data into and out of the PC something of a pain, but if it is merely "monitoring and controlling", this may just involve developing your code on another machine, building an Executable, putting it on a USB Drive, and copying it to the Test PC.

Another thing to ask your IT folks is whether or not you can get a special account without Internet Access and a "known" Username/Password that gives you access to your Program, with local storage on the PC's hard drive.  When you need to update the code, or "export" the data, you log off the "special", limited, account, log on as a "real" user with Internet access, and can then update your LabVIEW code, move the acquired data to a Share, etc.

Bob Schor