I have a project that requires two JRKs. I prefer these two JRKs to be daisy chained, so the project can be controlled through one USB cable. Also, I would prefer native USB, since virtual COM ports are harder to configure for the user and do not recover from failures gracefully.
I found out that the native USB interface does not support device id’s, so this interface probably only talks to the JRK connected to the USB. Is that true?
If I have to use the virtual COM port, is there a way to use Jrk.getConnectedDevices() to retrieve a devicelist and then somehow acquire the associated virtual COM port of the device?
Would it be possible for the native USB interface to inject Pololu protocol commands on the input wire, so I use the native interface but still have full support of the pololu multi-device protocol?
To control multiple jrks (from a USB connection) that are daisy-chained together, you would need to use a virtual COM port. With the jrks set up and configured correctly, any serial commands you send through the virtual COM port to the first jrk should get echoed to the second jrk through the TX and RX serial pins. There is no command that returns the COM port that the jrk is connected to, but the COM port can be configured in the Device Manager, and because the jrks have serial numbers, the same jrk will always be assigned the same COM ports. To answer your last question: no, the native USB interface cannot accept Pololu protocol commands.
In this case I think it’s best for me to use multiple USB connections. The benefits of native USB are too great to move back to virtual COM ports. I hope that in the future native USB with multiple JRKs will be made possible. I believe this could be achieved quite easily through a firmware upgrade and a new native USB command like transmitSerial(byte[] data), which would inject the bytes into the input buffer like it was received from the virtual COM port. It could then process the bytes and based on the configuration of the board pass it on to the TX line.
The reason I’m choosing native USB over the virtual COM port is that detection of the devices is much easier, so configuration by the end user is less prone to errors. Also a virtual COM port cannot be hot plugged reliably.
If you are using Linux or Mac OS X, you might consider using libusb to talk to the jrk’s virtual COM ports. This should give you a lot of the benefits of native USB. You would need to use lsusb to examine the jrk’s descriptors and figure out what endpoint to send and receive data on.
Someone on our forum has already done this for the Maestro Servo Controller, which has a very similar USB interface. The code is here:
Unfortunately I’m stuck on Windows and I’m using C#. The CLR SerialPort class has some internal problems that may cause uncatchable exceptions when the port disappears during use, so I’m not a fan of virtual COM ports.
