Problem with Real-Time Deployment

[DeltaJ]

Hi All,

I have developed a Real-Time application and it has been running perfectly well on my PXI in the development environment. However when I try to deploy it as an rtexe I seem to be running into problems. The code is made up of a number of subVIs (about 😎 which talk to each other using queues. These are all in a launch vi that I just call 'Controller'.

As a debug step I have put a piece of code in 'Controller' that will write a time-stamp to a file when it starts (Run on Startup). When I compile my code with all the subVIs present the file is not written when I reboot the PXI box. I have identified one subVI which stops the .exe starting/running correctly. By removing this - and compiling and running with the other 7 subVIs - my file is written to.

My question is what things should I try next? Are there particular things I should look out for in the problematic SubVI that I can delete to get the code to start properly? Or any steps I can take when compiling the .rtexe that might make things work? I have just been using the default settings so far.

And finally any hints about the best way to debug my code (on a RT-box) in general would be excellent - I'm fairly new to Real-Time so in the absence of a front-screen I am relying on writing to a text file to flag when/if things are occuring. Is there an easier way?

Many thanks,

Dave

[DaHelmut]

Hi DeltaJ,

The first thing you should check is that you are correctly handling errors in your VIs.

Are you merging errors and handling these properly in your RT VIs ? I mean, are the error inputs / ouputs present in each VI and connected to one another in the main VI using other VIs as SubVIs?

Also, you should have a look at the VI called "RT Debug String.vi" which allow you to output a message either on the screen or the RS232 port (cRIO, FP, etc).

I joined a VI I made a long time ago to debug a PXI. It allows you to log errors in a file and show the errors on the screen connected to the PXI (I do not have the RT module installed that's why you see a "?" for the VI "RT Debug String.vi"). The main VI is "Error.vi" and it takes an array of error cluster as input to write the errors that occured in your application.

 

Regards,

[DeltaJ]

Hi Maxime,

Many thanks for the code - I'll definately give it a try. And especially the tip about the RT Debug String VI.

However I really think the problem I am having with my code is compile problem rather than a specific error. The every first thing I do in my code is log to a file and with my problem VI in place I don't even get this. It seems that the error with the subVI is stopping the code even launching properly (although I do know the rtexe is launching because I can't access it to delete it).

Has anyone seen this problem before or are there specific LabVIEW functions that just shouldn't be in a Real-Time exe? The really perplexing thing is the code runs perfectly within the RT-Dev environment - its only when deployed that it won't run!

Many thanks again,
Dave

[DaHelmut]

Hi,

Well ok. Can you give us an overview of your code where you write to this file ?

Are you using constant file path ? Or are you building the path using several LabVIEW VIs ?

Are you writing to the PXI harddrive or an external storage device (USB) ?

Regards,

[DeltaJ]

Hi Maxime,

I am writing to the hard-drive of the PXI box - my path is simply c:\log\<timestamp>.txt. I have tried multiple builds both with and without my 'problem VI' - with the VI missing the file is written too (my deployment launches) and with the VI present the file is not written to....so I am assuming my deployment is failing to start!

Many thanks again for following up,

Dave

[DaHelmut]

Hi Dave,

Can't you send a snapshot of the VI that causes the application to stop executing ?(or the VI itself)

Regards,

[DeltaJ]

Hi Maxime,

I'm posting the VI won't do any good - although I say SubVI I should clarify that it is about one half of my entire application and is in-fact made up of about 150 SubVIs. My application is quite large.

My next step will be to take smaller subVIs, place them in the application and see if they alone prevent the compile. As soon as I can identify which low-level SubVI is causing the problem I will certainly post it.

In the mean-time in case it sparks any thoughts with you (or anyone else) the hardware in my application is a combination of Serial Comms and CANOpen. Some of my other (working) subVIs have CANOpen present but only the problem VI has VISA and CANOpen subVIs present.

Many thanks again,

David

[DaHelmut]

Hi Dave,

What version of LabVIEW are you using ?

What is your PXI controller ?

When you are running your application do you see an increase (big enough to explain the reboot) in the CPU load of your PXI controller ?

Regards,

[DeltaJ]

Hi Maxime,

I'm developing in LV2009SP1 and I am using a PXI-8110 running RTLV9.0.1.

The reboot is not being forced by the program - I am doing this manually (or through the dev environment) as my application is running 'set to startup'.I haven't been monitoring CPU usage - can I do this in MAX?

Running correctly - as it does in the dev environment - the program should write my debugging tag to a file and then one VI monitors a shared variable for a value change. All the other VI's wait (to dequeue an element). Unfortunately when deployed the code doesn't even get to the 'write debugging tag to a file' step.

Many thanks,

David

[DeltaJ]

Hi Maxime and all,

I seem to have isolated the problem VI - or at least one of them. It seems that the inclusion of OpenG 'Write INI Cluster' will prevent the executable from running when outside the development environment.

This has occurred in a very simple test VI. I have also tested the MGI 'write anything' as part of a real-time deployment and this seems to work okay. I'm going to replace 'Write INI Cluster' with 'MGI Write Anything' and hopefully my executable will run.

I will advise on how I progress. In the mean-time has anyone come across a work-around for this or possible another alternative?

Many thanks,

David