Torus Pro As A "Production" Machine

[SCzEngrgGroup]

I almost always use assemblies for fixtures. But, in this case, an assembly doesn't work well. For some reason, the reamed holes for the TTS shanks came out over-sized, which means all the TTS holders are shifted slightly from their proper positions. There is no easy way in HSMXpress to deal with those inconsistent offsets. I can make a fixture model that shifts the part locations, but then it's impossible to properly define the stock for 2DAdaptive operations, without it spending a huge amount of time cutting air. At some point, I'll need to make a new fixture - not big deal really.

I now have a very simple and elegant solution to this problem. I modified my HSMXpress POST, so I can now set a property (option) in the post to true, and it will automatically convert each operation in the job to a separate subroutine. I can then manually add g-code (in the Job Notes section) that is included in the g-code output file to call those subroutines, shifting the G52 offset appropriately before each call, to accommodate the small offsets of the TTS holders in the fixture. Simple, and NO manual editing required when the code is re-generated!

Today I also discovered, to my dismay, that in the process of adding the ATC communications to the PDB firmware, I seem to have broken something, as it misbehaved in a very odd way that I've never seen before. I'll have to get out my "PDB firmware debugging hat" sometime in the next few days and get that sorted out.

This problem is still vexing me. It is actually a bug in the PDB firmware, not the ATC firmware, though it occurs only when the toolchange is requested by the PC application, never when the toolchange is requested through the ATCs own UIs. but is proving quite difficult to track down. I know WHAT is happening, but haven't yet figured out HOW it's happening. It's hard to debug, since it requires seeing what is happening in the PC application, the ATCs controller, and the PDBs controller simultaneously. The good news is, this is the only problem I've seen in the last week, and I've run the machine a LOT in the last week. So I believe the ATC is now very nearly bug-free!

Regards,
Ray L.

[SCzEngrgGroup]

A few more years, and I might just get the hang of this! Here are a few more transfer arm drive parts - these two are the "structure" of the drive, which house the two custom Turcite linear bushings, and support the leadscrew drive (which is also now done). They look FAR better in real life than in this lousy photo - the surface finish inside and out is just phenomenal - it looks like all the surfaces were lightly "brushed" with a very fine Scotchbrite pad, leaving a perfect satin finish. I intentionally left the machining marks in the side "pockets", as I like the lovely circular patterns left by the HSMXpress 2D Adaptive roughing operations.



I also finally got to the bottom of the "PDB firmware bug", which turned out not to be a PDB firmware bug at all. Sadly, I cannot explain what was really happening, I just know I fixed it. The behavior was: Every once in a while, the PC would command a toolchange, which would, eventually, cause the ATC controller to command the PDB controller to tighten the drawbar. The PDB controller would do everything right, until it came time to actually turn the drawbar at which time it would simply sit there, not turning. Oddly, this seemed happen only when the PDB operation was commanded in response to a toolchange request from the PC, and the condition could be cleared by manually activating the PDB through its front panel. However, yesterday, it got MUCH worse, to the point I had a hard time getting these parts done. It seemed for all the world like a firmware problem, as re-setting the PDB controller would also nearly always clear the problem. But, after spending several hours digging into it, I discovered that the firmware was, in fact, working absolutely correctly, but the motor was not spinning when it should. I replaced the PDB motor, and it has not happened again. Incredibly, the old motor still appears to work perfectly, so I can't explain what was really going on. Very odd..... I do know that particular motor has had a very difficult life, as it was the one I have used on my machine since the very first PDB prototype, and it saw some major abuse in the early days of the PDB development. I have seen only one other failure on one of these motor, and that one fell victim to some foreign material getting inside the motor, causing a mechanical jam. After disassembling and cleaning that motor, it is still working fine to this day.

I have a few more small, PITA parts to make for the transfer arm drive, and then it will be ready for testing.

Regards,
Ray L.

[SCzEngrgGroup]

After a ridiculous number of delays due to factors beyond my control (and unrelated to the ATC development), I am now within a day or two of mounting the new ATC on my machine for the first time! It's all together, and seems to be working perfectly. All that's missing is the new mounting brackets, which I hope to get done tomorrow. Today I got all the many new sensors assembled, mounted, and tested. In particular, the new sensors for detecting whether or not a tool is present in each tool receiver is working perfectly.

The prototype has been working absolutely flawlessly since I replaced the faulty motor on the PDB a week or two back. I still don't have a clue what is wrong with that motor, as it still appears to work perfectly since being replaced. Very odd indeed....

Regards,
Ray L.

[RCaffin]

Ah, but what sort of motor is it?

Cheers
Roger

[SCzEngrgGroup]

Ah, but what sort of motor is it?

Cheers
Roger

Just a plain DC brush motor - very low-tech.

Regards,
Ray L.

[RCaffin]

Hi Ray

I have had DC brush motors go very noisy on me. They still spin, but they do make interference.
For that matter, I have had a (new) spindle drive supply blot out a transistor radio nearby, and send the Z axis everywhere! Good spindle drive supplies seem to be not so common.

Cheers
Roger

[SCzEngrgGroup]

A pretty good day today. I got the new transfer arm drive mounted on the machine, and it works beautifully - much smoother, and quieter than the prototype. I only have to adjust the length of the arm (due to a slight change in mounting position), and re-make one small part for the arm home/limit sensor, to adjust the limit positions. Then I can get on with mounting the new carousel, which will be much easier than mounting the transfer arm drive.

Regards,
Ray L.

[SCzEngrgGroup]

The new transfer arm drive is working like a charm. It did it's first real toolchanges today, with the old carousel. Getting the cabling sorted out took longer than expected - there are a lot of wires, and it's important for them to be properly clamped/constrained to prevent fatigue failures, and to keep them from getting tangled in the "works". Also, I'm being careful to make sure everything is sufficiently modular so that a failed sensor or motor can be easily replaced without any major disassembly.



First thing tomorrow, I have to do a little re-work on the top plate of the carousel, to extend the range of adjustability, and assuming I can adapt the shroud from the old carousel to the new one, I should have the new carousel mounted and working tomorrow. I had expected to have to re-make part of the mounting bracket, but I lucked out, and the old one works nicely by simply turning it upside-down! Sometimes, ya just get lucky!

One thing that continues to amaze me - how a small change in one part of the design can induce a large change in another part. In particular, a small (1/4") change in one dimension or location can require shifting another part by an inch or more. This is particularly true of the transfer arm drive position, which significantly affects both the position of the carousel, and the length of the transfer arm.

It really sucks NOT having a toolchanger for these few days, and I really feel bad having to retire the prototype, given that it's been working perfectly for some time. But, the new one will be even better.

Regards,
Ray L.

[RCaffin]

Just a thought Ray. I am currently going through a major rewiring on my CNC, to separate all motor power cables from all sensor cables. I was getting drift on the Z axis from noise pickup: motor power to sensor signals.

Cheers
Roger

[SCzEngrgGroup]

Just a thought Ray. I am currently going through a major rewiring on my CNC, to separate all motor power cables from all sensor cables. I was getting drift on the Z axis from noise pickup: motor power to sensor signals.

Cheers
Roger

Not sure what you're getting at.... The problem with my bad motor is it would not turn at all, even when given full power. I've never had any noise problems with the encoders or sensors - those signals all run in shielded cables, and are de-bounced either in software or hardware.

Regards,
Ray L.

[SCzEngrgGroup]

The new carousel is mounted (sans shrouds), and is working perfectly! It is wonderfully smooth and quiet. Now I just need about half a day to update the firmware to use all the new sensors. The only change I can see making in the hardware is a slight re-design of the tool lock "cam" on the carousel, to make it more positive. It's a simple plastic part, so just a few minutes machining time to make a new one. Everything else seems pretty near perfect as it is.



Regards,
Ray L.

[RCaffin]

Hi Ray

It was just a thought. I didn't have any real details of the motor failure.

Yeah, shielded cables ... but the shielding is NEVER 100%. And while shielding with copper braid is good at blocking electrostatic coupling, it does NOT eliminate magnetic coupling from high currents - which motors generate. It's a cruel world ... :-)

Cheers
Roger

[SCzEngrgGroup]

After beating my head against the wall for several days, sorting out a number of minor hardware and firmware issues related to all the new design features, the first pre-production ATC is now fully functional, and working considerably better than even the first prototype. I was getting veeeerrrrryyyy close to taking out my BFH and beating it inot dust, but this morning had a breakthrough, and things finally started falling into place. The hardware changes are minor - mostly minor clearance issues, but the firmware changes were extensive, due to the many new sensors, which are all now integrated and working properly.

Here is the first video, doing random toolchanges:



Average toolchange time is only 18 seconds - not bad, and well under the 20 second target. Reliability seems excellent, though I'm sure I've introduced a few new bugs with all the firmware changes. I think a few more days of testing, and I'll be ready to make a second unit for beta testing.

Regards,
Ray L.

[SCzEngrgGroup]

The new prototype ATC works VERY nicely. It's greatly improved over the old one - faster, smoother, quieter. With the new, MUCH "stiffer" servo tuning, it really moves nicely - very crisp and decisive.

I have clearly introduced new firmware bugs, as it gets confused when I force certain error conditions, but that is not at all unexpected, and will get sorted out in short order. Overall, I am now very pleased with how it's all working, and see no serious obstacles to finally getting it into production in the coming months.

Regards,
Ray L.

[SCzEngrgGroup]

Here's a blast from the past - the ATC I built (in about a month) for my old knee mill, years ago:



I've had to bring it back to life, to sell the machine, to make room in my shop. The PDB is, basically, the first prototype for the Novakon PDB, but uses an expensive NEMA planetary gearbox, and a large stepper motor, instead of the much smaller, less expensive parts used in the Novakon PDB. Overall, the Novakon PDB works 100X better, and is far smaller and cheaper. There is an ever bigger difference between this very crude, simple ATC and the new Novakon ATC.

Regards,
Ray L.

[SCzEngrgGroup]

Can an endmill shrink spontaneously, then return to normal size???? I've found something that has me absolutely mystified. I was assembling some power drawbars, and came across a part with dimension that was WAY off - it was a thru-bore that should have been 1.040" in diameter, but was actually just under 1". I re-checked the G-code, and it was absolutely correct! That is just one operation, out of about 20 in making that part, and the whole sequence is done in a single program that makes 5 parts at once, and the program ran 5 times to make 25 parts. EVERY other dimension was spot-on. The same tool was used for the majority of the cutting on those parts.

I cannot for the life of me explain how that could possibly happen. It's like the G-code just skipped right over the execution of that entire operation, which is impossible.

Fortunately, that bore is buried in the internals of the PDB, not remotely visible to the end user, and it was quick and easy to put the parts back on the fixture, and run that ope operation on them. So, nobody will be any the wiser.

But how could it happen????

Regards,
Ray L.

[RCaffin]

Hi Ray

Not by that much!

However ... if you are running Mach3 for this and using subroutines, be aware that there are some bugs inside Mach3, DEEP inside, which can sometimes have 'interesting' effects. There is at least one race condition which can screw the whole system up, and variables can get confused if you go down a couple of levels of subroutines. Been there, done that. Terry knows more about this than me. The bugs derive from a few basic design faults which can NOT (ever) be fixed - that's why Mach4.

Probing with Mach3 and an ESS can be problematic. Sometimes the XYZ return parameters are correct, but sometimes you get the starting value of the X, Y or Z instead of the final value. This does not happen with every release of Mach3, just some.

I am not saying this is what happened to you. I am just saying these things are sometimes possible. As I said, been there and done that.

Could it be that the loop number in a subroutine call was damaged, to be 1 less than it should have been? So the hole was not opened out quite so far?

Cheers
Roger

[SCzEngrgGroup]

No subroutines, and not using Mach3. Like I said, the g-code is absolutely correct, and cut the parts properly when I re-worked them. It's a real stumper....

Regards,
Ray L.

[Hirudin]

If the code is right (and presuming it was executed properly), and the tool didn't change, the only thing left that I can think of is the part. Could the part have moved while that bore was being finished? Only about 25 thousandths were left on the part, right?

In other words...
Not the code
Not the tool
Not magic
Execution?
Part shift?
What else is there?

Long shot: if the spindle was starting and stopping, and if the bore was shallow enough, the tool could have, conceivably, gone down into the unfinished bore and followed the proper path without the flutes touching (or without them cutting) if the spindle wasn't running. Were there any nicks on the unfinished bore?

[SCzEngrgGroup]

If the code is right (and presuming it was executed properly), and the tool didn't change, the only thing left that I can think of is the part. Could the part have moved while that bore was being finished? Only about 25 thousandths were left on the part, right?

In other words...
Not the code
Not the tool
Not magic
Execution?
Part shift?
What else is there?

Long shot: if the spindle was starting and stopping, and if the bore was shallow enough, the tool could have, conceivably, gone down into the unfinished bore and followed the proper path without the flutes touching (or without them cutting) if the spindle wasn't running. Were there any nicks on the unfinished bore?

The bores were perfectly round, and perfectly centered - just the wrong size....

Regards,
Ray L