Some help needed to achieve needed functionality

In the past days we tested the implementation of the acceleration on a simulator as the machine were we did the retrofit is already with the client.
On the simulator all works as expected, so we went to the client workshop.

On the client, version 2.7 pre was installed (with more or less one month old, as it was installed when the machine was retrofit in our workshop). So on the client, the version is probably older than the one that we tested with the simulation.

We did the same gcode on the client on the real machine. First test all was perfect and I was really happy as it seamed like the issue was solved, second test, the acceleration was not taken in account. It seams like a bug, because the respective pin showed the correct acceleration that we requested.
We did an enormous amount of testing and sometimes, changing from G64 to G61 did the trick, sometimes not. We did not reached a conclusion about what could make the acceleration be taking in account, except that if we restarted linuxcnc, the first run would always run as expected (with the acceleration taken in account). Second part, no. changing G64 to G61 or G64 P0.01 or another change back G61 did the trick.

Another thing that I found as not correct is that if we were in G64 mode, and in the Gcode a G61 was requested, the list with the actual G and M codes was not updated. Not sure if this is a feature or also a issue.

Since the client is far away from us, this is a problem that I would like to be tested before I go there again, and my question is: If the simulation works as expected, there is a probability of the real machine not behaving in the same manner?

My expectation is that on the client the version have some bug that in the meanwhile was corrected... (probably expecting too much)

Thank you

Just to be clear, are you saying that in simulation, a change of the relevant axis max_acceleration pin value always resulted in altered acceleration, but on the actual machine it did not?

Have you tried using 2.6-beta?

That should have the code in inihal and will not be subject to the same make or break changes that 2.7 is.
Or does your conversion rely upon other features that were not carried into 2.6?

The pins also give the same control of velocity, did you test the result of decreasing the feed rate in a similar manner on corners etc

regards

ArcEye wrote:

Just to be clear, are you saying that in simulation, a change of the relevant axis max_acceleration pin value always resulted in altered acceleration, but on the actual machine it did not?

Yes, the change was made, the pin did had the correct value, but not always the acceleration was taken in account. Like I said before, I was unable to determine the reason what triggered a correct or incorrect behavior of the machine.

ArcEye wrote:

Have you tried using 2.6-beta?

No, I did not.

ArcEye wrote:

That should have the code in inihal and will not be subject to the same make or break changes that 2.7 is.
Or does your conversion rely upon other features that were not carried into 2.6?

We are not using nothing special that needs 2.7, except the presence of the acceleration pin, that I was not aware that exists on the 2.6-beta.

ArcEye wrote:

The pins also give the same control of velocity, did you test the result of decreasing the feed rate in a similar manner on corners etc

We only tested the acceleration. Working outside, on the client site, it is not very easy to conduct experiments.

Hi

I have done my own experiments using MachineKit (Essentially 2.7 with all the ubc-3 and TP bits enabled)

When I tried setting max_acceleration to a lower figure during a program in a sim, I found it impossible to tell if it had worked.
The pin was set to the new figure, but any change in the axis movement was not detectable.

Then I reloaded the file and ran again, the effect was immediately obvious, it crawled around corners.

When I changed max_velocity part way through a program, it was also echoed in the pin value.
What was immediately obvious though was that the velocity did not change, both visually and the value in the gremlin DRO stayed the same.

However reload the program and the new figure is clearly being used

I think this proves something similar to what I originally suspected

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.

It does show however that a file reload will be sufficient, no need for a shut down and re-start, to change all the figures in the motion queue

What I did find though was that using the feed override slider was far more successful at immediate slowing of an axis

Looking at the code, the difference appears to be this.
The inihal pin values are applied using emcTrajSetMaxVelocity() for velocity

However the feed override mechanism is using emc_traj_set_scale_msg

I don't have time to dig right into it at present, but it looks like the former sets an absolute value which is only applied when the the queue is rewritten, but the latter sets a scale factor which is applied to all
velocities.

So there could be scope to address it in the same way, I will try to look further into it tomorrow.

regards

Thank you for your interest in this issue.
I do not know if the reload could solve the issue, as I did not reached a conclusion before. My college worked on the simulation before and I have almost sure that I saw the code running more than once without the need to reload and the acceleration settings were always taken in account, but I can confirm this tomorrow.

If the reload solve my immediate problem, I can force the axis to reload the code for each "button start", what could be a simple solution for now.

I don't have much time to look at it, but a grep through the sources seems to confirm my observations.

EMC_TRAJ_SET_ACCELERATION is one of the commands handled in emcTaskCheckPreconditions()
This is where settings are established, as it were, it is not where commands with immediate effect are processed
This is why it is only read when the program or the whole of Linuxcnc is restarted / refreshed.

EMC_TRAJ_SET_SCALE however is one of the immediate commands which is acted upon even whilst a program is running
It is checked whilst the interpreter is in Auto mode, is Paused, Waiting, Reading etc etc

There are pins available in halui suitable for connecting to a slider or dial and the function to set the scale. There is even a function available in emcmodule.cc, which is the main python bindings file
as well as emctaskmain.cc.

So if you stick with acceleration, you may have to force a reload to get the new figure read in.

If you go for scale (feed override) you have more options and they will be applied immediately

Add to you armoury G61 / G64 and not to forget the option of actually programing a G4 Px at the end of a line to give the bottom of the cut time to catch up, hopefully you can find a solution between them

regards