Products > Test Equipment
SDS1204X-E scope freezing when collecting waveform
bd139:
Ok had a few mins while on a pointless zoom call.
I'm running macOS 12.4 python 3.8.9 --> SDS1202X-E running 1.3.26 over wifi then ethernet.
Mine successfully runs everything up to "Query complete. Exiting program". At that point none of the physical controls are working. The network interface stops responding then as well which requires that I power cycle it by physically pulling the plug on it. I suspected that this would be related to LOCK being initiated when switching into remote mode which is a possibility but the whole network side pukes so I can't even validate that.
This is definitely a scope bug that is reproducible.
Edit: the firmware I have appears to be the latest published.
Edit 2: if you ctrl+C the python process then the whole scope hangs solid as well.
That is quite frankly shit!
2N3055:
So code opens the socket, asks for data 100 times and then closes the socket.
Could somebody try to open and close socket before and after each data transfer..
Maybe some buffers are not alloc/dealloc correctly, and they might get released with the socket destroy..
I'm not saying it's a solution but might point to exactly where the problem is...
bd139:
Edit: just added that test case.
More info.
1. If you open the socket, run 100 commands through, then close it -> CRASH.
1. If you open the socket and close it immediately without executing any commands -> NO CRASH.
2. If you open the socket, run one command and close it -> NO CRASH.
3. If you open the socket 100 times and run one command then close it, it takes bloody forever -> NO CRASH
So workaround is:
--- Code: --- for i in range(100):
s = SocketConnect()
qStr = SocketQuery(s, b'C1:WF? DAT2')
time.sleep(0.5)
print (str(count) + ":: " + str(qStr))
count = count + 1
SocketClose(s)
--- End code ---
So it can't be trusted to execute more than one command per connection reliably. Smells like some stupid C somewhere.
Someone at Siglent should get a JTAG debugger on it and gdb, crash it, get a bt and fix this ASAP. Big :-- :-- :--.
tv84:
--- Quote from: bd139 on June 21, 2022, 10:44:49 am ---Edit: just added that test case.
More info.
1. If you open the socket, run 100 commands through, then close it -> CRASH.
1. If you open the socket and close it immediately without executing any commands -> NO CRASH.
2. If you open the socket, run one command and close it -> NO CRASH.
3. If you open the socket 100 times and run one command then close it, it takes bloody forever -> NO CRASH
So workaround is:
--- Code: --- for i in range(100):
s = SocketConnect()
qStr = SocketQuery(s, b'C1:WF? DAT2')
time.sleep(0.5)
print (str(count) + ":: " + str(qStr))
count = count + 1
SocketClose(s)
--- End code ---
So it can't be trusted to execute more than one command per connection reliably. Smells like some stupid C somewhere.
Someone at Siglent should get a JTAG debugger on it and gdb, crash it, get a bt and fix this ASAP. Big :-- :-- :--.
--- End quote ---
0.5 is the smallest delay you can get reliably?
I think you will always have a limit in that number of consecutive operations. It's better for the user to control it in a specific situation than for Siglent to put a hardcoded limit that will affect everybody in all situations.
bd139:
There's no concurrency here. Operations always fully return before the next one starts.
Either way it should be reentrant and shouldn't crash the remote end. If it's not that's a bug.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version