[rlrhett]

I have been using the UC100 dongle for a while with a laptop and Mach3. The laptop is suffering, so I recently bought a new desktop computer to dedicate to the shop. It's an old Dell Optiplex 775. A workhorse, sturdy, business class machine.

I also decided to upgrade to UCCNC based entirely on Andy Birko's rave reviews.

The problem I'm having is that when I unplug the USB cable from the laptop and plug it into the desktop, EVEN IF THE DESKTOP IS TURNED OFF AND UNPLUGGED, my motors start jumping and stuttering all on their own. Plug the thing back into my laptop, no problem. I note that when the UC100 is completely unplugged from any computer the motors stutter and move on their own as well, just not as much.

Any ideas of what might be going on? I emailed the manufacturer and they were ZERO help. Wouldn't even entertain the idea of helping me troubleshoot. Took the attitude that the problem must be the computer and he didn't want to be bothered. Anyone considering this system should keep that in mind.

Anyhow, I don't know what to do to try to fix this problem.

Other than my UC100, my system is super basic: A 48V power supply from Keling, C10 BOB, three Gecko 251X connected, and three stepper motors also from Keling.

Thanks.

[samco]

not using the uc100 - my WAG is you have a ground loop issue. You didn't see it with the laptop because it is most likely isolated from the mains.

sam

[rlrhett]

not using the uc100 - my WAG is you have a ground loop issue. You didn't see it with the laptop because it is most likely isolated from the mains.

sam

I suspect some kind of grounding issue as well. I have to note that the same system plugged into the same computer over the parallel port rather than USB functions perfectly. Don't know if that changes anything.

Assuming you are right, what can I do? Is there something I can add to the USB cable or connector to fix a grounding issue? I am assuming since connecting to the parallel port doesn't produce this problem then the C10 BOB is probably ground properly, but is there something I should check there?

[dubble]

I'm sharing our previous e-mail conversations with the OP who states we provided Zero help and states that I told him that I do not want to be bothered, non of these statements are true.
Instead I think I did try to help him and asked him a few things to check, but the OP did bother to even check what I have asked about, this way I'm simply unable to help unfortunately.
Everybody can judge based on this...

Copy of our conversation below (in a reverse order, the last is the first e-mail):

Since I do not know what is happening, I'm not really able to help you resolving it, I beleive the issue is outside of the UC100 and is something to do with the external components connected and/or the configuration which causes the external components to work erraticaly. But since I do not have even a basic oversight on the external components nor am I able to produce the mentioned issue nor do I know what signals causing the erratic behaviour of the external components I'm afraid that I will not be able to help you, because my knowledge is very limited on what is happening.

The only ways for me and to be able to start understanding what is going on is if you will check the blue LED when the erratic movement is happening and when the software is not running.
Also an oscilloscope of logic analyser print of the step pin of the erraticaly moving axis would be very helpful, because that could prove that the UC100 is sending the wrong signals, otherwise I'm absolutely not sure about that,
moreover I'm suspecting the breakout board, e.g. a bad powering sequence, missing grounding, floating signals etc.

--

2015.09.14. 17:16 keltezéssel, Randolph ******* írta:
> Thank you. That's interesting, but that doesn't really help. I will check the lights, but the real point is that the same setup connected to a laptop running Windows 7 works properly, but when I connect it to a desktop Windows 10 machine the motors start stuttering and moving on their own. I literally have the laptop sitting on top of the desktop tower and just switch the USB from one to the other.
>
> I won't make any further conjectures as to what is happening and limit myself to asking you how to fix it.
>
> Yours,
>
> Randolph *******
>
> On 9/14/15 12:03 AM, Balazs Klincsik wrote:
>> I don't think that the UC100 is sending any garbage signals.
>> Even if Windows would send any garbage data via the USB (we've never seen anything like this though), the communication is robust with CRC checking and packets errors handling,
>> this means that basicly it is impossible that an invalid data is being executed by the motion controller.
>>
>> And you can verify if any data is being transmitted via the USB port to the motion controller with checking the blue LED, that LED turns on for a short amount of time when data is flowing on the USB port to the motion controller.
>> So, I advice you to check if the blue LED goes on anytime when the mentioned problem occurs, especially check it when no software is loaded, because then the blue LED should be always off.
>> If it does not go on and you still have motion then you can be sure that the signals are not sent by the UC100.
>> However the best way to check it out is to check the signals with an oscilloscope or logic analyser directly on the UC100 output pins.
>>
>> --
>>
>>
>> 2015.09.14. 5:27 keltezéssel, Randolph ******* írta:
>>> Thank you. That fixed the install, but now I have a new problem:
>>>
>>> When I power up my machine (c10 breakout board with 3 Gecko 251x) the motors go crazy. Garbage signals. Doesn't matter if no software is running, Mach3 is running, or UCCNC is running.
>>>
>>> When exact same machine with exact same UC100 is connected to my Windows 7 laptop, everything works as it should.
>>>
>>> On 9/12/15 6:06 PM, Balazs Klincsik wrote:
>>>> If it is a fresh installation of Windows 10. then you need to enable/install the .NET framework 3.5.
>>>> The UCCNC requires .NET 2.0 and on Win10 the framework 3.5 should be installed, it contains both the 2.0 and 3.0 frameworks.
>>>> Fix: .NET Framework 3.5 is Missing From Windows 10
>>>>
>>>> --
>>>>

[rlrhett]

I am interested in solutions, not the manufacturer justifying himself. However, if he would like to use this forum to discuss what I consider poor service we can.

"Since I do not know what is happening, I'm not really able to help you resolving it." If you say you are not able to help, that means you are not offering to help. Don't think there is any mischaracterization there of your words.

"But since I do not have even a basic oversight on the external components nor am I able to produce the mentioned issue nor do I know what signals causing the erratic behaviour of the external components I'm afraid that I will not be able to help you." I provided you with a list of the external components: C10 BOB, Gecko 251x drivers. If you need more information, ask. Sounds to me like you are not interested in helping.

What might have been helpful? If you don't have enough information on my setup, how about asking? Need more that the c10 and Gecko 251x? Tell me, I'm not trying to hide anything. As far as I know those are the only external components, but you would know better.

Another helpful approach? Perhaps you acknowledge that the system works on a Windows 7 laptop and not on a Windows 10 desktop. Could there be something in that? What might that tell you? What might I do to trouble shoot. Maybe you suggest I do something other than buy a $500 oscilloscope I'm unlikely to know how to use to trouble shoot your $150 dongle.

Finally, rather than come on the site and take offense that I am looking for help elsewhere you may wish to actually offer some practical troubleshooting steps. After all, you are the hardware designer and manufacturer. Presumably you would know best what may be happening.

I'm still looking for a solution. Others can judge for themselves your "helpfulness".

[dubble]

Ground loop means that you have a connection to the mains ground from the PC in more than one points. As samco pointed out you do not see this on a laptop since it is not grounded, running from a battery/isolated charger.
The ground loop can be forexample if you have the computer grounded via the mains connector and you also connect the ground of the UC100 (same as the computer ground) to the mains ground.
This other point could be forexample a screw connected to the breakout board's grounding to a control box grounded to the mains grounding.
This dual grounding will be a loop and the potential difference on the 2 points will cause current to flow between the 2 grounding points, this can cause noise and interferences to appear on the computer and in the UC100.

[dubble]

I do not have an oversight of the components you using, I ment I do not know these devices, have not used them.
I have concentrated and sent you the same question 2 times to get closer to the cause of the issue, got no answer, I can still only get closer if I get an answer on at least the blue LED state when the software is not loaded and when you get the movements.
Also as said a scope measurement would be the best if you have a scope at hands, if not then just start with the blue led.

You must understand that without feedback, without answering my questions I'm running in open loop... and just like a stepper motor I can easily loose steps.

[ger21]

The problem I'm having is that when I unplug the USB cable from the laptop and plug it into the desktop, EVEN IF THE DESKTOP IS TURNED OFF AND UNPLUGGED, my motors start jumping and stuttering all on their own. Plug the thing back into my laptop, no problem. I note that when the UC100 is completely unplugged from any computer the motors stutter and move on their own as well, just not as much

Proper practice would be to not have your motors powered up when the PC is not on. You shouldn't be powering your motors until the control software is up and running. If you follow this practice, then you don't have any issue.

[dubble]

If the motors shatter if the desktop is turned off and unplugged then I it is clear and I have to say it is nothing to do with the UC100, but is a drive or more likely a breakoutboard problem, since an unpowered UC100 cannot cause any movements, it is then simply unpowered and is therefor electrically inactive, is unable to generate any signals ... I think your motors will still shutter if you unplug the UC100 and leave the other components on their own.
I take my bet on the breakout board, that it does have buffers on the step/dir lines but does not have any pullups or pulldowns on them, the inputs are floating, so if you will even touch an input pin on the BOB with your fingers will cause the motors to shutter...
You should change that BOB or enable the pullups or pulldowns if it is possible, because this is a safety risk and could cause the machine to move unexpectadly and could cause injuries!
Or if the BOB/drive has a charge pump circuit and that has a pullup or pulldown resistor then you can enable that to make the system safe.

[daniellyall]

for a start you turn computer on, then turn on the machine power. if when you are finished you unplug the uccnc then just turn the computer off and things happen then in no way could the uccnc make anything happen. or if you just turn the computer off then thing`s happen the problem is else where.

ground loop can make that happen as power is dissipating or noise in the machine and you should not just pull the controller there is a proper and safe way to shut the machine down or you will get magic smoke.

all this is simple bask machine safety and yer ger21 know`s what he is talking about it`s a practise I do and have zero problems. and you have servo what are noise to start with

[rlrhett]

It's a problem with the firmware.

I loaded Mach3 onto the desktop and imported my XML file. When I launched Mach3 it told me that the UC100 had the wrong firmware and did I want to replace it. I clicked "Yes". Powered up my motors and they functioned just fine.

Happy, I closed Mach3 and launched UCCNC. I got a message that it was updating the firmware of my UC100. As soon as it started, the motors started going haywire.

Went back to Mach3 and again had it replace the firmware. Again the problem was solved.

It appears that the UCCNC software is forcing and update of the firmware that is either corrupted or does not work properly.

I would like to use the UCCNC software. Does this new bit of information help solve the problem? Is there a way I can prevent the UCCNC from changing the firmware on the UC100 dongle?

[dubble]

The UCCNC and Mach3 for the UC100 runs different firmwares, because they work totally different, even the basics are different, and they need different firmware codes to work and therefor if you ran the UCCNC and after Mach3 will replace the firmware and vica versa.
The firmware version detection and replacement of the firmware goes automaticly and only when nessessary.
If you will always run Mach3 with always the same plugin version then the firmware will not be changed and if you will run the UCCNC then again the firmware will not be changed,
but as soon as you switching between them the firmware will be changed, because it has to be changed.

And with broken firmware the UC100 will not run, the firmware is CRC error checked (both in the plugin of Mach3 and in the UCCNC) on every connection to the software and if there is even a bit error in the firmware then it will not run but will replace the firmware first.

I do not think the problem has anything to do with the UC100 or Mach3 or the UCCNC, try to unplug the UC100 with the new firmware and your motors will still shutter, it is a matter of the buffered signals and floating on your BOB, from what you typed down here in the 1st post in this forum thread makes me think this and I'm pretty sure that this will be the problem. Also you can try to unplug the UC100 from your BOB and touch some input pins with your fingers and the motors will move... and I have already typed down the possible solutions for you in a previous reply.

[rlrhett]

Sorry, but if I unplug the BOB from the UC100 it does not stutter. Nor does it stutter when I touch the input pin. Additionally, if I plug the BOB directly into the parallel port and bypass the UC100 it is solid as a rock.

I was also wrong about it stuttering when the computer was turned off. It stutters and jolts so badly I only have a few seconds to test before it threatens to crash into a limit. I must have been pulling the monitor's power cable thinking I had unplugged the computer. In any case, I have not been able to recreate the problem with the computer off and unplugged. I also want to correct the impression that it only stutters when the computer is turned off. I would never normally turn on the motors with the computer off. I was trying to test the theory that it was a ground loop by disconnecting the computer's ground. The stuttering and jolting happens with the computer ON.

The ONLY time it stutters is when it is connected to the UC100, and then only if the UCCNC has changed the firmware. With the Mach3 firmware it did not stutter and seemed to work properly. I didn't do any actual cuts, but the stuttering didn't happen and I was able to jog the spindle from the keyboard. As soon as I loaded UCCNC and the firmware updated the stuttering began again. I could quit UCCNC and even restart the computer, and the stuttering would be there. Again, the jumping is so bad I can only turn on the power for a few seconds at a time. I can't test to see what would happen if I change states on the computer, e.g. quit UCCNC while it's still on or shut the computer down while it is still on. Regardless, turning the motors off, launching Mach3, allowing it to restore the firmware, and then turning the motors back on seems to reliably fix the problem.


This is a C10 BOB. The same one made by your exclusive US distributor cnc4pc.com. All the inputs have a pull down resistor and all outputs are buffered. I have a very standard configuration on the C10. The x,y,z axis are on output pins 2/3, 4/5, and 6/7. The common is set to ground. I have limit switches on pins 11 and 12 and e-stop on pin 10.

I should also add that I had been using this CNC machine, configured exactly the same way, with this exact UC100, on a laptop running Windows 7 and Mach3, reliably for the last two years. The only reason I switched to this Windows 10 desktop is that the dust was causing the laptop's fan to get stuck and it was overheating causing shutdowns mid-run. I am willing to consider that there is something weird about this computers USB hub, but the fact that it seems to work with Mach3 points to a problem with the UCCNC and its firmware.

To answer the original question, there are no blue lights on the UC100 unless either UCCNC or Mach3 are running.

I could continue to use Mach3 and return the UCCNC to cnc4pc.com, but I keep hearing such good things about it. I really hate to give up on it. I have done everything I can think to isolate the problem. The actual repeatable circumstances of failure are:

1) UCCNC loaded firmware
2) Windows 10
3) Desktop computer with standard power supply

The actual repeatable circumstances for success are:

1) Mach3 loaded firmware
-or-
2) Laptop computer
3) Windows 7

If there is a problem with the BOB, it is not inherent in it or its configuration. The BOB doesn't change when going from success to failure and back again. Perhaps there is something wrong with the way the BOB interacts with the UC100, on a Desktop, using Windows 10, and/or using the UCCNC firmware. But the problem has to be originating outside the BOB.

Does this give anyone any ideas about what is happening or how to further trouble shoot?

[daniellyall]

do you have a common/earth wire running from the computer to the C10, where is the C10 getting it`s power from, is the power to the machine sunk to earth.
do you have one ended shielding wire on the machine.

it still is pointing to something else if it`s fine from the pp cable but goes funny with the USB cable, they are a different set up. do you have the enable pin connected on the C10.

changing from M3 with UCCNC plugin to, UCCNC will change the firm wear different program`s that`s a given.

pulling anything under power is a bit silly do it properly or you may kill the machine or your self.

you say USB hub is it a HUB or straight from the computer.

one of the things above can make your problem happen and one you should not do

[rlrhett]

do you have a common/earth wire running from the computer to the C10, where is the C10 getting it`s power from, is the power to the machine sunk to earth.
do you have one ended shielding wire on the machine.

it still is pointing to something else if it`s fine from the pp cable but goes funny with the USB cable, they are a different set up. do you have the enable pin connected on the C10.

changing from M3 with UCCNC plugin to, UCCNC will change the firm wear different program`s that`s a given.

pulling anything under power is a bit silly do it properly or you may kill the machine or your self.

you say USB hub is it a HUB or straight from the computer.

one of the things above can make your problem happen and one you should not do

The C10 does not draw power from the computer. It draws power from a 5vdc power adapter plugged into the wall (same circuit as the computer, but tried separate circuits and that did not fix the problem). No separate ground, just the + lead connected to the 5V terminal and the - lead connected to the GND terminal from the power adapter. Yes the enable pin is hard wired to the power adapter +. I believe nothing connected to the GND terminal next to the EN terminal, but I can look at it now. Will confirm in the morning.

By USB hub, I mean the built-in hub of the computer's motherboard.

[dubble]

I was also wrong about it stuttering when the computer was turned off. It stutters and jolts so badly I only have a few seconds to test before it threatens to crash into a limit. I must have been pulling the monitor's power cable thinking I had unplugged the computer. In any case, I have not been able to recreate the problem with the computer off and unplugged. I also want to correct the impression that it only stutters when the computer is turned off. I would never normally turn on the motors with the computer off. I was trying to test the theory that it was a ground loop by disconnecting the computer's ground. The stuttering and jolting happens with the computer ON.

OK, so the key information was incorrect, then we can drop the previous conclusion into the garbage bin.

The ONLY time it stutters is when it is connected to the UC100, and then only if the UCCNC has changed the firmware. With the Mach3 firmware it did not stutter and seemed to work properly. I didn't do any actual cuts, but the stuttering didn't happen and I was able to jog the spindle from the keyboard. As soon as I loaded UCCNC and the firmware updated the stuttering began again. I could quit UCCNC and even restart the computer, and the stuttering would be there. Again, the jumping is so bad I can only turn on the power for a few seconds at a time. I can't test to see what would happen if I change states on the computer, e.g. quit UCCNC while it's still on or shut the computer down while it is still on. Regardless, turning the motors off, launching Mach3, allowing it to restore the firmware, and then turning the motors back on seems to reliably fix the problem.

Based on the updated informations from you I think that you might have something configured uncorrectly in the UCCNC like a charge pump to a step signal or something like this, but again since you can't measure and can't check signals it is only a guess.

This is a C10 BOB. The same one made by your exclusive US distributor cnc4pc.com. All the inputs have a pull down resistor and all outputs are buffered. I have a very standard configuration on the C10. The x,y,z axis are on output pins 2/3, 4/5, and 6/7. The common is set to ground. I have limit switches on pins 11 and 12 and e-stop on pin 10.

I was talking about the input side of the output buffer ICs, if the input side of the output TTL buffers are floating will do random things when nothing is connected to the BOB because then the buffer input will be on an undefined voltage level (will read noise from the environment) and the output will give a solid 0/5V output with a random frequency as the input is just floating there, I came to this conclusion, because you gave me false description about the problem and I have used that false information to come to a conclusion which conclusion therefor can be also false.

I should also add that I had been using this CNC machine, configured exactly the same way, with this exact UC100, on a laptop running Windows 7 and Mach3, reliably for the last two years. The only reason I switched to this Windows 10 desktop is that the dust was causing the laptop's fan to get stuck and it was overheating causing shutdowns mid-run. I am willing to consider that there is something weird about this computers USB hub, but the fact that it seems to work with Mach3 points to a problem with the UCCNC and its firmware.

I should also add that I had been using this CNC machine, configured exactly the same way, with this exact UC100, on a laptop running Windows 7 and Mach3, reliably for the last two years. The only reason I switched to this Windows 10 desktop is that the dust was causing the laptop's fan to get stuck and it was overheating causing shutdowns mid-run. I am willing to consider that there is something weird about this computers USB hub, but the fact that it seems to work with Mach3 points to a problem with the UCCNC and its firmware.

A good test idea for you is to check what the UCCNC does when loading on the same Win7 PC and/or to check Mach3 loaded on the same Win10 PC.
Debugging something when you have a known "OK state" and a known "not OK state" should always with start from the working OK state with changing one thing at a time to reach the non working state. You making several changes like changing the computer and with that changing the OS too and changing the software the same time which is not a good debugging strategy and in most case can't lead to the correct answer, only to missunderstandings about the problem.

If there is a problem with the BOB, it is not inherent in it or its configuration. The BOB doesn't change when going from success to failure and back again. Perhaps there is something wrong with the way the BOB interacts with the UC100, on a Desktop, using Windows 10, and/or using the UCCNC firmware. But the problem has to be originating outside the BOB.

Yes, I agree that it is not sure that the problem is with the BOB. The false information about the stuttering when the PC is off made me think that it is the BOB,
but as you telling now that it was a false information it is not at all sure it is the BOB.
I would not say that it is sure not the BOB, but now there is no information which could lead me to think it is.

Does this give anyone any ideas about what is happening or how to further trouble shoot?

Well, it's hard for me to get an idea, I'm confused about what informations are correct and what are not.
Also I do not know what signals are causing the movements, a simple scope measurement could show it, but we know now that you do not have one.

IMO (and please do not take this an offense like you did last time I mentioned a scope) having an oscilloscope or a logic analiser is something every hobbyist should have if building a CNC machine and dealing with electronics. Having a scope can make things several things easier, it is also a great tool for learning and understanding electronics. A basic oscilloscope required to measure low frequency signals like this does not cost $500, but likely you can get one in the $100 range ... a very basic PC based USB scope or mini android based hobby scope may be even the fraction of that $100 and you can still measure everything out using a cheap scope like that.

[rlrhett]

I suppose the first thing I will do is upgrade the laptop to Windows 10 to see if that is the source of the problem. Doubt it, but it is a first step. It will take a few days because I am waiting for the magic "notification" that I am allowed to upgrade. I'll report back once that is done.

I'll also consider an oscilloscope, but I'm not feeling like spending more money. Maybe the Windows 10 test will be determinative.

[daniellyall]

good man dubble, the off base question`s all ways help rlrhell check the bob wiring diagram and just check if you need a common to your common ground (common means ground, earth, negative VDC)

[rlrhett]

good man dubble, the off base question`s all ways help rlrhell check the bob wiring diagram and just check if you need a common to your common ground (common means ground, earth, negative VDC)

I'm still trying to solve this, but I'm not sure what you are saying. As far as I can tell, the wiring on the C10 is correct. As I've mentioned before it has worked fine for years. In any case, my version of C10 has terminals for 5V, GND, and EN. I have the positive lead of a 5vdc power supply to the 5V, the negative lead to the GND, and a jumper from the positive to the EN. Pretty sure this is straight from the wiring diagrams. Are you suggesting I should NOT connect the negative VDC to the GND terminal? I'm not sure what you mean by needing a "common to my common ground".

I really am trying everything I can think to solve this problem. If you have a suggestion on how the C10 should be wired to meet the needs of the UC100, please let me know.

Thanks!

[daniellyall]

I will have a look at the wiring diagram, it`s a weird problem it is more than likely is something simple. and no more doing dangerous stuff it won't help