fpga code generation error after updating from 8.5.0 to 8.5.1

[UliB]

Hi All,

I have a FPGA-VI which was compiled in LV 8.5.0 without errors. After I updated to 8.5.1 the Code Generation stops, telling me the clock domain is not supported for write FPGA I/O node (see attachment).  Also I attached a picture of a simplified FPGA-VI which brings up the same error.

I use a PXI-7833R connected to a cRIO-9151 R Series Expansion Chassis with a NI-9421 modul (8-ch DI, 24V) installed in it.

My original FPGA-Code has a theoretical maximum of 22MHz, so I can't change the clock domain to 40MHz.

Do you have any suggestion how to get the VI compiled?

Uli

[UliB]

Hello,

I talked the problem over with NI.

They said "In LabVIEW FPGA 8.5.1 and NI RIO 2.4 the timing constraints [...] has been tightened [...]. To workaround this issue, a user can [...] or down grade to NI-RIO 2.3.1."

So I deinstalled NI-RIO 2.4 and all of its components and installed NI-RIO 2.3.1 again. Now the FPGA-VI can be compiled without errors.

Problem solved. 

Uli

[Ruhmann · Accepted solution]

I'm shocked that you don't get that error in previous versions.  You should not be able to use CompactRIO I/O in clock domains that are not a multiple of 40 MHz.  Here, you are using cRIO I/O in a 20 MHz clock domain.  If you changed the clock to 40, it should be fine.  (You can use a case structure to only sample your I/O when the index is even, thus sampling at 20 MHz.)  Also, all cRIO I/O inside the VI needs to be used in the same clock domain.  So, while you can use single cycle timed loops with your I/O, you should use the top level clock for these loops. 

Whoever you talked to at NI was incorrect when they mentioned the timing constraints.  We did tighten timing constraints to better guarantee safe execution, but that has nothing to do with this error.  I encourage you to use the latest software and not downgrade.

[Bassett_Hound]

Uli,

Any chance you can provide code that reproduces the issue?  Also, can you provide the Service Request number so I can follow up with the Application Engineer who helped out?

Thanks,

Basset Hound

[UliB]

Hi Ruhmann, hi Basset Hound,

thank you for your reply and giving me a better insight in things.

I started my VI with 40MHz clock domain. The Vi got bigger, some more logic here and some more code there. Finaly the compiler couldn't satisfy the timing any more. Instead of optimising the code, I reduced the clock domain.
Until your post I didn't realise I use CompactRIO I/O. Is There a difference to (let me call it) "direct R-Series I/O"?
I need the Expansion Chassis (Connector 1), the 9421 (8-ch DI) and 94?? (8-ch DO) to connect 24V logic to the FPGA. Additionally I have two SCB-68 (Connector 2+3) for 5V logic (DI, DO, A/B linear position measurement, pulse generation) and some analog input. All code in 1 VI, but distributed in 3 loops.

To change the clock domain back to 40MHz, I have to optimise my code . Well, the code is sloppy , so optimising is OK .

To tell the hole story:
After updating to 8.5.1, my first contact to NI was by phone. The engineer asked for the Code, the project and the hardware.
It took a while for me to put the information in an email. Meanwhile engineer the found a paper with the solution I
mentioned in my second post and send it to me, before looking at my code. The paper said someting about "tightend timing constraints",
"safe communication" and "multiple DMA target to host transfer". Not exactly what I was doing, but I reinstalled
 RIO 2.3.1 and ... compile successful.

@ Basset:
The simple VI (picture) in my first post reproducese the issue exactly.
I'm not at work any more, so I can't provide the full code or the SRQ# until tuesday (holiday on monday ).
FYI I'm located in Germany, so I called the german NI support.

Uli

[UliB]

Hi,

meanwhile I improved my code and the compiler meets the 40MHz timing again . So I will upgrade to NI-RIO 2.4 soon.

Some more questions:

I use another SCTL with a 10 MHz clock domain. Inside the loop I read four digital lines from an encoder (A/B/Z/error). The signals come from a SCB-68 directly to the 7833R-Device, so no cRIO I/O. Is there a limit for the clock domain in this application?

Where is the diffrence between cRIO I/O and signals connected directly to a R-Series device?

Uli

[Ruhmann]

When I said "cRIO I/O" I was actually referring to I/O from a C Series module, which are the modules you plug into an expansion chassis.  The normal R Series I/O, which you are using through the SCB-68, can be used in multiple clock domains and in odd frequency domains that aren't divisible by 40 MHz.  So, you should be fine using a 10 MHz clock with that I/O.