Scan Engine & EtherCAT Custom Device Feedback

[HansDas]

Thanks. Answer 2 was the solution with the Auto Detect Problem.

Actually I think it doesn't matter which bitfile I use. You can try this one.

[StephenB]

Glad that fixed the auto detect!

I can reproduce the error on my machine with your bitfile. Inspecting the bitfile, it appears it was created without the scan engine inside it, but rather uses the NI VeriStand FPGA IO Template.

If you want to use the scan engine add-on for NI VeriStand with a custom bitfile... that custom bitfile must have the scan engine compiled into it.

What are your trying to accomplish? Perhaps I can give you some advise on how you should proceed.

Do you just want to read and write all of your IO values or do you need custom FPGA code as well?

[HansDas]

I want to read a PWM signal with a NI9401 combined with the FPGA, calculate the high and low-ticks with the FPGA, convert these ticks in frequency and duty cycle in the realtime part of the cRIO and import these values into a Mathlab Model of an Engine. The engine model gives back pulses per revolution as a value which uses nearly the same way backwards. All together a closed control loop.

Is reading PWM signals a part of "custom FPGA code"? Then I guess I need it.

So how can i compile the scan engine within some simple FPGA-code in a LabVIEW project?

Thanks a lot Stephen

[StephenB]

If that is the only code you need to do, then I would use the scan engine because it will read all the rest of your basic IO without you having to write any code for that basic IO. The scan engine can also read PWMs on your 9401 using specialty digital' without using any FPGA code... but it unfortunately can only read duty cycle. So you will need to use the 9401 in 'fpga mode' and the rest of your modules in 'scan mode'.

Attached is a project that does everything you need. Note it has 9201 modules under the chassis because simply having a module in that slot in the project 'enables' that slot for scan mode so any basic IO module will work in that slot when you load this bitfile into NI VeriStand.

To convert the high time and low time to duty cycle and frequency... I would just do that in your model. A single tic in a 'single cycle timed loop' going at the default clock rate of 40 MHz is 25ns. So 1 tic = 25ns. Use that for your math.

One extra thought:

You have a 9853 module. This module is very advanced and difficult to use. You will not be able to use it with NI VeriStand without a huge investment in FPGA programming and custom device development. I highly suggest using a 9862 module instead because it will work with NIVS built in XNET support. See the section "Using the Scan Engine and EtherCAT custom device with NI 986x XNET modules" inside the scan engine download page.

One other extra thought:

Have you seen our engine simulation FPGA tools? This might be useful to you. Also, I'm rewriting those tools and should have a new version available in a month or so that will be a lot easier to use and have a lot more features. https://decibel.ni.com/content/docs/DOC-19122

[daufdi13]

StephenB

Is it possible to get one of the VIs in the Scan Engine Custom Device.lvlib unlocked?

'Get FPGA Info.vi' has a conflict with the System Definition API code.

Thanks,

Dan

StephenB wrote:

Here is what I have. good luck

[StephenB]

Unfortunately that code is internal and cannot be shared

[daufdi13]

In the library, the developer included a sub-vi that is already part of "Labview\vi.lib\Utility\error.llb".  So I have a conflict that I can't resolve. I created a service request 7407769 to try to resolve the conflict another way, but they couldn't get it to resolve.  The VI is "Error Cluster From Error Code.vi".  Can you please give me a copy of that VI that uses the "Labview\vi.lib\Utility\error.llb\Error Cluster From Error Code.vi"?

Thanks,

Dan

[StephenB]

What library includes that? I'm confused here

[daufdi13]

Scan Engine - Configuration.llb contains "Error Cluster From Error Code.vi"

A similar VI with the same name is in "Labview\vi.lib\Utility\error.llb"

[StephenB]

ah yes. OK so you should never link to the LLBs. They are loaded by NI VeriStand in the labview run time engine, so they include everything from vi.lib (since vi.lib is not present in the run time engine, and a NIVS customer might not even have labview installed). Consider those LLBs as compiled code blobs never intended to be used from the LabVIEW development environment.

Instead, you should lik the system definition API to the source of the custom device