I am using Simulink to communicate with a serial device. I am trying to use the Serial Send block to send a value to the device. If I try to use a 'traditional' source (such as the Constant block) to send data, I get the following error.
The block 'Serial Send' cannot be assigned a continuous sample time.
How can I send a non-continuous signal?
You have to convert signal to discreate. First put your data to Quantizer than output from Quantizer connect "Zero-Order hold " now you send data to serial send
Per a discussion on the MATLAB mailing list (source):
You can set a sample time on the
Constant block. If you double click on
it you will see the sample time is set
to -1. You can also drag in a sample
and hold block. You may want to turn
on sample time colours to make
debugging easier.
Update:
Also, you may want to try using the To Instrument block instead of the Serial Send block. I've never used either, but the main difference I see is that the To Instrument block is designed for sending "simulation data", which might be more compatible with the Constant block. Maybe there's a reason that you can't use the To Instrument block, though.
Related
I am new to STM32 and freertos. I need to write a program to send and receive data from a module via UART port. I have to send(Transmit) a data to that module(for eg. M66). Then I would return to do some other tasks. once the M66 send a response to that, my seial-port-receive-function(HAL_UART_Receive_IT) has to be invoked and receive that response. How can I achieve this?
The way HAL_UART_Receive_IT works is that you configure it to receive specified amount of data into given buffer. You give it your buffer to which it'll read received data and number of bytes you want to receive. It then starts receiving data. Once exactly this amount of data is received, a callback function HAL_UART_RxCpltCallback gets called (from IRQ) where you can do whatever you want with this data, e.g. add it to some kind of queue for later processing in the task context.
If I was to express my experiences related to working with HAL's UART module is that it's not the greatest one for generic use where you don't know the amount of data you expect to receive in advance. In the case of M66 modem you mention, this will happen all the time.
To solve this you have two choices:
Simply don't use HAL functions at all in case of UART, other than the initialization functions. Implement your own UART interrupt handler (most of the code can be copied from handler in HAL) where upon receiving data you place received bytes in a receive byte queue handled in your RTOS task. In this task you implement protocol parsing. This is the approach I use personally.
If you really want to use HAL but also work with a module that sends varying amount of data, call HAL_UART_Receive_IT and specify that you want to receive 1 byte each time. This will work, but will be (potentially much) slower than the first approach. Assuming you'll later want to implement some tcp/ip communication (you mentioned M66 GPRS module) you probably don't want to do it this way.
You should try the following way.
Enable UARTX Rx interrupt in NVIC.
Set Interrupt priority.
Unmask Interrupt request in EXTI.
Then use USARTX Interrupt Handler Function Define in you Vector.
Whenever the data is received from USARTX this function get automatically called and you can copy data from USARTX Receive Data Register.
I would rather suggest another approach. You probably want to archive higher speeds (lets say 921600 bods) and the interrupt way is fat to slow for it.
You need to implement the DMA transmition with the data end detection features. Run your USART in the DMA mode in the circular mode. You will have two events to serve. The first one is the DMA end of thransmition interrupt (then you copy the data from the current tail pointer to the end of the buffer to avoid data override) and USART IDLE interrupt - this will detect the end of the receive.
I want to continuously read simulink signal data into the command line while the simulation is running. get_param() seems to be blocking so that doesn't quite work when put in an infinite while loop.
I'm now trying to use a UDP send block but I can't seem to receive data. My UDP block sends data to localhost over remote port 25000 and local port 25001.
In matlab I use the following code but it simply times out with no data
u=udp('127.0.0.1', 25001,'LocalPort',25000);
fopen(u)
fread(u)
fclose(u)
delete(u)
What are my options to continuously read out simulink signal data into Matlab CLI?
Control Simulation Using the "set_param()" command like follows:
set_param('sys','SimulationCommand','WriteDataLogs')
For a working example, type "sldemo_varsize_basic" in the matlab command window. Then above command becomes
set_param('sldemo_varsize_basic','SimulationCommand','WriteDataLogs')
If you set the simulation time to sufficiently large and start the simulation, the "simout, simout1", "tout" and "xout" variables are created/updated in the workspace every time you issue the command above.
Unfortunately, I was not able to find a good quality documentation of this feature.
Are you trying to store the value of your model outports DURING simulation? This is not possible because the variables 'simout, simout1", "tout","xout" etc are created only once simulation is OVER.
In order to read/store the value of outports during simulation, you will have to attach an 'Runtime Object' to the outports.
Refer 'Access Block Data During Simulation' in the Simulink documentation or see this link: http://in.mathworks.com/help/simulink/ug/accessing-block-data-during-simulation.html?s_tid=gn_loc_drop
Hope it helps :)
This question has already been answered here using RunTime Objects as I have described above:
https://stackoverflow.com/a/17006419/6580313
How can I access the callbacks for the "UDP Send" Block (from Instrument Control Toolbox) in Simulink?
I want to send UDP data as fast as it is available in Simulink. After a short amount of time running my Simulink model the Simulation stops as "an asynchronous write is already in progress".
I would like to send whenever the status of that block is '{idle}', however I haven't found a way to access this information.
I also tried to write the function myself in a matlab script within the Simulink model, but code generation is not supported for udp class.
As far as I know, the UDP Send block doesn't give you access to that.
However, you can use coder.extrinsic(function_name_1, ...) to build your own MATLAB block.
I want to retrieve the data from simulink during simulation, and use serial network function to send these data to another program. Because I need to use another program to do some tricks and send command back to simulink, so I have to get data from simulink during runtime so that another program can make the right command.
I've tried using To Workspace block to export the data.
However, I can only got value in the very beginning of the simulation.
And I've also tried using scope and change some properties: check Save Data To Workspace and Uncheck Limite data to Last.
First, I started simulation, and I found the ScopeData didn't appear in the Workspace. Only when I stop simulation, ScopeData would appear in workspace.
And after that, I can use ScopeData.signals.values to get values.
But what I want is: when I start simulation, ScopeData would appear in workspace so that I can send these data to other program.
Does anyone know how to achieve this?
I found this page might be helpful, but I still don't know how to continuously export data during simulation.
Use get_param to read data from just at the current time. Also to send the data back to Simulink with set_param of a gain or another block.
An example of get_param
First load and start the simulation:
load_system('myModel')
set_param('myModel','SimulationCommand','Start');
To read data on any line of your simulink model:
Get a simulink block object (let's try a Clock with the name Clock):
block = 'myModel/Clock';
rto = get_param(block, 'RuntimeObject');
Then get the data on its first (or any) output port (or input) of that block.
time = rto.OutputPort(1).Data;
You could do the reading, in a timer callback.
Also this might be helpful: Command Line Functionality for Simulink
During simulation Simulink stores logged data in an internal buffer and only writes the data to the Workspace when the simulation is paused or stopped.
It sounds as if you really need to write an S-function (which will get signal values on a timestep-by-timestep basis) and communicate with Proteus that way.
Of course Simulink is a non-realtime simulator, so if you are talking about doing anything resembling real-time control then you are most likely taking the wrong approach altogether.
At any time during simulation you can force Simulink to write the simulation output data to the workspace:
set_param(bdroot,'SimulationCommand','WriteDataLogs');
I've found that this command is quite unstable in my Matlab 2010a for Win64. In particular I have to avoid it when simulation is stopped (i.e. first check
get_param(bdroot,'SimulationStatus') ), otherwise Matlab shows an error and asks to be restarted.
Is there any way to monitor all signals emitted from a widget with GTK3? I know that the event signal is emitted before an event, but I'm not sure of the distinction between "event" and "signal" in GTK terminology - as this does not seem to capture all signals.
I know GDK has a function gdk_set_show_events but this mostly shows events which are sent to the window from the operating system. Is there a GTK3 equivalent?
There is not built in function AFAIK, but I'm sure you can hack something together yourself:
Use g_signal_lookup to get all signal ids for a gtype. Then use g_signal_add_emission_hook on each signal of your instance to register a hook to be called whenever that particular signal is emitted. Inside the hook function, you're provided with the signal id via *ihint, from which g_signal_query should provide you with all the information you need to print debug messages. (I didn't test it, but it should work)
Note that this will unfortunately not work for signals defined with G_SIGNAL_NO_HOOKS.
Use g_signal_lookup to get all signal ids
It's a little more complicated than described. In order to use g_signal_lookup, you first need a signal-name. If you want to monitor every signal independent of the object-type, you first need to list all signals of the specific instance-type. This can be arranged by g_signal_list_ids for exactly one single GType. To get really ALL signals emitted on the instance, you need to iterate over all parent-types of this instance. You can do this by using g_type_parent.
I have build some utility-functions by myself, that provide this functionality for the same debugging purpose the question was intended. You can connect an Emission-Hook for all signals of a GObject-instance with gemu_glib_util_connect_to_all_signals or connect an emission-Hook to a GtkWidget-instance and all its children with gemu_gtk_util_signal_connect_to_widget_children.