Jump to content
  • 0

DMC60C CAN response to vcmdGetDescriptors


BrianMoyer

Question

Hello,

THIS IS NOT RELATED TO TYPICAL FRC USE OF THE DMC60C.

I am using a CANable with Windows 10 to talk to a DMC60c with great success generally. I have been able to send and receive most commands and responses. However, the vcmdGetDescriptors command generates really, really fast sequential response packets (0x206FC80 messages). I have a more expensive CAN adapter from National Instruments that receives all of the responses (there are 8 packets for a total of 64 bytes by default) from the DMC60C and reports that they arrive at around 7180 Hz (compared to the normal status, encoder, and analog messages that are reported to arrive at 100, 10 and 10 Hz respectively). The CANable typically receives the status message and then 3 to 4 of the actual response packets but misses the others.

Here is an example of the typical data the CANable receives (the initial T characters comes from the CANable - I discard them):

T0206FCC0400004000
T0206FC8080106444D43363043
T0206FC8080208446967696C65
T0206FC808363043040830352F
T0206FC8083334414137324231

The status message (the first row) indicates that 64 (0x40) bytes were expected. However, only 32 bytes were received.

The 6 bytes for the device name string arrived in the first packet (the 2nd row) and were as expected "DMC60C".

The first 6 bytes (of 8 bytes indicated in the message) for the Manufacturer Name String came through in the next packet (row 3) - "Digile".

The next packet should have contained "nt", the number 3, the number of characters in the Product Name String message, and the first few characters of that string. However that package was never received.

Neither was the one after that which should have contained 8 more bytes of the Product Name String.

The next packet (row 4) instead contained the last 3 characters of the Product Name String - "60C", the number 4 (indicating the Manufacture Date String was starting), the length of that string (8 bytes), and the first 3 characters of the date string "05/" .

The next packet should have contained the rest of the date string and the beginning of the Hardware Version Number string but it was not received.

The last packet received (row 5) contained 8 bytes -"34AA72B1" - that might be part of the hardware version number or the serial number. It is hard to say which because the beginning of the Serial Number String message was never received either.

So, my question is: is there anything I can do to slow down the DMC60C's transmission of sequential packets of data to allow them to be received by the CANable OR is there some other setting I should use to make it possible for the CANable to work with the fast data stream?

The CANable is set to 1000000 baud rate and is connected via USB to my PC. I am using serial communication to talk to the CANable with the baud rate of the serial communication set to 115200. I have tried increasing the serial receive buffer size but with no luck. I have maximized the serial polling loop speed and have logged every character received from the port - I can not see where I am losing any real data - it is just that the CANable doesn't seem to be getting (and thus never sends it back to Windows) the data from the DMC60C.

Thank you for any advice!

Sincerely,

Brian

Link to comment
Share on other sites

1 answer to this question

Recommended Posts

Hi Brian,

Unfortunately there is no easy way to slow down the packets transmitted by the vcmdGetDescriptors command without changing the firmware. It sounds like this is more an issue with the CANable device. I don't think there is much we can do for you here.

 

-Tommy

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...