Labview Deployment succeeds, but doesn't actually do anything

[MasterofUnlocking]

Hello everyone, I've got a few questions regarding Labview deployment issues. I was brought on to an already existing project and after a few weeks, successfully finished updating the existing code to how it was expected. From that point, the goal was to deploy that code onto a Windows XP computer (Does not have any Labview components installed on it) that was hooked up to our PLC via Ethernet cable. Unfortunately, this deployment is causing me headaches.

As I understand it, once we are finished with a project, we then create an executable and installer file through the build specications option, which I have done. Then, we install the file onto the target computer along with any other dependicies it has. This all SEEMINGLY goes well, I get no error messages or anything of that nature. However, upon running the program, it simply doesn't work. Ideally, from this program, we can control and monitor all of the various valves, sensors and whatnot connected to the PLC, along with recieving notifications in certain instances. None of this is functional when running it from the target computer.

One thing to note is that we are using various .NET components to email these notifications, but the PLC doesn't support any wire/nodes that use .NET. To make sure that alone wasn't the issue, I reverted back to older code without the notifications implemented and still nothing worked. This brings me to my questions:

1) Is there something I'm missing that could be causing these issues in the deployment process?

2) How can I use .NET features if the PLC doesn't support them? Or is that I will just have to find another way to do this?

Thank you all for your help!

[dthor]

When you say the built executable doesn't work, can you be more specific?

• Does the .exe just not launch? This is likely because the LabVIEW Runtime is not installed on the target computer
• Does the .exe launch, but the run button is a broken arrow? This could be any number of issues, possibly because the drivers for the PLC or for .NET are not installed.
• Does the .exe launch and run, but then there is no communication between the instrument and LabVIEW? Perhaps a control, such as a VISA address, doesn't have a default value set. I know that's bitten me before... Or, possibly, the component inside MAX has a different alias than on your development machine.

I don't think that using .NET to send notification emails would cause any issues with the PLC, because it's LabVIEW and the XP computer that are running the .NET code, not the PLC.

Unless, of course, I'm misunderstanding something.

[MasterofUnlocking]

You're right, I should have clarified. Out of the three you mentioned, it's the last one. The program launches, we can run it(ie, no broken run arrow), but there is no communcation. For example, we have a group of gauges that should read off some level sensors. When the program starts, they have their default value, but instead up updating, they revert back to their lowest point (Negative something, I'm assuming either the past programmer set this or it's a labview default).  Regardless, as you said, it seems that the two aren't communicating for some reason.

As for your last point, I agree with you. I didn't think there should be any issues. After some thought, I'm thinking it may be due to how the project was set up initially. From what I remember, there were two "sections": The target PC and the PLC. For some reason, I think the original team had the VI we are using under both the computer and the PLC, causing the .NET errors. I don't think this is necessary...especially if I can get the .exe to communicate with the PLC properly. Am I right to assume this?

[nathand]

When you say "PLC" are you referring to one of NI's embedded systems such as Fieldpoint or compact RIO?  If so, then you likely have two separate portions of your application: one that runs on the embedded unit, and the other that runs on the PC.  If you're only updating one, it is not surprising that it's not working as expected.

Which version of LabVIEW are you using?  Have you considered using the remote debugging feature to look at what your application is doing when compiled as an executable on the other computer?

[MasterofUnlocking]

---

@nathand wrote:

When you say "PLC" are you referring to one of NI's embedded systems such as Fieldpoint or compact RIO?  If so, then you likely have two separate portions of your application: one that runs on the embedded unit, and the other that runs on the PC.  If you're only updating one, it is not surprising that it's not working as expected.

Which version of LabVIEW are you using?  Have you considered using the remote debugging feature to look at what your application is doing when compiled as an executable on the other computer?

---

We are using fieldpoint, so I suppose that would be to what I'm referring. Other people here have called it the PLC, so that was probably a bit confusing. I didn't realize that you had to update both portions, is that ability within the project tools?

We are using Labview 2010 for our work along with it's respective components so it's fairly new. Unfortunately, all of the hardware including the other computer is at a location where remote debugging would be...difficult. If possible, I'd like to save that as a last resort (Though I'm near that point already )

[Jed394]

I've run into the same issue with deployment to a CRIO and LV 2011.  I'm in the middle of trouble shooting the issue right now and will update if i figure out whats going on.  Currently, my main VI runs fine when running locally but when building a startup application it is listed as "BAD" within the system monitor after deployment and reboot.  Therefor the VI is just never running.  This seems to be a strange behaviour considering this VI was successfully deployed before with very little changes since then.  

Another simular thread suggested using a source distrubution, i have yet to try that.  I will update if i find a solution to my problem that might help you as well.  

[nathand]

Do you know which Fieldpoint module you are using?  Some modules are actually self-contained computers which can run code; others are simply IO units (and the "smart" units can act as IO units without running any code).  You'll need to know how you're using the module.  Does a Fieldpoint module show up as a target in the project explorer?  If so, and you have code that runs on it, you can create a separate build specification for that application, then build and deploy it from the project explorer.

You mentioned that you took over and updated an existing project.  Was the original project written in an older version of LabVIEW?  If so, the target PC might have an older version of the Fieldpoint tools, and if you do have a smart Fieldpoint unit, you may need to upgrade it as well (you can do this within measurement and automation explorer).

Without having more knowledge of the details of your system, it's difficult to provide specific advice.  From your questions it sounds like you're not too familiar with the LabVIEW project environment and working with other targets.  It would help a lot if you could get an identical Fieldpoint setup on your desk to troubleshoot deployment and communication.

[MasterofUnlocking]

---

@nathand wrote:

Do you know which Fieldpoint module you are using?  Some modules are actually self-contained computers which can run code; others are simply IO units (and the "smart" units can act as IO units without running any code).  You'll need to know how you're using the module.  Does a Fieldpoint module show up as a target in the project explorer?  If so, and you have code that runs on it, you can create a separate build specification for that application, then build and deploy it from the project explorer.

You mentioned that you took over and updated an existing project.  Was the original project written in an older version of LabVIEW?  If so, the target PC might have an older version of the Fieldpoint tools, and if you do have a smart Fieldpoint unit, you may need to upgrade it as well (you can do this within measurement and automation explorer).

Without having more knowledge of the details of your system, it's difficult to provide specific advice.  From your questions it sounds like you're not too familiar with the LabVIEW project environment and working with other targets.  It would help a lot if you could get an identical Fieldpoint setup on your desk to troubleshoot deployment and communication.

---

I believe we are using a cFP-2220 fieldpoint module, which does indeed show up as a target. So, from your advice, I would a create separate build application for the fieldpoint module, using the same VI I have used for executable on the PC. After creating the build application, I must then build and deploy it from within the project explorer. If that's the case, that all makes sense to me and I believe there shouldn't be any further issue.

As for the original project, no, it was all done within the same version of Labview. Regardless, I plan to update the Fieldpoint tools module as well, just to make sure everything's good.

[MasterofUnlocking]

---

@Jed394 wrote:

I've run into the same issue with deployment to a CRIO and LV 2011.  I'm in the middle of trouble shooting the issue right now and will update if i figure out whats going on.  Currently, my main VI runs fine when running locally but when building a startup application it is listed as "BAD" within the system monitor after deployment and reboot.  Therefor the VI is just never running.  This seems to be a strange behaviour considering this VI was successfully deployed before with very little changes since then.  

Another simular thread suggested using a source distrubution, i have yet to try that.  I will update if i find a solution to my problem that might help you as well.  

---

Cheers, I'll do the same mate. Thanks!

[nathand]

---

@MasterofUnlocking wrote:

---

@Jed394 wrote:

Another simular thread suggested using a source distrubution, i have yet to try that.  I will update if i find a solution to my problem that might help you as well.  

---

Cheers, I'll do the same mate. Thanks!

---

Just out of curiousity, which thread was this?  I can't see how that could help.