Not sure if this is an issue with a unmodified version of iocontrol v2 or
potentially related to my own version which adds some pins that are
controlled by my remote UI that interfaces directly with NML via xemc
(xrmc for me). RMC = abbreviated Remote Machine Controller
I have been running fine until I started using iocontrol. In running
with iocontrol I choose to use v2 from 2.9 pre 0 and modified it only
to add some pins that are remote UI related for HAL. The problem is that
the NML remote process server itself becomes none responsive after
TOOL_ABORT reason=2 is sent right after a machine power on command.
Don't know
why it would even send this command during a basic machine power up
sequence that does not involve a tool change.
Below is a copy and paste that show the command sequence used to run
into the problem.
Remote connection watch dog polling in these are types:
(time=1580516452.319145,pid=2428)
1st remote UI command sent after remote NML connection estabished
Issuing RMC_TASK_SET_STATE -- ( +505,+24, +1, +1,)
IO CMD - RMC_AUX_ESTOP_ON
IO CMD - RMC_LUBE_OFF
NML_INTERP_LIST(0x561fbe3a9a00)::clear(): discarding 0 items
NML_INTERP_LIST(0x561fbe3a9a00)::append(nml_msg_ptr{size=24,type=RMC_TASK_PLAN_SYNCH})
: list_size=1, line_number=0
rmcTaskPlanSynch() returned 0
NML_INTERP_LIST(0x561fbe3a9a00)::get(): {size=24,
type=RMC_TASK_PLAN_SYNCH}, list_size=0
rmcTaskPlanLevel() returned 0
task: main loop took 0.047238 seconds
IO CMD - RMC_TOOL_ABORT reason=6
Issuing RMC_TASK_PLAN_SYNCH -- ( +516,+24, +0,)
rmcTaskPlanSynch() returned 0
(time=1580516452.319145,pid=2428): read 20 bytes from 6
(time=1580516452.319170,pid=2428): TCPSVR request received: fd = 6,
serial_number=6, request_type=1, buffer_number=1
(time=1580516452.319189,pid=2428): rcs_sem_post(196608) called.
(time=1580516452.319221,pid=2428): wrote 20 bytes to 6
2nd remote UI command sent
Issuing RMC_TASK_SET_STATE -- ( +505,+24, +2, +2,)
IO CMD - RMC_AUX_ESTOP_OFF
NML_INTERP_LIST(0x561fbe3a9a00)::clear(): discarding 0 items
NML_INTERP_LIST(0x561fbe3a9a00)::append(nml_msg_ptr{size=24,type=RMC_TASK_PLAN_SYNCH})
: list_size=1, line_number=0
IO CMD - RMC_TOOL_ABORT reason=5
rmcTaskPlanSynch() returned 0
NML_INTERP_LIST(0x561fbe3a9a00)::get(): {size=24,
type=RMC_TASK_PLAN_SYNCH}, list_size=0
rmcTaskPlanLevel() returned 0
task: main loop took 0.024445 seconds
Issuing RMC_TASK_PLAN_SYNCH -- ( +516,+24, +0,)
rmcTaskPlanSynch() returned 0
(time=1580516511.336288,pid=2428): read 20 bytes from 6
(time=1580516511.336314,pid=2428): TCPSVR request received: fd = 6,
serial_number=36, request_type=1, buffer_number=1
(time=1580516511.336333,pid=2428): rcs_sem_post(196608) called.
(time=1580516511.336367,pid=2428): wrote 20 bytes to 6
3rd remote UI command sent and also IO PWRSSR on (Spindle 240VAC power
solid state relay on).
PWRSSR is handled by IO and routed to hal
Issuing RMC_TASK_SET_STATE -- ( +505,+24, +4, +4,)
IO CMD - RMC_UI_PWRSSR_ON
NML_INTERP_LIST(0x561fbe3a9a00)::clear(): discarding 0 items
NML_INTERP_LIST(0x561fbe3a9a00)::append(nml_msg_ptr{size=24,type=RMC_TASK_PLAN_SYNCH})
: list_size=1, line_number=0
IO CMD - RMC_TOOL_ABORT reason=2
NML_INTERP_LIST(0x561fbe13ee80)::clear(): discarding 0 items
rmcTaskPlanSynch() returned 0
Issuing RMC_TASK_SET_MODE -- ( +504,+24, +5, +1,)
NML_INTERP_LIST(0x561fbe3a9a00)::get(): {size=24,
type=RMC_TASK_PLAN_SYNCH}, list_size=0
rmcTaskPlanLevel() returned 0
Issuing RMC_TASK_PLAN_SYNCH -- ( +516,+24, +0,)
rmcTaskPlanSynch() returned 0
(time=1580516665.491116,pid=2428): read 20 bytes from 6
(time=1580516665.491142,pid=2428): TCPSVR request received: fd = 6,
serial_number=115, request_type=1, buffer_number=1
(time=1580516665.491160,pid=2428): rcs_sem_post(196608) called.
(time=1580516665.491195,pid=2428): wrote 20 bytes to 6
After this if one additional command is sent the NML server for the
remote process becomes
none responsive and polling replies back to the remote also stop.
Connectivity
itself is still maintained.
Since direct interface into NML from a remote UI is not used by many is
it possible that problem may be a hidden one? I'm investigating this
issue further but have no additional info right now. I do need a method
to insure that the remote NML process server always stays responsive to
commands. The remote UI is able to automatically reconnect if the
connection is lost for some reason.
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
