console is very unresponsive

[Joe Hershberger]

Make sure that you have the "console out" DIP switch on the cRIO off if you are using the network console.

[virtuald]

So I just left... is it set to that by default? And what does it do -- will the console still work if its not set?

[Joe Hershberger]

So I just left... is it set to that by default? And what does it do -- will the console still work if its not set?

When the cRIO is shipped, all dip switches are off. The network console will still work, but the console will not be hooked to the serial port on the cRIO. When the console is hooked to the serial port, that means it is delayed by the serial port I/O which is only 9600 baud.

You should get faster network console performance when the serial console is disabled.

[virtuald]

Ooh, that is a convincing argument. Is this documented somewhere... I don't recall seeing it. If not, it should be.

[virtuald]

Ok, so I *finally* got around to doing that, and it doesn't work either. Next idea? This is rather annoying...

[Joe Hershberger]

Can you just post your code, or preferably the simplest example you can create that reproduces the problem, so I can have a look?

[virtuald]

Here you go. Keep in mind this is running with the 1/1/2009 update... I didn't notice today's update until just now.

[Joe Hershberger]

Wow... after all this, it ends up being completely unrelated.

First note, you shouldn't use a variable named "time". That's already taken as the name of a function: http://www.cplusplus.com/reference/clibrary/ctime/. Granted, it will overide it locally, but it's bad form.

Now for the true meat of your problem... in a word: float.

You are calling GetTime(), which returns the time from the real-time clock. That means the number is huge, since it's in seconds since 1979 or something like that. The function returns a double. You defined the variable "time" as a float. That means that when you assign GetTime() to time, it casts it to a single-precision floating point number (float). Since the number is so huge, the resolution of the float is 128 seconds! That means that your attempt to print 10 times a second was not working and you were simply printing continuously, filling up the printf buffer and making the console response be terrible.

Phweeew! So... you have a couple options. You can simply make "time" a double (don't call it "time") or you can call GetClock() instead, which is the number of seconds since the FPGA was reset. Since this is a MUCH smaller number, you will have plenty of precision with your float.

Finally resolution to this problem! (Terrible pun, I know. )

Cheers!
-Joe

[virtuald]

Heh. Well... ____... Just.. ____. *hits self*

To be honest, I used the float because everywhere else everything in WPILib was using a float so I didn't even bother thinking about it. I really don't like using floating point numbers in general because of that set of problems (and when I do, I'll use double) -- I've explained this type of thing to the students a number of times. Go figure that I get bit by the same thing... this is why one shouldn't use floating point numbers for discrete quantities like time... lol.

I'll try this tomorrow if there isn't a snowstorm. You're probably right though... would certainly explain a LOT (for instance, we were writing to a file in that type of loop and the robot went out of control... ).

And its seconds since 1970.

[virtuald]

That did it, thanks a lot.