PCGU1000 - Unit "ticks" and O/P Led Blinks?

I just got my PCGU1000 a couple of days ago and I am having some problems with it.

If I use the “Wave Sequence” tool and load this file :

[ul]1 60000 0.0 10.0 0.5
1 60000 0.0 1.0 0.5
1 60000 0.0 10.0 0.5
1 60000 0.0 1.0 0.5[/ul]

I choose “Repeat” and “Run” the profile. The Funct Gen now makes a high pitched “tick” sound every second and o/p led dims down for one second and then goes back to full brightness for another second.

It does this wether I have nothing connected to the output or my little wire ariel. (I am testing a 60khz radio reciever)

IS MY UNIT FAULTY ??

Also, which is quite anoying, when I “Exit” from the wave sequence dialog I get the following error message box :

“No Function Generator response”
“Please make sure …”

So after this I have to unplug the power supply and usb cable, then reconnect to get it to work again.

I should be using the latest software and driver as I download and installed from the support site just two days ago. (The CD that came in the box completley failed to install anything !!, wowexec.exe and setup.exe just hung !)

The PCGU1000 can’t produce wave sequence at repetition rate of 0.5s continuously.
The setup time of the generator is about 0.6 seconds.
There is not enough time to set up the generator properly if repetition interval is continuously 0.5 seconds or less.
The waveform data contains 8192 bytes of data. This data has to be sent to the generator via the USB “serial port” every time the waveform settings are changed.
The data sent to the generator is buffered. So it is possible to send periodically at the rate <0.5 seconds but not continuously.
If continuously sent the buffer finally overflows and the generator gets bad setting information. This causes the generator to act as you described.

Solution: You may send a sequence of 0.5s instructions to the generator, but periodically you should send longer instruction to “clean” the data buffer.
Here is an example: 1 60000 0 10 0.5 1 60000 0 1 0.5 1 60000 0 10 0.5 1 60000 0 1 0.5 1 60000 0 10 0.5 1 60000 0 1 5

I bought the function generator to test my MSF 60khz radio signal reciever ! The MSF time signal is simply modulated onto the 60khz carrier by turning the transmitter power right down or off every second for 100,200 or 500ms. Thus I just want to turn the output on/off every second for a few hundered milliseconds. How hard can that be ?

I can see why 8k bytes of data might be required to “digitise” a full wave form, but to turn the output on/off is booean piece of data, that surley should not require more the few bytes to be sent via the USB ? So did your firmware engineer design a communication protocol that needs 8k data to tell it to turn the output on/off or just to change to a different amplitude ?

Also why don’t I get “buffer overflow” error if it can’t handle choking on too much data ? Perhaps firmware engineer ignored this in his design and prefers the code to “crash” and become un-useable ?

Are there any commands in the FGULINK.DLL that can just turn the output on/off ? I have a working Visual C++ prog interfaced to the DLL.

Failing that, is the firmware in the unit “open” source ? Perhaps we can add some simple commands to the communication structure ? Commands that implement “delta” updates. eg “UpdateAmplitude(float voltage)”, “UpdateOffset(float voltage)”, “OutputControl(boolean on)”

Sorry there is no fast option in the FGULINK.DLL to turn the generator On/Off.
The firmware is not open source.

It still “ticks” every loop, even with this dead simple and SLOW update?

1	60000	0.0	10.0	2.5
1	60000	0.0	0.0	2.5

Please: There is no need for a sarcastic attitude, people are just trying to help.

[quote]It still “ticks” every loop, even with this dead simple and SLOW update ?[/quote]The signal output is turned off by the relay for a short period of time when the signal amplitude is increased.
This is done to avoid possible “overvoltage” output.
The “tick” is “normal” effect.

Sorry for the sarcastic attitude but I am incredulus that you supply a PC “programmable” function generater that falls over and locks up when running a simple wave form procedure like I showed you. Your answer that you designed in this clumbersome limitation and its not a bug would not impress many engineers.

This problem you found is a new finding.
This ‘bug’ is difficult to fix because the overflowing data buffer is included to the third party USB driver.
Instead: Warning should be added to the documentation not to use less than 1s wave periods in the wave sequence.

You should not blame the USB chip manufacturer who is the piggy in the middle here. You are incontrol of the firmware in the function generator and the C/C++ code for FGULINK.DLL on the PC. You just need to find a way of sending small command strings instead of 8k blocks of data over the USB link to implement functions like “set amplitude” or “set frequency”. I would have thought that could be done with command strings of just 10 or 20 bytes enabling hundereds of commands to be sent each second without overflowing the buffers.

Can the command used by FGU.exe to start/stop the generator output (when clicking/toggling one of the waveform selection buttons–see below) be made available in FGULink.dll?

I ask because I created the following waveform by just rapidly clicking the sine wave button off/on using the mouse (the top trace is a series of my clicking the command button, the lower trace is an expansion of the section highlighted in the top trace):

It is the 60 kHz modulation frequency required by the OP, switched on and off using the Sine wave button (which seems to toggle the generator’s output relay). My index finger is not that well calibrated however I achieved a 357 ms dropout by clicking the mouse button. 70 ms is the shortest “off” period my old arthritic finger could muster, so programmatically the 100 ms dropout should be doable.

The output relay’s reaction time will of course affect the intervals, also it might be asking a bit of it to be in continuous use. A better and almost as simple solution would be switch the generator’s output electronically, external to the PCGU1000. With a 60 kHz signal nothing too exotic would be required…

The precision of this might not be what the OP needs, however if that command were exposed in FGULink.dll it would be an easy task to add a timer to the PC application and perhaps meet the OP’s needs…

Switching the signal On/Off by the button is quite fast indeed.
Now this fast feature is “copied” to the FGULINK too.
Here is the link to download the modified test version of the FGULINK package:
box.com/s/smlqt5hvoxx2vbyw60cc

There is the demo software included to the package.
There is also 500ms/500ms On/Off test demo added to the demo software.

Here is a screenshot of 60kHz waveform run in the 500ms/500ms On/Off mode:

[quote]The output relay’s reaction time will of course affect the intervals, also it might be asking a bit of it to be in continuous use.[/quote]The DLL functions StartGen and StopGen are now faster and they are no longer using the relay to switch the signal On/Off.
So only the waveform is turned On/Off but not the possible offset voltage at the generator output.

Well and quickly done, I expected no other outcome!

I created this signal using VB6 and two CCRPPrecisionTimer controls:

One timer fires after the generator output has been ON for 900 ms. This timer’s handler then turns the generator output OFF and enables the second timer. After 100 ms the second timer fires, turns the generator back ON and enables the first timer.

Thank you for testing the modified “test” version of the FGULINK DLL package.
Seems to work as expected! :slight_smile:

Something I wanted to point out is that to use this for any serious timing application would be dependent on the controlling PC’s multimedia clock, which are generally not all that great and are in no way intended to be precision long term counters.

Also, even if it were driven by the PCGU1000’s clock, there would be a lot to be desired (no offense Velleman, you guys know I am a devout advocate) with regard to long term accuracy. I have no idea what the OP’s expectations in this regard are–“just sayin’”…