Detecting colors and signal duration. Is it possible?

[Bentz32]

if the file didnt open 

[Albert.Geven]

Hi

This file did open

The other did not, so something rotten on the newest file.

But what is the real problem.

The sorted retrieve  is handling all blocks in sorted order.

The idea is to move the motor position depending on color and size according the table in the diagram. So for each color, size combination a specific combination of the motors will be used.

I can explain later today as I'm also working on a program and have to finish this.

Just look again. the table that is fed to the retrieve has all the needed info, but maybe you have to edit that. And you are allowed to edit those tables.

[Bentz32]

Hi

Appreciate that you take time to look into this while you're busy 🙂

We absolutely have messed around with the retrieve table in the block diagram. We understand that this is what determines the positioning of the motor for each color and size, just like how the sorting table works for determining the arms movement.

However, we don't quite understand, after scanning and sorting ex. 8 bricks, how we can order just 1 specific out of those (and then order another different one after).

Now, it seems like when we press "retrieve now" after a complete sorting sequence, all of the listed (processed table) are fed into the sort and crunched table (in the UI). Now if we press the button again, nothing happens...

I dont know if the system tries to order every single brick at the same or what? Something is not working right tho.

For this reason, so that I know that we can get it done by Friday, I would consider going for the new UI as I tried to explain to you. A simple UI, with 8 different buttons, linked to 8 different subVIs. Would also like to list the processed blocks (like we have now) to get sort of an overview for the user of what has been sorted.

I'm thinking that since we already have predetermined spots for each block (not random positioning), then it wouldn't be wrong to solve it this way. 

Let me know what you think when you have time 🙂

Thanks

[Albert.Geven]

Hi

I had a few problems to load all of the sorter, so I keep to a minimum.

They are sorted now in color and length first color and second length.

This is done in one go with the sort function in LabVIEW.

The for loop handles all blocks after each other and you want to control for each block that you see what happens?

This can be done by a small extension in the last for loop.

As far as I can see you don't need several subvi's because the functions are the same but the values of the motor controls differ.

Above you see the addition of an extra frame and a while with inside a wait for 100 ms.

This 100 ms is just a value to prevent the LabVIEW to take 100% cpu power while waiting for a keypress.

But effectively that is done here. move the first brick of the list out and wait until somebody presses the next button below.

You can also use the lightbulb for debugging to slow the system, but here you should be able to see what happens for each block.

[Bentz32]

Thanks again, Albert!

This looks very promising, but I don't know if I explained the issue well enough for you. From what I could tell by what you just presented (I might be wrong), you can now order one brick at a time (this is good), but you have to follow the cronological order in which they are fed to the "sort and crunch"? 

The thing is that our examinator will ask (when sorting process is done) for ex. 3 arbritary blocks that we have to order for him/her. Leaving the rest of the blocks in the storing component. (This is why I thought making buttons for each brick was easier)

And bonus question; did you get around to see why we got problems reading brown blocks? I have in the sorting table, made brown "true", but the length measurements are still wrong compared to the other colours.... was thinking that brown is not defined in the case structure where "blue..red" or something is displayed.

Appreciate it

[Albert.Geven]

If the teacher would ask such thing, you can add a checkmark to each block in the sorted array and only transport out those. Is it sufficient to only add a checkmark to the colors and length array, so all short blue etc will be removed after pressing retrieve?

I'll make a suggestion for that.

[Bentz32]

Sadly, no 😞

We should be able to order only 1 of the desired color and size.

Ex scenario: 

1. Machine detects and stores these bricks:

2x2 red, 2x2 red, 2x2 blue, 2x4 blue, 2x4 red, 2x2 yellow, 2x2 yellow

2. Teacher wants us to order the following:

1x 2x2 red, 1x 2x4 blue and 2x 2x2 yellow

We should be able to order exactly this, and leave everything else sitting. Hopefully this explains it a bit better 🙂

[Albert.Geven]

Clear.

Instead of a checkmark you need a count to remove.

so only remove so many as is indicated.

Correct?

[Bentz32]

Yes, exactly. 

So if I understand correctly, this is how the UI will work:

1. When pressing retrieve now, all the processed blocks will be fed to "sort and crunched"

2. From here, one can select with a counter how many of a specific brick one wants out... I think one brick at a time is sufficient, and i fear that doing 2 at a time (of the same color and size) will be hard for the system to handle.

3. Once a brick is selected, we press "retrieve now" again((?) - maybe make another execution button?) And this will activate "retriever" subVI with designated constants from the table in block diagram window. 

4. Repeat 3

Is this somewhat correct?

[Albert.Geven]

indeed

but instead of pressing retrieve again, you will need to press next after each processed block.

I'm implementing this at the moment.

My problem was solved. I started with an older version....