A simple int box. It's driving me crazy! Any tips?

[tulamide]

I'm working on a solution for this. I'm almost done. There's just one little thing that prevents posting it...

The following works very well. But, at every start of the loop, the marked integer box needs to be set to -1. That also works very well, as long as I do it manually. But everything I tried to automatically set that box to -1 right before starting the loop just failed. I know that it fails because of the triggers. But if I work with trigger blockers, sample & hold, etc., the results are wrong (mainly because the needed triggers now also don't come through anymore). I can't believe that something so simple, as setting the int to -1 only works manually!

So does anyone have a solution? Or a tip? Anything?

scheme.jpg (227.98 KiB) Viewed 15595 times

[KG_is_back]

Use green selector, connect -1 to true input and what you have there to false. Then setup comparator to be true on first loop and false on others (I can't see from where to where you're counting) and connect it to the selector.

[tulamide]

Thank you KG. Unfortunately, as soon as it switches to the false input the select prim sends out triggers. That leads to a second calculation of the already calculated value (the first time the marked int will be 5, the second time it should be 8, in this example). So instead of using 5 (which leads to 8), it recalculates 5, which results to 11 (at least the calculation is correct ).

It gives me headaches

[tester]

Place somewhere sample and hold prim(s) and retrigger them only once to avoid feedbacks. This will pass values only once. Triggers in this design seem to be "bonded" so to speak (i.e. not separated by timers for example), so they should follow trigger order. In this case the S&H trigger will go from the point (the loop prim?) where the thing starts shooting (remember about trigger order).

[MyCo]

The int box is inside a green connection loop (its output is indirectly connected to its input). There is no simple way to fix that, because every trigger that changes the box goes through the "add" primitive and changes the int box again. It needs some S&H primitives and some "Last changed". Unfortunately you posted just an image and not a schematic...

[tulamide]

The int box is inside a green connection loop (its output is indirectly connected to its input).

Yes, that's on purpose. The equivalent of "n += somefunction(n) + x". At least that's what I try to achieve

Unfortunately you posted just an image and not a schematic...

Not on purpose this time. I just thought it's something, where the experienced ones just shake their head and say: "come on mate, don't you see that you just need to ..."

Here it is! And thank you for the descriptions. Although I know what you mean, I couldn't get it working. So, if you have a minute or two...?

[trogluddite]

This has it, I think...

intboxissue FIX.fsm

(2.08 KiB) Downloaded 862 times

As MyCo says - always post a schematic. Fixing a problem like this is not easy without knowing the semantics - exactly WHAT you are trying to achieve. In this case, knowing the purpose has allowed some other optimisations, as well as the fix for the initial problem. The whole thing immediately made sense once the clever 'arrays within an array' structure could be seen (very nifty!).

- The FIX. A 'Last changed switch' that sets the start value - note the trigger order, it is set before the loop begins. A trigger blocker inside the feedback loop prevents runaway triggers - the output from the 'Get' is enough to update the new index.
- The second "get at" is now only triggered when the loop is done, not every single iteration.
- The 'sample and hold' at the end ensure that the final output only triggers once per operation.

Note that there is something odd about the 'Array Section' primitive. Usually a trigger at any primitive input causes all other inputs to update their value - this would suggest the optimisation of trigger blocking the 'start' input. But this particular primitive doesn't seem to do this, so there's no way to update both the start point and the count without it updating its output twice - hence the final sample and hold to ensure "one in - one out" triggering for the module as a whole.

[tulamide]

Thanks a ton, trog! I was trying to get this working for 3 days now!

- The FIX. A 'Last changed switch' that sets the start value - note the trigger order, it is set before the loop begins. A trigger blocker inside the feedback loop prevents runaway triggers - the output from the 'Get' is enough to update the new index.

So easy, if you look at it now. I wonder why I couldn't think so logically? Thank you so much.

- The second "get at" is now only triggered when the loop is done, not every single iteration.

Very helpful, again so logical, and again I didn't see it

- The 'sample and hold' at the end ensure that the final output only triggers once per operation.

Note that there is something odd about the 'Array Section' primitive. Usually a trigger at any primitive input causes all other inputs to update their value - this would suggest the optimisation of trigger blocking the 'start' input. But this particular primitive doesn't seem to do this, so there's no way to update both the start point and the count without it updating its output twice - hence the final sample and hold to ensure "one in - one out" triggering for the module as a whole.

Very important information! I've learned quite a lot from just a small issue! Did I already say thanks?

Well, who cares? Can't be said enough. Thanks!

[MyCo]

Was playing with it... My version uses the previous value instead of another "Get Array"

[tulamide]

Wow! I have no clue, why or how your solution works. Which simply means, I will have a fun time exploring the module! It seems to be a more lightweight solution in terms of cpu load (just guessing from the lower number of elements used). As soon as I understand the inner workings I will incorporate it. Thank you very much for taking the time and showing me optimization