Get square corners

[GregFreeman]

This is the route I took to get 4 corners of a square if I have the center and the width/height. Is there a simpler way, or a VI that does this that I missed? Sometimes there are VIs that do similar things drawing palette and I'm wondering if it went overlooked.

[tst]

OpenG has a rectangle palette which exposes some vi.lib VIs to deal with rect sizes. I don't remember if they have this specific functionality or where they live in vi.lib (and, of course, you already have the functionality), but it's an option.

Another option which might work is to take the calculated distances and multiply them by combinations of -1 and 1 and add that to the center. This should probably allow you to get rid of the loop and simplify the code to a single multiplication and addition.

[altenbach]

If it is a square, the width and height are the same, so we have redundant/conflicting information.

If it is not a  square, your angles are wrong.

Are you looking for rectangle solution?

[altenbach · Accepted solution]

Here's what I would do. (I think tst had a similar idea).

You could even get rid of the /2 and simply add 0.5, -0.5, etc into the diagram constant.

 

(of course you don't need the graph code)

[GregFreeman]

---

@altenbach wrote:

Here's what I would do. (I think tst had a similar idea).

You could even get rid of the /2 and simply add 0.5, -0.5, etc into the diagram constant.

 

(of course you don't need the graph code)

---

It's a square, but the VI might as well handle rectangles as well. Thanks!

[altenbach]

---

@GregFreeman wrote:
It's a square, but the VI might as well handle rectangles as well. Thanks!

---

The nice thing is that the LabVIEW polymorphism allows handing the simplified square code with a very small change 😄

 

[billko]

LOL and here I thought I was going to get tips on how to clean up your block diagram!  😉  (You know, "square corners.")

[tst]

---

@altenbach wrote:

Here's what I would do. (I think tst had a similar idea).

---

Yes, that was my second idea.

Looking at the OpenG palette, I see that my first idea was not as elegant. I didn't try hard, but this was the cleanest I managed with those VIs:

It might be cleaner to subtract half the size from the center and use a single subVI and no unbundling.

While these VIs are clearly not optimal for this particular task, it's probably worth knowing them for other things. They live in vi.lib\picture.