Attempting control upgrade on my Novakon CNC mill

[kvom]

After 7 years with Mach3, I decided to follow a number of other who've elected to convert to Tormach's PathPilot.  For those with newer machines than mine, the conversion could be easier.   On mine, the machine control by Mach3 involves manipulating  pins on a parallel port.  And all the pin signalling is done by the motherboard under interrupt control in Windows.  That means that my highest speed moves are limited to 75 ipm, and the tool motion can lack smoothness.

Under PathPilot, all the pin manipulation is done by a general purpose IO card produced by Mesa electronics.  Windows is replaced by Linux running a version of LinuxCNC, and the PathPilot application is built on top of that.  When running, Pathpilot signals the GPIO card to send its pin signals out a DB25 connection to the existing breakout board and thence to the Gecko motor drivers.  After a few days work trying to get PathPilot configured properly, I've gotten the XYZ axes calibrated and can run X and Y easily at 125 IPM without losing steps.  This rate is still pretty conservative, but I need to get more comfortable with it going any higher.

Thus far, the only problem I'm stuck on is controlling the spindle speed from PathPilot.  The spindle want to run at 4K RPM regardless of the commanded speed.   

My test setup looks like this:



Cover is off the current control while the PathPilot computer sits on top so I can see the LEDs on the breakout board.

[Art K]

Kvom,
I am also in the process of switching over to PathPilot on my Tormach, although I'm not using the tormach cpu. about all that is working properly is the rpm and the manual move xyza. doesnt even shut off the computer. Guess I'm not linux edumacated enough.
Art

[steamer]

Kvom    you're going to like Pathpilot.

Been using it for a cm couple of weeks   it's alright!

[Vixen]

Hi Kvom,

I am also working towards converting my Austrian built Emco F1 to run on Pathpilot, currently it works great on LinuxCNC.

I have got to the point that it almost works ( heard that before?). Unfortunately the real time display is very slow and lags behind the movement. I suspect my PC is not fast enough to run Pathpilot, however it will run the simpler LinuxCNC.

May I ask the clock speed of your PC? That may help me understand my Pathpilot problems.

Cheers

Mike

[kvom]

I had a new computer built to run it.  I picked the cheapest components I could.  Motherboard is a MSI B250M and uses 2400MHz memory chips.  Pentium CPU chip.  Bootup time for PP is less than a minute.

I made some progress on controlling spindle speed, but it's still not completely correct.  Peter from Mesa has been contributing suggestions.    I hooked up the 4th axis to try to calibrate it and have no movement; just a cryptic error msg.

[Vixen]

Hi Kvom,

That looks to be a nice fast motherboard, it all depends what Pentium CPU they fitted. I quess it will be the fastest available.

Have you looked at the LinuxCNC forum. The have a whole section on getting Pathpilot to run on non-Tormach machines.

https://forum.linuxcnc.org/pathpilot

Thanks

Mike

[kvom]

I haven't seen that section as yet but will check it out.

Today I fixed a config error on the Z-axis reference plus calibrated the A axis.  I'm running the A at a very slow maximum velocity, so will see how fast I can up it before it loses steps.

As of now, spindle control is my only known problem..

[Vixen]

Hi Kvom
'
I have never understood the need for hobbyists to do 'rapid' moves at the speed of light. I set my rapid between 20 and 30 inches per minute. That's fast enough for me and well within my reaction time to stop the cutter crashing into the bed or the work clamps, if the new program is not quite right.

It would be a different matter if I were mass producing a thousand identical parts each day Then ''time is money', in hobby machining 'mistakes is money'

Cheers

Mike

[kvom]

Mike,

The rapids are nice to have in certain situations, but I think secondary to some other benefits.  I have been using some trochoidal toolpaths recently that have a lot of rapid moves;  in addition if I run an operation cutting air the first time through it's convenient to be able to cut the time to finish down.

I won't know if PP is significantly better in other ways until I actually cut some metal.  I do like the way the jog buttons are laid out on the main screen vs. the popup window in Mach.

One thing so far that I don't like is needed to ref the axes on startup before executing g-code.  With mach3 I can save my origin and shut down the machine, not needing to reference again on startup.

[Vixen]

Hi Kvom

The Pathpilot interface is suposed to be more machinist orientated than LinuxCNC (it's a bit software geeky). They both do exactly the same thing using the same core software. Where PP is supposed to score is in the work flow through. The machine control,  popups and program editing functions are more logically laid out from a machinist perspective and require less mouse clicks or button presses with PP.

the LinuxCNC and PP startups are the same. Like you, I did not like the need to reference on startup, so I disabled the reference and end stop functions. I also declared the various axes to be twice as long as they actually are to avoid the soft stops. The onus is on me to avoid crashing into the hard end stops. The origins are reset to zero every time the machine is started, so I take care to park the axes at zero, zero, zero before switching off. Not tried to do this in PP yet. I think I need a faster PC to get PP running correctly

Mike

[kvom]

One problem solved.  For the each axis config in the INI file I set the HOME value to 0 (so referencing doesn't move the axis, and I set MIN_LIMIT to -n and Max_LIMIT to n, where n is the amount the table can move along that axis.  Now the soft limits are set beyond the ends of the table no matter where the table is at startup when I reference.

[Vixen]

That's almost exactly what I had to do with Linux CNC.using the Stepwizard configuration tool
Just shows how similar they are

Mike

[kvom]

A difference between PP and Mach3 is that under PP I cannot jog to zero Z while stopped for a tool change.  In fact, once a program is running no jogging when stopped or paused whatsoever.  So it appears I'll need to break up my g-code programs, one file for each tool.

[Vixen]

Hello Kvom

It will be no surprise to you, that it is the same with LinuxCNC. One file per tool.

Mike

[Dave Otto]

In Mach 3 there is a tool change macro? that when M6Txx is called the mill moves to a programmed tool change position, (no jogging around necessary) after the new tool is installed cycle start is pressed and the program continues. I'm using Mach Standard Mill screen set but think it work the same in the stock program as well. I have run programs that use 8 or 9 different tools, one of the operations on the American 4 post oilers comes to mind.
That has got to be a royal pain having to post out a separate program for each tool.

Dave

[Vixen]

Hello Kvom and Dave

I am sorry, but I think I may have misled you.

Both LinuxCNC and PP can handle tool changes mid program. First, you need a tool length probe to measure the length of each tool. You use the probe to make a tool library with each tool having a unique tool number and tool length. You call off the required tool from the tool library within your multi tool change program.

I do not have a tool length probe, so I always have one file per tool. The way I work does not usually require tool changes.

You were quite correct in saying it is not possible to jog a tool after you have started to execute a file.

Cheers

Mike

[kvom]

I have an R8 spindle, so the only way to use tool length offsets is to have a lot of TTS collets.  Since i use a lot of different tools it's not very practical.  Assuming I had a few such collets I'd need to measure each one with a tool setter of some sort prior to running the file.  Even TTS collets wouldn't help with number drills.

In reality CamBam makes it easy to create separate files for each tool, so other than keeping track it will probably not be a killer problem.

Getting closer to a spindle solution.  I have a set of stepgen parameters that run the spindle reliably between 100 and 4000 RPMs.  Unfortunately the S values for this range are 100-555.  I have a few more things to try including using the lincurve routine to map commanded to actual.

[tvoght]

I do use the TTS tooling system and I'm pretty happy mounting each new tool in its own TTS holder.

Tool 1 in my table is a reference tool (a length of ground rod in holder number 1).

Each time I add a new tool, I first zero Z at the spot where I can just roll an endmill shank across the machine table under the reference tool.  I then mount the new tool and adjust Z until the endmill shank just rolls under the new tool. The difference in Z is entered into LinuxCNC's tool table entry for the new tool.

Before running a program, The reference tool is touched off to zero Z.  Tool length compensation is enabled in the program

For each tool change, a rapid to a safe tool change position is programmed, followed by an M6 tool change command. which (at least when using the AXIS Gui) stops the spindle and pops up a window telling me to change to the appropriate tool and click continue. no touching off is required at tool change time.

Even when running a file per tool, I use this method, because I only have to do a single touch off of the reference before beginning all the runs.

It's true that it's not practical to maintain drill bits in the tool table, but I'm happy enough touching those off individually and using separate runs.

--Tim

[Dave Otto]

I too use TTS holders in my converted knee mill, I have collected enough of them to do most anything that I need. But they're always coming out with something new and interesting. Kirk I not sure what you mean by "even TTS collets wouldn't help with number drills"? I run all my drills in ER collets; my mill has a little less than 5" of travel on the quill so you need to try to keep everything about the same length, so I don't use drill chucks much anymore.

I set all my tools to the top of the stock or theoretical top of stock using gage blocks. Different than what I do at work but I get by OK with it. After  I set all my tools for the job, then use the last tool to set the Z fixture offset.

My mill software at work allows me to mass modify the tool lengths of all the tools in the carousel at once. This comes in really handy when you want to shift everything up or down. I can set tools on the fixture plate which is bolted to my table. If I put the vise on top of the fixture plate I just shift all the tools up to the bed of the vise, or that plus the thickness of my paralells. Then I can set my G54 Z offset to the desired thickness of my part and I'm good to go.

Dave

[steamer]

With the Tormach, and the PP software, I just rezero the Z to the top of the work, and  PP takes it from there.

It's been working great for me thus far....and I'm making some really tiny parts as of late.

Dave

[kvom]

Something that could be a workaround.  Hit Stop at a tool change, which rewinds the file.  Jog to zero the next tool and then use the 'Run From Here' feature to skip to the M6 command before restarting.  I'll give that a try today.

[Vixen]

Hi Kvom,

That will work for sure, it's similar to the way I do things. That 'Run from' function is very useful I use it for all sorts of things.

It may be a good idea to edit your file with some extra notes to remind you of what tool to install next.

Mike

[kvom]

Cambam allows a label on the Mop that becomes a g-code comment and also generates a comment about the tool diameter specified.

[Dave Otto]

Something that could be a workaround.  Hit Stop at a tool change, which rewinds the file.  Jog to zero the next tool and then use the 'Run From Here' feature to skip to the M6 command before restarting.  I'll give that a try today.

Why not edit out the M6 command before you ever run the program, if you are only using one tool it is not necessary?

[kvom]

Cambam generates an initial M6 even for a single tool.  Under Mach3 it's just an extra click, and as well it's a reminder of what tool should be mounted.

I did notice one interesting fact as well.  If I add a '(' to the first gcode line of a Mop and a ')' at the end, it comments out the entire Mop.  That's easier than deleting the code, which has been my habit when I need to make a correction in a subsequent Mop and then rerun.  Probably better than run from here.

In any case I have found reasonable settings for the spindle stepper that at least generates motion from S100 to S4000.  I have coded up a HAL fix using the lincurve routine to give a more linear match between the S value and the actual resulting RPMs.  If that works I'll call it done and use PP for the next milling job.

[Vixen]

Hi Kvom,

That's good news that you have PP up and running on your non-tormach machine. I am very pleased for you.

It shows that under the skin PP is 100% LinuxCNC and that you can manipulate the HAL and INI files in the same way, to make fine adjustments to the set-up.

I have still not yet got my PP installation to work fully. The graphic display is slow and lags behind the actual stepper movement. I suspect my PC is too slow.

I wish I could find out  the true minimum processor speed necessary to run PP. Can anyone help?

Cheers
Mike   

[Jo]

I wish I could find out  the true minimum processor speed necessary to run PP. Can anyone help?

We have this problem all the time with virtualisation: It is very difficult to state metrics for computing power for any application: They can quote if you have X manufacturer's processor to this build standard (internal architecture on the silicon) of this version of bios, with this amount of defined memory of speed/architecture, running this version of a specific operating system it will work so long as you have no other stuff on the processor, running on the network, have a hard disc of specifics etc, etc. and you never look to update the software and they may wish to define a specific file size for the application to be running for the purpose of the metric..

This is clearly not possible and people would complain about that too as they would not be able to buy that specific build anyway so it is rather pointless  ..... so rule of thumb is an application provider over quote the requirements.

Jo

[Vixen]

I wish I could find out  the true minimum processor speed necessary to run PP. Can anyone help?

... so rule of thumb is an application provider over quote the requirements.

Jo

I take your point, but we are not working to a mil spec budget or methodology.

All I am asking is 'what works for the folks out there'. Who has run PP successfully and how fast was their PC?

Mike

[kvom]

One thing to consider is that much of the work done in the CPU under Mach3 is now done by the Mesa card.   It may well be that it's your video card that is the problem (or the video processor on the motherboard).

[Art K]

Mike,
I may be able to help you with the minimum system requirements. But will have to hunt it up after work.
Art

[Vixen]

Hi Kvom and Art

You may have a good point there regarding the Mesa card.

According to their documentation, the minimum requirement for LinuxCNC is only a slow a 0.4Ghz PC.

I am currently running LinuxCNC (the latest v 2.7 issue) on a 1.8Ghz PC with on-board video. I interface with the mill through the Paralleled Port. There is no Mesa card fitted. This arrangement has been working perfectly for the last four years. I conclude that the Mesa card is not essential to LinuxCNC.

Kvom have shown that PP is only a different GUI over the top of LinuxCNC. So I expected what works for LinuxCNC would also work for PP.

I understand the Tormach ship their systems with 2.4 Ghz PC's and a Mesa card. I am unsure if PP NEEDS a 2.4 Ghz PC, or if that speed is the standard speed for PC's in market place these days. I understand the Mesa card to be only acting as a buffer for the analog and digital signals and not adding processing power.

I have followed the instructions on the LinuxCNC forum to modify the PP software to operate with the Parallel Port instead of the Mesa card. As I say, it sort of works but the display is slow.

So, in truth,  I do not  know if my problem is with the speed of the PC or with the changes made to the PP software. I was trying to nail down the PC speed question first.

Thanks

Mike

[dieselpilot]

LinuxCNC is picky about graphics and mainboard chipsets and such. Everything in the PC changes realtime performance. If you go through the normal PC testing procedure you will find various things that are bogging the system. I've been running a mill on a Optiplex PIII 900Mhz for 8+ years, before that the same machine ran on a PIII 500. The Optiplex needed a separate video card to run well. Newer versions of Linux require a bit more power. I have a newer HP DC8000 SFF that runs excellent after a few tweaks and will eventually be used for a new system. Multiple cores and outrageous graphics cards don't necessarily mean a good Linuxcnc setup.

The stability of the PC is much less of a concern when a Mesa card is used. System performance comes into play when using parport stepping as realtime performance limits axis frequencies.

[kvom]

If you're running LinuxCNC via a parallel port anything I've contributed is moot.

[kvom]

I installed my latest version of the files, and now have a quite linear speed control of the spindle.  So I have buttoned it all up and am calling the conversion complete.