10-18-2017 03:50 PM - edited 10-18-2017 03:52 PM
I'm still not clear on "run too fast" In what way might a stop watch be non-simulatable? Usually we can make fast things behave like slow things. For example, I can average 1000 samples/second and get out just 1 sample/second. Maybe this isn't an important discussion.
Here's a quick tutorial on what bundle does. http://www.ni.com/white-paper/7571/en/ It's taking the value that's on the shift register and grouping it together. I could have used separate indicators for the top and the bottom but by bundling them, when we read them, we can be sure that the two inputs to the cluster were taken at the same time. Compare that to individual indicators, you might read one and then by the time you read the other, it might have a newer value that doesn't correspond to what you read a millisecond ago.
You stop the loops by pulling the power cord. What's wrong with eternal running?
10-19-2017 09:09 AM
Ok, I've started implementing nanocyte's solution into my program. Well, the SCTL appears to be working correctly, but then I run into a problem in my RT vi. For some reason the unbundle by name function is not showing the Events and Stamps names. What is wrong here? It's like the function doesn't see the cluster from the FPGA.
Thanks for that information on the Bundle function. I thought those functions always required a cluster input on the top; that's why I didn't know what it was. I thought you had to have a cluster input so the function will know how to actually set the items you want into the actual cluster.
10-19-2017 12:32 PM
Check out the tutorial. You'll see that the unbundle by name gets its element names from the labels inside the cluster on the front panel
You need to give the elements names. Right click on the element on your fpga front panel and select visible items>Label. That will let you name the elements and then when you unbundle by name, the element names will be shown.
10-31-2017 09:52 AM
Thanks for that information, nanocyte. Bah, I should have known that, but drew a blank.
Ok, I used your exact code for my FPGA and RT vis, but the problem I see is that the Stamps element in the FPGA vi changes from positive to negative. It seems to run then reset, but it runs so fast I can really see how it is sequencing itself; I can tell that it does have negative numbers.
On the RT side, the indicator shows only 0 or -0.
10-31-2017 01:01 PM
There's a fairly significant difference between your code and my code. I've circled it here
10-31-2017 02:12 PM
Whoops! Yes, that sure is different. . .and what a difference it made! I'm getting values now in the Events per second indicator, but they are really erratic. I tried to attach a video, but it would not let me.
The events per second indicator jumps all over the place. Why would that happen? It goes between 9.9 and 20, jumping back and forth between different numbers.
10-31-2017 02:38 PM - edited 10-31-2017 02:50 PM
Think it through. You have a signal that's coming at ~15 events per second (~70 ms) and you're sampling it at a rate of once per 100ms. That means you're going to sometimes see one event (10 e/s) and sometimes see two events (20 e/s). You might want to sample over a longer period of time (~1 second) or implement logic to count. Example
I have an even better solution. Did you ever check out page 2 of the other counting thread? There's an example there involving streaming all the event timestamps to the RT side using a FIFO. Now, that solution is really cool because now you can graph the timestamps. You could poll the FIFO to wait for 10 timestamps to be available and then subtract the first timestamp from the last or you could do something even more clever like doing a linear fit.
11-01-2017 08:24 AM
Thank you again, nanocyte. I used that example you gave and got much better results. We will work with that to clean things up and finish out our program. Your method is more advanced than what we are used to (which is why I needed so much hand-holding to work through this), so this gives us lots of room to learn and improve our work. We appreciate the help that everyone gave.
We'll definitely keep the solutions on hand for future reference. The graphing of timestamps is something that will be useful to us in future projects.