Who thought it would be a good idea to limit max size of the user defined grid in Pcbnew?!

[Art]

Right now the only way to create an array in Pcbnew for manufacturing is to do append board and then copy and paste that board multiple times. (at least the only way I know) To paste it precisely you need to set up the user grid so it would be your board dimensions plus whatever spacing you want to have. It worked fine on previous versions. Now somebody decided that it would be a good idea to limit max size of the user grid to 50mm. I get a warning message: "Incorrect grid size (size must be >= 0.001 mm and <= 50.00 mm) Why? What purpose can it possibly serve?! Now it became an even bigger pain in the butt to create an array. Do you guys have a competition there to see who can make life of a hardware developer the most difficult :)

My version is 2015-07-21 BZR 5970 on Windows 7 64 bit

[Wayne Stambaugh (stambaughw)]

I'm sure it seemed like a good idea at the time to whoever changed this.
 Here is an excellent example of an unexpected perfectly valid use case.
 Whoever clamped the user defined grid size, please change it back so
this poor user can get their work done.

On 8/12/2015 1:32 PM, Art wrote:
> ** Description changed:
>
> Right now the only way to create an array in Pcbnew for manufacturing is
> to do append board and then copy and paste that board multiple times.
> (at least the only way I know) To paste it precisely you need to set up
> the user grid so it would be your board dimensions plus whatever spacing
> you want to have. It worked fine on previous versions. Now somebody
> decided that it would be a good idea to limit max size of the user grid
> to 50mm. I get a warning message: "Incorrect grid size (size must be >=
> - 0.001 mm and <= 50.00 mm) Why? What purpose it can possibly serve?!
> + 0.001 mm and <= 50.00 mm) Why? What purpose can it possibly serve?!
> Now it became an even bigger pain in the butt to create an array. Do you
> guys have a competition there to see who can make life of a hardware
> developer the most difficult :)
>
> My version is 2015-07-21 BZR 5970 on Windows 7 64 bit
>

[Nick Østergaard (nickoe)]

This was changed in rev 5837

http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/5837

[Art (diametrix)]

Nick,

That's great! Can you change the upper limit to something ridiculously large?

[jean-pierre charras (jp-charras)]

50 mm Grid is already something ridiculously large.
With large grids, the on grid graphic cursor, most of time, cannot even be moved (the near grid point is of screen).
Which can be also seen as a bug.

So I am reluctant to allow a more ridiculously large grid.

Matrix duplication is not limited in size.

Panelizing a board (on GAL mode) using the matrix duplication after select the whole board takes less than 10 seconds.

And duplicated boards are perfectly aligned.

Or I missed something in your request.

[Art (diametrix)]

First of all my web search produced no results for GAL mode or matrix duplication when referred to KiCad

Ether you are using unofficial terms or there is no mention of them on the net. If you are referring to an OpenGL or Cairo canvas it will be a while before I make a switch to those and meanwhile my life just got so much more difficult.

Now about your objection. If you are going out of the way to enter large values into user grid and then go and actually select user grid from the menu and then think that it is a bug because you can't move the cursor while being zoomed all the way in - well in that case you probably shouldn't be design electronics in the first place. Trust me, that wouldn't be the most challenging thing to figure out in KiCad. It seems to me that intentional nature of the change works as a grantee of that not happening accidentally and confusing the user.

Besides you logic brakes down even with regular size gird. I can select any standard grid size then zoom in when only one grid dot is visible and then I would be unable to move the cursor as well.

[Nick Østergaard (nickoe)]

@Art, the reason for not much google results about it is probably because it is such an good feature that it does not need very much description and the fact that is is a new feature not included in the old stable.

The submitter of the feature has even written a good section about the tool in the manual. Please read http://docs.kicad-pcb.org/Pcbnew/Pcbnew.html#_array_tools and see if it can solve your issue.

[Art (diametrix)]

Like I previously stated, I don't use OpenGL or Cairo yet for the reason being it is not stable. But ok, for the sake of the experiment, lets try it. Open a new pcb (I don't want to actually have an array of boards in my main design) Switch to OpenGL - append my board. Nothing happens. Hmmmm. Switch back to default canvas. Append board here. That works. Go back to OpenGL. Now I have two boards here 8| That's ok, easily fixed. Now do an array on the entire board. Nothing crazy 5x2. Thinks for a while and then barfs out with out of memory message (that's on a Windows 7 64 bit system with a 16Gb and then gives non-stop "Vertex allocation error"

Like I said, not ready to switch yet. So I propose not to mess with what works for now until the latest and greatest thing is proven to work.

As a side note - why would you want to have less than more to begin with? Wouldn't you rather have a tool that can do more rather than less? And you have to go out of your way to make it less capable on top of that. Why would you intentionally hamstring the user?

Another side-side note. Technically, array capability would be extremely useful while generating Gerber files, but that does not really fall into the scope of this discussion.

[Nick Østergaard (nickoe)]

How big is your board? It sounds to me like the memory usage needs to be handled in a different way if your run out of memory. Please take your time to report that array issue in another ticket such that we can work on it.

I don't understand your side note. The array tool is more, rahter than less, and keep in mind that you _should_ be able to do everything you can do in GAL that you could do in legacy. If you find some feature that is not present in GAL, feel free t report it. But keep in mind there are minor intentional behaivour changes in GAL compared to the legacy canvas.

We talk about this because you are (mis)using the grid to create arrays, when there exist a tool to create arrays.

[Art (diametrix)]

@Nick

Let me address this misusing statement first:

1. This was the only way to create arrays in the older version of KiCad
2 Any other versions have not been released and/or proved stable

Now, if you agree with two statements above, tell me how am I misusing the grid to create arrays?

I don't care much at the present time to post any bugs for any other versions for the simple fact that I haven't tested them. When I get to the point of being ready to switch I will readily do so. Until then would you kindly refrain of breaking tools that work, even if is just a lowly legacy version.

My previous illustration was just to highlight the fact that you assumed that the new feature works fine in the new version. I just illustrated that your assumption is incorrect. Have you actually tried to create an array of multiple boards by appending a board file and then attempting to create an array from that?

The side note was not referring to the "tool", it was referring to the legacy version of KiCad. By introducing the limit on the size of the grid you made it "less" flexible.

My board is not big at all. It is 2"x 2" with components placed only on one side.

[Maciej Suminski (orsonmmz)]

Hi Art,

I feel sorry to hear about the issues you experience with KiCad. We do our best to provide possibly useful tools, but mistakes are inevitable given the software size and rather inadequate manpower behind the project.

I see your frustration caused by the OpenGL canvas incompleteness. While it still a work in progress, I know people (including me) who are able to design a board without a single switch to the legacy view. Right now we put all our efforts to make the new canvases stable therefore we really appreciate people who are willing to risk a bit to help us fix potential problems.

The problem related to board appending you describe was fixed in revision 6068, but perhaps it would have been fixed earlier if someone has reported it. It is very challenging to fix bugs that we never heard of, that is why we rely on our users good will to report problems. I believe the other error ('vertex allocation error') might have been already fixed as well, but you have to check against the newest revision. If the problem persists, please let us know (include the video card model & driver version you use).

In an attempt to convince you to the method Jean-Pierre has suggested, I prepared a video [1] that presents steps to panelize a board in pcbnew (excuse the artifacts, it is a fault of recording software). I used a more complex board with a desire of reproducing the vertex allocation error, but it went fine here. I hope you find it easier than using snapping to grid option.

Regards,
Orson

1. https://vimeo.com/136376400

[Nick Østergaard (nickoe)]

@Art, not do derail this ticket I will happily discuss your case on #<email address hidden>. Please keep in mind the content of #10.

A bit more related: I did use the misusing of using grids to align stuff earlier in the footprint editor, here it works quite well when you set the grid and the grid origin, then you can place pads quickly. But now that we have the align and distribute feature together with the move exact tools it is way easier to create stuff.

[Art (diametrix)]

Just discovered another reason to be able to use bigger values for the grid. I needed to place an origin point for the place file. The point would have to go to the corner of the board. I can look up the value of the beginning of the pcb edge cut line defining the edge of the board and find precise coordinate where the origin should go. Technically, there should be a tool that would allow you to jump to the manually entered coordinate. Short of that, the other way of doing it is to set up grid the size of the coordinate, which you can't because it is limited and it doesn't let you do that.

[Art (diametrix)]

And another reason: trying to do a board outline drawing just became so much more difficult. Before you would set the grid origin in the upper left corner change grid size to whatever board size is supposed to be and then do the whole outline in four clicks. Now if you lucky you can set it up to 1/10th of the board size and then count key presses like a monkey.

Jean-pierre as you see 50mm is not a ridiculously large value. Is this a simple case of French stubbornness or there is some kind of natural impossibility barrier that can not be physically exceeded, like speed of light?

[Chris Pavlina (pavlina-chris)]

I agree, the grid size should be practically unlimited. If users are bumping up against your artificial limitations, you've stuffed up.

> 50 mm Grid is already something ridiculously large.
> With large grids, the on grid graphic cursor, most of time, cannot even be moved (the near grid point is of screen).
> Which can be also seen as a bug.

This is silly. The same argument could be made for zooming in. In reality, I think we have too much respect for our users to think they're dumb enough to be confused by snap-to-grid. I'm totally in favor of removing the limitation, and I really hope other people can voice their agreement here, because I don't think Art and I are the only ones who find unlimited grid sizes useful. I use the grid in a similar way - I've also tried to use it for board outlines, just like you said.

Also, Art, stop being rude. Take your comments about "French stubbornness" elsewhere. Makes me uncomfortable to be on your side.

[Art (diametrix)]

@Chris

You are right. Stubbornness knows no borders or nationalities. I take it back. If there is a way to edit the post let me know, I will take it down.

> Makes me uncomfortable to be on your side.

It's not like you joined the dark side :)

[Chris Pavlina (pavlina-chris)]

> If there is a way to edit the post let me know, I will take it down.

Take a deep breath, count to ten, and think, before you post - that's the most foolproof way I've found as of yet to edit posts. A few developers have reportedly found meditation and/or medication useful in this.

[Art (diametrix)]

Chris, if you look at the date the thread was started you would realize I had more than enough time to take a lot of deep breaths. I guess it is time for medication now :)

[Chris Pavlina (pavlina-chris)]

Lord knows I could use some.
On Feb 3, 2016 8:01 AM, "Art" <email address hidden> wrote:

> Chris, if you look at the date the thread was started you would realize
> I had more than enough time to take a lot of deep breaths. I guess it
> is time for medication now :)
>
> --
> You received this bug notification because you are a member of KiCad Bug
> Squad, which is subscribed to KiCad.
> https://bugs.launchpad.net/bugs/1484207
>
> Title:
> Who thought it would be a good idea to limit max size of the user
> defined grid in Pcbnew?!
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/kicad/+bug/1484207/+subscriptions
>

[Jakub Kozdon (fldrivers)]

I think the same, the maximum grid size should be unlimited :)

[Jakub Kozdon (fldrivers)]

Why the maximum grid size is still limited ?

Simple thing is to change maximum grid size in dialog_set_grid.cpp

from

#define MAX_GRID_SIZE ( 50.0 * IU_PER_MM )

to (1 m as example, but this can be sufficient for most)

#define MAX_GRID_SIZE ( 1000.0 * IU_PER_MM )

[Jakub Kozdon (fldrivers)]

Of course .. here is the patch.

[Novak Tamas (novak-7)]

A year passed (middle Aug 2016 now) and nightly 7060 still has the grid limitation at 50mm.
Now I set this to a Wish...maybe something will be happening in the not-so-far future.

[Jeff Young (jeyjey)]

The patch date is old and so it appears way down the list where no one sees it.

Of course it's also old enough that it won't cleanly apply, so I've re-created it.

Just to prove that nothing is easy, this has to be applied AFTER the Grid Dialog changes that go with Michael's menu changes.

[KiCad Janitor (kicad-janitor)]

Fixed in revision ea1474307c8b56f8956fb9db7313573805d7f549
https://git.launchpad.net/kicad/patch/?id=ea1474307c8b56f8956fb9db7313573805d7f549

[Wayne Stambaugh (stambaughw)]

@Jeff, I'm not sure making the grid larger is what the bug reporter had in mind but I went ahead and merged your patch anyway. I'm sure there will be plenty of squawking if it is not adequate. Thanks!

[eelik (eelik)]

In general creating artificial limits is a bad idea. I know this as both a programmer (an open source developer) and an end user of programs. I can understand jp-charras' concern for viewing/snapping problems, but it's not been demonstrated it has actually happened AFAIK. And from experience, as a former open source maintainer, I know there always are people who find useful use cases for "features" you as a developer don't even know about.

If viewing/snapping problems are a concern, you can always change the "must be under 50mm" dialog to a warning which tells which kind of problems the user can experience. Then he/she's responsible for using it correctly.

I agree with others that Art's tone isn't constructive and doesn't invite to co-operation, but he's got a point. Don't limit users if it's not necessary, don't think nobody will ever need such and such.

[eelik (eelik)]

If my comment seems to be out of place it's because I for some reason didn't see recent actions here before I posted it. Thanks to Jeff Young, Wayne Stambaugh, Maciej Suminski and others who have been responsive here and elsewhere.

[Nick Østergaard (nickoe)]

No worries.

[Art (diametrix)]

@Wayne
<<<I'm not sure making the grid larger is what the bug reporter had in mind

Bigger is better! I guess it all depends on what the new limit is. Think of an average size board, let's say 4"x6". Let's say I want to use it to make an array. So I will need to set my grid slightly larger than 6" in one of the axes. What is the size of the new limit?

I'm not necessarily all or nothing here, but since you mentioned it, why does it have to be limited in the first place? The previous concerns aside (that you won't be able to figure out why your footprint is not moving when you zoom past a single size grid), is there actually some other reason for it?

[Jeff Young (jeyjey)]

The new limit is 1m (~40"). Have at it. ;)

[Wayne Stambaugh (stambaughw)]

I'm guessing the reason this limit was set is because it was (is?)
unknown what will happen when panning and/or zooming bumps up against
the numerical limits of the world coordinates so the limit was set small
to avoid creating the conditions for this to occur. Given that the
resolution of the board coordinates is 1nm that is certainly an issue.
With the 1m grid limit, we may find out what happens when we bump up
against that limit.

On 2/16/2018 1:09 PM, Art wrote:
> @Wayne
> <<<I'm not sure making the grid larger is what the bug reporter had in mind
>
> Bigger is better! I guess it all depends on what the new limit is.
> Think of an average size board, let's say 4"x6". Let's say I want to
> use it to make an array. So I will need to set my grid slightly larger
> than 6" in one of the axes. What is the size of the new limit?
>
> I'm not necessarily all or nothing here, but since you mentioned it, why
> does it have to be limited in the first place? The previous concerns
> aside (that you won't be able to figure out why your footprint is not
> moving when you zoom past a single size grid), is there actually some
> other reason for it?
>