simulation

RobotMatic wrote:

Dear Andy. It's not about the answers, it's about the approach. The cheap solutions that you offer do not contemplate an operator who only uses the machine and who does not know about installations, configurations, real time. etc.

This seems a fair comment. LinuxCNC was invented by US Government academics, and then picked up by hobbyists. It has not had _that_ much exposure in production environments. I think that Todd uses it in production, but given that he has suggested that his operators have an opinion about which controller they prefer, even they might not be the typical operator.
Stuart has been using a very large machine with LinuxCNC for many years (look at the age of this video ) and he machines very expensive parts of the aircraft industry. But, again, he is an enthusiast-owner-operator, not typical.

I hope that in the future Those who assign tasks in the project can understand what I am raising.

I thought I had made the point that _nobody_ assigns tasks. Nobody feels that they have the right to. What happens is that somebody sees something that could be better, and improves it, to their own specification, for their own reasons.
This is not the best way to make a great software package. But it is what we have.
Do you know any programmers? Do you fancy having a go yourself? Perhaps you can cajole, bribe or pay someone to add the features you want? (I would suggest discussing the concepts on the developers mailing list first, though)
To put this in perspective, I have now written some code for LinuxCNC, but I only started coding in C to fix a particular gap in the capability of LinuxCNC that I wanted to fix for my own purposes.

I fully agree with Todd.
thank you.

RobotMatic wrote:

If you use compensated trajectories, the linuxcnc pre visualizer on a lathe shows you the theoretical trajectory, not the real trajectory along which the tool is going to move,

Good point. I have worked round this sometimes by running the preview once with a zero-diameter tool, then running again with an actual tool and compensation to check that the visualised tool follows the required path. But I am not suggesting that as a solution. I did it when checking some G71 routines.

but I don't want to discuss this topic anymore, thank you very much. I don't agree with any of you.

Are you sure? I am actually quite interested in a discussion on how such a feature should work. I have never said that I think it is a bad idea, or that the current workarounds are better. I have just tried to explain the practical reasons that your request is unlikely to result in the feature happening in the near future. (Mainly that LinuxCNC is rather short of developers at the moment, and those that are active seem to be short of time to devote to the project)

If you no longer want to discuss the subject here, you could add the request with an "enhancement" tag on the tracker: github.com/LinuxCNC/linuxcnc/issues

That is why I am suggesting that, even if you can't code it yourself, you could describe exactly what such a feature would look like, and how it works on other controls.

I can't imagine, for example, that you have to watch an 8 hour simulation in real time?

Todd mentions that bad things happen with some controls if the point that the simulation ends (or is aborted) is not the starting position of the simulation. This seems to suggest that the simulation is done by disabling the hardware, and then when it is re-enabled the machine can make a rapid move to reconcile the hardware and software positions?
That probably should be avoided....