KMotionCNC instead of Mach4

[Roger]

Jul 18, 2021 21:21:13 GMT doubletop said:

Roger

What drew my attention to this is being able to utilise the DRO's to close the feedback loop. I'd always thought that an open loop system was questionable. Although I've been on the periphery of others CNC conversions I do really need to get some details together to do my mill. Starting with ball screws and then determining what type and size type of steppers to use. I wasn't aware of AC drives.

A question comes to mind about the integration of motor step counts and DRO readings. Does the system read the DRO's after every step and recalculate the steps to go? Does that have any effect on overall system speed? For example, to do a fast/long move stepper counts should suffice to get 'there abouts' however, you can't afford to overrun as there is no going back if the cutter is into the job. So when do the DRO's come into play? Maybe the antidithering has some role to play here?

Anyway if I do eventually decide to go ahead I know where to come for the additional interface boards, because you never get custom PCB's made as a one off

Pete

Hi Pete,
As far as I can see, the DSP runs a 'C' program that does all of the motion control, I can't tell exactly what's done in what order. If you put these questions on the Dynamotion Forum, Tom Kekeres will be able to answer them. It runs multiple threads, so how that's managed is anyone's guess.

Basically, you have to tune the system open loop, and only then do you introduce the feedback PID values. Usually, those are just a small amount of I to reduce the following error. That seems to work just fine because you can see the error on the graph reduce accordingly as soon as you close the loop with the linear encoders.

The problem with dithering is basically that a small error will always cause the output to change eventually to make the servo move to correct the error. That's the I term coming into play. Then it can roll over one digit too far and it just repeats. Ideally you need it to respond quickly so as to keep the error small, and that can make it worse. My issue is that there's lost motion that needs to be taken up quickly when it dithers in the reverse direction, and slowly in the other.

The interface boards might be useful, it depends on how you implemented your solution. Your welcome to what I have of course.

Roger

[Roger]

OK, today has been a bit of a disaster with the machine. I came to do some tests and found that the Machine On wouldn't latch. There was a blown fuse in the 24V power circuit, and it would appear that a stray wire had shorted it out. With that fixed, I still had a problem with the KFLOP, and that had a 5V fuse blown.
Anyway, the long and the short of it is that somehow it's managed to kill the KFLOP board, the DSP chip is getting really hot. That's not fixable here, so I've just ordered a new board. Maybe they will be able to fix this one, who knows.

So I'm in the process of figuring out if the KANAKOG interface board is damaged, and so far it looks like it isn't. The linear encoders still work using the Lathe DRO to test them, so it could be worse.

I need to go through the setup with a fine toothed comb to make sure something like this can't happen again. I'm still not entirely sure why it ended up damaged. Such is life, it's just a pain since it was going so well.

I'll probably have to reinstate the Mach4 solution while I'm waiting for the new board to arrive. I've got some commercial jobs that I need to be getting on with.

[sis]

Hi Roger,

I hope you are well. I've been following this thread closely. I too am looking at a small CNC build using this KFLOP. So please do continue to let us all know how this evolves.

Thanks and regards,
Steve

[Roger]

Jul 22, 2021 8:18:19 GMT sis said:

Hi Roger,

I hope you are well. I've been following this thread closely. I too am looking at a small CNC build using this KFLOP. So please do continue to let us all know how this evolves.

Thanks and regards,
Steve

Hi Steve,
If you're prepared to do a bit of extra work, KFLOP is an extremely powerful motion controller. It's not the easiest thing to get your head around, because it uses user modified 'C' files for things like Initialisation, tuning, homing and such like. At first, it's not clear how these things all hang together, because there's no explanation anywhere about it by way of an overview. It's also not clear how KFLOP interacts with KMotion and KMotionCNC until you've played with it quite a bit.
If you're going for a Stepper Motor drive, then they do an interface board with the necessary drivers. Mine is a novel application because it's using Step & Direction drives for AC Servos and Linear Encoders too. I've had to design an interface board to buffer the Step & Direction outputs and change them to Differential outputs for the Optos on the AC Servo. This also involved changes to the Initialisation files and a lot of head scratching to figure out what the port numbers those outputs were assigned to.
I'm sure most people manage to get a system running without having to delve anywhere near as deeply as I am.

[Roger]

I've spent the past few days reverse Engineering the KANALOG interface board. I started off just trying to decide if it was blown up or not, but ended up getting carried away and created a complete Schematic. Well, it's almost complete. There are some features I don't use, so I didn't bother with those.

Originally I was just going to buy the KFLOP motion controller and may my own interface. I'm glad I didn't because it's not as simple as I thought. The encoder channels are easy, they're just fed straight through. However, there are 8 Digital I/O, 8 ADC and 8 DAC channels too. Those are controlled by a few pins that direct the outputs to shift registers. There aren't enough interface pins on the KFLOP interface connector to interface with all of these functions directly.

Anyway, I'm almost at the point where I could make my own board that would be treated the same way as the KANALOG board, and that would enable me to just integrate all the parts and interface connectors neatly on one board. For the moment I'll just use the KANALOG board, but I might make my own, especially if this one turns out to be damaged beyond repair. I don't think that's the case though.

Yes, I know I didn't need to go to all this trouble, but I find it interesting to really get under the skin of what I'm using. That makes me less reliant on others when things go wrong, and less of a victim.

So the current state of play is that I've removed the 3V3 regulator from the KFLOP board, and replaced it with the new one that arrived today. All of the voltages now look good. I've also removed the 144 pin FPGA using the 'Chipquik' product featured in this video. I tried removing it with just a hot air gun at first, and it really didn't want to come off. I didn't want to end up destroying the board, so I looked for an alternative solution. This one uses a special low temperature solder that alloys with the solder in the joint, lowering its melting point to help get the chip off. It works pretty well.

[Roger]

A quick update on my attempts to repair the KFLOP Motion control board.

I managed to source three of the XILINX FPGA chips for £30, and I've fitted that, albeit with a bit of a struggle. It's a 144 pin TQFP, so it's very fine and easy to get shorts between the pins. However, once done, the LEDs flash in the same way they did on the good board, so that's promising.

However, connecting it to the USB failed to work, and on further investigation, that's not entirely surprising since it too is connected to the 5V supply which is the one that was shorted to 24V! So that was removed with Chipquik too, and a replacement was ordered. That's taken more than two weeks to arrive, so I don't think it ever will. I've asked for another, but I'm not holding my breath.

Instead, I ordered one from another supplier which arrived today. That needs to have its EEPROM programmed using a free utility provided by the device manufacturer. So I downloaded that, hooked it up, and it can see the device. However, I couldn't program it. Finally the penny dropped, I've managed to order a subtly different device, and since it doesn't match the template, it won't program it, even though it say's it's successful! My mistake, double check the numbers when eBay offers you something, it might not be exactly what you typed in!

So, I've just desoldered that one, and ordered yet another FDTI chip from a third supplier, and hopefully this one will be right!

All of this pantomime is entirely of my own making, so I'm not looking for any sympathy. At least it looks like it might actually work in the end, and I've learned a lot along the way. I've got the new one, and that does connect, but I don't want to use it unless I have to. I'd rather keep it as a virgin spare in case of any future dramas.

[Roger]

The correct FTDI USB chip arrived today, and with a bit of messing about with the programming utility, I've now got it so it's recognised by the Windows Device Manager. The programming utility is not that intuitive, and things got so bad that I had to read the manual in the end!

So I've learned something interesting about USB. I always wondered how the computer interrogated the device that's been connected, I didn't realise the USB interface chip itself had a user programmable section for that. Obvious really, when you know. I'd just assumed that the thing connected to the USB interface chip had to provide that information.

However, it still won't connect, even though the boot sequence looks good by the way it flashes the sequence of LEDs.

It might just be that there's another step that needs to be done that I don't know about, so I've posted the progress to date on the Dynomotion Forum in the hope that there's an answer.

[Roger]

Success! Following a suggestion on the Dynomotion Forum that it looked like the FPGA wasn't communicating with the FTDI USB chip, I painstakingly traced out the 8 data and 4 control lines between the two, and sure enough, one wasn't connected. The foot looked like it was soldered to the pad, but there was no connection. It took three attempts to clean, flux and get the joint to flow, but that did the trick.

So now it does communicate with the KMotion software, and it now remains to plug it all in again and see if it works with the KANALOG board or whether something else is blown up. There's only one other thing that looks like it might be connected to the +5V line on that board, so that might be damaged.

At least I've got the Schematic for the KANALOG board, so I know what's connected to what and how it works, broadly speaking. This is looking promising!

So to recap what I managed to blow up on this board by inadvertently connecting 24V to the 5V supply...

1) The top part marked by the Red arrow is a 3V3 Voltage regulator. The output of that feeds the other two regulators U2 and U3 which supply the lower voltages for the other chips.
2) The big chip with the Red arrow is the XILINX FPGA chip which basically does all of the random logic and interface circuits. This was getting hot when the board was powered up.
3) The bottom chip with the Red arrow is the USB interface chip which takes a 5V supply from the main board in this application.

The jumper J1 on the bottom RH side is for running the board using the power supplied by the USB interface. That's fine for bench testing, and for low powered interface boards. However, the USB isn't capable of providing enough current for the KANALOG board, so that jumper is removed.

KFLOP repaired by Georgia Montgomery, on Flickr

It's quite challenging to replace the 144 pin TQFP, you need to be very careful when getting it off because the pads are so delicate. It's also challenging to get neat and solid connections on all the pins without shorts. I don't want to over state the difficulty, but it's not a trivial task. I used desolder braid to clear some of the shorts.

It certainly makes you appreciate how precisely and quickly these processes are done in industry.

[Roger]

It looks like I've finally tracked down what blew up the KFLOP motion controller board. There was a splash of solder that was resting between a pin that was 24V on it, and one of the Step outputs for the Z-axis. Unfortunately it destroyed the driver in an impressive cloud of smoke, so I've ordered resplacements for that.

Anyway, it hasn't done any more damage, and I can now tidy up the wiring and make it secure. I'm going to shorten the cables on the Mach4 setup so they're neater and can be stored away more securely when I'm not using that. So finally I'm a it happier about it all now that I know what actually happend.

[Roger]

The purpose of this next job is to enable the easy switching from the old Mach4 system to the new Dynomotion one. The problem is that there are long wires connected to each axis for the old system, and those would have to be tidied up and stowed away when not in use.

This is how it currently looks, albeit with two of the Servo Amplifiers at the top being connected to the old Mach4 CM106-ESS board that's barely visible at the back right.

If you look at the large white connectors on the middle two amplifiers, you can see they are miles too long and the wires have to split into individual ones to go into the choc bloc type terminals on the board. I was going to shorten them, but that would have still left them connected.


20210530_205022 by Georgia Montgomery, on Flickr

So, putting on my thinking head, I thought I might just as well use one of the spare PCBs that I had made for the KFLOP board interface. Although I will still need to wire the connections individually to the choc bloc type of terminals, the board can be rigidly mounted and the connections made tidier.

There's a common 24V and ground required for each axis, and this board does that wiring on the board. There's another trivial circuit on a scrap of Veroboard that you can just see at the back right too. That takes the Optically isolated output from the Z-axis and puts it through a more manly FET to release the DC Brakes on the Z and A-axes. This simplifies it no end and it means I can lose the second set of wires going to the Servo Amplifiers. I just have to plug the ones from one system to the other. Ok, I still have to move the two wires for the DC Brake across, but that's all.

I'm not planning on switching back and forth, but it will be handy to be able to do this while I'm developing the code to handle the lost motion while using the Linear Scales. It's also handy to have a backstop in case of disaster, when I need it for a commercial job.

Anyway, I've copied and modified the schematic for this board to show how it's wired to the old motion controller, and this is how that's arranged. The 15Way 'D' connectors are on order, and I'll get this fitted as soon as they arrive. This will be a much more robust and reliable solution than two sets of flying leads.

20210818_214826 by Georgia Montgomery, on Flickr

The wires are just small enough to pass through the holes where the ICs go on the board, so I can wire this all on the back to keep it neat.

20210818_214754 by Georgia Montgomery, on Flickr

[Roger]

So near but still not right. I can see that the short I found appears to have damaged the output to the chip that was connected to, and that means the FPGA needs replacing again! Doh!
This is why I didn't want to just plug in the new one, I wasn't sure what the initial fault was. At least I know that now, so this time it ought to work. That's provided I can replace the chip again successfully.

Still, I've proved that the KANALOG interface board appears to be undamaged. I checked the only thing that was connected to the +5v supply, and that generated the A/D reference voltage which is fine. It also moves the X & Y axes. The only issue is that the Z-axis direction channel is damaged. That means it moves one way but won't reverse.

I'll have another go at it tomorrow. I'm pretty close to having this sorted out now, let's hope I don't mess it up at the final hurdle.

[Roger]

Bingo! I've finally got it all running today. I discovered that the shorted output to the differential driver chip had damaged the input side, which sadly comes straight from the FPGA. That meant that I had to carefully replace that again. However, this time it came off much easier because I'd used 60:40 Leaded Solder which has a lower melting point. I still used the ChipQuik though.

I've found that you do need to really lay a lot of the ChipQuik solder onto the joints to make sure it's well covered, and using a hot air gun is the way to go once you've run the soldering iron around it on all sides a couple of times.

Getting the excess solder off the board is best done by using the soldering iron on it while the PCB is held almost upside down, then shaking it off when it melts. It needs to fall clear of the board else it gets into everything and it's a sod to get off.

I've been looking at the dithering of the system, and it all seems much more stable now that soldering fault has been resolved. I guess there must have been some current flowing from the 24V through that which was upsetting the system.

I also investigated where the positioning errors were coming from. Putting the clock on the quill and seeing the table move back and forth sounded alarm bells, because it's supposed to be controlling to the Linear Scale! It turns out that was indeed happening, but the table was seesawing back and forth, yawing as the leadscrew tried to correct the position. That was caused by the Gib Strips not being anywhere near tight enough. It's a balancing act between having them tight enough to stop the table yawing, while not having it tight enough to bind up and gall. Obviously wear on the slides doesn't help this issue. One day I'll have to get it all reground, but it will have to do for the time being.

I think I'm going to just run it like this for a while. It's certainly better than it was Open Loop with Backlash Compensation. I can jog it and see it respond after a couple of one micron steps, and that's something I've never been able to do.

[Roger]

This is pretty messy, so I decided to do something about those coiled up wires that are just resting on the bottom of the cabinet and pulling on the connectors.

20210821_104817 by Georgia Montgomery, on Flickr

I found a piece of white drain pipe, the sort you have for a basin outlet, so I designed supports to use that. These bolt to the bottom of the cabinet using M6 square nuts. You can just see where the print is beginning to form those pockets

20210820_172549 by Georgia Montgomery, on Flickr

I measured up where the holes needed to be, and machined a couple of holes in a piece of PCB exit material as a drill guide.

20210821_102916 by Georgia Montgomery, on Flickr

The RH side was tricky to get to, since the computer underneath gets in the way. I didn't want to completely disconnect that and move it...

20210821_105340 by Georgia Montgomery, on Flickr

... so I used this ghastly right angled drive and a PCB drill for that one.

20210821_105949 by Georgia Montgomery, on Flickr

Ok, it still looks messy, but it's a big improvement.

All of those hanging wires are next on the agenda. I'll do that when the 15way D connectors turn up.

20210821_122640 by Georgia Montgomery, on Flickr

[uuu]

Could you put some channels for wiring along the top and down the side of the cabinet? So that the wires are taken up and round the edge, leaving access to the circuit breakers.

My EMCO has these nifty channels with clip-on lids - these allow cables to come and go at any point, whilst keeping things really tidy:

WIN_20190202_12_24_10_Pro by Wilf, on Flickr

Wilf

[jem]

May be a silly question, but why not just shorten the wires, and re connect them to their plugs? 15 way d connectors and easy enough to wire up and solder, or is there something that I am missing?

best wishes

Jem

[Roger]

Aug 21, 2021 13:30:44 GMT jem said:

May be a silly question, but why not just shorten the wires, and re connect them to their plugs? 15 way d connectors and easy enough to wire up and solder, or is there something that I am missing?

best wishes

Jem

The black connectors are oddball, and the 'D' connectors are ones that take armoured cable. I could probably find ones to suit the 'D's but I'm not so sure about the others. The other solution is to coil them up outside of the control box, but I thought this would be neater.

[Roger]

Aug 21, 2021 13:02:50 GMT uuu said:

Could you put some channels for wiring along the top and down the side of the cabinet? So that the wires are taken up and round the edge, leaving access to the circuit breakers.

My EMCO has these nifty channels with clip-on lids - these allow cables to come and go at any point, whilst keeping things really tidy:

WIN_20190202_12_24_10_Pro by Wilf, on Flickr

Wilf

I do have trunking like that already fitted, I just need to route the small cables through those. The ones that go to the Servos themselves may as well go straight to source since they're standing miles out to the front of the cabinet. I need to sort out the bigger issues, then I can do those.

[jon38r80]

Do they have to be inside the cabinet/box?
I am surprised you dont add a nice box on the bottom , you could take that gland plate out and put it in an extesion box that you 3D porint to suit to fit on the bottom. Looking at the photos you have posted the biggest problem you have is the cabinet isnt big enough for all the stuff you have in it. I dont see any cooling fan either, you could fix that too while you are at it.

[Roger]

Aug 22, 2021 12:24:08 GMT jon38r80 said:

Do they have to be inside the cabinet/box?
I am surprised you dont add a nice box on the bottom , you could take that gland plate out and put it in an extesion box that you 3D porint to suit to fit on the bottom. Looking at the photos you have posted the biggest problem you have is the cabinet isnt big enough for all the stuff you have in it. I dont see any cooling fan either, you could fix that too while you are at it.

Here's a shot showing the bigger picture of what's there. The PC sits underneath, and that limits what I can do. Obviously I could move any of it, but I just need a setup that works and isn't too messy.

If you look at the top, you'll see that there are two extraction fans. There's a perforated panel on the bottom at the right to allow air in.

You'll also notice a Stainless Steel angled tray above the control, and water pipes and a pump above that. The tray allows the travelling crane to pass over over the top, while protecting the control from any possible leaks.

20210822_160036 by Georgia Montgomery, on Flickr

So it is possible to put the cables further down, but the cabinet is already pretty big. 

[jon38r80]

Seems that a large pc case standing beside the pc you are using both facing out of your picture as it were might be a solution. I agree you are squeezing a quart into a pint pot. That's the trouble when you grow a system. At some point you outgrow the original and need to replan it.

I can see that you are running into the usual horrendous cable management problems that you get when you grow a system.

Anther possibility would perhaps be to build the PC and the controllers into a small server frame cabinet but that would be a large amnount of work and expense.,

Your solution makes much more sense as it stands for now.