polymorphic VI on FPGA

[mkais]

Hi Intaris,

the last Post was my Demo Project.

In your first Post you wrote: When I replaced the individual VIs with my new shiny Polymorphic VI I got errors on the FPGA. 

So where is this VI and Project? Can you send us the error_Screenshot?

What happen if you make a copy of your Project and remove unused polymorphic instances?

Thanks

[Intaris]

If you open the zip file in my previous post you will see that I have modified your project to

1) fix your mistakes (DBL are not supported on FPGA)

2) introduce an FPGA target for testing

3) modify the VIs so that the issue should become apparent

If I remove the polymorphic VIs the problem goes away because the problem IS the polymorphic VIs.

Please download, open and look at the project I have included in my previous post.

[Intaris]

So just for clarity  I will outline my problem again.

I have a polymorphic VI.

SOME of the polymorphic instances are FPGA compatible, others are not.  This I know and it is intended.

If I place the polymorphic VI on a FPGA BD, it declares the FPGA VI broken even if the actual INSTANCE of the polymorphic VI selected is FPGA compatible.

If I split up the Polymorphic VI into two polymorphic VIs, one FPGA compatible and the other not, things work fine.  I originally wanted BOTH sets of functionality in one because (to Paraphrase the Dude) it really tied the code together.

So my question is whether the breaking of a FPGA VI due to UNUSED instances of a polymorphic is intended or not.  I personally feel that it should NOT lead to breaking the VI since it's clear which instance is being used and it is actually compatible.

Shane.

[mkais]

look for the project on the Attachment. I wrote that you should initialize the Array. It works all fine. and the Polymorph VIs are supported on FPGA.

See Please my working Final Project, The FPGA VI and the Screenshots.

Best Regards

[Intaris]

Kais,

ich will nicht unhöflich sein, aber trotz mehrere Versuche, es scheint als ob Sie nicht in der Lage sind mein Problem zu verstehen.

Können Sie deshalb meine Frage an jemand anderes weiterleiten?

Ich meine nichts ungutes aber ich habe nicht so viel Zeit, dass ich in unnötige und nicht hilfreiche Diskussionen verwickelt werden will.

Gruss

Shane O'Neill

Spoiler

Die Arrays sind IHRE Arbeit.  Ich habe nichts mit Arrays zu tun und falls Sie mein Code (die ich vorher schon angehängt habe) anschauen, werden Sie es vielleicht auch merken.  Falls nicht versuchen sie eines.  Machen Sie ein Polymorph VI wo ein Mitglied FPGA Kompatibel ist und der andere nicht.  Jetzt platiziere der PolyVI auf ein FPGA BD und wähle die kompatible Version aus.  VI bleibt trotzdem nicht lauffähig.

[Vsh]

Kais,

I would like to highlight a point here, when a person titled with "Trusted Enthusiast" posts a question, definitely, he would have done his homework like NOT using dbls and settting the array size on FPGA target. Moreover, that is not the concern OP raised!

Intaris, I believe when you place a Polymorphic vi on the block diagram, entire poly instances are loaded to the memory. This you can observe in VI hierarchy of the FPGA vi. which might causing you the broken arrow.

[Intaris]

Vsh,

I can appreciate that they are loaded into memory but I question as to why the compiler tells me that VIs which are NOT being called lead to uncompileable code.  I see a difference between loaded VIs and USED VIs, even if perhaps the LabVIEW IDE does not.

If this is the only way the IDE can work then it's something I just have to take into consideration in future.  I really think it shouldn't behave in this way though.  In a perfect world.....

Shane.

[Vsh]

Shane,

Polymorphic VI is like a VI which has a case structure and you place different subVIs (instances) matching your datatype inside individual cases. If any of the subVIs inside case structure is broken or the target does not support functions used in that sub VI, you would still be noted as uncompileable. (Eventhough the sub VI is never called and you have connected a constant value to case selector. which is the scenario with Polymorphic instance that is been called)

Only advantage of Poymorphism is that it can adapt to different datatypes. but all other instances are also loaded into memory as part of the Polymorphic VI. Since the VI is calling a subVI which is not compatible with the target, broken arrow is quite normal.

---

  I really think it shouldn't behave in this way though.  In a perfect world.....

---

Well, sometimes you have to accept, thats how LabVIEW works 

[dan_u]

---

@Vsh wrote:

Shane,

Polymorphic VI is like a VI which has a case structure and you place different subVIs (instances) matching your datatype inside individual cases. If any of the subVIs inside case structure is broken or the target does not support functions used in that sub VI, you would still be noted as uncompileable. (Eventhough the sub VI is never called and you have connected a constant value to case selector. which is the scenario with Polymorphic instance that is been called)

---

Are you sure about that? I would hope a polymorphic VI would work more like a conditional disable structure. It loads all instances into memory when opening the VI, but for the compilation only the active code (the instance used) must be compileable.

In a perfect world...

[Nick-C]

Shane,

Nick here from LabVIEW R&D, I'm one of the Product Support Engineers for LV FPGA. Just came across this forum, sorry I hadn't seen it sooner and had a chance to respond. 

I haven't looked directly at your code just yet, but I will be doing so this afternoon to confirm what I suspect. As VSH mentioned, non FPGA supported functions inside other instances are likely the culprit. I suspect you have them inside conditional diagram disable structures, by target type. As you can see from these release notes, in LV FPGA 2012 SP1 we worked on some known issues with diagram disable structures inside polymorphic VIs. Didn't happen to see it in any of your previous posts, but have you upgraded to SP1 yet?

This afternoon I'm going to open up your project / setup a test of my own. I've got it from here and if indeed there is a bug (which there might be) it'll be more straightforward for me to file a corrective action request on it anyways. Hang tight, I'll have some more info for you soon.