Ok, so you can get MMEM:CAT? even with that self-test error when waking up from standby? Does it works when you powering it up (hard reset/power switch)? Whatever is the case could you please add your observations as comment in issue
#88.
Added to Github.
Same error at hard reset. Seems to work immediately after flashing firmware (no errors), but never after that, soft restart or hard restart, next boot gives the error.
I also can't seem to make the serial port work other than for firmware updating. When I enable the serial port in the UI it doesn't "stick", and no debugging info seems to come out of the port (Native Due).
Added to Github.
Same error at hard reset. Seems to work immediately after flashing firmware (no errors), but never after that, soft restart or hard restart, next boot gives the error.
Thanks.
I also can't seem to make the serial port work other than for firmware updating. When I enable the serial port in the UI it doesn't "stick", and no debugging info seems to come out of the port (Native Due).
That is something else. Did you experience the same issue with serial port with
v1.02? Also, did you change your host PC? We have a lot of trouble with USB possibly thanks to USB isolator as many people reported that it works with one PC and didn't respond with other.
USB isolator speed is fixed to "Full speed" (12 Mbit/s), but many (newer?) PC USB ports don't like it, many they are expecting "High speed" what is theoretically 480 Mbit/s but still higher then "Full speed".
Issue 1:
With this desktop I can get the serial port to connect every time. I use a USB3 hub, seems to work correctly. I can monitor the port ok, as well as do firmware updates, just dont see anything.
Nothing comes out the serial port that I used to flash the firmware after a successful flash. No SCPI commands return any text. DISP:TEXT OK does nothing on the serial port.
Issue 2:
On the GUI, I go to page 2, select "Serial (via USB) settings", click "Enable", click "Set" - "Serial Settings Saved!" - "OK". Then, when you click "Serial (via USB) settings" it is not enabled anymore.
I tried enabling with the serial via SCPI over telnet, still nothing out the serial, or no SCPI commands worked over serial.
Same result 1.02 or 1.1.
Found a typo in the SCPI manual:
5.15.39. SYSTem:PON:OUTPut:DISable
Syntax SYSTem:PON:OUTPut:DISable {<bool>}
SYSTem:PON:OUTPut:DISable?
111
EEZ PSU SCPI reference v1.0
Description This command controls status off all channel outputs on power up. If enabled (ON), all
outputs will be disabled regardless of what is stored in user profile selected for auto
recall.
Return Query returns status of forced output disabling on power up.
Parameters Name Type Range Default
<bool> Discrete ON|OFF|0|1 OFF
Usage
example
OUTP?
1
SYST:PON:OUTP 1
Should be
SYST:PON:OUTP:DIS 1
Issue 1:
With this desktop I can get the serial port to connect every time. I use a USB3 hub, seems to work correctly. I can monitor the port ok, as well as do firmware updates, just dont see anything.
Nothing comes out the serial port that I used to flash the firmware after a successful flash. No SCPI commands return any text. DISP:TEXT OK does nothing on the serial port.
Issue 2:
On the GUI, I go to page 2, select "Serial (via USB) settings", click "Enable", click "Set" - "Serial Settings Saved!" - "OK". Then, when you click "Serial (via USB) settings" it is not enabled anymore.
I tried enabling with the serial via SCPI over telnet, still nothing out the serial, or no SCPI commands worked over serial.
Same result 1.02 or 1.1.
Ok, it seems that we have a problem when selected speed is higher then default (i.e. 9600). I can reproduce that problem enabling and working with USB it that case. Please confirm.
Ahh, interesting. After successfully storing 9600, i can then change and store any value successfully, including 115200, and this is true for 1.02 and 1.1. If you disable, you need to reenable with 9600 first, then you can change to another value.
RE SD Card:
If I move the lines
#if OPTION_SD_CARD
sd_card::init();
#endif
down below
#if EEZ_PSU_SELECTED_REVISION == EEZ_PSU_REVISION_R3B4 || EEZ_PSU_SELECTED_REVISION == EEZ_PSU_REVISION_R5B12
fan::init();
#endif
and recompiled, and that seems to avoid the error. Not sure if you needed the SD card earlier, but that was my observation. May be timing related.
After this, however, the MMEM:CAT? caused the unit to lock up.
I added this to the issue 88 on Github.
Ahh, interesting. After successfully storing 9600, i can then change and store any value successfully, including 115200, and this is true for 1.02 and 1.1. If you disable, you need to reenable with 9600 first, then you can change to another value.
Please open a new issue in GitHub for this one.
RE SD Card:
If I move the lines
#if OPTION_SD_CARD
sd_card::init();
#endif
down below
#if EEZ_PSU_SELECTED_REVISION == EEZ_PSU_REVISION_R3B4 || EEZ_PSU_SELECTED_REVISION == EEZ_PSU_REVISION_R5B12
fan::init();
#endif
and recompiled, and that seems to avoid the error. Not sure if you needed the SD card earlier, but that was my observation. May be timing related.
After this, however, the MMEM:CAT? caused the unit to lock up.
I added this to the issue 88 on Github.
We have to inspect what is going on here, just one more thing: what unit you have? From crowdfunding (version r5B12) or earlier one which has Arduino Shield r3B4?
I have crowd funding unit, and so does my local techspace.
@Prasimix,
I was fiddling with eh H24005 to control it with an ARB. Not being able to handle the push-in connectors immediately but did in the end (ahum). Did not quite get the results I wanted but that would be me I guess (SDG2042x => H24005) Re-reading the schematics and bumped into the fact that X12-1 is the input for remote programming however the schematics on page 11 state that is'connected to ground pin X12-2 is the input? See below link to your schematics file.
http://www.envox.hr/eez/component/jdownloads/send/2-psu/15-eez-h24005-schematics.html?Itemid=0
The link is broken but if you let me know what sheet number and version you are referring to I can find it. In the meantime did you have a time to watch short video that cover that topic:
Hi Prasimix, for me the link is not broken but I've also noticed in your latest RB513a version that the same reference is there on page 11 X12-1 is tied to ground and X12-2 is the input which does not match the pink text on page 8. The pink text does correspond with the white embossed text on the front panel though. LINK:
https://github.com/eez-open/psu-hw/blob/master/Consolidated/EEZ%20PSU%20consolidated%20r5B13a.pdfI've seen your video indeed already and it did already help a lot.
Ok, so I don't understand where is a problem: you have to bring external signal (2.5 V for full scale i.e. 40 V) to pin 1 and return/gnd to pin 2 as stated on the PSU front panel. Of course, the frequency cannot be in kHz or MHz, it could go up to few hundred of Hz. Also set current should be greater the zero, otherwise if channel is calibrated properly current control loop will hold output to zero Volts.
Hi Prasimix, the only 'problem' I noticed, or perhaps mistake is that I read X12-1 to be input and X12-2 to be GND. But on page 12 they are reversed in your schematic. Am I now mistaking perhaps?
Huh, I'm possibly too tired and should go to bed, but are we talking about this part on Sheet 8 of 12:
YEp an compare that to....
Yes, but that is External trigger input not analog input for remote programming. Please note that X12 and X14 are mounted on the bottom side of the PCB therefore pin counting is mirrored. What you marked are pins 7 and 8 on front panel.
Yes, but that is External trigger input not analog input for remote programming. Please note that X12 and X14 are mounted on the bottom side of the PCB therefore pin counting is mirrored. What you marked are pins 7 and 8 on front panel.
That is quite the puzzle then to mentally reverse that. I believe you could follow my thinking here as the text on the front panel is exactly the same and from left to right. :-)
Hi Prasimix, can I send you a PM since I'm trying to generate with my ARB (SDG2042X) voltages on the H24005 but am barely successful. Using a simple wire from the COAX to the channel #1 or #2 input at: 1.00 Vpp and 1.00 V offset I'm getting a TOO high voltage programming voltage input detected message (orange box). Lowering to 500mV and 500 mV it's working but the graph at 2, 20 or 200Hz barely is a nice sinusoidal or square wave trace. Any tips, suggestions?
Lowering to 500mV and 500 mV it's working but the graph at 2, 20 or 200Hz barely is a nice sinusoidal or square wave trace. Any tips, suggestions?
Are you referring to "YT-view" mode on the PSU's display or did you measured that with your scope? Please note that YT-view is quite limited, and fastest refresh rate is 10 ms.
Yes I was referring to the YT view too indeed. I will re-test again later today. I was not sure how to get a 0 - 40 V range on the output. You were showing a more dynamic and larger graphs too. What are the max off-set and Vpp voltages?
Ok, then you have to know that with current MCU that is trying hard to generate and measure output voltage and current, and draw that on display without assistance of graphical controller/accelerator (which doesn't exists
) you cannot expect miracle.
Here is few examples of signal measured with scope. Pulse with D=0.3, 100 Hz, programing voltage of 2.5 V (i.e. full scale) and DC offset on the half (1.25 V) is show below. You can see that rising speed is about 20 V/ms, and falling about 10 V/ms
without load attached.
... ramp with same frequency and amplitude is 2 V / 1 V DC offset:
... sinewave with same frequency and amplitude:
It's clearly visible that such frequency is too high for analog part of the PSU, sinewave with lower frequency, e.g. 60 Hz looks much better:
But on the PSU display you can expect even with the fastest refresh rate od 10 ms (i.e. 10 drawings/sec) a nebulous graph:
You have to considerably lower the frequency to get meaningful results on the display, e.g. 5 Hz sinewave: