LabVIEW deployment problems

[kenavt]

Recently, I have been getting problems when deploying LabVIEW code to our practice robot (not permanently deployed, but temporarily, as long as the cRIO is on. I believe this is because the program is saved into RAM memory, but that is not the point of this post).

Specifically, when I attempt to deploy a robot project (from the Robot Main.vi), there springs up a Conflict Resolution window, where a bunch of VIs are unable to be resolved from current dialog, identified as part of a Real-Time Startup Application, and the VIs on the target will have to be closed to proceed. I click OK, and then I move on. Deployment begins and the VIs are pushed to the cRIO. However, they are pushed extraordinarily slow - about one VI every couple of seconds. Meanwhile, I lose comms according to LabVIEW (although the DS shows I still have comms), every once in a while. If I follow through with the whole deployment, I usually get about 85% of the way through, then lose comms permanently. Sometimes, it is before that.

To fix this issue, I have attempted to deploy with the "NO APP" dip switch turned to whatever is not the default position. This did not resolve the issue. Then, a couple of days later, I turned off my firewall, and attempted to deploy. When this failed in the same way as above, I attempted it in conjunction with the "NO APP" dip switch. Still, 'no dice'.

I know my code is fine, as another programmer on my team has deployed the exact same robot project to the same cRIO as it normally should happen, with the exact same ethernet cord (which has been used throughout this experience). This problem recently developed, as I have deployed other code to the cRIO previously (about a month ago). I also have all of the updates installed (LabVIEW, Utilities, and Driver Station).

Frankly, I'm at a loss. I have searched on CD for previous problems, attempted to apply those fixes, and failed. I plan to go to the LabVIEW booth at St. Louis, but until then, do you guys have any clue what's going on?

[Mark McLeod]

When you set the NO APP switch, do you follow that with a cRIO reset or cycling the power, before attempting to run your project?
If you do it right, then there won't be a Conflict Resolution pop-up.

[kenavt]

Originally Posted by Mark McLeod

When you set the NO APP switch, do you follow that with a cRIO reset or cycling the power, before attempting to run your project?
If you do it right, then there won't be a Conflict Resolution pop-up.

I usually cycle the power. Should I be resetting the CRIO (through the DS)?

[Mark McLeod]

Your description sounds like the NO APP switch isn't getting set properly.
To use the NO APP switch:

1. flip it to ON
2. reset the cRIO (3 equivalent ways)
   • cRIO panel black reset button
   • DS Diagnostics->Robot reboot...
   • cycle power
3. After the DS Comm light comes back on, then you can flip the NO APP switch back OFF. You don't have to though until you want the user code to startup automatically.

If you get the NO APP switch working, then you can move on to discovering why you have to use it in the first place.
Usually, it's only necessary if your code is running too fast and hard. There are ways to check on that.

[kenavt]

Originally Posted by Mark McLeod

Your description sounds like the NO APP switch isn't getting set properly.
To use the NO APP switch:

1. flip it to ON
2. reset the cRIO (3 equivalent ways)
   • cRIO panel black reset button
   • DS Diagnostics->Robot reboot...
   • cycle power
3. After the DS Comm light comes back on, then you can flip the NO APP switch back OFF. You don't have to though until you want the user code to startup automatically.

If you get the NO APP switch working, then you can move on to discovering why you have to use it in the first place.
Usually, it's only necessary if your code is running too fast and hard. There are ways to check on that.

I have read in other threads about the System Manager. While the NO APP switch has been ON (and I have cycled power), I have attempted to deploy. I have run the System Manager and observed that the CPU is occupied approximately 10-15% while data is being transferred between my laptop and the cRIO target. The VIs are still being uploaded to the CRIO at its crawling rate.

My friend has deployed the exact same code I have been trying to deploy the whole time with his laptop to the same cRIO, with the "NO APP" dip switch OFF. I believe the problem resides with my laptop hardware (or software on my computer, perhaps LabVIEW), not with the cRIO or with my code.

I have read through a few CD threads on deployment issues, and I believe this is a unique issue, as it hasn't been resolved (as far as I can tell) with the "NO APP" dip switch.

[Mark McLeod]

I agree, it certainly sounds like your laptop is not using the full network.

Does the same laptop appear slow if you're doing typical browsing?
Is there a second NIC on it that you can try, like wireless?

Is your DS using the same NIC?

[kenavt]

Originally Posted by Alan Anderson

How do you have your networking set up? It sounds like you're connecting by wire, but is the D-Link router in the mix? Do you perhaps have both wired and wireless networks active on your computer at the same time?

Originally Posted by Mark McLeod

I agree, it certainly sounds like your laptop is not using the full network.

Does the same laptop appear slow if you're doing typical browsing?
Is there a second NIC on it that you can try, like wireless?

Is your DS using the same NIC?

I am connecting by an ethernet cable while concurrently accessing our team's wireless network. This could, perhaps, be the issue. I will try disabling my wi-fi adapter, and then deploying.

I think all of our team radios are encrypted, but if none of them are, I will try to deploy via those. I will probably get to this tomorrow.

[kenavt]

When I attempted to deploy the code via an ethernet cord with the wi-fi adapter turned off via the hardware switch on my laptop, the deployment was faster, but not the speed it should be still.

Normally, my team has our radios put away and we don't use them at our shop, but I pulled one out and hooked it up. Deploying over the bridge WAS at normal deploying speed (a big relief). Success.

I believe the issue is with my computer's hardware (perhaps the motherboard, I don't know much about computer hardware). I have had problems with my USB ports in recent days, after I spilled a little pop on my laptop. I thought the only consequence was one sticky key, but it appears that it has infiltrated my laptop's case and gotten on the hardware. That probably explains my USB ports (which are physically located next to the sticky key, CTRL) and my ethernet port (which is a little farther away, but on the same side).

Either way, thanks a lot, Mark and Alan. I see the hard work you guys do helping others to fix their programming issues, and I can tell you that it means a lot to me, personally, as well as the others, I am sure. I don't think I can say thank you enough! Thanks!

[FourPenguins]

My team had a similar issue until the NI rep at Buckeye told us to disable Windows firewall. I don't know if that's the issue here (especially given the suspect hardware in your laptop), but he said that that was often the cause of connection/deployment problems.

[torihoelscher]

Originally Posted by FourPenguins

My team had a similar issue until the NI rep at Buckeye told us to disable Windows firewall. I don't know if that's the issue here (especially given the suspect hardware in your laptop), but he said that that was often the cause of connection/deployment problems.

That is true!!!
What my software mentor tells me and I sometimes remind him:
1) turn off wireless
2) turn off firewall
3) ping using cmd
4) if you cant ping power cycle
5) check ip address on computer
5.5) Use Measurement Automation Explorer
6) Reimage CRIO

[Alan Anderson]

Originally Posted by kenavt

I know my code is fine, as another programmer on my team has deployed the exact same robot project to the same cRIO as it normally should happen, with the exact same ethernet cord (which has been used throughout this experience). This problem recently developed, as I have deployed other code to the cRIO previously (about a month ago). I also have all of the updates installed (LabVIEW, Utilities, and Driver Station).

How do you have your networking set up? It sounds like you're connecting by wire, but is the D-Link router in the mix? Do you perhaps have both wired and wireless networks active on your computer at the same time?