Products > Test Equipment

Siglent SDS1104X-E and SDS1204X-E: Bode plot with a non-Siglent AWG

<< < (31/35) > >>

awakephd:

--- Quote from: bateau020 on September 17, 2024, 04:46:16 am ---In order to make espbode (or the python script) into a siglent emulating SCPI frontend for any AWG, that respects at least some of the standards, 3 loops/threads/processes are needed:

* 1 that does portmap on UDP (this part is used for broadcasts/discovery and by the HD scopes)
* 1 that does portmap on TCP (this part is used by direct VISA communication, as with the non-HD scopes
* 1 that does the VXI-11 communication (on TCP)The latter should switch to a new port after every LINK_DESTROY, and communicate the new port to the port mappers.

Made this work in the python version, in today's commit. Previously it only ran 1 of those loops at a time, which messed up communication with other SCPI tools.
Haven't really looked yet at how espbode does it.

--- End quote ---

Thanks, bateau. The espBode code assumes a sequential process, and of course at the moment, does not correctly respond to the HD scopes. It does not change ports, and it does not check the AWG to be sure the command succeeded. (At least for the FY6900 driver, it checks only for the newline character that is returned whenever a command is issued.) There is an interesting quirk in the code where it sends some commands twice, "because the AWG doesn't always respond the first time," and yet at the same time it also has some code to avoid repeating the same command when it has been issued by the scope - a comment says that the 1000-series scopes repeat some commands. All of this, and much, much more, is why this code is overdue for a complete rewrite.

I did have a chance last night to do a q&d test of UPD communication, just enough to verify that I can receive the expected 56-bye packet. Hopefully later today I'll have time to work up the rest of code to respond, change ports, etc.

I look forward to reviewing the changes you've made to the python code to allow the various loops to occur in tandem, rather than sequentially - and again, thank you for your tremendous help and work on this project!

Knutselaar:
Hi awakephd,

I made the driver for the FY3200.

awakephd:
Thanks! I will include that in my "history" of the program.

awakephd:
bateau,

I have been working on a q&d implementation of the espBode code that will handle a UDP bind request. I think I am almost there, using your python code as a reference. But I am not understanding the next-to-last line of your process_rpcbind_request_udp method:

self.rpcbind_socket.sendto(resp_data, address)

Does this send back to the originating IP and port? How does it get the data length? I would have thought the format would be sendto(buffer, length) - but "address" doesn't sound like a length.

For that matter, I am confused by the line near the start of the method where you set address as follows:

address = bytesAddressPair[1]

This would seem to set address to equal the address of the buffer + 1 byte (maybe??).

As is probably obvious, some of my confusion has to do with minimal knowledge of python. Any help you can give will be most appreciated!

By the way, I tried to figure out if there was a way to contact you via the github repository, but I could not figure out how to do that. :(

bateau020:
PM sent.

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