dSpace Drive-By-Wire Interface

[Georg Nestlinger]

Please try the following:

1) Open a blank Simulink model (i used the dSpace template in Matlab R2017b)

2) Open library 'dataspeed_drive_by_wire.slx' and add the CAN CONTROLLER SETUP block an the 'Drive_By_Wire_Interface' block to the Simulink model.

3) Press Ctrl+D.

4) What do you get? I get the error shown in the attachment.

I can fix these error messages by reloading the dbc-file in the CAN CONTROLLER SETUP block. But this only works for the current Simulink session [closing and reopening the Simulink model will bring me back to 4)]

[James Smith]

Did you run "install.m" to add the Dataspeed library folders to your MATLAB path?

The other issue that comes to mind, and I will add this to the manual in future releases, is that it appears that the path to the DBC file, as defined inside the dialog box for 'CAN_TYPE1_SETUP_M1_C1', is hardwired. That is, I do not see a way for me to define a relative path.

That would mean the user would need to customize this entry to be the path to the Dataspeed library on their PC, then push that change to the library (and save it) to make it permanent.

[Georg Nestlinger]

1) I tried running "install.m". But the library's need to be on your Matlab path anyway. I am pretty sure this is not the reason! Btw: there are paths defined in "install.m" which do not exist.

2) It seems that not the absolute path is stored! Because if I open the "CAN Controller Setup" block from e.g. model "dbw_interface_blocks.slx" stored on path "C:\folder1..." it refers to that path, if I store it on path "C:\folder2..." it refers to "folder2" (see also the attachment).

3) I also checked the "blockdiagram.xml" file inside the slx archive. Comparing the working with the non-working version there is one plausible difference regarding the data types (see attachment), which was also complained by Simulink (see attachment original post).

So to summarize: I don't know why it is working on your PC and I think you should get the same error message.

PS: I am also wondering why there are 5 (!) separate Simulink librarys! Four of them (all except the "vehicle_control_blocks.slx") deal with getting/sending data to the CAN-bus, and three of them have their own "CAN CONTROLLER SETUP" block! Why not merge some of them and use subsystems if you really need to group them?

[James Smith]

1) If "install.m" has paths that do not exist, you need to update to the latest release. That was an issue with the previous release that I found and fixed in the latest release.

2) If your model cannot find the DBC file, you must do as I previously stated, which is to navigate to the DBC file inside of the RTI CAN Controller dialog block, in the Data File Support, using "Replace Data File" button, as you have successfully done previously. (You stated this in your original posting.)

3) To get that change to stick, so that the next time that you open your model you no longer experience the issue, you must Push this change from your model to the library, then Save the library. These directions will be included in the next release of the firmware. (I have already updated the User Manual to address this issue.)

4) The mismatch on data types will go away once you have this DBC issue corrected, per the above instructions. (Digging into that symptom deeper is only chasing an artifact that will naturally vanish.) And, just to be sure, verify that in the "Options" tab inside of the CAN Controller Setup dialog box, the radio button titled "Data type is derived from the CAN signal specification" is selected. (See the screen-shot below.)

5) As for the libraries being split up, that was for organizational reasons. I will simplify and consolidate for the next release. Thank you for that suggestion.

If you have further issues, you can email me directly at:

[e-mail]

Thank you for your input.

Jim

[Georg Nestlinger]

Maybe I was a bit unclear in my 2nd point:

@ 2) My model can find the dbc file (it is located in the same folder as the Simulink model!), that's what I wanted to point out!

@ 3) I am aware of that method and I did it like this, the result is shown in 3) in my previous post.

@ 4) This option is selected.

[James Smith]

We should hold a WebEx meeting early next week. Trying to solve this via postings does not seem to be getting us anywhere.

One thing I can offer in the meantime, is that in my experience with this exact problem. you have to hit the "Set Signal Data Types" button, AND hit the OK button at the bottom of the "Options" tab dialog box, in order to get the dSPACE portion of the model to actually look to the DBC file for the data types. That is, it can appear to be set up correctly, but it isn't. That is a dSPACE issue that is beyond our control.

Please email me directly if you'd like to hold a WebEx meeting Monday or Tuesday of this coming week.

Thank you.