[DFTF] We eat what we CAN, and what we can't, we CAN...

[Greg McKaskle]

This link gives some info on the timers. There are other options for reading higher precision clocks, but for message timers, this is pretty good way to go for Windows. Note that the API doesn't guarantee that it will provide one ms resolution, but I've never seen a computer that had a value other than one.

http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx


Marshal was measuring the time at the robot. His first post has attached code, along with a much more interesting dataset from an earlier version of the DS when more UI stuff was causing overhead and lots of jitter.

Will C++ programs have the same resolution? It depends on how they are written. The LV editor and runtime are C/C++, so they call the multimedia API and increase the timer resolution. If they didn't do that, I think the modern Win32 event stuff would have a resolution of more like 16ms. I can't remember for sure what that number is, but the easiest way to measure it is to write a loop that measures the current time, sleeps for a small amount, and checks the time on wakeup. You can then compare the requested sleep amount to the actual time the thread slept.

I've attached images of some similar tests, each run on my VM'd windows 7 that is actually running on my mac. The top chart is a regular while loop with a sleep ms multiple, which attempts to preserve phase, but doesn't try to catch up. The bottom chart shows the same code, but with a timed loop, also set to discard misses, but retain phase. The timed loop in LV implements its own scheduler based on a high priority thread. It improves things a bit on windows, but really shows its stuff on RT OSes. Note that the first point is typically low because the loop is aligning to the clock phase. The tests were also run with standard priority.

As for the other articles you attached. I think that info is most appropriate for threads that do not yield due to I/O. If you have several computational threads maxing out the cpu(s), and you also have the timing threads running.

Due to technical difficulties with the attachments button, I'll attach loaded images in a followup post.

Greg McKaskle

[Greg McKaskle]

This is continued because I couldn't attach these images to the previous post.

These plots show what happens to the timing on Windows when two CPU maxed threads are running in parallel with the time/sleep loop. The top chart is once again timed using the ms multiple icon. The lower chart is the timed loop.

The second image is the same test, but with the time/sleep loops set to time critical priority while the CPU intensive tasks are normal priority.

The moral of the story?
Windows is not a realtime OS, but if you use the APIs well, you can get some pretty good timing from it. LV, in my opinion, makes it quite easy to play with priorities and timings and get a sense of how your system is running. You can certainly do the same with C++ if you are good with thread APIs.

Please note that all of this data was measured on Windows, and VxWorks should typically have even less jitter, but your milage may vary depending on how you use it.

To give details about the DS and the joysticks. The DS has lots of stuff going on internally, and the only high priority element is the control loop that sends the joystick and control data to the robot. Overall, the cpu usage for the app is quite low, and if you don't have lots of other stuff running, you should have pretty good response. The DS has graphs offscreen that I can use to measure its control loop rate under different conditions. Note that FIRST recommends, and I recommend that you go to the trouble of making a kiosk account for the Driver. This is really nothing more than changing the shell of that account to be the driver station. Since Windows Explorer is not even launched, quite a few processes and hooks are inactive. This is commonly done when LabVIEW and Windows are used for industrial monitoring apps or manufacturing test apps, and while it also will not make Windows an RT OS, it does help. It also helps to lock down test machines so that people don't play Solitaire or browse the web when they are supposed to be testing your electronics product. And when this is not good enough, or the PC is used for control, that is when it is important to move to an RT OS such as the one running on the robot.

Greg McKaskle

[Mike Copioli]

Originally Posted by Hugh Meyer

Joe,

2CAN:
Last year the 2CAN and serial port were the two options. NI must support them. This year may be different.

The 2CAN plugin is supported by Cross the Road Electronics, not NI. It is legal for any team to create their own Ethernet to CAN gateway. The API is the same for both serial and Ethernet the only difference is the plugin.

Originally Posted by Hugh Meyer

2CAN Web Page:
The 2CAN will show much data if you hit it with a web browser. We could not do that and control the Jaguars from the CRIO at the same time. It is one or the other.

This should not be the case , we update 10 Jags at a 5mS rate and view the web dash without issue. The Web dash transaction should be the only thing being delayed, if at all, since they have a lower priority than the Set transactions.

Originally Posted by Hugh Meyer

Also, the configuration to get to connect the web interface to the 2CAN is not a legal mode, since you must have a path directly from the browser to the 2CAN. Normally the 2CAN must be connected to the CRIO for normal robot operation. This year may be different, since the 2CAN will be connected to the switch.

I see no rule that states this configuration illegal as long as the "commands" are not altered.

<R59> If CAN-bus communications are used, the CAN-bus must be connected to the cRIO-FRC
through either the Ethernet network connected to Port 1, Port 2, or the DB-9 RS-232 port
connection.
A. Ethernet-to-CAN bridges or RS-232-to-CAN bridges (including the Jaguars, MDLBDC24)
may be used to connect the CAN-bus to the cRIO-FRC.
B. Additional switches, sensor modules, custom circuits, third-party modules, etc. may also be
placed on the CAN-bus.
C. No device that interferes with, alters, or blocks communications between the cRIO-FRC and
the Jaguars will be permitted (tunneling packets for the purposes of passing them through
an Ethernet-to-CAN bridge is acceptable as the commands are not altered).

[Ether]

Originally Posted by Hugh Meyer

Another way to think about this is to imagine a snippet of software code that generates a periodic wave out a port. All will be fine, when the process is running, but as soon as a context switch occurs, the signal rate will stall until the process is switched back to run.

Hugh,

I wrote a small 32-bit console app to do exactly that.

http://www.chiefdelphi.com/media/papers/2595

It toggles the RTS pin of the COM1 (RS232) serial port at 50Hz 75% duty cycle.

With a digital storage oscilloscope, you can see how Windows affects the signal.

For those without an oscilloscope who just want to play with it for fun, there's also a 1Hz version; with a cheap analog voltmeter you can see the RTS changing.

Have fun.

[Greg McKaskle]

Since I don't happen to have a scope, or a PC with a serial port for that matter, does anyone have a screen to share, or a description of the effect?

Greg McKaskle

[Ether]

Originally Posted by Greg McKaskle

Since I don't happen to have a scope, or a PC with a serial port for that matter, does anyone have a screen to share, or a description of the effect?

Started new thread here:

http://www.chiefdelphi.com/forums/sh...ad.php?t=98607