>> Simulink.Bus.createObject('simplebusdemo', 'simplebusdemo/Bus Creator'); >> whos Name Size Bytes Class Attributes ans 1x1 272 struct bus1 1x1 Simulink.Bus bus2 1x1 Simulink.Bus main_bus 1x1 Simulink.BusTo look at bus objects, use the buseditor. (click to enlarge) As of R2008a Simulink has a new bus editor, so unless you are using this release, your version will look different. The left pane shows all bus objects in the workspace. The selected node in the tree displays its children in the center pane, and on the right, you have the details for each selected element. The information about dimensions, datatype and signal name are all a part of the bus object. For hierarchical bus signals, the element datatype is the name of another bus. Looking at the main_bus, it has two signals, bus1 of type bus1, and bus2 of type bus2. The name and type do not have to match, but they do in this case. If you are happy with your bus objects, I recommend saving them to a MAT-file so you do not have to regenerate them every time. Some people prefer to generate an M-file and call that as part of their initialization routines, instead of loading the MAT-file. I have automatically generated this M-file during the call to Simulink.Bus.createObject. Given an output file name, Simulink.bus.createObject also outputs the code you need to make that bus object.
>> Simulink.Bus.createObject('simplebusdemo',... 'simplebusdemo/Bus Creator','simplebusdemo_busScript');Bus specification in action If I change my constant input signal to be type int8 instead of double Simulink will throw an error during update diagram (Ctrl-D).
As you can see, the bus object has locked down the specification for the signals fed into the bus creator. When something does not match Simulink reports an error. Bus objects can be specified on ports In addition to the bus creators, Inports and Outports can also be fully specified with a bus object. When a bus object is used on a port you are asserting that only that special type of connector can be used with that port. This port could be a root level Inport or Outport, or a port on a subsystem. If the subsystem is in a library, you have defined its interface, and all instances of the library block must match the specification. Getting back to the comment that “[bus objects] are one of the most important parts of the whole bus concept: allowing you to lock down an interface.” The concept of locking down an interface is important to developing reusable components as well as working with others on large modeling projects. This is a very powerful concept I have seen used in conjunction with an interface control document (ICD) to define the interface to a system. The document specifies the characteristics of the bus signals, and the bus object enforces that those characteristics are true. I have also seen a Simulink model specify the interface, with a script used to generate the ICD from the model. This makes the Simulink model the single source of truth. Your model will always be in sync with the specification if this is your workflow. Now it’s your turn What do you think about bus objects? Do you use them? I still have not had anyone volunteer to show off their use of bus signals with a screen capture from their model. Leave a comment and then send me an e-mail with the image. I will post it for you and we can all marvel at your work.
The input bus to block 'simplebusdemo_bo_error/Bus Creator1' does not match the bus specified by the bus object 'bus1' on the block dialog. The following errors were detected :Bus element 'Constant' of bus object 'bus1' is specified to be of datatype 'double', but the incoming signal has a datatype of 'int8'.
コメントを残すには、ここ をクリックして MathWorks アカウントにサインインするか新しい MathWorks アカウントを作成します。