# Not equal datatypes

**URL:** <https://tech-community.robotics.abb.com/t/not-equal-datatypes/2499>\
**Category:** Developer Tools\
**Created:** [February 9, 2009, 2:36pm UTC](https://tech-community.robotics.abb.com/t/not-equal-datatypes/2499 "2009-02-09T14:36:01Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![Bergur](https://avatars.discourse-cdn.com/v4/letter/b/e9c0ed/32.png) [@Bergur](https://tech-community.robotics.abb.com/u/Bergur)\
**Post date:** [February 9, 2009, 2:36pm UTC](https://tech-community.robotics.abb.com/t/not-equal-datatypes/2499/1 "2009-02-09T14:36:01Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Ingela](https://avatars.discourse-cdn.com/v4/letter/i/53a042/32.png) [@Ingela](https://tech-community.robotics.abb.com/u/Ingela)\
**Post date:** [February 10, 2009, 12:58pm UTC](https://tech-community.robotics.abb.com/t/not-equal-datatypes/2499/2 "2009-02-10T12:58:45Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Bergur](https://avatars.discourse-cdn.com/v4/letter/b/e9c0ed/32.png) [@Bergur](https://tech-community.robotics.abb.com/u/Bergur)\
**Post date:** [February 11, 2009, 3:17pm UTC](https://tech-community.robotics.abb.com/t/not-equal-datatypes/2499/3 "2009-02-11T15:17:15Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Ingela](https://avatars.discourse-cdn.com/v4/letter/i/53a042/32.png) [@Ingela](https://tech-community.robotics.abb.com/u/Ingela)\
**Post date:** [February 12, 2009, 12:39pm UTC](https://tech-community.robotics.abb.com/t/not-equal-datatypes/2499/4 "2009-02-12T12:39:50Z")

</div>

Hello,

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

---

<div class="post-metadata">

**Author:** ![Bergur](https://avatars.discourse-cdn.com/v4/letter/b/e9c0ed/32.png) [@Bergur](https://tech-community.robotics.abb.com/u/Bergur)\
**Post date:** [February 12, 2009, 1:19pm UTC](https://tech-community.robotics.abb.com/t/not-equal-datatypes/2499/5 "2009-02-12T13:19:34Z")

</div>

Hi,

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

Regards,  
Bergur and Kalle

---

<div class="post-metadata">

**Author:** ![Ingela](https://avatars.discourse-cdn.com/v4/letter/i/53a042/32.png) [@Ingela](https://tech-community.robotics.abb.com/u/Ingela)\
**Post date:** [February 12, 2009, 3:58pm UTC](https://tech-community.robotics.abb.com/t/not-equal-datatypes/2499/6 "2009-02-12T15:58:56Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![jzoss](https://avatars.discourse-cdn.com/v4/letter/j/8c91f0/32.png) [@jzoss](https://tech-community.robotics.abb.com/u/jzoss)\
**Post date:** [February 19, 2009, 10:07pm UTC](https://tech-community.robotics.abb.com/t/not-equal-datatypes/2499/7 "2009-02-19T22:07:26Z")

</div>

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 `size=10
data="bool;FALSE"` This message is received okay. Next, send a message with a TRUE value. Again, inspection of the sendMessage variable shows that it has `size=9
data="bool;TRUEE"` 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

---

<div class="post-metadata">

**Author:** ![Ingela](https://avatars.discourse-cdn.com/v4/letter/i/53a042/32.png) [@Ingela](https://tech-community.robotics.abb.com/u/Ingela)\
**Post date:** [February 25, 2009, 11:03am UTC](https://tech-community.robotics.abb.com/t/not-equal-datatypes/2499/8 "2009-02-25T11:03:51Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Erik\_Hellstrom](https://avatars.discourse-cdn.com/v4/letter/e/ea5d25/32.png) [@Erik\_Hellstrom](https://tech-community.robotics.abb.com/u/Erik_Hellstrom)\
**Post date:** [June 18, 2012, 10:06am UTC](https://tech-community.robotics.abb.com/t/not-equal-datatypes/2499/9 "2012-06-18T10:06:28Z")

</div>

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.