Teach Pendant Removal

As We want to remove Teach Pendant Completely from Robot. So, I want to handle all the errors that might happen between Controller Bootup to Arm Power on. I search about that but I can’t find anything relevant to that but i am able to get safety state like fault ,Emergency stop, Protective Stop from RTDE Port but is there any way to get exactly what is that error like that was shown in teach pendant through some existing ports like I saw Primary interface provides robot message explanation is that gives errors from bootup to arm power on? or any other way can I get the errors and resolve some minor errors by putting program in controller itself or else if I want to acknowledge to some serious errors to my external TCP/IP client without teach pendant. Can anyone suggest me some way to do above tasks.

The only way is to implement client for primary interface - this is what UR GUI is doing.
Most of the tasks in production “headless” configuration can be done using “dashboard server”, and then revert to TP for programming, or debugging.

Primary Interface will give me errors same like that gives to TP right? Dashboard Port and Primary Interface are the ports that works for TP(UR GUI) like PowerOn,Moving…etc Is that You are saying?

Correct, those two interfaces provide most data needed.

Thanks @mmi can you gave me sample code for unpack data from 30001 for package 20? because I can’t get data for Robot Message like safety mode message,robot comm message…etc. or else can you explain me how data will send to 30001 port like i receive first package 20 that contains robot version message and then i got package 20 but type was 12 that was not defined in ClientInterface_Primary pdf and then i got package each one of 23,24 and then i got only packages of 16 and 5 repeatedly. How can i get RobotMessage(20) types like safety mode message(5) ,robot comm message(6)like that …

Unfortunately we don’t have example code for parsing data sent on primary interface, as it’s not recommended for regular integrations.
In principle you need to ignore all non-documented messages, and reserved fields in documented messages. All messages have type and total length.
Most message types are sent only in specific conditions.

Thanks for your reply @mmi why it’s not recommended for regular integration?

I can get safetymodemessage(20) when pressing emergency stop i got all data mentioned below image except these robotMessageCode,robotMessageArgument,reportdataType,reportData are 0 only why?.

Data I got: ‘\x00\x00\x00\x14\x00\x00\x00\x01\x1e\xb6\x0eX\xfe\x05\x00\x00\x00\x00\x00\x00\x00\x00\x07\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\t\x05\x00\x00\x00\x00’

There is enough information in safetyModeType: 7 = emergency stop safety state.
In case of Fault, there would be more detailed error code.

PrimaryConnector.zip (6.5 KB)
This was the code I am using for data parsing can you check Is that Working Properly?