Some help needed to achieve needed functionality

There is no pin available, you would have to create one in a component (or substantially alter the code to provide one through LCNC itself, which in some ways would be easier)

That component would then have to access emcmotCommands and send an EMCMOT_SET_JOINT_ACC_LIMIT command

What I am unsure of, is whether the motion controller will accept such a command whilst a program is running.

The function you would be trying to access would be in src/emc/task/taskintf.cc
As I said, because it is only called during initialisation, I do not know if calling it during a program will work.

EDIT: Or indeed even if the value can be changed, whether the motion controller would read it. It probably has a local copy which it uses throughout the running program.

I am happy to look at this in a while, but family commitments mean that will not be for a week or so.

regards

andypugh wrote:

This is the way things are at the moment. We do keep seeing requests to change accel on the fly though. Maybe someone should look into it. One problem would be that a change in accel is likely to invalidate the whole motion queue. And imagine the carnage if the machine is heading towards the limits at high speed and suddenly no longer has the acceleration available to stop...

Or maybe only allow it when the machine is not in execution (stopped) I think it could cover all "destructive" possibility's.

I can try to implement, but accessing emcAxisSetMaxAcceleration(int axis, double acc), from a M code for example, is something that is beyond my knowledge (at least for now, but unfortunately I have the feeling that it would be for a long time).

andypugh wrote:

emcPT wrote:

I can try to implement, but accessing emcAxisSetMaxAcceleration(int axis, double acc), from a M code for example, is something that is beyond my knowledge

I think that driving the feed-override pin is almost certainly the right solution here anyway.

The only puzzle is working out how to detect that a slow-down is required.

I think feed-overrride is probably the way to go too.

I am unconvinced that anything you do to the MAX_ACCELERATION figure after LCNC has started will have any effect, due to values being held in local variables.
The motion controller is not going to call a function to get the value every time it needs it, it will call once and store it.

The stepgen setting I posted earlier, should work however, because the stepgen decides what pulses it sends irrespective of what figure the motion controller holds

You can experiment with the feed-override slider or tie the halui feed override pins to a dial in pyvcp if you wish to see if you can manually achieve what you require

The problem then is do you insert M codes to reduce the feed ( you could just change the Fnnn setting in gcode before corners without all that bother)
or can some sort of look ahead method which detects abrupt direction changes be devised)

regards

OK

I have found a much simpler method than trying to hack into the code ( I hope)

inihal.cc creates all the pins you need

They appear to change the values through the usrmotWriteEmcmotCommand mechanism, when the pin values change

I don't know why I had not seen them before, but you only look at what you need to look at in code as complex as Linuxcnc

There is a pin for each axis individually and one collectively for trajectory, both for acceleration and velocity

These are exposed and available through the ini component

Open Machine > HAL Configuration >Pins > ini

You will be able to play with these, setting different values in halcmd and see what effect this has


regards

Uhmm on the machine that we are working those pins are not present, maybe an update on the sources.
Makes sense if they are available only after January.

Uhmm on the machine that we are working those pins are not present, maybe an update on the sources.
Makes sense if they are available only after January.

I am using MachineKit, but just checked and it is in 2.7~pre too

It is probably in 2.6-beta too but I don't have a copy handy

andypugh wrote:

ArcEye wrote:

inihal.cc creates all the pins you need

So it does! Though it has only existed since January.

But I _still_ think that feed-override is the right way to do it

It may well be, but at least this makes testing the alternatives easier.

I am glad it is recent, thought I was getting early onset altzhiemers, was sure I would have noticed it when I was writing my access libraries for Qt