Heres a link to mindstorms software if you wanted that 🙂
- we used the 2015 32-bit
I leave you with a VI with a lot of textboxes explaining issues and some pictures of our complete system so that maybe you get a clearer look on what we're trying to do ...
My first advice is to keep wires as straight as possible and code as readable as possible.
I did no see major errors but as a "lazy brain programmer" I really cannot handle all the wire edges and at the same time see what happens. Just an advice, the compiler does not care but your mind does.
You can replace my color enum with the original LEGO enum and I would make sure that all color enums have the same type definition. If you see somewhere a red spot (as after the black enum at the upper right), this is a sign that the compiler adds a type conversion in the wire. Remove all these conversions by only using the original Lego color enum and not mine anymore.
Of course is it possible to show what is inside as color and timing, but you probably only want it at detection of a brick not each loop of the while so add it inside the detection case and use an array of detected clusters for that.
I will edit an example for that after dinnertime.
Thank you for taking the time... Really appreciate it!
I leave you a notepad-doc with som further explenation of the problem...
What you measure is milliseconds with noise from how many times the color measuring vi is running.
This is totally depending on speed of the color measuring vi. You can compare the speed of the system to the speed of the belt to see if the timing is realistic.
In your RTF I see that the first constant still generates a red dot at the shift register input, so hat one in the picture is probably still my version.
The compare itself is very fast so something else accounts for the differences.
I am downloadling LV12 now with LEGO (and will seek the old disk above) and can give you better examples afterwards. (Windows claims 2..9 hours for the download, but most of the time it is faster.
A flash of insight: you should detect black again and then use the previous color to act on the block.
Anyway a simple version of a cluster each time a new block is detected.
I've added a document trying to explain what happens with the comparison-block (less, lessandequal), and how it changes the measured length for some reason.
This is what holds us back from making any real progress at this time.
Thanks for the help! 🙂
I guess, that you enter this case with the wrong assumption.
The timing should start on a change in color from black to any color and stop on the switch from that color to black again. What I see on your screen is that the previous color is black in one and the previous color is green in the other occasion.
I made a slight change in my last .vi, did you use that vi or your edited your own version to get this result.
Maybe the transition is not as immediate as expected, instead of switching to black, an intermediate color can be detected at a boundary, That could cause a problem, Or a transient happens sometimes.
Send me your vi in which you found these results and I try to modify the logic to be more stable.
The screenshots i sent you are from the same code as you sent us yesterday, except we removed some of the blocks with the red square-thingy, just to try (couldnt really replace them with lego enums because we dont really know what replaces them...
When using your code, program works fine; it displayes corrrect previous and current color... The reason it shows black as previous, is because when system notices a different color, the previos one is naturally the black "default" color...
However, we still get the same measurement problem when applying the comparator...
Hi Albert, the legend!
We've added a few ideas to the VI and left a document explaining how we'd like the ordering system to work.
The less or equal comparator is still altering the length measurement... We cant seem to find any solution to this and it kind off holds us back
Thanks for all the help 🙂