Reduce list of events

[Simon_A]

Hello everyone.

I have a VI that list all events gathered in a cRIO9053 with NI9215 and NI9472. When i'm trying to see how many times my installation is on a trip order condition i have a lot of entries with the same entry time like the image below.

What i want it's to have one entry for each minute at least, or only one entry, each time the trip order status blinks to on.

My VI's are the following:

  

Someone have a tip about what i can do? I've tryied a while loop and waint until next ms multiple, but it didn't worked as i expected.

Thanks in advance.

[altenbach]

---

@Simon_A wrote:

I've tryied a while loop and waint until next ms multiple, but it didn't worked as i expected.

---

We cannot tell what you are doing wrong unless you show us what you are doing. Showing pictures of code fragments does not help.

What is the code architecture? We can't even see a toplevel loop!

Typically you would keep the current state in a shift register and log if the value changes (i.e. current != previous).

What is the datatype of the "trip condition"? If it is boolean, there is even a "boolean crossing ptbypt" tool of you want to use that.

Please attach a simplified simulation of your VI. Pictures are quite useless.

[Simon_A]

Hello Altenbach

I will try to upload some of vi's that interfer with this events.

[altenbach]

Sorry, my religion prevents me from trying to debug VIs with deeply stacked sequences and dozens of sequence locals. Too painful!

Hopefully somebody else can help.

[Simon_A]

Yeah, i understand that. I'm trying to add new functionalities and rebuild the VIs to optimize code and time, but it's to painfull...

[GerdW]

Hi Simon,

---

@Simon_A wrote:

Hello Altenbach

I will try to upload some of vi's that interfer with this events.

---

To add to Christian's comment:

• How are those VI related to each other?
• They all miss a lot of other VI files, including lvlibs and typedefinitions…
• Attaching FPGA related VIs without their lvproj file is nearly senseless…
• Why is the last element of the timestamp array shown in an indicator labelled "first element"?
• Why don't you (auto-)cleanup the VI blockdiagrams?
• Why don't you replace the stacked sequence by a flat sequence?
• Why don't you replace the flat sequences with pure DATAFLOW as you now see that you don't need a sequence structure at all to "OBEY DATAFLOW!"?
• …

[altenbach · Accepted solution]

To get you started, here's a very quick draft of a VI that adds log entries only under two conditions:

1. A value has changed
2. A certain time has elapsed since the last log entry

See if you can adapt some of it for your purpose.

[Simon_A]

---

@altenbach  escreveu:

To get you started, here's a very quick draft of a VI that adds log entries only under two conditions:

1. A value has changed
2. A certain time has elapsed since the last log entry

See if you can adapt some of it for your purpose.

---

Thank you Altenbach, i will try something like that, but i have one question. When i put the timing set to 100ms i don't have the risk that all the VI's are affected by that timing?

[JÞB]

---

@Simon_A wrote:

---

@altenbach  escreveu:

To get you started, here's a very quick draft of a VI that adds log entries only under two conditions:

1. A value has changed
2. A certain time has elapsed since the last log entry

See if you can adapt some of it for your purpose.

---

Thank you Altenbach, i will try something like that, but i have one question. When i put the timing set to 100ms i don't have the risk that all the VI's are affected by that timing?

---

Altenbach showed you what is known as POC (proof of concept) code.  The loop and timing are there only to allow you to observe the operation.   

Notably,  there is also Value Changed.vim that could be used to detect changes in either direction.  Internally it is very similar to the feedback node and comparison Shown.

[altenbach]

---

@Simon_A wrote:
When i put the timing set to 100ms i don't have the risk that all the VI's are affected by that timing?

---

Your computer is clocked in GHz so 100ms is an eternity and the typical iteration is extremely lightweight!

(It's like saying that the moon looks larger if you stand on a ladder. Yes, you are closer and we can calculate the increase in solid angle from first principles, but is is way below any detectable difference)

One way or another you need to poll if something has changed. (In the case of user changes, we could use an event structure with a timeout to do something similar, bit you are reading the state of an instrument, if I understand that correctly.)

You can easily increase the polling interval to anything you like, but if you make it too long, you might not be able to stop the VI quickly because the loop might take a long time to read the stop button state again. Typically you would incorporate my code into your toplevel loop or other suitable place that spins regularly.

Yes, there is a "Is value changed.vim" to detect value changes, but that's only available in very recent LabVIEW versions. There is also "value has changed ptbypt" for DBLs and "boolean crossing ptbypt" for Booleans. I prefer the explicit version as shown because I can e.g. decide exactly what should happen on first call. (e.g. the vim will always return "changed!" on first call).