PC SDK 5.14.02 Userdefined crash

labu

Hi all,

We have a PC SDK App which used to worrk fine dealing with fairly sophysticated RECORDS.

While upgrading to 5.14.02, where it is said in the release notes that some changes where made at init of UserDefined for better initialisation, everything turns weird...

_data = new UserDefined(DataType) does not generate any components and any attempt to reach components makes a System.Exception...

The same for the DataType.GetComponents().

I am running under VS2010 in Framework 4.0 (mandatory for vision app and performance)

I have to add that any RapidData pointing to a record returns a System.Exception when trying to access Value.

It seems to me that any user record which includes records (standard or user) fails to initialise.

Looking at the stack clearly shows it's relative to the added initialisation

   A? ABB.Robotics.Controllers.RapidDomain.UserDefined.GetComponentsAndAppendDefaultValue(RapidDataType objRapidDataType, String& fillData)
   A? ABB.Robotics.Controllers.RapidDomain.UserDefined.get_Components()
   A? Test40.Form1.button1_Click(Object sender, EventArgs e)
   A? System.Windows.Forms.Control.OnClick(EventArgs e)
   A? System.Windows.Forms.Button.OnClick(EventArgs e)
   A? System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
   A? System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   A? System.Windows.Forms.Control.WndProc(Message& m)
   A? System.Windows.Forms.ButtonBase.WndProc(Message& m)
   A? System.Windows.Forms.Button.WndProc(Message& m)
   A? System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   A? System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   A? System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
   A? System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
   A? System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
   A? System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
   A? System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
   A? System.Windows.Forms.Application.Run(Form mainForm)
   A? Test40.Program.Main()
   A? System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
   A? System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
   A? Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
   A? System.Threading.ThreadHelper.ThreadStart_Context(Object state)
   A? System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   A? System.Threading.ThreadHelper.ThreadStart()

SAMPLE DATA FOR ANALYSIS

 RECORD gripperconf
    num headsdown;
    num headsvac;
    num headsblow;
    num toolnumber;
    num prodspercycle;
  ENDRECORD

  RECORD ppspointdata
    string name;
    ...
    gripperconf conftool;
    speeddata h_speed;
  ENDRECORD
 
  RECORD toto
      string name;
    num val;
  ENDRECORD
 
  RECORD tata
      string str;
    speeddata sd;
  ENDRECORD
 
  TASK PERS toto montoto:=["toto",12];
 
  TASK PERS tata matata:=["tata",[1,2,3,4]];

The only data workabe is montoto of toto type (only atomics)

URGENT FIX NEEDED AS IT IS A MAJOR REGRESSION
 without any easy workaround

labu

Still buggy on 5.14.03 

John Wiberg

Hi labu,

 

This has been dispatched to R&D.

---

For testing purposes, from which version did you upgrade?

Have you run this on 5.14.01? (Since you say the changed behavior was in 5.14.02).

 

labu

Hi,

Yes it is ok in 5.14.01.

On another hand, I am wondering why should a Userdefined be initialised with default values wheres it is a safe way to make sure your  data has relevant info in if items are non null.

What is the goal behind this default init?

I feel it should be optionnal as this might compromise older apps relying on != null to make sure the data is valid.

John Wiberg

Hi labu,

 

R&D has looked into it and there is an issue with the update just like you have observed.

There will be a fix for that in the next release.

 

Right now we are looking into if there are any workarounds. We have some interesting leads with how and when the RAPID is declared, which can prevent the behavior. As soon as we have tested further I'll give you an update.

labu

Hi John,

We are currently still blocked with 5.14.01 and new robots are delivered in 5.15

Has this issue been fixed?

labu

Hi John,

 

Could you please confirm that the issue is fixed as we have got the same problem with PC SDK 5.15 connected to a robot in 5.14.01