LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Run a for loop on a boolean latch


@hhart wrote:

The outer for loop was a placeholder, since I could not figure out which structure was supposed to go in its place. I said that in my initial post.

 

Yes you did, but was thrown in with a lot of other words about needing to build a 2-D array.  And you even said "if that makes sense" which it obviously did not.  That bit of information got lost in the noise.


 

"I have attached a version of what I want to do with a second for loop in place of what I want to be a loop that will run the inner contents once and then reset, while compiling the data into an array."


 

What you  gave me takes two measurements from the same dial gage at the same time and then leaves it there. I need there to be one measurement taken when the take data button is pressed, adding onto the top or the bottom (it doesn't matter which) every time the user presses it. Then, the resulting array will record to an excel spreadsheet after the user is done collecting data.

 

 

No, I gave you back exactly what you gave me. which was N measurements 1 for each gage, then repeated twice.

I think you just haven't adequately described what you really want.  I don't understand why there is a Take button and a Record button.  Is there ever a situation where you don;t want to "take" the data?  And it would be impossible to record data if it hadn't been taken.

 

What I THINK you want is an application that runs continuously grabbing data from the gages.  (I would want to see what the gages are reading even when I'm not recording.)  And only when the user presses record does it write to the file.

 

0 Kudos
Message 11 of 18
(1,279 Views)

Nope. The gauges work by reading the number on their screen when they are passed an 'r'. Continuously reading data would be unnecessary. In the meantime, I have solved the issue myself. I attached the VI so you can see what I was talking about, since evidently you had an issue with my explanations. solution.png

 

Thanks for the effort, though.

0 Kudos
Message 12 of 18
(1,274 Views)

@hhart wrote:

NI have solved the issue myself. I attached the VI so you can see what I was talking about, since evidently you had an issue with my explanations. 

 


 

You get good advice, then you post garbage code and mark it as solution. Please unmark it!

 

Your code is highly flawed and should not be highlighted as solution. Did you even test it?

 

  • The inner sequence structure has no purpose. Delete it! (The same execution order is already fully determined by dataflow)
  • The timeout event is non-functional. it will wait forever. So why is it there?
  • The VI cannot be stopped (just aborted!) because there is no event for the stop button.
  • If you would add a stop event, It would potentially write a file with no data on the last iteration
  • Use "Buit array" instead of "insert into array" to append a row.
  • The file I/O probably belongs inside the "take data" event frame.
  • The terminals of latch action buttons belong in their respective event frame.
  • Since you are writing to a new file with every trigger, but the shift register stores all data since program start, your subsequencet files will grow progressively larger and contain more and more stale data.

 

0 Kudos
Message 13 of 18
(1,266 Views)

Unmarked. Thank you for your help, but I will look elsewhere for advice.

0 Kudos
Message 14 of 18
(1,251 Views)

@hhart wrote:

... but I will look elsewhere for advice.


Where exactly? (I would recommend some simple  tutorials. :D)

 

Here is actually the best place to get good advice. Guaranteed! So please come back after learning some of the basics!

0 Kudos
Message 15 of 18
(1,243 Views)

I will not be returning. I have continuously seen rude responses to people who are genuinely confused and have exhausted all other options. I use this forum as a last-ditch effort before talking to my (very busy) coworkers, but I guess even as a backup, productivity is impossible through this forum because of the disrespect. You should take a look at the spanish language NI forum for reference on how to approach people looking for help.

0 Kudos
Message 16 of 18
(1,238 Views)

I think you have that backwards. The "approach" is done by the person looking for help, not by the person helping.

 

Several very good people tried to help and ask for clarification where it was needed to solve the problem. 

 

Explaining the question clearly and asking nicely without immediately starting basless arguments goes a long way to receive polite answer. It is a two way street. I think the main problem here is a language issue, so if you are more comfortable asking in a different language, please do so. Language is also very likely the reason that you misundestood the tone of the replies and interpreted them as rude by mistake. Please re-read this thread again. Maybe use google translate to look for alternative translations into your language.

 

You might also want to change your signature. Some people might not recognize it as such and think it is intentionally added in response to their post . It makes people less friendly if it is read as a personal attack. Think about it!

 

0 Kudos
Message 17 of 18
(1,233 Views)

@hhart wrote:

Nope. The gauges work by reading the number on their screen when they are passed an 'r'. Continuously reading data would be unnecessary. In the meantime, I have solved the issue myself. I attached the VI so you can see what I was talking about, since evidently you had an issue with my explanations. 



A couple of things you said there don't make sense.

 

"The gauges work by reading the number on their screen when they are passed an 'r'".  Okay.  Fine.  I assume you have that build into the Read Gauge subVI which is where that would belong.  It doesn't have any effect on whether you take a reading when you hit a button, or continually take a reading.  At the level of your application, conitnually taking a reading means consistently running that subVI.  That it sends an "r" and reads a response each time it is called is just the lower level implementation in the subVI and doesn't affect how your application runs.

 

"Continuously reading data would be unnecessary".  Why is it unnecessary?   What is the harm if you do continually read the data?  It is running on a PC which is intended to do mundane tasks over and over again.  Pushing that work onto a user to constantly click a TAKE button every time sounds like a bad user experience.  Especially when you couple that with asking the user to hit a record button if they decide to keep the data.  If you don't want the reading of data to happen too fast, slow it down with a wait statement.

 

"since evidently you had an issue with my explanations."

The problem I have is that when you say something, I decode what you said and try to give you something that you want, then you go say it is all wrong because of some other reason that you never really said before.  I like challenges and like to be able to help people.  But when they come back with an attitude and seem unwillingly to help us help them, then there is nothing more than I can do.  I will stick in there for a short time hoping that they just need a tip in the right direction and that helps them see the light and get over the problem.  If someone is obstinate and not willing to listen or learn, then I'm just not going to keep banging my head against the wall.

0 Kudos
Message 18 of 18
(1,220 Views)