Test and Measurement Forum

ps3000_close_unit

Post your C and C++ discussions here

ps3000_close_unit

Postby jma » Mon Oct 06, 2008 5:50 am

Hi,
I have been writing a program for PicoScope 3026 and I have encountered the following problem:

Sometimes when running the software and rebooting the computer, the close_unit is not run as it should. So after the computer has rebooted the scope is still "reserved" and next open_unit calls fail, until I remove the USB-cable.

Can the scope be "reset" in a programmatic way to avoid the reset-by-unplugging-the-cable behaviour?

BR,
JMa
jma
Active User
Active User
 
Posts: 7
Joined: Mon Oct 06, 2008 5:43 am

Postby ziko » Thu Oct 16, 2008 9:47 am

Hi jma,

Is this using our software or your own software? If it is our software what version are you using?

Kind regards
Ziko

Technical Specialist
ziko
Zen Master
Zen Master
 
Posts: 1705
Joined: Fri Dec 01, 2006 10:03 am
Location: St Neots

Postby jma » Thu Oct 16, 2008 10:50 am

Hi Ziko,

Thanks for your reply. I have written my own software to read data from the scope. The ps3000_stop and ps3000_close_unit seem sometimes to lead to a situation, when they fail in a way that causes the next (and any consecutive) ps3000_open_unit to fail. I was just wondering if there is a way to reset the scope to recover from this kind of situation.

BR,
JMa
jma
Active User
Active User
 
Posts: 7
Joined: Mon Oct 06, 2008 5:43 am

Postby ziko » Fri Oct 17, 2008 11:05 am

Hi jma,

If you are switching the pc off, hibernating the pc, or re-booting the pc the PS3000 device should be unplugged before hand.

Hope this helps.
Ziko

Technical Specialist
ziko
Zen Master
Zen Master
 
Posts: 1705
Joined: Fri Dec 01, 2006 10:03 am
Location: St Neots

Postby wayoda » Fri Oct 17, 2008 12:31 pm

Hi jma,
ziko wrote:If you are switching the pc off, hibernating the pc, or re-booting the pc the PS3000 device should be unplugged before hand.

I really hope this was meant as a joke....

I once had a similar problem with an USB-device that was connected through a self-powered hub. This specific hub did not switch the 5V supply-current off when the computer was powered down. When the comupter was restarted later my USB-device was found by the OS but unaccessible by my own software simply because the powersupply was not disrupted on reboots.

Check your machine wether the 5V supply voltage is switched off on shutdown or reboot.

Eberhard
wayoda
Active User
Active User
 
Posts: 11
Joined: Fri Aug 01, 2008 9:49 am
Location: Wuppertal/Germany

Postby jma » Wed Oct 22, 2008 5:17 am

Hi, Thanks for the pointers. The scope is sometimes located elsewhere in the network and the user may not have access to the room scope is in, thus disconnecting the scope is not an option.

If the scope does not have a reset-functionality of this kind, I think I should reset the USB connection to re-gain access to the scope?

BR,
JMa
jma
Active User
Active User
 
Posts: 7
Joined: Mon Oct 06, 2008 5:43 am

Postby Erik » Thu Oct 23, 2008 7:32 am

Are you running under windows/linux?
Are you using streaming mode at all?
Are you checking all of your return values from the driver calls?
Have you tried reading an error code using ps3000_get_unit_info with PS3000_ERROR_CODE?
Erik
PICO STAFF
PICO STAFF
 
Posts: 53
Joined: Mon Oct 23, 2006 8:16 am
Location: Cambridgeshire, UK

Postby jma » Fri Oct 24, 2008 5:36 am

Are you running under windows/linux?
-Windows

Are you using streaming mode at all?
-No only block mode

Are you checking all of your return values from the driver calls?
-yes, I call stop and close_unit in consecutive loops and check the return values.

Have you tried reading an error code using ps3000_get_unit_info with PS3000_ERROR_CODE?
-no I have not tried this

Can you show me a code-example how to use stop and close_unit in properly? What I do is I loop for the stop for say 10 times, with a small sleep (100ms) and then do the same with close_unit. (I use a 1s sleep) between a successful stop and close_unit, since there was a post on this forum I belvieve that calling close_unit too soon after stop may cause the close_unit to fail.

BR,
JMa
jma
Active User
Active User
 
Posts: 7
Joined: Mon Oct 06, 2008 5:43 am

Postby Erik » Fri Oct 24, 2008 11:00 am

in block mode you only need to call stop if you want to abort a capture.
get_values will call stop internally in the driver.
if you still want a stop call in there call stop before you call get_data.

Are you keeping the unit open whie your application is running or are you trying to close/reopen between each capture?

Which version of the driver are you using?

an example:


main() {
open();

loop {
run_block();
while(!ready());
stop(); // optional
get_data();
}

close();
}

If you don't mind sending me your code, I can have a look at it.

Regards

Erik
Erik
PICO STAFF
PICO STAFF
 
Posts: 53
Joined: Mon Oct 23, 2006 8:16 am
Location: Cambridgeshire, UK

Postby jma » Mon Oct 27, 2008 6:46 am

Hi Erik,
Thanks for your reply. It seems that the discussion is going to take a wrong turn. I think I have not been clear what I try to accomplish, so here goes.

I have no problem during "normal operation". I call run_block, get_times_and_values etc. and they work fine. I only call close_unit in destructor of my oscilloscope-communicator class.

The problems is that because the destructor of the communicator class may not be called in some circumstances when application is malfunctioning (the oscilloscope handling is implemented in a dll within our own framework) the closing of the connection to the oscilloscope may or may not be done properly (stop & close_unit).

Now when the watchdog restarts everything again, the next open_unit may fail if closing unit was not done properly, and afaik there is no way to correct the situation other than unplugging the scope, which is not a good solution in my case. So I would like to know if there is some way to regain control of the scope in this kind of situation without the unplug feature.

Kind regards and thank you for your patience :)
JMa
jma
Active User
Active User
 
Posts: 7
Joined: Mon Oct 06, 2008 5:43 am

Postby Erik » Mon Oct 27, 2008 8:27 am

Hi JMa,

I think understand what your problem is.
It is not a hardware/device problem. When opening a unit our driver creates a software lock to prevent it beeing opened by another process. If close_unit() is not beeing called, this lock will not be released until you unplug the unit.

Unless you can find a way to handle an application error/exception and close the unit then, I believe you're out of luck.

I am sorry I couldn't be of more help to you.
Erik
PICO STAFF
PICO STAFF
 
Posts: 53
Joined: Mon Oct 23, 2006 8:16 am
Location: Cambridgeshire, UK

Postby jma » Tue Oct 28, 2008 7:46 am

Hi Erik,
Ok, thanks for the information. It is always good to know what causes the issue. I think I have to study if it is possible to reset the USB connection silently somehow.

BR,
Jarkko
jma
Active User
Active User
 
Posts: 7
Joined: Mon Oct 06, 2008 5:43 am


Return to C and C++

Who is online

Users browsing this forum: No registered users and 0 guests