This was not a iocontrol issue at all but rather I discovered or ran
into a CMS issue while adding NML types for HAL pins for use with TCP
connected remote UI (Rpin's). The below refer to file /nml_intf/emc.cc
(rmc.cc for me).
In my configuration the below are valid for ::update(cms) messages in
the emc.cc file.
RMC_CMD_MSG
RMC_SPINDLE_CMD_MSG
RMC_LUBE_CMD_MSG
RMC_COOLANT_CMD_MSG
RMC_IO_CMD_MSG
RMC_JOINT_CMD_MSG
RMC_JOG_CMD_MSG
RMC_TOOL_CMD_MSG
RMC_TASK_CMD_MSG
RMC_TRAJ_CMD_MSG
RMC_AUX_CMD_MSG
RMC_MOTION_CMD_MSG
RMC_RPIN_CMD_MSG
The below example is part of NML type additions for my Rpin's to
/nml_intf/emc.cc.
/* NML/CMS Update function for RMC_RPIN_MACHINE_CNC */
void RMC_RPIN_MACHINE_CNC::update(CMS * cms) {
RMC_RPIN_CMD_MSG::update(cms);
}
If the last line above has an invalid entry such as the below and the
remote command RMC_RPIN_MACHINE_CNC is executed:
RMC_RPIN_MACHINE_CNC::update(cms);
The system will no longer accept any commands after the RMC_RPIN_MACHINE_CNC
command is given from a remote UI that is using TCP into port 5005.
It does not terminate the connection but a LinuxCnc restart is
required to restore to working condition. Thus it appears that CMS
becomes none responsive.
I would expect that in the case of such an error that an error message
would be generated and that the system would recover and not become
totally none responsive. But there is no debug message generated and it
appears to be an issue with CMS in that it is not able reject such a
command or recover from it after attempting to execute it.
The effect of this is: Decreases system reliability
My added HAL Rpin's are working properly.
The sample shown is part of switching logic that changes the machine
from CNC mode to legacy Manual mode.
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
