LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Programmatically calling an FPGA vi to view over the FP vi

Solved!
Go to solution

Good morning. I have become stumped on this question for a bit so I thought I would post the question here.

 

Q: what is the best way to programmatically call a VI running on the FPGA to the FP main VI running on a touchscreen computer, where when the FPGA VI is called it goes to the top level of the screen without interrupting the VI output of the main VI?

 

I have researched using a queued message handler but couldn't get it to function properly. I have also researched dynamically calling a VI and asynchronously calling a VI but am unsure how to implement the correct one for what I are trying to accomplish.

 

What I am trying to overcome here has to a lot with tab control on the front panel VI as I have discovered that apparently while a tab is open to the top of the FP the other tabs do not I/O any values to the cRIO. This is good and bad for our application. The good part is that it allows a 'locking out' of other processes while the visible tab is on top. But the bad part is that if I open another tab then what I have running on the previous tab stops. I need to be able to incorporate both of these aspects in our program.

 

This example shows how I am using tabs in our program. (ATTACHMENT 1)

 

 

So in the example above, when page 5 is opened the graph indicator starts which is what I need, and when it closes it stops which is correct to.

 

But the issue is that when page 5 is open it also stops what’s happening on the other four tabs in the same tab pane which is NOT what I need to happen.

 

What I have done so far to correct this is - removing the page I need to open on top and made it into its own VI.

 

What this separate VI does is accept input from the FPGA resources including J1939 engine information through an NI9862 card and voltage / analog signals from sensors via an NI9207 card and reads the information on virtual indicators and gauges as seen here. So it makes sense to me to put the VI on the FPGA. (JPEG)

 

 

The information on this VI only needs to be seen periodically via the FP by the operator as it is called via a Boolean control (button) on the FP, but it still needs to run on the FPGA when not seen in order to pass information to the RT control for alarm processing. So in that, in the case of an alarm it causes something else to happen to the unit being controlled (ie. Execute an engine shutdown over the J1939 bus)

 

What this VI cannot do is interrupt the operations that are being executed by the main VI on the FP if called (to do a parameter check) but put the main VI into a ‘locked out’ mode if there is an alarm.

 

So then the question becomes how to call this VI from the Front Panel VI?

 

Well, I have tried to make a Queued Message Handler work which it did partially (I was able to open the VI and run it but I couldn’t work out how to close it) and unfortunately I have sub-sequentially erased that bit of programming code. Though I don’t think it would have worked anyway as I was trying to call it as a sub-vi in the main VI that was located on the computer and not on the FPGA target.

 

Then I tried dynamically calling the VI and found it did the same thing as if the VI were still connected to the tab control by stopping the I/O of the main VI while it was called to the front. I erased that bit of code work too.

 

So then I started looking at asynchronously calling the VI as I saw that it would allow both VI’s to run at the same time. Here I seem to have found the right answer to my own question, though, I believe that the example program I am looking at has a memory leak or is not closing out the called VI properly because within a few minutes runtime both VI’s slow to a stop. This is not good. I understand what the example code is trying to show but I don’t think it is programmatically correct and I have not been able to fix it. Here is the example code I was looking at. (ZIP FILE)

 

So while I believe I am on the right path I am not sure how to impliment it with the FPGA.

 

Download All
0 Kudos
Message 1 of 12
(3,177 Views)

I apologize that I don't currently have access to LabVIEW 2013 to look at your code, so the comments below may be way off...


Gearmiester wrote:

What I am trying to overcome here has to a lot with tab control on the front panel VI as I have discovered that apparently while a tab is open to the top of the FP the other tabs do not I/O any values to the cRIO. This is good and bad for our application. The good part is that it allows a 'locking out' of other processes while the visible tab is on top. But the bad part is that if I open another tab then what I have running on the previous tab stops. I need to be able to incorporate both of these aspects in our program.

...

But the issue is that when page 5 is open it also stops what’s happening on the other four tabs in the same tab pane which is NOT what I need to happen.


This isn't true. There's some misunderstanding here, that I can't see because I can't see the code. A tab control is simply a container - it's basically decorative. The controls inside it continue to act the same way regardless of which tab is active. Do you have the tab control wired to a case structure, and the control terminals inside of the cases? That would explain what you describe, and if so there's an easy fix - take the control terminals out of the case structure.

0 Kudos
Message 2 of 12
(3,161 Views)

nathand - what version LabVIEW?

 

Functionally the code is specifically designed to not allow tabs that are not on top to not function so as to establish different modes of operation for the same machine. So the short answer is yes, the controls are set inside a Case Structure.

 

LV12 AND LV11

Download All
0 Kudos
Message 3 of 12
(3,158 Views)

LV12

Download All
0 Kudos
Message 4 of 12
(3,151 Views)

I have LabVIEW 2012 available right now. If you can save for that version, I'll take a look.

 

Am I correctly understanding that you have deliberately designed your code such that it doesn't interact with the FPGA when the appropriate tab isn't visible, because the FPGA interactions are inside a case structure tied to the tab control, and now you're trying to work around that? Can't you move the parts that need to run constantly outside the case structure?

0 Kudos
Message 5 of 12
(3,147 Views)

You are correct, that is how the program is built. Each page of the tab has it's own set parameters to interact with the FPGA differently. (ie electromechanical controlling a hydraulic pump so each page has a distinct set of limitations on what the pump control does) this effectively creates a set of 'modes' for different parameter pump control to the same individual pump.

 

Here is a screen of the main program. The buttons at the bottom determine which mode the pump is in (effectively changes the tab control to a different tab)

 

So yes, the engine page has been removed from the tab control and made into it's own vi that I want to put on the FPGA target (as its only input and no interaction) but I want to be able to call the engine vi from the main program and not interrupt the main program if I am controlling the pump but just want to see what the engine and pressures are doing.

 

I added a screen of some of the code tied to the picture above.

Download All
0 Kudos
Message 6 of 12
(3,139 Views)

I'm sorry, but I can't match the two VIs you posted with your description of what's going on, especially since they don't show any use of the FPGA.

0 Kudos
Message 7 of 12
(3,129 Views)

Sorry for the confusion. These are examples only to show the tab control theory that is in place in my program (I made this example)

 

the other two vi's I didn't make and they are only an example to show how to asynchronously call a vi to run in parallel to another vi. But in that example there is an issue because the vi slows down to a stop after a few minutes of running. I think because there is a memory leak or it's not completely closing the secondary vi out.

 

I believe that this functionality would work for what I am trying to do, but I am trying to understand why it's not doing what it should correctly.

 

I have not written any code for the FPGA in my application yet as I am trying to find the best way to answer the question in the OP.

0 Kudos
Message 8 of 12
(3,119 Views)

Have you previously worked with LabVIEW FPGA but haven't started writing code for this project, or you've never used it at all? If you haven't used it, then that would explain some of my confusion, because the way you describe your yet-to-be-built architecture doesn't match the way LabVIEW FPGA works. You wrote "What I am trying to overcome here has to a lot with tab control on the front panel VI as I have discovered that apparently while a tab is open to the top of the FP the other tabs do not I/O any values to the cRIO." Have you actually discovered this, and if so can you post the code that demonstrates it?

0 Kudos
Message 9 of 12
(3,102 Views)

So, no I have not written any code for the FPGA before and as most of my programming training and experience in LabVIEW has been to develop the FP design and learning how to program using LabVIEW achetecture is why I had the original question here.

 

_______

Q: what is the best way to programmatically call a VI running on the FPGA to the FP main VI running on a touchscreen computer, where when the FPGA VI is called it goes to the top level of the screen without interrupting the VI output of the main VI?

_________

 

I assumed that if I were to call an FPGA vi to the front of my main panel it would follow the same program logic demonstrated in the way I am using the tab control. If it doesn't then all the more better. But since I was trying to call the vi when it was located in the main vi as a sub-vi I couldn't get it to work for me. So I though why not put it on the FPGA as all that vi is is a dumb indicator page, and call it from the main program.

 

So the nuts of it is simply trying to find the best program practice to do this. As of yet I have not figured that out.

 

Sorry for the forest instead of the tree.

0 Kudos
Message 10 of 12
(3,097 Views)