simulation

You certainly don't need to be a C programmer (or Python, or any other computer language) to learn how to set up and configure machines with Linuxcnc. I certainly am not. But if you can write and set up G-code you are a programmer of a sort. I have learned how to set up Hal files and program PLC logic, though. And none of the suggestions proposed in this thread would involve any programming other than configuring a hal file and maybe configuring a VCP button or two for the operator to press.

I would argue that Linuxcnc is at least as good or better than any new control you can buy for less than $2000. (Provided you are willing to learn how to and take the time to configure it correctly for your application.)

My experience with "dry run" simulations is that they generally aren't worth the effort to set up, compared with simply looking at the preview screen in Linuxcnc. (Which is already more useful and faster feedback than you get from the "Dry run" button on most Fanuc controls I've used.)

I fully agree with Todd.
thank you.

My 30-year experience as a cnc machine programmer with Fanuc-Fagor-hidenhain-hass-siemens-mitsubishi-hass and a lot of others says the opposite. 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, but I don't want to discuss this topic anymore, thank you very much. I don't agree with any of you.

thank you very much

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

I feel frustrated, I would like Linuxcnc to be better in the future, that is why every time I find something I communicate it. But I always hit a wall. I just want to collaborate. thanks again.

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....