回复： Re: Very hard to implement a long process dll or application in TestStand such as firmware download task.

[yangyang-rexxar]

Hi All

In my daily projects there are many firmware download tasks on mass production for kinds of products sucha s phone, mp3, game box and so on. The common download is performed via USB or serial port.

Firmware download is often a long process what will take up to hundreds of seconds. The download application or dll is often provided by customer or the chipset supplier, I have ever call a download dll in TestStand, the only way is to run the dll in another threading and at the UI threading I monitor the dll's log file for status, it looks a very stupid way to do, things oftn lose control.

This time I have to automatically download firmwares to a mp3(Sigmatel chipset), Sigmatel provided an application for parallel downloading what is very unstable, the application often hangs or crash, I tried to update the application source code but Sigmatel says they will not support if I change something.

If someone use the application, he needs to press the START button, if fail, press the STOP firstly, if crash..... everything lose control. In my opinion, even if I change the application to a dll, there are still long processes, I must let TestStand wait there for the log file information? I do not think that is a good idea.

My thought is this is a usual task in manufacturing, could someone please advice me how do you handle this kind of testing in your test station? How to run a long process task in TestStand and communicatio with it and keep everything in control.

Thanks.

帖子被paulbin在04-06-2008 07:49 PM时编辑过了

[j_dodek]

Hi Paulbin,

your words sounds from daily trouble in production line. You have written a programm and one part of it is from a supplier and this stuff is crashing and you HAVE to use it. You have spent hours and sometimes days with stupid workarounds and threads to keep it stable as possible. But for the production you are always the idiot. So welcome to club of TestStand idiots. I am a member since serval years.

Recently i have focused the Call Executable Step-Type. If you select "Wait for specified time" after this time the SDK Kill Process will be executed. Normally you know how long it takes.
If the dead time is reached windows kills the stuff. Oh! what about unclosed handles? You will see it on restarting uut. If it crashes at once you a stupid problem (I am sure you know it) but
if you have luck it could work extremly well and you are the winner.

One of my stranges workarounds was pressing a start button from supplier win32 application. Sounds boring but it as controlled by TS
Curious? Very Simple! Get the process handle. Then get the HWND of the process . Now take over the mousepointer and fake the mouse. Place the arrow to the button and
a WM_BUTTON_LEFT_CLICK. Thats all. Oh you can do this with Stop-Button, too.

Thanks for shaking out my heart

and greetings from the lake of constance, Germany

Juergen

All other Teststand-Idiots are welcome to shaking out their heart.
Or you have great TS workaround like injecting own code to external app/dll so post it here.

[yangyang-rexxar]

Hi man.

Should I write a VC dll for TestStand on get HWND and then control the mouse or is there any existing way to do in TestStand?

[j_dodek]

Hi,

I have used a VC++ dll

Here are some snipptes

void CProcessLoaderApp::PostMessageToProcess(LPPROCESS_INFORMATION lpProcessInformation,UINT Msg, WPARAM wParam, LPARAM lParam)
{
 FINDWINDOWHANDLESTRUCT fwhs;
 fwhs.ProcessInfo = lpProcessInformation;
 fwhs.hWndFound  = NULL;
EnumWindows ( EnumWindowCallBack, (LPARAM)&fwhs ) ;
 PostMessage ( fwhs.hWndFound, Msg, wParam, lParam );
}

BOOL CALLBACK CProcessLoaderApp::EnumWindowRcs5SystemTestCallBack(HWND hwnd, LPARAM lParam)
{
 FINDWINDOWHANDLESTRUCT * pfwhs = (FINDWINDOWHANDLESTRUCT * )lParam;
 DWORD ProcessId;
 CString Title;
 GetWindowThreadProcessId ( hwnd, &ProcessId );

 // note: In order to make sure we have the MainFrame, verify that the title
 // has Zero-Length. Under Windows 98, sometimes the Client Window ( which doesn't
 // have a title ) is enumerated before the MainFrame

 CWnd::FromHandle( hwnd )->GetWindowText(Title);
 if ( ProcessId  == pfwhs->ProcessInfo->dwProcessId && Title.Compare("MyApplicationName_ReplaceThatStuff") == 0)
 {
  pfwhs->hWndFound = hwnd;
  return false;
 }
 else
 {
  // Keep enumerating
  return true;
 }
}

 MainStuff:

SetCursorPos(10,23);
 m_App.PostMessageToProcess(&g_pi,WM_LBUTTONDOWN,0x01,0x000A0017);
  WaitForSingleObject(Event,200);
 m_App.PostMessageToProcess(&g_pi,WM_LBUTTONUP,0x00,0x000A0017);
  WaitForSingleObject(Event,200);

Greetings

juergen