Products > Test Equipment

SDS1204X-E scope freezing when collecting waveform

<< < (5/11) > >>

AnarchistWolf:
Id like to acquire the waveform every second or so (If your interested what im doing is Cavity Ring Down). for hours at a time, days if possible.

Im actually quite new to lingo in scopes so i havnt heard of holdoff. As for timebase it changes depending on how many waveforms i want to capture but that last i had set it to was 200ms/division.

Edit: More info, Freq is at 7540Hz, and i can get about 16 waveforms on the screen with that.

bdunham7:

--- Quote from: AnarchistWolf on June 21, 2022, 02:09:27 pm ---Id like to acquire the waveform every second or so (If your interested what im doing is Cavity Ring Down). for hours at a time, days if possible.

Im actually quite new to lingo in scopes so i havnt heard of holdoff. As for timebase it changes depending on how many waveforms i want to capture but that last i had set it to was 200ms/division.

Edit: More info, Freq is at 7540Hz, and i can get about 16 waveforms on the screen with that.

--- End quote ---

I'll assume from your other info that you meant 200µS (microseconds) not milliseconds.  OK, so holdoff is a delay before the scope retriggers.  If you set it to 0.5s, it will not capture more than 2 screens per second.  You can find it in the trigger menu.

AnarchistWolf:
Okay, so i have my trigger set a freq and im reading the waveform produced by a laser pulsing and some decay time.
Again maybe i dont understand this well enough but the scope is constantly being triggered on that freq. I am not stopping it and retriggering it every waveform capture.

(Unless its just doing that automatically and again im to new to know about it.)

Thanks,
W

2N3055:

--- Quote from: tv84 on June 21, 2022, 12:09:41 pm ---
--- Quote from: bd139 on June 21, 2022, 11:42:54 am ---There's no concurrency here.

--- End quote ---

Concurrency is what a scope never lacks...

What happens when the SCPI command inside the 100x loop is only "*IDN?"?

(It could be a bug, a feature and/or a buggy feature...)

--- End quote ---


When you execute *IDN? only, it doesn't have to allocate multi megabyte application buffer and adjacent stuff to TCP that to the other side...
One more thing to try is to try different sample memory size to see if it crashes faster or slower.

It smells like running out of memory to the point system is starved for resources and crash. Probably not deallocating all memory, but not happening when closing sockets might point to problem being with TCP transfer buffers..

Also a single capture-transfer cycle could be tried... But those are workarounds..

For OP use "open socket-transfer-close socket" once a second does the job though...

I would prefer to gather quality info so Siglent can easily reproduce and fix the deficiency if there is one...

tv84:

--- Quote from: 2N3055 on June 21, 2022, 02:41:13 pm ---It smells like running out of memory to the point system is starved for resources and crash. Probably not deallocating all memory, but not happening when closing sockets might point to problem being with TCP transfer buffers..

--- End quote ---

Too much vague to smell something specific. Although my nose smells concurrency.  :)

If a loop with 1 works and a loop with 100 doesn't work, how about a loop with 50, or 25, etc?

Once we get to a stable number, let's see how many times that stable number is stable. Always, failing occasionally, etc, etc?

This theme needs more info.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod