LabView array position in cluster causes problem with Simulink DLL

[PhilipJoeP]

For me, this is a very complicated question to ask because of its complexity and my lack of knowledge about LabView.  I apologize if I am not obeying the forum rules by mentioning other software products, namely MATLAB/Simulink.  The problem I am experiencing involve conflicting data types.

 

Little background about the application.  I am creating Simulink models and using Real Time Workshop to auto-generate DLLs of these models.  I then use the DLL blocks in LabView to initialize, execute, and terminate the DLL blocks.  The models I’m creating in Simulink (and therefore the DLLs) use Simulink bus objects (similar to clusters).  Within the bus object are smaller busses.  There is no consistent pattern as to how these buses are create within the main bus object, it all depends on the application. 

 

To create the “bus” object in LabView to send input data to the DLL, I can create clusters within clusters and wire this to the DLL block.  For the most part, this process works fine.  However, there is a specific problem I’m having when it comes to using arrays within the bus objects.

 

I have attached two zip folders to demonstrate this weird problem:

1. with array (good).zip
2. with array (bad).zip

[PhilipJoeP]

As the names imply, one of the zip folders contains a VI that works and the other does not.  In both folders you will find similar files.

1. Multiple_data_types_Array.mdl            (simulink model)
2. MultipleDataTypes_Array.m                 (loads Simulink bus object)
3. test_bus.mdl                                         (can be ignored)
4. Multiple_data_types_Array.vi     
5. Multiple_data_types_Array_win32.dll    (DLL file of Simulink model)
6. (two folders used to create DLL)

 

Note that the “bad” folder has two VIs:

1. Multiple_data_types_Array.vi
2. Multiple_data_types_Array2.vi

 

Note also that the Simulink models I’m using are test models that play around with multiple different data types.

 

***When running the VI’s, you will need to open up the DLL blocks (all three) in the block diagram and make sure that the DLL blocks are pointing to the DLL file found in the same folder.  And you want to avoid confusing the DLLs and paths since the names are very similar if not the same.***

[PhilipJoeP]

When you run the “good” VI with the default inputs, the correct answers appear in the indicators to the right of the main cluster.  All I’m doing with the “Array” in the cluster control is passing it through the DLL model and outputting it as an array indicator.  (The Simulink model used to create this DLL accepts the VI array and uses it as a Simulink array within the Simulink bus object.)  In the Simulink bus, the array is the last element in the bus object.  I have also reordered the elements in the VI cluster control to match the order in the bus object (again with the array being the last numbered element in the cluster).

 

However, when you open up the “bad” VI folder and open up “Multiple_data_types_Array2.vi”, you can see I repositioned the array control in the cluster as the third element in the cluster.  (And yes, I renumbered the elements in the cluster to reflect this.)  I also edited the Simulink model bus object so that the array is the third element as well.  When you run the VI, you do not get the same (correct) answers as the previous VI.  Everything looks good up to the “Cluster 32” indicator.  You can see that the sum indicator is now indicating 5 instead of 11.

[PhilipJoeP]

Here is the problem I’m seeing.  When an array is placed in between elements in a cluster control, and when using a Simulink model as a DLL, something goes wrong with the data that is positioned AFTER the array.  This was also confirmed by a fellow colleague when he tried to do the same thing.  In the case of the “good” VI, there was nothing else after the array in either the Simulink bus or the LabView cluster… therefore, all the calculations were fine.

 

It appeasr that there is an indexing problem when using LabView arrays with Simulink arrays, in which everything is one off.

 

Here’s another something interesting.  If you go back into the “bad” folder and open the “Multiple_data_types_Array.vi” VI, you will see I’ve replaced the array (in the third element of the cluster control) with a cluster of four numeric controls.  When I wire this cluster to the same DLL, and pass this cluster into the array element in the Simulink bus object, everything works fine!  Therefore the problem is with using the LabView array.

 

I know this is a very long post, but I figured if anyone wanted a tough problem to look at, this might be it.  I hope that the problem is simply a user error on my part.  I’d appreciate any help if possible. 

 

Thanks!

[Jon_S.]

Hello PhilipJoe,

I looked at your code and also experienced the same results as you did.  I did a little research found a KnowledgeBase article that discusses cluster alignments not matching with structures in a Visual C++ dll. I am not sure what compiler Simulink uses but I think that this could be the root cause. Also have you ever considered our Simulation Interface Toolkit? This program allows you to easily integrate a Simulink model into a LabVIEW program.

Simulink® is a registered trademark of The MathWorks, Inc.

[PhilipJoeP]

Jon,

Thanks for the response and link!  This might be the problem.  I will give it a shot/

Yes, SIT would make integrating with Simulink models simple.  Unfortunately, it's not an option yet for us.

Thanks again.

[nathand]

If alignment doesn't solve the problem, I would highly recommend using a cluster in place of an array in your LabVIEW structure; you can treat that cluster like an array within Simulink since the representation in memory is the same.  The difference is that a cluster has a fixed length and therefore can be embedded directly into the same memory as the rest of the cluster.  An array can be variable length so it has to be stored external to the cluster, with a pointer in the cluster to that memory location.  Your post stating that using a 4-element cluster in place of the array makes your code work suggests that using a cluster in place of an array is the right solution to your problem.

[PhilipJoeP]

If anyone is curious how this was solved, see this post.

http://forums.ni.com/ni/board/message?board.id=170&message.id=405986&jump=true

Phil