Member postings for David Taylor

Thanks!

Hi,

I'm wondering what the type of the screw that holds the inserts into these tool shanks is.

It looks like a countersunk torx screw, is that correct? Anyone know the diameter and pitch?

Regards, David.

PathPilot requires you reference all axes before it will do anything else. So it wants to hit a limit switch on each axis so it knows where the table and head are.

Even the Y axis, which is not used in RapidTurn mode, must be referenced. Tormach leave the Y axis usable for checking the lathe head is perpendicular to the Z axis and centring the lathe head in that direction. Once you've done that, you leave it alone until next time you install the lathe head.

With the aid of a torch I had a look under the front splash guard on the table and found the limit switch is in the middle of the bed casting, with lugs at either end of the table. I had about another 10mm to go before the right lug tripped the switch, which exposed about 10mm of the dovetails and had the table a LONG way over to the left.

But it's finally happy so now I can go onto trying to remember how to set up the toolpost!

I've set PathPilot to RapidTurn mode and it all looks as I remember. I just can't remember it moving the table this way when referencing the Z axis.

I guess there's limit switches on both sides of the travel so perhaps I'm stopping it right before it hits the switch but it's pretty scary how far over it is and I don't want to damage the ball screw.

Hi,

I put my RapidTurn back on the PCNC 1100 today and when I went to reference the Z axis (what is usually the mill's X axis), the table went left, and just kept going.

When in milling mode, referencing the X axis makes the table move to the right.

Have I forgotten that this is how the RapidTurn mode works? The table did not look like it was going to stop so I hit the stop button myself.

I can get it to hit the limit switch going to the right.

Regards, David.

Thanks all!

Hi,

I'm having trouble understanding the track circuiting article from Beer Heights Light Railway.

I think relays work by having current flowing through a coil, moving the internal switch from one contact to another when it is energised.

I think the article saying that when no wheels are bridging the rails, current flows down one rail, through the relay - energising it - and back through the other rail. When a wheelset bridges the rails the current can flow more easily through that so doesn't reach the relay, which de-energises.

Now onto the current leakage through the sleepers and ballast. On a wet day more current can conduct through those, so less current reaches the relay - perhaps not enough to energise it, hence the variable resistor near the power source. More current must be allowed into the circuit in this case.

In the hysteresis paragraph it talks about the on/off voltages for the relay. I don't understand that bit. Is the relay energised based upon current flowing or voltage over it?

If I have the above wrong, can someone explain it in terms a 10 year old can understand?

Old-school BASIC did have significant problems that stopped anyone writing good code with it. The best you could do was code that worked and was as good as the language would allow. I'd say those problems have been greatly reduced now.

I recommended one of our users try out a MicroMite for talking to a small grain silo he has. He's already used an Arduino for a pneumatic gate system for sorting sheep so he's technically very capable, but I thought the MicoMite with it's more immediate programming model might be a nice change.

If my kids were at all interested in programming I'd probably get one. I think it's a great project.

But I still mourn the simplicity the old 80s micros had, hardware wise.

The range of languages available is driven by demand, not hardware compatibility. It can be as random as one guy decides to write an operating system kernel for fun which then goes on to run most of the world's computers so lots of people keep its implementation language alive (straight C) or another decides he wants to write a language and it get popular for some reason (Python). Java was one of the, these days, more rare industry driven examples of a language getting popular. Marketing, the interpreted write-one-run-anywhere feature, and the fact it was actually a mostly better C/C++ for application level coding meant it took off. It's largely considered the COBOL of the 21st century which I think is unfair. COBOL is still the COBOL of the 21st century anyway!

I'll start by emphasising I am a fan of Python, despite it having a lot of features I don't like, and I think it's an excellent language for modern programming idioms. I've been programming full time for money since I was 16, 36 years ago. I've written programs in C for Windows 3, devs tools in VB6(!), COBOL on various mini computers, lots of C/C++ on *NIX systems, a lot of Java, a lot of server-side stuff, distributed stuff, remote sensing, and embedded systems. I am hopeless at web programming and hate it with a passion. I'm nowhere near as good as I used to think I was, but I don't think I'm the worst programmer around. My first language was BASIC on the C64 and I don't think it hurt me

I understand structured code, but forcing structure at that level just seems petty and not something a language should be concerned with. If the code 'in the large' is badly structured, some local indenting rules are not going to help. It can be confusing for IDEs because if you're pasting code at the end of an indented block the IDE can't tell if the code should be part of the indented block or part of the next piece of code at the next level out. It also means you can have code in a block that you didn't mean to be there. Delimiters at the start and end of code blocks avoid these problems. It's the same reason I *always* use curly braces in C/C++ code, even for single line blocks - then you don't end up with problems of code being in the wrong block.

Some of the problems with Python:

• You don't need a 'main' but if you don't have one you might get unexpected results. So they should have just required it. It's nice a beginner can write a one line program to print something on the console but if that causes grief in the majority of cases then it's a dumb idea. Eg, when importing a module, any code outside of a function in that file is executed. I guess you can argue this is good for initialisation code but it just seems wrong to me - it's like a side-effect.
  
• Default argument values that are lists or maps are initialised *once*, when the function is first parsed, rather than taking that value every time the function is called. That's insane and completely unexpected behaviour IMO
  
• No real threading, and now, worse, the modern curse of 'async' code. As with JavaScript this only came about because the original implementation was as a toy language/quick hack with no thought of support for threads. And now programmers are starting to think this is normal and it's infecting languages that *do* have real threads. If you want a tight select() loop for I/O like in C, then just give support for that.
  
• Not requiring types for function arguments and returns. Argument names do *not* sufficiently describe their types, and the language is perfectly happy for you to give *no* indication of what a function returns, if anything. There is *optional* typing but it should be a thing you opt out of, not in to. Note that annotating types for functions the way it is done in Python does not force those types, it just tells the caller what to expect and what will work.
  
  

However, Python's strengths outweigh all of that. It has some awesome and powerful features these days, which as I said, I'm only just getting to grips with.

I completely disagree that Python is a child of BASIC and perl - I don't see any inherited traits from either! And no, I will not 'just use perl'. I have never willingly written a perl program, and only debugged them when there was no other choice

Finally, I hate C++! I think it started badly and only ever gets worse. Java was a much better effort at a better C, except it's not much good for low level coding.

So people can more easily tell me I'm wrong, my favourite languages are C, Python, and Java. I think C# has a lot going for it too and would probably choose it over Java these days if I knew it better. Swift looks pretty good too.

I would replace C in a second with a better low level language. Rust, zig, and mojo are all languages I'd be happy to take on if I was paid to learn and use them.

C was not designed for large code bases, it was designed more like a very fancy macro-assembler. It has innumerable faults that have cost untold amounts of money. It's linkage system is painful and you get two choices - the symbol is global (even if not accessible, it still causes name clashes) or it's private to that compilation unit. The preprocessor is not a feature, it's a bug and is increasingly seen as such. C is actually a pretty nasty language where you need to be exceedingly careful not to stuff up but sometimes it's the only thing that will do the job. Luckily, nearly 50 years of C has exposed it's faults and allows newer languages to try to avoid them. Rust is catching up quickly, even for embedded programming. I don't know what caused the great C explosion in the 80s, or why something more suited to high level programming didn't take off instead. But for code heads like me, C still has a weird attraction.

For the recreational coders out there, the annual Advent of Code challenge is a great way to get into a new language. We used it at work to all get into something different and as a good morning conversation topic.

An interesting thread!

I wouldn't take office at Dijkstra. He knew what he was about but loved trolling.

The chip powering the CMM2 is quite a beast. Putting a quick booting BASIC on there might give some flavour of the retro experience but given it's a system-on-a-chip I feel the fun of learning and being able to understand the computer at a hardware level, like you could an 80s micro, will be missing.

Unfortunately I don't think you can get that experience now - even 8-bit retro kits don't have to cool sound and video ICs we used to have in our 6502/Z80/68000 micros and stop at a serial terminal or perhaps an FPGA VGA generator.

FWIW, I hate Python's significant indentation idea. I also take exception to the idea it's a great beginner's language. It's the most complicated language I know. I like it, and it's powerful, but it's *not* simple. It also seems to still have numerous ways to shoot yourself in the foot left over from when it was one guy's plaything. I've been using it for about 2 years full time and feel I've barely scratched the surface of what it offers.

I'm not sure I agree C is a good language for large code bases, despite the fact there are many large C code bases. Its preprocessor and simplistic include file system would not be tolerated in any modern language - most of which have tried to learn from the pain C inflicts in this regard!

I had the same pattern happen on a small handrail bracket for a 5" gauge tender. The bracket was steel, and I left it in the acid overnight by mistake.

It came out looking just like that but on a much smaller scale.

I had a look at an open source add-in https://github.com/TimPaterson/Fusion360-Batch-Post and regarding the rapids it seems to do a post-post-process - ie loads and analyses the post processed g-code.

I decided to have a look at the Tormach milling post-processor and have added a simple patch to put at least some of the rapid Z moves back. It seems F360 milling toolpaths often start with a rapid X/Y move, followed by two rapid Z moves, then goes into the cutting. So if my patch sees a Z move that goes to above 0 (ie above the stock when the top of stock = 0) it emits a G0 rather than G1.

This restores rapids to the start and end of a toolpath, and also on the way up after a cutting pass when doing multiple depths.

This might not go well for you if you don't have +Z above your stock, or don't get toolpaths similar mine!

function onLinear(_x, _y, _z, feed) {
  // existing post-processor code
  var x = xOutput.format(_x);
  var y = yOutput.format(_y);
  var z = zOutput.format(_z);
  var f = feedOutput.format(feed);

  // use rapids for Z movement to Z > 0 and no X/Y
  if (_z > 0 && ! (x || y)) {
    writeBlock(gMotionModal.format(0), x, y, z, "(Assumed rapid)";
    feedOutput.reset();
    return;
  }

  // existing post-processor code
  if (x || y || z) {
    ...

Edited By David Taylor on 01/12/2020 03:53:26

Edited By David Taylor on 01/12/2020 03:54:00

I used to what Why Is It So when I was a kid

He did chocolate commercials too. He was pretty popular down here.

luckygen1001 seems to be quite good at casting.

ActiveAtom is a pair of guys who are precision machinists. They're workshop is more clean and tidy than anywhere I've ever lived.

Bad Obsession Motorsport are a couple of English guys who build cars.

Edge Precision does high precision CNC work.

Keith Fenner has a lot of traditional machining and fitting etc.

Machine Thinking is an interesting engineering history channel.

SS Workshop is building an unusual loco he's designed from full size plans. I'm guessing he's stopped making videos because he didn't get the views to warrant the time and effort but what he has is pretty impressive.

Tips from a shipwright is good for one boat, but might get repetitive.

xynudu is ok, but has pretty well turned into a sponsored review channel for the usual suspect.

No, it still says hobby license. I thought if I logged out and back in it might refresh, but no. So the website didn't complain when I applied and says I was upgraded but it doesn't seem to have stuck.

I'll check out that aircraft club offer and see if I can do that. I don't care if I lose all my current work in F360 if I can get a good deal on something else. All my jobs except a safety valve design are one-offs anyway.

I might pay $500AU for F360 if it was a one-off cost for hobby use, but I'm not paying that every year when I only use the machine a few times a year for one-offs.

As I went back to uni this year I tried this. I signed out, restarted F360, and it still has all the limitations. I use my Tormach once every few months so didn't notice anything until today when it refused to write out tool changes or do rapid moves.

There goes my 4th axis altogether and the RapidTurn with any reasonable speed of tool movement.

I guess I can manually edit the G code to try and work around the rapids.

I've always had the same problem on my RF-45 clone. Perhaps because I only tighten up the right-hand screw on the X axis or the front screw on the Y axis the table skews and the non-locked dovetails are rubbing.

One thing I've learned the hard way is to look at the movements of the tool during the sim and in the toolpath. Some yellow lines (Fusion360 specific) can be easy to miss and a tool might go tearing straight through a stud or clamp in the middle of the stock when you didn't think it would because it was just cutting around the outside.

I usually make the clearance heights a bit low to save on head movements, but obviously it's called clearance for a reason! Plus of course you can model your studs and fixtures etc.

As for writing g-code I was also put off by all the articles that went though manually coding parts, not to mention the cost. But in 8 months I've not written a line of g-code, and only altered them a few times.

This is an amazing project John. The forethought in the design is something else.

The reason I stopped my subscription to ME some years ago was it seemed to be filled with 'out and about' type articles and reprints of some LBSC loco series.

I think it would be better to have those that ME has the copyright for reprinted in a book so those that want them can buy the book. I might even do so in that case.

But I was put off by them in the magazine for some reason.