Voltmeter is reading incorrect value when probe is disconnected

[DBX12]

Current Behaviour

A volt meter reads a value > 0V when the "red probe" is disconnected while the COM probe is still connected. Having the "red probe" connected and the COM probe not, it reads correctly 0V.

Build: Version 1.0.0 (rcCD-4157-0-6b14cfe9 2023-06-02) 64 [Qt 6.4.3]

Operating System: Linux Mint 20.3 Linux DBX12 5.15.0-73-generic #80~20.04.1-Ubuntu SMP Wed May 17 14:58:14 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Steps to reproduce:

• Add volt meter
• Add 9V battery
• Connect COM probe to negative terminal of battery
• Connect "red probe" to positive terminal of battery
• See a reading of 9V
• Disconnect COM probe and see a reading 0V
• Reconnect COM probe and disconnect "red probe"
• See a reading of 9V

Expected Behaviour

Volt meter shows 0V if either one probe is disconnected

P.S. Sorry for saying "red probe", I don't know how it is actually called (yet).

[failiz]

I tried a lot of times and I only managed to see the error once. Can you reproduce it consistently?

[KjellMorgenstern]

It would be good to have access to the fzz.

Early versions of Fritzing often did not clean up all data structures, for example when disconnecting or deleting. If another component was moved to the same position, it would "reconnect" to that uncollected garbage, and create a "ghost connection"

We are still investigating some cases of these out of sync connections. The simulator would not be at fault, there is simply a "ghost connection" somewhere in the project data structure. See https://github.com/fritzing/fritzing-app/issues/3904 . Similar applies to the IPC in Version 1.0.1 : The IPC Netlist would contain the connection, and an external integrity check (eg. with ZofzPCB) will show an error.

Especially, this tends to happen, when you seperate a wire (not delete it). While the circuit is displayed as open, there could still be a ratsnest line in the PCB view.

The workaround is usually to delete the wire, then undo the delete. This works because Fritzing 1.0.0 is aware of the ghost connections and cleans them properly. However, it looks like we did not catch all cases yet, because I assume above example was created from scratch, not with an old version of Fritzing?

[DBX12]

@failiz sorry for the long delay. Back when I wrote the issue, I could reproduce it consistently. Today I tried to reproduce it again (still on the exactly same version) and it behaved correctly repeatedly. But I think @KjellMorgenstern is on the right track with the fzz file being from an older version. If I remember correctly, I created that screenshot on a fzz file from an older version (one or two releases before the simulator became an experimental feature). Seems like when I edited that fzz in the old version, it introduced some leftover data structure into the fzz. Several months later, I updated to 1.0.0 and opened the same fzz again and tried out the simulator resulting in the screenshot above. Today I started with a new sketch created by version 1.0.0 and the simulator behaves correctly (as 1.0.0 did not introduce garbage structures yet).

[failiz]

I managed to reproduce it once in 1.0.0, not sure if @KjellMorgenstern has fixed related bugs in 1.0.1

[KjellMorgenstern]

There problem can be reproduced reliably with the potentiometer simulator example, Fritzing 1.0.1

1. In breadboard view, disconnet the black wire (don't delete it)
2. A ratsnest lines appears. This is still expected, since there are still connections in the other views.
3. Right click the ratsnest line and delete it. Now the connection should be deleted in every view. Indeed, no view shows a connection anymore. However, the Multimeter still shows 15V.

There is still an orphaned connection, and it will be listed in netlist exports for the simulator as well as the IPC export (ZofzPCB, a tool to verify IPC files against the PCB will probably raise an error).

[failiz]

But that example file was done with 0.9.9, if I remember correctly. I reproduced the error once by starting from a new file in 1.0.0 (but I only saw it once out of 20 times I tried to reproduce the error).

[Cedrick73160]

Not able to get a right reading at all...

version 1.0.1

[failiz]

We would need more info: Does it happen consistently? Can you reproduce the error by starting from a new project? If so, please, give detailed steps. Did you create this file from scratch? Are there other views wired? Please, upload the file. I tried this in my version and I could not reproduce the error.

[Cedrick73160]

I've opened the LED example and modify it until what I want. Still the same

It is consistently and happening with 3 different projects. I started file from scratch and from example. Only one view. file attached Multimeter issue.zip

[failiz]

Thanks! Did you delete any ratsnets?

[Cedrick73160]

you're welcome. Didn't deleted any ratsnets

[failiz]

@KjellMorgenstern , you mentioned recently that you fixed the orphan connections in the development branch. Did you find cases where these orphan connections were created without deleting ratsnets? If so, the problem will probably be fixed in Fritzing 1.0.2.

[KjellMorgenstern]

@failiz The data structure is quite complex, there are many ways to corrupt it.

1. "Breadboard ghost connections" Probably the most common cause was fixed with the 1.0.0 release: When disconnecting a wire from a breadboard, the connection would not be immediately removed from the bus. When a new wire was connected to the same (now apparently unused) column/bus on the breadboard, it would pick up that orphaned connection, and therefore also the corresponding connections in the PCB or Schematic.

2 "Copper0 ghost connections"

• Create a wire in PCB, between THT components.
• Go to schematic view.
• Double click the ratsnest line corresponding to the copper1 connection in PCB (only double click, no other operations) Now, sometimes (50-70%) this it would trigger and additional abstract connection in the PCB, on copper0 layer, but it will stay invisible and do no harm. Until...
• Now you delete the wire in the PCB. Everything still looks fine, you see a ratsnest line because there is still a wire in the schematic.
• Now you go to the schematic view, and detach (not delete) the wire on one side.
• You go back to the PCB: Problem! The ratsnest line is still there, although there should be no connection at all anymore.

We have a partial fix for this, going to be included in the 1.0.2 release. I say "Partial" because it does not fix already corrupted circuits: one has to manually wiggle the wires and it will go away. New ghost connections from this bug should not appear anymore. Ideally we would detect the copper0 and copper1 duplicates, but this is not straightforward, as it is perfectly legal to have a PCB connection on both layers at the same time. An automatic fix would therefore be risky.

3. The "voltmeter ghost connection" This one right here. It seems to be a new case, it still happens even with the fix 1 and 2. My guess is that it is related to how the voltmeter does not have a PCB view, but we did not debug deep into the data yet. It might be that there is a virtual connection in the PCB view, although there aren't even connectors for the voltmeter. A visual difference to 1 and 2 is that there is no visible asynchronous behavior = no doted line drawn.

We are adding automated tests and a verification class, so over time it should also be possible to refactor data structures for more inherent safety.

[KjellMorgenstern]

Hiding previous post since it lead into the wrong direction.

We are requesting a node from ngspice that does not exist in the netlist. getVectorValueOrDefault will then return 0. The difference will still be calculated, and we get a wrong reading.

--- a/src/simulation/simulator.cpp
+++ b/src/simulation/simulator.cpp
@@ -556,10 +556,14 @@ double Simulator::calculateVoltage(ConnectorItem * c0, ConnectorItem * c1) {

    double volt0 = 0.0, volt1 = 0.0;
    if (net0 != 0) {
-       volt0 = getVectorValueOrDefault(net0str.toStdString(), 0.0);
+       auto vecInfo = m_simulator->getVecInfo(net0str.toStdString());
+       if (vecInfo.empty()) return 0.0;
+       volt0 = vecInfo[0];
    }
    if (net1 != 0) {
-       volt1 = getVectorValueOrDefault(net1str.toStdString(), 0.0);
+       auto vecInfo = m_simulator->getVecInfo(net1str.toStdString());
+       if (vecInfo.empty()) return 0.0;
+       volt1 = vecInfo[0];
    }
    return volt0-volt1;
 }

The patch seems to work, but ngspice will still log the error about the non existing node.

[failiz]

Good catch!