I’ve purchaised two PCS500 oscillocopes and one PCG10 generator for my experiments. I need the oscilloscopes to run in single measurement mode syncronously to generator and some other equipment, moreover all these devices should be connected to single PC (it already has 2 LPT ports) and they should be driven by LabVIEW that will generate the waveform for PCG10 on the fly.
Trying to solve my problem I’ve already explored the dso_link.dll and found that it allows only to read the data from PCS500 device and only when the PC_Lab2000 software is running.
I’ve explored the pcs100_dll_package that provides most of the functions required for normal control of oscilloscope but unfortunately it does not work with PCS500.
I’ve explored the fglink.dll and found that it can send to PCG10 only the waveform previously saved to file.
After all these adventures I want to ask the following questions:
Is there any library or sample program code available which one provides the FULL control of PCS500 and PCG10 devices?
or -
Is there any description of lowlevel communication protocols for PCS500 and PCG10 devices?
You are right, full control via a DLL is only available for the PCS100 and K8031 oscilloscopes, and somewhat for the PCG10 and K8016 function generators too. For the moment there is no such dll available for the PCS500.
The low level control is described in the following manuals on the Velleman supplement CD: PCS500_operation.pdf, Using the printer port.pdf, PCS500-9a_cir.pdf, K8016_PCG10 operation.pdf and PCG10_8016_Diagrams.pdf. It is, however, very difficult.
A more complete dll for the PCSU1000 oscilloscope is currently under development. A dll for the PCS500 may be also developed in the near future.
The DLL for the function generator is quite complete for normal functions and for the sweep function. You can also load the user waveform if you can save it first to a file from your LabVIEW program.
Thank you for referencing me to the documentation. I haven’t browsed the CD at all before that.
It’s not really hard but it would be better to have the protocol description or sample code. If the same had happen ten or fifteen years ago then I used the disassembler w/o any doubt but today it will not be effective when you have to understand the code that tracks the exceptions and calls the kernel driver in order to perform the trivial “in ax,dx” operation.
Hello again.
I’m trying to access the PCS500 from LabVIEW but w/o any success. I wrote the VI for sending settings to oscilloscope (IC4…7). When I try to turn off the device that is currently on it works fine but when I try to turn on the device that is currently off nothing happens. The process is organized according to text of PCS500 Operation Description. (I have to note that the picture describing the shift registers loading differ from the corresponding text since the POWER_OFF bit transfer is ommitted on the picture and the RCK1 line behavour is inverted. The description text seems to be closer to circuit diagrams.) The graph of LPT port line signals during the real attempt to turn on the device can be found here http://projets.ru/image/lpt-timing-2.gif. Attempts to inverse the RCK1 line and/or CLK1 line were unsuccessfull too. I tried to to capture the LPT port line states when the PCLab2000 transfers the data to PCS500 but my data acquisition card is not enough fast. Please tell me what is wrong in my approach.
You get the power on by pulling the signal POWER_ON down. This is the output of optocoupler IC30. To keep the power on you have then to put IC4 output pin 7 low. After this you may release the IC30 output.
If you will look at the oscillogram then you will see that everithing goes according to your reply: the 25-th from left (or 8-th from right) high-low-high transition of CLK1 signal (red line) corresponds to low state of DB0_DATA signal (white line). According to specifications this should latch zero to 7-th output of IC4 at following high-low-high transition of RCK1 signal (blue line) but nothing happens in fact. The green line on the graph corresponds to pin 14 controlling the EN inputs of 244 element (IC16). It seems to me that the oscillogram fully corresponds to PCS500 description and scheme, and this algorithm has to work fine (to turn on the oscilloscope) but it doesn’t work. Where is my misstake.
Below there is a fraction of code that turns the power on.
There is a delay about 10 ms after pulling the IC30 output down. The time is based on the “out dx,al” instruction that takes about 1 us.
The delay is needed to charge the capacitors of the power supply.
After the 5 V on the board is OK and the LED LD1 lights, you can send the sequence to load the shift registers.
Here is the power on sequence of the program:
asm
mov dx,pr_port
add dx,2
in al,dx
or al,00000010b {244 on}
out dx,al
out dx,al
mov dx,pr_port
mov ecx,10000 @lo1:
mov al,11111011b {db2_load = 0}
out dx,al
loop @lo1
add dx,2
in al,dx
and al,11111101b {244 off}
out dx,al
end;
Now the DLL for PCS500 oscilloscope is ready to download from Velleman web site. The package contains updated PCS500.EXE program, PCS500D.DLL, instructions for use and example programs with source for VB and Delphi.
Thank you for PSC500 control DLL – it’s usefull but does not fit my requrements since the PC_Lab2000 (PCS500.exe) does not support more than one oscilloscope per one PC.
I need to run two oscilloscopes synchronously and to make them start measurements at the same moment of time using the external trigger signal which one occures every 200ms. Since the original software can work only with one oscilloscope and synchronisation of two PCs via the network some fails I continued to work at the LabVIEW driver for PCS500. I’ve already finished most of driver parts (including the control of two oscilloscopes) but I’ve got several questions.
20 steps of channel zero adjustment DAC is equal to one div of currently used channel scale, and value of 128 corresponds to zero offset, am I right?
Can you describe the “official” calibration with related ADC readout and DAC output conversion procedures?
Currently I use the following formula to convert the ADC readout to real input voltage value input_volts = ( ( -input_ADC - zero) / 32 - y_offset ) * volt_div
and the following formula to convert the desired y-offset (in divs) into corresponding DAC value DAC_code = DAC_zero - y_offset * 20
where zero is a value corresponding to zero volts (determined from calibration for each volt/div and equals to 128 by default); y_offset is a channel y-offset in divs; volt_div is a scale used during acquisition; DAC_zero is a value corresponding to zero channel offset (determined from calibration and equals to 128 by default).
Your calculation for the input_volts looks OK.
In my PCS500 the DAC code 76 affects the trace displacement to the screen edge. So the calculation should be:
DAC_code = DAC_zero - y_offset * 19
I used the the same method to determine the div-to-DAC_code conversion coefficient but I thought that it should be a good round number (decimal or binary). Also I thought that it could be known from the PCS500 circuit designer.
I’ll check your coefficient with both my PCSs. It seems to me that 19 is really more precise value.
Indeed, it is better to fine tune the y-offset value case by case. The component values of the circuit are selected to get proper y-position adjustment range by the sliders that output values between -128 and 127. Due to the analog components (voltage reference of the DAC, resistors and transistor) there is some variation in the DAC value that causes the y-offset of one division. The average value seems to be 19.
Your LabVIEW driver project for the PCS500 is interesting!
Hi!
I tried to work with your generator PCG10 not running fg.exe but all I’ve been able to do is turn it on.
I use fglink.dll to operate generator. It’s working correctly when fg.exe is running but if it isn’t generator reply false on command GenReady()
What can you advise me?
Is It possible to operate you generator by means of fglink.dll if fg.exe isn’t running?
you see, it is seemed like exact duration of signals are very important and standard windows timer can’t ensure necessary accuracy.
fastime.dll i think is facility to do this…
So you telling there is no way to control generator not using fg.exe and FGLINK.DLL control not generator but program which in its turn control generator. Am I right :oops:
You are right in both things:
Fasttime gives good 1 ms resolution and intervals starting from 1 ms for the timers. Standard Windows timer interval is about 50 ms.
Sorry, but the only way to control the generator is via the FG.EXE. It is huge program including all the hardware communication routines and calculations for waveform generation.
