LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

soft-reset PXI-System

Good morning,

 

I try to execute a "soft-reset" on a PXI-System, but I can't found any nodes to do this.

With "soft-reset" I mean a function like the ABORT and the RUN button in a VI. More precise, if you connect to the real-time target via "debug application" you get the normal frontpanel of the VI which is actual executed. With abort/run buttons now you can "restart" this VI, so you don't need a hard reboot of the whole PXI-System which take a long time to get a "clean" system state.

 

Is this posible?!

 

Thanks a lot

Heiko

0 Kudos
Message 1 of 7
(2,892 Views)

Hello Heiko.

I think I don't understand your problem: why do you want to restart your program?

Do your want a given VI to be called at will?

Do your want to restart the application if something is going wrong?

 

If your really need to abort your program your can do as follow (just an example):

 

- A main VI is executed at boot and calls dynamically a second VI. The main VI handles also abort requests sent by user through TCP/IP. This second Vi is the one performing the tasks of your program.

- If a request is received the second VI is aborted (see for instance https://decibel.ni.com/content/docs/DOC-15384/version/1) and then restarted.

 

(In my opinion there should be no need to abort and restart a program)

 

Best regards,

Marco

 

 

 

 

0 Kudos
Message 2 of 7
(2,881 Views)

Hello Marco,

 

on my RT-Target an executable is running at startup and waits for a command from HOST. The communication between HOST <--> RT-Target is implemented by using NSVs, the NSVs are provided by the HOST.

 

Example:

Now, if you start the RT-Target and the HOST is not available, the NSVs are also not available and an error occures. To fix this error, I have to

1. restart the RT-Target if the HOST is online OR

2. I connect via debugging to the running rt application and restart the application via "abort" followed by "run" button (also with HOST online). 

 

I want to do the second way programmatically, thats all. There is a function to restart the RT-Target (restart.vi, takes much time) but no one to restart only the running application.

0 Kudos
Message 3 of 7
(2,863 Views)

Hi!

 

I would use a plain TCP/IP (or even UDP) interface to send commands between host and RT-Target.

 

As for the error:

Which error do you get?

What happens to the RT-Side once you power up the host? the NSVs should become available...

Is it possible to see the relevant portion of code of RT-Target program?

 

 

Regards,

Marco

0 Kudos
Message 4 of 7
(2,857 Views)

Hey,

 

I think we strip off my initial problem, because I know WHY I get an error, this is all right (they are quasi correct and expected errors). I wrote only one example of an error, and some tests which get started have, this is induced historical, no timeout handling (like an polling HSI-Master).

 

I only want to do a "soft-reset" to spare time, that's all.

 

Thanks Heiko

0 Kudos
Message 5 of 7
(2,826 Views)

I'm wrestling with a similar problem, but I think I know how to fix it (just haven't had the time ...).

 

Background -- I "inherited" a LabVIEW RT program written using LabVIEW 7 (well before LabVIEW Project).  The PXI code was packaged into an LabVIEW Library (.llb) file and copied by FTP to a known location on the PXI's disk.  We used VI Server to locate the top-level VI on the PXI side and simply start it running.  At the end of the routine, we stopped the code on the PXI.  In this mode, the code was always present on the PXI, "ready to run", and we rarely had to reboot the PXI.  As a side benefit, we could have multiple PXI routines sitting on the PXI, each matched to a particular routine on the Host, with each Host routine starting (and stopping) its appropriate RT "partner".

 

I'm currently working on the much-revised, much-improved version of this program running on LabVIEW 2012 under LabVIEW Project.  My RT code is built as a Start-up Executable (.rtexe) and deployed to the RT Target as a Startup as part of the Build.  At the conclusion of the Host program, the RT program also exits, which (as you note) causes the PXI to reboot, meaning we cannot restart for a minute or so.  We also can't (easily) have multiple "pairs" of Host/RT routines that link themselves together at run-time (at least, not with a lot of extra work!).

 

I've been thinking about how to implement an "auto-restart" method for the RT code.  I don't think it would be too difficult, but have not yet tried to implement it.  My RT program consists of multiple parallel loops, with some initialization code at the beginning of the program (before the loops run) and some finalization code at the end.  The main idea is to get the program simplified to a single loop (in my case, a Queued State Machine/Message Handler) that internally starts and stops the other parallel loops (probably through a Start Asynchronous Call and a local Shared Variable "Stop Loops").  My current Exit State sets "Stop Loops" to True, breaks the connections with the Host, and exits the QSM, leading to the termination of the RT code.

 

One idea I'm planning to try is to add an additional State, "Restart", that is called by Exit instead of exiting the QSM.  This state would wait a few seconds (to let the other loops finish) and then perform (again) the initialization code that preceded the entrance to the QSM.  Note that this inevitably sets the initial QSM State, so on finishing the Restart State, the QSM's Initialization State should be next, "... and away we go!"

 

If you try this and it works, please post a followup here.  I'm anxious to try this, myself, but I've got other bugs to fix in this code before I can worry about "improving it" ...

 

Bob Schor

0 Kudos
Message 6 of 7
(2,799 Views)

Hello Bob,

 

thanks for your idea to solve my problem, I think it can work.... unfortunately only in your usage.

 

My RT-Loop consists basically of 3 states (like the NI example), "init, "wait" and "run". The init-state only executes if the RT-Target starts up. In normal operation and also if I can catch an error I switch back to the init-state and the RT-Target is back in normal condition.

Some Tests which run on the RT (all of them get startet over a dynamic call) can run in a infinite loop because there is no timeout-handling programmed in the test. So I was forced to handle timeouts parallel to the execution of a test. If now the test run in a timeout, I only have the chance to restart the PXI (this I do actually) or the I way I describe I want to do. I see no other way to abort a dynamically called VI...

 

Thanks and Greets

Heiko

0 Kudos
Message 7 of 7
(2,764 Views)