Jrk21v3 + LACT4P-12V-20 - USB connection lost during runtime

Hello,

I am using the Jrk21v3 to drive a linear actuator, sending commands via serial input form a VBA-Programm, while using a power supply unit @~21V.
It occurs from time to time that the controller/motor wont react anymore and the green USB-LED turns off, the Plot window freezes and the Utility displays an error (see the end of this post).

The problem was reproducible with the VBA code and the Pololu Jrk Configuration Utility at various settings (USB Dual Port/Chained, Never Sleep on/off, PWM-freq 20/5kHz, different limits).
Sadly I could not figure out the cause of the error.
Can anyone help me out?

I hope I could provide enough information, let me know if not.
Thanks

See the end of this message for details on invoking 
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.Exception: There was an error turning off the motor. ---> System.ComponentModel.Win32Exception: Control transfer failed.
   at Pololu.WinusbHelper.WinUsbDevice.controlTransfer(WINUSB_SETUP_PACKET setupPacket, Byte* buffer)
   at Pololu.WinusbHelper.WinUsbDevice.controlTransfer(WINUSB_SETUP_PACKET setupPacket)
   at Pololu.UsbWrapper.UsbDevice.MyWinUsbDevice.controlTransfer(Byte RequestType, Byte Request, UInt16 Value, UInt16 Index)
   at Pololu.UsbWrapper.UsbDevice.controlTransfer(Byte RequestType, Byte Request, UInt16 Value, UInt16 Index)
   at Pololu.Jrk.Jrk.motorOff()
   --- End of inner exception stack trace ---
   at Pololu.Jrk.Jrk.motorOff()
   at Pololu.Jrk.MainWindow.setMotorState(Boolean motorOn)
   at Pololu.Jrk.MainWindow.motorOffButton_Click(Object sender, EventArgs e)
   at System.Windows.Forms.Control.OnClick(EventArgs e)
   at System.Windows.Forms.Button.OnClick(EventArgs e)
   at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ButtonBase.WndProc(Message& m)
   at System.Windows.Forms.Button.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3625 (GDR.050727-3600)
    CodeBase: file:///c:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
JrkConfigurationUtility
    Assembly Version: 1.2.1.0
    Win32 Version: 1.2.1.0
    CodeBase: file:///C:/Programme/Pololu/Jrk/bin/JrkConfigurationUtility.exe
----------------------------------------
System.Windows.Forms
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3623 (GDR.050727-3600)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3624 (GDR.050727-3600)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
Jrk
    Assembly Version: 1.1.0.0
    Win32 Version: 1.1.0.0
    CodeBase: file:///C:/Programme/Pololu/Jrk/bin/Jrk.DLL
----------------------------------------
UsbWrapper
    Assembly Version: 1.1.0.0
    Win32 Version: 1.1.0.0
    CodeBase: file:///C:/Programme/Pololu/Jrk/bin/UsbWrapper.DLL
----------------------------------------
Accessibility
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/Accessibility/2.0.0.0__b03f5f7f11d50a3a/Accessibility.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
    <system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

Hello, vaQlab.

I’m sorry you are having trouble with the jrk.

The next time the error happens, there is something I would like you to try that should give us more information: Please open up the Device Manager (run devmgmt.msc or find it in your Control Panel). Select View → Devices by Connection. Find the entry that says “Pololu Jrk 21v3 Motor Controller”. The screenshot below shows you where I found it on my computer, and your computer is probably similar. The parent device of that entry should be named “USB Composite Device”. Do you see these entries in the Device Manager? Does it look like the screenshot below? Close your VBA program, close the Jrk Configuration Utility, and close any other program that might be using the jrk. Right-click on that USB Composite Device and select “Disable” to disable it. The three devices under it should disappear. Then right-click on it and select “Enable” to re-enable it. Does this solve the problem? Does the jrk’s green LED come back on? Can you now control it from the jrk configuration utility?


I suspect that some of kind of electrical disturbance is reaching the PC and causing it to shut off its USB port. You might be able to avoid this problem by putting a powered USB hub between the jrk and the computer. Unfortunately, the jrk’s native USB interface, which you are using, probably does not work well with some hubs we have tried such as the D-LINK DUB-H7 and we’re not sure why, so that might be another problem to overcome.

–David

Hi,

I’ve just followed your steps through the Device Manager. At deactivating, it asks me for restart permission (which I denied), after that the device is marked with a red cross. Upon reactivating the device, the green status LED on the jrk turns back on :slight_smile:
The jrk config tool as well as Excel 2010 are now able to control the motor again.

@Cabling: Configuration was changed several times without improvement on the jrk problem. It’s the same behaviour on all three ports of the netbook that is used, and I’ve now installed a powered hub that doesn’t help either. Adjusting the motor parameters to have a smoother run (current maxes out at ~0.8A instead of ~2.5 amps while aggressively switching directions) looked good until Excel crashed a few minutes ago :unamused: However the power supply should be good enough in any case, providing 6A@20V and is checked to supply at least 17V in the worst case.

Any suggestions what to check next? Disable/Enable the controller once crashed works fine and can be done via the devcon utility from Microsoft*, but the VBA program is intended to run on a account without admin permissions. Moreover, disabling only works with Excel and the jrk tool closed, which isn’t quite easy to do via Excel VBA :mrgreen:

Thanks in advance! :smiley:
*:

devcon.exe disable USB\VID_1FFB*
USB\VID_1FFB&PID_0083\00015227                              : Disabled <-- composite device, "needs restart" while programs still access the jrk
USB\VID_1FFB&PID_0083&MI_00\6&3841C72D&0&0000               : Disabled <-- can be disabled while jrk config tool is running, it's the command port
USB\VID_1FFB&PID_0083&MI_02\6&3841C72D&0&0002               : Disabled <-- also no problem, TTL port
USB\VID_1FFB&PID_0083&MI_04\6&3841C72D&0&0004               : Disabled <-- "Motor Controller", needs restart when still accessed
4 device(s) disabled.

devcon.exe enable USB\VID_1FFB*
USB\VID_1FFB&PID_0083\00015227                              : Enabled
1 device(s) enabled. <-- just the composite device

devcon.exe enable USB\VID_1FFB*
USB\VID_1FFB&PID_0083\00015227                              : Enabled
USB\VID_1FFB&PID_0083&MI_00\6&3841C72D&0&0000               : Enabled
USB\VID_1FFB&PID_0083&MI_02\6&3841C72D&0&0002               : Enabled
USB\VID_1FFB&PID_0083&MI_04\6&3841C72D&0&0004               : Enabled
4 device(s) enabled.

Hi,
some additional information via a port monitor…just the very moment the controller got “lost”. After that, Excel tells me the port isn’t opened and it cannot be opened again until the USB connector is removed/reconnected or the device is deactivated/activated. (Is there anything wrong with the commands I sent?) This happened three times in a row within a few minutes, after constantly moving the motor around since my last post.

Writes:

Port opened: "EXCEL.EXE" (PID: 272)
 AA 0B A5                                          ª.¥             
Port closed

Port opened: "EXCEL.EXE" (PID: 272)
 AA 0B A5                                          ª.¥             
Port closed

Port opened: "EXCEL.EXE" (PID: 272)
 AA 0B A5                                          ª.¥             
Port closed

Port opened: "EXCEL.EXE" (PID: 272)
Port closed

Port opened: "EXCEL.EXE" (PID: 272)
Port closed

Port opened: "EXCEL.EXE" (PID: 272)
Port closed

Reads:

Port opened:"EXCEL.EXE" (PID: 272)
 3C 04                                             <.              
Port closed

Port opened:"EXCEL.EXE" (PID: 272)
 79 00                                             y.              
Port closed

Port opened:"EXCEL.EXE" (PID: 272)
 78 00                                             x.              
Port closed

Port opened:"EXCEL.EXE" (PID: 272)
Port closed

Port opened:"EXCEL.EXE" (PID: 272)
Port closed

Port opened:"EXCEL.EXE" (PID: 272)
Port closed

Hello. It’s good that you have devcon and a serial port monitor.

I think the Device Manager asked you to restart the computer because there was a handle open to one of the jrk’s devices when you tried to disable the jrk composite device. You should have better luck if you close the jrk configuration utility and Excel.

Your serial command is incorrect. I suggest just using the compact protocol, in which case the command for reading the Feedback Variable is just a single byte: 0xA5. You are using the Pololu protocol but forgot to clear the most-significant bit of the the command byte. That would cause a serial protocol error on the jrk, but it should NOT cause the problems you are seeing. Even if you send junk to the jrk’s COM ports it will never try to shut down its USB connection or anything like that.

It’s great that you were able to fix the problem by disabling and re-enabling the drivers. I think you only need to disable the composite device to get it working again, so could you try doing “devcon.exe disable USB\VID_1FFB*” next time? Those two operations might be equivalent, I’m not sure. But it’s just another thing to try that will give me more information about the problem.

This is probably a motor noise issue. To verify that, could you try unplugging one of the leads of the linear actuator motor (so it can’t move) and see if the problem still happens?

–David

Hi,
we’ve had some problems elsewhere, so I didn’t focus on the jrk problem until today. But it would be cool to finally solve this :wink:

I modified the Feedback code to just use 0xA5, which works fine. The jrk config tool indeed shows a growing rate of serial errors when using the old sequence, I hadn’t noticed that before (it maxed out at 1 - no idea why it did that). Right now the motor is running again some random sequence to provoke our main problem…

“devcon.exe disable USB\VID_1FFB*” wouldn’t work, because there is no device with that identifier. They differ after the sequence “USB\VID_1FFB&PID_0083”
-> * is the composite device
every other one:
-> &MI_00\6&3841C72D&0
&0000 is the command port,
&0002 is tty
&0004 is motor controller

However, as I said before, only the two ports can be disabled while e.g. Excel is running. In order to disable the composite device which also seems to affect all other devices, one has to shut down all software that somehow uses the jrk. That’s fine for testing, but no solution for the final version.

===
Sadly, another interruption has just occured. The jrk lasted for about half an hour…
And I am not able to make it work again by disabling or restarting one or more devices with devcon. :cry:

Disabling/Enabling just the 0004 device -> config tool pops up, “There was an error initializing the device. There was an error connecting to the device. No devices were detected.”
Disabling/Enabling all four devices -> two popups:
“There was an error getting the firmware version from the device. Control transfer failed. Error code 0x1f.”
+
“There was an error reading from the device. There was an error reading PARAMETER_INITIALIZED from the device. Control transfer failed. Error code 0x1f”

Restarting the devices only works for the motor controller and the TTY port; command port and composite require a system reboot. A bit strange because usually the ports can be modified while the controller/composite devices are fixed.

Here’s a dump of the last actions:

Port geöffnet durch Vorgang "Unbekannt" (PID: 3000) (note: port opened by Excel - perhaps listed as unknown because the logger was started after Excel)

Request: 24.01.2012 12:54:57.47664 (+0.5625 seconds)

 A5                                                ¥               

Answer: 24.01.2012 12:54:58.97664 (+0.5000 seconds)

 51 02                                             Q.              

Port geschlossen (note: port closed)

Port geöffnet durch Vorgang "Unbekannt" (PID: 3000)

Port geschlossen

Port geöffnet durch Vorgang "Unbekannt" (PID: 3000)

Request: 24.01.2012 12:54:58.55464 (+0.5781 seconds)

 A5                                                ¥               

Answer: 24.01.2012 12:54:59.07064 (+0.5156 seconds)

 51 02                                             Q.              

Port geschlossen

Port geöffnet durch Vorgang "Unbekannt" (PID: 3000)

Port geschlossen

Port geöffnet durch Vorgang "Unbekannt" (PID: 3000)

Request: 24.01.2012 12:54:59.13264 (+0.0625 seconds)

 AA 0B 60 1F                                       ª.`.            

Port geschlossen

Port geöffnet durch Vorgang "Unbekannt" (PID: 3000)

 A5                                                ¥               

Answer: 24.01.2012 12:55:00.16364 (+0.5000 seconds)

 9C 02                                             œ.              

Port geschlossen

Port geöffnet durch Vorgang "Unbekannt" (PID: 3000)

Port geschlossen

Port geöffnet durch Vorgang "Unbekannt" (PID: 3000)

Request: 24.01.2012 12:55:00.69564 (+0.5313 seconds)

 A5                                                ¥               

Answer: 24.01.2012 12:55:01.19564 (+0.5000 seconds)

 74 04                                             t.              

Port geschlossen

Port geöffnet durch Vorgang "Unbekannt" (PID: 3000)

Port geschlossen

Port geöffnet durch Vorgang "Unbekannt" (PID: 3000)

Request: 24.01.2012 12:55:01.75764 (+0.5625 seconds)

 A5                                                ¥               

Answer: 24.01.2012 12:55:02.25764 (+0.5000 seconds)

 E6 05                                             æ.              

Port geschlossen

Port geöffnet durch Vorgang "Unbekannt" (PID: 3000)

Port geschlossen

Port geöffnet durch Vorgang "Unbekannt" (PID: 3000)

Request: 24.01.2012 12:55:03.85164 (+0.5938 seconds)

 A5                                                ¥               

Answer: 24.01.2012 12:55:03.35164 (+0.5000 seconds)

 0F 06                                             ..              

Port geschlossen

Port geöffnet durch Vorgang "Unbekannt" (PID: 3000)

Port geschlossen

Port geöffnet durch Vorgang "Unbekannt" (PID: 3000)

Request: 24.01.2012 12:55:04.91364 (+0.5625 seconds)

 A5                                                ¥               

Answer: 24.01.2012 12:55:04.42964 (+0.5156 seconds)

 0F 06                                             ..              

Port geschlossen

Port geöffnet durch Vorgang "Unbekannt" (PID: 3000)

Port geschlossen

Port geöffnet durch Vorgang "Unbekannt" (PID: 3000)

Request: 24.01.2012 12:55:04.50764 (+0.0781 seconds)

 AA 0B 60 3B                                       ª.`;            

Port geschlossen

Port geöffnet durch Vorgang "Unbekannt" (PID: 3000)

 A5                                                ¥               

Answer: 24.01.2012 12:55:05.53864 (+0.5000 seconds)

 C8 05                                             È.              

Port geschlossen

Port geöffnet durch Vorgang "Unbekannt" (PID: 3000)

Port geschlossen

Port geöffnet durch Vorgang "Unbekannt" (PID: 3000)

Port geschlossen

Port geöffnet durch Vorgang "Unbekannt" (PID: 3000)

Port geschlossen

Port geöffnet durch Vorgang "Unbekannt" (PID: 3000)

Port geschlossen

Port geöffnet durch Vorgang "Unbekannt" (PID: 3000)

Port geschlossen

Port geöffnet durch Vorgang "Unbekannt" (PID: 3000)

Port geschlossen

Port geöffnet durch Vorgang "Unbekannt" (PID: 3000)

Port geschlossen

Port geöffnet durch Vorgang "Unbekannt" (PID: 3000)

Port geschlossen

Port geöffnet durch Vorgang "Unbekannt" (PID: 3000)

Port geschlossen

...

Starting a new run with motor V+ removed but GND and controller pins connected. :confused:

Oh, btw, what’s the maximum length of the wiring between the jrk and the motor? I don’t think that would lock up the controller, but…

There is no absolute maximum length of wire between the jrk and the motor but shorter wires permit more power to be delivered to the motors. How long are your wires?

Maybe motor noise is causing this problem. You could try putting a capacitor between the jrk’s A and B terminals and see if that helps.

–David

Hi,

the motor has about 50cm of cabling attached, and I’ve added two 30cm extension cords. They are intended for high-end graphic cards (8-pin power connector) and should easily do 150 watts of power. So the wiring is pretty thick, but there is no shielding, which might impair signal quality. Our problem however occured before inserting these extensions, it’s just more convenient for the jrk placement and also more secure to have coded and tight fitting connectors.

I’ve added a quite large capacitor between the A-B connectors and the power supply and did a few minutes of testing, but I think the system is now even more prone to failure. It’s a massive EPCOS 22000µF/40V that has 10mOhm ESR/100Hz and may take ripple currents up to 9.6A :smiley:
I’ll try a smaller one right between the A-B terminals next time, if you could suggest a capacity point?

I meant a capacitor more like 0.1 uF, but it probably won’t make that much of a difference.

The problem is more likely to be with your power supply. Could you provide more details about what it is? You said it provides “6A@20V and is checked to supply at least 17V in the worst case.” How did you check it? How long are the leads from the power supply to the jrk?

The actuators are designed to run at 12 V and they have a stall current of 10 A at that voltage. If you’re running them at 20 V, the stall current would be around 10*20/12 = 16.6 A. The actuator will briefly draw the stall current if you start it up immediately at full speed so that could cause problems. You might be able to get around this by using the jrk’s max duty cycle and max acceleration settings.

–David

Hi,

well, a blocking capacitor differs from a large supporting capacitor, so it might be worth a try.

Max. 6A @ 15/16/18/19/20V or 5A @ 22/24V is the specificated output. 17V was measured while switching motor directions, which should use the most power. Test was at full duty cycles. I know that there may be peaks that I’m unable to detect without an oscilloscope, but as described below, even a better power supply doesn’t work.

Cable length is 1.6m (power supply leads) + 0.2m (adapter) + 0.4m to the jrk.

Settings at the moment are:
Max duty cycle 350
Max acceleration 15
Brake duration 0
Max current 3.996
Current calibration 37

I just checked with another power supply (a regulated one, triple output), type EA-PS2316-050 which is capable of 32V @ 5A / 16V @ 10A. It never shows above 0.6 amps in regular use with the settings above. And, more important: I’m not able to move more than about 10 times until the jrk is lost. Same with lowered supply voltages of 15V and 12V with up to 1.2A as measured by the power supply itself. Seems like the jrk is built to work best with the cheapest chinese crap supplies :mrgreen:

I’m sorry you’re still having trouble even with a different power supply.

If you haven’t done it already, could you try unplugging one of the leads of the linear actuator motor (so it can’t move) and see if the problem still happens?

It’s interesting that your failure rate changed when you switched to a different power supply. I think this means that working on the power supply is a good idea. It sounds like the power supply voltage is dropping at least 3 V (from 20 V to 17 V) while switching directions. I think this is the root of your problem, and there are two things you can try to reduce it:

  • You could try adding capacitance between the jrk’s GND and VIN lines. A few hundred µF would probably be OK, but since you have a 22000µF capacitor you might as well put it there and see if it helps. It should be mounted close to the jrk.
  • Try using the brake duration parameter. If you set it to a value that is large enough, it would prevent the jrk from driving the motor while the motor is moving in the opposite direction. I would set it to something big like 1000 ms at first to see if that helps, but you’ll probably want to try reducing it later so you can get better control of the motion.

It sounds like the cables between the power supply and the jrk are only 0.4m, which should be ok.

You said your max acceleration is 15, but what is the PID period?

–David

Hi,

yes, sorry, I forgot to tell you. The jrk ran overnight without problems when the motor was powered off. Maybe I should do another run in order to make sure this is reproducible and not just by coincidence.

I found that interesting, too. However, voltage doesn’t drop by 3V, as in regular use I do not switch directions that fast. In fact, the motor is at rest most of the time. It is mounted upside down and should carry some measuring equipment (tiny and light). Upon request, the motor starts and moves down to a specific, ever-the-same target point, stays there for about 15 seconds, and moves back. It then pauses for about half an hour. That’s it.

PID settings are:
Proportional coefficient = 6/2² = 1.5
Integral coefficient = 0.125
Derivative coefficient = 0.5
PID period 25 ms
Integral limit 500
Feedback dead zone 2
Reset integral -> off
At lower voltages this is quite slow (although that doesn’t matter in my application), but with ~20V it is reasonable fast.

Disconnecting the capacitor and switching back to the old power supply, the performance is now worse than ever before. I can hardly do any movements at all. My Excel test program was able to do three moves, and after reconnecting and using the jrk config tool, connection got lost after setting one single target in auto set target mode…without motor attached, it worked fine for the last ten minutes.
I think the jrk is about to die and I’ll return it. Hopefully the replacement will work as intended.
Thank you very very much for your patience and support :smiley: CU soon…

Thanks for reporting the results with the actuator disabled.

With a PID period of 25ms and acceleration of 15, it should take about 600/15*25 = 1000 ms for the jrk to accelerate from rest to full speed, so that sounds good.

I’m sorry you are still having trouble. The two suggestions I made in my last post still stand (adding capacitance between GND and VIN near the jrk, and using the brake duration parameter). Let us know if your jrk does die, and please be sure to ask us before returning anything.

–David

Hello from RAL Space Robotics. The jrks are great! we used them in many robots but now that we moved USB control we are experiencing a similar (to the one described above) issue with the jrk 12v12. We are using 6 jrk 12V12 to control drive motors of a robot. The power to the motors are from some LiFe batteries, the usb line is connected to an industrial grade (surge protected) powered USB hub and the hub is connected to a low power ARM single board computer (Beagleboard). We are running Ubuntu Linux and a custom python script dealing with the USB control of the jrks.

During operation randomly a jrk drops out, and the serial line is disconnected and we are unable to reconnect to it unless we power the jrk off and back on…

Just to note our PID and acceleration settings are set up so the motor reaches 0-100% power in 1 seconds and we were logging the current which never reached the current limit of the jrk.

We haven’t experienced the issue with the motors disconnected but I will do more test on this on Monday.

We will also try adding the capacitors as you suggested and report back.

Hi
I work with Kisdia above.
we have all of the pololus going into the hub.
the usb lead from the hub to the Beagleboard has no ground or power lines. this has stopped the previous issue of the beagleboard being shut down by the noise.
could the noise be causing the 5 Volt from the mini usb to be disrupted?
how is this power generated on the pololu?
Thanks
Wayne

Hello, Wayne and Kisdia.

I’m sorry you are having trouble with the USB connection to the jrk.

Could you give me more details about the error you are having? Do you see any messages about it in “dmesg”? What happens to the jrk’s two virtual COM ports? What are the jrk’s LEDs doing during the error?

Could you give me more information on your LiFe batteries and drive motors? Links to product web pages would be great.

Really? Standard USB cables have ground and power lines. Where did this modified cable come from?

All the grounds are all connected together, including the ground on the USB connector and the GND going to your battery. When both USBand VIN power are present, as they are in your system, the VIN supply powers the motors and a 5 V linear regulator. There is a simple circuit to choose between the on-board regulated voltage and the USB voltage, with the regulator power taking precedence. The ~5 V output of that circuit powers the microcontroller.

–David

Hi David

As we are driving the robot sometimes one of the pololus will stop responding to commands and continue with the last command given.
In linux the COM ports are visible. Sometimes we can reconnect straight away. Othertimes we cannot connect to the COM Ports. The serial port is blocked. In this case we need to hard reboot the pololus.
if we can connect the green LED is on if not it is off.

we are using two sets of 4 LiFe cells in series to give 14.8V Nominal.
the motors are standard DC Brushed motors with a gear box.
the control side of the robot (including USB hub) is powered by one set of batteries and the motors are driven from the other.

The USB cable was modified by me as only Data was needed and previously the the beagleboard was crashing from this noise.

i was wondering is something similar from the hub to the pololus would work?

Thanks
Wayne

Hi David,

Thanks for the quick reply, your help is much apprechiated. We think it might be a noise issue, so we are putting some 0.1uF capacitors accross the motors. Do you think it is worth putting some accorss the input lines?

Many Thanks,

Aron

When the jrk turns off its green LED, it’s because it’s not getting any power from the USB port and/or it’s not detecting any packets on the USB port. We’ve seen this sort of thing a few times before and I think it happens because some sort of noise is getting to the USB port and causing it to turn off, perhaps as a method of protecting itself.

Putting capacitors on the motor is a good idea, as described here:
pololu.com/docs/0J15/9

It would also be good to put a couple hundred microfarads of a capacitance between the jrk’s GND and VIN lines. Let me know if that helps!

Do you have an oscilloscope for monitoring the power lines?

Does your system have the “dmesg” utility? Do you see any messages about the problem when you run “dmesg” at the command line?

I’m kind of surprised that your modified USB cable is working without a GND line. I’m not sure if the same thing would work between the jrk and the hub. At the very least, if you’re going to make it work you would have to feed some 5 V power source into the jrk’s USB port so that it detects USB power and starts up its USB circuitry.

–David

Hi David,

We added the capacitors both on the motors and at the in line of the jrk 0.1uF in both case.
Also we think we experience less dropouts, but they still occur. We are experiencing diferent kinds of dropouts.

Our connection goes: 6 x motors* => 6 x jrk => industrial grade powered surge protected USB hub => single board computer, the disconnected usb line is between the single board computer and the hub and both the hub and the computer are provered from a smaller “clean” battery while the jrk and the motors are powered by the main battery.

I cases below it was only one pololu which dropped out. (not nescessarily the same one so it doesn’t seem to be a faulty board)

  1. mode one
    We don’t see the green LED turning off anymore (it is possible that they only turn off for a very short time when the dropout occurs), but in one failure mode the green LED starts flashing.
[2063.112335] tty_port_close_start: tty->count 1 port count = 0.

In this case I can’t reconnect to the jrk. I need to reboot the computer or the pololu.

  1. mode two, we believe this might be due to the hub
    In this case I can reconnect right away.
    Here is the printout from dmesg:
[157.202087] hub 1-2.5:1.0: port 6 disabled by hub (EMI?), re-enabling...
[157.227386] usb 1-2.5.6: USB disconnected, device number 10
[157.486206] usb 1-2.5.6: new full-speed USB device number 12 using ehci-omap
[157.610412] usb 1-2.5.6: New USB device found, idVendor=1ffb, idProduct=0085
  1. mode three, similar to mode 2 but doesn’t seem to effect the hub
[988.693847] usb 1-2.5.1: USB disconnected, device number 6

again I can reconnect right away after the error

*http://docs-europe.electrocomponents.com/webdocs/0bf3/0900766b80bf315e.pdf