Bi-Directional counter w/loop

trogluddite · 21 Jan 2011

Here's one I use from my toolbox. Not sure if it's the best way to do it, but it works OK.

sunsynth · 21 Jan 2011

And here the one with corrected trigger series:

1-2-Many · 22 Jan 2011

Thanks guys!

Sunsynth, your example was immediately instructive since it built off the familiar. Turns out I merely had the trigger lines from the Down trigger hooked up in the wrong order in my version. Swapping them makes it work! Although your mode selector is much more elegant (and simple).

...And Trogluddite - WOW! All done with simple logic, very impressive.

infuzion · 23 Jan 2011

Thanks guys; much better than the one I invented a year ago!

trogluddite · 23 Jan 2011

1-2-Many wrote: WOW! All done with simple logic, very impressive.

He he, just one of my little idiosyncracies - for some reason I always prefer to use discrete primitives rather than magical 'black boxes'. I learned most of my sequential logic stuff on early digital electronics hardware (good old 74LS... logic chips), so it seems easier to me doing it that way - I can see exactly what's going and measure values/count triggers at the deepest level.

1-2-Many · 26 Jan 2011

The following is a problem I PM'ed to Trog - thought I'd include it here for instructive purposes.

Also, please note the schematic is also wrong on the min & max values set for the counter (currently 1 & 10). It appears that the array is zero indexed, so to get the numbers 01-10, the counter needs to be set at 0 & 9 for min & max.

Hi Trog, I'm using your counter in a project, but the project (not your counter) still keeps counting in the same direction for one click when changing directions. I suspect it's due to weird triggering behavior from the getat primitive.

Here's the OSM -

Any help greatly appreciated

trogluddite wrote: Hi there,

The problem is actually with the edit box module - connect a string primitive direct to the array output and you'll see that the Get At updates correctly.

If you look inside the edit box, you'll see that the string input splits in two - one goes on to update the edit box itself, the other goes to the ReDraw primitive. The problem is with the order that the data is sent down those two links - you can see the order from the little 'tick' marks on the links, right next to the connector - the link with no tick marks gets updated first, then one tick, then two etc. You can see that the ReDraw link is the first in order - so the GUI gets redrawn first, then the edit box primitive gets the new string. So the screen is redrawn while the edit box still contains the previous string value, not the current one - so it's only what you see on the GUI that is wrong, the actual edit box primitive will contain the correct value.

The order of the links is determined by what order you created them in. So by deleting the link to the ReDraw and then connecting it again, you can reverse the order - so that the GUI refresh will wait for the data to update.

On links that have multiple inputs, you can change the link order just by clicking on the connector - but unfortunately, for multiple outputs, you have to delete and recreate all the links to do it. That's a shame, because the order of links can make a huge difference to how a schematic runs - it can be a real ball-ache sometimes trying to get it right, even after years using SM!

The Luddite

sunsynth · 26 Jan 2011

Index starts at 0 and a refresh trigger at the label input was missing!

infuzion · 17 Oct 2011

trogluddite wrote: Here's one I use from my toolbox. Not sure if it's the best way to do it, but it works OK.

I use this for a few things, but found 2 bugs. So I could not help reducing it while I was there performing surgery. infuzion v02 edits: assumes min = 1 reduced triggers has memory, so remembers value when you save OSM The Set value now sets "After Load" fewer parts

DigitalWhiteByte · 18 Oct 2011

This is my version without math operators, only logic switcher.