Load Problems

[tcjinaz]

We have had trouble for a big portion of the build season with loading the cRIO from LabView. Thinking we had gone too far with the code somewhere, we started a fresh project today from the arcade w/simulation. Started adding stuff slowly, until it broke. Well, it broke on something really simple. Added a control, and a VI to spit out a string based on the input control (built an enum to avoid name issues on SmartDashboard data). Well the attached doesn't load in the simulator, and smells like our problems going to the cRIO . What dumb thing have we done?
TIA
Tim

[Greg McKaskle]

The attached code is missing DevRefGet.vi. It is also missing the .ctl files, but I can get around that. If you attach or send the other file, I'll load it in the simulator to try to reproduce your problem.

Looking at the code, I don't see anything obviously wrong. What broke? Does it not compile, not run, something else?

Also, I see the value in the enum to string for the DevRefs if/when you are making code changes. But perhaps these would be better to build as an enum ring rather than a radio button control? The enum ring looks just like the one on the diagram. You can use the properties dialog box to build it, or you can type in the name, shift-enter, and type in the next, etc.

Greg McKaskle

[tcjinaz]

This got really ugly.

Let's start with my environment: Windows8 running in a virtual machine by Parallels under OSX 10.9.2 on a maxed out last Fall MacBook Pro. I know, lots of foundation variables.

Today, I create a new arcade project w/simulation. DS and a slightly customized DB are running. I go to RobotMain, change the target to My PC, then deploy from the white arrow. Result, No Robot Communications. See attached.

Something's corrupted some where. How does this happen?

TIA,
Tim

[Greg McKaskle]

Your setup sounds like mine, only mine is an older macbook. It should be fine.

Your DS window is covered, so I can't see the state of communications. The Waiting to Respond message is a generic message when the protocol isn't advancing. It can mean many things.

I can see your project window, and the LED on your target is not lit. This means that the first step is to find and connect to the controller. Once that happens, it asks the controller if it is already running code, what code, please stop and run this code instead, etc. That is the protocol.

My suspicion is that your VM networking may not be correct. Mine sometimes gets wonky when the laptop sleeps. It may be worthwhile to look at the DS Diagnostics screen to see if the ping LEDs next to the robot are lit green or not. You can also break the protocol down a bit and do smaller steps. If you right click on the target and choose Connect, this will only do the first portion of the protocol. Until this works, don't worry about your code or anything else.

If you post more description and more pictures, I can more easily help you get this going.

Greg McKaskle

[tcjinaz]

Thanks Greg. You start early Unfortunately, I am doing this after work in a timezone an hour later than you.

Built a arcade sim project from scratch. With no changes, I tried the target connect. The attached screenshot shows the results. Looked at the ethernet control panel and it was configured for IPv4 10.38.53.5

I hate Windoze...

Tim

[Alan Anderson]

Originally Posted by tcjinaz

Looked at the ethernet control panel and it was configured for IPv4 10.38.53.5

Did you check the Advanced settings to make sure that was the only IP address configured?

[Greg McKaskle]

Your DS has not been setup for your team number. It still reads xxyy. So the ping results are not valid. I think the simulator will work once that is corrected. You enter the team number on the DS's setup tab.

Greg McKaskle

[tcjinaz]

That's something new. The DS started forgetting the Team # between invocations. I can get a little farther now.
Did see some new mesaages that I had not seen before, about a loop running too slowly. Took a minute to remember the drive for n seconds VI is a loop
BTW, I asked the lint question, just to close that loop.
This isn't over yet, but I stopped going backwards.
Thanks,
Tim

[tcjinaz]

What expectations should we have of timing accuracy in the simulator? I am seeing what I thought was a lightly loaded TeleOp reporting 20-70mS executions (via 'Elapsed Timed.vi'), plus reported errors about a loop running too slow. The only loop referring to the asset was in TeleOp.

Aside: it would be nices to have a save as text option in the DS Diagnostics Message window. Triple-click is marginally useful. While we're at it some kind of text save from charts would be good. Or, toss out the definition of the stored file structure. I'm itching to code some Python

Oh to work in Unix, now that Spring is here.

Later,
Tim


PS CD's in trouble, I have come to grips with uploads

[tcjinaz]

PROFILE IS GREAT!

Found our stupid user trick (sending too much DS data in TeleOp) in a minute or two.

THANKS GREG

[Greg McKaskle]

Glad you found it. To answer your questions ...

The simulator is not simulating a cRIO, but it is a logical simulator of the code that runs on the cRIO. I'd expect that it will normally run faster than the cRIO, but that depends on the computer it is run on.

The log file format described in a few places on CD. Here is one http://www.chiefdelphi.com/forums/sh...d.php?t=104689

Since the log file contains all the info on the Diagnostics/Messages string and all of the Charts info, three are no other export buttons at this point. All of this is being reworked for 2015, so they may show up there.

Greg McKaskle