I don't think I will try an "LFCal" any time soon...
I can't figure out, however, what this would be used for. Why would one want to store and recall a calibration
I guess those to buttons are only meant for debugging or service purposes anyway.
Sorry, but the chinese/japanese characters are changed by smiley in my post, i didn't check that by preview, so lock in your own file to see its
FILE CONTENTS |
Has anybody looked at the file? Is it binary/ASCII? How big is it? If it's binary, have we got a hex dump?
Attached is the screencopy of "LFCal".
In case somebody thought that most bugs have been solved, I have an unpleasant surprise:
The command :FUNCtion:WREPlay:FMAX? returns the value that belongs to :FUNCtion:WREPlay:FEND
instead of the number of recorded frames.
Example: 5 frames have been recorded. :FUNCtion:WREPlay:FEND is set to 5.
When using the command :FUNCtion:WREPlay:OPERate PLAY, it plays the 5 frames as expected.
Now use the command :FUNCtion:WREPlay:FEND 3 to playback frames 1 to 3.
When using the command :FUNCtion:WREPlay:OPERate PLAY, it plays the 3 frames as expected.
Now, when requesting the maximum number of frames that can be set to playback using the command :FUNCtion:WREPlay:FMAX?
it returns 3 instead of 5.
:FUNCtion:WREPlay:FMAX?
Description Query the maximum number of frames can be played, namely the maximum number of frames recorded.
Who is actually communicating all these bugs to Rigol? Or is there a Rigol application engineer on this forum?
I have read the manual and it's not correct behaviour. Thank you very much.
Instead of showing me a screenshot of a part of the manual that I have already read for three times, you could maybe offer
some arguments or reasoning why you think it is correct.
The maximum number of frames recorded is 5.
The maximum number of frames to be played back is set to 3.
The query to maximum number of frames that can be played back should be the number of recorded frames: 5.
The query to maximum number frames set to playback is 3.Quote:FUNCtion:WREPlay:FMAX?
Description Query the maximum number of frames can be played, namely the maximum number of frames recorded.
When you set the end frame for playback, you don't change the number of recorded frames.
Use the :FUNCtion:WRECord:FEND command to set the maximum number of frames
recorded.
I'm not talking about :FUNCtion:WRECord:FEND.
I'm talking about :FUNCtion:WREPlay:FMAX
Changing the setting for :FUNCtion:WREPlay:FMAX has nothing todo with :FUNCtion:WRECord:FEND.
Recording and playback are two completely different things. Once you have recorded some frames (5 in the xample),
you can playback them, either all five or just one or only frame 2 to 4. This does not affect the number of frames stored in memory.
After playback has finished, you can playback again the same frames or set other values for the number of frames to playback.
Again, as long as you don't record again, the number of recorded frames stays the same.
What's so difficult to understand about this?
I'm not talking about :FUNCtion:WRECord:FEND.
I'm talking about :FUNCtion:WREPlay:FMAX
Changing the setting for :FUNCtion:WREPlay:FMAX has nothing todo with :FUNCtion:WRECord:FEND.
The documentation clearly claims otherwise.
QuoteRecording and playback are two completely different things. Once you have recorded some frames (5 in the xample),
you can playback them, either all five or just one or only frame 2 to 4. This does not affect the number of frames stored in memory.
After playback has finished, you can playback again the same frames or set other values for the number of frames to playback.
Again, as long as you don't record again, the number of recorded frames stays the same.
What's so difficult to understand about this?
If the documentation says that "function A reads value X, and function B sets value X", then how is it a bug when your use of B results in A reporting the value that you handed to B?
:FUNCtion:WREPlay:FEND != :FUNCtion:WRECord:FEND !!
:FUNCtion:WREPlay:FEND != :FUNCtion:WRECord:FEND !!Ah. Yes, you're right, those should be different. My apologies. So it appears the internals are confusing the two, which is a bug.
In case Rigol does ever visit: Rigol would, at this point, have nothing to lose and everything to gain by releasing/open sourcing the firmware.
...
Can anyone else here come up with business arguments that would make this move a clear win? Is there something I'm missing, where they will be throwing away something that Rigol considers critical?
Cheers,
-tg