BUILD EXE

[lo-co]

This is a regular request. Builds should be nightly to make sure we snag issues early. Record all issues here along with their resolution.

PLEASE KEEP THIS ONE OPEN

[lo-co]

Successful build today. Had to remove two VIs that were not used in the TE Cooler object library:

• Write TSP
• Read TSP

Build is not tested and is not currently set to run. Build is taking a long time to compile. Will get a time next build.

[lo-co]

Good server build today with CRD stuff in....

[JustinLangridge]

Couldn't get the build to run - can you provide instructions?

Also tried doing a new build-what determines what needs to be included?

How have you tested it ? How could we ?

[lo-co]

OK...so right now, I am just making sure the builds go. This is just an important first step.

The build needs to be deployed and realize that the port you are on will change (on the UI). Once a build is set as start up, it will force you to override or stop the run every time the system starts.

I am going to look this over but until now this has not been high priority

[lo-co]

Latest build is good:

[lo-co]

Installing NI RT Extensions for SMP so that we can monitor the CPU activity.

[lo-co]

Finally got the CPU monitoring working via the NI Distributed System Manager but we are not actually seeing the system running. Need to check the logs.

[lo-co]

Debugging the RTEXE

1. Got to Operate->Debug Application or Shared Library
2. In the Machine name or IP address box, input the PXI chassis IP address (192.168.101.214).

The RT exe will take a little bit of time, but once it starts up, you will begin to a Connection status output.

Application appears to be currently broken. Investigating this now.

[lo-co]

So, added a whole bunch of libraries to be always included in build. I think we have unresolved dependencies.

[lo-co]

Changed some of the advanced options such that in-lined VIs are not removed and unused library elements are not always removed. I still think we are dealing with dependency issues here.

[lo-co]

Discussing builds with Allan Smith here.

[lo-co]

OK. So have found a couple of broken links in the build:

• Controller.lvlib:Device Init CVT MSG
• Controller:Update Device Configuration MSG

The object signature looks wrong for the latter as there is no .lvlib extension.

Both have the following message in the Context Help:

This class is not well defined. The problem is one or more of the following: -- its private data control is broken -- its .lvclass file is missing -- any of its ancestor classes is broken

The second entry is definitely true but I have explicitly included both objects in the build. One commenter on the forum suggested that arrows associated with text comments on the block diagram can create problems. I found an arrow in the Do of the latter, but no arrows in the former or in any of it's subVIs or it's parent.

Both objects are children of two separate parents. Both parents are abstract and in the build (they show up through the menu item View>>Browse Relationships>> Unopened Typedefs unbroken).

Also seems that we are missing some DAQmx::Write:

However, you can see that the run arrow is solid and you can double click on the VI and it's FP appears (the method is Controller::Handle Power Switch. That seems to be a glitch. Context Help says

Expected path:...

And yet another one broken: Controller::Pre Launch Init.

In this case, the accessor VIs are there but they don't seem to be picked up in the property nodes. Also note that the Config VIs appear to be not totally properly loaded? Seems totally bizarre

[lo-co]

Instrument does not seem to be creating problems. Able to build this into a simple rtexe with no problems....

[lo-co]

Tried to run the device actor using the launch VI but nothing ever popped up on debug...

[lo-co]

Attempted to build a stump with the File Actor. Seems to have run and finished ok.

[lo-co]

On recommendation of AE, have mass compiled some of the folders and found one VI with an "insane error":

Insane object at FPHP+33AF3A68, UID 49, in "Controller.lvlib:Controller.lvclass:CVT Session FGV.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:\Users\Exscalabar\Documents\sw_repo\exscalabar_server\Controller\CVT Session FGV.vi

and

Insane object at FPHP+33AF3A68, UID 49, in "Controller.lvlib:Controller.lvclass:CVT Session FGV.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:\Users\Exscalabar\Documents\sw_repo\exscalabar_server\Controller\CVT Session FGV.vi

As defined here, this is an issue with a front panel type definition (FPHP). I have removed the original front panel objects and replaced them with non-type-def'ed ones. Recompiling the directory seemed to fix that issue.

[lo-co]

Verified - the problem with the exe is the VI O3 Frequency Train Actor::Generate Pulse Train. I removed this from the Actor Core and it does run. Not sure what the problem is but I am going to test a couple of things...

[lo-co]

Build is good now. Problem currently is with the sequence in the timed loop. Don't know why...

[lo-co]

Currently struggling with the web services not starting properly. One possibiliity is that we are starving the web server of resources due to the main application starting before the server. Tried to start service without VIs loading and this seems to not be an issue.

[datid]

I created a build which doesn't run the launcher, but launches from the web services startup.vi. If you look at the contents of the build you will see the original both the startup.rtexe and the xService .lvws are approx 22 MB, whereas in the new one (EXSCALABAR xService) the startup.rtexe is much smaller (it is just a dummy program that flashes LEDs). It still runs .. I think this means that everything is repeated in the 2 files, hence the messages when debugging. I am not saying it is lightning fast, but it is certainly no slower, and it is smaller.

[lo-co]

This errored out with 413. This is the same issue I had last time I tried this (doesn't look like this is documented above, but I had already tried this). That being said, you may be on to something but I am not sure why this impacts the startup. According to NI AEs, the dups are not consequential as it just means it tries to reference the web service locale but the app VIs are located in the app directory.

[lo-co]

So, one thing that I am trying is to

• Uncheck the Load VI at Startup check box for each of the HTTP methods in the web service, and
• Disable debug functionality for the exe.

Not certain exactly what is going on here, but it really seems to be correlated with the rate at which the FPs for the web service load. We shall now see what happens.

[datid]

I am not sure what had happened, but it wasn’t too happy this morning. I think it is back to a working state, but I did notice from git status, that every ( or nearly every ) vi seems to have been modified – do you think that was disabling the debug functionality ??

[lo-co]

So, it look like through some magic, Dave got this rolling. From restart to run, the system is up in less than 1.5 minutes. I am going to consider this the solution and will leave this ticket open for keeping track of the current builds. It is important to note that the LimitBodyRequest was set to 30 MB. Not sure why this worked this time, but maybe increasing it to the full 2 GB is just too much?

We need to make sure to document the build steps for this as this is a new approach for me.

I also should note that the reason that there may have been some issues is that I performed a mass compile on the entire directory to see if we might have any issues that were obvious in the compilation step.

[datid]

This is achieved by using "publish" in the web services, and including the launch code in startup.vi rather than a separate launcher. Publishing takes about 10 minutes, but then the system can be rebooted in about 1.5 min. LimitBodyRequest was set to 30 MB as the total size of the built executable has been around 22MB . There need be no build as such. I think this can be closed..

[JustinLangridge]

Closing this for now. We'll see how it performs when operating on the aircraft network. If there are issues we will re-open.