Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-36063

Fix the Unsupported Dialog Error in Real-Time Controller

    XMLWordPrintable

    Details

    • Type: Story
    • Status: Done
    • Resolution: Done
    • Fix Version/s: None
    • Component/s: ts_main_telescope
    • Labels:

      Description

      Fix the unsupported dialog error in real-time controller. When I tried to put the ts_labview_tcp_json as the submodule into the LabVIEW project, I faced the following error:

      Please help to fix this.

      A related discussion is:
      https://forums.ni.com/t5/LabVIEW/Error-Details-Display-Dialog-vi-and-Not-Found-Dialog-vi/td-p/4062026

      Another weird part is here:

      At each time that I opened and closed the LabVIEW project without any modification of code, the project will prompt the above window for the change, which I do not understand what it is.

      Note:
      1. To reproduce this error, sometimes, you may need to save and close the LabVIEW project and open it again.
      2. In my memory, you made use the dialog to get the error message in this module, maybe this is the root cause?
      3. When you worked on this ticket, you might find other parts to block your module to run in the real-time target. Please make a minimum change to make your module can work in the target. This ticket should be able to demonstrate this.

        Attachments

        1. appkind.png
          appkind.png
          40 kB
        2. quitLabVIEW.PNG
          quitLabVIEW.PNG
          11 kB
        3. readConfigFileDefaultPath.PNG
          readConfigFileDefaultPath.PNG
          39 kB
        4. targetSpecificError.png
          targetSpecificError.png
          341 kB
        5. weirdSavement.png
          weirdSavement.png
          174 kB

          Issue Links

            Activity

            Hide
            pcortes Patricio Cortes added a comment -

            Related to the first request: "Fix the unsupported dialog error in real-time controller":

            • I tried to reproduce this error and I got the same error message in targetSpecificError.png attached to this ticket.
            • This image shows that the Details Display Dialog.vi and Not Found Dialog.vi have problems. Both are not supported functions on real-time target.
            • The caller of these functions is the General Error Handler.vi used in TcpServerBase.clearErrorAndSendExplnation.vi.
            • I realized the General Error Handler.vi is not needed since we don't want to get any error dialog, only we need to get the error string (source). Hence, I have to use the Unbundle By Name LabVIEW function to get the string error only. This solves the error messages in targetSpecificError.png.

            Related to the second weird message in weirdSavement.png, after a did the previous workaround, this message disappeared in my test.

            Show
            pcortes Patricio Cortes added a comment - Related to the first request: "Fix the unsupported dialog error in real-time controller": I tried to reproduce this error and I got the same error message in targetSpecificError.png attached to this ticket. This image shows that the Details Display Dialog.vi and Not Found Dialog.vi have problems. Both are not supported functions on real-time target. The caller of these functions is the General Error Handler.vi used in TcpServerBase.clearErrorAndSendExplnation.vi . I realized the General Error Handler.vi is not needed since we don't want to get any error dialog, only we need to get the error string (source). Hence, I have to use the Unbundle By Name LabVIEW function to get the string error only. This solves the error messages in  targetSpecificError.png. Related to the second weird message in weirdSavement.png , after a did the previous workaround, this message disappeared in my test.
            Hide
            pcortes Patricio Cortes added a comment -

            Related to point #3:

            • there is this function called Quit LabVIEW inside of a Conditional Disable Structure that is blocking the building process. It will be necessary to remove it:

            Show
            pcortes Patricio Cortes added a comment - Related to point #3: there is this function called Quit LabVIEW inside of a Conditional Disable Structure that is blocking the building process. It will be necessary to remove it:
            Hide
            pcortes Patricio Cortes added a comment -

            Related to point #3:

            • there is an issue with the relative path for the reading of Default.ini file after the project is built and the executable is deployed into the cRIO.
            • the issue happens in the readConfigFileDefault.vi. In this VI we are using the Application Directory.vi that returns the path of the directory containing the application.
            • In the source project, the Default.ini file is located in ../config/Default.ini so the code to read this file is:

            • In the Development System mode, the Application Directory.vi gets the correct path to read the .ini file. However, when the Build Specification is created, and the startup.rtexe is created and run in the cRIO, this VI gets a different path:

            Interactive FrontPanel mode:  /home/lvuser/natinst/config/default.ini.

            Build mode: home/lvuser/natinst/bin/startup.rtexe/config/default.ini.

            • With the code shown in the previous image, the name of .rtexe is added to the path. This adds a new section in the path that does not appear in Development mode.
            • I tried to find a way to avoid modifying the code but so far I couldn't find a good workaround.
            • One option that I tried is to detect when the code is running into the Development mode, Interactive mode, or .rtexe mode (the last two are considered Embedded LabVIEW mode). This can be done using the App.Kind property node and the Case Structure:

            The App.Kind property node gets the Run Time System option and the Embedded LabVIEW option. Both can use the App.Dir property node to get the relative path of the application (*.exe and *.rtexe). Besides, the App.Kind property node gets the Development System option, which can use the Application Directory.vi to get the path of the project in the Development mode.

            • With this workaround, the TCP server runs without problems in cRIO, but probably there is another way to do that. I will try to find another solution.
            • I tested the cRIO CPU and it did pretty well: less than 3%.

             

            Show
            pcortes Patricio Cortes added a comment - Related to point #3: there is an issue with the relative path for the reading of Default.ini file after the project is built and the executable is deployed into the cRIO. the issue happens in the readConfigFileDefault.vi . In this VI we are using the Application Directory.vi that returns the path of the directory containing the application. In the source project, the Default.ini file is located in ../config/Default.ini  so the code to read this file is: In the Development System mode, the Application Directory.vi gets the correct path to read the .ini file. However, when the Build Specification is created, and the startup.rtexe is created and run in the cRIO, this VI gets a different path: Interactive FrontPanel mode:  /home/lvuser/natinst/config/default.ini. Build mode: home/lvuser/natinst/bin/startup.rtexe/config/default.ini. With the code shown in the previous image, the name of .rtexe is added to the path. This adds a new section in the path that does not appear in Development mode. I tried to find a way to avoid modifying the code but so far I couldn't find a good workaround. One option that I tried is to detect when the code is running into the Development mode, Interactive mode, or .rtexe mode (the last two are considered Embedded LabVIEW mode). This can be done using the App.Kind  property node and the  Case Structure: The App.Kind property node gets the Run Time System option and the Embedded LabVIEW option. Both can use the App.Dir property node to get the relative path of the application (*.exe and *.rtexe). Besides, the App.Kind property node gets the Development System option, which can use the Application Directory.vi to get the path of the project in the Development mode. With this workaround, the TCP server runs without problems in cRIO, but probably there is another way to do that. I will try to find another solution. I tested the cRIO CPU and it did pretty well: less than 3%.  
            Hide
            pcortes Patricio Cortes added a comment -

            Please help to check this PR. Thanks.

            Show
            pcortes Patricio Cortes added a comment - Please help to check this PR . Thanks.
            Hide
            ttsai Te-Wei Tsai added a comment -

            Reviewed in GitHub. Please help to update the story point accordingly. Thanks!

            Show
            ttsai Te-Wei Tsai added a comment - Reviewed in GitHub. Please help to update the story point accordingly. Thanks!

              People

              Assignee:
              pcortes Patricio Cortes
              Reporter:
              ttsai Te-Wei Tsai
              Watchers:
              Patricio Cortes, Te-Wei Tsai
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Jenkins

                  No builds found.