Creating a pressure drop shut down function

[otr1990]

Hello Labview-Community,
I have to set up a measurement system for determining the equi-biaxial stress-strain-ratio of elastomers. Therefor I want to blow up a circular membran with air in the shape of a ballon by means of a proportional-valve and two sensors (pressure, rate of flow). I used the Producer-Consumer-Design to gather the users test parameters and to send it to the Consumer-Loop. I made this because the whole community adviced it like that in this post:
https://forums.ni.com/t5/LabVIEW/basic-problem-with-making-a-UI/td-p/3780749

So far everything is working according to plan, but the material test will go until the circular membran breaks. So i like to add a detection of the material failure. I can either detect it with a pressure drop or with a increasing rate of flow. These two types are at least the ones that came directly into my mind. But anyway when the material failure is detected, I'd like to end the flat sequence in the consumer loop, and replace the last value (the value when the elastomer breaks) with the value 0 (valve is closed). As you may see, the bolean input parameters of the user interface go into a case structure in the consumer loop. I wanted to use the "False"-constant in the producer loop to turn true in the consumer loop, if a pressure drop/material failure is detected. Unfortunatly do I think, that a case just runs all the way through to the end and then turns into the material-failure-case (case 4,5,6,7) (boolean array). Then I tried it with an event structure, but it doesnt seem to work, cause my shutdown lamp never lighted up. And I'm worried that I get stuck into the event or is there a possibility to return to the timeout-event? I'm open to any new suggestions, that fullfill the following requirements:
In case, that material failure is detected:
-stop the current task in the consumer loop (basically flat sequences inside a case structure)
-replace the last value with the value 0, so the valve closes
-dont stop the producer and the consumer loop, so the user can directly start a new test with a new elastomer specimen.

Thank you for attention and everything else!
Tobias

[EcthelionV]

I recomend you to use the Queued Message Handler arhcitecture, is more robust.

Greetings!!!

[wiebe@CARYA]

---

@EcthelionV wrote:

I recomend you to use the Queued Message Handler arhcitecture, is more robust.

---

Note that in the referred thread I recommended the study of PC, SM, and other architectures.

The link to the QMH show an architecture almost exactly like a typical PC. Haven't looked at it very long, but I think the differences are not going to provide robustness, and might even make things more complicated.

I personally this any architecture is overrated, including QMH, PC and SM.

The problem with any\all of these architectures is that people then to see it as a final solution. So everything ends up in the architecture as raw code.

And that's why I like OO. Every peace of code ends up in nice tiny VI's. Every VI does exactly what it is supposed to do, as it's part of the puzzle.

I'll try to dig into the original question, but right now it will have to wait.

[crossrulz]

---

@otr1990 wrote:
...I'd like to end the flat sequence in the consumer loop, and...

---

What you really need here is a State Machine.

[crossrulz]

---

wiebe@CARYA wrote:

I personally this any architecture is overrated, including QMH, PC and SM.

---

The real problem with architectures is that people try to use a single architecture for every problem without thinking.  The lack of thinking just causes all kinds of issues.

Architectures are a great thing.  But there is no such thing as a silver bullet.  Each architecture has a use.

[wiebe@CARYA]

---

@crossrulz wrote:

---

wiebe@CARYA wrote:

I personally this any architecture is overrated, including QMH, PC and SM.

---

The real problem with architectures is that people try to use a single architecture for every problem without thinking.  The lack of thinking just causes all kinds of issues.

Architectures are a great thing.  But there is no such thing as a silver bullet.  Each architecture has a use.

---

Exactly, "one size fit's all application design" is a terrible thing. If you have a hammer, everything looks like a nail...

I find myself simply building the blocks, and (iteratively) put them together one way or the other. The result might in fact be exactly like an AF, PC or what not (SM not so much). But I chose exactly what I need, when I need it. I don't like an architecture\framework\template to tell me what to do and when to do it.

So when I said architectures are overrated, that is coming from someone who knows most of them... They are great as a stepping stone.

I'm more into patterns now. As I see it, they provide the same stepping stones, but at a slightly lower level.

Guess we're not helping the OP much...

[otr1990]

---

wiebe@CARYA

Guess we're not helping the OP much...

---

You do, if you also suggest me to investigate further on state machines. I really looked up the properties of the mentioned designs (SM, PC). They alwalys pointed out the benefit of queueing tasks into a line, without losing information (PC), but I wondered what this characteristic offers me in my  case 😄 I have no need for queueing tasks without loosing them. I just need a single task to be done and in case of a pressure drop the task has to stop.

[wiebe@CARYA]

Well, if you can get away with a simple sequence, don't use a SM, PC, AF, or what not. Make a sequence! Init, Start, Check, Stop, Optionally Repeat. Sometimes it's as simple as that, and simple should be the primary goal! Well, maybe second to actually being functional...

Or you can use a sequence for the HW loop. Then you probably need some architecture (or custom design) to separate the UI from the HW loop.