2011 Labview project with sbRIO cannot build RT app with Lv 2014: error 1003

[GreyGrey]

The link you posted says that it's a known bug in LabVIEW. Have you tried rebuilding the Packed Project Library with debugging enabled? The known issue is caused by the attempt to recompile a PPL. If debugging wasn't enabled, there is no block diagram for the compiler to look at. By enabling debugging you include the block diagram of the PPL in the build. 

[Bahsoun]

Hi 

Thank you GreyGrey for you assistance !

Effectively my project contains some PPLs. They are  included automatically by Labview.

As you can see, in attached screenshots, there is an library (PPL) called "NI_Real-Time Target Support.lvlib". It's not open and it's protected by password ! I cannot see block diagrams of any vi within it.

When I right click on this vi, and click "Properties" (second sceenshot) there is no way to "enable debugging". 

[Mathis_B]

You are generally confusing two things here. There are:

- (unpacked) project libraries aka lvlib. These exist as source code and and can be ported to higher LabVIEW versions.

- packed project libraries aka PPL aka lvlibp. These are lvlibs which have been compiled for a specific LabVIEW version. These PPLs only contain the compiled code, not source code. As such they are incompatible to any other LabVIEW version. In order to port these to different LabVIEW versions you first have to port your lvlib and then recompile this into a PPL

It is safe to say that your code does not contain any PPLs. Considering that they are specific to a certain LabVIEW version it would have meant that when opening your code and trying to run it interactively, you would have got error messages as LabVIEW 2014 would not have been able to access the LV2011 PPLs.

Do you have any conditional disable structures in your code? It would be worth checking if the (in the development environment) non-active cases contain broken VIs.

Do you have any case structures where you wire in a constant into the case selctor? That can cause builds to break.

In the build options under "additional exclusions" you can also play around with the "disconnect type definitions" and "remove unused polymorphic instances".

Best Regards

Mathis

[Bahsoun]

Hi Mathis,

Thank you for clarifying the difference between "lvlib" and "lvlibp" (PPL) libraries.

Yes project does contain some conditional disable structures. I have verified all "disabled" cases, there is no broken arrows.

Also I verified all case structures; I found one with "True" constant as case selector. Then I remove it.

And finally, I tried disabling/enabling the "disconnect type definitions" and "remove unused polymorphic instances" options, but no result. The same dialog error appears when I try to build.

I tried also the steps descibed in this article: http://digital.ni.com/public.nsf/allkb/705C2ECA081F3C7986256C0F00559B02

I have a question about changing the language of the labview. The project has been developed using Labview 2011 with French language, and now I'am using Labview 2014 with English language. Can this impact the build process ?

[Mathis_B]

I doubt that a different language version will cause issues like the one you are seeing here.

Next would be to start commenting out (diagram disable structures) large chunks of code until the build starts to work. Afterwards you re-enable bit by bit until it starts breaking again. This way you can narrow down which part of your code is causing the build to break.

[Bahsoun]

Hi,

OK, you are right, Commenting out were the simplest way debug this problem .

One other question please ! My project has an RT app  and FPGA vi. The main VI uses a reference to the FPGA vi. What I want is to make a simple modification in FPGA vi. Can I just recompilte it and delpoy it using MAX ? And then it will work with the old RT app ? 

Best regards

[Mathis_B]

If you are running RT in LV2011 and FPGA in 2014 it is unlikely to work. If both versions are LV2014 it would possibly work but I don't know for sure. I don't think that the bitfile gets encoded into the rtexe (or whatever the equivalent is on linux RIOs) but instead gets put into the support file folder. Overwriting that bitfile and re-booting the RIO should in principle work ... let me know once you've tried it 🙂

Best Regards

Mathis

[Bahsoun]

Hi Mathis,

I'am using you debugging idea of commenting out. 

I found that the problem is caused by  the "TCP Listenner.vi" function. When I put it into the "Disable structure" the build process passes, but it fails in other case.

So, we can say that is the issue. but I can't understand is the vi  that calls "TCPListnner.vi" doesn't show broken arrow. and I can run it normally in interactive mode.

Concerning the deployment of FPGA bitfile directly through MAX, sorry, I didnt do it. I read an article  about this here:  Managing FPGA Deployments.

I understand that it is cannot be done since my RT_main VI  uses "Open FPGA reference.vi" to call my the FPGA vi.

Thank you for your time !

Best regards

[Mathis_B]

That is indeed interesting. Have you tried deleting the TCP listener.vi saving the vi and dropping it again. If it is a weird corruption of your vi, that might sort it.

I have to say that I once had a similar issue in LV2012. When narrowing down which part of the code was causing this, it turned out to be something different everytime. I only managed to work around this by upgrading to LV2013.

Do you have an active SSP? That would be something to investigate with NI support

Best Regards

Mathis

[Bahsoun · Accepted solution]

Thank you so much Mr Mathis for your assistance and your time !

My problem is resolved. Now I can built my RT app and deploy it to my SbRIO successfully. It works fine 

Lets explain briefly what I did. The problem was in the "TCP listener.vi". I found that this VI uses a subvi called "Internecine Avoider.vi". And this last one  calls "Simple error Handler" subVi.

So what I made is ,Firstly, I copy-pasted these VIs from this directory on my disk "C:\Program Files (x86)\National Instruments\LabVIEW 2014\vi.lib\Utility\tcp.llb" to a folder in my project. Secondly, with the commenting out methodology, I can locate the bug in the "Internecine Avoider.vi". In fact, they use a "Conditional disable structure" in which they call "Simple error Handler.vi" if the target is not embedded. But,they don't call it if the target's type is embedded as my case. you can see that in attached captures. 

But, in build process, the compiler does select the right case ( Target_Type==embedded) and then the error occurs. So, I removed the "conditional disable structure", then the build passes successfully.