To answer your question at the end, in each orthogonal region, have the initial pseudostate transition to a history pseudostate, and from the history pseudostate in each region to the initial state you want to activate. You need a history pseudostate in each region and it should transition to the initial state you want to activate "before there is history". I'd throw in an image if I could ;-)
Do you have any suggestions for recording the runtime duration of a simulated State Machine & State as a value property or any property that can be used in parametrics??? I have never been able to find a solution that works with States and State Machines, as they do with Activities...I primarily use Cameo and creating or applying duration constraints is simple but actually recoring that duration from the simulated State Machine does not seem to be possible, despite it being very easy with activities.
I'd recommend manipulating the variable "simtime". You can put a constraint like "simtime > 20,000" as a guard for a transition. This means that the transition cannot occur until 20 sec has passed.
What would be the best way to model that if the fan is “off” (i.e. zero speed), it automatically shouldn’t oscillate. It should only be able to oscillate on the low, medium or high speed states i.e. there is a dependency between the orthogonal states.
Good point, I hadn't thought of stimulating the oscilate in more detail. While there are multiple ways to model, one way would be to add another value property under fan block, which is boolean called "rotating". When the fan is in the "off" & "oscilating" states, "rotating" = false. You could add logic to the other states (with opaque behaviors) to act appropriately similar to the way we did the RPM situation. Remember the "oscilate" state is currently modeled as when the knob is pushed in, and the "static" state is when the knob is pulled out. It may have been more helpful/less confusing to have named the states "pushed in" and "pulled out" to parallel the speed states naming convention: "3", "2", "1" instead of "High", "Medium", "Low".
Would it make sense to model the switch states, which can be changed when the fan is on or off, ie, like a real 4 way switch. Then use those switch states to control the fan and oscillation states?
![[Episode 46] The Open Source SysML v2 Tool SysON](/img/1.gif)
Awesome video, thanks for sharing 😊 keep posting regularly
Thanks for the awesome feedback, we intend to keep releasing videos!
To answer your question at the end, in each orthogonal region, have the initial pseudostate transition to a history pseudostate, and from the history pseudostate in each region to the initial state you want to activate. You need a history pseudostate in each region and it should transition to the initial state you want to activate "before there is history". I'd throw in an image if I could ;-)
Awesome thanks for the answer. We may have to create a follow on video to explain these topics.
@@CameoMagic pls make a video, I just cant understand🥲
Do you have any suggestions for recording the runtime duration of a simulated State Machine & State as a value property or any property that can be used in parametrics??? I have never been able to find a solution that works with States and State Machines, as they do with Activities...I primarily use Cameo and creating or applying duration constraints is simple but actually recoring that duration from the simulated State Machine does not seem to be possible, despite it being very easy with activities.
I'd recommend manipulating the variable "simtime". You can put a constraint like "simtime > 20,000" as a guard for a transition. This means that the transition cannot occur until 20 sec has passed.
What would be the best way to model that if the fan is “off” (i.e. zero speed), it automatically shouldn’t oscillate. It should only be able to oscillate on the low, medium or high speed states i.e. there is a dependency between the orthogonal states.
Good point, I hadn't thought of stimulating the oscilate in more detail. While there are multiple ways to model, one way would be to add another value property under fan block, which is boolean called "rotating". When the fan is in the "off" & "oscilating" states, "rotating" = false. You could add logic to the other states (with opaque behaviors) to act appropriately similar to the way we did the RPM situation.
Remember the "oscilate" state is currently modeled as when the knob is pushed in, and the "static" state is when the knob is pulled out. It may have been more helpful/less confusing to have named the states "pushed in" and "pulled out" to parallel the speed states naming convention: "3", "2", "1" instead of "High", "Medium", "Low".
Would it make sense to model the switch states, which can be changed when the fan is on or off, ie, like a real 4 way switch. Then use those switch states to control the fan and oscillation states?