07-08-2008 04:44 AM
07-09-2008 06:17 AM
07-10-2008 04:16 AM
07-10-2008 06:15 AM - edited 07-10-2008 06:24 AM
Apolgies posted before I was ready (Tabbed to submit by accident whilst I was typing and rapidly hit space!)
07-10-2008 06:15 AM - edited 07-10-2008 06:23 AM
Apologies posted before I was ready (+ double post)
07-10-2008 08:16 AM
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!
07-10-2008 08:33 AM
07-10-2008 08:39 AM
07-11-2008 04:14 AM
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!
07-11-2008 05:07 AM