QTPlasmaC with six axis

Got it working with the 6 axis kinematics and running Vismach next to the Gui so I can see what is happening without the machine.
Now the testing starts.
Thanks a lot for your help so far Phill. It is looking good so far and I am excited to see if we can get a full 6 axis machine to run.

So the next problem is the soft limits. It would seem that the joint soft limit is not treated the same as the world mode soft limit. I would have thought that the first of the limits that is activated will cause the movement to stop. This seems to not happen. If the world mode limit is reached the movement will stop but if the joint limit is reached the machine boms. You then have to go to joint mode (which we don't have yet) and jog off the limit and then go back to world mode. When jogging this can be done but when you run Gcode the initial limit check is only done on world mode and not on joint mode. SO if you run your Gcode, it could cause any joint to go into limit while the world mode is still not in limit. I would think that both should be checked when the code is loaded.

I would think that both should be checked when the code is loaded.

For non trivial kinematics proper limit checking at load time is not possible because the planner is totally ignorant of custom kinematics. Your best option would be to check for limit violations in cam or running your gcode in a simulation configuration. Depending on your kinematic you may even have to loosen your axes limits to be able to reach the full work space.

We could add a means to switch between joint and world modes.
Although without a lot of work the jog buttons would still have the axes graphics.

That would help a lot. I dont think it's a train smash if the buttons are not changed at this time. Or at at all for that matter.

Aciera wrote:

I would think that both should be checked when the code is loaded.
For non trivial kinematics proper limit checking at load time is not possible because the planner is totally ignorant of custom kinematics. Your best option would be to check for limit violations in cam or running your gcode in a simulation configuration. Depending on your kinematic you may even have to loosen your axes limits to be able to reach the full work space.

What is weird though is that in the simulation I don't run into the same issues. I don't know if limits are handled at all in simulation but it seems to be not the same. 

I don't know if limits are handled at all in simulation but it seems to be not the same. 

Hm, I don't see how that would differ in a simulation as the joint position commands are not dependent on whether real hardware is connected or not. As long as the limit value settings are identical in both configs. Are you sure you are getting soft limit errors with the machine and not hardware limits? That would of course require that you actually have hardware limit sensors on your machine, which I don't know.

No hardware limits connected at this stage. But I did look at both configs and they are not the same. I will have to try and establish the worst case offset between the world coordinates limits of the xyz axis and the over run caused by any of the rotational axis. The difference must be applied to the joint mode limits or visa versa. It just means that I have to keep the torch length (tool length) as short as possible.

@Phill, it would seem that we will need that button to put is in joint mode or world mode. It look like the limit issue is real and we have to deal with it this way. I noticed that Gmoccapy also has such a button for the 5 Axis configs.