crossrulz

See my first post. The Wait ms Multiple doesn't wait for the desired number of ms. I waits until the ms counter (a global counter) reaches a multiple of the input.

Yep, you are using the wrong wait. On an aesthetic note, instead of using the sequence structure, you might want to consider using a VI like this for the wait. I admit that I took this function from the Bloomy's LabVIEW Style Book and then edited it a little. It uses the error cluster to keep data flow instead of using the sequence structure. It helps keep my code clean. And if you haven't already, vote up this idea in the Idea Exchange. Wait.vi

I'm not sure I fully understand the problem. Posting some code would help the debug process. From my current understanding, it sounds like the Wait (ms) would be the function you want. The Wait Until Next ms Multiple function will sit there until the ms counter reaches a multiple of the programed value. So the first loop you set to 200ms. The Wait Until Next ms Multiple will sit there until the counter reaches 200. Next loop, you set the loop rate to 75. The Wait Until Next ms Multiple will sit there until the counter hits 225. So then you really only had a 25ms loop. Check out this snippet as an example. Note: You may have an output clock value off by 1ms due to Windows timing.

I typically use FIFOs in an FPGA. In my current programs, I use 1 DMA to send data down to the FPGA and another DMA to get data back. I then have one loop that reads in the DMA commands and then sends the commands to the relevant sections of code (I have a digital input, digital output, square wave generation, and specific communication bus sections of code) using FIFOs. By using globals, you can slow down your FPGA since sections of code will be blocked until the other section accesses it. There are times that I used them (non critical timing), but try to avoid them.

This doesn't look like it should work since you have a race condition on your Max Index(es). You really should use wires instead of the value property node. On another side note: locals are better than property nodes for getting/setting a value from a control/indicator, but a wire is best.

I just started thinking about Ton's method. While I don't see the point of the "XOR" and then the "Not Equal to Zero" (just use the "Not Equal"), I think he has the right idea about converting the boolean to a 0,1 and then adding. This does seem like a much simpler implementation.

oops, I originally looked at the wrong file... Where you are falling short is the fact that the arrays need to be predefined. I put data in the locations for a 5x5 array. If you are going to a 16x14, go to element 15,13 (because it is zero based) and put a 0. Do this for the Array control, "previous array" constant, and the "number of changes" constant and you should be good. I would also add a wait to your loop just so you don't hammer your processor. @ShaunR The number of changes is constantly being updated and saved in a shift register. Therefore a value change will not be missed.

I was using the event structure as a simulation so I could see exactly what all of my data was doing when I decided that the "1 second new data" occurred. I was aiming more for the example than the actual code you should use. In reality, you should be getting new data once a second, compare it to the previous data, increment the changed array where necessary. So yeah, get rid of the event structure and replace the data control with your input data (however you are getting it) and exit the while loop however you plan on ending your test.

If you post what you have so far we could help a little better. If reading your CSV is the issue, post an example of the CSV as well.

What you need to do is count how many times each index has changed. To do this, use a second array for just the number of changes. You can use nested for loops to iterate to see which elements have changed and if they did increment that element in the number of changes array. Then at the end, see which elements are greater than 10. Array Changes.vi

I'm with Ton. It looks like your default font size is larger than the standard 13 point.

I'm a little confused about what you are trying to do. Are you looking for 10 of the elements to change (as you stated) or are you looking for an element to change by more than 10 (as you described in your program)? Here's my shot at both. Hopefully this will at least point you in the right direction. Note: I used a 5x5 array to make it a little easier to play with on the front panel. Array Changes.vi

Yes, it takes forever to uninstall and install everything from NI. I would also recommend a registry cleanup. I have ran into problems where I would uninstall all NI software, reinstall, and my problem was still there. I found that I had to delete some registry entries in order to really start clean. Now that I'm thinking about it, it might be easier to reformat the hard drive and start from scratch.

You are almost there. All you really need to do is add logic to find the end of the patches and subtract indexes (see lower half of snippet). Note: If the data ends in a thin patch, you will not get a length out for that patch without some extra logic after this loop.

You might want to look into the Producer/Consumer design pattern and the use of Queues. There are certainly many ways to communicate between parallel VIs (global variables, Queues, Notifiers, Action Engines). Based on what little I understand about your situation, I would say the Queue if probably your best bet. As far as reducing block diagram size (for a main VI), subVIs are your friend, especially if you are performing the same action in different places.

Or just use the Threshold 1D Array primitive (should be right next to the Interpolate 1D Array) on your array of frequencies. Edit: I might have the signals backwards, but the concept is still the same.

If you put in an indicator to see the array before your interpolating, you will see that it has two elements (36, 15370). What you need to do is split the signals and take the second signal (frequency) and then interpolate.

I think this will accomplish what you are after...

They could at least learn to spell LabVIEW correctly (capitalization is wrong multiple times, two words once)

where is this error list you speak of?

It looks like Default Value is a scripting property (at least as of 8.6). So in the development environment, the answer would be yes. No so in an application. A work around may be to save your current value, invoke the Reinitialize to Default (use an invoke node), grab the new value (the default), and then set the value back to your original saved value. Hopefully somebody smarter than I has a better idea than that.

Your problem is in where you are trying to figure out when button was pressed. The state tunnel out of the for loop will only output the result from the last button check (Button 3). If you want to keep what you have, change the tunnel to a shift register and feed the previous value through in the false cases. However, polling controls are BAD. You will be much better off with an Event Structure. NI's example is from right when the event structure was coming out and I have a feeling it was simply upgraded from a previous version long ago. Polling uses up lots of CPU unless you have waits in your loops. An event structure will sleep until one of its registered events have occurred.

I'll take stability over fancy new toys any day!

The most simple way would probably make another consumer loop for showing your non-modal dialog boxes. Have another queue (or notifier) running around to tell the loop to run a certain window. You would be limited to one dialog box opening in the new consumer, but it is a quick and easy way to handle your issue.

Shaun hit the big one. You need to properly shut down your system: turn power supplies, function generators, DIO, etc. off, reset other equipment, close out references and handles. The abort button will not do that. I have troubleshot a program where someone hit the abort button and ran again and wondered why the DIO port was not available (because it wasn't released from the previous run!). My experience, however, is mostly with non-LabVIEW people as my user and 99.9% of the time they do not see my giant Stop button (even though it is in the top right corner) and go straight for the Windows "X". If you don't handle this properly, the VI is still actually running even though you don't have a front panel. This will lead to a similar problem as just aborting. So I don't use Stop buttons anymore and just use an event structure and the "<This VI> Panel Close?" filter event. I discard the event, close up everything properly, and then shut down (if needed).