LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Broken Arrow --No Errors

I have a project that I am updating from LV 8.2 Legecy DAQ to LV 2011 DAQmx.  I had done 99% of the changes needed when I suddenly noticed that I have a broken arrow. When I check the error log I find no reported errors.  I see this type of issue reported back in the LV7.1 days but nothing recent. I have tried mass compile but it gets dozens of errors. Here are just a few:

 

#### Starting Mass Compile: Thu, Jan 19, 2012 4:16:56 PM
  Directory: "P:\FREEMAN\Labview\Autotest_2012"
  ### Bad VI:    "Get Test Parameters Rev A1.vi"    Path="P:\FREEMAN\Labview\Autotest_2012\Autotest Rev G2d w zero crossing.llx\Get Test Parameters Rev A1.vi"
  ### Bad VI:    "Autotest Rev jjf01-09-12.vi"    Path="P:\FREEMAN\Labview\Autotest_2012\Autotest Rev jjf01-09-12.vi"
  ### Bad VI:    "Autotest Rev jjf01-13-12.vi"    Path="P:\FREEMAN\Labview\Autotest_2012\Autotest Rev jjf01-13-12.vi"
Search failed to find "Write to Digital Port .vi" previously from "<vilib>:\DAQ\1EASYIO.LLB\Write to Digital Port .vi"
Search failed to find "AI Read (scaled array).vi" previously from "<vilib>:\Daq\Ai.llb\AI Read (scaled array).vi"
Search failed to find "AI Read.vi" previously from "<vilib>:\Daq\Ai.llb\AI Read.vi"

 

I can find and open each of the above and all exist none have broken arrows. 

 

Has anyone ran into this with LV 2011?

 

 

0 Kudos
Message 1 of 6
(3,237 Views)

You upgraded to a NI-DAQ version that no longer supports LabVIEW 8.2.  (And may be using obsolete traditional DAQ functions)

 

Search NI for "Upgrading from Traditional DAQ"  there will be a good Knowledge Base article to help you


"Should be" isn't "Is" -Jay
0 Kudos
Message 2 of 6
(3,225 Views)

"Write to Digital Port" and "AI Read" are definitely Traditional DAQ VIs. You indicated that you were transitioning to DAQmx but it appears that some of your code is still using Traditional DAQ. Do you have both Traditional DAQ and DAQmx installed?

0 Kudos
Message 3 of 6
(3,201 Views)

Thanks to both Jeff Bohrer and smercurio_fc for the tip.  In my work to convert to DAQmx, I thought I had found all of the old Triditional DAQ vi's but as you both point out the flagged vi's are not DAQmx. I will review and search out  any Triditional vi's. 

0 Kudos
Message 4 of 6
(3,183 Views)

I just resolved this problem.  Turned out I did NOT have any Traditional DAQ vi's in my code. None of the sub vi's that did DAQ operations had broken arrows. Only the top level vi exhibited the broken arrow. This lead me to believe that the problem was somehow originating in my top level vi which was in process of being converted into a State Machine type structure when the problem appeared.

 

In the process of editing the top level vi into a state machine I had a single frame Stacked Sequence sitting outside of the main State Machine Loop. This Stacked Sequence contained a Two Button Dialog box with a string constant input. It was left over from the original non-statemachine code as a reminder that I needed to quiry the user if they wanted to test another item. 

 

To clean up my diagram I deleted the Stacked Sequence and it's contents. As soon as I did the broken arrow went away.  I did a Ctrl-Z to undo the deletion and the broken arrow came back. I then did a Remove Sequence deleting the Stacked Sequence but leaving the Button Dialog box intact. The broken arrow went awayAgain I did a Ctrl-Z to undo and the broken arrow came back.

 

OKnow it was apparent that this Stacked Sequence was the culprit. I then did a right click Replace on the Stacked Sequence and told LV to replace the existing Stacked Sequence with a new Stacked Sequence. This also eleminated the broken arrow. After I did the replace, doing a Ctrl-Z would not break the arrow.

 

Conclusion: This code was originally written in LV 5.0 and has been revised many times with the most recent revision done in LV 8.6. I assume that the Stacked Sequence somehow was carried over from a previous version of LV and was corrupted. Replacing it solved the problem.

Message 5 of 6
(3,168 Views)

It's possible. It's also possible that the sequence was resized in such a way that code got hidden. That was quite possible to do in earlier versions of LabVIEW, such as LabVIEW 5.

0 Kudos
Message 6 of 6
(3,163 Views)