Channel Wire Behavior in Executable

[MeCoOp]

I'm using LabVIEW 2016 and I have a producer/consumer architecture with several producer loops sending data to the consumer via channel wires.  One loop is reading voltages from an NI 9205, I'm using 7 channels total that are being read into an array.  The array and the error cluster for this producer loop are then sent to the consumer loop where they are displayed to the user.  In development mode all channels function as I would expect.  When I make an executable the first element of the array doesn't read.  It's connected to a pressure transducer but shows no response to stimulus.  Anyone run into a similar problem or have insight to what I may have over-looked?

Thanks.

[crossrulz]

Sounds like a hardware wiring issue to me.  Does the task work in MAX?

[stevem181]

A few suggestions:

1) Show us the code

2) Place an indicator for the problem channel (chart for example) ahead of the Channel Wire code

    This would be a temporary measure to see if the data is OK before the CW stuff.

3) Try using the Remote Debugger - Operate -> Debug Application or Shared Library

    (You have to set "Enable debugging" on the Advanced page of the build specification.)

steve

[MeCoOp]

It works fine in MAX and on the development machine, I only run into the issue when using the executable.

[Bob_Schor]

Your title suggests that you are "suspicious" of the behavior of (your) Channel Wires in your Executable.  I have been using Channel Wires for about two years, and have built numerous Executables using them, without any problems or issues.

I suspect you have a "bug" in your code, which is difficult (for me) to identify without seeing (and potentially running/building/modifying/testing) your code.  So don't send any pictures of Block Diagrams -- send actual VIs, or if it is in a larger LabVIEW Project, compress the Project Folder and attach the resulting .ZIP file.

Another technique which can help is to find a colleague with some knowledge of programming and walk through the code with her.  You'd be surprised how often the "Aha!  What was I thinking?" light bulb goes on.

Bob Schor

[billko]

---

@Bob_Schor wrote:

Your title suggests that you are "suspicious" of the behavior of (your) Channel Wires in your Executable.  I have been using Channel Wires for about two years, and have built numerous Executables using them, without any problems or issues.

I suspect you have a "bug" in your code, which is difficult (for me) to identify without seeing (and potentially running/building/modifying/testing) your code.  So don't send any pictures of Block Diagrams -- send actual VIs, or if it is in a larger LabVIEW Project, compress the Project Folder and attach the resulting .ZIP file.

Another technique which can help is to find a colleague with some knowledge of programming and walk through the code with her.  You'd be surprised how often the "Aha!  What was I thinking?" light bulb goes on.

Bob Schor

---

You don't know how many times I'm discussing an issue with a colleague and suddenly "OH!  Never mind, I got this."

[DuncanW.]

I agree that this is probably a bug in your code. Since it hasn't been mentioned here yet, I would also recommend looking at the way you are referencing physical channels. For example, if you are hard coding channel names, then it is quite possible that, once you move out of the development environment, LabVIEW is unable to recognize the device channels because it is expecting a different naming scheme. This thread offers a better explanation of these kinds of issues and how to solve them.

Based on your description of the problem, I would be surprised if this is your particular issue, but it is definitely worth thinking about. As others have said, please provide VI's!

Best,

Duncan W.

[MeCoOp]

Thanks to everyone that has replied.  I know ultimately the easiest would be to post the code I'm a little reluctant because there are some shared variable in there that won't work and I'm not sure how work would feel about posting all of it so I may have to edit it heavily to post the code with the problem I'm dealing with.  

I did however go into the loop that is reading the array of voltage channels from the NI 9205 and feed an array control to the channel wire instead.  When I did this I did receive the feedback I would have expected from the first channel and it did respond to me manually changing the channel.  I went into max and confirmed again that channel 0 is reading.  I've attached two pictures showing the set-up of the task and the read from the NI 9205.

I should also mention the array manipulation worked in development and as an executable.

Thanks.

[DuncanW.]

Since your code was able to recognize a control array, you are seeing the proper input in MAX, and it only breaks upon being ported as an executable, the problem is probably either in your configuration and use of the DAQmx task, or in building the executable.

Things to check to test task config:

Are you testing the input in MAX using the exact same configuration as your programmatically created task?

As I mentioned in my earlier post, I would not recommend explicitly defining channel names if you are planning to port your code to another machine. Unless you can guarantee that the 9205 on every computer will be called "VoltIn", then your code that is passing VoltIn/ai0:6 to the Create Task VI will likely break at some point.

Things to check to test executable:

Make sure your code contains nothing system-specific. This can include any reference that is explicitly defined. While these can be used effectively, you need to be very careful when using any hard-coded references or absolute paths across machines.

Is all of your software up-to-date on both machines? You may be experiencing some kind of conflict between DAQmx driver versions that is corrupting your read at times.

It will be hard to offer more specific advice without being able to run and inspect your code ourselves.

Duncan W.

[MeCoOp]

Duncan - Your point about explicit channel names is well taken.  I build the channel name to include the test station ID so for the third test station VoltIn becomes "TS3VoltIn."

I'm currently running through all of the available NI Updates now to see if that helps solve the problem.

Thanks to everyone for the suggestions.