PCGU1000 First Period

Instruments PC Generators
1

I am using the PCGU1000 to generate a line synchronization signal for
3 line scan cameras. The line sync signal needs to be a square wave
which can be adjusted in frequency from 12 KHz to 18 KHz.

Currently I am using the FGULINK.dll from the file FGULINK_1.zip that
allows the application to run on Windows 7 without needing to run
as administrator.

I am using the following function call sequence to generate the line
sync signal.

[ul]
OpenGen();
SetGen( 2, 12000, 5, 2.5 );
// Wait 5 seconds
StopGen();
// Arm 3 Cameras
StartGen();
[/ul]

The problem that I am having is that the first period is not correct
as can be seen in the following signals that were captured by
an oscilloscope.

1024×768

1024×768

Is there some way to use the PCGU1000 and to get the correct
timing on the first cycle of the output waveform?

Is there some way to change the duty cycle on the square wave output using
FGULink.dll?

2

I do not believe that what you wish to do is possible with the current hardware/firmware–though Velleman’s support team have more than once delivered near miracles to meet a user’s needs…

Using StartGen() I was able to duplicate (or at least come close to) your observation:

Then I thought that perhaps activating/deactivating the -40dB filter might create a clean on/off of the output however this does not seem to be the case.

This trace was captured when toggling the -40dB filter off using the AttOn() library function:

Same-O, same-O…

Perhaps the support team can provide a solution, it seems that for your purpose the signal would have to toggle on at the rising edge of the first pulse…

3

I missed your duty cycle issue–the only way to affect that is to use a custom library waveform file. It is not difficult at all, here is a 10% duty cycle rectangular wave.

-1.0 (7200)
(0)   
 1.0 (800)

It pulls the output to a relative -1.0 for 7200 of the 8k data points; -1.0 (7200), switches immediately; (0) to a relative output of 1.0 for 800 data points; 1.0 (800). The relative output values will be scaled to your selected output level, the 8k points define on entire cycle of the output waveform that will be generated at your selected frequency…

4

Thanks for your tip about using a custom waveform to generate a variable
duty cycle pulse.

5

[quote=“bruce_a2e”]Thanks for your tip about using a custom waveform to generate a variable
duty cycle pulse.[/quote]

You are quite welcome.

What 'scope it that that you are using? It is a very nice display.

6

We have an Agilent DSO6104A oscilloscope.

7

Neat–my “top-of-the-stack” 'scope is an older Lecroy 9354L 500MHz instrument with a 2GS/s maximum real time rate. I also have a Lecroy 9450A 300MHz (400MS/s RT max), and a Lecroy Wavejet 312 (100MHz, 1GS/s RT)…

8

This PCGU1000 First Period problem will be tried to solve in the next release as soon as possible.

9

That would be amazing, thank you!

10

I’m very sorry but this problem seems to be hardware related (relay delay etc.) and cannot be resolved by the firmware update.

11

Looking at the schematic I had been wondering about that–can the startup of the DDS engine be delayed until the amplitude, filter, offset and attenuation settings have stabilised?

12

Thank you for this suggestion.
I’ll check if this is possible.
Anyhow quite large modification is needed to the FPGA firmware…

13

[quote=“cliffyk”]Looking at the schematic I had been wondering about that–can the startup of the DDS engine be delayed until the amplitude, filter, offset and attenuation settings have stabilised?[/quote]Thank you cliffyk for this comment.

Now there is added a 10ms delay before the waveform data is output.
This seems to help to solve the first pulse problem.
Here are some screenshots:



All these examples are with zero DC offset.

A minor problem occurs if there is DC offset setting other than zero.
In this picture can be seen how the offset voltage is output 10ms before the beginning of the waveform data:

The first pulse is not “very good”.
If the first pulse must be good too, you can’t use the offset.
Here is an example library waveform to get positive pulses having amplitude of 5V max:

1.0 (100) (0) 0.0 (400)

Here is the link to download the demo program and the updated file (fgu1000.bit):
box.com/s/i6u74udrfu2h6tmalqz9

14

Bravo! Again I am most impressed by your and Velleman’s support!

-cliff-

15

Now the newer version FGULINK_1.ZIP is also updated:
box.com/shared/a5ub2zlbjq

In this version it is possible to sweep library waveforms too.
This version doesn’t output any signal when the generator settings are changed.

viewtopic.php?f=11&t=6562
viewtopic.php?f=11&t=5244

16

Thanks to all the people who worked on fixing this problem.

Now I have my program working and generating the required camera timing signal.

I am using a library waveform that I created that goes from 0.0 to 1.0 and keeps
the offset at 0V.

I did have a small problem getting the SetLibWave() function working correctly
from by C++ program. It turned out that my C++ program was using an old
version of the FGULINK.dll from C:\Windows\SysWOW64 instead of the newer
file that was in my project directory. When it started using the newer version
of the *.dll file every thing worked correctly.

Again thanks for your help.

17

[quote=“bruce_a2e”]Thanks to all the people who worked on fixing this problem.

Now I have my program working and generating the required camera timing signal.

I am using a library waveform that I created that goes from 0.0 to 1.0 and keeps
the offset at 0V.

I did have a small problem getting the SetLibWave() function working correctly
from by C++ program. It turned out that my C++ program was using an old
version of the FGULINK.dll from C:\Windows\SysWOW64 instead of the newer
file that was in my project directory. When it started using the newer version
of the *.dll file every thing worked correctly.

Again thanks for your help.[/quote]

Velleman’s support is amazing, is it not?

18

Thank you for the reply.
It is good to see that everything works fine now!