Trigger component interval is not working

Hey forum!

I’m creating a process inside my definition that “listen” a file in my computer through File Path component and then everything works after this (for now, doesn’t matter the rest). I need to update this component in a time interval to keep tracking changes in my computer as mentioned. So, naturally I thought the Trigger component would do the work, since we can choose the time to update the component.

But, here comes the trouble: when I connect the trigger to the File Path component, it keeps updating the component ou of the time I defined. It works just fine on others components such as number (see the video attached).

Is this supposed to happen? I’m not sure if this is a bug or something, but I could use some help!

Thank you!

That must be a bug. I assume one of the python scripts is triggering updates, or do you see the same thing if they are both deleted?

Hey David! Thank you for the fast Reply!

One script extract a ID value from a data text, I dont think it’s the problem in this one. But in the other i use the sticky variable to address the data to another python component further in the definition.

If I delete both as you mentioned, then the trigger work as expected, but only both of them.

If doing some tests now, I’ll keep you updated.

Ok, I was troubleshooting and then found this:

If I connect my trigger to File Path and then disconnect the python script to the data component, works just as expected (see the video). If I reconnect, then the problem appears.

1 Like

Hey David, I changed to my main acc.

So, I found the issue, but I would like to know your opinion:

When I connect the trigger in my defition that “influences” (let put in this way) some component from MetaHopper, then this happens.

So, being said, Is this a problem within R7 and GH or with MetaHopper? Andrew is very active in the forum, I will ask him about this issue also.

Thank you in advance David!

1 Like

I’m pretty sure the problem is with the trigger. It fires at the specified intervals but also whenever there’s a new solution for any other reason. Just a hunch that, I’ll need to check to make sure once I get into the office.

Yeah it was a bug. Every trigger would always expire all its targets on every solution, even if that solution wasn’t caused by the trigger. It should be fixed in the next Rhino7 release. Logged under RH-62138.

3 Likes

Nice! I’m glad for the support, David!

Thank you! Have a nice 2021!

ok, I have a really weird question on this topic

I have just found this while troubleshooting a definition where a trigger was connected to multiple script components

(Rhino 7.3.21012.11001, 01/12/2021 here)
is it expected behaviour for the trigger component to auto-enable disabled components connected to it when its clock is started?

random stupid example
image
Trigger_autoenables.gh (13.4 KB)

It’s an option of the trigger object.

I have tried both “free target object” and “lock target objects”, for sure I’m missing something

initial state, timer stopped, no trigger connected:


Trigger_autoenables_re.gh (17.2 KB)

after connecting the triggers:

when the timer is started:

all this leads me to think that a component connected to a trigger is forced to output its data, regardless of both its initial state being “enabled” or “disabled” and the trigger-option being “Free target objects” / “Lock Target objects”

of course I’m 200% fine with this :slight_smile: I just expected any disabled component to be “dead” and not allowed to output any data unless deliberately revived