DSP Robotics Support

There's an input in the 0-1 range. The idea is that the float at the bottom right holds the lowest value by only updating if the input value is less than that float value.

What happens instead is that the float value is always set to the input value, but it only updates when you either click inside the schematic window or drag the mouse across the highlighted connector.

What am I missing? Thanks.

I don't know why that would work... but this should
The bottom primitive is "Sample and Hold"

just by view....at least the trigger order is wrong. The connection from input to the validator should be the first and the one to the trigger switch the second.
Can't say why the trigger is killed. You can do it with an added s/h prim like i did and it should work fine...



EDIT: oddson was faster...

Oh... yours doesn't work because the output triggers are being supressed and the comparison operator is not getting the updated values.

oddson wrote:Oh... yours doesn't work because the output triggers are being supressed and the comparison operator is not getting the updated values.

hmm... i don't see a surpressed trigger. It's a matter of trigger order. This one works fine. At least here....

I didn't mean yours... I didn't know you'd posted when I added that.

But you're likely right that it's not PHI's problem either. I do think the Boolean trigger is simpler and clearly a sample and hold is needed.

oddson wrote:I didn't mean yours... I didn't know you'd posted when I added that.

but looking at yours i ask myself if that really does the job well? I guess the true to trig is not the way to go because it needs to become false before a new trigger can be sent IIRC?

I tried to 'play along' on my own here ... also tried to understand what the circuit needed to do.

I did wire up the examples you guys posted ... but to be honest ... none of them seem to do what I thought was to happen.

Probably the 1st issue is me not clear what is needed. The 'Peak Hold' label gave me the impression that we might
be looking at a type of VU peak 'bug' indicator ... but I'm not sure of this ...

So like ... I've been a lot of help

stw wrote:just by view....at least the trigger order is wrong.

Sorry, yes, I had already changed that but the behavior didn't change.

oddson wrote:Oh... yours doesn't work because the output triggers are being supressed and the comparison operator is not getting the updated values.

Hm, that's odd. I would expect it would be able to draw the value from the float without triggers passing through like that. I still don't really understand the propagation of triggers in this program.

stw wrote:but looking at yours i ask myself if that really does the job well? I guess the true to trig is not the way to go because it needs to become false before a new trigger can be sent IIRC?

That's true; good catch. I wouldn't have realized that if you didn't point it out. I think with the trigger switch it's doing the trick.

Thanks everyone.

Propagation of triggers is not that bad.
...gets a little bit worse if there are too many ambiguous loops of trigger flow.
So - what do you need to be explained again?