Unstoppable RT Startup Application

[Mitch_Peplow]

Hi all,

Need a bit of help with something.

I built an RT app which runs at startup and uses network streams for communication and data transfer. The stop signal that kills all the RT loops is sent to a shared variable on the target from the Host via the network stream. All good, apart from one little issue . . . . the network streams wont connect so I cant stop the loops and thus it runs indefinitely

Now initially I thought fine, that's ok, ill amend the code and re-deploy, however because its running I cannot connect to the controller to change anything or re-deploy no matter which way I go about it.

Even forcing the controller into Disable RT Startup App mode wont allow me to connect or re-deploy.  

Any ideas how I can stop the application from running to allow me access or delete the application without doing a full reset as I don't want to lose the network configuration settings?

Cheers in advance.

Mitch

[mitchtheMG]

Hi Mitch,

My name is Mitchell Lewis, from National Instruments Technical Support.

With regards to your query, have you tried undeploying the real-time executable before re-deploying again? If you have done so without any success, I would suggest looking into a few alternative solutions at the following links to resolve the issue:

http://digital.ni.com/public.nsf/allkb/7BE1A1F4363C0465862569A6000319F9?OpenDocument

http://digital.ni.com/public.nsf/websearch/6EDCBF0F0498814F86256B570080DD20?OpenDocument

If all else fails, then you may need to perform a full reset on your RT device. With newer versions of the Measurements and Automation Explorer (MAX Version 5.0 or later), you should be able to perform a reset while retaining your network settings. You can find more information in the following link:

http://digital.ni.com/public.nsf/allkb/6B1343F61905203386257051006573CA

However, if the above solutions are unfeasible for you, I’d be grateful if you could provide the following information, so that I may better assist you:

1. The version of LabVIEW you are running
2. Real-Time device used
3. Is the device visible in MAX?
4. Any other troubleshooting steps taken (if any)

I hope that this information will be useful for you. If this is not the case, please do not hesitate to contact us and we would be more than happy to assist you.

Kind Regards,

Mitchell Lewis

National Instruments

Applications Engineering

www.ni.com/support

[Mitch_Peplow]

Morning Mitch (that’s to you, not to me )

Forgive my stupidity but where is the undeploy option as there is only the option to deploy when I right click the build?

I have indeed seen all those documents before, however I’m using a cRIO-9038 which runs Linux which I believe, and please correct me if I'm wrong, does not allow for FTP transfer/interrogation (not sure if legacy software can be installed to bring FTP capability back).

I have actually managed to get into the controller to stop it after much foul language and the threat of a bucket of water. Managed to get in using the USB emulated Ethernet Link-Local. I was able to connect and set both RT and FPGA to not run at startup then re-deploy. All good, however this has led me onto more issue.

The streams still won't connect, but I think I know why, however instead of using the stream to send a stop signal down to the shared variable I thought I would simply assert the stop in the Host directly which should then get read down at the RT side, but it does not see the state transition. If I assert the value via the distributed system manager the RT target stops straight away so the variable will work, just not from the Host. Any ideas why? The SVs are all set as absolute, not target relative.

The other thing is that  when I come to stop the Host, it now takes 5-7 seconds to stop the application whereas it used to stop in the blink of an eye and the only addition is the assertion of the SV stop signal. Why has the writing of a SV value slowed my code up so much?

Cheers in advance.

Mitch

[mitchtheMG]

Hey Mitch,

No worries mate, that’s what we’re for 🙂 Also, good to hear that you’ve been able to stop the application at startup on the VI.

Anyway, you should be able to find the “Undeploy” button when you right-click the cRIO target in your project tree. I’ve attached a screenshot for your reference (see "undeploy scr 1.png"), though the screenshot doesn’t have the "Undeploy" option on there. It should appear in the place as “Deploy” and “Deploy all” options. (see "undeploy scr 2"). It usually appears if you’ve already deployed the application on the cRIO.

If you’d like, I could have a look at your code, so that I could have a better idea of the issue? It might be alot easier to visualise the problem.

Kind Regards,

Mitchell Goon

National Instruments

Applications Engineering

www.ni.com/support

[Mitch_Peplow]

Hi Mitch,

I don't think I've ever seen a project with a remote target that has the undeploy option on the controller or indeed the build; it's always an option for the shared variables.

I need to have a play around when I get five minujtes to try the undeploy option and see if it does indeed remove everything, including the build, or if it just removes the shared variables. If this is correct then I'm assuming the removal of the rtexe is a manual operation only at this time.

The code I have is currently in the process of being stripped down to form part of a template so at this time I can't send you any code as the project needs a full cleanup, however there must be some common pointers to look at when a shared variable asserted on the Host does not update on the RT target? Remember it works when forcing the value through the distributed system manager.

Cheers

Mitch 

[mitchtheMG]

Hi Mitch,

Do correct me if I’m wrong, as far as I understand it at the moment, it could be a case of either the shared variables not updating to the DNS server quickly enough, possibly due to DNS timeouts or incorrectly configured network settings on the RT target, or that a shared variable was created from a custom control typedef, and is not properly linked.

The former can usually be resolved by re-configuring your RT target’s network settings. The latter is a known issue when creating shared variables from a custom control typedef, which can usually be resolved by using local variables instead.

In any case, these articles might be worth a look:

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

http://digital.ni.com/public.nsf/allkb/6E37AC5435E44F9F862570D2005FEF25?OpenDocument

I hope you find this information helpful and do update me if it resolves the issue.

Kind Regards,

Mitchell Lewis

National Instruments

Applications Engineering

www.ni.com/support