Advanced Search

How much?

I believe you should sell for scrap price.

The incentive to sell comes from the fact that you don't have to haul it to the scrap yard.

Also, the scrap yard will almost certianly resell it as a lathe.

Scrap it in good condition if it comes to that.

(I am not interested in purchasing it)

RotarySMP wrote:

With the castings I am drawing up for my antique motorbike engine project, where everything has draft angles and fillets,  I am definitely hitting the limits of it's filleting engine. I normally end up deleting my extrudes, and fillets multiple times, and changing the order I do things, and sometimes find an order which leads to most of the fillets I need. 

To be fair, this is frequently a problem with Fusion 360 too. 

www.gumtree.com.au/web/listing/desktops/1333283465
www.gumtree.com.au/web/listing/desktops/1333056375

The nice thing about a Mac is you can control the fans with the SMC via a tool like mbpfan.

Old Apple products were really well-made.

Their newer stuff has no quality control of any kind.

But 2018 is long enough ago that I think quality will be decent.

Why is everyone here Austrailian?

I would still recommend the Intel Mac Mini.

You can buy a bracket for mounting from Apple (though it will set you back $100).

(The price will vary depending on your location because Apple's prices have no basis in the item's actual cost, they are solely a marketing decision.)

I recommend you keep all original brusheless motors, but perhaps you don't care about preserving old motors enough to spend the time.

Try to sell them, they may be worth more than their scrap value.

(Not sure what scrap metal prices are like where you are)

I'm assuming the closer you are to China (and Vietnam, Thailand, etc.), the higher the value of E-waste because the shipping to the recycling center in Asia is cheaper.

Be aware that switches due wear out, especially from DC, capacitive, and inductive loads.

If you notice sparking sometimes, replace the switch.

Remember that worn-out switches will only spark sporadially b/c AC power cycles and the swith will only spark near the peak of the cycle.

1. I tried to define the real machine limits in the .ini File. i.e. Z axis travel of 1065mm and home at zero. But after starting and homing z is automatically at -180mm.
 

Changing machine limits in the ini will (and should not) change anything in the DRO at startup. I'm not sure where you see '-180' for Z. This is what I get:
 

2. While running the example part (which makes me happy every time i do it... thank you so much) i realized that the tool change position is defined by G53 in the M6 remap. But in the vismach sim it definitely looks different between T101 und T2.

You might get confused about the difference in the tool path backplot (ie the pink line). This is purely a product of the visualization and comes from the different direction of the x and z tool-offsets for milling and turning.  Absolute machine position is reflected by the values in the 'Joint Position' section in the right hand panel:

 

Note though that 'G53' (and also 'G28', G30') must only be used in 'IDENTITY' mode as the axis directions will follow the directions of the rotated axes in TCP modes or as defined in the TWP plane.

3. Does the kinematic has the prerequisite to work only if home is the position where both spindles are in line with each other? So X and Y between both spindles rotational axis is 0 ? I assume that is not the case.

The kinematic is setup with the pivot point of the spindle rotary to coincide with the machine reference point (ie joint positions all 0). 
On a real machine config we can define the home positions (ie where a joint is 0) using the 'HOME_OFFSET' and 'HOME' values in the ini[JOINT_n] section. This is just not simulated in a simulation config.

1. M19 R180/R0 works fine and is needed for the lathe tools. But I definitely need to write a custom component for this functionality, because the spindle is hydraulically locked and of course alot of logic needs to be implemented for this rotation.
I'm not sure yet how to implement it. My preference would be a custom G-code like i.e. G490 XXX (XXX = Degrees in multiples of 30°) that then calls the custom component. How does the Half TCP Lathe mode know the current tool orientation? As already said it works flawlessly with M19 but would it also work with G490 ?

Currently the kinematic gets the spindle orientation through a hal connection to 'spindle.1.orient-angle'. This pin is set to the angle as requested by 'M19 R.... $1'. Because this value changes instantly it would likely cause a following error in the b-axis drive on the actual machine hence the note in the README about using actual spindle feed back (there are other HAL internal options to make this a gradual change inside hal if there is no real time feedback for the spindle position).  So the kinematic just needs the orientation angle sent to the designated halpin 'mazak-integrex-200y-kins.tool-angle'.

2. I know it sounds a little bit stupid, but it would be nice if the tool rescue function would be limited to pressing the button TWP and then getting asked on how much the tool shall retraced in mm in z (only positive values accepted). Usually in those situations I'm nervous and don't want to wreck the spindle...

This is certainly possible.

Please post your gm.hal and gmoccapy_postgui.hal so we can have a look. The gmoocapy_postgui.hal should include the lines from the documentation.

I played around some more with the sim.

1. I tried to define the real machine limits in the .ini File. i.e. Z axis travel of 1065mm and home at zero. But after starting and homing z is automatically at -180mm.

2. While running the example part (which makes me happy every time i do it... thank you so much) i realized that the tool change position is defined by G53 in the M6 remap. But in the vismach sim it definitely looks different between T101 und T2. See pictures attached. I tried to do a G49 before the tool change call, but that made it worse. For the ATC the position of course need to be the same every time.

3. Does the kinematic has the prerequisite to work only if home is the position where both spindles are in line with each other? So X and Y between both spindles rotational axis is 0 ? I assume that is not the case.

And here are some topics I'm thinking about:

1. M19 R180/R0 works fine and is needed for the lathe tools. But I definitely need to write a custom component for this functionality, because the spindle is hydraulically locked and of course alot of logic needs to be implemented for this rotation.
I'm not sure yet how to implement it. My preference would be a custom G-code like i.e. G490 XXX (XXX = Degrees in multiples of 30°) that then calls the custom component. How does the Half TCP Lathe mode know the current tool orientation? As already said it works flawlessly with M19 but would it also work with G490 ?

2. I know it sounds a little bit stupid, but it would be nice if the tool rescue function would be limited to pressing the button TWP and then getting asked on how much the tool shall retraced in mm in z (only positive values accepted). Usually in those situations I'm nervous and don't want to wreck the spindle...

Kind regards,
Jochen



 

Regarding touchscreens, confirm that they are a USB HID one and don't require any specific\manufacturers drivers.

This is perfect! I believe these links cover pretty much everything I was hoping to find.
Thank you very much!
I'll take a closer look at these pages and the related ones.

Hopefully, you'll have some time to answer a few questions if I’m still unclear afterwards.

To get information about the pin functionality you need to look at the man page of the specific component which can be found here:
linuxcnc.org/docs/html/man/man9/


For example the 'motion' component:
linuxcnc.org/docs/html/man/man9/motion.9.html

or the 'pid' component
linuxcnc.org/docs/html/man/man9/pid.9.html

Where I work right now it's pretty lean ( thanks to the new tariffs ) so I wont be messing with ours unless
we have a really good reason to need it. That said I wish you luck on your project.

RotarySMP wrote:

The 7i97T has one SS configured on a connector, but with two S devices (7i73 and 7i84) you will probably need to flash a firmware with an additional SS port on the DIL connector.

Thanks for your input Mark.

Excuse my ignorance, but I assume the SS refers to the RS-422 serial connection?

Love your channel by the way. Digging the engine build. The John Britton diy way must run deep, and rightly so.

Well, I have been trying for a couple of hours to get this to work.

Not sure just what should be in gm.hal versus gmoccapy_postgui.hal.

Can someone please post a working solution for both hal files ?

John.