Solve I/O module problems
      Back to home
      1. GI.knowledgebase
      2. Troubleshooting
      3. Solve I/O module problems

      Common module errors and mitigation

      List of common issues when using I/O modules and how to resolve them

      Modules:

      Q.bloxx

      Communication

      SLAVETRANSFERLOCKED_INCOMPATIBLE:

      This message can occur in test.commander, when uploading a controller with some Q.bloxx into a project. It is also written in #actual.sta of the controller.

      The reason for this can be, that one module-specific parameter in the module files is not correct. The concerning files are:

      • Configuration file (*_c.gcf)
      • Interface file (*_i.gcf)
      • Calibration file (*_cal.dat)

      In all these files there are the same parameters for:

      • Casing Type (CaTy)
      • Module Type (ModTy)
      • Sub-Modul Type (SModTy)
      • Function Type (FuTy)

      All these parameters have to be the same in all files of the module.

      It is also very important, that each module-configuration file in the controller is 1:1 the same, as in the module!

      If all these requirements are not fulfilled, the module will not communicate correctly on a controller.

      To solve this problem, please try the following steps:

      • In each case: use “cleanup connected controller” to delete the wrong module files on the controller!
      • Download default configurations to the module with test.commander.
      • If this didn't help, connect to the module using ICP100 (either directly or via controller → see communication settings in ICP100). It will recognize any wrong settings in the files and will correct them automatically. After uploading the module into ICP100, the corrected files need to be downloaded again (→ button “M” - Send to Module).
      • Only expert users: establish direct communication to the module using ebloxxDirectComm, read all files, and compare the parameters manually.

      SLAVETRANSFERLOCKED_SAMEADDRORBADLINE:

      … ERROR*SLAVEFILESNOTLOADED

      Possible reasons for this message (→ files cannot be transferred correctly):

      • Modules have the same address on the bus → check dip-switches if they are set correctly. If an address is not set via Socket, check the address in the Slave Setup assistant.
      • Problem with bus communication: cables not connected correctly, the problem with bus termination, long cabling..
      • corrupt file in module (interface/configuration): try to
        • cleanup controller in test.commander,
        • download default configuration.
        • If this doesn't work → ebloxxDirectComm (expert users only!)
          • read interface/configuration file → if there is an error on any file, the file is corrupt.
          • get a valid file (e.g. with ICP100), and download it to the module.

      T_TRANSFER:

      Data communication with the module is not possible in measurement mode. Please check

      • Are ALL modules recognized correctly in configuration mode?? → try to upload configuration in test.commander or use an FTP connection with total commander (4/4) and check in #actual.sta if all connected modules answer correctly.
        • So, a possible reason can be a hardware issue: cables not connected correctly, faulty module disturbing the bus, …
      • If hardware is checked and everything is OK → check module files (as mentioned above: parameters in _c.gcf, _i.gcf, _cal.dat). Also follow the steps mentioned, for example, clean up the controller, connect to modules with ICP100 to correct the files, and use eBloxxDirectComm (experts only).

      Write Project

      Missing Modules

      Case 1:

      • Module configuration file already exists IN the Controller, but the module has an error (for example: if the module is physically not connected to the controller anymore)

      When writing a project to a controller with this condition, the following message will come up in test.commander:

      e1

      Button “OK” The module(s) will be disabled IN the controller! This means, that the configuration in the Controller will have errors, especially when there are references to channels on the disabled module - arithmetic channels, Dataloggers, or test.con applications may be affected!!
      Button “Abbrechen” (Cancel) Neither the configuration IN the controller nor the test.commander project will be changed and the upload process will terminate with an error. The user can now solve the issue before writing the project again.

      Read Project

      When uploading an existing project from a Controller to test.commander, some errors or warnings might occur. Especially when the physical structure of the system has changed (slaves added/removed), or if there is another error with a slave. So there has to be a mismatch between the controller configuration and the physical setup.

      In general, NO files within the controller will be modified during the upload process! ONLY the files in the test.commander project will be modified!

      Missing Modules

      In test.commander, the following message will come up when uploading a controller configuration to a project if

      • there is a module file in the controllers' configuration, but the module is physically not connected

      e2 

      As the message box says, the module will be loaded but marked as DISABLED in the project (not in the controller!).

      Because of the missing/disabled module in the project, it can happen, that the overall project settings are not valid anymore because some references to the modules' channels got invalid!

      In this example, the DataLogger of Q.station has a reference to a channel of the missing module: 

      e3

      Depending on what the user wants to do, there are some possibilities to solve this problem:

      Scenario 1: The user wants to remove a module from his setup and wants to continue with the measurement.

      • delete the deactivated module from the test.commander project.
      • check the settings of the DataLogger configuration
      • Update project

      Scenario 2: The user has an old project within the controller and wants to create a completely new setup (new modules, new DataLogger, and so on). In this case, the whole setup needs to be reset to default.

      • Select “Cleanup Connected Controller…” in test.commander
      • Connect new module setup to Q.Station.
      • Create a new test.commander project and upload the controller configuration again with the newly connected modules.
      • Again errors will come up due to “old” DataLogger settings
      • Assign DEFAULT controller configuration with test.commander (all previous settings in Q.Station will be deleted

      e4

      • Update project

      Scenario 3: The user just wants to see the actual configuration without changing anything.
      2 possibilities:

      • delete test.commander project again and check, if the erroneous module is OK.
      • activate the deactivated modules again, to reactivate the references (not recommended because other errors can happen, which might be very time-consuming)

      Error after "Cleanup"

      Cleaning up a controller using test.commander (Utilities → “Cleanup Connected Controller…”) only means, that all module-configuration files will be deleted within the controller. All other settings, like virtual variables (arithmetic channels), DataBuffer, and DataLogger settings will still be active in the controller, but all the references to module channels will be lost. In this case, the controller will automatically list up all missing or invalid references in the #cfgerr.sta file, which will be displayed in test.commander when uploading the configuration:

      e5