LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Problem using FEEDBACK NODE in RT programs

LV2013, LVRT2013

 

There's something fishy about this code:

Chunks.PNG

 

 

The purpose is simple: because of other limitations, to send a large file (string) over a TCP connection, I have to "chunk" it up and send it in pieces.

 

Each block has a FIRST and a LAST flag, and a chunk of string.

 

The point of this code is to assemble those chunks back into a single string on the receiving end.

 

I use the same VI both in the HOST (windows PC) and on an RT target (PharLap)

 

The code works fine.

 

But there's an oddity.

 

1... I SAVE ALL on the project (which contains both the HOST side and the RT side)

 

2... I RUN the RT program.  LV might or might not save that the ASSEMBLE CHUNKS vi needs saving.  I can save it and run the RT part fine.

 

3... I RUN the host program.  It runs fine.

 

4... If I CLOSE the project, LV will warn me that ASSEMBLE CHUNKS needs saving.  Why?  "The VI was recompiled".

 

5... If I SAVE it on the host side, and then RUN the RT side again, it again needs saving, for this one VI.

 

Why is that ?  it is as if there is something different about the VI when compiled for Host, or when compiled for RT.

 

By itself, that is nothing more than a nuisance.

 

BUT

 

Now I have compiled it into a PPL (*.lvlibp).  I compiled it on the RT side, but when I use it on the Host side, it complains that the VI is broken, because it's "missing a connection to an external routine".

 

It's not smart enough to tell me WHAT it's missing, but that's the message.

 

If I open the PPL solo (without a project), that VI is just fine.  But when it's used on the host side, it's broken.

 

That reinforces the idea that something about the VI is particular.

 

I have lots of other VIs that are shared (host & RT) without this problem.

 

This is the only one with a FEEDBACK NODE.

 

If I rework the VI to use a WHILE LOOP and a shift register, then the problem goes away.

 

What is it about FEEDBACK NODEs that is so squirrelly ?

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 1 of 8
(2,942 Views)

Two wild guesses...

 

1) Make sure you have shut off "Automatic Error Handling" to rule out the VI needing recompiled because of error handling checks.

 

2) Experiment with including the Re-entrant VI in the OTHER branch of the project (move from Windows so RT or vise versa) or removing it from teh project completely and let it just show up in Dependancies.

 

Like I said, wild guesses.

 

If you learn anything, please feel free to school us on what you find.

 

Ben

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 2 of 8
(2,936 Views)

Thanks for your brain cells, Ben.

 

 

 

1) Make sure you have shut off "Automatic Error Handling" to rule out the VI needing recompiled because of error handling checks.

 

I didn't explicitly check that, but the fact that I replaced the feedback node with a while loop / shift reg seems to rule that out.

 

 

 

2) Experiment with including the Re-entrant VI in the OTHER branch of the project (move from Windows so RT or vise versa) or removing it from teh project completely and let it just show up in Dependancies.

 

It's not in the project where I USE it.

 

If I move it from the RT side to the host side in the project where I BUILD the PPL, then I get the same thing in reverse.  It works on one side and loads broken on the other.

 

There's something about the feedback node that compiles differently on RT vs. Host, it looks like.

 

 

If you learn anything, please feel free to school us on what you find.

 

Well, I'm not shy about doing that, but I can't chase it any more now.  The WHILE loop works.  My first venture into usage of the feedback node is a failure.

 

C'est la vie.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 3 of 8
(2,924 Views)

Are you sure it is the feedback node that is causing it?  I'm thinking it is more that the same VI is being used on both targets.  Each target compiles it differently.  And whichever way it was last saved, the LV recompiles it for the other target and then asks you to save it because it is recompiled.

 

Suppose you made two identical, but separate VI's, one for each target.  I'm thinking that neither will be ask to be saved after the first time each gets saved.

 

I remember having something similar to a small VI where I was using it both on a PC and on a Fieldpoint target in the same project.

0 Kudos
Message 4 of 8
(2,903 Views)

Are you sure it is the feedback node that is causing it? 

 

--- I have several other VIs that are used in both targets. No problem.

--- When I convert to WHILE LOOP / SHIFT REG, I can use it on both targets - no problem.

--- If there's another conclusion to draw, I don't see it.

 

 

 

I'm thinking it is more that the same VI is being used on both targets.

 

--- I have several (50+) other VIs that are used in both targets. No problem.

 

 

 

Each target compiles it differently. 

 

--- And why is that?  It doesn't happen for ALL my shared code, just a few.

 

 

 

 

And whichever way it was last saved, the LV recompiles it for the other target and then asks you to save it because it is recompiled.

 

--- That seems to be what's happening.  But why?  It doesn't have to save EVERYTHING, only this one.  At least one OTHER one has a similar function, with a feedback node in it.  It shows the same symptoms.  That one is not in a PPL, so it doesn't load broken, but it does the who-saved-it-last trick, same as the one above.

 

 

 

Suppose you made two identical, but separate VI's, one for each target.  I'm thinking that neither will be ask to be saved after the first time each gets saved.

 

I don't want to do that, for maintenance reasons, but that's a reasonable supposition.  The question is why?

 

 

 

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 5 of 8
(2,895 Views)

Maybe it is something about feedback nodes that compile differently as compared to other program aspects, but the fact it is based on the targets changing I think is still the key part of the equation.  It is interesting that a shift register is not causing this while a feedback node it, because I often think those two things are interchangeable.  But they probably aren't truly identical and there maybe some slight, subtle difference about a feedback node as compared to a shift register.

 

Maybe someone from NI who knows more of the underpinnings of the compiler can explain why a feedback node would cause it to compile differently for different targets and will respond.

0 Kudos
Message 6 of 8
(2,893 Views)

It is interesting that a shift register is not causing this while a feedback node is, because I often think those two things are interchangeable. 

 

I thought so, too.  I never used feedback nodes until I tried this recently.  It made for neater-looking code, but it seems like the same function.

 

But no.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 7 of 8
(2,886 Views)

For what it is worth...

 

The initializer terminal is unique from the SR.

 

When used in FPGA it is different.

 

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 8 of 8
(2,879 Views)