I´m really impressed about the signal generator PCGU1000´s features.
I´m programming a user-interface which auto-generates lib-files for variable pulse train signals.
Using fgu.exe V. 3.03 and fgulink.dll from FGULink_Demo_VB2008_express that I downloaded from your support site there are some crash-situations for certain lib files.
I have uploaded a zip-file with representative parameter-libs to box.net/shared/d303f230kqqrrd676lu9
I have tried those lib files with fgu.exe V. 3.03, V. 4.03 and V. 5 ( from your FGULink_v5).
They all show different behavior:
V 3.03:
fgen1_31_ok.lib works fine,
fgen1_32_fail.lib fails with several exception errors and file pointer errors, restart after power off of generator necessary to reestablish connection
4.03
Fgen1_31_ok.lib works fine,
Fgen1_32_fail.lib causes program termination without error message, after restart of fgu.exe no power off/on of the generator necessary
Debug_fgen1.lib causes program termination without error message
V 5 no lib file functions working, always error message “address violation”
Please help.
Question: I know that 8192 points on a curve can be uploaded to the generator.
Now please tell me the calculation limits for the repeating factors in a lib file.
I.e. I want to create a pulse train of 30 pulses 300 us on and 700 us off each pulse (1000 hz) followed by 2 off pulses of 1000 us each (1000 hz). That´s the sample file fgen1.lib that shall be driven at 31.25 hz.
you can see that the easiest way to calculate the timeslots is basing on 1 microsecond units and therefore the high repetition factors for each datapoint.
In a future release I want to use much higher repetition factors and so I need the limit the generator can cope with.
The reason for increasing the repeating factor is that I want to step down to ns resolution so that the UI can cope with double values for timing instead of long int.
The pulse train signals my UI creates are exclusively rectangular.
It seems that the problem occurs if there are more than 32000 samples in the data file.
The software tries to “resample” the file to fit to the 8192 samples space of the generator.
To avoid the problem please use less than 8192 samples in the input file.
To get sharp edges you can use the (0) operator in between the lines in the .lib file.
Instead of using this:
0.0(700)
1.0(300)
0.0(700)
1.0(300)
0.0(2000)
You can use this:
0.0(7)
(0)
1.0(3)
(0)
0.0(7)
(0)
1.0(3)
(0)
0.0(20)
The resulting waveform should be equal in both cases.
The edges with the second alternative are even sharper than with the first one.
Here are oscilloscope screenshots of both cases:
Here is the file that should output a waveform according to your specifications:
One alternative is to create always an “image” of the waveform.
This data file should be every time exact 8192 samples long.
There should be no repeating and no (0) operators, just plain data (-1.0 to 1.0).
though quite simple this lib parameter file produces a sawtooth curve instead of a rectangular pulse curve:
1.0(1)
(0)
0.0(1)
(0)
curve shape:
+++
+++++
+++++++
+++++++++
why? I need a rectangular output. please help.
after activating a new lib by SetLibWave() what exactly happens with the frequency and curve shape? Scope shows sometimes lower frequencies and sometimes higher frequencies until the frequency and curve shape I sent is established.
There seems to be a restriction to use the (0) operator.
The (0) can’t be used just after the start of the file.
There must be minimum one sample after the starting point.
To get symmetric (50% duty cycle) square wave you can use this data file:
1.0
1.0(1)
(0)
0.0(1)
or this one:
1.0
1.0(5)
(0)
0.0(5)
[quote]2. after activating a new lib by SetLibWave() what exactly happens with the frequency and curve shape? Scope shows sometimes lower frequencies and sometimes higher frequencies until the frequency and curve shape I sent is established.[/quote]When the waveform settings are changed, the generator can output different frequency for a short period.
Below is a link to download a modified version of the FGULINK.
In this version the generator output is blocked until the new waveform settings are complete.
Here is the link to download the modified version: box.net/shared/a5ub2zlbjq
Thank you very much for the updated linkfile. stopping and restarting with defined frequency is right the way I wanted to go.
according the workaround with a leading 1.0 I had tried it first but I thought that it would influence the duty cycle. now that it´s clear that it doesn´t we can say that the first parameter is a dummy entry, isn´t it?
Once more thanks a lot for your competent support.
[quote]Thank you very much for the updated linkfile. stopping and restarting with defined frequency is right the way I wanted to go.[/quote]Yes, this version doesn’t output the intermediate frequencies when the settings are changed.
[quote]according the workaround with a leading 1.0 I had tried it first but I thought that it would influence the duty cycle. now that it´s clear that it doesn´t we can say that the first parameter is a dummy entry, isn´t it?[/quote]Yes, we can think the first value is just the starting point of the waveform but it has no “length”. The next values make the waveform.
