mesa 5i25/7i77 Yaskawa servo

If MAX_OUTPUT is set to 0.0 then it is probably ignored, the same as if no MAX_OUTPUT is specified.

Thanks Guys,

We seem to have the basics all sorted now. Runs smoothly, the DRO agrees with the ruler using 500 counts per unit.

A question about setting up axis. The machine has 6 over-limit safety switches that we have left as was, ie. operating the relay holding power to the servo drivers. The 3 homing switches, acting comfortably inside the over-limit switches, are now handled via the 7i77. Homing is making the right sort of moves but at what the DRO sees as the positive ends of the axis. Either way, the homing switches on this old machine appear to have originally been set up for a left handed axis system!

I assume you can set it up anyway you like, but is there a preferred standard in use by machinists that it's worth conforming to? i.e. a right handed system. The z axis I'm thinking should be positive in the up direction, but homed at the top, with deeper cuts being more negative numbers? Should X and Y then be made to follow as a right handed system, zeroed at the negative end such that the table is traversed with positive co-ordinates?

To get the PID working with the drive direction we needed to set output scale to -10 in the ini file. I understand that this is also the way to reverse direction of the axis. Would this mean having P and FF1 as negative numbers? Is this normally how it's done or is there a tidier way of doing it? I suspect we could also reverse the hardware connections of our encoder but I would rather leave that conforming with the circuit diagrams of the manuals you find in the internet. ( You don't want to make the system too illogical for anybody following behind. Morbidelli's not perfect at that either!)

Thanks again

Cheers Ian

Its best to reverse the analog output scale (as you have done)
to correct backwards feedback.

Swapping encoder leads will reverse the feedback position which
is not what you want if its already correct

I would not use negative PID parameters, there are bugs in the PID component with negative parameters

Thanks Guys,

We seem to have the basics all sorted now. Runs smoothly, the DRO agrees with the ruler using 500 counts per unit.

A question about setting up axis. The machine has 6 over-limit safety switches that we have left as was, ie. operating the relay holding power to the servo drivers. The 3 homing switches, acting comfortably inside the over-limit switches, are now handled via the 7i77. Homing is making the right sort of moves but at what the DRO sees as the positive ends of the axis. Either way, the homing switches on this old machine appear to have originally been set up for a left handed axis system!

I assume you can set it up anyway you like, but is there a preferred standard in use by machinists that it's worth conforming to? i.e. a right handed system. The z axis I'm thinking should be positive in the up direction, but homed at the top, with deeper cuts being more negative numbers? Should X and Y then be made to follow as a right handed system, zeroed at the negative end such that the table is traversed with positive co-ordinates?

To get the PID working with the drive direction we needed to set output scale to -10 in the ini file. I understand that this is also the way to reverse direction of the axis. Would this mean having P and FF1 as negative numbers? Is this normally how it's done or is there a tidier way of doing it? I suspect we could also reverse the hardware connections of our encoder but I would rather leave that conforming with the circuit diagrams of the manuals you find in the internet. ( You don't want to make the system too illogical for anybody following behind. Morbidelli's not perfect at that either!)

Thanks again

Cheers Ian

Thanks Tommy,
Sometimes the obvious eludes you. Yes home switches at one end but run to the other end of the table for home itself.

Still can't see the easiest way to change from a LH to RH axis orientation. I'm stuck at either physically reversing the output of one of the 3 encoders or switching the axis naming such that X is across the bed (along the gantry) and Y is the longest axis. Is there a convention here we should stick to?

What version of Linuxcnc are you running? Your link was to V 2.6 which may be different to later versions. For the important stuff, always start at them main linuxcnc site and follow the links to the docs for your version.

I know setting this stuff up does your head in. It did to me when I built my machine.

I think there is a scale pin on the Mesa encoder inputs which you can change the sign of to reverse the direction but I only ever use the encoder input for plasma torch voltage.

I've only ever used V2.8 and V2.9 but have set up my machine either way (eg gantry has been set as X or Y at different times) and the homing is different to 2.7. I've also reversed the direction of the Z axis at different times. All in software.

and yes, if it homes to the max limit end, you could apply a home offset to move it back to the correct position.

Also with Z axis direction, I found it was easiest to apply a permanent G54 offset. eg my Z axis is 86mm long so I go to the top of the axis and touch off at +86mm which puts the bottom of travel at 0.0. Linuxcnc remembers this so it should never need touching again. But with plasma I don't ever need to control the Z axis from gcode.

Thanks Rod, Thanks Tommy,

We have version 2.7 running. I'll make sure I search in that version.
So it appears there's no particular standard re left or right handed axis setup. Goes for driving on Australian vs. Italian roads I suppose I shouldn't have expected the hardware layout of the Morbidelli to offer any clues. But now knowing that we can easily convert orientation in software takes it away as a potential future problem.

We should note that to reverse the axis direction you need to flip the sign of both the encoder-scale and the output-scale in the ini file. Switching just one of them will have the PID output acting in the positive feedback direction and you'll immediately get a max-f-error shutdown.

Cheers Ian