Why is my test harness build failing in Jenkins due to a sample time mismatch error?

We use Simulink Real-Time (SLRT) and Simulink Test to run Hardware-In-The-Loop (HIL) tests on our Speedgoat systems using a Jenkins CI pipeline.

We've added two new test harnesses to our model, which build successfully on personal machines but fail on Jenkins due to a sample time mismatch error. This error is unexpected since all other harnesses and the model itself build without issues. 

Error using tlc_c
Sample time mismatch. When a Bus Creator or Bus Assignment block outputs a nonvirtual bus, all of the signals driving its input ports must have the same sample time.This restriction applies even if the elements of the object defining the bus specify an inherited (-1) sample time.The sample time (0.001) of the signal driving 'Input Port 6' of 'MyHarness/HIL/HardwareInterface/CAN/Bus Creator' does not match the sample time (0.01) of the block.

Error in coder.internal.ModelBuilder>i_buildProcedure (line 722)
buildResult = tle_c(hCodegenMgr ,...

Error in coder.internal.ModelBuilder.make_rtw (line 119)
[buildResult, mainObjFolder] = 1_buildProcedure ...

Error in build_target

Error in build_target

Error in build_standalone_rtw_target

Error in slbuild_private

Error in slbuild_private

Error in s1_feval

Error in slbuild

Usual fixes like clearing Jenkins workspace or creating a new job haven't resolved the problem.  How can we resolve this Jenkins-related issue when usual workarounds don't work?

Answer 1

[MathWorks Support Team]

Typically, a sample time mismatch error in a CI pipeline can be traced back to two main causes: 

 

1) Hard-Coded Sample Times in Referenced Models: Often, the harness models that encounter errors have their inports/outports sample times hard-coded within the referenced models. This rigidity can lead to mismatches when the build environment differs from the development environment. 

 

2) Discrepancies Between Model Versions: A mismatch between the version of the model on a developer's personal machine and the version on the Jenkins machine can also cause these errors. Such inconsistencies can lead to unforeseen issues during the integration and build process. 

 

Strategies for Mitigation 

To circumvent the first issue, it is essential to ensure that sample times within the referenced models are defined as variables. This approach allows for greater flexibility, enabling easy adjustments to align with the configurations of various machines. 

 

Moreover, the issue of hard-coded sample times is further complicated when dealing with harness models that utilize Model Variants with Variant activation times set at startup. This specific configuration may obscure sample time mismatch errors during local development, only for them to become evident when moved to a Jenkins environment. 

 

If the sample times aren’t hard coded and the issue remains, here are some things you can try to make sure the there are no discrepancies between the model on your personal machine and on the Jenkins Machine:

 

1) Identify the Execution Mechanism: 

• Determine the method used to execute your MATLAB script within the Jenkins environment. Common methods include using the command line options matlab -batch or matlab-batch, employing the MATLAB Jenkins plugin, or other execution techniques. Identifying the exact mechanism is crucial for pinpointing the root cause of the issue. 

2) Replicate the Jenkins Environment:

• Even if the issue does not occur outside of Jenkins, attempt to replicate Jenkins' environment as closely as possible. This involves: 
  • Using the same machine where Jenkins' job runs. 
  • Employing the same execution method used by Jenkins (except if it's exclusive to the Jenkins plugin). 
  • Accessing the copy of the source code within the Jenkins workspace. 
• To achieve this, you could SSH into the Jenkins machine, navigate to the Jenkins workspace, and manually execute the command (e.g., matlab -batch <your_main_script>) used by Jenkins to run your MATLAB script. This step helps in isolating the problem by confirming if it's specific to Jenkins or related to the environment setup. 

3) Review Source Code Management (SCM) Configuration: 

• Assess the type of Source Code Management (SCM) system integrated with your Jenkins setup. Understanding whether Jenkins is configured to clone a fresh copy of the project for each build or if updates are manually pulled in on an occasional basis is essential. This information can help in identifying if the issue is related to how the source code is managed and deployed within your Jenkins environment.

By following these troubleshooting steps, you can systematically identify and resolve issues related to executing MATLAB scripts and HIL simulations in a Jenkins environment, ensuring a smoother and more reliable integration process.