Conditional Trigger Misunderstanding

[vitaliy_kh]

@TArman

As I said before, welcome to Event Driven programming.

Nothing is wrong with the Event Driven programming if this is done right.
The firmware on all Embedded Controllers in company I am working for is Event Driven.

EDIT
BTW, I designed number of DIY Controllers using Hubduino + Arduino IDE. Everything is Event Driven and non-blocking.

[marktheknife]

@vitaliy_kh

What is everyone see in a Select Trigger Events field?
My good guess, everyone will clearly see the Condition is True.

@vitaliy_kh

Now Event happened and:

Ops, Log says: Not Triggered because the condition is FALSE.

Just because it was true when the page in your screenshot was last refreshed doesn’t mean it was true at the time shown in the log.

[hubitrep]

@vitaliy_kh

This is clearly a BUG

It's not a bug, it's the same edge case we've been discussing from the start, where both the trigger and the condition are looking at the same attribute, and you expect one to be latched and not the other. IRM is just not designed to work like this and this is an edge case best dealt with a RE. It's an edge case because the general case is that the condition is looking at something different than the trigger and this WHOLE discussion becomes moot.

Unless I'm missing something, seems to me your choices are:

• accept the design and use the workaround (a single RE-gated trigger, calls another rule's action if you have multiple triggers to gate and want to re-use)
• learn groovy and write an app as I suggested above

[TArman]

@vitaliy_kh

The Condition right before the Event is True.
All Actions must be Executed.
Right?
Tell me please what is not right with this picture?

What you are REALLY saying is run rules only if the state is true AFTER THE EVENT OCCURS, not BEFORE the event occurs.

[vitaliy_kh]

@marktheknife

Just because it was true when the page in your screenshot was last refreshed doesn’t mean it was true at the time shown in the log.

Generally you are correct.
But in the above case the Condition was 100% TRUE because only an Event itself was changing a Condition State.

[vitaliy_kh]

@TArman

What you are REALLY saying is run rules only if the state is true AFTER THE EVENT OCCURS, not BEFORE the event occurs.

I am clearly saing Run Actions if Condition is TRUE BEFORE the Event.

[TArman]

@vitaliy_kh

I am clearly saing Run Actions if Condition is TRUE BEFORE the Event.

In you head, I’m sure, but that’s not what you wrote in RM ‘’language”. RTFM

[vitaliy_kh]

@hubitrep

accept the design and use the workaround (a single RE-gated trigger, calls another rule's action if you have multiple triggers to gate and want to re-use)

Yes, the curent implementation is accepted.
I have a clear picture how to deal with this feature.

@hubitrep

learn groovy and write an app as I suggested above

No way I will create any SW Code in any programming language if only LOGS is my tool for the debugging.

[hubitrep]

@vitaliy_kh

No way I will create any SW Code in any programming language if only LOGS is my tool for the debugging.

I have faith in you, stranger Aren't you used to dealing with just a handful of test pins and BIST?

I get it, but it's worth a try. I've taken to write built-in tests in my apps. Create a test instance of the app, assign test virtual devices, run the test. Works pretty well.

[vitaliy_kh]

@hubitrep

I have faith in you, stranger Aren't you used to dealing with just a handful of test pins and BIST?

In a past for the HW debugging I used Oscilloscopes (still using them) and Logic Analyzers. Since I switched to FPGA design Logic Analyzers is not needed anymore.
All my test SW was written in C/C++. And for the debugging I am/was using full scale JTAG Debuggers. Yes, sometime Test Points and Logs are very helpful but not a primary debugging tools. To my eyes using a forest of logs is very inefficient and drives me crazy.