Motor Drive - Bridgeport Centroid Conversion - Crazy Z-axis Oscillation - Page 1
Forum section: electronics / repair

author: doombot1
author_rank: Contributor
timestamp: October 14, 2025, 11:37:37 pm
content: Howdy all,This is somewhat of a last-ditch effort but I really want to cover all of my options here before I send in the PLC board of my mill for repair - the diag cost alone is $250! So... here goes nothing. For reference, it is a Centroid (formerly Ajax) DC3IO PLC board.I've made a few posts about this on another forum that I hope I am allowed to link to (if not, I'll rewrite that post here) -https://centroidcncforum.com/viewtopic.php?t=12044Essentially, the tl;dr is my Z-axis oscillates back and forth at high speed (varies based on what my jog speed % is set to, though). The X and Y axes are fine. Swapping the Z axis motor/encoder with those of the X axis makes the X axis move all funky - i.e., the problem follows the control board's Z axis - and it is not a motor or encoder problem.I've been probing the main DC3IO board like a madman for the past little while here and am not really making any progress, so I am posting here with the hopes that maybe someone has better knowledge of signal pathing than myself and at the very least could give me some pointers on what or where to probe. It really screams feedback loop to me but I don't know enough about motor drives to guess anything else.What I've done so far -I've put a current probe on the X & Z motors, and the main motor voltage supply (pics in the linked thread above)I've also put a normal probe all over the place - I can at the very least see feedback whenever the Z axis does its thing pretty much anywhere on the board, but the signals are clearly different between the X/Y and Z axes.I removed the board & desoldered/tested all four of the large MOSFETs on the Z axis and they did not seem suspicious to me. All four showed the same/similar specs.I probed both sides of the optoisolators towards the right side of the board, and on Z, both sides do show wacky spikes. I'm fairly confident, then, that this means there's an issue somewhere on the logic side, and it isn't power-component-related (but I could absolutely be wrong here).I did try adjusting the CB3 pot and that didn't seem to influence anything, even when given a full turn or so. I've put it back to where it started at this point, though.Oh - and all of the fuses are good, I've probably checked that a hundred times by now. Even the little green through-hole one neat the top right of the board.Another of my concerns is that this could also be the fault of the PCI card that the fiber optics (which are outputs of the card) and the motor encoders (which are inputs to the card) connect to, but however the heck those fiber optics work is a mystery to me. 3 are dedicated to PLC signals and 2 to the motors - so it isn't separated X/Y/Z, and thus, I can't just probe them to check if the problem is there. And unfortunately, Centroid repair will charge $250 for diag on a per-component basis - so if it does happen to be the card and not the mainboard, I'm out an extra $250.There are some pictures of the board in the album that's attached to the linked thread - but I added a few more pictures of it here just in case those are at all helpful. But please let me know if there's any more info I am forgetting - the mill is directly below me in the garage so it's a quick thing to get more data on.If anyone's got anything that is at all helpful on this, thanks a millionand let me know if this belongs in another topic but I figured it fit best in repair.

author: Whales
author_rank: Super Contributor
timestamp: October 14, 2025, 11:59:24 pm
content: EDIT: Ty for the photos and lots of details, helps a lot.Question 1: Do you have an oscilloscope?Question 2: Is this the right manual?https://mail.centroidcnc.com/downloads/CNC10_DC3IO_Manual.pdfQuestion 3: Are the axis motors brushed two-wire motors?Question 4: Can you give us photos + descriptions ofallthe axis sensors you plug into this board for normal operation, so we can visually see what types you have and where they connect? It looks like this board supports different types.It looks like this one PCB does all 3 axes.If true then this would rule out power supply issues. The problem would most likely lie with (worth checking in this order):1. A software issue (Z axis control loop variables configured differently)2. Different Z-axis-only peripherals you have not tried swapping yet (end limit switches?)3. One of the 3 copies of circuitry used for the 3 axes.

author: doombot1
author_rank: Contributor
timestamp: October 15, 2025, 12:09:54 am
content: Answer 1: Yes - a few screenshots of scope traces can be found at the photo album at the Centroid CNC form link I providedAnswer 2: Yes, that's the correct manual, although I think the "mail" portion of the link is making it appear as an unsafe link. Here it is w/o that portion:https://centroidcnc.com/downloads/CNC10_DC3IO_Manual.pdfAnswer 3: DC motors (not sure if brushed or brushless), 3 wire + encoder.Answer 4: There should be some more zoomed-out pics of the control cabinet in the linked album as mentioned above. Unfortunately, I don't actually know enough about the board to know every sensor that's plugged into it. But as far as I am aware, the important ones really are the endstops and the 5 fiber cables coming from the PCI card.This PCB does have all 3 axes, correct. And the axes are in descending order (physically) Z, Y, Z - as in, the circuitry blocks are arranged in this order. Looking at my first picture of the board, (with the large Lattice FPGA being at the middle left side of the board), the top two 314J optoisolators are Z, middle 2 are Y, and bottom 2 are X. Similar case for the control circuitry & current sensors for each axis - it's all somewhat grouped on a per-axis basis. You can also see what axis each bunch of components corresponds to by the silkscreened labels on the trim pots. CBZ is z axis, CBY is y axis, etc.As far as I can tell, this is not a software issue - I haven't actually played with the PID values but all of them look similar across X and Z (I've mostly been using X as a comparison, although using Y would be the same net result). It's also worth noting that the previous owner of the mill mentioned that it worked for many years up until it broke - I suspect some component having broken, a metal chip shorting two leads, etc - unlikely to be a software issue. Especially given that swapping the X and Z motors/encoders still produces the issue on the Z axis (as coming out of the mainboard).I do not believe it's related to endstops at all - this happens in the middle of travel as well - not just at endstops. Swapping them around also does not change anything. My best guess is that it lies in (3) - one of the 3 copies of circuitry used for each axis. The waveforms I pictured in my aforementioned album do provide some useful feedback but I unfortunately just don't know enough about motor controllers to use that information for anything - maybe someone knows if bad caps/resistors/etc leads to a waveform looking like this.

author: Whales
author_rank: Super Contributor
timestamp: October 15, 2025, 12:28:02 am
content: Ah the albums were not loading for me, ty I can see them now.QuoteAh so it's never worked right whilst in your possession? That's useful to know.

author: Whales
author_rank: Super Contributor
timestamp: October 15, 2025, 12:38:05 am
content: Quick addendums whilst I'm still digging:- The fibers look like they are for digital data. If they were bad you would be seeing a wide variety of problems, not like this neat/tidy/predictable problem.- Nice to see you're using a current probe and not probing the HV directly- OH MY GOD BRIDGET YOU'RE A MESS! Please get a crimper for spade terminals, stuff like this is sad and a big risk considering how expensive all these parts are:

author: Whales
author_rank: Super Contributor
timestamp: October 15, 2025, 12:48:46 am
content: I am really confused. Where do the encoders connect to this board? I can find the end limit switches easy, but nothing about encoder/servo feedback. Do they connect to a different PCB maybe?EDIT: Yes they do! They connect to the "console" device. Oh dear.See PDF diagram athttps://centroidcncforum.com/viewtopic.php?p=84176#p84176(but be warned you can't text search it)This means the control loop is massive. The problem could be anywhereie the board you have photo'dmightbe 100% fine.

author: doombot1
author_rank: Contributor
timestamp: October 15, 2025, 12:52:36 am
content: Worth noting - many of the pictures in that album are very old! All of the screwed down wires have been replaced with spade/fork connectors & both the control cabinet & the mains voltage cabinet have been completely organized. The guy before me didn't care to spend the time doing it right, I suppose. And you're correct - this particular issue has been present since I got the machine.Yes - sorry - the encoders do connect to a separate board. In the one pic in that album of the full control cabinet, with the PC at the bottom - they go into that long PCI card that's towards the bottom of the PC. And damn... looking at these pictures again is reminding me how awful this thing used to look. Let me find some newer pictures & attach those to another reply to help make this a tad easier.

author: doombot1
author_rank: Contributor
timestamp: October 15, 2025, 12:59:37 am
content: Here are some pictures of the cabinets post-reorganization. I don't hate myself quite enough to deal with the cabinets in their previous sorry states.

author: doombot1
author_rank: Contributor
timestamp: October 15, 2025, 01:00:47 am
content: Quote from: Whales on October 15, 2025, 12:48:46 amThat's my concern :/ and I fear there's only really one way to find out for sure, unfortunately. I suppose all I can do is hope that it's a problem with the mainboard & send that one in first.

author: Whales
author_rank: Super Contributor
timestamp: October 15, 2025, 01:16:46 am
content: From what I gather this is the full control loop:Encoder <cable> console device <optic cables> DC3IO motor driver board <cable> brushed motor <mechanical shaft>Encoder <cable> console device ...You believe you have eliminated the encoder and motor by swapping them for another axis. I think it's unlikely to be the optic cables. This leaves:* Encoder cable (did it get swapped too?)* Console device (electronics & firmware)* DC3IO boardIf you measure signals on any of the 3 above suspects they willallshow the faulty signal pattern because the system will be measuring the jiggles. There are two ways to find out which part the problem is coming from:1. Replace boards one by one until the problem goes away (do you have any friends with the same mill?). This is probably what the service teams will do if you ship them your stuff.2. "Break" the feedback loop, so the jiggly signal problem will be seen to come OUT of one board but NOT IN, telling you that board is the cause.It's easy to break the loop via the mechanical shaft. Ie unplug all motors, plug a motor or lightbulbon your bench(not in the machine) into the Z axis outlet, then plug any axis encoder into the Z's axis encoder input. Now the motor & encoder are no longer mechanically connected, "breaking the feedback loop". You then operate the encoder by hand (hand-cranking the axis) until the motor stops spinning. You can then measure signals all along the chain of device & cables and see if you can find out where the jittery behaviour is being introduced.Sadly, the place I really want you to "break the loop" is the optic fibre connection. But I can't think of an easy way of doing this. I suspect it will be something like a simple 9600 baud infrared LED link, but that's still not something you can twist some wires together to test. Going to have to think on this one.Maybe it's possible to disconnect the fibre optic cables whilst the unit is running? Given that it's a safety-critical piece of equipment they will probably make it enter an emergency shutdown mode within miliseconds of the cables being disconnected, so probably not.EDIT: Nonetheless, see if you can get the machine to operate with a broken feedback loop, like I've described here. Does this make sense to you?

author: doombot1
author_rank: Contributor
timestamp: October 15, 2025, 01:23:07 am
content: I'm in agreement that it's unlikely to be the optical cables. The encoder cable *needs* to be swapped with the motor - if I try just swapping the motor power wires and leave the encoders as-is, the machine throws a runaway and forces a power cycle as soon as I try moving a motor. Likewise, I'm pretty sure disconnecting one of the fibre cables while it's on would stop the machine immediately - but I'd also be weary in that case of some undefined and possibly damage-causing behavior if the machine doesn't have the proper handling for it.I do see what you're saying with the hand-cranking an axis - and I'll run downstairs & give that a shot within the next hour or so here - the only issue with that is the motors don't have manual handles - although I suppose I can open up the pulley cover & spin the pulley manually. But I suspect I'll hit a runaway condition - but it's worth a shot!Sidenote - super awesome that you're doing all of this digging for a random internet stranger. Means a lot to me.

author: Whales
author_rank: Super Contributor
timestamp: October 15, 2025, 01:29:50 am
content: > if I try just swapping the motor power wires and leave the encoders as-is, the machine throws a runaway and forces a power cycle as soon as I try moving a motorDamn.There will likely be a way of overriding this for service reasons. Perhaps the end limit defeat switches on the DC3IO board? They might do more than just affect the end limits.Can you tell the CNC software that you mill has a bed/axis 1km long? That might defeat the movement timeouts. (OFC please make sure to have all your motors disconnectedDon't want to see a news story about someone impaled on a wall by a thrown bed.)> Sidenote - super awesome that you're doing all of this digging for a random internet stranger. Means a lot to me.No problems. I'm off work sick today and enjoying trying to help a bit. Wish I could visit in person.

author: Whales
author_rank: Super Contributor
timestamp: October 15, 2025, 01:53:08 am
content: Are you using an MPU11 or a CPU10 as your controller card?

author: doombot1
author_rank: Contributor
timestamp: October 15, 2025, 02:01:14 am
content: That's a great question - I think it's a CPU10 but I'm not 100% sure. I'm about to go try some motor stuff so I'll check that as well & report back.

author: Whales
author_rank: Super Contributor
timestamp: October 15, 2025, 02:05:35 am
content: Random thing from the manuals: try disabling the MPG (Alt+W?) and disabling/unplugging all other user input devices that might be used to control the axes. Just in case they're flaky.

author: doombot1
author_rank: Contributor
timestamp: October 15, 2025, 02:07:00 am
content: Just checked - it’s a CPU10 daughterboard.

author: doombot1
author_rank: Contributor
timestamp: October 15, 2025, 03:02:42 am
content: Alright, another quick update. Getting to the point where I can’t make heads or tails of this because it’s all sorts of confusing, lol. Let me try to explain what I did as best I can.I have easy access to the Y motor’s pulley (I’d do this all on my bench but it would essentially require me to tear down half of the machine and at that point, it’s substantially easier to just send in the parts). For the record - none of this has to do with the X motor or encoder at all. I took Y’s encoder and plugged it into the Z encoder port on the PCI card. I unplugged Z’s encoder from the card entirely and left it unplugged - they’re rotary encoders - to ensure it wouldn’t spin when I spun the Z axis and cause a runaway. I then unplugged the Y motor power cables entirely and left Z plugged into the correct Z power port. Turning the machine on and jogging Z does move the Z - it moves the axis pretty fast though, presumably because the encoder isn’t moving so it keeps trying to move it more? That being said… from what I could tell, it moved smoothly. The problem with this is that it moved the Z very fast - faster than I can normally jog it (jog speeds are set fairly slow anyways). And when the Z axis is jogged in a normal state, the bouncing is only really noticeable at low and medium speeds. When the axis is moving fast enough, it’s more of less unnoticeable. So I’m not sure if that actually gives me any information or not…Also - I did try disabling MPG, and jogging the motors from within the software instead of from the control pendant - and neither of those did anything of note.

author: Whales
author_rank: Super Contributor
timestamp: October 15, 2025, 03:04:45 am
content: https://www.centroidcnc.com/downloads/cnc10_install_service_manual.pdfLooks like there are multiple safeguards that will trip if you try and run the axes open loop, including "409 axis lag" and "410 position error". No hints as to whether it's possible to disable them or enter a service mode.http://www.cncsnw.com/CPUs.htmQuoteHuh. A single flaky encoder input line could cause your issue.Might be worth checking if you have a revision A version of the CPU10 board (see photos in link above), then email Centroid about your problem and ask if it could have been because of this. A shorted wire sounds likely given the original photos of the machine from the previous owner.I can't find any high-res pictures of the CPU10 board on the internet. If you have time would you mind photing the front & back sides like you did for the DC3IO board? Diffuse lighting is best (overcast day or white ceiling room) to avoid specular whiteness on the shiny PCB.

author: Whales
author_rank: Super Contributor
timestamp: October 15, 2025, 03:11:28 am
content: QuoteThat's good, you managed to break the control loop and got some information out of it.These resultssuggestthe Z motor driving circuitry is fine, it's not hiccupping. The problem is before that in the system. This is only apartialalibi for the DC3IO board, but it's still something.Yes the higher than normal speed is expected. It will probably ramp the motor up to max current because it thinks the motor is running too slow (the encoder says it's not spinning at all).QuoteThe problem disappearing at higher speeds can be caused by one of two things:(1) Saturation of the control loop in software. If the motor max power is 1.0 and we instruct it to run at 0.5 +/- random jiggles then we will see it jiggle. If we instruct it to run at 2.3 +/- random jiggles then it will just run at 1.0.(2) Problem is in the transistors driving the motor and only appears when they are being PWM'd. I think this is less likely because current limiting should be kicking in, which will cause it to start PWMing anyway.

author: doombot1
author_rank: Contributor
timestamp: October 15, 2025, 03:14:15 am
content: Oh man, I’m really hoping it isn’t a problem with the daughterboard. If some of the centroid forum posts are to be believed (and I’ll email them tomorrow & ask to double check), a CPU10 card is very hard to come by…

author: doombot1
author_rank: Contributor
timestamp: October 15, 2025, 03:18:27 am
content: The board is a CPU10A - mine was manufactured at some point in 2005 I believe. I wouldn’t be overly surprised if a small piece of swarf got into the cabinet and landed on one of the encoder pins & shorted something… but again, I’m realllly hoping that’s not my problem. I’ll ping centroid about that tomorrow as well, although most of the help they’ll actually give me seems to be users helping me in the forum - they really want you to pay for help :/I’ll take some pics of the CPU10 board momentarily.

author: Whales
author_rank: Super Contributor
timestamp: October 15, 2025, 03:24:01 am
content: Looking forward to your pics! Please also do one with the wires plugged in so I know which connectors are used. (And to make putting it back together easier! There will always be something you miss)If you're lucky then it might just be one of these input chips gone bad. There are 5 of them on the right side near the 6 black encoder input IDC connectors:You would diagnose this by swapping the IC used by the Z axis encoder input connector with any one of the others (some of them might even be for channels that you're not using). You will want a friend that has done hot air work before, or a hot air rework station + tape to insulate the rest of the parts + flux + solder + tweezers + practice on some scrap PCBs first. Should take 5-10 minutes to swap, maybe more to inspect and check for bad solder joints afterwards.Just a theory. Once I have higher res photos I'll be able to follow the traces, read the part numbers and work a bit more out.

author: doombot1
author_rank: Contributor
timestamp: October 15, 2025, 03:43:03 am
content: Well dang, I wrote all of this out and then it didn’t actually post. Ah well, here goes attempt #2.My lighting kind of stinks but this is the best I can do. The large ribbon cable at the upper left is the jog panel. In descending order, the ribbons on the right are unused (4th axis), Z, Y, X.I do have a hot air station and a bit of experience but I do just hate doing it, especially with a board that may as well be unobtanium. And given that I don’t actually know for sure whether this is the actual problem. But… given that the 4th axis is unused, and there’s even a 5th input, I think I have 2 extra tries? Ugh… I’ve got some pondering to do… I really don’t want to send this thing in but I also really don’t want to make it worse than it already is!

author: Whales
author_rank: Super Contributor
timestamp: October 15, 2025, 03:48:50 am
content: Yeah, I know.If you prep well (tape & paper covering the parts you don't want to desolder) and use a proper temp-controlled hot air source then your risks are relatively low. But I won't push you to do it, you're right, there are risks involved and it's not a guarantee that this is the problem (it's just aneasyishthing to try that has some likelyhood of being the cause).Thankyou for the pics. Would you mind reading the part numbers off the 5 ICs I circled? I suspect they're all the same, but I can't read them from your photo.EDIT: Also your logs say this machine has had an interesting life:QuoteI'm going to assume that the emergency stop is used as a power switch, so that means 1000 cycles of usage. It lines up with the X limit trip counter too (homing after startup)."Full power without motion" (stalls?) and "encoder connection is bad" are suspect, they're 20% and 10% of the runs. Eep. The position errors are low enough it might just be from normal problems like bad tool paths (too fast of movement or maybe getting stuck on parts).

author: doombot1
author_rank: Contributor
timestamp: October 15, 2025, 03:51:02 am
content: Sure thing - they’re all the same, DS26LS32.I actually have a whole bunch of nice metcal stuff and almost completely forgot I had a SOIC-16 desoldering tip. Wayyy easier to use and I’m much more comfortable with a wand. That said… one chip’s already off and the second should be in about fifteen seconds; it’s a quick procedure. I’ll just have to get out the microscope to solder them back on but that’s no big deal.Sometimes I forget I’m IPC 7711/21 certified, lmao

author: Whales
author_rank: Super Contributor
timestamp: October 15, 2025, 04:10:16 am
content: Eeek.I followed some of the traces from the encoder connectors in your photos. They go to those DS26LS32, but also tee off to the lattice chip (PLD?) at the top right. Direct connection, no resistors or other parts in-between.That's not what I expected. And unfortunately the DS26LS32 inputs (common mode maximum rating +/-25V) are probably hardier than the programmable lattice chip's inputs.

author: doombot1
author_rank: Contributor
timestamp: October 15, 2025, 04:14:57 am
content: Well damn, you just have to keep being the bearer of bad news, don’t ya?!Totally kidding. It’s funny what they did and didn’t put protection on for these boards. For instance - they *did* put protection on the DC3IO board for reverse motor voltage (because some genius wired the 110VDC in for the motors backwards when debugging this thing before selling it to me)

author: doombot1
author_rank: Contributor
timestamp: October 15, 2025, 04:28:21 am
content: Just an update by the way - unsurprising given what you said a few moments ago - but swapping the two chips didn’t help, unfortunately. Z still jitters.That said… I’m way more confident doing that for future repairs; it was far easier to do it than I remembered. So that’s a good thing!It’s a real shame Centroid charges diag on a per-part basis, and a bit scummy at that IMO. Seems like it doesn’t really make sense in a system like this where the two boards form a feedback loop and are so intertwined anyways. Now I’m just trying to figure out which one I want to send them first, and hoping it isn’t the wrong one because then I’ll have to kiss another $250 goodbye for nothing :eyeroll:

author: Whales
author_rank: Super Contributor
timestamp: October 15, 2025, 04:37:45 am
content: Sorry doombot.Yes I think it's likely to be one of those two boards. It's a shame you can't cut the fibre optic link between them and imitate signals for it, that would help you work out which board.Services costs are probably an important part of their business viability. DIY CNC adaption kits sounds like a high risk market to me, customers will do all sorts of crazy things. If you only charge for goods but not service time then you'll go broke.

author: Whales
author_rank: Super Contributor
timestamp: October 15, 2025, 04:39:09 am
content: Passing thought: can you redefine/re-arrange the encoder inputs in software? Eg if you configure your machine to have a fake extra axis or spindle? Or is Z always stuck on the same encoder input connector?

author: doombot1
author_rank: Contributor
timestamp: October 15, 2025, 04:43:38 am
content: I suppose you’re right on that, and I’m certainly not expecting them to give service time away for free. I’m more just peeved that these two boards don’t get combined into one “unit” just given how intertwined they are. But… enough of me complaining!I’m not sure if the encoders are software-configurable but I guess that’s something I should check… good thought! If they are, maybe I could swap Z to the 4th axis port & see if that works. I’ll have to give that a shot… and then I think it might be time to call it a night, it’s getting late here. But this is definitely something I’ll mull on overnight, and get a few questions asked to Centroid to at least see if I can get a better idea of what I have to do here.

author: Whales
author_rank: Super Contributor
timestamp: October 15, 2025, 04:45:59 am
content: Yeah per-board is silly, that forces the customer to make arbitrary guesses before sending things back. Good luck and good night. Get some sleep

author: doombot1
author_rank: Contributor
timestamp: October 15, 2025, 04:53:06 am
content: Thanks! And thanks again for the help today.Btw - just powered the machine up one more time. I can see where there are positions for the 2 unused axes - so I think I can set them in software? I suppose I can just copy the PID values & such from the existing Z, and then probably plug the Z encoder into the axis 4 position. I’m just not sure if that will correspond to button presses on the jog panel, even if I rename the axes accordingly. One issue I see is there are a whole load of machine parameter bits that can be set in a massive table - and I’m not sure if I would have to also change any of those accordingly to use the Z axis. I’ll do some research tomorrow morning as well. I’m gonna sleep on it & maybe it’ll come to me in a dream, lol.

author: doombot1
author_rank: Contributor
timestamp: October 15, 2025, 05:03:50 am
content: On second thought… I think I misunderstood what was going on with that. Although I can set up a fourth axis, I didn’t see anywhere where I can actually make the Z axis use the encoder for a different axis - but I’ll keep looking around tomorrow.P.S. I keep forgetting to say… feel better soon! Hope it’s nothing too serious.