Conflict Resolution

[3286]

We have tried uninstalling and reinstalling the Labview program and even installed it on another computer but we keep getting the same conflicts for some reason.

[Alan Anderson]

That isn't an error message. It's just an informational warning letting you know that there is a program already running on the cRIO, and it will be be shut down if you continue with the process of deploying.

Since that's what you want to happen, just click OK and let it continue.

[3286]

We've continued but the robot code does not show up when we deploy it.

EDIT: We have re-imaged the cRio and the robot code loads fine, but it will not respond to the joystick. The laptop reads the joystick inputs but the robot itself won't move.

[Baconfly]

Sorry to ask, but is the refnum for the joystick the same in the teleop.vi as in the begin.vi?

[Alan Anderson]

Originally Posted by 3286

We have re-imaged the cRio and the robot code loads fine, but it will not respond to the joystick. The laptop reads the joystick inputs but the robot itself won't move.

Just to get the question out of the way before we go deeper into debugging:

Have you clicked the "enable" button on the Driver Station in order to enable the robot?

[3286]

We enabled it. We got Error code "44061 occured at Left and Right motor in the VI path in Main.VI"

[Alan Anderson]

Originally Posted by 3286

We enabled it. We got Error code "44061 occured at Left and Right motor in the VI path in Main.VI"

That most likely means the "watchpup" has decided you're not updating the motor speeds often enough. If you added any programmed delays in Teleop, that could cause it. Intentional delays or long-running loops are rarely the right answer.

What have you changed from the default robot project?

[3286]

Here is the most current situation. Reinstalled all 3 of the updates for 2011. Deleted all of the saved FRC2011 project files from our documents ( the existing code that would be written and deployed to the crio from our computer ) Reimaged the crio. Built, deployed and ran at start up the FRC 2011 canned code from Labview, with no changes to it whatsoever. Still getting the 44061 error. Driver station shows the pwm width changing on the status bars when the joystick is moved in any direction. Camera is working.

Error in execution in loading the program? Could we have somehow corrupted the files in our laptop? We could uninstall and reinstall labview and the 3 updates easily enough, we have lost a ton of time here but seem to be running out of logical answers.

The odd thing, it actually did work prior to trying to integrate the compressor vi's from the labview examples. Last year the compressor portion was already in the FRC canned code and this year it appears not to be.

Thanks again

Mike

[Mark McLeod]

The -44061 error is not your fault.

The 3.0 version of the default Framework, without changes, generates that error for everyone.
The LabVIEW 3.1 Update that was just released fixed that small oversight.

In Periodic Tasks.vi there is an LED toggle function that runs in a loop of 0ms by default and drains the CPU dry.
So, in projects based on the original version of the Framework, the CPU usage is at 100% when the project first starts up.
It gets better once you Enable from the Driver Station and the original zero default value gets overwritten with a bigger number.

They fixed that default value in 3.1 so projects created after applying the 3.1 update won't show that error.

To fix your pre-3.1 project you just need to change the default value of that LED toggle.

• From the Project Explorer window, go to the file called Robot Global Data.vi.
• You'll see LED Toggle Rate (ms) with a value of 0.
• Change the 0 to 1000
• Right-click on the value and choose Data Operations->Make Current Value Default

Then Build and Run as startup again.

[3286]

Alan, Mark...THANK YOU VERY MUCH, thank everyone who replied. We have had a huge exercise in wondering " WHY " because we had a successful deploy and run and then we didnt, and we chased everything that seemed logical wondering if it was something we had changed or not. That was why we tried several re imaging and re deploying, even to the point of uninstalling and reinstalling the software and updates.

My size 13 boot would love to stop kicking myself in the backside, was this generally well known and did we miss it in a update or post somewhere along the way or was this discovered the hard way and result in lots of other teams having the same frustration and lost time? Theres that part of me that would love to pass the blame somewhere , but that wont help anything now, so I guess Ill pull my big boy pants up and move along.

Mike

EDIT: We have been getting the same error message over and over again. From the picture on the first post there says there is a conflict but we can't locate the conflicts. Is there any way to check where the conflicts are located? We've tired backtracking them manually but to no avail.

[Alan Anderson]

Originally Posted by 3286

EDIT: We have been getting the same error message over and over again. From the picture on the first post there says there is a conflict but we can't locate the conflicts. Is there any way to check where the conflicts are located? We've tired backtracking them manually but to no avail.

The "conflict" is between the code that's already running on the cRIO and the code that you're deploying to it. You're telling the system to accept a "Real-Time Startup Application", and it's letting you know that there are things running that it will have to stop in order to continue. That is a normal part of the process. It isn't an error message. Don't worry about it.