Member postings for Joseph Noci 1

Nick Popich, well known member of the Rand Society of Model Engineers in South Africa, passed yesterday aged 91. Perhaps some of the members on this forum knew him - he was a most Talented person and did amazing work.

Some of his early work here:

SAR 16DA

He will be missed!

Joe

Sloowww progress, but at least it is progress.

The Polar interpolation is working well - I have not machined anything so yet, but with a sheet of aluminium centered on a shaft in the chuck and a sheet of paper glued to it, pen in the tool holder, I am drawing very respectable squares,hexes, etc on the paper.

issues to contend with now are re-homing the C axis when exiting the polar modes, etc, but those are minor and fairly simple.

However, I am frustrated now by what I thought was resolved and simple!

I am having a lot of trouble with tool offsets sometimes violating machine limits. This issue is specific to Linuxcnc, so general tool offset management and definition processes for Fanuc, etc, won't help...

Is there anyone who has a lathe running Linuxcnc who can chip in and help me understand the tool offsets procedure please...!?

I guess a small toggle switch in series with the stepper drive enable signal ( they all have this signal..) is just as easy to activate, if not more so, than a lever/pins, etc for a clutch action, and a lot easier to implement mechanically.

The issue of back driving the stepper - I did cover this with an analysis on some previous post on the subject, but the posts get lost in time so quickly..

There is NO down side to backdriving other than if the stepper is a powerful one you may feel a slight notchiness at the handwheel.

All half decent stepper driver will have back-emf diodes at the switching devices, and if FET's these are inherent in the FET. In addition, the back emf will never exceed what is seen under driven conditions, since the generator action back emf is the same as that seen while the stepper is driven as well - it is a permanent magnet motor/generator..Most stepper drivers are rated from at least 24volts, most 4 to 6 amp drivers at 40 to 50 volts - spin a poweful stepper at 200rpm and see what voltage you get, even off load - you will be hard pressed to reach 50volts rms...And when 'spinning' the mill table handwheel, the stepper rpm will never reach 200rpm...

That myth needs to be put to bed..

Joe

You have a very nice Mill in the FB2 - some don't like it because of the round column, which at full Z extension does exhibit some lack of rigidity if milling heavily, such as with the Shell end mill. However, don't let that put you off - that machine is VERY capable - I have done a lot of work on mine ( I have 3....) that may have been thought not practical. It is an accurate machine when set up sweetly, and stays set with very smooth slide action. It is very well made. Enjoy it! Did you obtain just the machine or some tooling/accessories as well?

Joe

Sorry, no..I live in Namibia so cannot help I fear.. Sure someone from your region can advise. The capacitor value is on the body of the capacitor - the capacitor is in the base of the mill - you need to remove the cover on the right hand side of the base , 6 screws, 3 top and 3 bottom. Unplug from the mains before doing so! The capacitor fastens to that side cover.

Joe

Is this the Single phase FB2?

So when the left speed selector is in the left position (S) the three speeds selected by the right selector (I,II,III) are higher than the speeds when the left selector is to the right (H) ?

That cannot be....Even if the gearbox was dis-assembled and reassembled 'incorrectly', it is not possible to transpose the low / high range select gear to make it do that!

I suspect that this is a single phase motor, and suspect the running capacitor is dead - gone low capacitance.

The fact that in high gear you can stall it by hand reinforces my belief. I believe this is also the cause of the 'low speed in high gear' - in low range the reduced motor torque ( due to the dud Capacitor) is still enough to run through the gearbox and drive the spindle near true speed. The high range load is to much for the motor - it has not got enough torque, and so does not achieve the correct speed.

Change the Capacitor..

Joe

Been some progress on the Polar Interpolation. The Polar Interpolation software is working well and tested with a simulator to verify the math. In fact, the math, and the software turns out about 20 lines of code, so very simple.

The big issue is in the integration with Linuxcnc itself - and this is in line with the usual Linuxcnc pains...

Switching from 'trivial-kinematics' (essentially cartesian kinematics, with arc's) to 'Polar-kinematics' (with G12.1 g-code - which we had to create and make Linuxnc believe it exists..) is not simple. Since the last axis position before G12.1 was a 'cartesian' one - with a relationship to the machine coordinate zero, and to the work coordinates zero, with tool offsets, when we enter the polar mode, we have to convert that position to a polar one, with the tool remaining in irs current position - so, forward and reverse kinematics, and right now it does not work because linuxcnc is rather convoluted in the way one has access to parameters related to all the machine and work coordinates.

This project was all about the challenge of the mechanics, never about the software - Boy, was I wrong!

I decided against the Chinese 'GSKxxx' type controls - scares me a little since when I ( and I will..) find some issue that the controller does not do, improper polar modes, or any thing even very small, there is nothing I can do about it...At least with Linuxcnc I can fool myself into the belief that I can make it work, even if it's now good time after bad!

Joe

Edited By Joseph Noci 1 on 05/10/2021 07:23:20

If you have not seen the video clip by AlJazeera - The Dark side of Green Energy - try to find it - maybe here -

Green Energy down Side

The resulting huge increase in manufacture of parts/items requiring use of heavy metals and other exotics ( Iridium, Barium, Neodymium, etc) results in the massive mining of these elements raw materials. The majority of these raw materials are found in world size quantities in non- first world countries - Chilli is the biggest copper producer with a 'hole' 7 x 5km, 500meters deep and a disastrous surrounding area from a wasteland, pollution and contamination point of view, all seeping into the groundwater. Copper mass will increase from 12kg in a typical IC engined car to 50 to 70kg in an 'E' car. The motors magnets will require around 22kg of magnets - from a heavy metal base. It is quoted that all copper production over the last 300 years will have to be repeated again, but this time within 30 years...

China has the largest Heavy metal mines in the world - that video shows the unbelievable disaster developing around those mines - Huge lakes formed from the mining sludge pumped out over open land - sludge containing all the heavy metal residues, acids used in the extraction process, etc. And they are not alone in there production methods - Waste management in all these places cuts into profits...

So the First world sits comfortable on there podium touting how green they are and saving the world...

The ONLY way out of this mess is for people to suffer so badly that we eventually have no choice but to buy less, use less, discard less, want less, fly less...

Edited By Joseph Noci 1 on 03/10/2021 20:43:25

Well....

I clicked on the link you gave and abt half way down is a table of supported G codes, and G12.1 et-al is missing so looked no further. After what you posted I downloaded the whole manual and it is as you say!

I need to dig some more - $3K is a lot of money, but if its not good money after bad, may just be my way out!

Thanks for this info!

Joe

Get the GSK980TDc manual here.

Nope, No G12.1, G13.1 nor G112 / G113, so can't do!

And thats the story of my life..

Joe

Sent a request for the supported Gcode list - lets see!

Joe

The method chosen by the PolarBear designer is to post-convert a standard, non-polar Gcode file into cartesian and angular segments. That is as we discussed in our posts. To expand on the downside - A polar interpolation kinematic would interpret the polat Gcode commands and generate output 'commands' ( step pulses, ie, the smallest resolution increment possible on a given machine) driving the axes along the cut path. To obtain that same resolution ( which you DO need if you look carefully at the hyperbolic path motion for our square in the C axis) in a post-processed Gcode file would mean thousands, maybe 10's of, Gcode lines converting Polar to small coordinated X and Caxis moves. In addition, the surface finish suffers because the feed rate cannot be properly interpolated down to individual Gcode moves, and so impossible to maintain any constant feed rate or material removal rate.

In the standard Caxis/Xaxis G12.1 interpolation, feed rate is normaly inverse time as well, which gives constant cutting edge feed, while the Caxis motion rate can vary hyperbolically

See what Polarbear says..

I had to develop a postprocessor for g-codes:

**LINK**

This postprocessor imitates the polar movements that would be run by a cartesian controller. This works great too. But it is not efficient. It generates twice or more g-codes and it cannot run the machine at efficient feed rates. Even if we calculate the best feed rates, the firmware will treat the movements as cartesian and recalculate the decelerations and accelerations, which would be wrong for polar motions.

Therefore, without special firmware for polar and cross slide motion, the machine often runs at inefficient feed rates.

My brain is so wrapped around this C axis at the moment...head spinning.

Difficult for me to explain - I lack the correct terms and the appropriate math insight!

The Gcode G02 X Y I J allows the mill to generate in interpolated ARC in the XY plane.This will cat an arc in the material at the appropriate position.

If that Gcode is preceded by G17, the ARC is in the XY plane, by G18, the arc will lie in the XZ plane, etc.

Similarly G02 X Z I K generates an interpolated arc on a lathe in XZ plane, but that arc is an XZ move, such as an arc on the end of a shaft in the chuck.

If you use a rotary axis in the mill, and constrain the Y axis (as in a lathe) , the lost Y axis has to be wrapped around the A axis and you would have to use a Gcode along these lines

G02 X A(angle) I J - this is then POLAR interpolated from Y to A to generated that curve. If you machine does not have that interpolater mode it will not work. J is for XY plane

Polar interpolation on the lathe is similar, but 'not quite' - 

For example here is the basic code to mill a 40mmx40mm square on the end of a shaft:

G12.1
G42 G0 X60. Z-5. C0. F.(feedrate)  # this line is the initial; position of X and Z ( and C = Y )
G01 X40.
C20.
X-40.
C-20.
X40.
C0.
G40 X60.
G13.1
G0 Z10. M05

The C axis is not given in angles or arcs - you treat it like a Y axis, cartesian position.

So read that file with Y instead of C, for a milling machine and it is basic XY move from corner to corner.

But the G12.1 Polar mode causes the controller to convert the 'Y' position to a set of cordianted C axis and X moves...

Joe

Edited By Joseph Noci 1 on 27/09/2021 21:42:25

Edited By Joseph Noci 1 on 27/09/2021 21:42:50

Michael, that paper is exactly the issue and the guts of that paper is precisely the core of what I would need to implement, Unfortunately, as with most papers, they provide the gravy and very little, if any, meat! However, its not really to complex, especially if I limit the function to basics. We will see...

Interesting paper though - positioning accuracies of 6um, etc...!

Joe

Edited By Joseph Noci 1 on 27/09/2021 20:41:55

Yes, they do. Centroid was my first port of call, with a near_purchase...It does implement a C axis and was told it would do what I want, but turns out that was not so - It does exactly what my LCNC setup as at present does - NO Polar Interpolation, no G12.1/G13.1. As with mine, it can only do C axis Indexing and coordinated moves. So you can drill holes on the face of a part at any angle, using the live spindle, etc, but no polar stuff..I searched for a controller or software to do this...Considering the pain en-route to what I have, I would have happily paid $3K for an of-the shelf option!

Joe

Hi John,

Here is where one has to get you mind wrapped around the issue ( or the axis)...Also why I am only discovering the issue now, since as I mentioned before, you really only learn when you need to, not in passing..!

Anyway - The motion you speak of is essentially still just linear.

In other words, when you issue G01 X10.00 A10.00the two axes will move to 10mm and 10deg coordinated. So when A has move 1deg, X has moved 1mm, etc. The two axes will accelerated together, travel together and both decel to the 10mm/10deg finish line together. That's coordinated, not interpolated in the true sense.

This works identically in the C axis lathe - A G01 X10 C10.00 will do as your mill did.

Now Imagine cutting a square head on the end of a shaft in a Caxis/live tool lathe - It is educational to visualise the actual C axis / X axis movement relationships in travel as the path is cut - the path is non-linear, sort of Hyperbolic.

If the CAM packagedid the interpolation and then generated Gcode that was simple coordinated 'linear' moves, ie, many short G01 Xxx Cyy moves, then each move would be coordinated and the actual cut path alone one side of the square would be done by hundreds of such G01 moves - Caxis would rotate a tiny bit and X would likewise move a tiny bit, etc.

But CAM packages that are capable of C axis/live tool lathe camming tend NOT to generate such piece-wise code - they use 'interpolated modes' - They issue a G12.1 (or similar) which places the controller in polar mode. Then the issues Gcode are a specific notation of X and C axis moves, which if the G12.1 were not active, would make the two axes simply move in coordinated motion as the examples above - the path followed would not be along the side of the square at all! The G12.1 makes the controller looks at the X/C move command and do a linear to polar conversion to establish the path, and back to cartesian coordinates to then move each axis in normal coordinated mode, in very tiny increments, many thousands, compared to the hundred in the example above.

A long story...!

Hope that explains a little?

Hi Martin. Unfortunately , not really.. G16 initiates Polar mode but in XY plain, and so intended mainly for XYZ axis machines such a mills. What G12.1 does on a Polar modes equipped lathe is take the polar Y modes of the XYZ machine and convert the motion to X linear and C axis rotation, wrapping what was Y axis linear around the C axis.

The key lies in your last bits of the post -

G00 X42.4264 Y 225
G01 X42.4264 Y 135
G01 X42.4264 Y 45
G01 X42.4264 Y 315
G01 X42.4264 Y 225

Still all linear moves, just computing the XY position in polar form...

The only way forward I see is for me to write my own full Polar Interpolation kinematics.

Edited By Joseph Noci 1 on 26/09/2021 20:07:36

John, the spindle is actually the C axis in a lathe, but the principle is similar. And no, you can't adapt a milling profile - or I suppose you can, but you have to unwrap the c axis required motion into a Y axis linear motion and convert that to C axis motion coordinated with X...! So no, not really..

Well, nothing useful to report, other than that I am feeling somewhat like a piece of threaded rod at the moment...

It turns out that when I started this project, the future dilemma would, and did, lie in the fact that success was 'doomed' as I did not know what I did not know. And to discover what you don't know only seems to come about when the task in front of you demands that you dig deep and research a lot, for days...

I was searching for a machine controller that could do lathe C axis with live tooling, and did not realised what I should have asked was - C axis with live tooling AND polar interpolation...

Many climbed in and said to persevere with LinuxCNC as it 'can do anything' - but if you search ( exhaustively!) you find NO one has actually done this with LinuxCNC...

Bottom line is that LinuxCNC CANNOT do Polar modes - it lacks the kinetics, and so lathe polar work is not possible with Polar style Gcodes. And Polar Gcodes are what is generated by ALL the CAM packages I have looked at, tried, trialled and cried over.

All CAM packages that deal with Caxis/live tool lathes generate a G12.1 code which sets a suitable controller into polar mode and which then does the Cartesian/polar math. For this to work with LinuxCNC the CAM package would have to convert all coordinated Caxis/Xaxis polar moves to small line increments of angle and x Axis move commands. I have not found any package that can do it! 'Someone' siad F360 can, but did not have the time to test a simple case for me...I also understand that F360 Lathe post-processor has 'warts'...?

I had a few CAM companies looking at the issue - it took some doing to get them to understand the issue - they could not get past the disbelief initially that a lathe CNC controller could not do Polar motion...These are companies whose CAM costs between $2000.00 and $4500.00 per seat..Out of 5 companies, 2 were very helpful they even phoned me here in Namibia a few times for more details - I was so frustrated that I was 'sort of' considering paying such a price for something that would work and explained such. They went away and came with a proposal to add the non-polar piece wise Gcode stream - cost to add would be around $2500.00 plus some TBD cost to adapt a postprocessor for the lathe...

So I thanked them for their time, and thats that!

I do not like F360 - it is to complex to live with - if you don't use it for a few months, it takes a day to get back into it, re-learn the syntax and commands, etc - and they keep changing it - also dislike very much the user use-case and cloud base nonsense...So if someone who knows F360 well is prepared to do a small test code for me, I would be most appreciative - if it works maybe i'll purchase a license...- this may be my only solution bar one - this being that I write my own polar kinematics for linuxcnc and somehow integrate it with some new Gcodes (G12.1/G13.1), etc. That is such a mission - it was supposed to be a user adaptable tool, not a project unto itself!

Bah!

At least the mechanics are successful - the ATC works well and the whole thing works well as a 2 axis lathe!

True...