NetConole replacement

I have written a net console replacement. This is a Windows console app (i.e. run in a CMD window) called netterm (attached here). One of the advantages of this program is the support for ANSI font color.

Our robot code has macros printing “Info”, “Warning” or “Error” messages. Info lines are green, Warning lines are yellow and Error lines are red. When debugging the robot code, we found that debug spews are sometimes too chatty especially when using the CANJaguar class. Sometimes, our debug messages got drowned in the ocean of messages. Having different colors help us to spot important messages our code printed out. Another useful option is the ability to save the debug session into a log file.

For syntax on how to use this tool, type “netterm /help”. The first time you run this tool, you need to provide your team number. For example,
netterm /team=492

The program will save this info into the registry so the next time you run it, you just simply type:
netterm

Don’t worry about the other options. For FRC application, all options should have the correct default values. The options are for communicating with other applications.

Since the app monitors UDP port 6666, when running the first time, Windows Firewall will prompt you for permission to monitor network ports.

NetTermTool.zip (12.5 KB)


NetTermTool.zip (12.5 KB)

Is there any chance we could see the source for this? I’d like to build it for mac too!

You can access the source here.
http://proj.titanrobotics.net/hg/Frc/Tools/file/eb83d84b6846/NetTerm
But what operating system are you running on the mac? This is written as a Windows console app. So it will take some effort to port to the mac OS.

I’m running Mountain Lion. Actually, I was able to get your EXE to run in the mac command line with Wine. I’ll probably stick with that, instead of porting it. Maybe porting will be my offseason project.

The RoboPy guys have a python-based replacement (though not supporting color afiak)
You can find it at https://github.com/rbmj/netconsole and it should run cross-platform fairly gracefully. You need python (Not any of the robot stuff, just python) installed on your computer to run it, but it supports any robot language that uses NetConsole.

Hey, that’s a pretty neat app. I like it. :slight_smile:

Perhaps you can help with a problem we have. Some text is not transmitted from the cRIO to NetConsole. This is intermittent. For example, we print a small amount of info just after the robot boots, via printf’s in RobotInit(). Sometimes the info is printed, sometimes not, and sometimes part of it is printed. More often than not, none or only part of the info is printed.

We also experience dropped characters when typing in the console. The cRIO recognizes what we’ve typed, but doesn’t always display all of the characters.

I was hoping that NetTerm would fare better, but NetTerm seems to have the same issue. So I assume the issue is on the cRIO side or in the communication path. Any ideas?

Both netterm and netconsole use UDP. By definition, unlike TCP, UDP doesn’t guarantee no packet loss. So if you overwhelm the network with packets, it is possible to lose some. It is just the nature of UDP for higher performance. Netterm allows you to switch to TCP but communication protocol must be agreed on both sides. So if you want to use TCP, both side must be using TCP. Unfortunately, the cRIO side is designed to use UDP only. So this doesn’t help you. In any case, if you overwhelm the network with packets, you should reconsider how you do printf’s. Printing lots of stuff in a tight robot loop is normally discouraged. This will drastically slow down your robot and may cause the “Watchdog not fed” warning so the robot may hesitate. If you want to see the value of some variables, there are many alternatives than using plain printf’s in a loop. If you really want to do printf’s in a loop. Do it once every 10 or 20 loops or so. You can also use the SmartDashboard to monitor variables.
EDIT: After reading your post again, you seem to have a network dropout issue. You may want to reposition the wireless router on the robot. If the network drops out intermittenly, UDP will also drop packets.