LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

SIT Issues - Undefined Functions and non-compilation

Dear All,
 
FIrst off hi! Am new to LabVIEW, SIT and the forums. I currently have an issue with SIT 4.0 that I hope you can help me with.
 
 
Background:
 
We are trying to move a Simulink model off of a Windows environment into a cRIO-9004. This will run the simulation on startup and will get its data and will pass its data via UDP links (2 x Transmits, 2 x Receives). The system will not have a host VI, it is to run stand-alone in that respect.
 
Currently we have a model working fine in Simulink. It communicates both locally and over the network using custom UDP blocks that we wrote in C (and so have src for).
 
 
Issues:
 
Currently when we try to build a DLL from ANY model (even a simple output of a constant) the model will autocode into C and a DLL will build but when importing it into LabVIEW we are told that there are functions defined in the DLL that are not defined in the header (it lists a standard 21 functions [i.e. NISIT_<fn name>] ). The header seems to define a different 4 (or 5 - currently not to hand apologies) <Model name>_<fn name>. These are soemthing like Initialize, Update, Output, Terminate.
 
So I cannot currently import. The 21 functions seem overkill to manually define in the header but am I wrong? Why is the SIT not writing the header correctly. This issue relates to a model without our UDP blocks, the UDP functionality would be added around the DLL in LabVIEW using standard LabVIEW function blocks.
 
 
In addition, rather than directly importing the DLL we considered directly deploying a DLL with the UDP functions embedded in it. However, when using RTW in Simulink it autocodes to C fine, but upon compilation into a DLL is raises issues (in true MATLAB style, typically vague and non-helpful). Any ideas?
 
 
Many thanks for any of your time,
 
Rich
 
 
Additional Info:
 
  • LabVIEW 8.5 (with Real-Time Module)
  • MATLAB 2007a
  • MS VC++ 6.0
  • The engineer who wrote the custom UDP blocks suggests that it might be an issue with using WinSock in his blocks
  • Any other info please ask 🙂
0 Kudos
Message 1 of 16
(3,870 Views)
Hi Rich,

Hope you are doing well today! I am looking into this issue for you and will post back soon when I have the right answers. Give me a day! If you have any questions/comments, be sure to let me know.
Adnan Zafar
Certified LabVIEW Architect
Coleman Technologies
0 Kudos
Message 2 of 16
(3,845 Views)
Hi Rich

What is the exact error message and error code you are getting? Can you post some screen shots or try copying and pasting the error and error codes? Just to make sure, does this error actually occur with any model including very simple models?  Are there any differences in the error for a simple model versus your model?

Are the 21 undefined functions created by you or purely by the Simulink compiler? Are you using nidll.tlc as your System Target File?

If the model you are trying to build does not use your custom UDP blocks, then why do you believe the issue is related to using WinSock in those blocks?

Adnan Zafar
Certified LabVIEW Architect
Coleman Technologies
0 Kudos
Message 3 of 16
(3,821 Views)

Apolgies posted before I was ready (Tabbed to submit by accident whilst I was typing and rapidly hit space!)



Message Edited by RichardJarvis on 07-10-2008 12:24 PM
0 Kudos
Message 4 of 16
(3,813 Views)

Apologies posted before I was ready (+ double post)



Message Edited by RichardJarvis on 07-10-2008 12:23 PM
0 Kudos
Message 5 of 16
(3,813 Views)

Adnan,

Thank you for looking into this and I must apologise, my original post wasn't all that clear with hindsight. So I will answer you questions and try to be clearer on the situation:

There are two situations and issues here.

1) Any simlpe model (i.e. constant -> output, or say pulse_gen -> transfer_fn -> output) will happily compile and link to a DLL using you nidll.tlc and the makefile etc that it produces. When importing the DLL (just standard import, not using SIT Connection Manager) I get an error, however:

 

2) When exporting a DLL (like above) it will load fine onto the target when using SIT Connection Manager, no errors like above.  We thought of using this method to do everything in Simulink and use the SIT connection manager as above to load it all. The issue we were having with this is that the UDP blocks that were custom written would not compile when using nidll.tlc and the makefile etc. It will run fine as an s-function in Simulink. The engineer who wrote the blocks thinks it might be that your makefile would not like the UDP blocks as they use Winsock and he assumes that the makefile will raise an error as winsock will not be in the LabVIEW environment.

So to fully answer your questions:

1) What are the exact codes?

When examining the error in Situation 1 that's exactly what I get. Interestingly if I include all the header it lists on the right hand side (clearer in the following screen print) then LabVIEW hangs when adding parsing the "simstruc" headers: (N.B. if you are looking at the addresses of these images then ignore the name of this one!)

The other error I'm getting with regards to the UDP blocks manifests as follows (ignore Paint in the background showing the Config Screen):

 


2) Does the error occur for any model or just yours?

The errors surrounding the missing functions concerns any model when importing (SIT Connection Manager seems not to mind). The error when compiling/linking the DLL surrounds just our model due to the UDP blocks


3) Are the 21 undefined functions created by you or purely by the Simulink compiler?

We haven't touched any of the files after they are thrown out of the compiler. The 21 or so functions it lists all begin NIRT_<FnName> (N.B. I previously posted wrongly stating NISIT_<FnName>. NIRT_ is correct) so I assume that's the compiler. The ones defined in the header (the 4) all start <ModelName>_<FnName>

The functions I assume I want (copied from the produced header file - I have not edited it. RWFJMildModel is the name of the Model file. There are no instances of the letters NIRT):

/* Model entry point functions */
extern void RWFJMildModel_initialize(boolean_T firstTime);
extern void RWFJMildModel_output(int_T tid);
extern void RWFJMildModel_update(int_T tid);
extern void RWFJMildModel_terminate(void);


The ones LabVIEW finds in the DLL (due to the DLL_EXPORT I imagine) and not the header can be seen in previous screen prints.

 

4) Are you using nidll.tlc as your System Target File?

Yes all instructions provided online, in the SIT 4 help etc are followed and this includes using nidll.tlc:


5) If the model you are trying to build does not use your custom UDP blocks, then why do you believe the issue is related to using WinSock in those blocks?

The model we plan on using eventually currently includes the UDP blocks, although if we cannot import them we will wrap the UDP functionality around the "rest of the model DLL" in LabVIEW provided we get that working. The other models are simple (as in thrown together in less than 30 secs) and I have no reason to believe this, I think this confusion was caused by my terrible first post, apologies.


Thank you for you help, it is much appreciated

Rich

P.S. My company blocks imagehosting sites so I cannot confirm if the screen prints are in place, in the right order etc. They should however all be there!

0 Kudos
Message 6 of 16
(3,797 Views)
Hi Rich,

Can you try posting the images in a .zip file? Name them appropriately so I can associate them easily. Thanks for the comprehensive answer.
Adnan Zafar
Certified LabVIEW Architect
Coleman Technologies
0 Kudos
Message 7 of 16
(3,795 Views)
0 Kudos
Message 8 of 16
(3,792 Views)

Hello Rich,

The RT OS that can be found on the 9004 controller supports/include some C, C++, Win32 symbols and one of the DLLs that we support is wsock.dll.  So it might be so that most of the function calls that is taking place is supported by the OS but you should be able to verify this by creating the DLL using RTW and the compiler you currently use and then test the DLL using our DLL checker utility that can be found here:

http://digital.ni.com/public.nsf/allkb/0BF52E6FAC0BF9C286256EDB00015230?OpenDocument

Just make use of the correct checker corresponding to the version of LV RT you use.

Then you can see if any errors exist in the DLL if it contains any function calls not supported by the OS and see if any Windows related calls take place that Pharlap don’t support.

Of course if functions related to SIT is thrown just ignore those for now – but you have at least a chance to rule out if the errors are related to the Winsock functions or not.

Hope this helps!

Regards,
Jimmie Adolph
Systems Engineering Manager, National Instruments Northern European Region

0 Kudos
Message 9 of 16
(3,776 Views)
Hi Rich,

Some other questions for you:

Why are you trying to import the DLL when not using the SIT Connection Manager?  From your screenshot, it looks like you are using the Import Shared Library Wizard.  Am I correct?  If so, is there a particular reason as to why you do not want to use the SIT Connection Manager?  The SIT Connection Manager is made to read the DLLs and understand them, so that is why it should be used with these DLLs that you are trying to import.
 
My next question involves using some of the models that are shipped with SIT. Have you tried the procedure with the sine wave example?  If you are continuing to have problems with this, then there may be a problem with the install of the software since these models are known to work.
Adnan Zafar
Certified LabVIEW Architect
Coleman Technologies
0 Kudos
Message 10 of 16
(3,770 Views)