Mesa 5i20 servo configuration

Zig wrote:

Conventional XYZ G code file can then be used to move the laser beam while direction change in Z axis ( think of this as an engraving machine ) would control laser state.
The Z axis is a dummy axis to the extent that there is no physical Z axis actually taking place. This way the entire proces is within established G code generation process abd laser satus is controlled by G code without a need for any other inputs.

Yes, I assumed that. There is no reason for that dummy axis to have a stepgen in the Mesa card, though. Which would leave more GPIO pins free.

Last night i was getting reports that some of the pins did not exist. Obviously something was not done correctly.

Generally a typo. (_ for -, - for . etc) If you but a line:
show all
in the HAL just after all the addf functions you will get a list of all the pin names that have been created.

PCW wrote:

For constant laser power, can you just take the existing velocity signals from the X and Y encoder HM2 module and do the SQRT of the sum of the squares (maybe theres a comp for this already) and output the value as PWM/analog?

There is such a function, it is called "hypot"
www.linuxcnc.org/docview/html//man/man9/hypot.9.html

And it seems to me that doing the maths in HAL and moderating the laser power that way has to be a far better plan.

Zig wrote:

The step gen module in hostmot behaves differently to the stepgen in emc2 hal.

I am not sure why that matters, but that is probably a sign that I don;t understand what you are doing.

You could use a software stepgen for Z, there is no reason that you can't mix and match them, and that would let you allocate the outputs to any GPIO pins you wanted to use. However those pins only update at the servo-thread rate even if you were to create a base thread for the software stepgen.
One compromise would be to use the Mesa stepgen for the pulse generation, but also set up a software stepgen (linked to the same motion pins) and to only use the direction pin of that stepgen, linked to a gpio pin of your choice.

Returning to you earlier post, if you really think that wiring up an external monostable is easier than adding a velocity-linked hypot function in HAL then you are missing an awful lot about the power of HAL.

If I was doing what I think you are doing, (modulating laser intensity with Z velocity and compensating for tracking velocity?) I would be feeding the velocities through a "hypot" and a couple of "scale" functions to a Mesa PWM generator which controlled laser power.

I am not sure what you are using the latching direction pin for, but whatever it is, HAL will have a solution.

Zig wrote:

I use the Z axis directin flag to enble the laser.

Eccentric, but each to their own

www.linuxcnc.org/docview/html//man/man9/comp.9.html
should work. Something like this (modify to suit your actual situation)

loadrt comp count=1
addf comp.0 servo-thread
net z-vel axis.2.joint-vel-cmd => comp.0.in0
net laser-on comp.0.out => hm2_5i20.gpio.007.out
setp comp.0.in0 0
setp comp.0.hyst

I am sure that hal would be able to handle these issues and indeed it is not a hal problem but rather my inability to speak hal fluently which drives me into the arms of external hardware solution.

It is worth learning. Nobody ever burned themselves picking up the wrong end of a keyboard.