I am currently working on a project that incorporates an EStop circuit. The EStop circuit transmits a 'normally on' (TRUE) signal under normal circumstances. When the EStop button is pressed the signal drops out and becomes FALSE. The digital signal is just for me to catch so I can potentially issue a 'one-shot' command (controlled stop), in the brief period, before connection to all motors and systems fault out.
I have tried configuring an event based task under 'Task Configurations' using the digital EStop output (seemed like the most ideal use case). However the 'event' conditions require a Boolean variable and will only trigger on a rising edge instance. Because my EStop signal is normally 'on' (TRUE) this will not work for me unless I can somehow invert the conditions of the event.
I understand I can incorporate the functionality I am looking for within my main task using an if statement and an inverter, but it seems silly there seems to be no option to invert the conditions of the event.
If what I am asking for is possible please let me know. If anyone can confirm it is NOT possible I will also accept that answer.
Related
I'm working with TIM2 on the STM32L068K which is a Cortex M0 processor. When I write to the timer enable bit, all the interrupt flags immediately get set. This in itself is a known issue and apparently endemic to the processor design based on the online commentary I've read.
I can clear out the interrupt flags by writing to the status register, but the problem is that the NVIC pending IRQ bit for this source (#15) is also set. This means that the second I execute cpsie i I get vectored to the ISR for source #15 (confirmed by seeing that this is the reported source in IPSR). I've tried multiple techniques for writing to NVIC_ICPR, but the bit remains set. As one example of many things I've tried, check out this site : https://www.sciencedirect.com/topics/engineering/pending-interrupt. I've also tried the CMSIS calls to no good effect. Do writes to this register only work in handler mode, not thread mode? And if so, how then can you stop a spurious interrupt from happening? Is it possible to manually enable handler mode without triggering an exception?
Note that this website does say "If the interrupt source generates an interrupt request continuously (level output), then the pending status could remain high even if you try to clear it at the NVIC." I wouldn't expect the TIM2 IRQ to fall into this category as it should only be triggering when the count reaches zero, which is not happening here, and the interrupt flags for it have already been cleared anyway.
I'm wondering whether it is possible to change a block parameter in Simulink (or the value of one saved as a variable) using a different block to enable conditional execution. What I would like to do is have a certain block parameter (in this case, Counter) run during the simulation with an initial value, and have it change to a different value if a certain condition is satisfied.
Ultimately, what I would like to get out of this is to get a Counter block to stop running upon the satisfaction of that condition.
I'm pretty new to Simulink, but I'll detail some of the stuff I've tried so far:
Dashboard switches (Slider, Knob etc.) - I know they're used to
change tunable parameters of blocks, but they cannot be linked to
other blocked and can be only be controlled manually.
Matlab Function block - didn't seem to work, I'm obviously missing something.
Is it maybe possible to disable a certain block/link when that condition is met? That would be a straight forward approach, but I'm not sure it can be implemented in Simulink. Any help would be appreciated!
So to meet your ultimate goal have you considered to place your counter in an enabled subsytem?
Whenever the requirements are met to stop the counter you simply disable the subsystem and the counter will stop.
On the output port of that enabled subsystem you will have the options to preserve the last value or reset it to certain one.
For the use case of being able to abort parallel simulations with a MATLAB GUI, I would like to stop all scheduled simulations after the user pressed the Stop button.
All simulations are submitted at once using the parsim command, hence something like a callback to my GUI variables (App Designer) would be the most preferable solution.
Approaches I have considered but were not exactly providing a desirable solution:
The Simulation Manager provides the functionality to close simulations using its own interface. If I only had the code its Stop button executes...
parsim uses the Simulink.SimulationInput class as input to run simulations, allowing to modify the preSimFcn at the beginning of each simulation. I have not found a way to "skip" the simulation at its initialization phase apart from intentionally throwing an error so far.
Thank you for your help!
Update 1: Using the preSimFcn to set the the termination time equal to the start time drastically reduces simulation time. But since the first step still is computed there has to be a better solution.
simin = simin.setModelParameter('StopTime',get_param(mdl,'StartTime'))
Update 2: Intentionally throwing an error executing the preSimFcn, for example by setting it to
simin = simin.setModelParameter('SimulationCommand','stop')
provides the shortest termination times for me so far. Though, it requires catching and identifying the error in the ErrorMessageof the Simulink.SimulationOutput object. As this is exactly the "ugly" implementation I wanted to avoid, the issue is still active.
If you are using 17b or later, parsim provides an option to 'RunInBackground'. It returns an array of Future objects.
F = parsim(in, 'RunInBackground', 'on')
Please note that is only available for parallel simulations. The Simulink.Simulation.Future object F provides a cancel method which will terminate the simulation. You can use the fetchOutputs methods to fetch the output from the simulation.
F.cancel();
I am using Sync in the following way:
sync true (ports.ocp_cmd$ == 3'b010);
I want the simulator to go to the next command the same cycle the data in ocp_cmd is 010. currently the simulator automatically jumps 1 cycle and only then goes to the next specman command.
How can I change my command line so that no delay is created (so that I will be able to raise the ack signal in the same cycle if desired)
Since the sync true statement must reside in a time consuming method. Compare when the sampling event - for the time consuming method - occurs relative to the change in ocp_cmd becoming 3'b010. It could be that you must modify your sampling event.
I guess what you mean that you sample ocp_cmd at the rising edge of the clock and this means you are raising ocp_read starting with that clock, which means the two signals will have a 1 cycle delay between each other.
If you know ocp_cmd doesn't glitch, you can change your sync to sync true (ports.ocp_cmd$ == 3'b010) #sim.
This isn't proper practice when working with synchronous signals. You'd be better of monitoring the cause of ocp_cmd going to 010 and relying on that.
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.