LabVIEW
moving elements from array to array
- The circled area defines the array elements (cluster of some named scalars so we can do "by name"). Of course it needs to match the elements of the array in e.g. "1. queue 1". we cannot tell from a picture what that is!
- Why did your turn the 2D array constant into a 3D array constant???? Resize the index terminal back to two to make it 2D. Do you understand arrays at all? You cannot get three elements out of a row if there are only two columns.
Obviously, a picture can never tell most of the story that's why you need to attach your VI!!!!
@dannn2020 wrote:
But i added a third column to the cluster, so in one row im going to get 3 numbers,
I attached my VI below.
- Never attach a new VI with the same name as an earlier, very different vi!! Keep the confusion low!
- The blue array constant only has two columns, but you are trying to read three.
- A cluster does not have "columns", just elements.
- The cluster constant only has two elements. you cannot wire it to an array that has three elements in the cluster. (Since that cluster occurs in many places, make it a typedef so you can change the type anywhere at once).
Your cluster constant and most of your array indicators only have two elements. Unlike arrays where the size can change, clusters are fixed.
You continue to get stuck with very basic concepts and I still recommend to use all the training resources offered. You don't learn to swim by diving off a cliff into the deep ocean full of sharks.
Back to the problem: Once you have more than one limited queue in a row, you also need to correctly deal with "backpressure", i.e. with situations where an element expires, but cannot go to the next queue because there is no room.
As I already said, create a typedef for your inner cluster so you can change it everywhere at once. Are you familiar with that? Then think of a scalable solution that can deal with an unlimited amount of queues without any changes in code. It's not rocket science. For the queue display, you could use a 1D array of clusters, containing a queue. Then have a 1D array of queue definitions, where each element is a cluster of min time, size, etc. The rest should fall into place.
Just drop a [indicator | control | constant resp.] into each cluster container and make sure it has a label (else you cannot use "by name"!).
As mentioned twice, learn about type definitions to make life easier! Once the cluster is a typedef, just edit the typedef and all instances will automatically follow. Better than herding cats!
OK, to give you something to chew on, here's a very quick attempt at a scalable solution. I am sure it can be improved.
All you need to do is change the typedefs to include the fields you like and fix up the display. Leave the management fields intact (queue#, tick, etc.).
To better trace how the queue behaves, I only add a sequence number (increments with each entry) and an iteration number (depends at what loop iteration the button was pressed) to each entry. Just replace with your fields.
Place a diagram constant of the desired type (orange, blue, pink, scalar, array, etc. etc.) on the diagram, show the label, give it a useful name, then drop it into the cluster container.
As I already said, make it a typedef! Do you know what that means? Note that once it is a typedef, you edit the typedef to add or remove elements.
@dannn2020 wrote:
I spent all night trying to study this and from what i understood, there is a few extra things that i dont necessarily need, and for example the time elements spend in specific queues is randomly generated not selected. (but i have all that).
.
You don't need to study it, just fully understand it. Most of my code can be re-used for any similar problem by just changing the typedefs and making some minor adjustments. Leave the queue managements items, add what you need, remove what you don't need! Should not take you more than 5 minutes.
