LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

My graph does not look as expected!!! Can someone help?

Solved!
Go to solution

I am measuring pressure from a system. The system would build up pressure for 2 seconds, then release it for 1 second. In other word, the solenoid valve closes for 2 seconds to build up pressure, then opens for 1 second to release pressure. So the pressure would go up to around 140 psi, then come down. It would repeat this cycle.  So with this small information. I'm expecting my waveform graph to look like this below.

GRCK5000_1-1673881828012.png

 

But instead, I am getting this below and I can't figure out what I am doing wrong. I have attached my VI. 

GRCK5000_2-1673882120797.png

I just can't figure what I'm doing wrong. 

 

P.S: My comments on the block diagram says 2 minutes and 1 minute. It should be second(s). Sorry about that. 

 

0 Kudos
Message 1 of 12
(1,510 Views)

I don't see anything wrong with your graph or your program (except, of course, for your "style" -- aside from not using more-appropriate "Wait" functions (like "Time Delay" or "Stall Data Flow", both of which can "sit" on the Error Line, there is absolutely no excuse for using the space-wasting "Sequence" structure, now that you've learned to use the Error Line to sequence your code.  You can use a single Error Line for both the Digital In and Digital Out, branching it to have the Time Delay occur in parallel with  the Analog Sampling (which you want to finish first, but not start timing until the sampling starts, I presume).

 

You take and plot 1000 points at 1 kHz, and that's what your plot shows.  So what's the problem?  Your code says "Write a False to the Digital Line" (does False open or close the valve?), then take 1000 points at 1 kHz (1 second delay) and plot the results, then wait at least another 100 ms until 2 milliseconds from the start of the program elapses (which puts us at 1.1 seconds, more or less), then write True to the Digital Line, wait another 100 ms until 1 ms from the writing True to the digital line elapses, and you are done.   Your graph shows a plot up to 1000 msec, which is what you requested.

 

Bob Schor

0 Kudos
Message 2 of 12
(1,485 Views)
Solution
Accepted by topic author GRCK5000

The vi acquires 1000 samples at 1 kHz. Total time: 1 second. The graph is as expected, I guess.

Maybe you can have a little better results with my modified vi (definitely not optimized, though).

Paolo
-------------------
LV 7.1, 2011, 2017, 2019, 2021
0 Kudos
Message 3 of 12
(1,483 Views)
Solution
Accepted by topic author GRCK5000

Your code makes absolutely no sense!

 

I would start with a simulation and substitute the hardware IO later. Here's a quick draft (based on my earlier example). You can easily adjust the logic depending if an open valve increases or decreases the pressure. The overall logic will not change. Modify as needed.

 

You can easily substitute your valve control and pressure reading with minimal changes.

 

altenbach_0-1673893966009.png

 

 

.

Message 4 of 12
(1,455 Views)

Thanks Pinkpanter! I am able to capture everything. The graph looks complete now.

0 Kudos
Message 5 of 12
(1,403 Views)

I knew my code wouldn't make no sense to Mr. Altenbach. 😂

Thanks a lot for the feedback/correction. I like that simulation, but the only problem I have with simulations is, sometimes they can hide the status of the system. For example: if the valve is not doing what it's supposed to do (open and close), the simulation will keep working, showing a perfect waveform chart or graph. This is why I'm afraid of using simulation. 

But this is what I have now based on the code you helped me with. Any feedback based on my comment?

GRCK5000_0-1673967323913.png

 

0 Kudos
Message 6 of 12
(1,394 Views)

@GRCK5000 wrote:

I like that simulation, but the only problem I have with simulations is, sometimes they can hide the status of the system. For example: if the valve is not doing what it's supposed to do (open and close), the simulation will keep working, showing a perfect waveform chart or graph. This is why I'm afraid of using simulation. 


 

The simulation tests the algorithm, they don't hide anything because there is no external "system". The simulated valve is doing exactly what it is supposed to do, and if it doesn't it is easy to tweak the code until it does. Troubleshooting code is much easier and faster if you don't constantly need to spin up external hardware. You can easily expand the simulation to e.g. introduce exceptions to test error handling (not shown).

 

You only need to write to the DO if the boolean has changed. No need to hammer it with the same value with every iteration of the loop.

 

Now you are halfway there. What's left is to replace the lower part of the code with the pressure measurements.

0 Kudos
Message 7 of 12
(1,383 Views)

That makes sense. Thank you for the clarification !

So I decided to modify my code to look like this below. What do you think?

GRCK5000_0-1673974894435.png

Also, rather than posting another question. I thought I would just keep this thread going by asking about water hammer. I have watched a couple of YouTube videos. Now I have a better understanding of what it is. So let's say I want to measure the pressure of the reverse flowing of water when the valve closes. Do you think the  code below should work? (see attachements)

GRCK5000_1-1673975474017.png

 

 

Download All
0 Kudos
Message 8 of 12
(1,367 Views)

When embedding images into a post, please select "image size large" (default is medium when pasting directly) so we can actually see something without having to constantly click on things.

 

altenbach_0-1673976260710.png

 

Message 9 of 12
(1,361 Views)

Sorry, I don't have LabVIEW 2021 on the current computer, but using "variant to data" on a waveform makes absolutely no sense!!! What was the thought process to even place that? (see also)

 


@GRCK5000 wrote:

Do you think the  code below should work? (see attachements)


The proof is in just trying 😄

0 Kudos
Message 10 of 12
(1,359 Views)