LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

FPGA or Host Controller for timing?

Solved!
Go to solution

@Dhouston wrote:

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.

 


@Dhouston wrote:

 

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.

 

Regards, Jens

Kudos are welcome...
0 Kudos
Message 11 of 28
(1,458 Views)

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.

 

Trudging onward.

0 Kudos
Message 12 of 28
(1,442 Views)

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...

 

Regards, Jens

Kudos are welcome...
0 Kudos
Message 13 of 28
(1,438 Views)

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+.

0 Kudos
Message 14 of 28
(1,430 Views)

I don't get it? Why not use nanocyte's suggested solution:

grafik.png

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.

 

Regards, Jens

Kudos are welcome...
0 Kudos
Message 15 of 28
(1,426 Views)

@Dhouston wrote:

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.

 

 

0 Kudos
Message 16 of 28
(1,416 Views)

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 was operating.

 

 

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).

-The loop timer with waiting time of 0 is to synchronize the loops as I found out the hard way that using this loop timer with different wait values causes problems. 

 

Whoops, did nanocyte just post something while I was typing this?

0 Kudos
Message 17 of 28
(1,414 Views)

@Dhouston wrote:

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 was operating.

 

 

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).

-The loop timer with waiting time of 0 is to synchronize the loops as I found out the hard way that using this loop timer with different wait values causes problems. 

 

Whoops, did nanocyte just post something while I was typing this?


Running continuously is not a problem because of the subtraction. Lets say it's been running and the count is a 1000 and then 100ms later it's 1100 that implies you have a rate of about 1 pulse per millisecond.

 

There are much much better ways to synchronize your loops. For example you could subsample the pulse count at the rate of the analog inputs by using a local:

subsample local.PNG

You could also use a handshake to sync data

0 Kudos
Message 18 of 28
(1,409 Views)

Hello nanocyte.  I'm glad you popped in since your solution seems to be the anchor point here.

 

In answer to your questions:

 

What does "run too fast" mean?

-I wondered if a SCTL would actually time faster than an actual stopwatch would since that is the type of timing mechanism I want to replicate.

 

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.

- Ugh!  I think you are using some things I don't know about, nanocyte.  In your SCTL, is that a bundle function you are using to bundle the shift registers into the count?  Just what is that thing that is labeled "count"  in your SCTL?  It looks like a time stamp constant or something. Then comes my big question:  How are you able to stop these loops?  There is no control or anything wired to your loop stops.  When I do this, I get the eternally running program.

 

Why can't you have more than one SCTL? Nope, that's not a rule.

-What?  Really?  I thought I heard this very thing in the online FPGA course. Maybe I got that mixed up with all the things you can't have inside an SCTL.

0 Kudos
Message 19 of 28
(1,406 Views)

Hello Dhouston

 

What does "run too fast" mean?

-I wondered if a SCTL would actually time faster than an actual stopwatch would since that is the type of timing mechanism I want to replicate.

A SingleCyleTimedLoop will execute on every cylcle of the FPGA clock that you assign that SCTL to. The typical base clock rate for many NI FPGA products is 40 MHz, so all code that you put inside a SCTL will execute at a rate of 40 MHz (exeption: if the code takes to longer to execute as 25 ns, than you'll get an compile error and then you know, you have to change something in your FPGA code).

 

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.

- Ugh!  I think you are using some things I don't know about, nanocyte.  In your SCTL, is that a bundle function you are using to bundle the shift registers into the count?  Just what is that thing that is labeled "count"  in your SCTL?  It looks like a time stamp constant or something. 

The number of executions of the SCTL is counted. As this takes 25ns, it is kind of a timer.

 

Then comes my big question:  How are you able to stop these loops?  There is no control or anything wired to your loop stops.  When I do this, I get the eternally running program.

This programm is designed to run as long on the FPGA till you reset your FPGA resource or power down your cRIO. That's something typical for FPGA code. You want to run that indepently of your RT-code.

 

Why can't you have more than one SCTL? Nope, that's not a rule.

-What?  Really?  I thought I heard this very thing in the online FPGA course. Maybe I got that mixed up with all the things you can't have inside an SCTL.

There are some limitations when using more than one SCTL, like sharing resources. But yes, you can have as many SCTL-loops in an FPGA code as you like - as long as the code compiles...

 

Regards, Jens

Kudos are welcome...
0 Kudos
Message 20 of 28
(1,396 Views)