LV & External Software crashing

[Mitchum]

Hello, LV community!  I am at my wit's end trying to solve an issue that I am having.  I am hoping someone can provide some wonderful insight into why i'm having this issue.  I've attached an image of the block diagram where action is occuring based on user operation prior to LV crashing.  I'm somewhat "new" to LV, so excuse me if you notice anything redundant, weird, unecessary, etc. on the diagram (tips accepted, though!!!).  With that said, i'll explain below.

BACKGROUND:

I've created an installer that, ideally, can be used on multiple PCs.  This installer provides two executables and the LV-RTE.  The two executables are called DATA CONVERTER (LV-written software) and DOWNLOADER (non-LV software).  All that my executable does is basically use SystemExec.vi to call a specific function of DOWNLOADER.  From there, DOWNLOADER is used by the operator to download data log off of a PLC hardware.  The DOWNLOADER screen will show a progress bar from 0-to-100% to indicate when the datalog has been successfully transferred from the PLC hardware to the operator's PC.  The reason why DATA CONVERTER was created is two-fold: 1) check if the PLC hardware is connected to the PC via USB...if false, then it will prompt the user and the software will shut down.  2) To hide the full UI of DOWNLOADER by using command prompt to call a specific function.

ISSUE:

On many operator PCs and PLC hardware, the operation has been smooth from start to finish.  However, on three completely different operator machines, three different locations, and three different IT networks, they have reported that the whole thing freezes up and crashes.  What happens is this: The DATA CONVERTER successfully calls DOWNLOADER via the SystemExec.vi, but when the progress bar from DOWNLOADER comes up, both executables crash.  I uninstalled the LV software and ran DOWNLOADER to download the data log off the PLC, and it ran smoothly.

TROUBLESHOOTING:

I was remotely connected to the operator's PC and I decided to try running DOWNLOADER on its own (which meant the operator could see the full UI), but it still crashed at the progress-bar point.  I then decided to try removing all of LV that was installed on the PC, and suddenly the DOWNLOADER would run smoothly.  Next, I thought "maybe try to run this whole process under ADMIN and see if it works".  Therefore, I re-installed the whole package as ADMIN but the freezing and crashing started happening again.  I've tried a few other things but, in my mind, it seems like the issue occurs when LV uses SystemExec.vi to call DOWNLOADER.

Has anyone ever had an issue like this?  What could it be?  Any thoughts, opinions, etc is much appreciated.

PS: my block diagram has "UPLOAD" written all over it...but it's basically transferring data from the PLC hardware to PC.

-Mitch

[Vijay_J]

Your issue seems to be OS (Operating system) dependant. Have you analyzed under which OS it runs smoothly and under which it does not?

Does the Downloader.exe is developed using LabVIEW? 

I assume Data Converter and Downloader working consistently in some machine and it is not working at all in some other machines as described.

[Mitchum]

Prior to the described issue, the only other one i've seen was when I tested the installer on Windows XP.  Installation and full operation of both Data Converter and Downloader ran smoothly on four different PC's with Windows 7.  I then installed on three different PC's with Windows XPs.  Two out of three crashed during installation (my post here).  I eventually managed to install on all three Windows XPs but I had to do something involving ending the msiexec.exe processes.

The Downloader.exe is third-party from IDEC.

My understanding of SystemExec.vi is that it calls things via cmd prompt (please enlighten me if i'm wrong or not fully understanding this).  My hunch is that there is some sort of tight restriction by the IT networks that prevent running progams from running things via command prompt.  I would be interested in following this kind of lead, but I know nothing about IT networks and I may very well open up a can of worms that would eventually lead nowhere.

Currently, I have made only one modification to my software.  Per the SystemExec.vi on my block diagram, the "Wait Until Completion" has always been set to True.  I am switching to False and going to see if this would do anything...not sure if it would.  My understanding of this function is that, if true, the Data Converter waits until Downloader is done and closed (and if it hangs, it crashes, i guess?).  If false, the Data Converter just finishes its event while the Downloader is still running.  Would you agree?

[Joel-I]

Hi Mitchum,

Regarding the System Exec.vi, you're definitely correct that it uses the command prompt.  This Knowledge Base article should be useful:

http://digital.ni.com/public.nsf/allkb/8E19CA81874FFDD786256BE40066C151

Does the standard error output return any information?

Regards

[Mitchum]

Joel,

I'm going to recompile an executable to test out on the operator machine.  I'll be sure to include the standard error output and see if it will reveal anything.  Scheduled to do so on Thursday afternoon.

Thank you,

-Mitch

[Mitchum · Accepted solution]

Just wanted to close this thread with a "solution"...although it's not quite one (in my mind).

So, it looks like there was a certain GPO utilized by IT that encrypts the transfer of data through USB cables, making it unreadable or something.  Our typical cable setup for data transfer looks like this:

OUR PRODUCT   >>>   8-mini din to RS232 > converter > RS232-to-USB   >>>   OPERATOR PC USING THE SOFTWARE

Our team had taken a guess that most desktop PCs today will not have an RS232 port available, which is why we provided this whole setup.  But it looks like, for the operator PCs having issues, they happen to have the RS232 port on their desktops.

By setting aside the converter and RS232-to-USB, and then directly connecting the 8-mini din to RS232 cable, the GPO was not activated and data transfer was successful.