Cameo 2021x: Flow Properties & conjugated proxy port issues

[DR_]

Here's a simplified example of the problem:

Assume you have a "cable TV" signal (the interface type). You also have (two) Three Way splitters, and a few TV's.

Create a "3-way-splitter" block; add 3 proxy ports, and type the proxy ports as "cable TV". Lets go one step farther, and specify TWO of the THREE proxy ports are CONJUGATED.

1. Create an IBD,
2. with the cable TV coming "IN" to the first Splitter (by drawing a connector line from the border to the splitters non-conjugated port).
3. Create a flow: with the cable TV going *IN* to the splitter on the non-conjugated port. [Note: you can create flows in either direction]
4. Send one of the remaining two (these are conjugated) *OUT* to a TV, then add a flow. [Note: you can create flows in either direction]
5. Send the remaining port (conjugated) *OUT* to your second splitter on the non-conjugated port, then add a flow. [Note: you cannot create flows in either direction, further, it shows the "3-way-splitter" block title on both ends, twice (not the unique name of the individual part, like splitter1, splitter2)]
6. More precisely, (in step 5), you can create many, many, many flows, you can choose either drop down, but regardless, the arrow direction stays in one direction, which is actually decided by which end you start your connector from

Noting step #6 above, go ahead and completely delete the flow and the connector (line) from the model. Recreate it starting at splitter 2, and go in to splitter one. The direction cannot be changed. If you actually try to refactor it, and "reverse flow direction" you get an error: "Flow is not reversed: This type of reversion is not supported because the flow source and target are the same element".

These two splitters are indeed the same type, but they certainly are not the same element. Further, shouldn't we be able to specify direction, and shouldn't model validation catch it if I have flows reversed or inconsistent between objects? (MODEL VALIDATION PASSES BOTH WAYS). I am able to revers flows to the TV & splitter, but not between the two splitters unless I "cheat" by starting the connector line at the opposite proxy port.

[jmorales@strattechnologies.com]

There are a few ways you can model this. Using multiplicities might make it easier to add and remove tvs and splitters, for example. Is this what you're trying to do? Can you attached a few screenshots of the issues you're running into? You may be running into an issue with definition vs. usage.

cable tv domain.jpg

cable tv ibd.jpg

[DR_]

This isn't about multiplicity as these are separate parts, just happening to be of the same type, (cameo validates what I'm demonstrating as valid), but it really should fail. One of the cases should fail (the one in red because it is a inconsistent conflict of established definition):

flows_conflict.PNG

However, Cameo will allow you to "trick" the arrows direction (flow direction) by "starting the connector on a certain proxy port"... see example....

splitter2-p2_to_splitter3_p1_ok.PNG

splitter3_p1_to_splitter2-p2_wrong.PNG

Doing the above is actually how I was able to demonstrate the conflicting flow directions between the splitters in the first picture. (despite the port conjugations).

When you define the flow, apparently it-(the arrow-direction-as-pictured)- follows where you started from, implying you have a choice (but you shouldn't).

Note: Cameo refuses to allow me to perform a refactor --> reverse between splitter1 to splitter2 (or) splitter2 to splitter3:

flow_not_reversed.PNG

; So, intuitively, I should not be able to "trick" the flow direction when defined... simply by changing the proxy port I start the connector from.

Further.... because the port is conjugated, all of the flows should be forced to be the same (unless I define bidirectional for it). In that case I should be able to choose which one to realize. But if we're discussion the flows between splitters of the same type, it will not allow me to define bidirectional flows (why not??) therefore the flow direction is only manipulated/manipulatable by where you begin the connector (suspicious).

Here's the options you get when you create a flow. The names are missing (only the block type is show), so it is not helpful:

Which Splitter is which.PNG

I hope this helps demonstrate the issue.

[jmorales@strattechnologies.com]

How have you defined your interface block? If the flow property of the interface block that types the proxy ports is not "inout", you should get a validation error on one of those item flows.

javaw_N4RqABgXNi.png

[DR_]

I had not specified the flow property for the "TV Signal" (thus all of my proxy ports show no direction) - if I do, it does cause validation errors in different connections based on choosing in or out. This implies validation doesn't check that "item flows" are sane with respect to conjugated ports, validation only checks sanity of conjugated ports to flow properties - if defined? (confirming that conflicting arrow directions can be drawn (demonstrated), and validation doesn't flag it).

In the example I drew, it was intentional that a splitter has THREE physical connections (that is a real world example). An IBD of that splitter in it's simplest form is just all three tied together internally. Thereby, the "flow" is either-or-(even both), thus for the splitter it's flow property would be "inout". Functionally, a "TV Signal" on one of the inputs, (any of them), would be present on the "outputs", further, that same design of splitter could be connected a multitude of ways; so it seems sensible that on the splitter only, you want to allow those 3 ports to be "inout"...

This causes you to need to specify "TV Signal" (up to 3 different ways, with flow properties); at least one defined as "inout" that you can use on the three splitter ports, and an additional one that can be conjugated if needed. However, doing so still doesn't allow you to reverse direction (or even logically define direction) of the item flow you connect to/between it if you are using two splitters of the same type connected to each other (as in my example), which is a perfectly legit way to connect a splitter. Thus....

Please try this:
If I have two distinct instances of the same type of part, connected to each other (and their ports are inout), I should be able to specify the information flow (item flow direction) between them but cannot. This seems to be a bug. I certainly shouldn't be able to trick it's direction by how I start drawing it and more importantly it go unchecked if it's not allowed (but it seems logical that it should be allowed, right?).

If I specify "inout" flow property on the ports of two different "block-name, (typed)" interconnected parts, it allows me to define an item flow in one direction and reverse it - but it doesn't allow this if I interconnect two instances of splitters.

[jmorales@strattechnologies.com]

I see what you mean. If you have two parts, typed by the same block, connected to each other through conjugated ports, you cannot reverse an item flow. This is true regardless of flow properties within the interface block. My images show a validation error because there is one, but the issue exists regardless of validation error.

You may be right, this might be a tool issue.

refactor step 1 (Medium).jpg

refactor step 2.jpg

error msg.jpg

[DR_]

I see what you mean. If you have two parts, typed by the same block, connected to each other through conjugated ports, you cannot reverse an item flow.

Correct, in general. The tool should allow "blocks with same types" just as much as it allows interconnects between blocks with different types. Which means that the tool should include the blocks instance Part-NAME instead of (or including) the type for clarity in creation & management of item flows.

The tool does allow you to fake an item direction (based on where you start drawing it), it should force the direction to be "correct" (or at least be consistent).

Ultimately, adapting your experiments in trying my sample, I added flow properties to the ports like you suggested, (makes total sense, and provides validation!) then made the flow properties on the splitters be [inout], and called that interface type "Cable TV (inout)" and made it a specialization of "Cable TV". (it has some side effects, but provides the cleanest, validation ready solution).

Hopefully the dev team can reproduce and enhance! Thank you for your assist!