Control/indicator communication on Linux cRIOs seems buggy

[andre.buurman@carya]

Recently I came accross something I thought I needed to post in the forums, but haven't had the time to do until now.

On VxWorks based cRIOs I was used to using controls and indicators the transfer current value data back and forth between my RT and FPGA targets. It worked like expected in developement and run-time environment.

Now the newer Linux targets I used for 2 projects lately seem to display a different behavior in development mode vs. run-time mode when implementing controls/indicators as method of transferring current value data.

in development mode everything worked as expected (same behavior as VxWorks targets), but in run-time mode setting control values toward the FPGA didn't always stick (seemed random between controls). Ultimately I implemented a work-around by setting the critical values using User Define Variables using the scan engine interface.

I know it will be hard to demonstrate this behavior on my current projects as I went with a work-around, but the problem is there as I saw it in 2 different projects that don't show any code base. One project was done in LV2016 and one was done in LV2017.

Hope it helps to find a bug or other explanation for these observations.

[AJost]

Hi Andre,

I have personally never observed the behavior you describe and also seen no other reports so far.

So I would like to investigate a bit further and first reproduce it on my machine.

Currently I have to make a couple of assumptions which I would like to clarify before trying

1) cRIO in FPGA mode (no scan engine)

2) FPGA reference opened statically with an Open FPGA VI reference (i.e. not dynamically, no typecasting etc.)

3) Using the read/write control to write to a control/indicator on the FPGA FP

4) development environment = starting the RT VI from the LV project and using the interactive front panel

run-time environment = start-up executable (either headless or with HMI on screen/Host PC)

5) not sticking: if you change the value on your RT VI it doesn't translate to the FPGA

6) No other ingredients which could have an influence are present (no OOP, toolkits, PPL i.e. plain simple LV/RT functions

A minimal example would be ideal, but if I have a more detailed description I could also write some test code.

Andreas Jost

Applications Engineer

National Instruments

[andre.buurman@carya]

Hello Andreas,

To answer your questions:

1. cRIO in hybrid mode (some IO is done via scan engine) streaming is done via DMA FIFO and configuration and enable flags via controls

2. FPGA -bound to bitfile, checked run and checked bind ref. No dynamic mode.

3. Yes

4. Dev mode yes. Run-time yes with remote panel.

5. Yes, the value is programmatically set through FPGA property node in a certain state of a state-machine, but the value didn't stick, so the value seen via the remote panel was not as expected in that state. See foot note for extra expanation.

6.  LVOOP where FPGA ref is part of an FPGA Interface class' data and only accessed in that class' methods.

Foot note:

In the last project (LV 2017) the FPGA interface could be called from 2 reentrant running VIs. Although the 2 instances wouldn't be able to make a call to the same FPGA Interface method (by design).

In the project (LV 2016) before that, it had to with an indicator that didn't update from the FPGA to the RT host when it was in a 5kHz loop, but eventually this one was solved by placing it in a slower 1kHz by itself. This project didn't use the scan engine.

If you would like we could have a skype call so I could show you the code, it might help finding a suitable test case.

[AJost]

Hello Andre,

A skype call/screen demo would be awesome. I will get in contact with you via a different channel.

To summarize: most things are very basic except for OOP.

I can't quite see if there is any connection between the two applications, but that is something to investigate.

Andreas

[andre.buurman@carya]

Thanks for diving in.

Let's hope we at least find some reason why it might happen and maybe the reason.