-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CRC error RDTech DPS #9
Comments
Hi robofreak, looks like a bug in the sigrok rdtech-dps driver, or more specific in the modbus CRC check (modbus_serial_rtu.c -> modbus_serial_rtu_read_end()). Furthermore the driver is missing a mutex. That's a generic fix I can add, when the CRC check is working. |
had the same error with sigrok-cli. So it is a bug in the driver. |
Thank you, for your fast response.
Here is the log from smuview. I see it is linked again sigrok v0.6. So maybe this error is already fixed in newer sigrok versions:
|
interesting! |
I've looked into the driver code, but without the device there is not much i can do. Unfortunately, the logs you attached doesn't help either. Perhaps the error occurs so fast with SmuView because of the missing mutex? I'll add the mutex in the test AppImage too. @littleyoda : You have a Korad psu, don't you? It would be great, if you could confirm the thing with the unreliable buttons and check if my fix is working (issue #7 ). |
My Modell of the Korad psu do not have these buttons. Sorry, can not test it :-( |
I have done some further investigation. When thesigrok-cli is running in log level 5 I can see the crc error occuring, when the USB connection has been closed.
|
Hi robotfreak, You don't need to add "-l 5" for the log output this time. |
Hi knarfS,
|
Hi knarfS, success. I got it working. The only change I made, is in the rdtech_dps_capture_start function. Setting devc->expecting_registers to 0, instead of 2. Not sure if this is the right way to fix it, but for me it works. Now the device_close function will never read any pending data.
|
The CRC error was a red herring and only a subsequent error... :( I don't think your fix solved the actual error, though the expecting_registers thing doesn't make much sense the way it is implemented... I updated my branch with more log output in the interesting parts. Would be great if you could attach a log without your patch and one with. |
Now I get a memory access violation error with or without my patch the log output looks the same: .```
|
Ups, my bad. |
ok, here are the logfiles for the updates branch with and without my patch. |
Development moved to https://github.com/knarfS/libsigrok/tree/patches2 Both tests failed, when trying to get the ovp_active config key. The code for getting the config key looks OK, as far as I can tell. Could you try to get the key with sigrok-cli (replace conn string with your settings): Next thing I can do is deactivate this two config key and then testing if there are other config keys that are failing. |
Here are the log files for ovp and ocp active config key: |
I think I got it! It was hopefully only a timeout that was set to low. |
Here are the log files. The serial_read_blocking time varies from 33...124 for ovp, 19...91 for ocp. |
The important duration is 1st serial_read_blocking() in modbus_serial_rtu_read_begin() which is around 450ms. Pretty close to the former timeout of 500ms. But the most important question: Is SmuView working now? |
No, smuview don't work. Here is the log: |
Yeah, but my assumption was right ;) However the timeout of 1000ms was still to low... |
Cool, now smuview is working. Thank you so much knarfS |
Could you attach the log output, so I can adjust the timeouts and make a pull request to libsigrok. |
Damn, this is too bad. Yesterday smuview is working, today not. Here is the logfile from today. I have not got one from yesterday. |
It's again the timeout. Seems like sometimes 5s isn't enough. Puhhh.... Could you play around with the timeout by yourself? You'll find it in src/modbus/modbus_serial_rtu.c, line 148. I'd start with 20000ms (THAT should be enough) and then look at the time in the log ("modbus_serial_rtu_read_begin(): 1st serial_read_blocking() time =") and adjust it down. When SmuView is running stable, start to change the output voltage, current, toggle the output, etc. to stress the power supplies lil' CPU and check if the duration of the serial_read_blocking() is rising... |
Sorry, but I don't get the timeout working. Even 40s isn't enough. At the moment the chances are 50:50 to start smuview succesfsully. If smuview starts successfully, the blocking time is always less than 5s. |
Sorry for the late reply. |
No worry. Now it is working like a charm. Phantastic job! |
I moved the patches for the RDTech power supplies back to my branch "patches" (https://github.com/knarfS/libsigrok/commits/patches). I also added meta packages: When the regulation (CV/CC) or the output state changes or one of the protections (OVP/OCP) is triggered, that will be displayed in SmuView. I would be happy, if you could test my changes again and append a log file with log level 5 (./smuview -l 5) |
Here are the log files (first failed connection, second successful connection): |
Most of the issues should be fixed in libsigrok since 16.12.2019 and are now available in the SmuView 0.0.4 binaries. |
Can anyone confirm that the x86_64 appimage from 0.0.4 is working for the DPS? I tried on both Windows and Ubuntu and experienced the same CRC error with the files from the latest release. I've confirmed that the DPS works properly using RD Tech's software on Windows, so I don't think it's a problem on my hardware. I tried building from source on Ubuntu and ran into python issues using either the method from the SmuView manual or the Sigrok Building from Source page. |
I've implemented a workaround in the sigrok driver for the DPS devices some time ago (see sigrokproject/libsigrok@aff2094). Because I don't own one of those PSUs, I can't do a proper investigation of that problem.
Can you give some details about that (CMake and/or make output)? Probably a missing dependency or something similar. Maybe open a new issue. |
I got a CRC Error when trying to connect a RDTech DPS Power supply:
The text was updated successfully, but these errors were encountered: