Help with 'Speedy' valve gear and other issues...

[Roger]

Jan 14, 2021 3:06:47 GMT David said:

Jan 13, 2021 15:58:29 GMT Roger said:

So I've found the function in the script that outputs the comments, and just don't output them if they are more than 30 characters long.

You're ahead of me, that was my first question.

It was frustrating I couldn't find a way via the F360 API to get access to the actual toolpath operations. You can bring them up in the UI, and they have the rapid moves intact at that stage and having access to that information would have been useful. But I also wanted to remove annoying comments from Autodesk and add my own.

A piece of gound steel that size wouldn't be cheap. Mouthpieces must pay well!

Hi David,
The comment was surprisingly easy to fix, even though I don't have a programmer's manual and I have no idea of what the language is.
Looking at the style of it, I guessed there would probably be a 'length' method or sizeof() function for the text string, and to my surprise my first guess worked. I've since found the Post Processor reference here which ought to make other changes a bit easier.

/**

Output a comment.

*/

function writeComment(text) {

  if (text.length<30){     I just added this test
    writeln(formatComment(text));

    }

}

I don't like rapid moves, I'll probably replace those with a default feed linear move so that the control will respond to the feedrate override. Frankly I think rapids are dangerous and I never use them.

I don't think the Steel plate was that expensive, it's Plough Ground, so not a precision item. You know me, I would rather go the whole hog and make something that's useful for more than just the one job I'm doing. I've made a lot of different commercial jobs on it, a lot with internal or external N o. 0 Morse tapers and things I need in quantity.

I enjoy developing a new process or method, and I find that it always comes in useful later. That's why I'm persisting with Fusion360 for Lathe parts because I can see this is a much more practical way to create the programs. At the moment it's a real pain with Alibre, so I only use it when there really is no alternative.

[ettingtonliam]

'--it's plough ground so not a precision item.---'

Pardon my ignorance, but what is 'plough ground' steel? I've never heard the expression before.

[Roger]

Jan 14, 2021 13:21:29 GMT ettingtonliam said:

'--it's plough ground so not a precision item.---'

Pardon my ignorance, but what is 'plough ground' steel? I've never heard the expression before.

It's a rough grinding process using the face of a very large grinding wheel. The surface finish and flatness is way better than Cold Rolled plate, but it's nowhere near what you would get from surface grinding. If you zoom in on the picture, you can see the curved grinding witness marks.
I just ordered it from my Steel Stockholder, it's not outragously expensive. You can buy Aluminium plate ground the same way. It's a handy way to get large plate that's flat enough to use as finished without having to machine it.

[ettingtonliam]

Thanks for the information.

[Roger]

I'd somehow convinced myself that the X-axis needed reversing, whereas what had happened was I hadn't correctly copied the Post Processor to the workshop computer. Anyway, I can see how to do that now in case the need ever arises.

However, that still left the Mach4 complaining about the soft limit being exceeded on this G83 Peck Drill block and the G81 Drill block on the other program.

Originally, I thought the issue was that I shouldn't combine the Z-axis offset with the G83 Z value, but that was actually correct. What it didn't like was the R-1.289 command which isn't a Radius like it is everywhere else, but the absolute retract height. So this needs the Z offset added to it too.

Fortunately I'd already done the harder part, capturing what G-code is currently active and electing to change the R values only if it's on a drilling canned cycle.

Note, these are functions in my CNC Utility program, not the post processor.

Anyway, here's what the program looks like for the centre drilled hole in the centre of the cone with the G92 offset for T5 added...

(Appended G92s from T# offsets file)

O1001

(Drill2)

T4

G92X-289.87Y-125Z59.17

S1200 M3

G1 X0. Y0. Z8. F500

G1 Z3. F500

G81 X0. Y0. Z-1.6 R2.9 F5.

G80

Z8. F500

M30

... and this is what it looks like afterwards. You can see that both the Z and R values now have the offset added and they're absolute values.

You'll also notice that I've changed the Post Processor to output a G1 and an F500 feedrate instead of the G0 rapid move. This means it not only goes slower to the rapid position, but I can override it or pause it from the control. It's a lot less scary than having the machine zoom off when you're trying to do something carefully.

(G92 offset addition done)

(Appended G92s from T# offsets file)

O1001

(Drill2)

T4

S1200 M3

G1X-289.87 Y-125 Z67.17 F500

G1Z62.17 F500

G81X-289.87 Y-125 Z57.57 R62.07 F5.

G80

Z67.17 F500

M30

I'm sure most people wouldn't bother going to these lengths, but it makes the final program much clearer when you're single stepping and trying to set it up. I know from the Z values exactly how high the end of the stock will be above the tooling plate, so I can see if I want it to go there next.

So here's a tentative go on a piece of undersized 6mm stock to see if it's any good. Obviously it didn't clean up the whole profile, but the grooves look about right. They're slightly undersize, so I've made a small adjustment to the T1 offset in the ToolOffsetFile.txt to correct that.

I'll make the stock for the real thing with less overhang.

20210114_161758 by Roger Froud, on Flickr

Ideally I'd like to leave this set up so I can put it back later and get it set up quickly. However, the drills are very fragile, and it's going to get knocked where I have to keep it.

So I've 3D printed two of these protective covers that engage snugly with the ER32 collet nuts. The lugs are to stop it from tilting over if it gets bumped.

20210113_195130 by Roger Froud, on Flickr

I might print a little cover for these too, we'll see.

20210113_195113 by Roger Froud, on Flickr

Anyway, so far, so good, I haven't broken anything yet. However that may all change soon when I come to drill the hole!

Obviously I could have made all the cones I need in the time it's taken to figure all of this out, but that's not the point. I really enjoy these little diversions, and this is going to be so much more useful now it's easier to do.

Next up, making some cones!

[David]

Jan 14, 2021 9:34:29 GMT Roger said:

The comment was surprisingly easy to fix, even though I don't have a programmer's manual and I have no idea of what the language is.

The post processor is Javascript and the API scripts are Python. Weird they went with two languages but I assume it was for historical reasons. A Javascript interpreter that exposes an internal object model has been relatively easily embedded in apps for at least 20 years - I've done it once, and worked with another instance. So they would have had that in their CAM engine for years. Python is cooler than Javascript these days so I guess the F360 team decided to use it. One language would have made more sense to me though. You can also write the API "scripts" with C++, but I wouldn't bother.

Autodesk has all the API docs on line, and there is a post-processor developers guide PDF. It has some useful info, but to do what we're doing it doesn't help much. The functions are pretty self-evident.

[Roger]

Jan 14, 2021 21:56:41 GMT David said:

Jan 14, 2021 9:34:29 GMT Roger said:

The comment was surprisingly easy to fix, even though I don't have a programmer's manual and I have no idea of what the language is.

The post processor is Javascript and the API scripts are Python. Weird they went with two languages but I assume it was for historical reasons. A Javascript interpreter that exposes an internal object model has been relatively easily embedded in apps for at least 20 years - I've done it once, and worked with another instance. So they would have had that in their CAM engine for years. Python is cooler than Javascript these days so I guess the F360 team decided to use it. One language would have made more sense to me though. You can also write the API "scripts" with C++, but I wouldn't bother.

Autodesk has all the API docs on line, and there is a post-processor developers guide PDF. It has some useful info, but to do what we're doing it doesn't help much. The functions are pretty self-evident.

Ah, that's what it is. To be honest, I just wing it. Looking at what the code structure is like, you can second guess most of what you need. I've programmed in many languages, Algol, Visual Basic, Delphi (Pascal), Fortran, C and C++, but not Javascript or Python although I've taken a peek at Python. Unless you're programming all the time you'll never remember the syntax of any of them. Most of my programming has been in Assembler, starting with Motorola 6800, then Zilog Z80, Rockwell 6502 and Motorola 68000 as well as some in 8080, through to 80486.
I enjoy picking something up from time to time, but I wouldn't want to do any of it for a job any more. I do the odd embedded project with PIC or one of the ARM processors that Silicon Labs do, but I struggle to stay engaged with them these days. It just feels like I've been there too many times before and I don't need to go there again. So much of it is out of your control these days, you're a victim of whatever libraries and development environment you have to deal with. It was so much simpler years ago when it was just Assemblers and Linkers and maybe 'C'. Nowadays we squander the vast amounts of power in our computers because we've lost control of what's going on deep down at the processor level.

These days it seems that people need Linux, a screen, mouse and keyboard connected to a Pi or something, before they are capable of blinking a couple of LEDs. For choice, I like to stay close to the hardware.

[Roger]

Ok, that was nearly an accident... the way that Fusion360 deals with the G81 and G83 drilling clearance and retract heights is bizarre. It doesn't seem to make any sense unless you make those the same and referenced to the hole face. You can select them from a huge variety of reference levels, and it's more than happy to create a retract value that's -ve, plunging the drill straight into the surface at speed!
You'd think there would be a collision warning for something like that, but there isn't.

Anyway, being super cautious and trying it with the Quill retracted has saved breaking the drill and now I'm aware and have made notes on how to set the values it ought to be ok.

There's also a bug in Mach4, which means that if you have a G83 with an R- value, it doesn't respond properly to the Stop button. It stops the spindle, but carries on the Z movements until the full depth is reached! Nice!

Hopefully I'll actually nail this tomorrow.

[Roger]

This is the first one made with the 1/4" Brass bar to the correct dimensions. I've done three more, but run into difficulty with the tool getting stuck and pulling out of the holder. I've managed to pull the drill out with some difficulty, and that's setting again with hopefully a better bond. I've used Florist's wire to get some Loctite into the hole this time.

I'm concerned that this is going to happen again, so I've introduced a pilot drill that's 0.6mm and goes 7mm deep which will help with clearing the flutes on the through hole.

20210115_133451 by Roger Froud, on Flickr

[92220]

Hi Roger.

If you have a diamond file, just run it over the shank of the drill to roughen the outer surface SLIGHTLY so that there is somewhere for the Loctite to sit in while the drill is pushed in....even just in a few places across, will work. Use loctite 290, which is low viscosity, and just put a spot on the end of the drill shank to allow it to flow up as the drill is pushed in. That should then lock it into the shank. As long as there is at least a 0.001" thick layer of Loctite, it will hold. With sufficient clearance, just twisting the drill as it is inserted into the shank, should centre it well with a layer of Loctite all the way around.

Bob.

[Roger]

Jan 16, 2021 10:16:07 GMT 92220 said:

Hi Roger.

If you have a diamond file, just run it over the shank of the drill to roughen the outer surface SLIGHTLY so that there is somewhere for the Loctite to sit in while the drill is pushed in....even just in a few places across, will work. Use loctite 290, which is low viscosity, and just put a spot on the end of the drill shank to allow it to flow up as the drill is pushed in. That should then lock it into the shank. As long as there is at least a 0.001" thick layer of Loctite, it will hold. With sufficient clearance, just twisting the drill as it is inserted into the shank, should centre it well with a layer of Loctite all the way around.

Bob.

Thanks Bob, that's a great tip, I'll do that. The drill that got stuck in the work finally broke last night so I need to mount a new drill. Hopefully I won't break this one before the new ones I've just ordered arrive.

[Roger]

I've uploaded the video to YouTube instead of Flickr this time.

This is how far I got before breaking the drill, not too bad. You can see the one I had to heat up to pull the drill out from. I'm amazed it came out, it was properly stuck. Doubtless it didn't do it much good. Anyway, I got a few more out of it.

20210115_223054 by Roger Froud, on Flickr

[Roger]

It turns out that the #74 drill broke because the 0.6mm PCB drill broke in the hole before it. That sounded alarm bells because it wasn't that deep, and I thought it was worth going throught the whole setup from scratch to see where the problem was.

First up was moving the tooling plate out of the way to check the tramming of the head. I decided to set this all up with the quill locked to my scribed line on the handle when it was 50mm from the top. This is very close to where it will be when the job is running.

In that position, the clock was showing about 0.1mm between these two extreme positions...

20210116_124435 by Georgia Montgomery, on Flickr

... so it wasn't outrageously wrong.

20210116_124455 by Georgia Montgomery, on Flickr

However, it would be better if it was closer, so that's what I'm doing here, slackening the bolts and gently moving it with the giant lever.
I've found it to be a waste of time trying to use a mallet to move it, you just can't get a subtle enough control of the movement.

Anyway, that's within 10microns now, so that's better.

20210116_125418 by Georgia Montgomery, on Flickr

Then I've gone to each tool and clocked around it and updated the offsets in the ToolOffsetFile.txt and entered the new heights.

There was a significant error of around 0.1mm on the centres, and this it probably what was causing the issue with the deep drilling. That's further helped by pilot drilling the through hole to 6mm deep with a 0.75mm drill. I can't go any deeped without risking it touching the finished tapered bore. Still, it's 6mm less for the #74 drill to do, and it allows a bit more flexibility when the drill is buried up to its neck.

20210116_142302 by Georgia Montgomery, on Flickr

Obviously that's now messed up the centre of the turning tool too, so I've used the wobbler on that again and turned one to get a starting point for the OD. It's never going to be spot on for the first part, but it was within 25microns, so that's not bad.

As a side note, I spotted a slider for overriding the rapid traverse today. I had noticed it long ago, but had forgotten about it since I don't use rapids. However, the Peck drilling does use rapids, and this provides a handy way to calm it down a bit.

20210116_151223 by Georgia
Montgomery, on Flickr

There's quite a lot that could be done to speed this up, but frankly it's not worth the effort for the few I'm making. It's only taking about 12minutes from start to end. If I change the feedrates in the G-Code, they will get overwritten when I output from Fusion360 again.

I have figured out how to start the pecked holes away from the face though, so that I'm not drilling fresh air for the first minute or so.

Anyway, so far so good, I'm on the first part machined to size so hopefully that's resolved the problem.

I've got another 5 pieces of #74 drill coming in case I make a hash of it.

[David]

F360 has so many settings in the heights tab, and the descriptions are not that clear IMO. They also have some non-obvious interaction with the height setting for the stay down feature on the linking tab.

[Roger]

Ok, this has worked out just fine, I've now made twelve 'starter' cones for the initial batch of tests. All I need to do now is to decide that drill patterns I want to try and start making them.

Here's a video on YouTube for the 16 minute version I've ended up with which included the deep 0.75mm pilot drilled hole which gives the #74 drill a much easier time. I'm using pecks of just 0.25mm and have slowed the rapids down so it's not so hectic.

I've also made the gauge which has a reamed 6mm bore so I can check the fit of them. They all needed a slight touch with emery paper on the very end to remove burrs and a few microns that the end flange was oversize. 

Anyway, I think that's enough to be going on with. I'm just 3D printing some more dust and protection covers so I can take the tooling plate off and store it will the tools intact.

20210116_214720 by Georgia Montgomery, on Flickr

[Roger]

Jan 16, 2021 21:55:31 GMT David said:

F360 has so many settings in the heights tab, and the descriptions are not that clear IMO. They also have some non-obvious interaction with the height setting for the stay down feature on the linking tab.

Agreed, they simply don't make sense in my opinion. They also assume that your control will be able to make use of them, and mine certainly can't. There's a nice function in Peck Drilling where you can select an initial peck distance and have it reduce by a set amount, clipped to a minimum. You can also add a dwell. Neither of these things work in Mach4, and I suspect most other controllers.

What they really ought to do is to remove functions based on what post processor you select, but that's too user centric. They just take the easy option and throw in everything the most complex machine could do. In the end, you just find what works and ignore the controls that seem pointless or just don't do what you might reasonably expect them to do.

Frankly I don't think some the the height controls work as intended, it's pretty buggy in my opinion.

Anyway, I've managed to force it to give me a usable output, and I shouldn't complain since it hasn't cost me anything! Still, when you've written software for a living, it annoys you when you see a shoddy job that you know you could have done better.

[Roger]

I had planned to start machining the holes in a few of the cones today, but it was going to involve a lot of cutting and pasting of G-code to use the 4th axis. There will be many variants of this to explore, one being the type below which has three rows of holes, with the second row offset at a different starting angle.

So instead, I've modified the 3D model to allow quick and easy modifications to the position, number and angle of the holes. The changes are synchronised with the CAM output as far as the hole positions are concerned.

To make the output more flexible, I've added a new command for my 'CNC utility.exe' program to interpret that you can see on the three machining operations for this model in the LH pane. Adding the word ANGLEREP alerts the program that the next digit is the number of iterations required in 360 degrees. If there is a second keyword START, the following number is interpreted as the start angle.

4th axis CAM by Roger Froud, on Flickr

So for the above model, the raw output from Alibre CAM is as follows...

You can see that it's basically three single hole G81 drilling operations which is all you'd get if you used it as it is.

(Drill size 1)

(Combining vent row 1 ANGLEREP6)

(Tool Dia. 0.5 Corner radius 0.25)

T2

S1500M03

G01 X2.750 Y0.000 Z0.498 F1000.0

G81 X2.750 Y0.000 Z-3.250 R-0.800 F5.0

G80

G01 X2.750 Y0.000 Z0.498 F5.0

(Combining vent row 2 ANGLEREP6 START30)

G01 X3.900 Y0.000 Z0.498 F1000.0

G81 X3.900 Y0.000 Z-3.250 R-0.800 F5.0

G80

G01 X3.900 Y0.000 Z0.498 F5.0

(Delivery vent hole ANGLEREP8)

G01 X7.487 Y0.000 Z0.500 F1000.0

G81 X7.487 Y0.000 Z-3.000 R-1.150 F5.0

G80

G01 X7.487 Y0.000 Z0.500 F5.0

M5M30


However, after I've processed this by pressing a button in the CNC utility program, you get this output...

This was slightly more tricky to do than I expected, it's actually done in two passes. That's because you need to know ahead of time what all of the sub programs are so that you can create the first part of the G-code which is the calling part.

I've started with program number 1001, and you can see that it's calling that from angle 0 (A0) 6 times (L6)
The second sub program 1002 is starting at 30 degrees (A30) and again 6 times.
The third sub program 1003 is starting at 0 degrees (A0) but this time 8 times.

The sub programs are then output separately, with the appropriate top and tail with the measuring mode momentarily switch to incremental while the angular increment is done.

(4th axis commands done)

M90

A0

M98 P1001 L6

M90

A30

M98 P1002 L6

M90

A0

M98 P1003 L8

M5M30



(Drill size 1)

(Combining vent row 1 ANGLEREP6)



O1001

(Tool Dia. 0.5 Corner radius 0.25)

T2

S1500M03

G01 X2.750 Y0.000 Z0.498 F1000.0

G81 X2.750 Y0.000 Z-3.250 R-0.800 F5.0

G80

G01 X2.750 Y0.000 Z0.498 F5.0

G91

A60F10000

G90 F1

M99



(Combining vent row 2 ANGLEREP6 START30)



O1002

G01 X3.900 Y0.000 Z0.498 F1000.0

G81 X3.900 Y0.000 Z-3.250 R-0.800 F5.0

G80

G01 X3.900 Y0.000 Z0.498 F5.0

G91

A60F10000

G90 F1

M99



(Delivery vent hole ANGLEREP8)



O1003

G01 X7.487 Y0.000 Z0.500 F1000.0

G81 X7.487 Y0.000 Z-3.000 R-1.150 F5.0

G80

G01 X7.487 Y0.000 Z0.500 F5.0

G91

A45F10000

G90

M99



Anyway, I'll give it all a try shortly and then we can start to cut some metal. This will prove to be a very useful utility now I can quickly create programs for the 4th axis.

[andyhigham]

I was thinking about your set up for making these cones.
As you are using the mill with 4th axis to drill the radial holes, you could use the same set up to mill the OD and the grooves. Then transfer to the lathe to drill and ream the axial hole

[Roger]

Jan 17, 2021 20:30:24 GMT andyhigham said:

I was thinking about your set up for making these cones.
As you are using the mill with 4th axis to drill the radial holes, you could use the same set up to mill the OD and the grooves. Then transfer to the lathe to drill and ream the axial hole

You certainly could machine the grooves that way. The hole through the middle is time consuming though when done on the lathe because you have to be so careful not to forget how deep you've gone with each peck. Overshoot and you'll snap the drill. Doing that on the mill removes that danger when it's all set up. Ok, it takes about 16minutes to turn the OD and drill the through hole, but I can live with that.

Now it's set up, I can put it back and run some more off with only one trial cut to get the diameter right.

What I could really use is an ER32 collet in the 4th axis, I might sort that out shortly because that would be very useful.

Edit:- I've just ordered one of these ER32 square bodied chucks which woll solve the problem. I can clock this up in the 4-Jaw on the 4th axis and that will make repeat work much easier.

[David]

Jan 16, 2021 23:03:02 GMT Roger said:

Jan 16, 2021 21:55:31 GMT David said:

F360 has so many settings in the heights tab, and the descriptions are not that clear IMO. They also have some non-obvious interaction with the height setting for the stay down feature on the linking tab.

Agreed, they simply don't make sense in my opinion. They also assume that your control will be able to make use of them, and mine certainly can't. There's a nice function in Peck Drilling where you can select an initial peck distance and have it reduce by a set amount, clipped to a minimum. You can also add a dwell. Neither of these things work in Mach4, and I suspect most other controllers.

What they really ought to do is to remove functions based on what post processor you select, but that's too user centric. They just take the easy option and throw in everything the most complex machine could do. In the end, you just find what works and ignore the controls that seem pointless or just don't do what you might reasonably expect them to do.

Frankly I don't think some the the height controls work as intended, it's pretty buggy in my opinion.

I've sometimes thought the same, that the height settings are buggy, but I'm not sure. It's so complicated in the end I figure it was probably my mistake when something goes wrong. You do get some weird Z heights in the output though, especially when you use the stay down feature. While doing my mods to the post-processor I would put easily recognised values into the fields so I could calculate which combination of settings the final value came from. It was still confusing and didn't always make sense to me!

I'm not convinced they should limit the exposed settings based upon the target machine. The post-processor would have to be changed to support a call back where it can report what g-codes and options it supports for one. That would be tedious but doable.

Then you'd have the problem of a user choosing one target, setting the parameters, then choosing a different target that supported more or less parameters before generating the g-code. That's unlikely, but it is possible so would have to be handled.