X-Controller disconnections with PC part way through the job

Oops sorry, didn’t see Phil’s response…

@PhilJohnson @Nathan2,

Thanks for all your input so far. I went down a different rabbit trail last evening trying to ensure that my rig was static free. This entailed trying to ground off my X-Carve frame (pretty hard to do with the black rails as the paint/coating seems to be electrically insulating) and adding a drain wire to my shopvac hose. While I did get a chance to cut longer, it still petered out on me. So, I don’t know if I cut longer because of what I did, or just pure chance as there doesn’t seem to be a rhyme or reason otherwise.

That said, I don’t have time tonight for trying anything and I need to get ahold of Inventables to see the best way of using UGS with the X-Controller. You see, what I am cutting from is from Cut2D and is already g-code, but the Easel pre-processor for Cut2D (and any other 3rd Party CAM programs) eliminates some g-code from being generated (preamble and postambles) because Easel generates that on the fly… So, I now have to track down the correct pre-processor for the X-Controller not using Easel…

@PhilJohnson. Just got off the phone with Inventables about the log file I sent up after one of the failures. John said I should be able to use the Easel post processor with USG, but I will definitely take a look at yours and compare it.

They also recommended that I re-flash my X-Controller and have seen trouble with folks using 6ft or longer USB cables, because of my workshop layout (half of the garage…), mine is 10ft. If that turns out to be the problem, I will have to rethink my setup as my open garage door faces the street and I wanted the PC to be out-of-sight, out-of-mind to passer-bys. It’s an old computer, and not worth much, but someone wouldn’t know that until they took it. I’m getting an Intel Compute Stick as part of an IoT Virtual Bootcamp. I will probably use it for this when I’m done with the boot camp.

@RobertCanning. Yes, I have looked at using $H and yes, it does indeed home and unlock my machine. I just haven’t had the time to try my g-code with USG yet. That’s on the plate for tomorrow evening.

And yes, actually, Inventables was very helpful when I asked what post processor to use for USG.

@PhilJohnson, regarding soft limits isn’t that for saying if the machine motion goes beyond X or Y (perhaps Z), then assume that you can’t have gone that far and trip a limit? If that’s the case, then I don’t think that is the issue as I would expect it to fail at the same X-Y location (or close to it). I have had it fail close to 0,0.

Oh, and Inventables looked at my logs that were sent up to them and they are seeing a message indicating that the X-Controller has disconnected from the PC (reset itself?).

And as far as “magical fairy gremlins”, nope, don’t believe in them, never said I did… There is some logical reason this is happening, just haven’t figured it out yet. My assumption (perhaps faulty) is that it is RF/EMI/Static Electricity related.

I will get you guys the GRBL config info you asked about.

Thanks

@RobertCanning, That’s cool, but, please make sure you post your pics of those gremlins next time. :grin:

1 Like

@RobertCanning @PhilJohnson Here are my settings…
$0=10 (step pulse, usec)
$1=255 (step idle delay, msec)
$2=0 (step port invert mask:00000000)
$3=3 (dir port invert mask:00000011)
$4=0 (step enable invert, bool)
$5=0 (limit pins invert, bool)
$6=0 (probe pin invert, bool)
$10=115 (status report mask:01110011)
$11=0.020 (junction deviation, mm)
$12=0.002 (arc tolerance, mm)
$13=0 (report inches, bool)
$20=0 (soft limits, bool)
$21=0 (hard limits, bool)
$22=1 (homing cycle, bool)
$23=3 (homing dir invert mask:00000011)
$24=25.000 (homing feed, mm/min)
$25=750.000 (homing seek, mm/min)
$26=250 (homing debounce, msec)
$27=1.000 (homing pull-off, mm)
$30=1. (rpm max)
$31=0. (rpm min)
$100=39.980 (x, step/mm)
$101=39.867 (y, step/mm)
$102=188.976 (z, step/mm)
$110=8000.000 (x max rate, mm/min)
$111=8000.000 (y max rate, mm/min)
$112=500.000 (z max rate, mm/min)
$120=500.000 (x accel, mm/sec^2)
$121=500.000 (y accel, mm/sec^2)
$122=50.000 (z accel, mm/sec^2)
$130=790.000 (x max travel, mm)
$131=790.000 (y max travel, mm)
$132=100.000 (z max travel, mm)

@PhilJohnson, @RobertCanning, & @Nathan2. I have to say that I have not tried USG yet… that said, I did contact Inventables to get their take on my issue and they suggested three things.

  1. Reflash the X-Controller. Didn’t make a difference.
  2. Try as short of a USB cable as I can. (I used a 3 foot one for this test). Didn’t make a difference.
  3. Take the faceplate off of the X-Controller and unplug the faceplate’s USB connector and directly attach the computer to the controller board. This worked! I had a complete and flawless job run!!!

I will now get back to Inventables and determine what happens next as I would rather not use my X-Controller faceless if possible. It sounds like there is something hinky with that faceplate USB connector, or the cable from that connector to the controller board.

Thank you for all of your time and patience with this. I will post more later when I hear back from Inventables on hopefully a permanent solution.

Jim

1 Like

Interesting…been having similar problems and have tried every upgrade and work around that I have read about here on the forums, it has been much less of a problem, but this makes sense. I swear I bumped the USB cable on the front of the X-Controller and it effected it’s connection status as well. What type of USB connection is used on the controller board itself after bypassing the front faceplate? Been since November since I put it together. Following…

It’s a USB mini B connector.

1 Like

Hi everyone,

I think I might have the answer, and since I am getting a little older, I have begun practicing the time honored tradition of giving long-winded explanations for everything instead of getting right to the point. So brace yourselves:

I used to have the exact same problem and went through many of the same aforementioned steps to troubleshoot it, Sometimes, I could go a few hours without issues, other times it would disconnect in just a few minutes. I tried different computers, different USB cables, different ports, upgrading Easel… all sorts of things; but just when I thought I had it figured out, it would happen again. I even ended up writing a piece of software which would analyze and visualize the GCode and allow me to easily regenerate new GCode to pick up and start where the carve failed.

It did not seem to be a computer/usb/software issue… So at one point, I thought that it might be power surges, because there were a few times that I had turned on another powertool in my shop, and at that moment, my XController disconnected.

I experimented with this, and was able to occasionally reproduce the problem without having to run a carve, simply by going into the ‘Carve’ menu (in Easel) where you can home the machine. On several occasions, I was able to force a disconnect just by inducing a surge… but I had noticed that this was ONLY a problem when I had the DW611 running. If the router was not running, it did not seem to be an issue.

So… I purchased a semi-expensive power conditioner to get rid of any surges.

That did not work.

Then, I tried running my X-Controller and the router (DW611) on two completely separate circuits and kept both of them quiet (I didn’t run any other tools). Expecting this to solve the problem, I was very disappointed that I still had the issue.

BUT, this experiment lead me to believe that the problem was on the other-side of the X-Controller. Namely, my wiring from the XCarve to the XController.

When I built my machine, I used Velcro strips to lay my DW611 power cord along the top of the drag-chain - for both the gantry, and the return to the XController. The length to the router’s cord only got me part-way to the XController, so I got a heavy-duty grounded 4foot appliance extension cord and extended the length of the router cord so that it could follow the rest of the drag-chain and then past the XController to an outlet.

Now, in a previous life, I was into computer networking, and I had run into issues when un-shielded network cables were run too close to power lines. So I setup an experiment:

I removed the Velcro which was keeping the DW611 power attached to the drag-chain. I then made sure that there was at least a few inches separating the power from the cables in the drag-chain and started a 5-hour carve. No problems!. Then, I did several smaller hour to two-hour long carves. Again, no problems.

So then, I put my router and the XController all on the same circuit (but through the power conditioner) as my main power-runs for my other high-amp power tools and started a carve. I then tested again by running some high-amp tools, and there was no issue at all.

It’s been about a month now that I have not had any issues, and I have been using it fairly heavily.

So - here’s my theory on what the problem is: Since the XCarve is DC and the router is AC, I think that when the router itself would surge it would cause a momentary DC-pulse in the neighboring cables within the drag-chain. This pulse would then upset the GRBL board - which would then disconnect from the PC… OR maybe I’m just crazy and have just had a stretch of coincidental good luck!

Anyhow… I really liked having the power ride the drag-chain, as it ensured that there would be no snags when carving large-dimensioned pieces. So: I am going to try getting some extra shielding for my power cable, and also putting some ferrite-cores on my motor lines.

Anyhow - that’s my experience with this issue. Perhaps you can try a similar experiment and see if isolating the router power from the stepper-motor lines makes a difference.

Let me know if this helps anyone!

3 Likes

I had the same issue. I bypassed the panel mount USB connector and I never had another problem. Here is an old thread about it for those interested.

@DaveAndrews. Thanks for the info. Please let us know what kind of shielding and/or ferrite cores you find that works. I already tried a USB cable that had ferrite cores on both ends and that did nothing. Is there a preferred end for the ferrite cores on the stepper lines? Motor end vs. controller end? Or should it be on both ends as some cable do?

A similar problem is well documented in the 3D printer world, which is why I immediately pulled my DeWalt power cable out of the drag chain. (It’s just as easy for the router power to follow the dust vac hose.) In my 3D printer case, limit switches—even if not used—contributed to crosstalk between stepper motors, and vice versa. It’s not about the gcode operation, is about the signal from one set of wires, say a stepper, being induced into another set of wires—either another stepper, a limit switch, or coming from (a rather powerful) AC signal—when those wires are physically parallel and in close proximity for a long distance (say, 2-3 feet). The fix for my 3D printer was to put physical distance between the stepper motor wires and the limit switch wires. Though it makes no logical sense, it solved the problem. As pretty and handy as the drag chain looks, cheap wires (I even tried shielded wire on all steppers) don’t make the pretties actually capable of doing the job.

A USB cable with ferrite cores fixed it for me: Which GCode Sender? - #24 by bdubu

Just eliminate the computer entirely. Use CNCjs & a Raspberry Pi

1 Like

That’s an interesting take, but frankly the while the Raspberry Pi is a very nice piece of hardware (I have three of them), it still is a computer. So, you haven’t eliminated a computer at all.

That said, I still may look at it since it looks like it could be interesting.

1 Like

RobertCanning was spot on when he mentioned “static”. I am very certain that your troubles are down to static generated by the vacuum when it sucks up wood dust. I have had exactly the same trouble and spent many months trying to isolate the cause. Reading through the posts here I think I have tried every one of them and nothing cured it. I shielded cables, put chokes on USB cables, tried different PCs and so on and so on.
My X-Carve would run faultlessly with the vacuum on when cutting air but the at some point during the job when cutting wood the carve would just stop and and maybe raise an alarm on grbcontrol. But once it had stopped that was it, the job was wrecked.
You MUST earth your vacuum pipe and your vacuum pipe MUST be electrically conductive. You’ll get nowhere with a standard shop vac hose.
I hope this helps.

Thanks for the reply. I wouldn’t be surprised as I live in Arizona where single-digit humidly is not uncommon at times (…it’s a dry heat…).

That said, as it turns out, I was not the only one having these issues with the X-Controller and Inventables has slightly redesigned the USB section of the X-Controller logic board because of that and sent me one. I have tried it out on some sample cuts and the new board does indeed appear to have resolved my issues. That said, I haven’t had time to try do to a lot with my X-Carve, but hope to start doing some more in June.

1 Like

Interesting what you say about the X-Controller. I have recently (this month) bought a new X-Controller and I wonder if I may still have the problem lurking round the corner. When did Inventables make the mod and send you an updated logic board?

I don’t know when they made the mod, but I got mine just over a month ago. I’m guessing the mod isn’t that much older.