Triggering a Ramp Signal to Start

[OwenDavid]

The signal source components are switched on and off by the simulation timestamp.

For example, a ramp can be started at t=1s or a pulse can start at t=5s and then end at t=7s giving a two second duration.

However, is it possible to declare that I would like a ramp or signal of a certain duration and then assign it a logic trigger and thus start at an arbitrary timestamp? Now the ramp would start when the logic condition changed. Such that the ramp start is dependent on a logic event and not a pre-determined start time?

To give a real world example, a hydraulic motor is turning a geared winch. We can use the angular position sensor to count the number of revolutions. Once 20 revolutions had been completed the user would change the valve position to slow the winch until the 30 revolutions had been completed. The time to complete the first 20 revolutions is dependent on the initial valve position (flow rate) and thus the time of the change in control signal cannot be pre-determined.

Perhaps this control functionality exists by combining other components already in the default library? Or it may be outside the scope of the Hopsan implementation given the way the simulation is conducted at discrete timestamps.

Can anyone with more experience comment on the above or propose a way to achieve it? Thoughts/comments very welcome.

[robbr48]

For a ramp component, the workaround is to use an integrator component, since the integral of a step will be a ramp. The maximum value of the ramp can be limited with a saturation component.

I like the idea of triggering source signal components from other components though. The workarounds will not work for more advanced sources as for example sine waves. There could be a "trigger" port, which overrides the start time parameter. Optionally we can of course create a new set of "triggered source" components. This needs some thinking though. What should for example happen if a source component is triggered multiple times?

[OwenDavid]

Ok, thanks I will try this approach and it should help to understand the signal components better.

I thought over my initial comments and realised we can perhaps summarise them by saying the signal components are currently only a function of simulation timestamp. If they could be also be a function of logic and/or parameter inputs, i.e. triggers, then they could become independent of the simulation timestamp, we could call this pre-determined, and be used to respond to the actual state of the simulation parameters. Counting the number of motor turns is a good example.

I modified the default ramp component to include a trigger and a ramp duration. Thus, if the trigger goes high then divide the ramp duration by the simulation timestep which gives the total number of ramp steps. Now divide the amplitude by the number of steps and add this small piece of the amplitude to the base value on each iteration.

For example,

ramp duration = 2 seconds
sim time step = 0.001

number of ramp steps = 2/0.001 = 2000

amplitude = 4

amplitude / no. ramp steps = 4/2000 = 0.002

value to add to basevalue on each iteration = 0.002

I would suggest at least two trigger inputs - one latching, i.e. if it goes high once then the ramps starts and then continues whilst ignoring the trigger thereafter, the second being momentary, thus the ramp continues only when the trigger is high, such that an pulsing trigger would give a stepped ramp.

My modified ramp code is working for proof of concept, but being only the second time I have modified c++ code, doesn't reflect the standard of Hopsan (yet)! :) Perhaps I will get it up to standard and then share for comments.

[robbr48]

Your algorithm looks correct. It would be interesting to see the code whenever you think it is good enough :)

An alternative solution would be to sample the current simulation time when the input is triggered and use it as start time. Then we should be able to keep the existing code. I would prefer to have only one ramp component, which can be triggered either by a fixed start time or by an input signal. If the input is not connected, the start time parameter will be used. There should also be only one input signal, and a new parameter to control the trigger behavior (latching or momentary).

The only problem I see is that the start time parameter will not be grayed out when connecting the input signal. This may confuse the user to believe that the start time is still being used. There is currently no ways to disable one parameter depending on another one though. Only solution is to write a good documentation for the component and hope that someone is actually reading it :)

[OwenDavid]

Ok, I'll refine the code with your guidance.

How can we determine if the input is connected? Is there a bit that goes high or a function I can call? Perhaps another component already does this and I can re-use the code - any suggestions as to which ones?

[robbr48]

There is an isConnected() method in the Port class, see e.g. the "Position & Velocity Source" component:

https://github.com/Hopsan/hopsan/blob/master/componentLibraries/defaultLibrary/Mechanic/Linear/MechanicVelocityTransformer.hpp#L79

[OwenDavid]

Proposed code for new ramp signal that can be either triggered or time based.

Points of interest

• Test model compares a variety of use cases and negative amplitudes
• Warning and Info messages added to advise user of mode - triggered or timed
• Triggered ramp mode is enabled by a connected port and requires a ramp duration from the user. There is error handling and a warning message if the duration is missing
• The ramp is triggered by the input going high - i.e. non zero. This could be refined to be limit based if more likely to be useful? I.e. start the ramp when the input signal is above such a value, default could be 1, i.e. a bool/logic signal going high and changed to give the trigger wider use cases
• The signal appears to work correctly
• The input port position matches other input/output signal icons.

Interested in thoughts/comments wrt Hopsan style and refactoring of else if statements. Applying this concept to the other signals could result in powerful and flexible signal toolbox.

Triggered Ramp Test Component & Model.zip

[robbr48]

It looks good overall. According to Hopsan coding style, there should not be a newline before first bracket, i.e.:

if(condition) {
    code
}

The if statements could also be rearranged so that we only check if the trigger port is connected once. This would improve readability and improve performance slightly.

The only problem with this kind of component is that it introduces dependencies between parameters and ports ("if port A is connected, parameter B must be set and parameter C will not be used..."). However I don't see any possible solutions to this, except creating two separate components, which I also think should be avoided. In the long run I think we should add support for reconfiguring components depending on parameter values. This would also be useful for other purposes like FMI and Modelica support. Any opinions here @peterNordin?

I also think this component should replace the existing ramp component. It should be backwards compatible provided we don't rename any existing ports or parameters.