LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Problem using Dynamixel Pro with LabVIEW RT 14

Has anyone gotten Dynamixel Pro servo motors that use Protocol 2 to work with Labview RT?

 

Thanks in advance!

-Dan

0 Kudos
Message 1 of 6
(2,624 Views)

I can't see why not, Looking here the communications is a simple RS-232 protocol Albeit with some funky bit stuffing (replacing 0b 1111 1111 1111 1111 1111 1100 with 0b 1111 1111 1111 1111 1111 1100 1111 1100) and a strange header (0b 1111 1111 1111 1111 1111 1100 0000 0000)

 

A VISA session should work


"Should be" isn't "Is" -Jay
0 Kudos
Message 2 of 6
(2,585 Views)

I have been using the Protocol 1 library as a template to build the P2 vi's, but I am having a little bit of trouble with the funky byte stuffing.  I was able to get the correct CRC values from the CRC code provided by Robotis, but am not totally sure how to implement the byte stuffing.

 

Thanks!

0 Kudos
Message 3 of 6
(2,568 Views)

After converting the length and data to string just do a search and replace on "FFFFFFFD" with "FFFFFFFDFD" (Calculate the crc after stuffing)  I know, that means you need to gyrate U8[] to String to U8[] to String but, that's how they implemented the darned thing. (I said it was funky)  .And, of course, you need to "Unstuff" the received data just the opposite.

 

 


"Should be" isn't "Is" -Jay
0 Kudos
Message 4 of 6
(2,559 Views)

I understand that the directions state to calculate the CRC with the stuffing applied, but I was calculating the correct CRC value sans stuffing (based on CRC values for examples given in the manual) .  Which begs the question, are the directions correct or was that just a really cool coincidence?

0 Kudos
Message 5 of 6
(2,556 Views)

@Ddrizzle wrote:

I understand that the directions state to calculate the CRC with the stuffing applied, but I was calculating the correct CRC value sans stuffing (based on CRC values for examples given in the manual) .  Which begs the question, are the directions correct or was that just a really cool coincidence?


Probably a cool coincidence with a normal packet that didn't require any stuffing


"Should be" isn't "Is" -Jay
0 Kudos
Message 6 of 6
(2,550 Views)