Some sort of trigger issue

TomC · 11 Jul 2009

Dunno if this is the problem in your schematic here, but I've had similar problems.

Have a look into your "x(t) >= x(t-1)" module:

- the float input goes into the float AND and trigger input of the (unnamed) module below

- in this module, the trigger goes to BOTH "Float Sample and Hold" (FSAH) primitives

My guess is that because both FSAH get the trigger at the same time, the one at the bottom does not yet see the changed value from the upper FSAH primitive when the trigger shots.

My workaround (from memory) was to delay the trigger to the bottom FSAH by a couple of ms with a timer.

Tom

oddson · 12 Jul 2009

Thanks... in writing up something to tell you why you couldn't be right I've discovered that the problem is coming from that setup. I still think there a bug and possible more than one - or perhaps two bugs that only show when connected together in just the right way.

Here's how that thing was supposed to work:

When the float is altered it is fed to S&H1 where it sits waiting for the trigger.

Since outside the module the trigger input is connected to the same float value a trigger is fired to S&H2 which updates with the output from S&H1 which is still the old value - transferring this value to it's output for the comparison. Then the second trigger goes to S&H1 to update it's output to the new value while S&H2 still has the old and now the comparison is what I want. The problem that I didn't think of is that in between it's comparing the old value to itself and therefore will always have a true output for an instant before it's getting to the actual comparison. So an integer S&H is needed so that he comparison output is only released on the second trigger getting to S&H1.

So I tried this and now I'm getting False values to show at the exterior comparison (the one shown in the screenshot from my first post) but it seems to be delayed until the next trigger is received - at which time both inputs show as True... 😕

oddson · 12 Jul 2009

There's also the issue of why I needed to have trigger from the float fed separately though another module instead of just connecting directly from the float but when I do the behaviour is different.

TomC · 12 Jul 2009

oddson wrote: Thanks... in writing up something to tell you why you couldn't be right

So the behaviour I described (which, of course, was right 🙂 )was intended by you. Okay, I didn't knew that.

Tom

exonerate · 12 Jul 2009

oddson wrote: There's also the issue of why I needed to have trigger from the float fed separately though another module instead of just connecting directly from the float but when I do the behaviour is different.

Here's a fix......

Haven't bothered looking into the exact reasons why that fixes it. My guess though is the trigger from the "current timecode" input is causing the boolean and to happen before the "x(t) >= x(t-1)" module has done it's thing.

Cheers 😉

Exo

oddson · 12 Jul 2009

Thanks... doesn't work for what I want yet as the trigger switch the boolean is feeding still doesn't work.

infuzion · 13 Aug 2009

I notice this weird mis-firing of values in some of my green schematics also, especially when they get larger with alot of connections. I use a workaround by sending a final trigger to my output. You can also experiment by changing the link order.