PSCU1000 DLL feature requests

Instruments PC Oscilloscopes and Recorders
1

Gentlemen -

Please consider adding the following features to the PSCU1000D.DLL

[ul]Parallel set of “Getter” functions providing ability to query current state of all instrument features. This would allow seamless use of either the Scope GUI or a third-party control application without ambiguity about the current instrument state.

Ability to set Time/Div down to .02uS. Current DLL only supports to 2uS

Add entry into registry providing installation location of the PCSU1000.EXE application, so that third-party controls can launch the GUI if it is not already running. Alternately, provide a DLL call that launches the GUI if it is not running and does nothing if it already is.

Provide means of reading Waveform Parameters for each channel.

Provide DLL function to copy Scope screen to clipboard
[/ul]

2

Hello Jim,

Thank you for your suggestions to improve the DLL for the PCSU1000 oscilloscope.
Adding the “Getter” functions to query current state of the instrument settings is a good idea. I think this will be added in the near future to the DLL.
Current DLL supports all the real time sample rates up to 50MS/Sec. The highest sample rate is achieved at 2uS/DIV range.
To get the 1GS/Sec ranges 0.2uS to 0.02uS running, it needs more care from the user to set the trigger On and to set the trigger level properly to get solid waveform image on the screen. If the GUI is not visible then there is possibility to get erroneous results. This is why the 1GS/Sec ranges 0.2uS to 0.02uS are not supported by the DLL.

Reading the Waveform Parameters via the DLL is also good idea. I think this feature will be added to the DLL in the future as well as the copy to clipboard and starting the PCSU1000.EXE application via the DLL.

3

I am aware that use of the 1 GS/S mode requires corresponding configuration of the trigger. Nevertheless, I submit that all essential functionality of the instrument should be accessible via the DLL. As it stands now, I can’t use this powerful feature of the scope in my automated test application.

Furthermore, it would be entirely feasible for the DLL to automatically enable trigger mode whenever entering the high-speed sampling mode, as does the GUI already.

By the way, shouldn’t the DLL provide a means of detecting when the trigger has fired, so that the application can read the DSO data immediately after the trigger condition has been met? How else can application software efficiently query for DSO waveform data when triggering is enabled, whether in 1GS/s mode or not?

4

Indeed, it seems that the 1GS/S mode has to be added to the DLL.
Also some kind of means of detecting when the trigger has fired will be added.
This all will be added to the next release of the DLL.

5

Providing a query function which indicates when the trigger has fired is good. However, ideally, the DLL should also include a method allowing an application to obtain a handle to a DLL-managed Windows event which is asserted (by the DLL) when the trigger condition is met. This approach allows multi-threaded applications to efficiently process asynchronous instrument-related events without having to resort to (inefficient) polling.

In the future, additional events could be added to provide notification for all other important state changes such as button presses on the GUI (to allow third-party tools to remain synchronized to the GUI), range errors or any conceivable exceptional or asynchronous condition. Applications can then use WaitForMultiObjects to efficiently block on any or all of these conditions simultaneously.

6

There is now a new DSOLink.DLL, PCSU1000D.DLL and PCSU1000.EXE available for testing. Manuals are also updated.

Modifications:
No need to add any delay after the DLL calls. The DLL waits and blocks the thread until the main software responds.
Note: Do not close the main software PCSU1000.EXE from its GUI when the DLL is in use. Instead use Stop_PCSU1000 DLL call to close the oscilloscope program.
Put the Stop_PCSU1000 function call to your applications exit routine to ensure that possibly hidden PCSU1000.EXE terminates.

Added Start_PCSU1000 and Stop_PCSU1000 functions to the PCSU1000D.DLL.

Added DataReady function to DSOLink.DLL. This function can be used to check if there is fresh data available from the oscilloscope. Indicates also when the triggering occurred.

Now the 1GS/s time/div ranges are also available via the DLL.
Note: The triggering is automatically put on by the PCSU1000.EXE program.

Not yet done:
Reading Waveform Parameters for each channel.
A DLL function to copy Scope screen to clipboard
The “Getter” functions to query current state of all instrument features.

Get it here: PCSU1000 DLL

7

All of the features seem to work fine for me except for the Start_PCSU1000 function. I can’t get that method to work within my testbed code, nor does it work properly in your supplied Delphi-based example.

Now, perhaps I mis-used it somehow. Initially, I extracted the contents of your new ZIP to my network drive and copied the new DLLs to my Windows\System32 folder. Then, I ran the PCSU1000Run.exe demo. When I clicked on the Start PCSU1000.exe button, it launched the scope GUI. The GUI started to auto-calibrate, but hung. Then the PCSU1000.exe demo hung. I had to use task manager to kill both the demo and the GUI. Subsequent to that incident, I have not been able to get the demo code nor my testbed to successfully launch the scope GUI. But, if I launch the GUI manually, both the demo and my testbed can successfully shut down the GUI.

Your thoughts?

8

Sorry, it was not mentioned in the documents that the PCSU1000D.DLL must be in the same folder where the new PCSU1000.EXE is put. Please remove the PCSU1000D.DLL from the Windows ’ System32 folder and copy all the files from the zip package to a new folder. Then run your application or PCSU1000Run.exe in that folder. Should start the PCSU1000.EXE too.

9

I have deleted Pcsu1000D.dll and DsoLink.dll from the Windows\System32 folder and placed the new versions of these DLLs into the PCSU1000 installation folder C:\Program Files\Velleman\PC-Lab2000SE. Nevertheless, I still cannot successfully launch the GUI using the new DLL call. I receive an error dialog which reads “I/O error 103”, as shown below:

http://www.innovative-dsp.com/ftp/Work/Pcsu1000%20launch%20error.jpg
– VEL448: Please use the url tag for large pictures.

Another thing I’ve noticed is if I manually launch PCSU1000.exe instead of Pc_Lab2000se.exe, I am not confronted with the Velleman port selection dialog, and the scope GUI application starts directly and hangs in exactly the same way as shown above. Perhaps you are attempting to launch PCSU1000.exe within the DLL and this is somehow problematic?

10

The error message “I/O error 103” appears if the PCSU1000.EXE doesn’t find the file st_m.bit.
It seems that PCSU1000.EXE tries to locate the file st_m.bit from wrong location if launched manually. Normally PCSU1000.EXE is launched from within Pc_Lab2000se.exe.

Please make following test: Create a new folder and extract all the files from PCSU1000_DLL_Demo.zip to that folder.
Then run PCSU1000Run.exe manually in that folder and check if you get PCSU1000.EXE running from it.

11

I confirm that if I run either the Velleman demo program or mine when launched from within a folder containing the files extracted from the DEMO zip file, everything works fine.

However, I hope you will lift this restriction on the final version of the DLL. This co-location requirement is awfully inconvenient.

12

Thank you for testing the software. Indeed, it is rather inconvenient to copy all those files to the application folder.
I try to locate the reason to the problem and improve the final release of the DLL.

13

There is now a new “GetSettings” function added to the PCSU1000D.DLL. Also the software path is now stored to registry. So your application needs only to locate the two DLLs (DSOLink.DLL and PCSU1000D.DLL) either from SYSTEM32 folder or from your application folder.
This features are included to the latest version of the PCLAB2000SE software.
You may download the v2.05 of the PCLAB2000SE and the pcsu1000_dll_package.zip from velleman.be/be/en/download/files/

14

I downloaded and installed the new DLLs and scope application. Unfortunately, I am unable to successfully retrieve instruments settings via the new GetSettings call.

I have verified that the function is present in the new DLL, and while I can seemingly call the method, passing a pointer to an integer buffer, my buffer remains unmodified following the call.

Secondly, I am still unable to Start the scope application via the DLL call unless I set the current working folder for my application to be the folder containing the PCSU1000 DLL and scope application. While this can be accomplished via a call to SetCurrentDir, it requires that I fetch the pathspec to the scope application folder from the registry to discern the install location.

Any thoughts?

15

Have you run the PCLAB2000SE.EXE program after its installation? If not, then run it.
When run it, then the path to the PCSU1000.EXE will be put to the registry and the PCSU1000D.DLL finds the path and can start the PCSU1000.EXE from your application folder. This is mentioned on page 1 of the PCSU1000D_DLL.PDF document.

The key in the registry is: HKEY_LOCAL_MACHINE\SOFTWARE\Velleman\PcLab2000SE. There Value1 contains the path.
I tested once again: I copied only the following files to a new folder from the DSOLink_demo_Delphi.zip :
PCSU1000Run.exe
DSOLink.dll
PCSU1000D.dll

Then I run the PCSU1000Run.EXE and click “Start PCSU1000.EXE” button and the PCSU1000.EXE starts from its install folder.
Also the “Get Settings” button seems to work OK.

16

I am very interested to the new feature :
“…No need to add any delay after the DLL calls…”

I can not download the upgraded DLL from this forum because the link to the “PCSU1000 DLL” does not works.

I have also tried to download all the latest versions in the USA and BE download area but always i get the old “PCSU1000D.DLL”

The zip says to be updated in the May-2007 but the “PCSU1000D.DLL” is always Feb-2007 and i must always use a very complicate wrapper and many delays finely manually tested…

SORRY FOR MY HORRIBLE ENGLISH !!!

Bye from Livio

17

There are no PCSU1000D.DLL updates after the Feb-2007 version.
Strange that you have to add the delays.
Could you please describe the problem more detailed (possibly with some source code snippets).
Are you sure that you replaced the old DLL from the Windows\SYSTEM32 folder too?
Do you have the latest PcLab2000SE version 3.05 installed?

18

I was using the DLL from : “fgulink_rev3.zip”
and from : “pcsu1000_dll_package.zip” (updated 4-5-2007)

I deduced from your message that the best place where i can found the most recent updates is always the most recent PcLab2000SE…

Now i download the PcLab2000SE 3.05 and I try if the delay are not necessary.
Normally i prefer the “not installed” versions and “isolated” applications so now i will install PCLAB2000, copy the important files end then disinstall it.

Regard to my delays they are as follows :

Gen_Start
'
Scope_TrgOn
Scope_TrgSource 2
Scope_TrgEdge 1
Scope_TrgLevel 90
'
Scope_Voltage1 0
Scope_Coupling1 2
Scope_YPosition1 0
'
Scope_Coupling2 1
Scope_YPosition2 0

And my wrapping functions are as follows:

Public Sub Gen_Start()
StartGen
Sleep 5000
End Sub

Public Sub Scope_TrgOn()
TrgOn 1
Sleep 30
End Sub

Public Sub Scope_TrgSource(n As Long)
TrgSource n
Sleep 30
End Sub

Public Sub Scope_TrgEdge(n As Long)
TrgEdge n
Sleep 30
End Sub

Public Sub Gen_Set(ByVal func As Long, ByVal freq As Single, ByVal ampl As Single, ByVal offset As Single)
SetGen 1, 1, 1, 0
Sleep 100
SetGen func, freq, ampl, offset
Sleep 100
End Sub

If I remove delays (a use a sleep-window api) then many commands are not executed.
The main delay is after “StartGen” and sometimes, when the system is busy also with this great delay (5 seconds) some following command is not executed.

The “SetGen” command must be preceded with a “dummy” command
with some parameter set to a different numerical value.
If I do not send this preliminary command and two “SetGen” or “SetSweep” commands with the same parameters are issued then only the first is executed.
This is wrong because if the frequency is changed (for example by a
human command ) then a new SetGen must be executed always.

bye and thanks for your patience to read my english…
Livio

19

I have downloaded the “pclab2000se_3_05.zip” and I have discovered that if i unzip it and then run SETUP.EXE in a folder with a long name (more that 128 characters) windows says : “Incorrect parameters”

Then i have moved the folder in the following folder :
“C:\Documents and Settings\Livio\Desktop\TEMP and System pointers”

and the installation now is OK !!
the spaces in the folder name are also OK

I will write to you when the test are complete…

bye
Livio

20

The FGLINK.dll is not updated. It needs some delay between the instructions.
The PCSU1000D.dll is updated and should not need any delays. It is strange that you have to add some delays there too…