Constant failure to deploy

[MarkBlack]

If you import the VIs from the problem project into a blank project does it still fail to deploy?  Can you post the text from the deployment dialog window when it fails?

-Mark

[Daniel_H]

I checked battery levels and voltage level on the cRIO and it's all ok.

Maybe I found the problem.

I'm using tons of smoothing filters. In one of my deployment tests I removed them and it deployed.

I also left all camera VIs and it deployed, I removed only the filters.

Its going to be a problem to work in traction control without these VIs, though..

here's a screenshot of my original program:

It's also possible to create a smoothing filter using this menu:

but they also didn't deploy, and the output signal is not very good.

Anyone else found this problem??

[MarkBlack]

We believe this is an issue with building code using VIs from the signal processing palette.  R&D is looking into this and we will keep you updated with what comes out of that.

[MarkBlack]

Cross Post

This has been escalated to R&D and they have been investigating it. So far we might have a work around for you: If you open the build spec, visit the page for exclusions, and check the option to remove unused members from project Libraries, your build time should return to reasonable times.

Sorry for the troubles, I will give you an update when I have more information.

[njg]

Yesterday I rebuilt the application and tried deploying to the cRIO using a fully charged battery - no difference.  It appears that most, if not all, of the files are being sent, the host computer looses communication with the target, and then displays a "failed to deploy".  Rather than going the route of a new project and/or attempting to narrow down what might be causing the download failure, I decided to ftp directly to the cRIO and place the contents of my build folder directly in the cRIO startup folder.  That worked!  We now have a robot that starts up with our code.  We'd still like to be able to use the deploy method, but this should narrow down the scope of what isn't working. (and it gets us back on path)  By the way, we're not specifically using any signal processing VIs, though we are using a number of the WPI VIs (in case any of them have signal processing VIs embeded).

[MarkBlack]

njg,

Have you tried removing unused polymorphic VI instances and Disconnecting type definitions from your build before deploying your code?  This has given other teams some success.

Cheers,

Mark

NI FIRST Support

[Daniel_H]

If I check these 3 boxes, my smoothing filters are still going to work?

I was able to build and deploy successfully checking the last one, but I am unable to test whether the filters are working (our electronics are currently disassembled to mount into the robot).

[MarkBlack]

Yes your filters should still work.  These check boxes will only remove the portions of code that are not essential to the operation of that code.

[Scott_the_Idabot]

OK, I figured out what OUR problem was with the constant failure to deploy, maybe it will help others as well

Unfortunatley, I don't have the team laptop with me, so I will have to semi-post from memory.

In the robot root directory there is an ini file, ni-rt.ini.  Within that file is the path to the boot code.  The actual path to the boot code is something like c:/ni-rt/startup, the path in the .ini file was something like c:/ni-rt/C/startup. I simply edited the .ini file and removed all references to the /c.  ( I used WS-FTP to connect and copy files )

I ASSUME the cause of the /c comes from the defalut path on the laptop which includes the \c.  You PROBABLY can edit the path in the build specs and it will solve the problem as well.

A.  I hope this helps someone,

B.  If you need more specifics, I will take some screenshots next time I am at the laptop.

[MarkBlack]

You are correct in assuming these items in the INI file can be changed in the build properties in your project.  The included screenshot shows the location where this can be edited in the Deployment (build) properties.