[kamocat]

Originally Posted by Radical Pi

You're right about the baud, both the black jag code and the cRIO driver init at 115,200.

I'm not sure how the LabVIEW code runs, but I see it a bit different in the C++ version. 3 messages are sent for each Jag getting an init. First is a firmware version request. 2nd, if in Voltage mode, is a message to enter voltage mode (for the other modes, that message is sent when telling the jag to enable PID). The 3rd message is telling the jag that the data line for speed is the encoder (the comment says that the jag requires it for all modes).

Normally, each message, either sending data or requesting data, uses 2 packets. On a sending command (such as setting the speed reference), the command is sent and then the jag replies with an ACK packet. On a requesting command (such as firmware version), the ACK packet is replaced with the reply, and no ACKs are sent. For some reason, the Voltage mode enabler (but not the speed, current, or position enablers. bug?) doesn't check for an ACK packet, so only one packet is used in the code, but according to the Jag firmware an ACK is still sent, so that should still count for 2 packets.

So, I count 6 packets traveling over the serial connection for each jag during init. All other commands use 2 packets , either a single set or a single get (except for setting PID values and configuring the position limits, which use 3 send messages each, so 6 packets each).

One slight correction to my earlier post about what goes over the serial. The arbitration field IS included in the serial packets. It holds the command for the jaguar as well as the device id as a 32-bit unsigned int. Here's my count for the size of the serial packet: 1 byte start of packet, 1 byte for size of packet, 4 bytes for message ID, and then 0 to 4 bytes of data, for a total of 6-10 bytes per packet.

ACK messages contain no data, so 6 bytes large. The original sent message could be 6-10 bytes still, so a single send message totals to 12-16 bytes.

Requests for data from the jag also carry no data, so those again are 6 bytes. Responses always carry at least one byte of data, so those total to 13-16 bytes.

Assuming worst-case scenario (16 bytes for each command), 900 messages can pass through at 115,200 baud, or a little less than 1 full command (send and receive) every millisecond.

At 1 command per millisecond, I doubt the data transfer itself is the bottleneck in your tests.

woah, that post got a bit out of control. Time for bed

Radical Pi, that's good to know.
The only thing about the messages that doesn't explain is how the limit switch settings are modified. I'll quote from Luminary Micro's Firmware Development Package User's Guide.

Forward Soft Limit Switch
This setting takes two values. The first is 16.16 signed fixed-point value that is the position of the forward soft limit switch. The second is an 8-bit value that specifies if the motor position must be greater than or less than the position of the forward soft limit switch. Greater than is encoded as 0
and less than is encoded as 1. Less than should be used if positive voltage results in the position increasing and greater than if positive voltage results in the position decreasing.
If this command is sent with no data, the motor controller will respond by sending this same message to report the position of the forward soft limit switch.

This has not changed in the FRC firmware.


Also, I'm sure the Black Jaguar driver is the same for all languages; we use the same .out file, don't we?



So, what's left to cause the commands to take so long?
Bogging down of the cRIO processor? (I don't think so; this is the only thing running on it)
Slow response time on the Jaguar? It has a 50 Mhz processor.

I don't know what the issue could be.

Is there anyone who has a robot available that can confirm my results? (I don't care if you use my code or create your own)
From another standpoint, it's remotely possible my code is at fault. I can test anyone's LabVIEW code for them. If you tell me how to deploy the compiled code over FTP, then I can test code written in C++ and Java as well. (If you didn't notice, I have lots of time)