Meaningful Log for Error 1003 When Running Deployed Code

[Quiztus2]

Error 1003 occurred at an unidentified location

Possible reason(s):

LabVIEW: (Hex 0x3EB) The VI is not executable. This error may occur because the VI is either broken or contains a subVI that LabVIEW cannot locate. Select File>>Open to open the VI and verify that you can run it.

The RT Image contains a secret subset of the host's vi.lib. Excluding vi.lib is the default build setting and is recommended in LabVIEW: (Hex 0x6C0) When Deploying Source Distribution to RT Target - NI

When running deployed code, we get error 1003 if the RT Image does not contain a .vi or .ctl that exists in the host's vi.lib. My tests showed that this can likely be a single .ctl.

I ask NI either to publish which .vis and .ctls each RT Image contains, or, even better, to create a log that helps identify which .ctl or .vi is missing. A log with even an obscure signature of the item that failed to load is better than having no information. The alternative—disabling “Exclude vi.lib” because of one or two missing files in the RT Image—leads to unnecessary bloat and code duplication for every single plugin deployed.

I ask NI to either publish which .vis .ctls each RT Image contains or better to create a log which can help identifying which .ctl or .vi is missing. A log with an obscure signature that failed to load is better than no info here. The alternative of not excluding vi.lib because of one or two missing files in RT Image is effectively unnecessary bloating and duplication of code.

[Petru_Tarabuta]

+1. "A log with an obscure signature that failed to load is better than no info here." - Couldn't agree more. Even a code that has no meaning to us (end-users), such as 0xABCD, but that can be traced by NI to certain parts of their source code, would be massively useful. It enables conversations such as I am experiencing error X. It gives a unique, specific name to the issue. It helps pinpoint the issue. This is the power of naming. Right now multiple cRIO issues exist but don't have a name, for example the issues identified in the excellent HSE Dokuwiki article: https://dokuwiki.hampel-soft.com/kb/ni-rt/deployment (including the two NI Forum discussions linked in that article).

[MandatoryAlias]

Deploying code via the IDE is always janky and broken.  Just avoid it entirely.  NI has had 15 years to fix this and they have not and probably will not.

Build your rtexe and create a package (.ipk).  I know that doesn't answer your problem directly but it is a very consistent way to circumvent the issue.