LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Trying to run scan mode and fpga interface mode simultaneously is causing errors

Solved!
Go to solution

I am trying to read from a 9236, 9237, and a 9215 with the scan engine and read from two 9211 modules with the fpga. This is because I need to acquire at 200 Hz with the 9236, 9237, and 9215 but the scan engine's maximum rate is limited by the slowest module in the system, which in this case is the 15 hz max of the 9211. 

 

So in order to use both interfaces (scan engine and fpga) I followed the instructions given in this article percisely.

 

1. Created the project and added the crio device using the scan engine interface.

2. Added the fpga target and drag and dropped the 9211 modules into it

3. Created the fpga file to interface with and compiled with no errors.

4. Interfaced with the fpga file almost precisely the way the "Getting Started with 9211" example project does while using the scan engine to interface with the other modules.

 5. After descovering errors i created a VI that would just test the 9211 portion of the code (called 'thermocouple FPGA Method Test.vi')

 

The data returned from the fpga interface was nothing but zeros on all channels, even though thermocouples were hooked up on some of them. (all zeros as inputs into the convert to temperature vi yields -410.616 degrees F, if you happen to have the hardware to try this.)

 

I am recieving the following error from the open fpga reference vi:

 

error code -61141
" Thermocouple FPGA Method Test.vi<append>
<b>FPGA activities:</b>

Reference open through FPGA interface.
Reserved outside LabVIEW FPGA: The RIO Scan Interface is running. You must set the chassis to FPGA Interface mode in order to unlock the FPGA."

 This is extremely frustrating because as I have described I have been very careful to not only follow the instructions for simultaneous fpga and scan but also to model my VI to the example VI, even if only for now, just to try to get things working.

 

Any help would be appreciated because I need to solve this problem to continue development and I am sort of in a time crunch. I have opened a support ticket (Reference#7256226) but the app engineer has not had time to respond.  

 

 

My system:

crio-9014 RT controller with crio-9104 backplane. 

Labview 2009

Latest drivers and software on both pc and rio device (RIO 3.2 scan engine support june2009)

 

 

Message Edited by rex1030 on 08-25-2009 12:31 PM
---------------------------------
[will work for kudos]
0 Kudos
Message 1 of 6
(4,977 Views)
Solution
Accepted by topic author rex1030

rex1030 wrote:

I am trying to read from a 9236, 9237, and a 9215 with the scan engine and read from two 9211 modules with the fpga. This is because I need to acquire at 200 Hz with the 9236, 9237, and 9215 but the scan engine's maximum rate is limited by the slowest module in the system, which in this case is the 15 hz max of the 9211. 

 

This should not be the case.  The 9211 data will not update every scan, but you should be able to run the scan faster than 15 Hz with no issue.  Did you have specific issues with this?

 

So in order to use both interfaces (scan engine and fpga) I followed the instructions given in this article percisely.

 

1. Created the project and added the crio device using the scan engine interface.

2. Added the fpga target and drag and dropped the 9211 modules into it

3. Created the fpga file to interface with and compiled with no errors.

4. Interfaced with the fpga file almost precisely the way the "Getting Started with 9211" example project does while using the scan engine to interface with the other modules.

 5. After descovering errors i created a VI that would just test the 9211 portion of the code (called 'thermocouple FPGA Method Test.vi')

 

Can you try making sure that the chassis is set to FPGA Interface mode and that the setting is deployed.  I noted that the article you referenced told you to select the deploy later option and doesn't explicitly mention deploying the chassis later.  Running a VI with an open FPGA reference vi will not automatically deploy chassis settings so you need to do it explicitly.  Try these steps.

 

1. Right click on the chassis item and select properties.  Make sure the FPGA Interface radio button is selected.\

2. Right click on the chassis item and select deploy.  

3. Try your VI again.

 

The data returned from the fpga interface was nothing but zeros on all channels, even though thermocouples were hooked up on some of them. (all zeros as inputs into the convert to temperature vi yields -410.616 degrees F, if you happen to have the hardware to try this.)

 

I am recieving the following error from the open fpga reference vi:

 

error code -61141
" Thermocouple FPGA Method Test.vi<append>
<b>FPGA activities:</b>

Reference open through FPGA interface.
Reserved outside LabVIEW FPGA: The RIO Scan Interface is running. You must set the chassis to FPGA Interface mode in order to unlock the FPGA."

 

The likely cause of this error is that the FPGA Interface setting on the chassis has not been deployed.  If the chassis is still in Scan Mode the fixed personality bitfile will be loaded at boot and the FPGA will be locked.

 

This is extremely frustrating because as I have described I have been very careful to not only follow the instructions for simultaneous fpga and scan but also to model my VI to the example VI, even if only for now, just to try to get things working.

 

I'm sorry you have had difficulty.  Assuming I'm correct about the source of your issue, it looks like we need to at the very least update that KB to include the deploy step.

 

Any help would be appreciated because I need to solve this problem to continue development and I am sort of in a time crunch. I have opened a support ticket (Reference#7256226) but the app engineer has not had time to respond.  

 

 

My system:

crio-9014 RT controller with crio-9104 backplane. 

Labview 2009

Latest drivers and software on both pc and rio device (RIO 3.2 scan engine support june2009)

 

 

Message Edited by rex1030 on 08-25-2009 12:31 PM

 

Please let me know how these suggestions work out.  Hopefully this resolves your issue but if not I'm happy to continue to help.  Once you are out of your time crunch any suggestions you have on how to make this process easier would also be appreciated.

 

Thanks,

 

Sebastian

Message 2 of 6
(4,972 Views)

 All I had to do was right mouse click on the chassis in the project and click deploy!

 

You are the man. Wish I could do more than just say thanks mate.  That totally needs to be added to the knowledgebase article and I am gonna get on that right now. What a stupid freaking problem to have but man am I happy you were able to help.

 

This crio stuff can be so hardware specific it is nearly impossible to find someone that can actually run your project on the same hardware I have, so I can't thank you enough for the solution. Who would have thought that you can change chassis settings in the project and run a VI, deploying the compiled fpga file, and it wouldn't deploy the chassis settings changes? Doesn't this count as a bug?

 

I mean, the whole reason this error is so cryptic is because I was able to right mouse click on the crio device and the "FPGA Interface" bubble was checked. Yet I was getting an error saying it wasn't.

Message Edited by rex1030 on 08-25-2009 01:29 PM
---------------------------------
[will work for kudos]
0 Kudos
Message 3 of 6
(4,953 Views)
I've modified the document accordingly. It will hopefully be live tonight.
Jeff | LabVIEW Software Engineer
Message 4 of 6
(4,930 Views)
Look at that! Top notch. Someone deserves a raise 🙂
---------------------------------
[will work for kudos]
0 Kudos
Message 5 of 6
(4,927 Views)

Glad to hear that was the answer.

 

It looks like Jeff's edit is now live, so hopefully that will help for the future.

 

I do agree that the behavior of the chassis settings is confusing (and you aren't the first person to have a similar problem).  I will raise this as an issue, and hopefully we can do something to improve the behavior in a future release.  It sounds like even something as simple as more detail in the error message would help a lot.

 

Sebastian

0 Kudos
Message 6 of 6
(4,893 Views)