Open failiz opened 2 months ago
And now I tried to change some wires while doing a transitory simulation. I moved a wire in the breadboard and it created a spice netlist where the name of the nodes are different, see below:
This means that will not be able to modify wires during the simulation. Not sure if there is an easy way to make the code to make it deterministic. Please, note that the netlist should be identical as I am changing one view (BB) but the items are still connected in the other (SCH).
This might be introduced by usage of QSet or QHash when generating the list.
We had a similar problem with the search in sketch feature. Before 1.0.3 it often resulted in irritating matches. After we prioritized exact matches over substring matches, we still had to make sure the result stays in order when de-duplicating and looking up the view items. For this, the KDToolBox::DuplicateTracker class was very useful. See 25b3f720
It is not introduced by QSet or QHash. I modified the code to use a list instead of a Set, and it still happens.
I think it is caused by the scene()->items() which is used to generate the netlist. I am calling it from the schematic sketch view, but there are connectors from other views too. (If I remember correctly Fritzing, makes a wire for each of the views). And thus, modifications on the breadboard view (e.g., removing a wire or adding a new wire not connected in one end) produce a different list of connectors items to generate the netlist (even though the "netlist" electrically is equivalent), but the order of the components and the name of the node changes.
Problem
The same circuit (I tried with flipflop_led_flashing_circuit) does not produce the same results all the time. Launch Fritzing and observe how the circuit behaves differently (sometimes the green signal spikes first, other is the blue one). This is a tricky circuit and chaotic in the beginning. It seems that the order of the components in the spice circuit matters in this case. I exported the netlist of the two behaviors and they are different (components are placed in different places):
Proposed Solution
Make that Fritzing always produces the same spice output. In this case (the order of the components), it is just annoying, but changing the name of the nodes of the circuit could have strong consequences if we go for loading new netlists every time there is a user interaction in the circuit.