veristand

[dhlee04]

Hi everyone.

I'm trying to compile a simulink model (.mdl) for NI Veristand 2013 by using NIVeriStand.tlc.

Error message occured as following (Under the MATLAB 2009b) 

"Real-Time Workshop error in block: "Sample2/Matlab Fcn", block type "MATLABFcn": Not yet supported by Real-Time Workshop"

In this case, I can't use the Embedded Matlab function block (w/ coder.extrinsic(-))instead of MATLABFcn, becasue the function tried here use a "COM-object library" call. (And, when I try to use the Embedded Matlab Function block, Some errors related to the COM-object library call occured.)

your help would be a great help.

thx

[Jarrod_S.]

Generally a first thing to try is to build your model against the built-in grt.tlc target. Does that generate the same error?

[dhlee04]

Dear Jarrod S.

Thank you for response.

As you commented, I tried to build my model against the grt.tlc target, and I still had same error message as follows: Real-time Workshop Error in Block: "Sample2/MATLAB Fcn", block type "MATLAB Fcn": Not yet supported by Real-time workshop.

According to MATHWORKS, MATLAB 2009b doesn't support "MATLAB Fcn" in its real-time code generation. They advices I can use the "Embedded matlab function" block instead of "Matlab Fcn", but Embedded matlab function block doesn't support "actxserver" function for COM-object. (the reason why I have to use the actxserver is that the IMU sensor I want to use only support the C and Matlab and "the actxserver" should be included to open its COM-port in MATLAB/Simulink environment.)

In addition, as I heard, the Veristand 2013 supports up to MATLAB 2009b.

I don't know What I'm supposed to do..

I appreciate your comments in advance, and I really hope I can get some valuable advices from you.

Many thanks.

Lee

[Jarrod_S.]

Am I understanding you correctly that you wish to access some IMU sensor through a COM port from your model to acquire data? If you have to use an activeX COM-object to communicate with its driver, then I don't personally see any options to do that within your model itself.

One thing you might look into would be to replace the block that gets data from your sensor in your model with a VeriStand Inport block available in the VeriStand palette. This will create an input to the model where the IMU sensor block used to be.

Then when you build your model and import it into VeriStand, it won't directly be reading the IMU sensor through its driver. It will just have a generic input that you can map to from VeriStand. To complete the link, what you might do is look to build a Custom Device for use in VeriStand that can acquire your IMU sensor data through an appropriate driver. You can then add that custom device to the system definition with your model and use the Mappings dialog in System Explorer to connect the IMU sensor output to the input of your model.

This is very common for models in VeriStand. They don't generally directly access any of their IO. Instead, the IO is configured in the VeriStand system definition separately and then mapped into model.