Test of R&S®HMP4040 in devel

added testing label

changed the description

Sorry for being stuck in such an early stage, but I'm not being able to successfully compile the code. I'm getting

  The source directory

    /home/mario/work/labRemote/src/exts/nlohmann_json

  does not contain a CMakeLists.txt file.

if I just "git clone", without including the nlohmann_json submodule (I understand that), but then many lines like

/home/mario/work/labRemote/src/libCom/ICom.h:5:10: fatal error: nlohmann/json.hpp: No such file or directory
 #include <nlohmann/json.hpp>
          ^~~~~~~~~~~~~~~~~~~

if I "git submodule update --init" afterwards. I see that the last commit on devel passed the pipeline, so it is most likely some needed extra configuration that I'm missing when configuring with CMake. I'm sorry if these new requirements are already written somewhere, I haven't found them so far.

Hi @mariog , this is something that we came across yesterday too and is being addressed by !99 (merged) .

Our CI installs a central nnlohman_json (yum install json-devel), so it missed the broken dependency when using the external package.

Hi @epianori, thanks a lot. It builds with no problems on fix-exts-json. I'll work from there and update you as soon as possible.

Sorry, @kkrizka. Best, Mario.

Hi @epianori and @kkrizka,

I have already tested the communication with R&S®HMP4040 in fix-exts-json and these are the results:

The functions that read from the PS are all working fine, but the functions writing on it are not working properly. They don't return any errors, but they don't write the request (e.g. the Voltage Level) on the PS. As it appears, the R&S PS is having some timing issues after the sleep functions were removed.

Specifically, it looks like it needs a bit more time between (for example) INST:NSEL 2 and VOLT 6.000000. Sleeping some time (e.g. 200 ms) at the beginning of each send call makes it work fine again.

This doesn't happen when reading, since at that time we're sending to the PS "INST:NSEL " + std::to_string(channel) + "\n" + "VOLT?" instead of two separate commands to select chanel and read the voltage. I'm not sure if this will continue happening after merging the generic SCPI class in !90 (merged) though.

Hi @mariog , currently the SCPI class keeps that structure where first we set the channel and a separate command sets the voltage; however, the channel is set in a separate function (just as in the AgilentPs class).

@kkrizka , any thoughts on this?

Hi, I'd like to let you know that I'm still trying to get rid of the timing issues here without sleeping at all (I know that was the point of the lock and unlock functions). I'll tell you if I come up with a cleaner fix during this week.

Best, Mario

Hi @mariog ,

Thank you for continuing to look into this. Some notes from my end that might help with this.

The removal of the sleep function is not related to the lock/unlock. They should work with sleep too.

The purpose of sleep was to 1) give the power supply time to respond and 2) for the complete data to be transferred into the USB device buffer on the PC. The amount of wait time was rather arbitrary and I've found situations where I had to increase it even further (ie: running labRemote on a Zynq SOC FPGA).

Thus the sleep was removed in favour of reading from the device until the entire message was received, as indicated by the termination character (\n). This seemed like a more stable (and potentially faster) method to deal with 2).

However I am starting to believe that 1) is a problem for this method. For example, in !97 (merged) I had to add a timeout to our Prologix USB-GPIB interface. In some cases, I've seen that the Prologix box tried to read the response before the power supply was ready to send it. The result was a correctly terminated empty string read by labRemote.

I wonder if you are seeing a similar problem with the direct USB interface. That is, we are sending the second command while the power supply is still busy processing the first command. Thus is ignores the second one.

Note that I run the CharDeviceCom (meant for direct USB connections) with a E36300 without any problems here.

I realized one more thing. Your PS uses the cdc_acm driver, which I believe corresponds to a serial device. So you should be using TextSerialCom. The CharDeviceCom is meant for power supplies with the usbtmc driver that expose the power supply as a simple character device.

Sorry for the confusion.

@mariog Can you also clarify which communication implementation you are using?

Hi @kkrizka,

We have been using TextSerialCom with no problems so far. What's happening when we send two consecutive commands to the PS is exactly what you describe. The second one is ignored because the PS is busy with the first one when it receives it. I've been trying to get any response from the PS confirming that a command has been received with no success so far.

The HMP has a so called "handshake" function that would solve all of these timing problems, but we must use the RS-232 interface of the PS to enable it, which we are not doing right now. I don't seem to be able to find any solution from the software side.

At any rate, if we had to end up sleeping, we would need to do that only between two send calls. I wonder if this could be the solution.

Hi @kkrizka, I have some news on this:

Sleeping between send "select channel" and send "select voltage/current" (in RS_HMPXXXX.cpp) will also solve the issue. I've been doing some trial and error and for our PS 1 ms is always enough.

Here, by "sleeping" I mean either actually sleeping or doing anything else that does not interfere with the PS. Since this is a very small amount of time, I wonder if sleeping could actually be a possibility.

Hi @kkrizka,

I've been testing this a bit more and it looks that the sleeping time needed between commands to not ignore the second one depends on what the first command does. So between "select channel" and "set voltage" one millisecond is enough, but we would need up to 7 between "set voltage" and "turn the output on".

The manual says nothing about the USB interface (the one we're using) with respect to this, but it recommends sleeping between 50 and 100 ms between commands if using the RS-232 interface (sec. 7.1.3).

Also, it mentions that both for RS-232 and the GPIB interfaces, there's available a so-called "handshake" function, that would make the communication synchronous so we don't need to worry about sleeping times. Of course to use these we would need to buy the actual physical interface.

mentioned in issue #45 (closed)

mentioned in merge request !167 (merged)

Test of R&S®HMP4040 in devel

Designs

Child items ...

Activity