10-03-2017 03:53 PM - edited 10-03-2017 03:54 PM
Hello all again. I figured out something that fixed the Analog indicator update problem, but I don't know why this worked. I put the Analog I/Os in a separate While Loop. Then when I ran the FPGA vi, everything updated like I desired. So, why would the Analog I/Os not update when they were in the same loop with the Digital I/O?
This is made even more strange to me because the Digital I/O was in its own While Loop inside the main While Loop. The Analog I/Os were just inside the main While Loop.
You found the correct solution, but you don't understand, why it works. Thats's sad. OK, here's the explanation, it's one of the basic principles of LabVIEW: All code inside a loop is executed once before it runs again. So you had the AI-reading and another loop in parallel within your main loop. Hence AI is executed once as is the inner while loop. As long as the inner while loop is running, the AI read is not executed again.
My next problem which is related to this is the "timer" part of my program. I had mentioned that the timer and the counter need to be together, as they are critically connected. Well, the FGPA can not work with my timer code as it is. I get an error stating that the "Wire type is not supported", and this error appears on the wire from the Get Date/Time In Seconds VI. So I have to make a timer that works for FPGA. I looked at nanocyte's solution, and the answer here appears to be a SCTL. I put this in the FPGA VI, but when I use the Tick Counter Express VI set for msec, I get 0. All I have in the SCTL is the Tick Counter and an indicator. I need to convert the msec value to regular seconds anyway, but why am I getting a 0 in the indicator?
I think the link that was provided earlier in this thread by nanocyte is a very good solution for your problem. It counts your encoder and gives you a timing information about when the counter increased. That should be all you need to go on.
10-18-2017 10:18 AM
Thanks for that information, jg69. Despite having worked with Labview for a while, I see there are still principles of it that I still don't get. I suppose that understanding will come with time and usage.
I'm working with nanocyte's solution. If I can get it to work, I'll check it as the solution to my problem. Otherwise I'll still leave this topic open in case someone else has any ideas.
Blazes, I used the SCTL that nanocyte suggested and got a counter that went negative AND positive, with a range from -30,000 to 40,000. How in the world does that happen when I only have an increment in that loop? I suppose this is yet another principle I don't get.
10-18-2017 10:48 AM
A SCTL usually runs at 40 MHz, so adding from 0 to 40.000 can happen within 25 µs. Did ypu really create an FPGA code as suggested? With the value-change detection?
Perhaps it would be a good idea to upload your actual code...
10-18-2017 12:51 PM
Ok, I attached the FPGA segment of the program. In the SCTL, please ignore the shift register, as that was an early attempt at timing that did not work. The Tick counter (set to msec) and 32 bits does give positive numbers, but that number is not in the form of a double, which I know the FPGA can not do. Well, I suppose I can do a Fixed Point conversion to double in the host vi to fix that. I'll see about it. Since this is a timer, we need the decimal portion of the value as well.
However, the biggest issue here is that apparently the tick counter runs even though it should not do so. When the Rate Reading Boolean is in the False state, the tick counter should not be running, yet when I click the Boolean to true, the counter starts off at 90,000+.
10-18-2017 01:28 PM
I don't get it? Why not use nanocyte's suggested solution:
No need to start or stop your reading of your flow meter, it runs continously inside the FPGA, and inside your RT code, you'll calculate the Pulse Rate.
Your FPGA vi makes not much sense. Why use a loop timer with waiting time = 0? It's also recommended to use the loop-timer express VI inside the first sequence of a flat sequence structure (read the help about why that's recommended).
And for your trial about using tick count inside a SCTL to measure the time: this VI will hand back the number of ticks/µs/ms since start of the FPGA, not since your first call. So in order to measure some time period with that VI you have to take the difference between two calls of that VI.
10-18-2017 02:46 PM
nanocyte. Thanks for the link. I see you use a SCTL, which looks a little like my Pulse Counter loop. I didn't know if a SCTL would run too fast. The counter needs to be in sync with the timer. I thought of using a SCTL for the timer and the counter, but I don't know if both of those can go in a SCTL, and since we can't have more than one SCTL, I am at a standstill on how to handle this.
What does "run too fast" mean?
Why wouldn't timer and counter be able to go in the same loop? That's what I have in my code. The top +1 is the counter the bottom +1 is the timer (notice how the RT code subtracts two subsequent "stamps" and multiplies by 25 ns to get an accurate measure of how long it's been since the last count sample.
Why can't you have more than one SCTL? Nope, that's not a rule.
10-18-2017 02:47 PM
Thanks for that, jg69. Let me provide some information and answers to some of your questions and responses here:
Why not use nanocyte's suggested solution:
-Looking at it, nanocyte's solution works for counting (e.g. counting digital edges). However, my issue is timing (like a stopwatch). The Pulse Counter loop I have does count the pulses properly, although based on your statement listed below, I may redo it.
No need to start or stop your reading of your flow meter, it runs continously inside the FPGA, and inside your RT code, you'll calculate the Pulse Rate
-Ok, my issue here was that I vaguely remember running into the issue of a continuously running program (due to the FPGA loop never stopping), or an FPGA loop which started counting pulses immediately when in fact nothing w