Standalone LinuxCNC machine simulator using the Stepper-Ninja HAL interface

Hi tuxcnc,Thank you for your feedback and suggestions! You have actually touched on two of the next major features we are planning: physical tools and tool measurement.I think it would be useful to explain the underlying concept of this simulator, because it is slightly different from a traditional G-code simulator.Our goal is to simulate a real CNC machine, including its capabilities, limitations, and potential mistakes.A real CNC machine does not interpret G-code itself. LinuxCNC is responsible for interpreting G-code, planning trajectories, applying tool offsets, and controlling the hardware. The machine simply responds to the commands it receives.We want our simulator to behave in exactly the same way.The virtual machine will have its own physical state: axis positions, spindle, installed tool, tool geometry, workpiece, sensors, and eventually machine geometry and collisions.An important design principle is that the physical state of the simulated machine must remain independent of what LinuxCNC believes that state to be.For example:

• If LinuxCNC requests tool T5 but the operator installs the wrong tool, the simulator should use the geometry of the tool that was actually installed.
• If the physical tool length differs from the value in LinuxCNC's tool table, that difference should affect the machining result.
• A virtual toolsetter should be able to detect the actual tool length, just like a real toolsetter.
• Incorrect offsets, incorrect tools, or incorrect workpiece positioning should be capable of producing incorrect machining results or collisions.

This behavior is intentional. We don't want the simulator to automatically correct mistakes that would also happen on a real machine.For the same reason, I would prefer not to intercept or reinterpret M6 using a custom REMAP. We should instead investigate how to model the machine-side tool-changing process through the normal LinuxCNC interfaces, without interfering with an existing tool-change implementation.Of course, the simulator should also support automatic tool changers in the future. The important distinction is that a requested tool change and the tool physically installed in the spindle are not necessarily the same thing.We have also completed the first virtual spindle implementation. LinuxCNC can now control it through the normal spindle commands, with encoder feedback returned through the Stepper-Ninja interface.Our next development steps are the physical tool model, tool changes, and tool measurement.Your feedback is very valuable because it helps us identify what is needed to make the simulator useful for real LinuxCNC configurations.Thanks again for testing the project!

fmueller wrote:

• If LinuxCNC requests tool T5 but the operator installs the wrong tool, the simulator should use the geometry of the tool that was actually installed.
  • If the physical tool length differs from the value in LinuxCNC's tool table, that difference should affect the machining result.
    • A virtual toolsetter should be able to detect the actual tool length, just like a real toolsetter.
      • Incorrect offsets, incorrect tools, or incorrect workpiece positioning should be capable of producing incorrect machining results or collisions.

I can't imagine it.
The simulator cannot use information that is not available.
If, for example, we have a manual tool change, the simulator can at most receive information that the tool has been replaced. LinuxCNC does not ask what physical tool the operator has installed, cannot use the answer to a question he did not ask and cannot transfer information to the simulator that he does not have.
I wrote about tool measurement simulation only in the sense that the simulator would show the movements that will actually be made.
I have a remap that goes to the manual tool change position, then moves to the height sensor, and then returns to where it started. Showing these movements would make the simulation more realistic, but it seems impossible to simulate operator error.
There are simply things that cannot be done and you have to accept it.
Coming back to REMAP M6, it could probably be done.
You could use a shell script that would first run a program to tell the simulator to change the tool, and then run the user remap  program. This should work.
An alternative would be to change the stepper-ninja code so that additional information is transmitted. Maybe it's worth going in this direction, because it would provide additional possibilities that could be useful in the future...

Hi tuxcnc,You are absolutely right that the simulator cannot know which physical tool has been installed if that information is never provided.I think I didn't explain one important part of our concept clearly enough.The simulator is not intended to receive all its information exclusively from LinuxCNC. It should eventually have its own virtual machine operator interface.Think of a real CNC machine with a manual tool change.LinuxCNC requests T5, moves to the tool change position, and waits for the operator. But LinuxCNC cannot physically verify which tool the operator puts into the spindle.Our simulator should behave similarly.The user would be able to select and install a physical tool through the simulator interface. That tool could be T5, but it could also be T3 by mistake.The simulator would then use the actual geometry of the installed virtual tool, independently of the tool information stored in LinuxCNC.The same principle applies to workpiece positioning, tool lengths, and eventually fixtures and collisions.Of course, this requires a virtual tool library and an operator interface, neither of which is implemented yet.Your example of the M6 REMAP moving to a toolsetter is particularly interesting. The simulator already receives the axis movements through Stepper-Ninja, so those movements do not need any special G-code handling.Once we have physical tool geometry and a virtual toolsetter, we could also simulate the actual contact with the sensor and return its signal to LinuxCNC.I agree that additional communication might be useful for automatic tool changes and other machine functions. However, I would prefer to keep the original Stepper-Ninja protocol unchanged if possible, and investigate a separate interface for simulator-specific interactions.The main idea is to simulate the physical machine independently of the controller's assumptions, including situations where the operator makes a mistake.Thank you for challenging this concept. These discussions are very helpful for defining the architecture before implementing the next features.