bullet proof way to compile FPGA, run on startup for Hybrid mode and find resource names

[Steffen01]

I got a cRIO 9074, profibus module and NI 9871, 9870.

it seems FPGA bitfile has to run first so then in Scan mode the other modules are found, resource names assigned and so on.

This sounds like chicken and egg. Don't I have to compile FPGA first, but to compile, it needs to know about the other modules and how its connected to it?

The profibus module will most likely never change, so once the FPGA is compiled, would it be best just to reference to the bitfile in the startup vi? I just want to make sure, the FPGA starts on cRIO startup. Because at present it does not seem to start and I never find the NI modules and their resource names. Then of course nothing works in scan mode either.

[Steffen01]

Open FPGA Reference node in bitfile mode

https://forums.ni.com/t5/LabVIEW/error-61017-in-the-RT-VI/td-p/635236

"Run the FPGA VI interactively by clicking the Run Button in the main FPGA VI. After this, you should be able to see the new COM Ports provided by the NI-987x Modules listed in NI MAX and also be able to open a Visa connection from a Real-Time VI.The connection to the serial ports should still be possible even if the FPGA VI has been already stopped. After rebooting the target, you will need to run the FPGA VI again to re-enable the ports. Resetting the FPGA from Real-Time with the corresponding method will also cause the ports to be disabled."

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000PAk5SAG

When you compile the VI, the LabVIEW FPGA Compile Server adds to the FPGA VI all the logic necessary to communicate with modules you are using in Scan Interface mode. When you run the host VI, the Open FPGA VI Reference and the Start Read/Write control wired to the Timed Loop ensure that the FPGA VI is running before the I/O variables in the Timed Loop start returning data.

http://home.hit.no/~hansha/documents/lab/Lab%20Equipment/cRIO/resources/Getting%20Started%20with%20C...

forgot to mention: at present FPGA does not start. All I did is moving the project to a new laptop

[MichaelBalzer]

Not sure if you've seen this article on setting up hybrid mode. Basically your LabVIEW project knows about the hardware, so when you compile the FPGA, it knows what resources to include in the bitfile to enable scan mode for the 987x modules. You then run the FPGA bitfile when your RT application first starts (this part is key, scan engine won't run otherwise). Once the bitfile has been loaded and is running, you can access the serial resources from the 987x modules. One issue I've seen in the past when doing this is if the serial resources weren't cleanly closed on the last RT run, they may not load properly the next time you go to use them. The workaround here is to close any serial resources in the RT code before opening them.

Just a note with the profibus module - my past experience was that it required two bitfiles to run. The first bitfile initialises the profibus settings (slave address, slave mode), while the second bitfile runs the actual profibus network comms. Both bitfiles were compiled with scan engine capabilities (for reading six other modules). The setting bitfile was then run from the RT, and after a short pause, the FPGA reference closed and then the second bitfile was started. I don't know if the API for that module has since changed, but it required extra work to use compared to NI's first party offerings.

I wish you luck - based on my past experience with these modules, there can be lots of gotchas. Make sure you trap any and all errors to help with debugging!

[Steffen01]

Hi Michael,

thanks. I compiled the bitfile and loaded it onto the cRIO Flash and set it to autoload on device bootup.Now FPGA LED is blinking and I manage to see my resources. Either when I run the FPGA vi or the RT Main vi. So thats a win. But I the Profibus Module does not run even though its called up in the RT main vi. I has error 61003 coming in and the sub vis have error 65536 out. Seems there are not slave and master addreses communicated into the profibus vi so it just reads zeros.

The thing is, everything used to work, I just put the whole project onto a new PC and the cRIO got a new IP address. But this should not affect it, the IP address comes in at the FPGA reference. At present its just one bitfile for the Profibus module. I am not sure, how the data is pulled out. Seems there is an array. The PB module is configured via Kunbus / ex Comsoft software and then just spits out 20 bytes worth of data. Its a pain, apparently we could not get Modbus. Even though we just read 2 flows and 2 pressures per second.

there is something on error 65536

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000PAjWSAW

and this sounds worth trying

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P9tQSAS

[Brian.D]

Where does error 61003 occur specifically? It seems you already have found some documentation on 65536, but the first error/warning may be causing that issue.

[Steffen01]

there is something on put a new Real time vi on the target. Copy paste existing one. Make new Open FPGA reference and delete old one. This is working when deployed. Will reboot cRIO, see if its still working. Then try to compile. The errors may be related to that. I make a screenshot later

[Steffen01]

this is what I meant

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P9tQSAS

then disconnect all typedefs and some global variable was playing up. Now it seems to work. I will post a screenshot later

[SMARDT_CHILLER]

ok, here the screenshots

haha, my alter ego, different computer