Hi Jake,
I’m writing some software which requires OpenGL and XEM communication. My program calls ReadFromPipeOut() every frame (that is 11ms). When I unplug the USB, sometimes this function doesn’t return. To be sure that everything is valid I check GetDeviceCount() right before performing the operation. When the function freezes GetDeviceCount() is still 1. Apparently the driver didn’t perform the update of the information yet.
How can I avoid this problem?
Thank you so much.
Fabrizio
Don’t unplug the USB. 
I will look into this and see if I can reproduce this issue here. I will try to get back to you on this early next week.
HEY! are you becoming like Microsoft?? 
“Your XP is too slow now? just format the hard-drive” :).
Seriously. Thanks. Let me know if you need anything else to reproduce the problem.
Fabrizio
Fabrizio-
I think the best option at this point is for us to add a method for timeout to the ReadFromPipeOut and WriteToPipeIn methods. I will try to get this setting worked into the 1.3.0 release of the API.
Fabrizio-
Try this out… The Pipe function will fail when the board becomes disconnected. Of course, if this is something that could happen, your software will then need to check connectivity.
okFrontPanel.zip (144.2 KB)
Ok Thanks a lot Jake!!! This is what I was looking for. I’ll give it a try.
Fabrizio
PS: Is this part of the 1.3.0? Can I still download the new release?
This will become part of the 1.3.0 release. However, it is not currently part of the 1.3.0 alpha that has been posted.
Hi Jake,
Is this modification also part of the 1.3.1? Because I’m doing some plug/unplug tests and my software freezes always during the ReadFromPipeOut function 
Ciao
Hello-
The fix is in 1.3.1. I just tried with the PipeTest. I setup a long transfer and unplugged during the transfer. I get “WriteToPipeIn” (or “ReadFromPipeOut”) failed. I can then reattach the device and reconfigure it.
Are you not seeing this behavior with PipeTest?
Odd… I see this behavior in the PipeTest program. I recompiled/linked my progam many times, just to be sure that the result was linked with the newer library. Yet, it freezes if I unplug. I’m writing a very simple demo and try again.
What operating system are you using?
Hi Jake,
I just wanted to be sure to isolate the problem, so I run some tests. This is what I found. I created a very simple setup. On the FPGA I used the exact VHDL I use in project with the communication problems. To test the communication failure I wrote a simple C++ program that retrieves a specific number of bytes. This program does use only the new okFrontPanel library (1.3.1).
I discovered that if I retrieve up to 1024 bytes (included), the ReadFromPipeOut function fails always as expected. If I increase the number of bytes (even to 1026), the functions does not return, or it does, it does it for a couple of times and then freezes :eek: . This is a very odd behavior. What can it be?
Thank you so much
Fabrizio
Hi Jake,
I just wanted to be sure to isolate the problem, so I run some tests. This is what I found.
I created a very simple setup. On the FPGA, I used the exact VHDL I’m using in the project with the communication problems. Since the function involved in the error is a reading function from a PipeOut, the DSP side of the project is not involved at all.
To test the communication failure I wrote a simple C++ program that retrieves a specific number of bytes. This program does use only the new okFrontPanel library (1.3.1).
I discovered that if I retrieve up to 1024 bytes (included), the ReadFromPipeOut function fails always as expected. If I increase the number of bytes (even to 1026… by the way, my program uses transfers of 4096 bytes every about 5ms), the function does not return, or if it does, it does it for a couple of times and then freezes. This is a very odd behavior. What can it be?
Thank you so much
Fabrizio
PS: To answer to your previous question, I’m using XP pro.
Thanks Fabrizio, I will have a look at it this week.
Hey Jake,
did you have a chance to look into this problem?
Thanks
Fabrizio
Hi Fabrizio
Unfortunately, we have been unable to replicate the problem you’re having. Each time we disconnect the device, the API returns a failure code. We are also using Windows XP (SP2) here.
Does the issue depend on your configuration file? i.e. can you reproduce the results using just the PipeTest code, for example? (pipetest.bit as well as the PipeTest.exe)
If I understand you correctly, you say that the PipeTest does not work for you either – it hangs when you detach the device. Is this true?
Have you been able to try another PC?
Hello,
I was wondering if this was ever resolved, and how to tell (using the C/C++ Lib) if the XEM has been disconnected. I am currently having my PC lock up when the XEM looses power… note that the power jumper is pulled because the XEM gets power from another board…
Thanks,
Bill
Hi Bill,
No… actually this problem wasn’t solved. No matter what I do to check if the board is connected or not, if I unplug the FPGA the PC freezes. I just tried on a brand new PC with 1.3.1 installed. Nothing… I decided to write a very simple test and give it to Jake because he was unable to replicate the bug. Let’s keep in touch.
Fabrizio
Hi Fabrizio,
Yes I’m bothered by the same concerns… My applications lock up when the peripheral I am working with is turned off… Not every time, and It hasn’t gotten to the point where I am trying hard to find the problem… Although I have had the XEM crash my machine, (BSOD w/ USB message) and once took the hard drive with it… (that really hurt). One thing I have that is different from the “norm” is I am running the XEM on external power, so the “hot plug” feature built into the connector is not utilized, and thus my application may be more difficult to deal with… But I would still think that the device driver should know what applications are attached, and allow them to return with failure, rather than locking up the app, or even the machine, and who writes communications calls to device drivers with void returns?
I wrote to ask Jake for a “recommended” way to make sure the machine is alive, but I still havn’t gotten a reply… check out my posts…
It also looks like the checkXEM() you suggested didn’t work either… oh well…
I’m really hoping that either Jake starts fixing these problems, or would release his source code, so the community can… I would hate to end up writing wrappers for everything- to spawn com tasks with timers- so that I can kill them when they lock up… bad enough I had to put a wrapper on the pipe-out to know how much data is ready to be read…
Well good luck… I will be plugging away here, probably get the Cypress Kit out in the long run if there isn’t another way…
Stay in touch… Bill
Bill-
Thus far, we have been unable to replicate any freezing during an operation if the XEM is detached. PipeTest, for example, doesn’t gracefully die because it isn’t written to handle detachment, but it also doesn’t hang. Our FrontPanel application, however, is designed to gracefully handle detachment. (but it also doesn’t perform any pipe transactions)
The recommended way to handle detachment under Windows is for your application to listen for the WM_DEVICECHANGE event. This event is sent any time a USB device has been added or removed from the system. When you receive this event, your application must rescan the devices to see if the XEM serial number you were talking to is still available.
We presently use the Cypress driver as our underlying device driver. Unfortunately, that puts us at their mercy and reliant on their programming prowess. I apologize if you lost any data when their driver crashed.
As with many programming issues, the “right way” is often much more complicated than the simple examples provided. Capturing the WM_DEVICECHANGE is one thing FrontPanel does that our samples do not do. We avoided this complexity in our samples because, in some cases, it would double their size. Likewise, many of our applications written for clients use multi-threaded and mutexed access to the device which is necessary in some cases. Again, for some programmers this is simply too complicated to follow.
Done right, the PipeTest sample would include multi-threaded access because it can perform long operations with the device that otherwise clog up the Windows event loop. It would also process the WM_DEVICECHANGE. These are programming practices more in-line with good operating system programming and less with talking with our API, so we decided to leave them out – it’s more Microsoft’s charge to show examples of good OS programming.
If there is interest, we would consider adding a WM_DEVICECHANGE processor to a sample. It would probably be better suited to a new sample, but I’m not sure. Any suggestions?