tknopp / RedPitayaDAQServer

Advanced DAQ Tools for the RedPitaya (STEMlab 125-14)
https://tknopp.github.io/RedPitayaDAQServer/dev/
Other
37 stars 10 forks source link

Improved documentation of examples #24

Closed jusack closed 3 years ago

jusack commented 3 years ago

Hi, before you fixed it a few days ago, the Julia example in the documentation was not up to date, causing my first copy-pasted attempt to fail. I found a way to include the contents of the Julia script for the example in the Markdown file handled by Documenter.jl. This will keep the documentation from breaking as long as the examples are updated when new changes occur.

I also fixed the plot under the first example and added a page for the waveforms example.

Greetings from Lübeck, Justin

tknopp commented 3 years ago

wow, this is really cool Justin!

tknopp commented 3 years ago

So I have to disclaim one thing: The documentation is right now not really done. So please there might be still quite some errors in it.

I will merge this right now since I want to see what Documenter will do out of it :-)

tknopp commented 3 years ago

I added you to the list of contributors. This has the advantage that you can directly work in this repo and create branches. This makes your live a little bit easier. You can then still make pull requests by branch comparison. I can also cherry-pick things from you branch. We typically use acronyms e.g. ja/docu for a branch that you initiated and that deals with documentation :-).

jusack commented 3 years ago

Thanks, that's awesome! I also noticed that the Julia client does not care if I set invalid values for the decimation (maybe also other parameters, I haven't checked). I might add some checks in the client, since the limitations are (as you said) not really documented ;)

tknopp commented 3 years ago

yea indeed. I am not fully sure how we should deal with that exactly. So who is responsible for doing the checks. Client? Server? We want some general strategy here.

jusack commented 3 years ago

I found that the server itself puts an unspecific error in its error queue, which the client can (but does not have to) check, however I am not sure how useful it would be to cehck this after each SCPI command. In my opinion it would be more user friendly to allow the Julia client to only send valid commands, but then it would have to be updated in two places if the server gets changed.

tknopp commented 3 years ago

yep. I think for now it is ok put some checks to the Julia client library. The downside really is that we also have the Matlab and the Python client library which motivates to put actually more things into the server instead of the client, to keep the client small. Maybe it would be more simple to just drop the Matlab/Python client library. Or just drop Matlab and focus of bringing the Python library into the same state as the Julia ones.