Big size LabVIEW VI

[VUC]

Hey,

I have a very big VI (test_connecting.vi) with included subVIs (Comparison.vi). But I can't connect at the end of VI's block diagram the In Place Element Structure output array with For Loop right shift register inside terminal and save the VI!

Can anyone connect and save the VI?

Cheers,

Evita

[Duffy2007]

Hello VUC,

i can connect but also not save.

Is the intention to sort the array?

[Norbert_B]

I think your loop should look like this:

[VUC]

This VI is to check the sorting algorithm and later on to be implemented in FPGA, but FPGA doesn't support Sort 1D Array in Target.

So now I am stuck with the LabVIEW VI size limit.

Evita

[Norbert_B]

Evita,

the array has to be sorted ascending/descending? Your code currently only swaps even pairs (e.g. index 0 and 1) but not uneven (e.g. index 1 and 2). This does not look right.

[VUC]

For now it doesn't matter what if the sorting is correct.

The problem is LabVIEW dealing with big size VI. Now and then I come back to this problem, but having no successful results I always have to think about alternative solution.

This looks strange that it is impossible to save VI after connecting one wire.

[Norbert_B]

---

@VUC wrote:

For now it doesn't matter what if the sorting is correct.

[...]

---

Uh, well, but that IS the main problem here. Your code is overblown and leads to issues. Not only functional ones... (e.g. readibility!)

If you don't provide information about what the sorting is about, nobody can help you to implement a more efficient (and MUCH smaller) VI to perform the sort.

[VUC]

My question regards LabVIEW capabilities not algorithm implementation.

Is there a size limit for LabVIEW functionality?

[Norbert_B · Accepted solution]

Yes, LabVIEW has limitations in the size of the block diagram and the front panel.

However, I am not sure if your issue is connected to exceeding the limits. I would rather think that the pure amount of subVI calls are the source of the issue.

Why my question on the algorithm is important is because this is how an ascending sort in "brute force bubble sort" would look like:

EDIT: Updated screenshot to be correct. Previous had some issues in the boolean logic for termination.

[VUC]

Thanks for this suggestion, but as I said before, it is planned to be implemented in FPGA, thus the execution must be as parallel as possible.