Troubleshooting Common Tech Support Issues

In the Technical Support team at dSPACE Inc., we interact with customers on a daily basis to help them get up to speed with the many different products dSPACE makes and to provide solutions for any issues that might be encountered along the way.

Sometimes we come across issues that we’ve never seen before and they may take some additional troubleshooting steps before we are able to suggest a solution, but after you do this job for a while, you start to notice patterns. So in this blog, I’m going to take you through a day in the life of a fictional dSPACE user who’s having a very unlucky day. We’ll call him Chris.

Chris attended dSPACE’s two day training class on Real Time Systems (email your account manager for more information!) and so he has a pretty good understanding of dSPACE, but since he is very unlucky, he’s going to run into a lot of common issues. We’ll walk through these issues together and I’ll point out what steps you can take to troubleshoot and avoid these kinds of problems.

Chris has just been handed a MicroAutoBox II (MABXII) that he needs to start learning how to use. So, remembering the wise words of the teacher from his Real Time Systems class, he launches MATLAB^®, types “RTI” into the command window, and opens up the “Demos” library. When the library opens, he sees that there are a bunch of demos for different functions on the MABXII, but since he’s just getting started he decides to use the first one. So he opens the demo and immediately hits the “build” button. Everything seems to proceed fine for a while and then, at the last second, he gets an error message:

What Chris has forgotten is that MATLAB will automatically try to download the compiled model to MABXII after it has successfully built, but it can’t download the application unless the MABXII has been registered in ControlDesk Next Generation (CDNG) first. Fortunately for him, this error message only indicates that the loading failed, but the build completed successfully. So when he launches CDNG and loads the application to his processor it loads without any issue. Chris decides that he wants to disable MATLAB from automatically loading his application, but he doesn’t know how to disable that setting. So he opens the dSPACE HelpDesk by going to ‘File’ > ‘Help’ > ‘Search’. Through the HelpDesk, he learns that he needs to go to ‘Simulation’ > ‘Model Configuration Parameters’ in his Simulink model and then to ‘Code Generation’ > ‘RTI Load Options’ and uncheck the box for ‘Load application after build’.

Now that he is feeling confident about his ability to build and load an application to his MABXII, he decides that he needs to start adding Input/Output channels to model. The final application that his team is working on will need channels for digital-to-analog converters (DACs), CAN communication, and digital output signals. After adding and configuring all of these blocks, he starts to see that his model isn’t behaving the way he expected after loading it to his MABXII. He notices three issues:

1. His DAC channels are outputting a voltage, but it is not the voltage that he is commanding
2. None of his CAN messages are being interpreted correctly
3. He isn’t seeing any signal being transmitted on his digital output channels at all

To help him with troubleshooting these problems, Chris opens up the library of demo Real Time Interface (RTI) models that dSPACE provides. He opens this library by typing ‘rti’ into the MATLAB command window and then clicking on the library block that says ‘Demos’.

After examining a few of the I/O demo models, he realizes that all of the DAC blocks in the demo models have gain blocks in front of them. To find out why this is, he opens up the dialog on a DAC block and then clicks the ‘Help’ button, which launches the dSPACE HelpDesk and takes him directly to the page that discusses that particular DAC block. The document explains that each DAC/ADC block has a different “scaling factor” that determines how it translates the value inside of Simulink to the physical voltage value that it is outputting / inputting. This scaling factor needs to be accounted for with a gain block.

After making this change in his model, Chris’s DAC channels are now outputting the correct voltage, but there are still issues with his CAN channel and digital output channel. There doesn’t seem to be any more information that he can glean from the demo models, so Chris turns to the hardware documentation on his MABXII that will give him a detailed description of all of his I/O channels. After some searching in that document, he realizes that he has forgotten two things:

1) he has forgotten that dSPACE documentation recommends an external termination resistor on the CAN bus, and 2) he must make the appropriate high reference voltage available to his digital output channels. To fix his CAN issue, Chris adds a 120 Ohm resistor to his CAN bus. And to fix the digital output channel he adds a jumper wire in-between the VDRIVE and VSENS pins on his MABXII Zero Insertion Force (ZIF) connector.
Now that Chris has made all of those changes to his model and hardware setup, he is getting the correct output from his MABXII, so now he needs to start capturing and analyzing some of the data using ControlDesk Next Generation. After creating his project, dragging some signals onto a plotter, and starting measurement, he again notices several issues with the data that his plotter is displaying:

1. Some of the variables that he defined in his model are not available in the Variables window inside of CDNG.
2. When he switches his plotter from “Triggered” to “Continuous” measurement mode, he notices that there are periodic small gaps in his captured data and he would like to capture continuous data.
3. He can’t figure out how to change the x-axis of his plotter so that he can see a longer period of time.

Thankfully, dSPACE provides a searchable database of frequently asked questions that includes detailed answers to 2 of the 3 questions. You can get to this database by going to the dSPACE website, (www.dspace.com), choose your localization, clicking on “Support”, clicking on “Knowledge Base”, and then searching the database. Chris finds two documents that are directly related to the issues that he is seeing. The document that discusses missing variables in the Variables window explains that he needs to check to make sure that he hasn’t selected “Inline Parameters” in the Model Configuration Parameters window. From these documents, he also learned that the gaps he was seeing in his continuous plotter were happening because, although he had changed his plotter to “continuous”, his acquisition service was still set to “triggered”.

After searching through all of these documents, he was still unable to figure out how to change the scale on his x-axis. To figure out how this functions, he decides to contact dSPACE support.

When he contacts them, they explain that there are two ways to change the x-axis depending on if his plotter is in continuous mode or in triggered mode. When the plotter is in continuous mode, he can change the axis by right clicking on the plotter > selecting Properties > Axis > x-axis > synchronization. Whereas, when the plotter in in triggered mode, he needs to change the axis by changing the length of the duration trigger in the correct raster. He can make this change by going to the ‘Measurement Configuration’ window > Acquisition > HostService > Duration Trigger.

I hope this blog will prevent you from running into issues when using your dSPACE system. More importantly, I hope that you’ve learned about the many different troubleshooting options that dSPACE makes available. So the next time you run into an issue while using your dSPACE system, you’ll know how to start resolving the issue. As always, if you have any questions, dSPACE Support will be happy to help!