check disconnect/reconnect behavior when changing voltage on a power symbol

[davidperrenoud]

From tjtomk...@gmail.com on January 22, 2011 05:01:12

What steps will reproduce the problem? 1. Create a small circuit using power.fpz
2. Modify power value to 3.3 or 12 volts
3. Try to save circuit

What is the expected output?
Expected outcome is a saved circuit.

What do you see instead?
The application crashes.

What version of the product are you using?
Fritzing 0.4.4 (b4641)

On what operating system?
OSX 10.6.6 Please provide any additional information below.

Original issue: http://code.google.com/p/fritzing/issues/detail?id=1326

[davidperrenoud]

From irasc...@gmail.com on January 22, 2011 08:51:49

Crashes under Windoze as well.

If the part is unconnected before the voltage is changed, then there's no crash. When you change the voltage, and the part is connected, the wire is deleted, and the direct cause of the crash is that somehow the wire isn't completely removed, and so when trying to save the partly deleted object there's a crash.

The reason the wire is deleted is that when the voltage is changed, the power part tries to connect to a different net (using a new wire) with that voltage. Maybe some other approach would be better.

Status: Accepted
Cc: daniel.t...@ixds.de andre.knoerig

[davidperrenoud]

From tjtomk...@gmail.com on January 22, 2011 13:18:36

I tried to recreate the issue using your workaround, I have a circuit already heavily populated including 5v powers. If I perform "If the part is unconnected before the voltage is changed, then there's no crash.", I find the application crashes. I would assume (haven't tried), recreating the circuit from scratch.

[davidperrenoud]

From irasc...@gmail.com on January 29, 2011 14:50:22

r4676 . Added a patch which seems to prevent the crash. Leaving the bug open, because I'm not sure about the current disconnect/reconnect behavior: the disconnect may be ok, but I'm wondering why there's no reconnect.

[davidperrenoud]

From tjtomk...@gmail.com on January 29, 2011 21:39:38

Re-tested; comfirmed correct behaviour. Thx

[davidperrenoud]

From irasc...@gmail.com on July 02, 2011 02:07:01

Summary: check disconnect/reconnect behavior when changing voltage on a power symbol
Owner: irasc...@gmail.com
Cc: -daniel.t...@ixds.de

[davidperrenoud]

From bitsybof...@gmail.com on October 01, 2013 15:43:19

When changing the voltage on a power symbol, all wires in schematic which were connected to it are deleted.

[davidperrenoud]

From irasc...@gmail.com on October 01, 2013 20:10:46

@6: Because it could lead to a situation where some parts are connected to two voltages, though I suppose we could check for this, and leave the wires connected in that case.

[davidperrenoud]

From bitsybof...@gmail.com on October 02, 2013 15:33:50

@7, if this removing-wires-for-label-change-on-power-symbol feature is useful (I beg to differ), it should just remove up to the first bend point.

IMHO, such checking should be done as part of a ERC function, initiated by a user, and left for the user to resolve as with DRC, not automatically on the fly.

[failiz]

When changing the voltage in a power symbol, the wires which were connected to it are deleted. This still happens in 0.9.4. However, I think this is not the right behaviour. Users should known what they are doing and if you put the power pin, wire it and then change the voltage you have to wire it again.
The previous argument ("Because it could lead to a situation where some parts are connected to two voltages") does not seem coherent when you can connect two power symbols with different voltage to the same net and Fritzing does not complain at all.

[failiz]

Remove imported label and add schematic view

[failiz]

This is caused by function SchematicSketchWidget::setVoltage(double v, bool doEmit)
This is the code:

	QUndoCommand * parentCommand =  new QUndoCommand();
	parentCommand->setText(tr("Change voltage from %1 to %2").arg(sitem->voltage()).arg(v));

	new CleanUpWiresCommand(this, CleanUpWiresCommand::UndoOnly, parentCommand);
	new CleanUpRatsnestsCommand(this, CleanUpWiresCommand::UndoOnly, parentCommand);

	QList<Wire *> done;
	foreach (ConnectorItem * toConnectorItem, sitem->connector0()->connectedToItems()) {
		Wire * w = qobject_cast<Wire *>(toConnectorItem->attachedTo());
		if (w == NULL) continue;
		if (done.contains(w)) continue;

		QList<ConnectorItem *> ends;
		removeWire(w, ends, done, parentCommand);
	}

	new SetPropCommand(this, item->id(), "voltage", QString::number(sitem->voltage()), QString::number(v), true, parentCommand);

	new CleanUpRatsnestsCommand(this, CleanUpWiresCommand::RedoOnly, parentCommand);
	new CleanUpWiresCommand(this, CleanUpWiresCommand::RedoOnly, parentCommand);

	m_undoStack->waitPush(parentCommand, PropChangeDelay);

The if we remove the loop that removes the wires, the issue is that the ratsnets are not updated when you change to BB or PCB view. @KjellMorgenstern , any ideas about how to fix this? There are CleanUpRatsnestsCommand and CleanUpWiresCommand before and after the setPropCommand, but they do not have any effect.

The issue is the same in #2669, but in the SchematicSketchWidget::setProp(ItemBase * itemBase, const QString & prop, const QString & trProp, const QString & oldValue, const QString & newValue, bool redraw) function.

[failiz]

OK, I think I found the solution. We need to force the flag of doRatsnest in updateRoutingStatus (SketchWidget). We can do that by adding the connector of the netlabel or power symbol to the list of updated connectors, which triggers the doRatsnets flag when calling checkUpdateRatsnest().

Proposed code (see more in my PR):

CleanUpWiresCommand * cuwc = new CleanUpWiresCommand(this, CleanUpWiresCommand::UndoOnly, parentCommand);
cuwc->addRatsnestConnect(itemBase->id(), itemBase->cachedConnectorItems().at(0)->connectorSharedID(), true);