Home » Eclipse Projects » Papyrus for Real Time » Correct use of plugin capsules
| Correct use of plugin capsules [message #1774835] |
Fri, 20 October 2017 11:50  |
 Nicolas Hili
Messages: 40
Registered: March 2017 |
Member |
|
|
Dear all,
I am creating an example using plugin capsules. The example is a "more or less" game where "guessers" have to guess a number between 0 and 100. A single instance of a "Number" capsule is created within the Top capsule (to do that, a "number" capsule part of type "Number" is defined as optional in the Top capsule). I have some troubles connecting an imported capsule to the capsule that imported it.
The scenario is the following:
1. The instance of the Top capsule incarnates n guesser instances of the Guesser capsule (also defined as optional within Top capsule). "n" is determined by an attribute of the Top capsule.
2. The instance of the Top capsule also incarnates the single instance of the Number capsule, the latter will initialize a random number to guess in its initial state.
3. Then, after a specific timeout, the Top capsule sends the "capsuleID" of the number capsule instance to the first guesser.
4. Upon reception, the first guesser "imports" the Number capsule in order to make a guess. To do that, a "number" capsule part set as plugin has been defined in the Guesser capsule.
The steps above work, the model is similar to the ComputerSystem model in the Git repository of Papyrus-RT.
Now, to be able to make a guess, the guesser capsule (which imported the number capsule) has to be connected to that number capsule. To do that, I tried to create a connector between the "numberPort" internal port of the Guesser capsule and the "numberPort" external, conjugated port of the Number capsule (both ports are represented in the screenshot "Capsule_Class_Guesser.png"). When doing that, I am not able to import the capsule anymore.
The line:
frame.import(numberID, number, 0) {
returns false.
My question is: how can I import a capsule and after import, connect its port, so we can send a message to it?
Thank you very much for your answer,
Best,
Nicolas
[Updated on: Fri, 20 October 2017 20:36] Report message to a moderator |
|
|
| Re: Correct use of plugin capsules [message #1774850 is a reply to message #1774835] |
Fri, 20 October 2017 14:02  |
|
Hi Nicolas,
Ports on imported or incarnated capsules are bound automatically, so there is nothing to do in that regard.
However, I noticed that you did not have those parts set as "isNotification." When set, the RTS will automatically send "isBound" and "isUnbound" messages when the capsule instance id bound (e.g., when imported/created) and unbound (e.g., when deported/destroyed).
That way, you can create your state machine to take advantage of these signals, e.g. By having Connected/Disconnected "super" states.
I hope this helps!
/Charles Rivet
|
|
|
| Re: Correct use of plugin capsules [message #1774853 is a reply to message #1774850] |
Fri, 20 October 2017 14:25 |
|
Looking at this more closely, there are a couple of things you could do. The first would be to have both guesser and Number have ports that can connect and then import both in the same context (e.g. Import the Number instance into the Guesser or vice versa). If there is a connector in that context that links those ports, it will be automatically connected, and then you can set notifications so that you know when both are connected and you can start guessing.
I'm also not sure what the timer's role is. I thought it was a timeout on the guesser (i.e., the guesser has a limited time to guess the number), but I am not sure...
/Charles Rivet
|
|
|
| Re: Correct use of plugin capsules [message #1774860 is a reply to message #1774853] |
Fri, 20 October 2017 15:02 |
Ernesto Posse
Messages: 438
Registered: March 2011 |
Senior Member |
|
|
Just to add to Charles' comments. There are both structural and behavioural issues involved:
- Behavioural: when defining capsules that are going to be incarnated in optional parts or imported in plugin parts, it's always a good idea to mark the relevant ports of that capsule as "notification" ports, like Charles says, and use the rtBound signal to detect when the ports get hooked up, to ensure that they are connected before attempting to send messages through them.
- Structural: it looks like you are trying to connect Guesser.numberPort to Guesser.number.numberPort~, but this is not allowed, because in Top you have a connection between Top.numberPort and Top.number.numberPort~, and Number.numberPort has replication 1, which means it can be connected to only one other port. Imagine how it would happen at runtime:
1) you incarnate Top.number: this creates the connection between Top.number.numberPort~ and Top.numberPort
2) you incarnate a Guesser in Top.guesser[0]
3) in the guesser you try to import Top.number into Top.guesser[0].number
At this point the runtime will try to match all the "free" ports of Top.number with the ports on the Top.guesser[0].number (BTW "ports on a part" is not the same as "port of a capsule"). If Top.guesser[0].number.numberPort~ is already connected to, e.g. Top.guessuer[0].numberPort, then this port-matching would fail, because Top.number.numberPort~ is the only port on Top.number and is already connected to Top.numberPort~.
Indeed this connecting behaviour is expected. Otherwise you would be connecting Top.guesser[0].numberPort directly to Top.numberPort, bypassing Top.number altogether. To see how this is problematic, imagine that Number had an internal part with a port connected to Number.numberPort~ (which would be a relay port). Then how would that connection make sense, if the port is not replicated?
I hope this is clear.
My suggestion would be to add a separate port to Number which you use to connect to Guesser, e.g. Number.guess, and in Guesser, connect it to Guesser.numberPort (or whatever internal port you need).
[Updated on: Fri, 20 October 2017 15:14] Report message to a moderator |
|
|
| Re: Correct use of plugin capsules [message #1774875 is a reply to message #1774860] |
Fri, 20 October 2017 18:33 |
Nicolas Hili
Messages: 40
Registered: March 2017 |
Member |
|
|
Thanks both of you for your suggestions :)
Charles Rivet wrote on Fri, 20 October 2017 14:02Hi Nicolas,
[...]
However, I noticed that you did not have those parts set as "isNotification." When set, the RTS will automatically send "isBound" and "isUnbound" messages when the capsule instance id bound (e.g., when imported/created) and unbound (e.g., when deported/destroyed).
[...]
Indeed, I could not understand why I did not receive rtBound or rtUnbound and that is why I used timers. I will try to set isNotification to true :)
Ernesto Posse wrote on Fri, 20 October 2017 15:02
[...]
- Structural: it looks like you are trying to connect Guesser.numberPort to Guesser.number.numberPort~, but this is not allowed, because in Top you have a connection between Top.numberPort and Top.number.numberPort~, and Number.numberPort has replication 1, which means it can be connected to only one other port. Imagine how it would happen at runtime:
[...]
You're right, I've totally missed that. That is the reason why I could not import the capsule. Setting the replication of the numberPort to n > 1 indeed works. Thanks :)
Ernesto Posse wrote on Fri, 20 October 2017 15:02
[...]
My suggestion would be to add a separate port to Number which you use to connect to Guesser, e.g. Number.guess, and in Guesser, connect it to Guesser.numberPort (or whatever internal port you need).
[...]
I then try something similar than that. I created two ports for Number. The first port called cmdPort of type cmdProtocol connects the Number to the Top capsule (no replication) while the second port called numberPort of type numberProtocol connects the Number to the guessers (replication set to 10). Would that work? I thought it would, but for some reason, when connecting the cmdPort to the Top capsule, it does not work.
Nicolas
|
|
|
| Re: Correct use of plugin capsules [message #1774880 is a reply to message #1774875] |
Fri, 20 October 2017 19:13 |
Ernesto Posse
Messages: 438
Registered: March 2011 |
Senior Member |
|
|
Nicolas Hili wrote on Fri, 20 October 2017 14:33
You're right, I've totally missed that. That is the reason why I could not import the capsule. Setting the replication of the numberPort to n > 1 indeed works. Thanks :)
But be careful: if you have that connection, the import may succeed, but the behaviour may not be what you expect, as you will have this sort of "short-circuit" connection between the guesser's internal port and Top's internal port where Top.guesser[0].number.numberPort~ is acting as a weird relay between Top and Guesser. I don't remember of the top of my head if this would actually work. Furthermore, you have many instances of guesser.
For this reason I would recommend adding a different port.
Nicolas Hili wrote on Fri, 20 October 2017 14:33
I then try something similar than that. I created two ports for Number. The first port called cmdPort of type cmdProtocol connects the Number to the Top capsule (no replication) while the second port called numberPort of type numberProtocol connects the Number to the guessers (replication set to 10). Would that work? I thought it would, but for some reason, when connecting the cmdPort to the Top capsule, it does not work.
If the connection that you are adding between number and guessers is in Top, then yes, the replication would have to be 10, but if you are adding the connection in Guesser, from Guesser.numberPort to Guesser.number.numberPort~ then the replication would have to be 1, because there is only one number imported in each Guesser.
|
|
|
| Re: Correct use of plugin capsules [message #1774887 is a reply to message #1774880] |
Fri, 20 October 2017 19:58 |
Nicolas Hili
Messages: 40
Registered: March 2017 |
Member |
|
|
Ernesto Posse wrote on Fri, 20 October 2017 19:13
Nicolas Hili wrote on Fri, 20 October 2017 14:33
You're right, I've totally missed that. That is the reason why I could not import the capsule. Setting the replication of the numberPort to n > 1 indeed works. Thanks :)
But be careful: if you have that connection, the import may succeed, but the behaviour may not be what you expect, as you will have this sort of "short-circuit" connection between the guesser's internal port and Top's internal port where Top.guesser[0].number.numberPort~ is acting as a weird relay between Top and Guesser. I don't remember of the top of my head if this would actually work. Furthermore, you have many instances of guesser.
For this reason I would recommend adding a different port.
Nicolas Hili wrote on Fri, 20 October 2017 14:33
I then try something similar than that. I created two ports for Number. The first port called cmdPort of type cmdProtocol connects the Number to the Top capsule (no replication) while the second port called numberPort of type numberProtocol connects the Number to the guessers (replication set to 10). Would that work? I thought it would, but for some reason, when connecting the cmdPort to the Top capsule, it does not work.
If the connection that you are adding between number and guessers is in Top, then yes, the replication would have to be 10, but if you are adding the connection in Guesser, from Guesser.numberPort to Guesser.number.numberPort~ then the replication would have to be 1, because there is only one number imported in each Guesser.
Okay, I found the mysterious causes why having two different ports of two different types (one for connecting the Top capsule to the Number capsule with no replication, and a second one for connecting the current Guesser to the Number capsule with no replication) did not work. This has something to do with the incremental code generator apparently. The example containing two different ports/protocols works if I remove the entire generated code and regenerate entirely. But I did have some issues when I tried it incrementally (some mysterious behaviour of the incremental code generator happens here). I can probably reproduce the bug easily.
I have set no replication to the numberPort as there is always only one guesser at a time, and I ensure the current guesser deports the capsule before the following one imports it.
Thanks again :)
Nicolas
[Updated on: Fri, 20 October 2017 20:35] Report message to a moderator |
|
| |
Goto Forum:
Current Time: Thu Apr 18 11:07:07 GMT 2024
Powered by FUDForum. Page generated in 0.01867 seconds |
] 
Search
Help
Register
Login
Home
