Not equal datatypes

Bergur

Hi,
we are programming PC SDK application with RAB 5.11 and simulating it in RobotStudio 5.11. We can update robot positions via this application (creating a queue and using "myQueue.send") and read current positions from the controller (using "RMQGetMsgData"). The problem is that the position update doesn't always work. If we send small position changes it works fine but if we send larger steps the RAPID program crashes at "RMQGetMsgData" and shows the error message:
RMQ Error - Not equal datatypes.
Description
Task:  T_ROB1. The datatype  in the rmqmessage is of the type robtarget and the datatype in argument Data is of the type robtarget.

We have the type robtarget in both the RAB and RAPID codes. Any suggestions?

Regards,
Bergur and Kalle
  

Ingela

Hello,

The first guess, from the error message, is that the bytes array that you send from the PC SDK is not correctly formatted in the cases where you get the error, (should be something like this):

    IpcMessage message = new IpcMessage();
    Byte[] data = new UTF8Encoding().GetBytes(?_orobtarget;[[930,0,1455],[1,0,0,0],[0,0,0,0],[9E9,9E9,9E9,9E9,9E9,9E9]]?__);
    message.SetData(data);
    rapidQueue.Send(message);

Can you show the code on the PC side and on the RAPID side:

1. When it works as it should

2. When writing a position fails

 

Bergur

Hi Ingela,
the code was the same both when we got the error and when it worked. It crashed kind of randomly.
We think we have solved the problem now. It seems like it was a problem with the Byte[] definition. Before we were using byte[] because we got errors when using Byte[]. However by removing "using ABB.Robotics.Controllers.RapidDomain;" and inserting "using RobTarget = ABB.Robotics.Controllers.RapidDomain.RobTarget;" instead we got it to work.

Now we are facing another problem. We can run the RAB/RAPID application when we run the RAPID code with the start button in off-line mode. However, if we run it with the play button in simulation mode it complains "couldn't obtain mastership of RAPID".
This is how we've tried to request mastership along with setting the controller to automatic mode:

using (Mastership m = Mastership.Request(controller.Rapid))
{
    //Perform operation
    robT = aMechUnit.GetPosition(CoordinateSystemType.World);
    //robT and aMechUnit declared before
}

Any suggestions?

Regards,
Bergur and Kalle

Ingela

Hello,

 

What happens if you run under RobotStudio Options - Virtual Time - Free Run? (still in simulation mode)

Bergur

Hi,

thanks a lot for the help. It works if we use the Free Run option. What does this mean?

Regards,
Bergur and Kalle

Ingela

Hello,

 

RS Help:

 

Time handling during simulation

When simulating stations with events or several controllers, or other time managing equipment, time can be managed in two modes: either as free runtime or as time slices. RobotStudio uses time slice mode by default, but you can switch to free runtime, if required.
Free runtime  Since all controllers use the same computer resources, their synchronization might not be exactly as in the real world if they run independently of each other (called free run mode). The cycle time will be correct, but the timing for setting signals and triggering events might be inaccurate.

Time Slice Time slices can be used to ensure that the timing for signals and other interaction between controllers is accurate. In this mode, RobotStudio synchronizes the controllers by dividing a time segment into small slices and waiting for all controllers to complete a current time slice before any controller can start anew. Thus, the controllers are synchronized, and the cycle time will be calculated correctly. The drawbacks are that the virtual FlexPendant cannot be open, and that the simulation might be somewhat slow and jerky, depending on the complexity of the simulation and the performance of the computer.

jzoss

Bergur,

I have also recently begun building a new PC SDK application that communicates with RAPID using the Messaging functions.  Today, I experienced a similar issue to the one you describe, involving the "Not equal datatypes" error.

In my test code, I have tracked this down to what I think is an internal RAPID bug.  When you use a persistent IrqMessage variable (as described in the examples), the message's "Data" member is not cleared when setData is called.  This should be okay, since the "size" member describes how many characters are valid for the current message.  The RAPID internal code seems to be ignoring this "size" attribute, however, and will complain with error 41694 if there are 'extra' characters in the data field.

webwiz/2811/RAB_Messaging_error_41694.zip

Try running the attached example code in C# and RAPID.  This code implements the basic messaging example described in the RAB application manual.  First, send a message with a FALSE value.  Inspection of the sendMessage variable shows that it has [code]size=10
data="bool;FALSE"[/code]  This message is received okay.  Next, send a message with a TRUE value.  Again, inspection of the sendMessage variable shows that it has [code]size=9
data="bool;TRUEE"[/code] Note the extra "E" character on the end.  This should be ignored, since it is outside the specified message size.  But this message causes the 41694 RAPID error.

As a workaround, try uncommenting the local sendMessage variable definition at line 55.  This will clear the message "Data" member everytime a new message is sent.  In this case, the same FALSE/TRUE message sequence will *not* cause a RAPID error.

Hope this can help (maybe)!

 - Jeremy Zoss
  Southwest Research Institute

Ingela

Hello,

 

This is a bug. We found out that the PC SDK erratically ALWAYS send 444 byte (no more, no less). 

Data must therefore be null terminated.

 

We have also found out that there is a problem reading the data if the PC SDK thread is running as STA. Changing it to MTA will solve that problem.

Ingela2009-02-25 11:10:25

Erik Hellström

Has the bug with the message size been resolved?

I'm using 5.14 and it seems like I always get 444 bytes messages even though the sent data is smaller.