LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Abort/Exit 3rd party program

Hi!

 

I've developed a test system that flashes a device via a 3rd party flasher (hardware and software).

Sometimes the 3rd party program freezes or crashes for an unknown reason, can be hardware or software.

 

I communicate with the 3rd party program in a separate loop and uses the System Exec.vi to call the 3rd party program via its Command Prompt tool.

I am pretty sure, without actually having tested, that the rest of my application is responsive and running.

 

Question:

I could implement a timer function that after X milliseconds says "Hey! You havn't completed the flash sequence in the time I gave you, ABORT!'.

But... is there some way to kill that 3rd party program automatically when a timer indicates a problem? Without the user having to open the Task Manager and end the process manually.

Or maybe another way to solve the problem.

 

Best regards

Peter

0 Kudos
Message 1 of 20
(3,898 Views)

You may use the same "System Exec.vi" to kill the program.

-----

The best solution is the one you find it by yourself
0 Kudos
Message 2 of 20
(3,890 Views)

Can I kill a process from the command prompt? Or you mean I should call some function in the 3rd party toolbox?

0 Kudos
Message 3 of 20
(3,881 Views)

You can kill a process from the command prompt. Use "taskkill /im <processs name>/f. Google for more information

 

Good luck

-----

The best solution is the one you find it by yourself
Message 4 of 20
(3,877 Views)

What is that 3rd party device?

 

Funny story:  I was working along side another developer that was having a simillar issue.  Out of the blue the 3rd party flash programmer would just hang up.  This is not desired in high volume automated production test systems.  After a few days of banging on the problem they asked me for ideas.  I immediately whent to the manufactures web-site saw they had a FAQ section and that FAQ#2 was "Is the xxx Device suitable for automated high volume systems?"

 

BINGO!  one more mouse click and I found the answer.  "No, this is not an anticipated use case for xxx device.  Every once in a while the device becomes unresponsive requiring a system reboot to restore proper operation."

 

This is what I call "Other people funny"  its only funny when it does not happen to you.


"Should be" isn't "Is" -Jay
Message 5 of 20
(3,863 Views)

Jeff: Its a SEGGER ARM Flasher. I like the product commad tool interface. But unfortunatly this happends now and then for no obvious reason.

0 Kudos
Message 6 of 20
(3,837 Views)

P@Anand: Thanks! I'll give it a try!

0 Kudos
Message 7 of 20
(3,836 Views)

@PeterPoPS wrote:

Jeff: Its a SEGGER ARM Flasher. I like the product commad tool interface. But unfortunatly this happends now and then for no obvious reason.


That device has a remote interface!  just use VISA to send serial commands to the darned thing.  (Works well- I've done it but, lack example code since I don't work at that place anymore)


"Should be" isn't "Is" -Jay
0 Kudos
Message 8 of 20
(3,820 Views)

I know, but you loose some functionality when you communicate via serial and it behaves differently.

 

By using the command prompt and the USB interface I can select flash speed (before and after init). Also when the device is flashed it starts the flashed application. These two options should be available in the serial interface too since you can store a project file on the device and use it.. But it doesn't work.

Message 9 of 20
(3,812 Views)

Are you using their J-Flash program?  I have never had an issue with it not responding.

0 Kudos
Message 10 of 20
(3,810 Views)