Has anyone ported LabVIEW to VxWorks 6.6?

[bill__]

I was wondering if anyone had ported the LabVIEW runtime library to VxWorks 6.6 using microprossesor SDK. My final target is a motrola 6100 VME SBC running VxWorks 6.6. 

If someone has done this....have you been sucessful in implementing Queues? Timed Loops? Clusters? 

[Claire_Reid]

Hey Bill,
Have you check out the LabVIEW Microprocessor SDK Porting Guide?

Message Edited by Claire R on 06-21-2009 11:01 AM

[bill__]

Claire,

I have looked at the porting guide, and have had some sucess with simple VIs running on our target! But now I am stuck with a series of other problems. I have not sucessfully been able to use:

-Variants (Sucessfull compile, and load on target, but get a runtime error)

-Queues (Sucessfull compile, and load on target, but get a runtime error)

-Timed Loops (Not sure how to create the timing source needed)

-File I/O (Not sure if this is supported)

-RTFIFOs (sucessful compile but unsucessful load on target--symbols are undefined. I think this problem may be on the forums already regarding confilcting RTFIFO files between LabVIEW Microprocessor SDK vs. LabVIEW Realtime Module but not sure)

I know these are a lot of issues, but any help would be much appriciated. 

Thanks!

Bill

[Claire_Reid]

Hey Bill.

Can you please post the error codes that you are getting so I can do a search on them.

[Claire_Reid]

Hi Bill,

Please post your error codes if you still require help on this.

[bill__]

Claire,

Upon some more debugging it is clear that a problem exists upstream of these individual functions which is casuing the error.

The problem is that we are unable to pass data between subVIs using clusters on our embedded (VxWorks) target.

The exact same VI will function properly under (1) native LabVIEW windows environment and (2) windows console, however it will not function properly on  the VxWorks target. An example of the output differences between target types is provided below:

Windows Console (expected behavior):

--TYPE before SubVI--

 4

--Words before SubVI--

 100

--TYPE inside SubVI--

 4

--Words inside SubVI--

 100

--TYPE after SubVI--

 4

--Words after SubVI--

 100

VxWorks Target (incorrect data passed):

--TYPE before SubVI--

 4

--Words before SubVI--

 100

--TYPE inside SubVI--

 4

--Words inside SubVI--

 0

--TYPE after SubVI--

 0

--Words after SubVI--

 0

I think that there is some alignment issue which is causing the data to be dropped, though not positive. I have a zipfile that I could email you with our project and the generated code. Could I email it to you?

[bill__]

I made a change to LVDefs_plat.h for vxworks which seems to tackle the alignment issue.

#define ALIGNMENT __alignof__ (double)

to 

 #define ALIGNMENT __alignof__ (int)

Seems to fix it. I  am now gathering infor regarding downstream issues.

Thanks,

Bill

[Claire_Reid]

Hey Bil,

I am out sick today, but I will deifnitelu take a look at all of this tomorrow.

[Claire_Reid]

Hey Bill,

If you are using the C style function calls build option, front panel control and indicator values in the top-level VI are not generated correctly and are ignored.

Workaround:Use a top-level VI with an empty front panel or do not use the C style function calls build option.

[Bill_in_Detroit]

Bill:

Did you ever get past the problems you were having getting LabVIEW running on the VxWorks platform?  I am trying to keep my company on a LabVIEW embedded track for long term volume development but keep hearing noise from LabVIEW deniers that say "people that know" say that they have reviewed LabVIEW Embedded for (whatever use) and that it has "too much overhead".

What do you think?  I figure by now you should have an opinion.  Anyone else that actually knows (has experience with getting LabVIEW code ported to hardware platforms other than sbRIO) the answer, feel free to chime in.

Bill_in_Detroit