On my computer, Cirkit Designer is very slow. Loading the program and a drawing takes several minutes. Any time I change a wire or component, that also takes about 10 seconds.
Is there anything I can do to improve performance or is this an inherent problem with the software?
I’ve been using both the MAC AND Windows versions on some older machines 2015 vintage with no problems.
Rendering can be slower with larger circuits (> 80 wires) but even then that is only when moving chips that are maintaining the connections and re-routing a large number of wires. Still only a second delay, nothing similar to what you appear to be experiencing.
Leevi
Hi Jim,
Thanks for sharing your issue, and my apologies for the inconvenience. In general, the slow speed is related to some inefficiencies with auto-routing the wires, which I do have a solution in mind for and which we can prioritize in an upcoming update.
Just so I can make sure the problem is resolved for your case, do you have an example file I could test against? If you want to keep your data confidential, you could also submit a bug report in the app.
Best,
Austin
Austin,
Nothing particularly secret here. The camera trigger takes about 90 seconds to open in Cirkit Designer. I had to rename these from .ckt to .cirkit to upload them.
Camera Trigger.cirkit (24.8 KB)
Prototype Shield.cirkit (24.8 KB)
The prototype shield is my attempt to create that part. Essentially though, it should have ground and power busses like a breadboard and the groups of three pins should be connected, also like a breadboard. Is there a way to do that?
Jim,
Thanks for sharing this circuit, that is very helpful!
After taking a look, I was able to identify the bug causing the slow down, which I have a short-term solution you can use now, while I work on a proper solution in an update.
The problem is with the power and ground lines connected to the pot (see the first attached image). Specifically, the ends of the wires (connecting to the breadboard’s power rails) are within a bounding box of the part, which confuses the routing algorithm.
If you move the ends of those wires so they are outside the bounding box of the pot, Cirkit Designer should speed up for you.
I’m also working on a more general solution (which I’m targeting for an update over the next week), but I hope this helps in the mean-time.
I saw that you attached a second file (Prototype Shield), but it looked the same as Camera Trigger - I just wanted to check if I’m missing something, or if there was a second circuit to take a look at.
Thanks again for reporting this issue.
Also, we don’t have a way yet to link the pins within a component definition, but we can definitely add that behavior.
Austin
Original:
Wires Updated:
Updated File:
Camera Trigger.ckt (24.9 KB)
Austin,
Thank you. That helps and it’s much faster now.
I thought I’d saved the shield as a component, but apparently that didn’t happen.
This should just have the shield in it.
Prototype Shield.cirkit (320.5 KB)
Jim
Regarding routing, the automatic routing is nice, but I really wish it were possible to put a wire in “manual” mode and both to change which pin in the breadboard it connects to, or drag one or more handles to move it. For example, the dark blue and the highlighted yellow wires in my layout don’t route as well as in your version of the same file.
Jim,
I’m glad the temporary fix is helping.
I have a working general solution that should really speed things up. I’m also going to work on getting the “manual” wire manipulation completed as part of this upcoming update.
I’ll keep you updated of my progress and let you known when we’ve released the update (ideally around 1 week from now). I’ve also fixed the bug with newlines in the text labels, which will be part of this update.
By the way, thanks for sharing your proto shield component! I understand what you mean about linking the component pins now. In terms of the behavior of these pins, I think it would make sense that any wires connected to these pins are colored the same since they belong to the same net. Is there any other custom behavior that you think would be helpful?
Austin
I have a similar issue, and I don’t have any component bounds inside another component.
If I do anything with the following design, it takes about a minute to redraw. I created a few of these components, and the pins are not on grid… Could that be an issue?
It would be nice to be able to manually route.
Hi Gary,
Thanks for posting your issue!
I agree that the placement of the custom component pins is contributing to your issue.
The core problem/bug for both your circuit, and Jim’s above, is that the auto-routing algorithm is redrawing all of the wires in the circuit every time a change is made. So a single slowly routed wire is affecting every change on the circuit.
The fix we’re working on will address this by only auto-routing a newly placed wire (leaving everything else unchanged). Also, you’ll have the ability to manually manipulate the wires.
This is a prototype of the update we’re hoping to release next week:
Austin
I thought the issue was if one component was sitting on top of another component, which I don’t have.
Are you saying that pins placed inside the boundary of a component will cause this problem? If so, I can edit the component and place the pins just outside the boundary. Would that help?
For Jim’s case, one of wire ends on the breadboard power rail overlaps a component, so that wire takes a while to route. And since the algorithm is re-routing all of the wires each time (including that wire), the issue is present every time a change is made to the circuit.
Jim’s problem isn’t occurring in your case - it’s perfectly fine to define component pins over the component as you’ve done.
I think the slow-down is coming because the pins aren’t defined on the grid - in that case the algorithm uses a much finer path to route the wire. For a single wire, this increase in time isn’t really that much, but it becomes an issue since we’re re-routing all of the wires every time a change is made.
I think there’s a much better chance of seeing a significant speed up once I push the fix, so I think the best bet would be to wait for that.
Thank you for taking the time to respond!
Not being on grid was the other thought I had.
I’ll go ahead and redesign those parts with the pins on grid, and will be eagerly awaiting the next version.
I created a few components with the pins on grid, and as you suspected, the redraw is much faster. A single wire was taking close to a minute on my first circuit above. Wires go in on this design in 5s.
When you have the ability to manually move nets, it would be nice if the user could lock the component positions. I occasionally grab a component when trying to run a wire, and don’t notice until I start dragging. This messes up the layout, and requires a much slower redraw.
Gary,
Where did you get the image of the prototype shield?
Austin,
This is the same kind of shield I’ve been asking you to include, but a better image. The ideal solution would be to make it like the breadboard, where the connected pins are actually connected.
Hers’s an image of the Adafruit shield:
I used my iPhone to take the pics of both components in that test layout. I had to take it from about 2 feet away to reduce the parallax effects.
I tried using my scanner but the focal length was too short. I may try that again, as it would give me a pic I shouldn’t have to scale.
For the motor driver shield, I used a .1 inch grid transparent overlay that extends slightly further outside the component to make it easier to scale the component to match your grid in the component editor.
Gary,
That’s great to hear that positioning the pins on the grid helped with the speed issue!
I can see how that would be frustrating if you lost your manual wire placement by accidentally grabbing a component - we’ll definitely consider adding the ability to lock components. I’m not sure if we’ll be able to get that into the release this week, just because of timing, but likely in a follow-up release.
Jim,
Thanks for mentioning! Since the behavior is a bit more complex than existing components, we probably won’t be able to get this into the release this week, but we’ll definitely look into adding this in a follow-up release (adding the Adafruit protoshield to our library as well as the ability to define similar functionality in the component creator).
Austin
Been there, done that.
Nothing worse than creeping elegance!
How’s the release coming along?
