Setup board or select board via popup in Simulink Desktop Real Time packet library

I am trying to make a mask that programmatically allows me to setup the board as well as selecting any previously configured devices in the packet output or packet input block. My test block is really simple where I have the following

\

And then in my Parameters and Dialog tab, I've chosen DrvName, DrvAddress and DrvOptions as a promote parameter to be able to configure it with the mask itself. However, it only appears as a text and some vectors that does not really do anything as shown below

How should I go about this? I want to try and setup the board using some pop-ups but I could not get anything configured even when I try to use the Initialization and simply get the DrvName list etc.

Answer 1

[Jan Houska]

Hi Khalid,

the driver-related parameters of the Packet Output block are specific for individual drivers and undocumented for programmatic use. That said, you have correctly identified the three related parameters - DrvName, DrvAddress, DrvOptions. Their meanings are like this:

DrvName is the type of the device. Typically, it is formed as the vendor name, then device model name or number, separated by slash. Spaces and other special characters are often replaced by substitute characters, e.g. underscores, to make the parameter a valid file name.

DrvAddress is the parameter that serves for distinguishing multiple devices of the same type. It can be some hardware address, local port number, or just the ordinal number (first, second, etc.), based on the type of the device. The pair of DrvName and DrvAddress uniquely identifies the device.

DrvOptions is the parameter that specifies various device-specific options and its format differs by device type, because each device requires a different set of parameters. In the case of the Kvaser CAN device, these are parameters like baud rates, message acceptance filter masks, and such.

The safest way how to set values of these parameters programmatically is to set them using the GUI first when developing your program, then read their values using get_param and use the exact same values when you are calling set_param from your program.

Please also note that the Packet Output block does have a popup selection of previously configured devices, so you may just try to use that. And if you really want to dig into the internals of the block parameter configuration implementation, please take a look at the rtblkgui and rtdrvgui functions. But please keep in mind that these functions implement undocumented internal functionality and their behavior or even their existence may change with any future release, without warning.

Good Luck, Jan

[Khalid Hersafril]

Thank you for the input.

"The safest way how to set values of these parameters programmatically is to set them using the GUI first when developing your program, then read their values using get_param and use the exact same values when you are calling set_param from your program."

Just to re-iterate on this note, I have tried this but apparently both of them is just giving me the same DrvName value which is essentially just Kvaser/CAN_Device. I tried to configure it to different board setup as well, but all leads to the same device driver name along with the same driver options apart from the baudrate being different.

The following is my configuration in the packet block:

First block

CAN Channel: 0

CAN baudrate: 500

Second Block

CAN Channel: 1

CAN Baudrate: 1000

However, the DrvOptions output is: [0 0 0 0 500 0 0] and [0 0 0 0 1000 0 0]

with no sign of much difference.

As of now, I chose not to promote any of these parameters and configure them separately and store it in a library.

[Jan Houska]

Hi Khalid,

it is correct that both the blocks give the same DrvName, because they are both the same type of device. It is also correct that the DrvOptions vectors differ in one item only (the baudrate), because all the other options are apparently the same. However you may be missing the DrvAddress - this should be 0 or 1 to distinguish between CAN Channel 0 and 1.

Jan