WIP: Auto orient analog components

[kasbah]

Just experimenting a bit with auto-orientation. So far only with resistors in the analog examples. It's a brute force approach, going through all the different combinations and I am trying to find a good metric. Everything just seems to favor complete vertical orientation so far.

Minimizing bendPoints seems like it could be a good metric and would allow for some horizontal components if it wasn't so awkward at placing them. E.g. for the common_emitter example this could be a total of 3 bendPoints (1 less than when both resistors are vertical) if the vin chain to the base of the transistor was straight:

• resistor_divider
• common_emitter
• and

[kasbah]

I just found out about postCompaction and set it to 4 which I believe is LEFT_RIGHT_CONNECTION_LOCKING. All the strategies seem to improve all graph layouts in a similar way but I found some edges crossing a node in one case when using EDGE_LENGTH. Here is the common_emitter with the base resistor horizontal again. It doesn't actually impact the bendPoints count though. I guess those are not joined/removed.

• resistor_divider
• common_emitter
• and

[kasbah]

I've implemented my own way of counting the bendPoints (ignoring any bendPoints that are on straight edges) and that seems to select good graphs. It's favoring having as many vertical resistors as possible while minimizing bendPoints. I also made it discount bendPoints that are going to output labels as that seems to help with the examples I have.

• resistor_divider
• common_emitter
• and

[dvc94ch]

That invokes netlistsvg 2^(two-port) times. As I said I'm not sure all users prefer that to specifying the direction manually.

Is there a reason this can't be performed in replicad?

[kasbah]

Yes, I am making no claims of great efficiency. It seems to at least be bearable for the examples. Nitpick: if added here it would invoke elkjs.layout 2^(n two-port components) times, and elkjs does seem to be pretty darn speedy.

Anyway, for the time being I am just playing around. If anything is added here it should be behind an option as to not impact other use cases. If it's better to put it into replicad then I'll put it there but there is nothing replicad specific at all to what I am doing.

postCompaction should definitely be the default as it improves all example layouts, I'll do a separate PR for that.

Just trying the mcu example.

before:

after:

[kasbah]

Doesn't yet fare so well with the full common emitter example from pycircuit.

[kasbah]

@dvc94ch how did you get the pycircuit common_emitter to look like that in the readme?

When I run the example with current netlistsvg I get:

[dvc94ch]

Not sure, not too many commits have been made, see which one caused the change... It still can be flackey sometimes even with the correct ports and orientations...

[kasbah]

Ah thanks, yes, looks like it was the addition of lateral tags with f72ac93bf48f8427cb0b4b7c7c0c39e1d95a4e67. What do you mean by flakey? Just a bit odd looking schematics sometimes?

[nturley]

Whoa. Post compaction looks awesome! I need to try that. That might solve a lot of the issues with the ELK layouts that I was running into.

[nturley]

This capacitor is backward.

Reverse it and it should look much better.

[kasbah]

Not much better unfortunately.

@@ -19,16 +19,16 @@
         },
         "C2": {
           "connections": {
-            "A": [
+            "B": [
               70
             ],
-            "B": [
+            "A": [
               10
             ]
           },
           "port_directions": {
-            "A": "input",
-            "B": "output"
+            "B": "input",
+            "A": "output"
           },
           "type": "c_h"
         },

I would be interested to try and force input labels to be all the way to the left.

[kasbah]

Rebased this onto #42 and it makes the mcu example almost perfect:

Full common emitter is better too, though you can see some of that weirdness mentioned in #42 going on in some variations.

• mcu
• common_emitter_full

[kasbah]

Today I tried to feed it this Charlieplexing netlist.

It doesn't do so well with any orientation unfortunately.

[amstan]

For my circuits I found that the vertical capacitors works best. Most capacitors were decoupling, therefore one or both of the ends were going to a GND or a VCC. Horizontal capacitors were rare, the only places I can think of is:

• series capacitors in filters
• those AC coupling caps in the class A amplifier example

Similarly with resistors: pull-ups / pull-downs, if one or more pins on that resistor goes to GND or VCC, make it vertical. Though there are more places where I use horizontal resistors and regret them being so derpy due to lack of port swapping:

• 0 ohm resistors connecting 2 signals
• current measuring shunts
• series termination

I'm not saying that auto orienting wouldn't be cool, but it's not the end of the world to not have it so far.

PS: Re https://github.com/nturley/netlistsvg/pull/40#issuecomment-397060391 The ideal would be for the diodes to be vertical and resistors to be horizontal. So ignoring auto orienting logic, does netlistsvg yield something compact? If not then your bend minimizing logic won't really detect this ideal orientation as optimal (so it shouldn't really be blamed).

[amstan]

Yep, the charlieplexing example looks pretty horrific even with directions hardcoded:

After some port swapping (R3 was backwards, hooking up even numbered leds backwards since we don't support 180 rotation yet):

Looks a little better to me as a human, but there are a few bends in there, probably because of other elk layout choices, so I'm still not sure your bend metric would have picked this one above the first picture.

Regardless, I think the input to your combination trials shouldn't just be a matter of is it "_v" or "_h", you also need to consider the 180 deg rotation, that will essentially solve port swapping too.