Pushing the HAAS's limits

Machine Shop HAAS
#1

Hello. Attached is an embossing plate I did over the weekend on the HAAS. This was a little diffent than what most people do on the HAAS. Most parts cut are basically a 2 dimensional part where cuts are done to a final value and is constant throughout the part. This one was a truer 3 dimensional (actually 2.5D) part where there are 1000’s of x/y/z axis movements. The end result of this is that it leads to a very, VERY large file. This was roughly 3x3, and was over 35000 lines of G-code (over 600K bytes). As you can guess it doesn’t fit on our 75k machine.

The obvious solution is to use the DNC (drip) mode to transfer the file, it was froth with problems. while it ran for a while, it would eventually error out and not always in the same spots. It seemed be be closer to a fixed # of bytes hovering about 250k bytes into it before it threw a range error. The range error seems to be used for a number of things. What I think is happening is that the XON/XOFF doesn’t really work and it eventually overflows the memory. I fought this for a while before I ended up chopping the g-code file into smaller blocks. (What a pain in the butt to do on the fly). luckily I speak G-code but it takes a while to find a spot that you can start over on. So what was a 1 hour job ended up taking 4 hours.

Anyway, because Fusion360 isn’t exactly an efficient code generator, the more people use it, the more people are likely to hit these limitations.
there are a couple of things that need to be looked at:
-The first is the length of the RS232 cable. Prevailing wisdom seems to say it shouldn’t be more than around 20 ft. Following the cable there is a large spool of cable sitting atop the HAAS which is probably more like 20 yards long. Out in the world we call this an ANTENNA. We should look at shortening this with a smaller cable to avoid signal degredation, and error introduction from the surroundings or electrical discharges.
-We need to look at slowing the baud rate of transfers while in DNC mode to give the machine more time to execute the code before swallowing some more. This is not a cure, but it should allow for longer programs. The downside to this is that it will slow down regular downloads to memory. The reason being is that it requires changes on the controller to slow down the baud rate. SORRY, but I don’t want just everybody doing that on the controller. If I find slowing things down works, we’ll just have to live with it overall because we NEED DNC mode to work.
-Large programmed parts with multiple features (tool changes) will likely have to be broken up into multiple files. That wasn’t really possible on my plate since it is literally one large component based on an STL file.
-UPGRADE memory. This is just a wish list item. In reality, it’s not very viable. HAAS itself does NOT have an upgrade for a machine as old as ours. A complete controller change is necessary and HAAS does not carry that. It would have to be a 3rd party part and would only give us 1 meg of memory to boot. Prices have changed since Bryan G looked into it. Prices I saw were roughly $3500 with the controller.

so in short, as we move forward with F360 and larger programs be prepared for some challenges. it’s going to be doable but it’s going to hurt.

Incedentally, this plate was one of my smaller ones. It’s really going to hurt on the big ones. cheers!

10 Likes
#2

This is exactly the kind of thing I want to do with coinage dies, although the detail is enough finer that I have planned on home-building a mill for the purpose. I’d love to know more about your workflow.

#3

it all starts with a 3D model. In this case this is an STL file. STL is difficult to convert to a solid body so that Fusion360 can produce toolpaths. (They all claim they can do STL but only to about 20K faces which is nothing and is blocky.) Coinage (and in my case maker stamps) are a little different because of text. i haven’t mastered raised text yet. Text in relief is easy. In the case of text, I’m experimenting with a 20 degree V engraving bit. something like a 1/32" flat end mill doesn’t always get thru between the letters. If I get any of those to work I’ll post it.

1 Like
#4

I have my eye on a CAD/CAM package designed specifically for the task. There are two commercially available, with the cheaper one costing about $1000. The more expensive one is much higher.

1 Like
#5

now I’m intrigued. what packages?

#6

The cheaper one is Daniel Carr’s “VS3D/VSCAD”, which he developed in the process of starting his own mint (which is basically what I want to do). It’s been dormant for a while, but I’ve been in contact with him, & he affirmed that he would have no problem going back into active development if I wanted to start using it.

The other one… agh, it’s in my notes somewhere. I know they were advertising that it had been used by the Royal Australian Mint.

1 Like
#7

that is really cool. I don’t know if you’re familiar with hobo nickles, but that is worth looking up. I’d love to try my hand at one with CNC.

1 Like
#8

Ah, I visited Ron Landis at his workshop in Eureka Springs a while back. Ron is one of the great modern masters of the hobo nickel, & he showed me one where he had altered the Indian side into a tetradrachm of Alexander the Great. Of course, he also cuts coinage dies by hand…

1 Like
#9

oh yeah - there is no substitute for those masters that can do it by hand. I just don’t have the talent so I do things by machine. cheers!

#10

This can’t be the first time it’s been suggested, but what is the state of discussion on a Raspberry Pi based loader/feeder for G code?

Something with a USB stick port and maybe access to shared drives, with preset rate limits on feeding the code.

#11

The Original Hobo Nickel Society has produced several die-struck tokens over the years, in the standard nickel size (but other metals for obvious reasons). Some of those were by Mr Landis, & if you’re not familiar with the series, I think you’d find it interesting.