Unexpected pulses in Smart Components outputs

MicheleG

Hi,
I noticed something strange with Smart Components behavior so I created a simple SC to show you the problem.



It should simply work like this:

• DO_1 is set when only DI_1 is set.
• DO_2 is set when only DI_2 is set.

The SC uses only 3 LogicGates, the blocks "LogicSRLatch" are there only for debugging.

The outputs Latch_1 and Latch_2 show respectively if DO_1 and DO_2 change from 0 to 1.

RESET is used to reset the Latch_ outputs.

How to replicate the problem:

• Set DI_1 and DI_2 to 1;
• Click RESET;
• Set DI_2 to 0.

You should see both outputs Latch_1 and Latch_2 going to 1.

Latch_1 is correct since DO_1 becomes 1.

Latch_2 should remain 0 since DO_2 should remain 0 but an unexpected pulse occurs in DO_2.

Attached you can find the Smart Component as library.

It seems like Smart Components blocks are evaluated/updated in a wrong order.

I have noticed this wrong behavior in many other SCs and this is very frustrating.

Am I doing something wrong? Am I missing something about SCs? 

Thanks in advance!

Maxim Riabichev

Hello,

Yeah I recreated the SC and see the same odd behavior.

It's as though there's a short time where both InputA and InputB on the LogicGate_2 are HIGH when they switch over from 1/0 to 0/1.

I will bring this behaviour to R&D's attention.

Thanks for reporting it!

DenisFR

Hello,

Can you show us I/O Connections list order?

Maybe if you rearrange it, it should happens well?

Did you set "Allow cyclic connection" flag?

@Maxim, Logic should compute all logic before expose its result.

I think for now it compute with events so it compute all for each changed signal.

PS: Can you ask R&D to export and show "Allow cyclic connection"?

Maxim Riabichev

@DenisFR I've attached the SC to this reply (so you can do some tests if you wish). Just change the file type from .txt to .rslib.

Regarding the exporting of "Allow cyclic connection", didn't you create a post asking for this a while back? If so, if I recall correctly R&D has already been informed about this request.

MicheleG

@DenisFR I've set "Allow cyclic connection" flag for all I/O connections (even if there are no cyclic connections) but the problem still persists.

About rearranging the list, I don’t know what could be the “right” order.

 

When I created the discussion I attached a .zip file containing the the .rslib but I just noticed it disappeared. Next time I’ll rename it in .txt. Anyway the SC shared by @Maxim is exactly the same.

Johannes Weiman

I think the root cause here is that connections and their logic are updated in a depth-first fashion. It can be demonstrated by a very simple case:


When DI0 is set to 1, the Output signal of the XOR gate will actually be pulsed (and the latch will go to 1).

This is because the connections from DI0 to the inputs are updated sequentially, and the internal logic of the gate will be executed once for each connection.
So the Output will go to 1 when InputA (or InputB) goes to 1, and go back to 0 when InputB (or InputA) goes to 1. (The order of the connections obviously doesn't matter in this case.)

To change this behavior is not trivial and could possibly also break existing stations. But I can see that a "breadth-first" execution is probably what you want in most cases.

MicheleG

Thanks, your answer clearly explains the strange behavior of the outputs.

Anyway, I am shocked by this.

I thought that Smart Components work following the common approach that ensures data congruence:

1) Read all inputs

2) Execute logic

3) Set outputs

Instead, you are saying that SCs work on events executing their logic many (pointless) times with NON-CONGRUENT inputs and producing temporary wrong outputs.

I can imagine that changing this wrong behavior is not trivial and could possibly break existing stations but probably it is already breaking many FUTURE stations.

If a SC as simple as an “XOR” has unsolvable problems, I will not even try to build any more complex logic. A wrong pulse can cause a disaster in the simulation since many fundamental SCs executes on pulses (e.g. JointMover, PoseMover, etc.). Furthermore, I am currently thinking that wrong pulses are just one of the possible problems that a logic working on non-congruent data could produce.

I considered RobotStudio as one of the most advanced robot simulation software, I am teaching it at University and I am using it for virtual commissioning, but I am realizing it has huge problems that make impossible the realistic simulation of devices other than ABB robot controllers. Actually, I expect a solution from ABB, otherwise it will be necessary to integrate or change it with other software.

Maxim Riabichev

Hello Michele,

R&D are aware of the limitations due to this behavior and are thinking of ways to improve the functionality for the future.

Thank you for bringing it to our attention.