• Content Count

  • Joined

  • Last visited

About BrianMoyer

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I am really new to using the Analog Discovery Studio for my courses but am very experienced with LabVIEW (certified developer).

    Is there a way to use the LabVIEW functions to implement control of a motor with a quadrature encoder providing feedback and with the motor needing PWM output to control speed?

    I saw the scripting examples for encoder measurements but that is way beyond my pay grade so any help with LabVIEW tools would be much more useful for me.

    Thank you!



  2. I have determined that the issues I was seeing were a result of poor PID control parameters and that the CAN Control message as documented is just fine. To anyone else attempting to directly control a DMC60C using CAN, know that having bad PID control parameters can lead to LEDs that flash valid (green or red depending on direction) briefly and then turn to solid yellow for a bit, repeat. This can cause occasionally violent stop-starts or just strange jerky motion. Another possible symptom is having the motor spin (using CL velocity control) but at an apparently constant rate (very fast) that is unresponsive to target setpoint changes.
  3. Hello, I am using a couple of DMC60C with an NI-XNET USB 8502. I have had some good luck but am running into a very specific question. The control message: 0x02060000 Uses a signed 24-bit integer for both closed loop velocity and closed loop position control setpoints. However, the makeup of that value is only loosely described in the documentation. My questions are: 1) is the byte order as shown in the manual correct? It appears strange to go trgtH in byte 3, targtL in bye 4, and trgtM in byte 5. I could understand H, M, L or L, M, H but it seems oddly shuffled as presented. 2) is a negative 24 bit value stored as 2's complement? Thank you for any advice. My motor does not appear to like the values I have been sending for velocity control mode. Sincerely, Brian
  4. 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